Unjustified Caption Text
Published 20 years, 2 weeks past
I just stumbled across a browser bug this evening that I thought you all might like to know about. So we all know that IE6/Win supports text-align: justify, right? Wrong. Sorry, but it’s the truth: IE6 does not fully support text-align: justify. True, it mostly supports that declaration, but if you apply said declaration to a caption element, guess what? You get centered, non-justified text instead. It’s very much as though, in the case of caption elements, IE6 replaces justify with center.
I just thought I’d pass this along in case it might help anyone else avoid some furious head-scratching. And, I’m sorry to say, I don’t know of a workaround. If anyone finds one, please leave a comment to that effect.
This is a perfect illustration of how difficult it is to do comprehensive CSS testing. Every CSS support chart I’ve ever seen has marked down IE6 as supporting justified text; I mean, why wouldn’t they? It clearly did so… for the specific test cases used to create that support chart. The odds of a test page including a caption element are pretty vanishingly small, unless of course we’re talking about a test page that includes every single XHTML element in existence. And to test every element known for every property-value combination… well, I’ve talked about that before. No need to trample the same ground even flatter.
Comments (12)
I’ve done that head-scratching a while ago for a problem with padding Setting it to
display:blockexplicitly did solve my problem. Hmm, according to the html 4.01 specs it is an inline element. Or do I read that wrong ?.
I think the problem has its root that they use the html align attribute to align text within a caption rather than the caption box. So align=”left” would not put the caption box left to the table as required by html 4.01 but would make the text left aligned.
The caption element is treated differently in Gecko browsers and Safari too. I don’t remember which is which right now, but if you add a top margin to the table, one of the two will push the caption away (provided the caption is displayed at the top, obviously), and the other will not, which is what I would expect.
Maybe that has something to do with Philippe’s comment about caption being an inline element. Guess I’ll have to look into that ;)
http://www.w3.org/TR/CSS2/tables.html#x2
caption is display: table-caption
The specification is not fully clear if table-caption is treated as block-level, but http://www.w3.org/TR/CSS21/tables.html#q6 says:
“Captions above or below a ‘table’ element are formatted very much as if they were a block element before or after the table, except that (1) they inherit inheritable properties from the table, and (2) they are not considered to be a block box for the purposes of any ‘run-in’ element that may precede the table.”
http://www.w3.org/TR/CSS2/text.html#propdef-text-align
“Conforming user agents may interpret the value ‘justify’ as ‘left’ or ‘right’, depending on whether the element’s default writing direction is left-to-right or right-to-left, respectively.”
I read somewhere that captions only take 3 basic formatting styles, which might be border, font and padding. Alas I can’t for the life of me find the relevant page again! If I do, I will post the link here.
I just ran across a similar situation. IE has a bug in that form text inputs in a fieldset seem to inherit the parent container elements margin. It’s one of those things that until you happen to set up the exact “wrong” situation, you’ll never see it.
I wonder if it would be possible to set up a system where you could dynamically select select a series of HTML elements to be included on a page and apply CSS styles to those elements at the same time, then go back and add more elements as children of the first ones, etc. Then you could possibly build a page to test the exact layout you wanted.
Anyway, this is another one to file away for future hair pulling sessions when things don’t work.
Philippe: you’re correct that
captionis defined to be an inline element in the HTML (and XHTML) DTD. However, as ‘Anonymous’ pointed out, any element declared to bedisplay: table-captionis treated as a block element. I interpret that (and note it’s an interpretation) to mean that atable-captionelement should generate a block box, and take on the aspects of a block box, the same as if you declaredcaption {display: block;}.Al: !
Roger: Yes, I noticed that too but wasn’t able to pin it down well enough to report. Once I do, I’ll post about it. (Along with another obscure IE/Win table bug I found.)
Chris: I’d like to see that. I know there are a very limited number of properties that apply to
colelements, but I don’t recall seeing anything aboutcaptionelements.Eric: you say in your post,
re [8]: Eric, yes I agree with your interpretation about the display value for
caption, and how that works. The problem I see is that IE Win doesn’t understand that value. I’m not sure which algorythms are used by Microsoft (according to the css21 specs they can use different ones fortable).It then ignores the value ‘justify’. Weird is that it aligns the caption as centered. I thought it’s default value was ‘left’, could be wrong, though. I’ve the habit of always including the text-align property in my stylesheets, to overcome weird inheritance problems.
The inconsistency with <caption /> is the most absurd simple tag issue since Opera insisted on putting borders on <fieldset /> despite what your stylesheets might have to say on the matter.
Seth (11): That’s not a “feature” but a bug.
Just add to your CSS:
fieldset {border:0px solid}