W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [CSSOM] Searching/Navigating stylesheets

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 11 Apr 2011 15:25:35 -0700
Message-ID: <BANLkTim_AV4JkM3JY=Li69yCNim+Vtn6ZA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style list <www-style@w3.org>
On Mon, Apr 11, 2011 at 2:44 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 4/11/11 12:57 PM, Tab Atkins Jr. wrote:
>> Possible Solution: Add elem.rules(), which returns a list of rulesets
>> (CSSStyleRule) that apply to the element, ordered by decreasing
>> specificity.
> Gecko sort of has this internally.  Webkit exposes this to web content, sort
> of.  See the discussion in
> https://bugzilla.mozilla.org/show_bug.cgi?id=438278

Yup.  getMatchedCSSRules exposes this information, but in reverse
order (least specific first), which is kinda annoying.  Plus, it has
same frustrating call pattern as getComputedStyle, where the function
is defined on window and takes the element as an argument.

> There are a bunch of open questions involving user/ua sheets, cross-site
> stylesheets, etc that need to be answered before exposing this sort of thing
> to web content.

Indeed.  I'd want to expose the information in UA/user stylesheets,
though perhaps in a readonly way.  Cross-site stylesheets are a
problem, unfortunately.  Probably we'd just have to omit that
information, and live with the fact that this means the info may be
incomplete.  There's a lot of things you can't do with cross-domain

>> Also, elem.rules(‘property’), which filters the rulesets
>> to only include ones which actually set the particular property.
> Note that this is not as useful as it may seem (e.g. elem.rules("color") has
> a good chance of not telling you anything useful).  It's not clear to me
> whether the usefulness outweighs the footgun potential.

Hm, I'm probably just being dumb here and missing something obvious,
but why does this have a good chance of not telling you anything

>> Possible Solution: Add an @id name; rule that can be added to
>> declaration blocks, and a document.ruleByID(name) function which
>> returns the ruleset with the given id.
> Or rather a ruleset with the given id; presumably one that comes last in
> cascade order?  Again, the question of what to do for cross-site stylesheets
> remains.

Not sure whether it should be the first or last thing with a given id.
 Getting the first matches HTML's multiple-id behavior, but getting
the last matches CSS's usual behavior when overriding things.  I
suspect grabbing the last is the better answer.

For cross-domain stylesheets, same answer - they'd be ignored for the
purpose of this function.

>> Possible Solution: Add a rule.disable() and rule.enable() to CSSRule,
>> and rule.disable(‘property’) and rule.enable(‘property’) to
>> CSSStyleRule, which “turn off” the ruleset or the specific property,
>> and turn it back on again.  This could possibly be reflected by a
>> !disabled value appended to the property.
> This makes sense to me for rules.  I'm not sure about doing it on a
> per-property basis...

Editors like Webkit's Inspector or Firebug allow you to shut down
individual properties in a ruleset.

>> Possible Solution: Allow declaration blocks to be selected with
>> Selectors.  A stylesheet is a root node, rulesets are children (some
>> types of rulesets, like media rules, can have more rulesets as
>> children), and properties are attributes on the ruleset.  You could
>> then easily find your custom property by doing something like:
> This involves the parser doing "something" with properties it can't parse,
> right?  I'm somewhat opposed to this.  If you can't parse it, you have no
> idea how to expose it properly.  I do note you considered this.
>> After all, the parser knows what the property's name was
> That's not necessarily true, no.
>> the error-handling implicitly looks for things that look like property
>> names and values so it can skip over them properly.
> No, the error-handling just looks for ';' not inside
> parens/brackets/quotes/etc.  It's pretty easy to create things that look
> nothing like allowed property/value pairs and that current CSS parsers skip
> over just fine; you'd need to define new CSS parsing rules to make this work
> at all.

Ah, kk.  Webkit's Inspector does indeed attempt to parse invalid CSS
as an unknown property/value pair, and displays it.  For example, if I
create a document with <div style="foo:bar;"></div> and inspect the
element, I'll see a "foo:bar" property there flagged as invalid.

The additional parsing rules should be relatively trivial - just split
the invalid content at the first ':'.  If the content preceding the
colon matches the property-name production, trim the whitespace off
both pieces and expose it as an invalid property.  Values are only
exposed as strings in current CSSOM, and we can decide whether to try
and be smarter about things when we decide on a more advanced CSSOM

(This could also be expanded to allow exposing custom @-rules inside
of blocks, once we allow that sort of thing.)

Received on Monday, 11 April 2011 22:26:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC