Vertical alignment of text within a DIV
~john
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>
Els
> 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
> 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>
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.
--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/
Now playing: Camel - Lady Fantasy (Bonus track)
~john
thanks
Wayne Poe
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.)
Gus Richter
> 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/>
--
Gus
Spartanicus
>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,
>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.)
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
--
Spartanicus
Christian Kirsch
> "Wayne Poe" <lo...@h4h.com> wrote:
>
>> 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.
>
Would you care to elaborate on that (or maybe just post a link?)
Thanks a lot
Spartanicus
>>> 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.
>>
>
>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
--
Spartanicus
Wayne Poe
> "Wayne Poe" <lo...@h4h.com> wrote:
>
>> 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.
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
>> 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.
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,
>> 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.
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
>> 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.)
>
> 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
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.
Chris F.A. Johnson
> Spartanicus wrote:
>> "Wayne Poe" <lo...@h4h.com> wrote:
>
>> 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.
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.
--
Chris F.A. Johnson <http://cfaj.freeshell.org>
===================================================================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Stan R.
> > 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.)
>
> 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
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.
* * * * * * * * * * * * * * * * * *
--
Stan
* If emailing a reply, please use stan^blz/hmrprint/com,
* after properly converting it into a legal address :-)
Spartanicus
>> 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
>> 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.
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
>> 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.
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.
--
Spartanicus
Spartanicus
>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.
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?".
--
Spartanicus
Wayne Poe
> "Wayne Poe" <lo...@h4h.com> wrote:
>
>>> 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.
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
>>> 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.
>
> 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.
>>
>> 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.
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"
>> 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.
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.
Stan R.
> "Stan R." <st...@invalid.blz/hmrprint/com.com> wrote:
>
>> 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.
>
> 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.
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.
--
Stan
Spartanicus
>> 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
>> 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?
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.
--
Spartanicus
Wayne Poe
> "Wayne Poe" <lo...@h4h.com> wrote:
[...]
>>> 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.
>>
>> 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?
>
> 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.
Spartanicus
>>> 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?
>>
>> 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.
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.
>>
>> (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,
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,
>
>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?
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.
--
Spartanicus
Jim Moe
>>
>>>> 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.
>
> 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.
>
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!
--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)