Closed Bug 62150 Opened 24 years ago Closed 23 years ago

Specificity of STYLE attribute should be (1,0,0), not infinite


(Core :: CSS Parsing and Computation, defect, P3)






(Reporter: pierre, Assigned: pierre)


(Keywords: css1, Whiteboard: [fix in hand] (py8ieh:0x0000g0 vs 0x000100) WG)


(5 files)

The STYLE attribute is currently assigned an infinite specificity.  This is done 
in nsHTMLGenericElement, line 214:

Following a discussion on the CSS WG mailing list:
Netscape and Microsoft should stop doing this and assign a specificity of (1,0,0) 
to the STYLE attribute as the spec says:

The proposed patch is, duh, to change the line above to:
Whiteboard: [fix in hand]
We may need to make this a standard-mode-only thing if it breaks too many sites.
Keywords: qawanted
QA Contact: chrisd → ian
Whiteboard: [fix in hand] → [fix in hand] (py8ieh:0x00g vs 0x010)
Hmm - I added a comment to this bug but it is apparently lost...

My only concern is that the value 0x100 is possibly not correct, though I am not
sure. The spec says that we need to assume a sufficiently large base, and I'm
not sure if 16 is sufficiently high. I guess that it just limits us to 16 IDs,
attributes and tags in any one selector, which seems small but livable. I'm not
too familiar with how we calculate and represent the weight for normal rules,
but I'd assume that we use the same base. If this is the case, then we have the
same limits anyway, so r=attinasi. has noted this bug in every single UA that it has reviewed, and 
each entry is accompanied by a recommendation that the bug *NOT* be fixed. I'm 
not one to blow off standards lightly, but here I agree with 
The standard does not make sense, and needs to be changed.

If standards compliance is ruled more important than common sense, then I 
suggest that this bug be set to trivial - low priority.
I'm going to change the specificity of the STYLE atribute in 0.9.1 but since I 
don't want to take any chance, I'm going to do it in strict mode only.

Target Milestone: --- → mozilla0.9.1
Moving to m0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Moving to m0.9.3.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Keywords: qawanted
Whiteboard: [fix in hand] (py8ieh:0x00g vs 0x010) → [fix in hand] (py8ieh:0x0000g0 vs 0x000100)
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
I don't recall the exact words of the discussion that lead me to file this bug as 
a 1-line fix, but it's not.

The problem is that the RuleWalker visits:
1) the HTMLStyleSheet.
2) the CSSRuleProcessors from the different CSSStyleSheets that belong to the 
3) the HTMLCSSStyleSheet.
It means that whatever their weight, the rules from HTMLCSSStyleSheet override 
those from the document's cascade.

The proposed patch makes the inline style rules part of the cascade in strict 
mode only.  The HTMLCSSStyleSheet gets the RuleProcessor from the CSSStyleSheets 
and enables it to merge the inline style rules into the cascade.

It required some new APIs:
- In nsICSSStyleRuleProcessor.h, to allow some communication between the 
HTMLCSSStyleSheet and the CSSProcessor.
- In nsIStyledContent.h, to access the inline style rule.  Also, in addition to 
WalkContentStyleRules and WalkInlineStyleRules, I added WalkFixupStyleRules 
because the BodyFixupRule still needs to be walked at the end of the cascade.

--> Marc & Daniel: please review
--> DBaron: please approve/review
--> Hyatt: just for confirmation, is it ok to make the XULElement's inline style 
rule part of the cascade with a weight of 0x100 or do you prefer to have it 
processed like a FixupRule (ie. with infinite specificity as it used to be)?
Attached patch patch 1.0Splinter Review
It is ok to make xulelement's inline style part of the cascade.
(thinking at loud : me thinks that we should really have a triplet (or even a
 quadruplet) for specificity instead of a single integer)
Daniel & dbaron: please review
brendan & scc: we have a shortage of reviewers in layout. Could you please r/sr 
this patch?  Thanks.
brendan threw this at me. I'm not sure we have a shortage of reviewers, but the
silence _is_ deafening. I can't comment intelligently on the value of this fix;
it seems somewhat controversial, but I'll leave that to dbaron, hixie, and
others to debate.

So, I'll do what I do best...pick nits!

1. You've altered (one of?) the SelectorMatches ctor's to take a PRBool as it's
third argument. However, you're passing |nsnull| when you use it. I'd have
expected PR_FALSE?

2. It's not immediately obvious to me why you needed to create
nsIRuleProcessorSheet. Could you explain? It looks like HTMLCSSStyleSheetImpl
doesn't really care _what_ mCSSProcessor gets set to; it really just cares that
it got set so it can decide whether or not to WalkInlineStyleRule().

Other than that, the patch seems fine to me, and you can count me as r= if hixie
and/or dbaron are ok with it.
Thanks for the review.  We have a shortage these days: Marc and DBaron are all 
over the place because of topEmbed issues and Daniel is out sick.  I assumed 
DBaron and Hixie were fine with the possible consequences of the patch otherwise 
they would have marked the bug WontFix a long time ago.  Still, I won't checkin 
before a last confirmation from them.  Daniel and Hyatt said separately that it 
would be ok in XUL and in the Editor.

1) Correct: aHasInlineRule should be PR_FALSE, not nsnull.

2) The HTMLCSSStyleSheet needs to know whether it is followed in the cascade by 
some CSSStyleSheets (and thus whether the previous processor is a CSSProcessor) 
in order to make the inline style rules part of the cascade or not.  If it makes 
them part of the cascade, it needs to be notified when the processor goes away. 
For that notification to take place, the CSSProcessor needs to call 
DropRuleProcessorReference() which is currently only implemented in 
CSSStyleSheet. That's why I moved this method to a separate class that both 
HTMLCSSStyleSheet and CSSStyleSheet inherit from.
I am ok with the specificity of the style attribute being changed to (1,0,0) rather
than (1,0,0,0) in strict mode. Some other members of the working group are not...
so this may change again in future.

hyatt: this patch will probably affect your style attribute optimisations. Please
take a look.
What rules are typically going to start beating the inline style rule now?
Any rule with an ID selector (and anything else) could beat style attributes. 
This includes "html#myhtml p".
I think the patch requires some new files, but I don't see them in the
patch.  (I'm not sure about Mac, but on Windows and Unix, cvs diff will
show the contents of new files that have been "cvs add"-ed if given the
-N argument, i.e., "cvs diff -wN".  Hopefully MacCVS has an equivalent
feature.)  It would make the patch easier to review if they were there...

But anyway, without that, a few comments (although not a complete
review of what's there):

Why not put nsIRuleProcessorSheet into the interface inheritance
hierarchy so that nsIRuleProcessorSheet inherits from nsIStyleSheet and
nsICSSStyleSheet and nsIHTMLCSSStyleSheet inherit from
nsIRuleProcessorSheet rather than nsIStyleSheet?  This whole thing seems
like an overuse of COM (there's only one implementation of the two most
specific interfaces anyway), but while we're here, why not at least save
the extra 4 bytes, since it seems to make sense anyway?

We still need to figure out what optimizations relating to inline style
need to be undone.

Maybe, once this is done, it might make sense to split the
nsCSSRuleProcessor stuff into a file separate from nsCSSStyleSheet.cpp
(probably by copying RCS files at the repository level and then
eliminating lines from both sides in the checkin)?

+  nsCOMPtr<nsISupports> sheet(do_QueryInterface(aStyleSheet));

You shouldn't need to QI to nsISupports -- you can just cast to put it
in an nsISupportsArray, unless you really want that array to contain a
pointer to a specific interface (e.g., nsIStyleSheet), in which case you
should QI for that rather than nsISupports.  Further, why bother with
NS_ENSURE_TRUE?  We know this isn't going to fail (unless there's
programmer error, in which case it will be noticed very quickly when it
crashes) -- we shouldn't waste time on a null check we don't need.
Ugh, this patch could cause a very serious footprint bloat when inline style is
used.  Currently inline style rules are almost always the leaves of the rule
tree.  If you lower their specificity such that author sheet rules start easily
clobbering them, then you will defeat the rule tree's sharing capability and
will cause many more rule nodes to be constructed for a given document.

If I understand the consequences of this bug (and taking into account what
others are saying in the bug comments), then it is my opinion that this bug
should not be fixed and the style attribute should retain an infinite specificity.

Most rules in a sheet are shared by multiple content nodes.  Inline style
applies to exactly one content node.  I do not understand the motivation of
making inline style less specific than rules that are designed to match multiple
content nodes.  

Inline style (with this "fix") will end up being shoved into the branches of the
rule tree instead of the leaves, and this will result in duplicate branches
being created for rules that could otherwise have shared the same rule node.

Could someone explain the motivation behind this change, because I honestly
don't get it.  Questions of rule tree impact aside, the change (again assuming
I'm understanding the change correctly) doesn't make much sense to me.
Ok, I just read the discussion on the WG mailing list.  I am dead set against
reducing the STYLE attribute's specificity to 100.  This leads to situations in
which the author of a stylesheet will have to worry about whether or not the
specificity of his/her sheet rules exceed 100.

This could cause bugs and regressions in the chrome if applied to chrome
stylesheets.  Under no circumstances should this change apply to stylesheets
used in XUL.

With this change, certain rules in XUL chrome for example will start beating out
inline style simply by virtue of their complexity (i.e., having lots of
selectors in the rule).  That makes no sense.

This change is counter-intuitive and illogical.  IMO even in standards mode, we
should not comply with this requirement, and we should push to errata
implementations of CSS to correct this problem.
Errr... errata the specs, not the implementations. ;)
An example of a rule that would beat inline style and yet potentially still
apply to many content nodes:

#a b[c="d"] {


e.g., applied to

<body id="a"> .... </body>

I see no logical reason why the above rule (designed to apply to multiple
content nodes) should be considered more specific than inline style rules.
My take on this is that if we decide not to fix it, we should make it clear.  We 
either do it or we don't but there is no point marking it Future again and keep 
an ambiguous attitude.

- There are no new files.  The patch is still valid on a pull from yesterday.

- This fix is a controversial issue but different things compelled me into doing 
it now rather than later: arguments from the W3C folks, conformant 
implementations exist, other modules use it (SVG was mentioned), DreamWeaver 
relies on it (per Daniel).  It is controversial but nevertheless it was confirmed 
again several times this year.
- Unfortunately, I don't know the story as of why the style attribute was not 
assigned the highest specificity but I see the interest for authors to be able to 
override style attributes with IDs in old web pages.  It certainly helps in the 
upgrade path to css-friendly web sites.  There could be an interest in the Editor 
too: it would allow to migrate from an all-style-attribute approach as we have 
now to a model where styles would be assigned using IDs and classes, and you 
agreed last week that it would be more efficient in terms of performance. 
- IDs don't apply to multiple content nodes either.  There is a rationale to give 
them the same weight as style attributes.
- If you don't want it for XUL, I suggested earlier that we continue to process 
the XULElements inline style rules as FixupRules instead of InlineRules (ie we 
invert nsXULElement::WalkFixupStyleRules and nsXULElement::WalkInlineStyleRules 
in the patch).
- I'm not convinced the footprint would be hurt as badly as what you describe. 
I'll have to look into it and see how IDs and inline style are used thoughout the 
chrome for instance.  Could you also point me to the lines of code that would 
defeat the rule tree's sharing capability if inline style rules are not the 
leaves of the rule tree?
Well, correct me if I'm wrong, but a rule like:

button#myButton {

will beat inline style with this change, right?  There are rules like that in
the chrome.  I don't see the logic in having the rule above beat inline style. 
If you want to beat inline style you can just use !important.

The logic is that both inline style and ID apply to a single content node, so it 
seemed normal to give them the same specificity.  Now in the example above, if 
you specify a selector with an element + an ID, its specificity becomes higher.

Some people wanted inline style to have a higher weight than even !important 
rules in embedded and external stylesheet...  Some people wanted to give it a 
higher specificity than any selector...  And some people even wanted to get rid 
of inline style altogether...  Finally the authors of the spec decided it would 
be more logical to see it (I'm extrapolating here) as a shortcut for not using an 
ID, and thus make it part of the cascade like any ID.  This approach makes sense 
too: imagine authors trying to migrate existing pages that have tons of inline 
style into a set of pages that would have their style defined in external 
stylesheets.  If we follow the spec, they can add IDs to their elements and style 
them the way they want.

The response to using !important is here:

Overall, I understand both standpoints.  I made that fix because in spite of 
several debates, the spec was maintained.  Should we now tell the WG and Mozilla: 
"We've got a fix but we at Netscape think that the spec is wrong and we won't 
check it in"?

(CCd emeyer who did have strong opinions about not following the spec)
The following testcase revealed that WalkOneRule() in nsCSSStyleSheet.cpp should 
read "if (weight > 0x10000)" instead of "if (weight > 0x100)".  I will have to 
update some of my own testcases too.
I don't really know what I can say, despite having what I admit are strong
opinions on the subject.  I agree with Hyatt in broad terms that the spec is
counterintuitive, but I don't see any indication that the CSS WG is going to
budge on this issue, and I'm not about to say that we should just ignore the
specification.  Not yet, anyway.

There is one thing that occurs to me, which is that nobody knows what following
the spec in this fashion would really mean since nobody's ever done it.  If we
could get a build which is in perfect conformance on this point, we could use it
to surf around the Web and see what (if anything) breaks on the change.  That
would help us decide what to do, and would also provide some good material if
the debate it revived within the CSS WG.
The problem I have with this change is best illustrated with the following
example.  Consider the following two style rules:

body button { ... }
#myHTMLDoc button { ... }

These rules are being applied to the following document:

<body id="myHTMLDoc">...</body>

I as a sheet author would assume that those rules are more or less equivalent. 
I would be very surprised to discover that the first rule loses to inline style
but the second rule beats inline style.  Both rules apply to every button in the
document.  Neither rule is designed to apply to just one content node.  Why does
one beat inline style when the other loses?

Furthermore, consider these two rules.

#foo { ... }
button#foo { ... }

The first rule loses to inline style because it has the same specificity.  The
second rule beats inline style because the tag name was specified.  Again, those
rules are more or less equivalent, and both apply to just one content node. 
Suddenly because I qualified the tag name, the rule starts beating inline style?

This is just completely illogical to me.  I honestly don't even see the other
side of this argument.
> There is one thing that occurs to me, which is that nobody knows what following
> the spec in this fashion would really mean since nobody's ever done it.

This assertion is false ; most SVG viewers implement the specificity of the style
attribute has it is in the spec. As Chris Lilley, chairman of both CSS and SVG
Working Groups pointed it out, SVG needs this specificity to be (1,0,0) and that
is one of the reasons why the CSS WG cannot/will not change the spec.
Why does SVG need this?
I don't know why SVG needs this, since I've never really gotten that part of the
debate, but I can show you the logic behind supporting the CSS definition of
inline specificity.  The specficiation defines inline styles to have a
specificity of 1,0,0.  By defiition, the specification is correct until it's
been changed through an errata, at which point it's still correct, just
differently.  If you're going to make a big deal out of standards support then
in for a penny, in for a pound.

As for not being able to see the other side of the argument, I can't help you
there, but I suggest you try if only for the sake of expanding your horizons.  I
fully understand your position on inline specificity, and personally I agree
with it.  Sadly, neither of our opinions constitutes a change to a published
specification.  It just means that, like people who refuse to accept that
'width' and 'height' define the dimensions of the content-area of an element
instead of its visible components, we think the specification should be changed
and get frustrated when that doesn't happen.  Thus we have a choice: eat our own
"we support standards correctly" dog food, or willfully violate a five-year old
specification just to suit our personal preferences.
> > There is one thing that occurs to me, which is that nobody knows what
> > following the spec in this fashion would really mean since nobody's ever
> > done it.
> This assertion is false ; most SVG viewers implement the specificity of the
> style attribute has it is in the spec. As Chris Lilley, chairman of both CSS
> and SVG Working Groups pointed it out, SVG needs this specificity to be
> (1,0,0) and that is one of the reasons why the CSS WG cannot/will not change
> the spec.

Most?  I wrote some tests, and with Ian's help tested 8 SVG viewers.  Of those,
1 implemented what the CSS spec said, 5 implemented what we do, and 2 did not
implement CSS well enough to distinguish between the two based on the test I wrote:
David : I have no personal interest here !-) I was just repeating what I heard
the chairman of the Group say in a conf call some time ago.
Interesting data.  Were you planning to point it out to the WG or on the public 
mailing list, or is it not even worth it?  On the other hand, if Adobe, 
Macromedia and Mozilla are conformant, more will probably follow.

>If we could get a build which is in perfect conformance on this point, we could >use it to surf around the Web and see what (if anything) breaks on the change.

We are unlikely to see any problems just by surfing around since we decided to 
follow the spec in strict mode only.

You introduced some confusion in your example with "body button" and "#myHTMLDoc 
button" because there is only one body within a document.  Change the example to 
"div button" and "#myDIV button" and the perspective is completely different.  
Both selectors should definitely not have the same weight.

Ian made a similar objection and Daniel's response was:
Besides the templates mentioned by Daniel, it also allows authors to easily 
restyle pages that have many style attributes.

About your second example with "#foo" and "button#foo", one could say the same 
thing about "#foo" and "#foo[bar]".  Both apply to a single element.  Still, 
there is a reason why adding an attribute or a tag increases the specificity of a 
I don't deny that the specificity is naturally increased by the addition of
extra selectors.  I'm just arguing that it's counter-intuitive that such small
additions to a rule's selector would cause the rule to be more specific than
inline style.

It seems odd to make such a dangerous change.  This would be a divergence from
all other browsers, from Opera to IE.  If we're the odd man out, we run the risk
of being the "broken browser."  Don't expect people to understand any arguments
we make to defend ourselves.  They'll sound just as illogical to Web developers
as they do to me.
It won't be the only feature in strict mode that we will have right and the other 
browsers will have wrong, we are still committed to be standard-compliant.  The 
debate over the pertinence of the spec happened several times already over the 
past couple of years and the decision was maintained.  That's why nobody here who 
is or has been involved in the WG, 6 persons all with different degrees of 
support of opposition to the spec, seems to be willing to debate it one more 

The approach should be: "there is a patch, let's make sure it is sound".  I'll 
post an update that takes into account the comments from waterson and dbaron.

It came to my mind that a reason that might have pushed to the adoption of the 
spec as it is is the possibility that authors always have to override the style 
of any element by adding a declaration in an external stylesheet (one can always 
define a selector with a higher specificity).  Maybe they did not want inline 
style rules to be the exception.
> It came to my mind that a reason that might have pushed to the adoption of the
> spec as it is is the possibility that authors always have to override the
> style of any element by adding a declaration in an external stylesheet (one
> can always define a selector with a higher specificity).  Maybe they did not
> want inline style rules to be the exception.

It's not always possible thanks to this, since it's not possible to override
inline style on an element that doesn't have an ID attribute.  (It is always
possible through !important, though.)
(Actually not even that if the inline style attribute has !important
Sorry, I wasn't very clear and I had this particular example in mind...

The spec allows authors or editor applications to add IDs everywhere without 
modifying the appearance of the page, then work on an external stylesheet to 
override any style they want (including inline style) and put the stylesheet 
online when it's ready (or even link it to the page under certain conditions).  
During that time, they can continue to update the textual contents of the page 
without hurting the development of the stylesheet.

If inline style has an infinite specificity, there is no smooth upgrade path: 
they have to rewrite the page all at once.
> That's why nobody here who 
> is or has been involved in the WG, 6 persons all with different degrees of 
> support of opposition to the spec, seems to be willing to debate it one more 
> time.
> The approach should be: "there is a patch, let's make sure it is sound"

I support both the analysis and the conclusion
AFAICT there are two camps of opinion here:

1. The spec wasn't well thought through on this issue, so we ought not
   rush to implement it. (``If it ain't broke, don't fix it.'')

2. The spec has withstood several rounds of discussion on this point
   and has not been changed, so we ought support it. (``In for a penny,
   in for a pound.'')

It doesn't seem like any real headway is being made at this point -- unless
pierre, glazman, and emeyer have worn hyatt et. al. down. Ought the interested
parties get together and try to arrive at a consensus?

My $0.02: emeyer, although in for a pound, says that the real impact of this
change is unknown. I think we can safely assume that the latency for uncovering
``problem'' websites will be high (say two months). Although it was claimed that
SVG needed this, dbaron and hixie discovered that several SVG viewers don't
properly support it anyway. (Furthermore, it's likely that our first round of
SVG support will be entirely based on a plugin, which wouldn't use our style
system anyway.) Given the predicament of our current market share, compatibility
is king: let's not strike a bold posture with (what appears to be) a marginal
feature that may put compatibility at risk.
Ok, my turn.

Let me summarise the arguments here. PRO lines are the arguments for following
the spec as is, CON lines are the arguments in favour of changing the spec.

PRO: The spec is there, let's not change the status quo.
CON: We have ample precedent for changing the spec if it is wrong.
CON: The status quo is that browsers don't implement the spec on this.

PRO: SVG user agents do this per spec, let's not change it out from under them.
CON: The majority of SVG user agents do not do this per spec.

PRO: SVG needs this.
CON: This is a statement without any logical supportive argument.
CON: SVG is not any different from XHTML when it comes to the cascade, and
  XHTML doesn't need this.
CON: Authors in the real world find the spec illogical in this regard and
  prefer that the style attribute be its own distinct cascade level.

PRO: The spec allows external stylesheets to always override the style
  attribute without changing the document.
CON: Not if there is no ID on the element or its parents.
CON: Normal style attribute rules can be overriden by !important external rules
  regardless of cascade.

PRO: If inline style has an infinite specificity, there is no smooth upgrade
  path: they have to rewrite the page all at once.
CON: This is incorrect as one can use the !important specifier to override
  all normal style rules without even using an ID.

PRO: The spec allows external stylesheets to always override the style
  attribute, even if this means adding ID attributes.
CON: If you can change ID attributes you can change style attributes (e.g. at
  a minimum to remove !important specifiers and thus allow external rules to
  override style attribute rules).

CON: The spec causes a physically separated style rule to become merged in with
  the cascade at an arbitrary level, confusing authors.
PRO: The position is very logical if you consider the style attribute to be
  equivalent to pointing out an element by ID.
CON: This fails if you consider the case of a rule which has an ID as an
  ancestor selector instead of the subject of the selector -- this rule, which
  points to multiple elements, still beats the style attribute.

CON: There are web pages that rely on the non-spec behaviour.
PRO: That's why we have quirks mode.
CON: There is a distinct risk that implementing this per spec will break 
  existing web content.

CON: This will break chrome.
PRO: We can put chrome in quirks mode.
CON: That would be the wrong thing to do, as chrome is XML and XML should be done
  correctly in all cases.

CON: This will badly affect footprint because style attributes will no longer be
  leaf nodes in the style resolution tree.

CON: This may affect DHTML optimisations since style rules will have to be merged
  with the author level of the cascade instead of being their own level.

Given the above arguments, including the fact that some of them have come to
light as new arguments since the last debate within the working group (in 
particular the details regarding performance and SVG implementations) I suggest
that the Netscape representative raise this in the working group as an issue
which should be changed in the specification. As I understand it, at least
three Netscape employees strongly believe the spec should be changed, at least
one believes it should be changed (but not as strongly) and two either claim no
opinion or believe we should implement the spec as is. I shall leave it up to
the Netscape W3C reps to therefore decide what the Netscape position should be.

My personal position, as invited expert, is that the spec should be changed.
Whiteboard: [fix in hand] (py8ieh:0x0000g0 vs 0x000100) → [fix in hand] (py8ieh:0x0000g0 vs 0x000100) WG
The argument about using !important was flatly dismissed last year.  The 
arguments that are related to Mozilla's chrome, footprint and DHTML optimizations 
cannot be brought up to the WG.  

The objection should be along the line:
1) Authors in the real world find the spec illogical.
2) The majority of bowsers and SVG user agents do not do this per spec (see
3) We recently developed a fix but we don't want to make it part of the product 
if other organizations don't commit to support the spec.
4) If no other organization commits to it, the spec should be changed.

I think it would be a sensible way to bring up the topic a last time.  If 
Netscape people agree with that, I'll post the message.  Experts' opinions are as 
always most welcome (thanks for the summary, Ian).
Target Milestone: mozilla0.9.5 → mozilla0.9.6
After considering Ian's points and the state of browser and SVG implementations,
I'm going to retract my previous position.  We should NOT, in my personal
opinion, change the specificity-handling behavior of Mozilla at this time.  This
is not worth fighting the tide of every other implementation out there, despite
the violation of the spec.  We'll work to get the spec changed, or else get
other implementors to agree to follow the spec.  Hopefully one of the two will
actually happen (and personally I continue to hope it's the former that happens).

One more technical case that hasn't been mentioned.  

Suppose you have the following in a sheet:

/* Establish initial position of my div. */
div#foo {
  position: absolute;
  left: 10px;
  top:  50 px;

Now in your script in the Web page, you write a function to move the object:

function moveDiv(myDiv, newLeft, newTop)
  // Set my new left position = newLeft; = newTop;

The above code will fail because the specificity of the rule in the sheet beats
inline style.  I do not see how anyone could look at this example and still
stand by the position that the style attribute's specificity should be lowered.
 What I've shown is a widely-used piece of code that would have to be changed
should we choose to implement this "feature".

The spec is definitely not a collection of "features" that we "choose to 
implement or not" but that example looks to me as one big nail into the coffin.  
Why didn't we think about it earlier?  :-)

Closed: 23 years ago
Resolution: --- → WONTFIX
Are you taking that example to the CSS WG so they can mull it over and fix the spec?
The discussion moved to the WG (thanks to DBaron):
You need to log in before you can comment on or make changes to this bug.