19874 2012-11-06 09:16:53 +0000 Drop scoped stylesheets 2013-02-12 19:35:22 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified All All RESOLVED NEEDSINFO P2 normal --- 19995 1 daniel.glazman eoconnor bzbarsky eoconnor jackalmage mike public-html-admin public-html-wg-issue-tracking rubys public-html-bugzilla oldest_to_newest 77930 0 daniel.glazman 2012-11-06 09:16:53 +0000 It's proposed to drop scoped stylesheets because they are totally undefined on the CSS part. In particular, the way they integrate into the cascade, the specificity of scoped selectors, how web fonts are shared or variables passed, is *totally* undefined. Since it's very unlikely the CSS WG will have time to specify this in reasonable time for HTML5, even leaving the feature "at-risk" is useless and it's probably a better signal for the specification and the W3C to drop it for the time being. Warning, this does NOT say this feature is interesting and even important for the future (for copy/paste and shadow DOM in particular); it only says the feature is absolutely not ready for a CR. It also does not say the html part of scoped stylesheet is not defined, it says the CSS part is not... References: Already present in my comments on HTML5 LC in may 2011, strictly unaddressed by HTML WG. http://www.w3.org/2002/09/wbs/40318/html5-last-call-poll/results#xq4 TPAC 2012, CSS WG, monday morning, meeting with plh and HTML WG chairs http://logs.csswg.org/irc.w3.org/css/?date=2012-10-29 77955 1 bzbarsky 2012-11-06 16:20:41 +0000 I believe the cascade/specificity bit is actually well-defined, or at the very least there is a proposal everyone agrees on last I checked. I agree that fonts and variables are a problem that may warrant pulling this from the HTML5 REC. 77957 2 rubys 2012-11-06 16:59:16 +0000 I'll note that this is already listed on the features at risk page: http://www.w3.org/html/wg/wiki/index.php?title=HTML5.0AtRiskFeatures&diff=13639&oldid=13638 77962 3 daniel.glazman 2012-11-06 17:51:09 +0000 (In reply to comment #1) > I believe the cascade/specificity bit is actually well-defined, or at the > very least there is a proposal everyone agrees on last I checked. A "proposal everyone agrees" is not a REC or even a CR. And I am myself still unsure about the proposed specificity. More importantly, this discussion never happened seriously in the CSS WG (where such a technical discussion belongs) because the HTML WG never asked us to do so. 77964 4 daniel.glazman 2012-11-06 17:53:26 +0000 (In reply to comment #2) > I'll note that this is already listed on the features at risk page: An at-risk feature that is eventually dropped is "something we wanted, made public in CR and cannot afford right now". A feature dropped before that goes out of the radar. I am asking the pros and cons of both approaches to be discussed, not only technically but also in terms of public image for W3C. 77966 5 rubys 2012-11-06 18:10:04 +0000 (In reply to comment #4) > (In reply to comment #2) > > > I'll note that this is already listed on the features at risk page: > > An at-risk feature that is eventually dropped is "something we wanted, > made public in CR and cannot afford right now". A feature dropped > before that goes out of the radar. I am asking the pros and cons of > both approaches to be discussed, not only technically but also in > terms of public image for W3C. Perhaps this will be of use then: http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#cr-remove-early - Sam Ruby 78337 6 jackalmage 2012-11-15 07:52:57 +0000 (In reply to comment #1) > I believe the cascade/specificity bit is actually well-defined, or at the > very least there is a proposal everyone agrees on last I checked. It's now well-defined in the Cascade module: <http://dev.w3.org/csswg/css3-cascade/#cascade> > I agree that fonts and variables are a problem that may warrant pulling this > from the HTML5 REC. Variables are a non-issue. They're properties, and so scope just as well as anything else. For fonts, it depends. If we're willing to say "welp, those aren't actually scoped - they leak into the global font set", then it's easy. I've seen pushback in doing anything better. :/ We could do something like disable @font-face normally, only allowing it in an @host rule (which relaxes the scoping). @host still needs to be properly defined, of course. 83022 7 eoconnor 2013-02-12 19:35:22 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Additional Information Needed Change Description: No spec change. Rationale: It's not clear to me if this bug report counts as a nomination for early removal per §13 of the WG's Decision Policy: http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#cr-remove-early If Daniel or one of the Chairs could clarify, that would be great!