 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / CSS / August 2006Vertical alignment of text within a DIV
Sorry if this is a dumb question buy my CSS is pretty bad... but how do I get text to center vertically within a div tag? Here's my code below... the text is displaying on the far top-right. I would like it far right centered vertically. #test { width: 100%; height: 55px; margin: 0 0 0 0; padding: 0 0 0 0; border: solid #3366CC; border-width: 1px 0 0 0; text-align: right; font-size: 14px; font-weight: bold; color: #ffffff; } <div id="test">would like this text centered vertically</div> > Sorry if this is a dumb question buy my CSS is pretty bad... but how do > I get text to center vertically within a div tag? You don't really, at least not in the same way as in a table cell. > Here's my code > below... the text is displaying on the far top-right. I would like it [quoted text clipped - 15 lines] > > <div id="test">would like this text centered vertically</div> Add a <p> around the text inside that div, and give it a top margin. It will always stay at that level though, regardless of the text wrapping or font resizing. Yes, the text will be resizable, in any other browser than IE - as it should. To give IE users the same benefits, please don't set a font-size in px, but use % or em.  SignatureEls http://locusmeus.com/ accessible web design: http://locusoptimus.com/ Now playing: Camel - Lady Fantasy (Bonus track) thanks > > Sorry if this is a dumb question buy my CSS is pretty bad... but how do > > I get text to center vertically within a div tag? [quoted text clipped - 32 lines] > > Now playing: Camel - Lady Fantasy (Bonus track) >> Sorry if this is a dumb question buy my CSS is pretty bad... but how >> do I get text to center vertically within a div tag? [quoted text clipped - 26 lines] > other browser than IE - as it should. To give IE users the same > benefits, please don't set a font-size in px, but use % or em. Actually this is a major short coming to CSS, as I jsut keep seeing more and more cases of it jsut makes life difficult and painful for what shoudl be basic things. Just like the "equal column height" and proper multi column layout dilemas. Seriously, I cannot fathum how the inventors of CSS (at least the position part; the formating parts of CSS are not a prolbem at all and work great) could not of made it straight foward. Would it really have been so horrible to having something like align-vertical, align-horizontal, and proper height control (notice how 100% heights on DIVs inside DIVs sometimes push out of the confines of the outer div, when the spec CLEARLY states the height % should of the CONTAINING DIV's space. This strangeness happens is virtually any CSS supporting browser I've tested (Moz, FF, IE, Opera...) I'm sorry, but it really seems CSS has not yet come of age. don't get me wrong, CSS is a triuth in many areas, but in the area of layouts, anything advanced (or many things easily doable with, gasp, tables) it just seems so lacking. At the very least, it makes many things easy (having styles that can be easily reused) but at the same time it makes many thing a heck of a lot harder than they should be, or even near impossible without some wild or strange hackery. (Keep in mind I don't mean cross browsers hacks.) >Actually this is a major short coming to CSS, as I jsut keep seeing more >and more cases of it jsut makes life difficult and painful for what >shoudl be basic things. Just like the "equal column height" and proper >multi column layout dilemas. Equal "column" height is possible with CSS2 methods, but IE doesn't support that part of CSS2. Multi column layouts (text ends at the bottom of one column and continues at the top of the adjacent right column) make no sense at all on the web, the fact that this cannot be done with CSS2 is a good thing. (Regrettably it looks like CSS3 may provide authors with a method to create such monstrosities.) >Seriously, I cannot fathum how the inventors of CSS (at least the >position part; the formating parts of CSS are not a prolbem at all and >work great) could not of made it straight foward. Would it really have >been so horrible to having something like align-vertical, >align-horizontal, Although not implemented in a straight forward manner, again this is possible using CSS2 methods, but again not supported by IE. The fact that IE doesn't support these bits of CSS2 could be considered as a blessing in disguise because the way that it is provided for in CSS2 has all the drawbacks (minus one) of HTML tables: reflows, or nothing being rendered until all content has been downloaded. >and proper height control (notice how 100% heights on >DIVs inside DIVs sometimes push out of the confines of the outer div, >when the spec CLEARLY states the height % should of the CONTAINING DIV's >space. You misunderstood the phrase "containing block" http://www.w3.org/TR/CSS21/visuren.html#containing-block >This strangeness happens is virtually any CSS supporting browser >I've tested (Moz, FF, IE, Opera...) Moz, FF and Opera more than likely render such according to spec, your understanding is flawed. >I'm sorry, but it really seems CSS has not yet come of age. don't get me >wrong, CSS is a triuth in many areas, but in the area of layouts, [quoted text clipped - 4 lines] >impossible without some wild or strange hackery. (Keep in mind I don't >mean cross browsers hacks.) Sadly CSS2 does not offer a good method for creating layouts suitable for the web, this is indeed a shortcoming. But layouts that work on the web are a complex problem if the serious drawbacks of table layouts are to be avoided SignatureSpartanicus Spartanicus schrieb: >> Seriously, I cannot fathum how the inventors of CSS (at least the >> position part; the formating parts of CSS are not a prolbem at all and [quoted text clipped - 4 lines] > Although not implemented in a straight forward manner, again this is > possible using CSS2 methods, but again not supported by IE. Would you care to elaborate on that (or maybe just post a link?) Thanks a lot >>> Seriously, I cannot fathum how the inventors of CSS (at least the >>> position part; the formating parts of CSS are not a prolbem at all and [quoted text clipped - 6 lines] > >Would you care to elaborate on that (or maybe just post a link?) http://www.w3.org/TR/CSS21/visuren.html#display-prop http://homepage.ntlworld.ie/spartanicus/css-table.htm should work in any modern browser but IE SignatureSpartanicus >> Actually this is a major short coming to CSS, as I jsut keep seeing >> more and more cases of it jsut makes life difficult and painful for [quoted text clipped - 3 lines] > Equal "column" height is possible with CSS2 methods, but IE doesn't > support that part of CSS2. Well, yes and no. Correct me if I'm wrong, but when IE6 first came out, wasn't CSS2 not yet finalized? > Multi column layouts (text ends at the bottom of one column and > continues at the top of the adjacent right column) make no sense at > all on the web, I wasn't refering to that, but actually sidbar type setups, which are incredibly easy with html <tables>. But saying it is no suitable, is more of your opinion than stone carved fact I fret. NOthing wrong with that, but it would be nice if you said so instead of pushing as what everyone should be doing. Actually have a two column news-paper style layout is rather well suited for, well, news sites, as many seem to do just. >> Seriously, I cannot fathum how the inventors of CSS (at least the >> position part; the formating parts of CSS are not a prolbem at all [quoted text clipped - 10 lines] > tables: reflows, or nothing being rendered until all content has been > downloaded. How about this one, going the other way: Take this code: ######################################################################### <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <style type="text/css"> body { margin: 4px; } #outter { background: #66AAFF; color: #007700; height: 300px; border: #000000 2px solid; padding: 5px; } #outter .inner { background: #BBBBBB; height: 100%; width: 90%; border: #DD0000 2px solid; padding: 50px 0px 50px 0px; } </style> <title>um...</title> </head> <body> <div id="outter" align="center"> <div class="inner">111</div> </div> </body> </html> ######################################################################### Notice how the bottom of the outer div gets pushed down properly in IE6, but in Moz 1.7 and FF 1.5.0.6, NS 7, and Opera 8, the inner div's bottom simply gets pushed out of the bounds of the outter div. If no pading and borders are used on inner, then it's uniform in all those browsers. Granted, according to O'Reilly CSS pocket ref, height "defines the height of an element's content area, outside of which padding, borders, and margins are added." But it doesn't say ANYTHING about pushing OUTSIDE it's container (which seems rather undesirable for a flow/non-positionsed layout. In fact, it only makes sense for absolute positioning, where the container no longer matters in that respect.) So you tell me, is this a design flaw of CSS (and the fact it doesn't seem to give you very much control over weather content should "push" it's container's height so that everything "fits" ? Other than overflow, which DOES NOT solve this problem, but instead only allows to either hide it and make the container scrollable.) >> and proper height control (notice how 100% heights on >> DIVs inside DIVs sometimes push out of the confines of the outer div, [quoted text clipped - 9 lines] > Moz, FF and Opera more than likely render such according to spec, your > understanding is flawed. Actually, with strict on, I've witnessed many anomalies on the Moz/FF/NS side of things, just as much as I've seen on the IE side. Browser bias is not something you want to get into here. >> I'm sorry, but it really seems CSS has not yet come of age. don't >> get me wrong, CSS is a triuth in many areas, but in the area of [quoted text clipped - 9 lines] > the web are a complex problem if the serious drawbacks of table > layouts are to be avoided Yes, but if CSS actually made it even half as easy to do many layouts you could easily hack out with <table> based layout, as frowned upon as they may be, you wouldn't have half as many posts concerning how to do such layouts in CSS only. I just wish the CSS advocates here would simply admit CSS has not yet arrived to the point where it completely replaces "old fashioned" layouts, if you will. I too wish CSS would come of age, and I hope CSS3 resolves many the glaring issues. But I fear it will take some time before it will be safe to broadly embrace the new spec when it comes out, for fear of leaving previous gen browsers in the cold, just like when CSS2 first arived. You can not expect the shift to CSS3 to change over night. This is why I find CSS2, which it's infinate potential to really be a failure in that it should of come out a lot stronger and compatibility among browsers should of been ensured. >> Multi column layouts (text ends at the bottom of one column and >> continues at the top of the adjacent right column) make no sense at [quoted text clipped - 8 lines] > Actually have a two column news-paper style layout is rather well suited > for, well, news sites, as many seem to do just. Spartanicus is right. A 2-column layout which flows from the bottom of the first column to the top of the second column only makes sense when you have a fixed column height that is entirely visible. You can never be sure of having that in any browser window. SignatureChris F.A. Johnson <http://cfaj.freeshell.org> =================================================================== Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) >> Equal "column" height is possible with CSS2 methods, but IE doesn't >> support that part of CSS2. > >Well, yes and no. Correct me if I'm wrong, but when IE6 first came out, >wasn't CSS2 not yet finalized? CSS 2.0 achieved Rec status in 1998, IE6 stems from 2000 IIRC. >> Multi column layouts (text ends at the bottom of one column and >> continues at the top of the adjacent right column) make no sense at [quoted text clipped - 8 lines] >Actually have a two column news-paper style layout is rather well suited >for, well, news sites, as many seem to do just. Such layouts make no sense at all on an output media of unknown size, they only work on an output medium with a given and fixed size. >Take this code: Posting code is not appreciated, post a URL if you want to demonstrate something. >> Moz, FF and Opera more than likely render such according to spec, your >> understanding is flawed. > >Actually, with strict on, I've witnessed many anomalies on the Moz/FF/NS >side of things, just as much as I've seen on the IE side. Browser bias >is not something you want to get into here. It is common for people to take IE's rendering as correct, not least because it often does what people expect. Where Moz and IE differ, IE's rendering is almost certainly wrong. >> Sadly CSS2 does not offer a good method for creating layouts suitable >> for the web, this is indeed a shortcoming. But layouts that work on [quoted text clipped - 5 lines] >they may be, you wouldn't have half as many posts concerning how to do >such layouts in CSS only. Again: CSS2 has made that possible, although many are not aware of this facility. The problem with that solution is that it has all the drawbacks of HTML table layouts minus the insignificant semantic issue. >I just wish the CSS advocates here would simply admit CSS has not yet >arrived to the point where it completely replaces "old fashioned" >layouts, if you will. The problem is more complex than you realize, certain aspects that make tables such a popular layout tool have rather nasty consequences. The method present in CSS2 that can be used to replace HTML tables used for layout only addresses the semantic issue which is by far the least significant of the problems with HTML tables used for layout purposes. It may well turn out to be impossible to retain the aspects that make tables such a popular method to create layouts whilst avoiding the nasty consequences. SignatureSpartanicus >>> Equal "column" height is possible with CSS2 methods, but IE doesn't >>> support that part of CSS2. [quoted text clipped - 3 lines] > > CSS 2.0 achieved Rec status in 1998, IE6 stems from 2000 IIRC. I stand corrected, though I would put forth that it wasn't really feasable for widespread use (in terms of anything beyond forrmatting - ie layouts) for a sometime well after 2000, as the majority of the web in 2000 seem to be using the "old fashioned" <table> wrapper approach, and somewhat popularity of NN 4.x didn't exactly help in the area of CS layouts at the time, imho. >>> Multi column layouts (text ends at the bottom of one column and >>> continues at the top of the adjacent right column) make no sense at [quoted text clipped - 11 lines] > Such layouts make no sense at all on an output media of unknown size, > they only work on an output medium with a given and fixed size. Ok I think I misunderstood what you wrote the first time around. I once agian stand corrected. >> Take this code: > > Posting code is not appreciated, post a URL if you want to demonstrate > something. With all do respect, it is infinately more useful to post code i na post rather than to simply provide a link, as someone searching in the future is likely to end up wit ha broken link, where as my code will still be here. I cannot help it if you are unable to take 10-20 seconds to copy, paste, and save, and open an html file. >>> Moz, FF and Opera more than likely render such according to spec, >>> your understanding is flawed. [quoted text clipped - 6 lines] > because it often does what people expect. Where Moz and IE differ, > IE's rendering is almost certainly wrong. This is not always true. It depends a lot on which mode is being engaged in whichever browser. [snippy do da] >> I just wish the CSS advocates here would simply admit CSS has not yet >> arrived to the point where it completely replaces "old fashioned" [quoted text clipped - 10 lines] > tables such a popular method to create layouts whilst avoiding the > nasty consequences. I'm sorry, but I've all too fequently how bad <table>s are for layout purposesare, but hardly ever do I see a real ellaboration on that. Tell me, what is truely so bad abotu using <table>s for layout? The web got along quite well for a long time using them. I used them almost exclusively for a good 5 years since around 1998, and it was never the problem DIVs are for making such a simple layout consisting of a sidebar and main column, both the same height. Or is there some mysterious solution to that (without using a hack such as using repeating backgound solid color images to achieve what <table width="96%"><tr><td width="160" bgcolor="#BBBBBB">side</td><td bgcolor="#DDDDDD">main column</td></tr></table> easily does. And yes, CSS can be blened into that as well, such as takign the inline width and colors out of the <td>s and into style cheets. This worked well for such a while, and is routinely condemded but almost never said why, why at the same time touting CSS, as powerful as it may be, can't even do such a simple task as what I outlined in one line of code. >> It is common for people to take IE's rendering as correct, not least >> because it often does what people expect. Where Moz and IE differ, >> IE's rendering is almost certainly wrong. > >This is not always true. It depends a lot on which mode is being engaged >in whichever browser. All bets are off if you are referring to quirks mode, but it most certainly is true for standards compliant mode which I assumed you referred to when you wrote: >>> Actually, with strict on, I've witnessed many anomalies on the >>> Moz/FF/NS side of things, just as much as I've seen on the IE side. We will happily prove you wrong, just post examples. (note that I for one only review URLs). >> It may well turn out to be impossible to retain the aspects that make >> tables such a popular method to create layouts whilst avoiding the [quoted text clipped - 3 lines] >purposesare, but hardly ever do I see a real ellaboration on that. Tell >me, what is truely so bad abotu using <table>s for layout? 1) Reflows (a) when embedded content loads in table-layout:auto mode. 2) Do not contain their content properly (b) in table-layout:fixed mode. 3) Grid remains rigid regardless of the viewport width (c). 4) The content order cannot be changed independently from the position on screen. (a) Reflows: screen content jumping around like a mexican jumping bean because the rendering of the layout grid depends on it's content. (b) Containing contents, there is no acceptable overflow behaviour: 1) In document scroll bars (usability nightmare). 2) Part of the content is clipped (content partially disappearing is unacceptable). 3) Part of the content overflows into the adjoining space (thereby often obscuring other content). (c) The CSS2 "handheld" media property was ill conceived, it made unwarranted assumptions about the viewport width on mobile devices, and fails to cater for a-typical viewport widths on non mobile devices. Sadly most of the properties that make table layouts so popular amongst authors are directly responsible for the problems they cause for clients. The user's interests ought to trump the author's desire for simplicity. SignatureSpartanicus [...] >>> It may well turn out to be impossible to retain the aspects that >>> make tables such a popular method to create layouts whilst avoiding [quoted text clipped - 5 lines] > > 1) Reflows (a) when embedded content loads in table-layout:auto mode. That a characteristic of how rendering in general (of the browser) takes place, not something specific to <table> layouts. > 2) Do not contain their content properly (b) in table-layout:fixed Um you got it backwards, it's <div> s that can't seem to stay with it's borders in many cases when you expect it should. <td> s will not normally allow content to spill out of their confines. > mode. 3) Grid remains rigid regardless of the viewport width (c). This is not disadvantage of <table>, as all you have to do is scroll, and this can sometimes be desired, depending on your target audience. Actually one could argue the it SHOULD ork that way. If you have a have a side column and flexible width main column, why woul you want anything other than the side column remaining on the, well, SIDE? I would arue thats the whole point of using a <table> for this sort of laytout in the first place. Many people just don't want the behavior of <div> s sliding under seach other. > 4) The content order cannot be changed independently from the position > on screen. > > (a) Reflows: screen content jumping around like a mexican jumping bean > because the rendering of the layout grid depends on it's content. Again, this is NOT specific to a <table>, but <div> s can do the same with the width is unspecified and you have a whole lot of content coming in. Thats a charasteristic of the rendering engine. > (b) Containing contents, there is no acceptable overflow behaviour: How so? Is this not how the auth sets it (<td style="overflow: ..."> and as I said, the default behavior may be desired, which keeps the contents from spilling out of it's confines and pushes the sides of the containing cel las need to fit the content, something horribly difficult with CSS/div layouts. > 1) In document scroll bars (usability nightmare). What on earch are you talking about? How does this have anything specifically to do with tables? Default behavior of tables is no scroll bars i nthe cells. If you had been using HTML for sometiem you would this. One can also change the default behavoir of a cell using an overflow style. > 2) Part of the content is clipped (content partially disappearing is > unacceptable). In <tables> s? This is just plain false. With divs, perhaps, I've seen that happen with overflow: hide, but this applies to must any block elements. Going be a table's default behavior, I can't think of any time such clipping as you describe occurs at all. > 3) Part of the content overflows into the adjoining space (thereby > often obscuring other content). Not in <table> s. THAT is precisely what can happen with pure CSS/div layouts (albiet, the design of the page itself might be flawed if this is happening. It has absolutely nothing to do with <table> layouts. That is purely a stylesheet / CSS layout issue. > (c) The CSS2 "handheld" media property was ill conceived, it made > unwarranted assumptions about the viewport width on mobile devices, True, which is why it seem to hardly be used ever. > and fails to cater for a-typical viewport widths on non mobile > devices. And why should it? Thats more the job of the page author than anyone else to ensure the pages they write appear as expected (or at least acceptably) on the target medias. > Sadly most of the properties that make table layouts so popular > amongst authors are directly responsible for the problems they cause > for clients. What problems are that? I've never seen <table> based layouts fail in the same way div/CSS layouts do when care isn't taken. > The user's interests ought to trump the author's desire > for simplicity. True, but you still need to create a design. It depends on who you are developing for, their needs. The target audience. There are many cases in my work where the customer wanted the simple <table> layout. >>> I'm sorry, but I've all too fequently how bad <table>s are for layout >>> purposesare, but hardly ever do I see a real ellaboration on that. [quoted text clipped - 4 lines] >That a characteristic of how rendering in general (of the browser) takes >place, not something specific to <table> layouts. Content in the flow is rendered according to an inline or block mechanism, content below a line or block box does not affect content above it. Not so with a table layout, there content below a row can and often will cause the entire table to reflow. >> 2) Do not contain their content properly (b) in table-layout:fixed > >Um you got it backwards, it's <div> s that can't seem to stay with it's >borders in many cases when you expect it should. <td> s will not >normally allow content to spill out of their confines. http://www.w3.org/TR/CSS21/tables.html#width-layout I presented two cases since different arguments apply to each mode. >> mode. 3) Grid remains rigid regardless of the viewport width (c). > >This is not disadvantage of <table>, as all you have to do is scroll, >and this can sometimes be desired, depending on your target audience. >Actually one could argue the it SHOULD ork that way. I referred to the fact that working within the possibilities of CSS2, table cells stay in the same grid pattern regardless of viewport width (with the previously noted exception). This is a serious problem when the size of the output medium varies greatly as it does with the range of web clients in use today. >> 4) The content order cannot be changed independently from the position >> on screen. [quoted text clipped - 12 lines] >from spilling out of it's confines and pushes the sides of the >containing cel las need to fit the content, Which is a major problem, one that you appear to be oblivious of, or are refusing to see. >something horribly difficult with CSS/div layouts. Again this is perfectly possible with CSS2, just not supported by IE. >> 1) In document scroll bars (usability nightmare). > >What on earch are you talking about? How does this have anything >specifically to do with tables? Tables can be rendered in two modes. Again: I presented two cases since different arguments apply to both. I suggest that you read what I wrote more attentively, currently most seems to pass you by. >> (c) The CSS2 "handheld" media property was ill conceived, it made >> unwarranted assumptions about the viewport width on mobile devices, [quoted text clipped - 5 lines] > >And why should it? Because the range of viewport widths with for example desktop situations is extensive. >> Sadly most of the properties that make table layouts so popular >> amongst authors are directly responsible for the problems they cause >> for clients. > >What problems are that? That is what I've been explaining, I can't help if you ignore what I write. >I've never seen <table> based layouts fail in >the same way div/CSS layouts do when care isn't taken. I can't quite parse that, when care isn't taken with what, table layouts or "CSS layouts"? Table layouts have specific failures. A CSS layout coded by a skilled author is not particularly prone to failure, there are however a lot of poorly authored "CSS layouts". >> The user's interests ought to trump the author's desire >> for simplicity. > >True, but you still need to create a design. It depends on who you are >developing for, their needs. The target audience. There are many cases >in my work where the customer wanted the simple <table> layout. Creating problems for the user is not in the interest of anyone. SignatureSpartanicus >>>> Equal "column" height is possible with CSS2 methods, but IE doesn't >>>> support that part of CSS2. [quoted text clipped - 10 lines] > and somewhat popularity of NN 4.x didn't exactly help in the area of CS > layouts at the time, imho. IE6 has been almost completely static in terms of features and standards compliance since 2000 when it was released. Given the thousands of repairs for security fixes I would have thought they would slip in a few useful fixes for rendering. Hah! Signaturejmm (hyphen) list (at) sohnen-moe (dot) com (Remove .AXSPAMGN for email) > > I'm sorry, but it really seems CSS has not yet come of age. don't > > get me wrong, CSS is a triuth in many areas, but in the area of [quoted text clipped - 8 lines] > for the web, this is indeed a shortcoming. But layouts that work on > the web are a complex problem if the serious drawbacks of table What I am really curious about is why HTML/CSS/JavaScript (and even XML [1]) weren't created as components one would download and install on their operating system, much like you would Perl, PHP, or such. In this scenario, everyone, regardless of OS or user agent (or browser) would all have the same components making up the core parsing and rendering parts, while the UA/browser sits on top of that, doing any ad/popup blocking, blocking of components, or anything else a browser adds to the base web experience. To be honest, this would of infinitely been the best solution that would of easily prevent years upon years of browser wars, mounds of extra code (think JavaScript compatibility between NN4.x (and equivalent Mozilla) and IE4.x and pre 4.x of each. Anyone whose been on the HTML scene since the late 90's would know what I mean there.) Why the governing bodies who write the spces for HTML/XHTML, XML, CSS, JavaScript, in their seemingly boundless wisdom, could not of seen this as a far better solution, is a mystery to me. They could of made this happen. They could of developed the parsing and rendering engine cores that would be a dependency of any UA/browser. These engines would then be updated regularly, just like things like Perl, PHP, Python, and even entire operating systems are. HTML, CSS, etc, updates could become part of normal operating system updates in fact. Newer version of UAs and browsers could call on the user having a minimal version of HTML, CSS, etc installed (or perhaps come packaged with a version, or even better yet, check for updates regularly!) Was there any real reason that this would of been a bad idea? I mean, look at my scenario. It still allows for everyone using whatever UA they wish, as is presently the case, with all the features, the only difference being uniform rendering across the board, like, IMHO, it should of been from the very start, instead of the mess we ended up with. Thats my $0.02 * * * * * * * * * * * * * * * * * * [1] Granted, XML, XSLT, Schema, etc, all have command line and GUI tools for parsing and checking code (like for well-formed-ness), and on that note, there's even nsgml for checking HTML, but what I mean by having HTML, CSS, and JavaScript as components is having the body that governs them, instead of just writing the specs, they should of released components in the force of parsers and maybe even rendering cores that any UA would use. Such a system would of been truly harmonious imho. * * * * * * * * * * * * * * * * * * SignatureStan * If emailing a reply, please use stan^blz/hmrprint/com, * after properly converting it into a legal address :-) >What I am really curious about is why HTML/CSS/JavaScript (and even XML >[1]) weren't created as components one would download and install on [quoted text clipped - 5 lines] >ad/popup blocking, blocking of components, or anything else a browser >adds to the base web experience. There are a host of reasons why this is not the case. Historically browsers have allowed a very limited interface between the host application and plugins. HTML, CSS, DOM, JS etc. require extensive interaction to provide web browser type functionality. Using a plugin type structure to tie such technologies provided in separate modules together with some sort of glorified skin on top of it, it would be very difficult to create the type of web browser functionality that we are used to today. Not to mention that it would be very inefficient. Even when realised it would not put an end to compatibility issues, version differences would see to that. You also seem to presume that browser wars are a bad thing by definition. This is only partially the case, a benefit of having competing renderers is for example a drive for the title of the fastest, the least buggy, the most standard compliant, the one with the most rendering features etc. etc. Asking why HTML, CSS, JS etc. aren't centrally developed and made available is similar to asking "Why can't everyone use the same browser?". SignatureSpartanicus >> What I am really curious about is why HTML/CSS/JavaScript (and even >> XML [1]) weren't created as components one would download and [quoted text clipped - 17 lines] > functionality that we are used to today. Not to mention that it would > be very inefficient. I fail to see how you can readily say it is inefficient when such a thing doesn't even exist. You have no idea how it would be implemented exactly, but if it were as I attempted to draw out, it would provide the necessary functionality and optimizations, as well as enhanced debugging. Actually I think you're echoing the overall problem in the lack of understanding of the fundamental concept for logical separation. You're too worries in HOW something is or would be implemented, rather then WHAT it might have done had things gone that way. The same way of thinking is precisely what may have lead web browsers down the path they went. > Even when realised it would not put an end to compatibility issues, > version differences would see to that. Errm, no I think you missed the whole point. The core would be a constant that would be updated from time to time, like anything else in the operating system. Perhaps only as often as the likes of Java or Perl are updated. The point is the core would be uniform with maybe tweaks and fixes and every so often a new feature or something. Versions of the user agent could be virtually independent of the "core". Also, can you imagine a system with multiple cores (or perhaps, a single core that allows for backwards compatibility; ie: a page author specifies the page uses HTML 3.2 Strict in the DOCTYPE declaration, or even older, and hiving a modern browser fully adhere to that? And at the same time allowing the /user/ of the User Agent to override that if that way. The possibilities are virtually boundless. > You also seem to presume that browser wars are a bad thing by > definition. This is only partially the case, a benefit of having > competing renderers is for example a drive for the title of the > fastest, the least buggy, the most standard compliant, the one with > the most rendering features etc. etc. But that's not exactly the case. I don't think anyone can doubt the IE has one of the largest, if not thee largest, percentage of usage, despite it's bugs. Yes, FF, Opera, all have a growing following, but all in all the "browser wars" over the years, imho, have caused a lot of harm in the form of a lot of extra code for web developers to write to ensure things always work right. > Asking why HTML, CSS, JS etc. aren't centrally developed and made > available is similar to asking "Why can't everyone use the same > browser?". That is just absurd. In my scenario, no one HAS to use the same browser, as the parsing and rendering have been taken out of the equation. --- Ok how about thinking about it like this. the world-wide-web (WWW) is meant for wide spread viewability, right? Browsers (User Agents) are the gateway that allow the "web" to be viewed. Ok. Now, what is it all User Agents (read: graphical browsers) share in common? They parse HTML, and they then they render it. Ok, now, as any good OOP programmer might realize, would it not be wiser to take the common elements from application-wide scope and instead implement them in a system-wide level that applications are free to use? As I have stated many times, this exact approach is makes many other languages, scripting engines, database engines, and various other types of servers what they are: stand alone packages, many of which allows other applications to either use or interact with them in some manner or another, that are each /maintained/ by a central body. SignatureStan > Show do > I get text to center vertically within a div tag? Here is a page where someone has gone to the trouble to explain methods: <http://www.student.oulu.fi/~laurirai/www/css/middle/> SignatureGus |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.