- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 14 Jul 2008 17:37:53 -0500
- To: "Andrew Fedoniouk" <news@terrainformatica.com>
- Cc: "Joshua Cranmer" <Pidgeot18@verizon.net>, "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, www-style <www-style@w3.org>
On Mon, Jul 14, 2008 at 4:52 PM, Andrew Fedoniouk <news@terrainformatica.com> wrote: > Tab Atkins Jr. wrote: >> >> On Mon, Jul 14, 2008 at 4:17 PM, Joshua Cranmer <Pidgeot18@verizon.net> >> wrote: >> >>> >>> Tab Atkins Jr. wrote: >>> >>>> >>>> I agree here, though, that *without* a :scope or :context pseudoclass, >>>> it can be difficult to achieve proper modularity. Frex, in this >>>> fragment: >>>> >>>> <section> >>>> <style scoped> >>>> div span { color: red } >>>> </style> >>>> <span>span content</span> >>>> <div> >>>> <span>some more span content</span> >>>> </div> >>>> </section> >>>> >>>> The second span will definitely be red, but the first will be red >>>> depending on whether or not there is a div somewhere further up the >>>> ancestor chain. >>>> >>>> >>> >>> This sounds as if it's a bug. As developer, I would intuitively expect >>> such >>> a document fragment to have the same results regardless of extra content. >>> Whether or not the section is wrapped in a div or not should not (IMHO) >>> affect the styles generated by the scoped stylesheets. I fail to see a >>> compelling use case that calls for the scoped stylesheets to be >>> knowledgeable of the existence of any elements outside the scoped root >>> (e.g., the section). >>> >> >> Being able to do a query against the full document *is* useful, but >> you need some way to specify that you want a selector to *only* query >> against the elements in scope, or you get the unintuitive results that >> you mentioned. That'd be the :scope/:context pseudoclass. >> > > That will lead to requirement to prepend practically all style rules in > scoped style sheet with the :context > modifier: > > <div> > <section> > <style scoped> > :context div span { color: red } > </style> > <span>span content</span> > <div> > <span>some more span content</span> > </div> > </section> > </div> If you have no other way to unambiguously match, then yes. However, this sort of ambiguity won't often apply. Using an #id somewhere will scope the selector unambiguously (as the matching element can only occur once in the document), as will several of the other compound selectors, like the child selector. > > That implies that style systems inside <style scoped> and <style> shall use > different CSS "vocabularies" or flaws. > This pretty much means that you cannot share your style declarations between > standalone and embedded version > of your <section>. That also means that <style scoped> only implies of use > of inline styles. > <style scoped src="..." /> will become a nonsense - you cannot reuse the > same scoped style for different > sections even on the same page as they may contain position dependent > selectors. Yes, that's the point of global matching - that you *can* make position-dependent selectors and use them in several different positions. Using :scope/:context in the front will guarantee that your selector is *not* position-dependent, if you wish (and your selectors are sufficiently ambiguous to require them). Personally, I use something very similar on my pages anyway. I have a css file of global styles that apply to all pages, and then a separate css file of all the style rules that apply to individual pages. My site templates are set up so that the content of each page is within a uniquely-id'ed container, so that I can prefix each page's set of rules with the appropriate #id. This ensures that they (a) don't leak out and wreck the template around them, and (b) they don't interfere with some other page. What I'm saying is, prefixing rules with a specific selector to ensure they match correctly isn't something weird or a flaw. It's already a common practice, as I'm sure others do something similar to what I do. This proposal wraps it in a bit of syntactic sugar, and allows end-users to apply this technique even when the site author doesn't specifically cater to them. The <style scoped> attribute has the additional benefit of sandboxing the rules so they won't alter the non-scoped content, as explained previously. > If you do need global selectors use standard approach - put your styles in > global scope. And they will work. > The beauty of scoped style sheets is in the fact that they are scoped per se > - can be applied to the scope > elements independently from positions of these scope elements in the DOM > tree. > CSS simply does not allow you to do such independent isolation now. That doesn't help you when you want to hook selectors off of higher-up things but still only apply the rules within the scope. The previous example of styling <h1> differently based on the style of the body is one example of this. Philip TAYLOR (Ret'd) <P.Taylor@rhul.ac.uk> wrote: > Good Lord, I finally understand what all this debate is about. > Thank you, Tab ! Heh, you're welcome. I aim to please. More specifically, I aim to make my writing as clear as possible, especially when I notice confusion in others. Joshua Cranmer <Pidgeot18@verizon.net> wrote: > I don't see how it's useful--I would like a real-world-ish example. Certainly. Say you have a blog, and want to apply certain styles to your post. However, your blog has a different theme in different sections. Frex, the current "Latest Post" showing on the front page has large, flashy headers, while the same post viewed on its own has normal headers, while the same post viewed in a list of archives has a smaller, underlined header (so as to not be so distracting). You can achieve all of these in the same scoped stylesheet by selecting against #ids higher in the document and styling appropriately. This may not be the best example (this is likely a consistent style question that should be answered by a document-wide stylesheet affecting *all* post headers on the given page...), but consider more special-case operations. Say you have an image in your post that you don't want to show on the front page (it's large and would crowd out the text). Hiding images in your Front Page post isn't a general rule, it's something you want to special-case for this one post, but you want it to show in other views. Here being able to select against the entire document proves very useful. Basically, *any* time you have one-off styling that you want to appear different in different contexts.
Received on Monday, 14 July 2008 22:38:33 UTC