Re: Tabbed Interfaces in CSS

Brad Kemper wrote:
>>> Ah, so that's what it is. And I can't seem to override it with my own 
>>> '!important' declarations either, even if I put it in a 'style' 
>>> attribute, so that does seem like a bug in Firefox.
>>
>> Use of !important rules in a UA sheet is a vendor-specific extension
> 
> It is? I thought !important was well defined for use within any style 
> sheet.

Sort of.  The grammar allows it.  The prose in CSS2.1 section 6.4.2 says:

   Both author and user style sheets may contain "!important"
   declarations, and user "!important" rules override author
   "!important" rules.

That sounds to me like they're not allowed in UA sheets.  Further, 
they're not listed in section 6.4.1 item 2, where you'd expect them to 
be listed if they were meant to override other UA rules.  So per what 
the spec actually says, they're not allowed in UA sheets.  Or something.

> It doesn't talk about which has precedence, in the way that it does for 
> author use of !important vs. user use of !important (user overrides 
> author, in a reversal of normal precedence).

Sure, and precedence is the only thing !important matters for!

> So lacking any such exception, one would expect that normal precedence applies, in which the 
> rules in earlier loading style sheets (such as the UA style sheet) can 
> be overridden by later loading rules with the same or greater 
> specificity.

Except the same reasoning used for the user/author reversal applies 
here.  At least if you're actually going to allow such declarations.

> I've never seen anything that makes the !important declarations in UA 
> style sheets more powerful than the ones in any other style sheet.

You haven't seen anything that mentions or allows them at all, really. 
That's because there isn't anything.

> But its not in C++ code; its in a style sheet, and should therefore 
> follow the normal rules of how style sheets work.

Why does that matter?  Seriously, the whole "ua style sheet" is a black 
box as far as the rest of the system is concerned.  It's there so that 
one has a simple conceptual model for the default values of the 
properties in any given UA.

But basically, the fact that these rules are in a .css file is a Gecko 
implementation detail.  Same for the non-!important rules.  It could all 
be done in C++ code with no effect on spec compliance.

> If it was a vendor extension, it should have -moz- in front of it, 
> shouldn't it?

Why does that matter for an extension that's not available to web authors?

Seriously, if a UA wants to allow an extension ONLY in its UA 
stylesheet, why would it need to prefix it?

>> I'd like to see the spec that says so.  Note that the default 
>> rendering required of <legend> for web compat cannot be described via 
>> CSS at the moment,
> 
> How so? Because it has a background that is transparent to everything 
> except the border of the fieldset?

That's a minor part of it, yes.  More to the point for this discussion, 
it affects the width of the fieldset in interesting ways.

> That's actually one of the things that I COULD change.

Indeed, but to allow such a rendering at all, one has to not comply with 
CSS as it stands.  This means not using the standard CSS rendering 
codepaths and doing Something Else.  What that Something Else should be 
is an interesting question.

> The properties that could NOT be changed not only 
> COULD be described by CSS, but apparently ARE described by CSS in the UA 
> style sheet (width, position, etc.).

Right.  See the width thing above.

> I don't know why not. It can be simulated pretty well with a absolutely 
> positioned span inside a relative position div  with a little padding on 
> the top. That doesn't seem that exotic.

Oh, really?  Please replicate for me the behavior of this testcase:

data:text/html,<!DOCTYPE html><fieldset style="display: 
inline"><legend>longlonglong</legend>short</fieldset>

with that setup.  I don't have IE to test on right now, but Gecko, 
Webkit, and Presto all render that interoperably, for what it's worth. 
For that matter, what about:

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

?

>> The extent to which UAs paper over this fact in various ways varies, 
>> but the CSS spec doesn't specify anything over those papering-over 
>> attempts.
> 
> Maybe it should.

Sure.  When it does, in a way compatible with the web, we'll implement it.

> Innards of select cannot always be described or restyled via CSS, but 
> some things, like positioning and width, often can be, and often are.

Sort of.  Can you really describe or restyle the position and width of 
the <select size="1"> dropmarker (assuming there is one in the relevant 
platform theme at all)?  Of the <select size="1"> display area (the one 
that shows the currently selected option)?  I have yet to see a UA that 
would let me do that.

> What is so complicated about a simple little box with text in it?

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/forms/nsFieldSetFrame.cpp&rev=3.169&mark=342-346,354#337

> The fact that 'legend' can't in Firefox but can in other UAs absolutely smells like a bug to me.

Fundamentally, once you figure out something is not covered by CSS you 
have two options in the face of people trying to apply style to it:

1)  Try to do something to honor the styles; when CSS is extended to
     cover the item in question it'll either have to define what you did
     as the spec or break pages that depended on your behavior.
2)  Ignore the styles so that authors don't become dependent on your
     behavior and you don't constrain future development of the spec.

Which one a UA picks is a design choice.  UAs are not necessarily 
consistent in how they make such a choice for different features.  Your 
call on which one you think is the right choice in this case, but there 
are pretty good arguments for both.

-Boris

Received on Saturday, 25 April 2009 04:44:39 UTC