Bug 19874 - Drop scoped stylesheets
Summary: Drop scoped stylesheets
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Edward O'Connor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 19995
  Show dependency treegraph
 
Reported: 2012-11-06 09:16 UTC by Daniel Glazman
Modified: 2013-02-12 19:35 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Glazman 2012-11-06 09:16:53 UTC
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
Comment 1 Boris Zbarsky 2012-11-06 16:20:41 UTC
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.
Comment 2 Sam Ruby 2012-11-06 16:59:16 UTC
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
Comment 3 Daniel Glazman 2012-11-06 17:51:09 UTC
(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.
Comment 4 Daniel Glazman 2012-11-06 17:53:26 UTC
(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.
Comment 5 Sam Ruby 2012-11-06 18:10:04 UTC
(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
Comment 6 Tab Atkins Jr. 2012-11-15 07:52:57 UTC
(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.
Comment 7 Edward O'Connor 2013-02-12 19:35:22 UTC
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!