Closed Bug 62150 Opened 24 years ago Closed 23 years ago

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

Categories

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

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
mozilla0.9.6

People

(Reporter: pierre, Assigned: pierre)

Details

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

Attachments

(5 files)

back-up patch (don't review)
25.47 KB, patch
Details | Diff | Splinter Review
patch 1.0
29.20 KB, patch
Details | Diff | Splinter Review
testcase in strict mode
950 bytes, text/html
Details
testcase in quirks mode
857 bytes, text/html
Details
testcase in quirks mode without doc sheets
468 bytes, text/html
Details
The STYLE attribute is currently assigned an infinite specificity. This is done in nsHTMLGenericElement, line 214: cssRule->SetWeight(0x7fffffff); Following a discussion on the CSS WG mailing list: http://lists.w3.org/Archives/Member/w3c-css-wg/2000OctDec/0227.html Netscape and Microsoft should stop doing this and assign a specificity of (1,0,0) to the STYLE attribute as the spec says: http://www.w3.org/TR/REC-CSS2/cascade.html#specificity The proposed patch is, duh, to change the line above to: cssRule->SetWeight(0x100);
Status: NEW → ASSIGNED
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.
RichInStyle.com 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 RichInStyle.com. 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 document. 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.0 — — Splinter 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)? (twice) + nsCOMPtr<nsISupports> sheet(do_QueryInterface(aStyleSheet)); + NS_ENSURE_TRUE(sheet, NS_ERROR_INVALID_POINTER); 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. DBaron: - There are no new files. The patch is still valid on a pull from yesterday. Hyatt: - 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: http://lists.w3.org/Archives/Member/w3c-css-wg/2000OctDec/0239.html 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. http://www.people.fas.harvard.edu/~dbaron/css/test/sec060403b
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: http://www.people.fas.harvard.edu/~dbaron/css/test/sas/
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.
>>DBaron: 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. >>Eric: >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. >>Hyatt: 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: http://lists.w3.org/Archives/Member/w3c-css-wg/2000OctDec/0231.html 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 selector.
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 time. 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 declarations.)
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 http://www.people.fas.harvard.edu/~dbaron/css/test/sas/) 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 myDiv.style.left = newLeft; myDiv.style.top = 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? :-) WontFix.
Status: ASSIGNED → RESOLVED
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): http://lists.w3.org/Archives/Member/w3c-css-wg/2001OctDec/0037.html
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: