Re: Tabbed Interfaces in CSS

Brad Kemper wrote:
> Hmm. That's an interesting point. It would seem from that, that 
> !important in a UA sheet would at best have no effect, or at worst be 
> invalid (like adding !invalid to the value).

Or in other words, its behavior is just not defined.

> So you're saying that it is not so much that the UA has a style sheet 
> that loads first with some defaults, but that the UA style sheet is not 
> a real style sheet, just something that just imperfectly approximates 
> the starting point? 

No.  I said exactly what I meant: the spec requires UAs to behave as if 
all rendering differences between what a UA does by default and what 
you'd get if you had a bunch of XML elements in the null namespace 
rendering with no stylesheets applied behave as if the UA applied a 
single stylesheet prior to the rest of the cascade.  For example, if 
HTML <p> is supposed to end up as a single rectangle containing the 
text, it should have a "display: block" applied to it.  And in 
particular, if the author does:

   p > span { display: inherit }

then the span in question should end up with "display: block".

At no point is there a requirement that there be an actual CSS file with 
an actual "p { display: block }" rule in it; not the key words "as if" 
above.  Of course in a lot of UAs having such a CSS file is in fact the 
simplest implementation strategy.  But something simple like handling of 
<img align="left"> is not handled via an actual CSS rule in Gecko, even 
though it affects the _computed_ style of the image as if the rule 
"img[align=left] { float: left; }" were applied (or rather a whole bunch 
of rules, with all possible cases of the value after the '=').

> OK, so a little more complicated to maintain all the ins and outs of how 
> it has worked in the past. I got pretty close with this:
> 
> http://www.bradclicks.com/cssplay/fieldset.html
> 
> Or at least that works pretty well on Webkit. Firefox doesn't seem to 
> allow generated content to be positioned.

It does in anything based on Gecko 1.9.1 or later (Firefox 3.5, say).

Here's a simple example that you can't do with that approach:

data:text/html,<!DOCTYPE html><fieldset style="float: 
left"><legend><span style="color: green">longlong</span><span 
style="color: blue">long</span></legend>short</fieldset>

> But I'd prefer if you just said 'legend { position: 
> -moz-legend-position; background-color: -moz-legend-background; }'

That wouldn't be compatible with the web, infortunately (and yes, I'd 
looked into using |position| here).  Simple testcase

data:text/html,<!DOCTYPE html><fieldset style="float: left"><legend 
style="position: static">longlonglong</legend>short</fieldset>

And yes, sites do that.

One could introduce a whole new CSS property to describe legend's 
positioning behavior, but that would mean sorting our how it interacts 
with existing display/position/float.  One could add a hack where if the 
position is static and the float is none then you do the current 
behavior (though there are some interesting questions regarding display 
still).  That involves defining exactly what one means by "legend" in 
that case.  Right now in Gecko, the definition is basically "this thing 
that's out of the fieldeset's flow in this particular special way".

All this could be done, and might be.  It's just not required by the 
spec, so not precisely a bug in terms of CSS compliance.

> But those are pieces of an element that can't be selected and don't have 
> rules in your style sheet.

Well..... sort of.  They can in fact be selected in Gecko's UA 
stylesheet.  See 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/style/forms.css&rev=3.151&mark=190-210#190 
and 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/style/forms.css&rev=3.151&mark=220-236#220

You're right that we don't allow such a selector in an unprivileged 
stylesheet to match the very real DOM nodes and CSS boxes that we build 
there.

 > Legend is an actual HTML element with rules
> in your style sheet. I feel that once you put a rule for something in 
> your style sheet, you should allow that rule to be overridden using CSS. 
> Otherwise it is just something pretending to be CSS.

Yep.  That's all any rendering of <legend> can be right now, precisely.

> Well, not so much my call. But it doesn't seem to me too likely that the 
> Web would break if you let authors override more of the default styling 
> of LEGEND.

The web wouldn't break; the ability to define legend handling via CSS in 
the future might.

-Boris

Received on Sunday, 26 April 2009 00:36:18 UTC