Re: Border at top of the page

On 2007-11-29, Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> wrote:

Scripsit Ben C:

It looked too complicated. The message seems to discuss CSS issues,
yet it's in the HTML group. Are you referring to HTML or CSS
conformance?

CSS conformance.

However, doctype sniffing affects the rendering even when no style sheet
is present.

Well in some browsers (Firefox at least) one of the results of doctype
sniffing is a different default stylesheet.

Actually we can use style sheets to _nullify_ the effect of
doctype sniffing in these issues, by adding explicit rules for margins
(adding a wrapper for the "loose" or "anonymous" text if needed).

Only in some of these issues. There are two kinds of quirk: those you
can achieve with a default style, and those where you need to implement
special behaviour.

An implementor might achieve the latter by inventing special properties
like -moz-first-node, but it doesn't change the fact that he's having to
implement behaviour that isn't in the CSS specification.

An example of the first kind of quirk is form { margin-bottom: 1em }
which Firefox applies in quirks mode (i.e. as a result of doctype
sniffing). You might say that's not a quirk, it's just a different
default style.

I'm inclined to call a "quirk" anything that gets turned on by doctype
sniffing.

Section 3.2 (of CSS 2.1) explains that to claim conformance you have
to do the cascade and give every element a value for every applicable
property.

Yes, but does this exclude the possibility of affecting the rendering
with something external to CSS?

Not in general. For example, suppose instead of the usual toolbar, you
alpha-blended "Home" etc. buttons on top of the actual page itself.

Someone could argue: I set that div to background-color: red and the
stacking rules mean it's on top. So it should be red. Why's it greenish
pink and why can I see a picture of a house on it then?

But that would be a poor argument. It's clear that this hypothetical
browser has rendered the page according to the rules, and then drawn
some extra controls on top of it. You might say that's a stupid place
for a toolbar, but it doesn't really count as CSS non-conformance.

But what about IE's habit of leaving gaps of 3px between floats? You
could say: IE conforms to CSS, and then it moves things a bit. This
isn't a non-conformance, it's just a feature external to CSS that
affects rendering.

But that would clearly be rubbish. It's obvious that the 3px gap is a
non-conformance to CSS, which says explicitly that floats' margin edges
should go flush next to one another.

But is there anything to say that the initial value of a property
(which may be pink) can't depend on the day of the week? Well it
doesn't say that specifically I suppose, but only because it's
obviously ridiculous.

Why would that be ridiculous? Browsers are allowed to have different
default rendering for documents, or different browser style sheets. Why
couldn't a browser have different defaults in different days. I think
you agree that a browser update might modify the defaults; it changes
the browser to a slightly different browsers. Why couldn't the defaults
change otherwise? Or we could just define the different behaviors as
updates. :-)

I hadn't thought of doing it like that-- I was proposing a different
initial value on different days, and a constant default stylesheet that
doesn't set background-color for <p> at all.

The specification doesn't say that the initial value has to remain
constant from one day to the next, but only because it doesn't rule out
every ridiculous possibility.

But I suppose I have to concede that there would be nothing wrong with
different default stylesheets for different days of the week.

Or days of the year. You might set <p> to green on St Patrick's day for
example.