- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Sat, 25 Apr 2009 13:46:23 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: www-style list <www-style@w3.org>
- Message-Id: <E220F025-11E1-4332-8979-6A6ED701722B@gmail.com>
On Apr 24, 2009, at 9:43 PM, Boris Zbarsky wrote:
> 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.
Only via a very strict interpretation of "may". If my boss tells me I
may get a raise, it doesn't mean no one else will get a raise. I read
that sentence as addressing only how author and user sheets interact
with !important, not as a proscriptive against other sheets using it
at all (or even against using it at all except as a vendor-specific
extension).
> 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.
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).
> [...]
>
>> 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.
That doesn't logically follow.
6.4.1 creates a special exemption for user style sheets. It does not
say that the earlier a sheet loads, the more precedence its '!
important' takes.
> [...]
>> 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.
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?
> [...]
>>> 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>
>
> ?
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.
But I'd prefer if you just said 'legend { position: -moz-legend-
position; background-color: -moz-legend-background; }',* but still
allow those properties to be overridden with author rules. Webkit
allows the position and width and so on of legend to be overridden,
and is much more flexible on that as a result.
* presumably, -moz-legend-position would mean that the element is
middle-vertical-aligned with the top border of the closest fieldset
ancestor, but if there was already something there with that position
then the property would be ignored. Display could just be inline-
block, and white-space could be no-break, and authors that wanted to
override that would just end up with the consequences of doing so.
>> 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.
But those are pieces of an element that can't be selected and don't
have rules in your style sheet. 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.
>> 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
Yeah, OK on that. Wow.
>> 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.
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. Having an internal style that does its own magic
would not seem to require ignoring styles that could change it from
that.
Received on Saturday, 25 April 2009 20:47:06 UTC