[whatwg] @font-face rules in <style scoped>

I'm implementing <style scope> for WebKit at the moment, so please allow me
to add my take to some of the issues raised (although I certainly don't
claim to be an authoritative source of insight! ^_-). Comments inline:

On Sat, Nov 19, 2011 at 10:11, Daniel Glazman <
daniel.glazman at disruptive-innovations.com> wrote:

> Le 18/11/11 23:40, Ian Hickson a ?crit :
>
>  I'm happy to add clarifying text or an example to the spec if that would
>> help.
>>
>
> [cc to www-style, reply-to to www-style ]
>
> Wow, wow, wow. Slowly please.
>
> I think you should discuss that in www-style before any addition to
> html. The complete mechanism for handling scoped stylesheets will impact
> us strongly.
>
> In particular, the scoping of at-rules has NEVER ever been
> discussed with the CSS WG. If scoping @media would not be a problem
> in most cases, scoping @font-face could be an issue for rendering
> engines unable to maintain more than a document-wide list of font
> matchings at this time, ie the current state of CSS.


How to best implement scoped @font-face is indeed an issue I'm facing at
the moment. @keyframes is another.




> I don't even
> want to discuss scoping CSS Variables at this time...


With the new variables proposal, scoped variables shouldn't be an issue at
all.


How can
> we access the list of stylesheets - including scoped ones - affecting
> a given element?


If that becomes necessary, it probably would require a new interface, e.g.,
document.styleSheetsForElement(<element>).



> How is "scoped" reflected in the CSS OM?


I'm not very familiar with CSS OM, but my guess would be: not at all, as
the contents of the style-sheet are not affected per se.


Are scoped
> stylesheets visible from document.styleSheets?
>

Yes (why not?).


What's the precise mechanism for the resolution of styles ? Does
> a scoped style "override" a global one that is set "deeper" in
> the subtree ?
>
>  <div>
>    <style scoped="true">p { color: black }</style>
>    <div>
>      <style>p { color: red }</style>
>      <p>black or red?</p>
>    </div>
>  </div>
>
> (I've always said that scoping should imply a specificity increased
>  by an ID selector's specificity, and that's why I still think the
>  p above should be black ; I know others have expressed a different
>  opinion)
>

I disagree! Apart from the changes selector matching behavior, why should
<style scoped> be treated differently? This would just add unnecessary
complexity, and be rather arbitrary IMHO (why add an ID specificity and
not, say, class specificity? why not make the rules "!important" instead?).

If you want to add such a mechanism, I'd rather suggest to add it
orthogonally to <style scoped>, e.g., via an additional attribute:

    <style important>
    <style scoped important>


Cheers,

- Roland


Seen from the CSS WG, the way the scoped attribute works is totally
> undefined and the four little paragraphs contained in the html spec
> are helpless. I don't think this is "ready for implementations"
> as annotated in your spec; it's vastly underspecified.
>
> </Daniel>
>
>

Received on Monday, 21 November 2011 20:12:12 UTC