- From: Glenn Maynard <glenn@zewt.org>
- Date: Sun, 17 Feb 2013 11:35:46 -0600
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: whatwg@whatwg.org
On Mon, Jan 21, 2013 at 8:39 AM, L. David Baron <dbaron@dbaron.org> wrote:
> But I think it's a large amount of extra implementation complexity
> to honor @-rules whose purpose is to build global dictionaries (in
> particular, @keyframes and @font-face), and I suspect the end result
> of honoring them would yield technology that's more confusing for
> authors. Anything that can be done by changing the meaning of an
> @keyframes or @font-face rule within a subtree could also be done by
> declaring a different animation rule or font-family within that
> subtree. I suspect the extra clarity from the latter makes it a
> better authoring practice anyway, so I don't think implementations
> should be required to add support for a feature that it's better to
> not use.
>
You could make the same argument against most of @scoped: you don't need to
define a scoped style for a class, just use a different class name.
It seems more likely that you'd want to use this for font-faces or
keyframes so that you can be sure the name won't collide. For example, a
templating system might output
<div>
<style scoped>
@font-face { font-family: "font"; src: url("font.ttf"); }
</style>
<span style="font-family: font;">content</span>
</div>
where the font URL is dynamically generated and the span is entered by the
user, who's been told that the font-family "font" will be defined to
something. The template doesn't need to worry about colliding with a
font-family by that name elsewhere (including other instances of the same
template or elsewhere in the document).
I don't know about implementation complexity (though I don't know why
creating a stack of font-face dictionaries would be any more complex than
creating a stack of style rules), but I don't think this is any more
complex for authors than the rest of @scoped.
--
Glenn Maynard
Received on Sunday, 17 February 2013 17:36:12 UTC