- From: Jens Meiert <jens@meiert.com>
- Date: Wed, 16 Jul 2008 13:17:39 +0200
- To: www-style <www-style@w3.org>
On Tue, Jul 15, 2008 at 12:50 AM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
>
> <html>
> <style>
> body #content p { color:red; }
> <body>
> <div #content>
> <style scoped>
> p { color:green; }
> </style>
> <p>what would be the color of this text?</p>
> </div>
> </body>
> </html>
>
> It appears as <style scoped> should always be more specific than rules in
> just a <style>.
> Yes/no?
Yes, shouldn't it.
Just brainstorming, but don't scoped styles only make sense when the
cascade is modified accordingly, especially when taking into account
the "page owner wants to override author styles that are out of his
control" scenario? And shouldn't it be considering rather impractical
to change the way specificity is calculated (n,n,n,n,n instead of
n,n,n,n), so that scoped styles might just require a different origin
[1], like
* user agent declarations
* user normal declarations
* author normal declarations
* owner or author 2 normal declarations
* author important declarations
* owner or author 2 important declarations
* user important declarations
I cannot tell what this actually means for implementations (on first
sight, it looks backwards-compatible), but it might help resolving
this issue.
On Tue, Jul 15, 2008 at 4:19 AM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
>
> Normal specificity rules will simply not work.
> To be able to overweight global styles you will end
> up with something like this:
>
> <style>
> body.foo #content p { color:red; }
> </style>
> <body>
> <div #content>
> <style scoped>
> body.foo #content p { color:green; }
> </style>
> <p>what would be the color of this text?</p>
> </div>
> </body>
Agreed, and wouldn't this drive scoped styles useless anyway, as
simply allowing "style" elements to be used within "body" would mean
the same? Given this case, @scoped should probably be dropped.
[1] http://www.w3.org/TR/CSS21/cascade.html#cascade
--
Jens Meiert
http://meiert.com/en/
Received on Wednesday, 16 July 2008 11:18:15 UTC