W3C CSS validator questions

[ktinkel]

Our home page (http://www.desktoppublishingforum.com/) here validates as valid XHTML Strict and its style sheet also validates. However, I get several warnings that I am not sure I understand:



Line : 5 (Level : 1)
You have no color with your background-color : body


Line : 5 (Level : 2)
Redefinition of background-color : body


Line : 41 (Level : 2)
You have some absolute and relative lengths in padding. This is not a robust style sheet.


Line : 56 (Level : 2)
You have some absolute and relative lengths in padding. This is not a robust style sheet.
What should I do about the first two? Is it that I am not supposed to set background-color in body in the first place? What color would I set there? Inherit? From where? Redefine?

As for the other two, I have never heard it was not robust to use different sorts of values (i.e., em and %) before. How does that weaken the stylesheet?

[annc]

Dunno about the second two, but can see the problem with the first two:

You have defined the background-color twice: transparent, and white. I'd remove the transparent defintion if you want it to be white.

Having done this, you can use background-color: inherit elsewhere to avoid nasty surprises in coloured boxes etc.

The other warning come back to the one I was complaining about recently, that since they introduced the warnings, they seem to require a text colour and a background colour for everything. If you add:

color: #000;

Then the second warning will go away.

[ktinkel]

You have defined the background-color twice: transparent, and white. I'd remove the transparent defintion if you want it to be white.

… they seem to require a text colour and a background colour for everything. If you add: color: #000; [to body] Then the second warning will go away.Ahhh. I have been using background: transparent for body since I first started using stylesheets, based on something I read. Took it out and added color: #000000; and now both warnings have stopped.

As for the use of different value types, maybe someone else will advise on that.

Whew. Thanks.

[annc]

As for the use of different value types, maybe someone else will advise on that.Yes, I'd be interested to hear about that, too.

[George]

Our home page (http://www.desktoppublishingforum.com/) here validates as valid XHTML Strict and its style sheet also validates. However, I get several warnings that I am not sure I understand:




Line : 5 (Level : 1)

You have no color with your background-color : body




Line : 5 (Level : 2)

Redefinition of background-color : body




Line : 41 (Level : 2)

You have some absolute and relative lengths in padding. This is not a robust style sheet.




Line : 56 (Level : 2)

You have some absolute and relative lengths in padding. This is not a robust style sheet.
What should I do about the first two? Is it that I am not supposed to set background-color in body in the first place? What color would I set there? Inherit? From where? Redefine?

As for the other two, I have never heard it was not robust to use different sorts of values (i.e., em and %) before. How does that weaken the stylesheet?



I recently encountered the exact same assessments and asked myself these questions. Finally, I decided it just doesn't matter. And, so far as I can tell, it really doesn't. There are rules and there is reality.



Regards,



George

[ktinkel]

I recently encountered the exact same assessments and asked myself these questions. Finally, I decided it just doesn't matter. And, so far as I can tell, it really doesn't. There are rules and there is reality.I guess. It isn’t that I aspire to perfection or anything like it (far be it!), but I would like to understand the messages!

[Ian Petersen]

You have no color with your background-colorIt's generally regarded as good form to define both foreground and background colours so as to avoid any mishaps if the stylesheet gets cascaded with another stylesheet that redefines one or the other colours making the text invisible. You have some absolute and relative lengths in padding.Bad things can happen if you mix pixels and percentages on the same object in the same direction. They won't scale uniformly in most browsers.

[iamback]

I recently encountered the exact same assessments and asked myself these questions. Finally, I decided it just doesn't matter. And, so far as I can tell, it really doesn't. There are rules and there is reality.These are warnings - if they were about rules, they would be reported as errors. The warnings usually indicate potential problems with scaling (mixing units can cause problems there, or cause totally different layout in different browsers) or with accessibility (not defining both foreground and background color can lead to illegible text). Both of those problems are very much part of reality - but of course you you are free to ignore that bit of reality. ;)

For a forum about desktop publishing and web development it would be wise not to ignore such warnings, which is why we have this thread!

[George]

These are warnings - if they were about rules, they would be reported as errors. The warnings usually indicate potential problems with scaling (mixing units can cause problems there, or cause totally different layout in different browsers) or with accessibility (not defining both foreground and background color can lead to illegible text). Both of those problems are very much part of reality - but of course you you are free to ignore that bit of reality. ;)

For a forum about desktop publishing and web development it would be wise not to ignore such warnings, which is why we have this thread!

I've gotten away quite nicely with ignoring this part of what is called reality, (the rules on the warnings, that is) and expressing that point of view is why I participated in the thread. Wisdom is a rather relative concept, I guess.

Regards,

George

[ktinkel]

The warnings usually indicate potential problems with scaling (mixing units can cause problems there, or cause totally different layout in different browsers) …I wish I could understand that. I often use ems for vertical spacing (distance from top of the window or below the logo, etc. to the text) and % for major horizontal units (outer margins, element widths, gutters between elements).

I have been scratching my head about how that could cause a scaling problem, and while anything may look different from one browser to another, I haven’t seen anything that could be attributed to that particular approach.

Perhaps I am too inexperienced! Once I have seen it all, then …

[ktinkel]

Bad things can happen if you mix pixels and percentages on the same object in the same direction. They won't scale uniformly in most browsers.I would expect not. But I don’t do that.

If I use pixels, it is for text indents (so that regardless of type size, the text will be indented to the same point). Otherwise, horizontal measurements are in percents, vertical in ems, and it is that that sparked the warnings.

Wonder if the validator just looks to see what units are included in a statement — so if I used padding-left: [n]% and padding-top: [n]em that the validator would ignore it. Guess I should text that next time.

[iamback]

The warnings usually indicate potential problems with scaling (mixing units can cause problems there, or cause totally different layout in different browsers)I wish I could understand that. I often use ems for vertical spacing (distance from top of the window or below the logo, etc. to the text) and % for major horizontal units (outer margins, element widths, gutters between elements).Note that I was very careful how to formulate that - see re-quote with added emphasis. But if there's a warning, it's best to investigate if there really could be a problem - maybe not, but a validator cannot always determine that.

One thing confuses me, too: the validator refers to particular lines, and only two of them. But the validator makes a list of valid CSS statements which doesn't quite match the actual file (it would leave out any actually invalid stuff) - so do the line numbers refer to the resulting valid statements or the original file? I couldn't quite match it up - the more so since you seem to have (had) more than two such statements "mixing" percentages with ems (and zeros - which the validator is possibly interpreting as pixels, but shouldn't). So which statements exactly it's grumbling about is not clear to me.

That said, you also have a few where you use only three, not four sizes - valid but these always confuse me... (I like to be explicit and avoid confusing myself, so I either use separate statements, or four numbers, always reminding myself to start at the top and go around clockwise.)

I have been scratching my head about how that could cause a scaling problem, and while anything may look different from one browser to another, I haven’t seen anything that could be attributed to that particular approach.If you always do as you say, using % for horizontal units and ems for vertical ones - probably not. The validator is only a dumb program though, and it's only warning you. So double-check, and draw your own conclusions, is all. But I certainly don't agree with George that you can just ignore the warnings: all warnings are potential bugs (maybe only visible with another browser, or another font size, etc.), so they are worth double-checking. Effectively the validator is telling you: "I'm not sure there's a problem here, you'd better check."

Perhaps I am too inexperienced! Once I have seen it all, then …Your approach of using % for horizontal units and ems for vertical ones is sound and usually does not lead to scaling problems. Don't forget borders (generally sized in pixels!) though. If you're using (horizontal) percentage widths and border widths expressed in pixels, you are mixing absolute and relative lengths.

But browsers differ in how they translate the percentages to numbers of pixels (possible rounding errors) and not all browsers implement the standard perfectly (notably IE's incorrect interpretation (http://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug) of the block model (http://www.w3.org/TR/REC-CSS2/box.html)). This page (http://www.positioniseverything.net/explorer/percentages.html) page is also instructive (or confusing, since the page doesn't display well in Mozilla either... ;)).

But whatever, the stylesheet currently is actually not robust:
1) There's still the long-reported problem (see "using this forum" section) of the main heading overlapping the middle column so the heading in that column can't be read (screenshot 1, again, with standard font size and window width at 800px).
2) If I increase the font size by only one notch in Mozilla 1.7 the three-column layout goes all wacky (screenshot 2); also note what happens to the "Contact us" menu item here: it's barely legible...
It's possible that even a perfectly valid stylesheet without any warnings is not "robust".

[dthomsen8]

I would expect not. But I don’t do that.

If I use pixels, it is for text indents (so that regardless of type size, the text will be indented to the same point). Otherwise, horizontal measurements are in percents, vertical in ems, and it is that that sparked the warnings.

Wonder if the validator just looks to see what units are included in a statement — so if I used padding-left: [n]% and padding-top: [n]em that the validator would ignore it. Guess I should text that next time.

Let us know if you make a test somewhere. I do pay attention to warnings from the validator, because I can learn something from them for the future, even if I won't change my existing HTML.

[ktinkel]

Your approach of using % for horizontal units and ems for vertical ones is sound and usually does not lead to scaling problems. Don't forget borders (generally sized in pixels!) though. If you're using (horizontal) percentage widths and border widths expressed in pixels, you are mixing absolute and relative lengths.Yep. Always a problem. I usually just figure a border (even a one-pixel border) is .5%. Since I rarely use vertical rules or borders, though, it usually isn’t a problem for me.

But whatever, the stylesheet currently is actually not robust:

1) … main heading overlapping the middle column …

2) If I increase the font size by only one notch in Mozilla 1.7 the three-column layout goes all wacky.Aaargh — right you are. But I wouldn’t say the stylesheet is not robust — this seems more like a basic design failure!

I was semi-reconciled to the first problem. But that the whole layout goes wacky with an uptick in size is outrageous. Wonder how I missed that? (I see it now with Firefox and Safari, so I really am a bum!)

I have been switching to position: absolute and pages seem more controllable that way. Annoying figuring everything out, but then most of it stays put. Do you think that would help here?

Thanks for being persistent.

[ktinkel]

Let us know if you make a test somewhere. I do pay attention to warnings from the validator, because I can learn something from them for the future, even if I won't change my existing HTML.Looks as if I must do something about this (see Marjolein’s last message). Sigh.

[iamback]

I usually just figure a border (even a one-pixel border) is .5%. Since I rarely use vertical rules or borders, though, it usually isn’t a problem for me.Just before seeing your reply I had totted it all up and figure your widths are 99% + 2px. Since 1% of 800px is 8px that should be OK (even for a window width of 640px it should) - but remember the pesky rounding errors: the only answer there is to test!

I have been switching to position: absolute and pages seem more controllable that way. Annoying figuring everything out, but then most of it stays put. Do you think that would help here?Possibly - but don't forget that some elements may need to grow vertically as font sizes increase (see the topmenu!). a height: auto can do wonders here - but at the same time that means you cannot use position: absolute at least to position something vertically (as in below a page header). Nesting divs can help (sometimes): have one div postioned (relatively) below the one that "grows" and within that position other divs.

Unfortunately (at least in my experience!) layout with CSS is still more a matter of trial and (a lot of) error than an exact science... I always test with increasing font sizes, and for me the result has to be acceptable with the font scaled up one "notch", and at least sort-of usable with it scaled up two notches. No hard rules... I just try and look to see what I get. :)

[iamback]

Aaargh — right you are. But I wouldn’t say the stylesheet is not robust — this seems more like a basic design failure!Also forgot to mention: do you have the developer toolbar (for Mozilla/Firefox)? If so, turn on Outline -> Block Level Elements - if not, go and get it yesterday! ;) It can really be a great help to see how your blocks are actually positioned - see attachment (font size +1 situation).

[ktinkel]

Also forgot to mention: do you have the developer toolbar (for Mozilla/Firefox)? I do, and looked at the page without increasing the size. However, even that suggests a problem.

Thinking it would be a rounding thing, I reduced the total width (elements, padding, margins, and 1% allowance for the 2 rules) to 99%. (It had been 100%.) Still breaks.

I think I need to rethink. Ouch. Just what I wanted on a rainy Sunday afternoon, the start of Chinese New Year! :rolleyes:

[iamback]

I think I need to rethink. Ouch. Just what I wanted on a rainy Sunday afternoon, the start of Chinese New Year! :rolleyes:Sorry about that. How about some fireworks then, to liven things up?

[ktinkel]

Sorry about that. Take another look (http://desktoppublishingforum.com/). Try to break it now. (It seems okay if you go up 4 ticks in font size; after that it does make a bit of a mess.)

I hope, she says, fingers crossed.

No fireworks, but think I will make some Chinese food for dinner.

[iamback]

Take another look (http://desktoppublishingforum.com/). Try to break it now. (It seems okay if you go up 4 ticks in font size; after that it does make a bit of a mess.)

I hope, she says, fingers crossed.Hope she doesn't turn off images? But I do, in testing. Always. At some point, at least (such as when I can't select text!). <eg>
It's broken, at least because the alt text doesn't repeat the headings you squirreled away (att. 1).

So: better, but no cigar yet...

But now that you are using position: absolute for the columns, have you tried what happens when you add height: auto to the top menu (#navbox) and the header (#logobox) to allow them to grow with the text size (and unhiding the h1 and h2, of course!)? And getting rid of the position: absolute for the #logobox - or at least defining its top position in ems rather than px - since now that still is still being overlapped by a "growing" #navbox (att. 2). Giving the same treatment to the columns, making #logobox (the restored version) full width and moving up the h2 should also help (at least get rid of the top padding). And what happens if you don't define a top for the columns at all?

Getting there, not there yet. ;)
And I don't think I like the new style of the #navbox - but that is merely a matter of taste; the black band along the top gave the page a strong anchor and that's lost now.

Hmmm ... any of that Chinese dinner left? I woke up, it's stil the middle of the night, and I'm hungry!

[Ian Petersen]

Wonder if the validator just looks to see what units are included in a statementI'm sure that's what it's doing. The validator should really only be checking that your code is formally valid - that you've dotted your 'i's and crossed your 't's, so to speak - not whether you've actually written anything sensible. Obviously, it is checking for a little more than that, but probably not to the level of expanding shorthand padding specs to see whether they apply horizontally or vertically. As Marjolein points out, borders specced in pixels are a no-no if other dimensions are in percent

[George]

But I certainly don't agree with George that you can just ignore the warnings: all warnings are potential bugs (maybe only visible with another browser, or another font size, etc.), so they are worth double-checking.

I never said ignore warnings. I said I had the exact same situation KT had in one situation -- that I couldn't figure it out, that I decided it wasn't very significant, and I left it alone, which is a procedure that applies from time to time.

Regards,

George

[iamback]

I never said ignore warnings. I said I had the exact same situation KT had in one situation -- that I couldn't figure it out, that I decided it wasn't very significant, and I left it alone, which is a procedure that applies from time to time.Sorry, but from your message it wasn't clear that you - as you state now - were referring to one particular case. It rather sounded as a general approach. Thanks for the clarification. :)

[ktinkel]

It's broken, at least because the alt text doesn't repeat the headings you squirreled away (att. 1).Ooops. That was an oversight.

… have you tried what happens when you add height: auto to the top menu … getting rid of the position: absolute for the #logobox … same treatment to the columns … what happens if you don't define a top for the columns at all?I didn’t even know about most of that! (New to positioning.) I’ll play with it.

You remind me of the nun who taught geometry in my second year of high school!

Hmmm ... any of that Chinese dinner left? A small serving of asparagus and pork (just about enough for my lunch, in fact).

[ktinkel]

… borders specced in pixels are a no-no if other dimensions are in percentOkay. So how do you spec vertical borders (i.e., vertical rules) if the other element widths are expressed in %? Use .1%, assuming roundup would keep it at 1 pixel up to some point? (And then it would really get ugly, but so would the page, so so what?)

[iamback]

Ooops. That was an oversight.You should know that I am not a fan of images-of-text.

I didn’t even know about most of that! (New to positioning.) I’ll play with it.That was the idea. ;-) Mind you, it may not even work - but do play with it, try different approaches...

You remind me of the nun who taught geometry in my second year of high school!LOL! No one's ever compared me to a nun before. :D

A small serving of asparagus and pork (just about enough for my lunch, in fact).Oh, never mind - enjoy your lunch! Time to think about my own dinner. I think I'll warm up that fresh pea soup I got yesterday - I love that but you can't cook it in small quantities... ;-)

[ktinkel]

You should know that I am not a fan of images-of-text.I expected no less. But I had the type above and to the right of the logo as CSS-controlled text, but it wouldn’t stay put. Help me with that, and I will gladly dump the image text.

Mind you, it may not even work …Oh, gee — thanks.

I think I'll warm up that fresh pea soup I got yesterday - I love that but you can't cook it in small quantities... ;-)That’s exactly what I do love about big pots of soup (or stew or pot roast, etc.). You can have meals for days ahead!

[ktinkel]

… have you tried what happens when you add height: auto [etc.]Take a look. Some of it works, some not.

… and unhiding the h1 and h2, of course!I can unhide h2, with only minor pandemonium (it works as is and up two sizes). H1 is a pain because that type does not really fit over the logo; so it is part of the image with h1 hidden.

And what happens if you don't define a top for the columns at all?Disaster — they zip up to the top of the window!

[Ian Petersen]

So how do you spec vertical borders (i.e., vertical rules) if the other element widths are expressed in %?With great difficulty! <g>

Actually it's not that difficult. The trick is there must not be an explicit percentage calculation that includes a pixel dimension without any 'elastic' to make up the unknown remainder. E.g.

width: 80%; border: 1px; margin: 10%;

won't work very well, since there isn't 'room' for the border since the width and border already add up to 100% (80 + 10 + 10 = 100%). If you make margin 9% then it doesn't add up to 100% anymore, but the remainder is undefined. Sometimes it may be more than a pixel, sometimes less. Explicitly defined percentages must always add up to 100% without any uncertainty. The answer is to let the browser calculate one of the widths itself. Thus:

width: 80%; border: 1px; margin: auto;

will work, since we explicitly define the width and the border but the margin is simply 'what's left over' and the browser will happily calculate that.

Sometimes it's easier to explicitly set the widths on a containing DIV and then set the border on another DIV nested inside. Clear as mud, isn't it? <g>

[ktinkel]

With great difficulty! <g> … The answer is to let the browser calculate one of the widths itself. Guess I have to work on that.

[iamback]

Take a look. Some of it works, some not.OK - just getting you in the process of playing with the boxes ;-)

I can unhide h2, with only minor pandemonium (it works as is and up two sizes). H1 is a pain because that type does not really fit over the logo; so it is part of the image with h1 hidden.I note you now have the logo and "Desktop Publishing Forum" together as one image - just as I was going to suggest, at least while you sort this out!

Now what I suggest you try is:

comment out the h1 you have (instead of hiding it)
get rid of the word "logo" from the alt text - make it just "Desktop Publishing Forum" or maybe "DTP - Desktop Publishing Forum" to match only the text ("logo" is a description, not a replacement).
then wrap the image in a/the h1 tag (which you do not hide) so you end up with something like this (a slight variation):<h1><!--Desktop Publishing Forum<br/>--!><img src="images/dtp_kt_sm_type.png" alt="DTP - Desktop Publishing Forum" width="220" height="88" /></h1>

Now you just need to place the h2 next to that. Start by making sure the #logobox takes up the full width so we have some room for the h2; then make the h1 inline (display: inline) and float it left; make the h2 inline as well and (at least for now) don't give it any padding. See what you end up with after that (I'm just writing down what I would try next, not testing!).

Debugging tip: style pesky elements you're moving / sizing with a colored border or a colored background; I do it like this:
border: 1px solid red; /*DEBUG*/Of course, use different colors and maybe border styles for different elements. Just move the /* to the start of the line to temporarily disable it - until you're really sure yur design is robust and you feel you can remove it completely. Apply this to your #logobox at least to seen what's happening.

Disaster — they zip up to the top of the window!Conclusion: you can't use absolute positioning in relation to elements that need to scale (unless you specifically want to overlay).

Try thinking of "stacking" a number of full-width blocks vertically:

topmenu #navbox
page header #logobox
page content: you'll need a new div here - a wrapper for your columns

With no explicit positioning at all, these three boxes will just end up below each other, no overlap, each can grow vertically to accommodate user's font size effects.

Then within the page content wrapper block put your three columns - define widths, margins, and "float them into place": that's relative positioning only - nothing absolute in sight. Because you must have (only) nested floated elements here, you must set height: auto; on the containing page content div (try giving it a DEBUG light background color to see why).

Still just writing up what I'd try - but I think this should get you a lot closer to a fluid layout.

[ktinkel]

Still just writing up what I'd try - but I think this should get you a lot closer to a fluid layout.Oy. I’ll give it a try.

Thanks for your help. I am sure it is good for me. Or I hope so, anyway! :)

[ktinkel]

Start by making sure the #logobox takes up the full width so we have some room for the h2; then make the h1 inline (display: inline) and float it left; make the h2 inline as well and (at least for now) don't give it any padding. I didn’t end up doing it this way; will try later. (Fried brain syndrome.)

Then within the page content wrapper block put your three columns - define widths, margins, and "float them into place": that's relative positioning only - nothing absolute in sight. Because you must have (only) nested floated elements here, you must set height: auto; on the containing page content div (try giving it a DEBUG light background color to see why).Something must be wrong; that is, the thing works without a height:auto on the containing box; and it absolutely ignores my attempt to apply a background color, so I stopped trying. Makes me nervous, though.

[ktinkel]

OK - just getting you in the process of playing with the boxes ;-)Now this is very weird. I have validated the HTML and the CSS, and get warnings on the CSS about using “absolute and relative lengths” in margin at Line 69 and Line 83.

I couldn’t see it, so copied the entire report, including the CSS, placed it in a new BBEdit text file, and searched for “margin” — there are absolutely no mixed lengths in any margin setting.

What’s going on? If we cannot trust the W3C validators, who can we trust? ;)

[iamback]

Now this is very weird. I have validated the HTML and the CSS, and get warnings on the CSS about using “absolute and relative lengths” in margin at Line 69 and Line 83.

I couldn’t see it, so copied the entire report, including the CSS, placed it in a new BBEdit text file, and searched for “margin” — there are absolutely no mixed lengths in any margin setting.

What’s going on? If we cannot trust the W3C validators, who can we trust? ;)First: don't forget this is a program, they're constantly tweaking it, and it's always possible there are bugs. - I strongly suspect we have one here....

I ran the report and found those same warnings. Then, in spite of the fact that it is hard to find actual line numbers back, I hit on the trick of looking at the difference in line numbers: 69 and 83 are 14 lines apart. And - did I mention this before? - I supect that a compination of 0 (without a unit) and relative units (like % or em) is trippnig it up.

Sure enough, I find these two lines: margin: 0 3% 0 0;
margin: 0 0 0 3%;The first is in #left, the second is in #right - and they are exactly 14 lines apart. However, there are also quite a few instances where you have things like margin: 0 .5em; and it's not complaining about those. Looks like that warning is triggered only with % in combination with 0 (which may first be interpreted as something like 0px or 0pt!).

As a test, in one of those likes change all the zeroes to 0% - then re-validate. If it ends up with only a single warning, we've pinned it down and should report as a bug. (The link at the bottom of the report leads to a page metioning some email lists, the first of which is (also) for reporting bugs in the validator: www-validator-css@w3.org
This mailing list is for comments or bug reports on the CSS validator. (If it is as I suspect, it should be easy enough to fix: just don't warn if all "absolute" lengths are in fact zero.)

[iamback]

I didn’t end up doing it this way; will try later. (Fried brain syndrome.)I can well imagine that! I'm working on my "big film archive operation" and puzzling out CSS problems is a pleasant break. :D If you're staring at it all day... well, take a break! (Do some film archiving, maybe? ;)) But do try later - although it is definitely behaving better now! No more overlap, the page content is just "pushed downwards" when the heading grows with increasing font size. Do get rid of the word "logo" in the alt text, at least, for now.

Something must be wrong; that is, the thing works without a height:auto on the containing box; and it absolutely ignores my attempt to apply a background color, so I stopped trying. Makes me nervous, though.Don't get nervous! If you don't have any padding in the containing box, and no margins on the contained boxes, you may not see the background color (did you scroll all the way down?). In that case, switch to using a glaring DEBUG border - one px should do it. Then try with and without height: auto on the containing box. The aim is to show what difference that makes. Try in different browsers, too.

[dthomsen8]

As a test, in one of those likes change all the zeroes to 0% - then re-validate. If it ends up with only a single warning, we've pinned it down and should report as a bug. (The link at the bottom of the report leads to a page metioning some email lists, the first of which is (also) for reporting bugs in the validator: (If it is as I suspect, it should be easy enough to fix: just don't warn if all "absolute" lengths are in fact zero.)

Good detective work! You provide a circumvention, and a way to report the bug to those who can fix it. I suppose we could decide to put units on all measurements, but it does seem like the validator should work without it.

A better question is to ask whether any browsers are confused by this kind of situation.

[ktinkel]

… I supect that a compination of 0 (without a unit) and relative units (like % or em) is trippnig it up.

As a test, in one of those likes change all the zeroes to 0% - then re-validate. If it ends up with only a single warning, we've pinned it down and should report as a bug. (The link at the bottom of the report leads to a page metioning some email lists, the first of which is (also) for reporting bugs in the validator: (If it is as I suspect, it should be easy enough to fix: just don't warn if all "absolute" lengths are in fact zero.)That is what I figured out — that it was objecting to 0 without a unit designation. But I do believe that is recommended (and after all, zero is zero is zero!)

I will test and send an e-mail! Thanks.

[iamback]

That is what I figured out — that it was objecting to 0 without a unit designation. But I do believe that is recommended (and after all, zero is zero is zero!)

I will test and send an e-mail! Thanks.Indeed, zero is zero - and for that reason that is the only value that is valid without a unit. So the validator "should" not treat it as a non-relative unit ... if that is what it's doing, as I suspect.

[ktinkel]

Indeed, zero is zero - and for that reason that is the only value that is valid without a unit. Don’t forget values for line-height — they can be (and often should be) used with no stated unit.

[iamback]

Don’t forget values for line-height — they can be (and often should be) used with no stated unit.Ah, I just learned something! :) I looked it up in the standard and found that indeed you can specify line-height as a <number> which is in fact a multiplication value for the font size. Very nice.

Values for this property have the following meanings:

normal
Tells user agents to set the computed value to a "reasonable" value based on the font size of the element. The value has the same meaning as <number>. We recommend a computed value for 'normal' between 1.0 to 1.2.
<length>
The box height is set to this length. Negative values are illegal.
<number>
The computed value of the property is this number multiplied by the element's font size. Negative values are illegal. However, the number, not the computed value, is inherited.
<percentage>
The computed value of the property is this percentage multiplied by the element's computed font size. Negative values are illegal.

[ktinkel]

Ah, I just learned something! :) I looked it up in the standard and found that indeed you can specify line-height as a <number> which is in fact a multiplication value for the font size. Very nice.My dear — I think you just made my day! :):)

[iamback]

My dear — I think you just made my day! :):)Since my motto is: learn something new every day - so did you (made my day)!

[ktinkel]

As a test, in one of those likes change all the zeroes to 0% - then re-validate. If it ends up with only a single warning, we've pinned it down and should report as a bug. Well, it did do that, and I attempted to report it as a bug. But what a bureaucratic nightmare!

The rule is one much register before posting to the list, and there is a list of places to register; only problem, the CSS validator list was omitted.

After poking around further, I decided to post anyway. Got an auto-reply asking me to follow a link to confirm my posting; only problem, the list does not respond (got three time-outs before giving up).

Oh, well. Maybe I’ll try that link again another day. I have until Feb 7.

[iamback]

Well, it did do that, and I attempted to report it as a bug. But what a bureaucratic nightmare!Well, there's one thing to be said for the W3C lists: they don't have spam. Requiring registration and/or moderation for a first post certainly contribute to that. (Now if they only would obfuscate email addresses in their archives... :()

Oh, well. Maybe I’ll try that link again another day. I have until Feb 7.Let me know if you don't get through - I could try then (not that I'm subscribed to this list yet, but I am subscribed to a few others at W3C, and I'm getting interested. ;)