Re: [CSSOM] Searching/Navigating stylesheets

On Mon, Apr 11, 2011 at 3:34 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 4/11/11 3:25 PM, Tab Atkins Jr. wrote:
>>
>> 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.
>
> I should note that this call pattern reduces web compat risks compared to
> adding new short-named properties on elements.  For example, we've already
> had a number of web compat bug reports on Gecko from adding .list on form
> controls.

Yeah, compat's always an issue.  I'd prefer trying for the (imo)
better API first, though, and only giving up and switching to the
version on window when we learn that there's a problem.


>>> 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
>> useful?
>
> Consider this testcase:
>
> <style>
>  div { color: purple; }
> </style>
> <div>
>  <span id="x">Some text</span>
>  <script>
>    alert(document.getElementById("x").rules("color").length)
>  </script>
> </div>
>
> Does the alert show "0", as I would expect?  If not, why not?

Ooh, good point.  I'd previously thought about this, but forgot to
include it here.  It would be useful to expose where the inherited
value is coming from, though I'm not sure what the best form is.  I
have a few ideas:

1. Expose a readonly virtual style that includes all the inherited
styles.  This always appears last in the list, as inherited styles are
less specific than any property directly applied to the element.

2. Expose the ruleset on the ancestor that produces the value that
would inherit.  This only really makes sense when you're requesting
the rules that apply a particular property, not the one that grabs all
the rules that apply to an element.


>> For cross-domain stylesheets, same answer - they'd be ignored for the
>> purpose of this function.
>
> OK.  I think this is going to make this API very very fragile, esp. whenever
> a CDN is involved....

The current hacks that depend on the CSSOM are equally fragile, unless
they get around the issue by using a server-side proxy.

CORS could presumably fix the issue, opening a CDN'd stylesheet to be
read by a page.


>>> 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.
>
> I'm not sure we need to burden the core CSSOM and style system with that
> edge case, though.  The number of such editor implementations in the world
> is _very_ small, and they all rely on non-public APIs and will continue to
> do so (e.g. they do need to show the cross-site style rules).

Hm, possibly.  The two concepts are separable, so we can talk about
them separately.


>> 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.
>
> And if you have:
>
>  <div style="foo & bar: baz"></div>
>
> ?

Dropped (and not exposed as an invalid property), as the part
preceding the colon doesn't match the property-name production.


>> The additional parsing rules should be relatively trivial - just split
>> the invalid content at the first ':'
>
> Modulo parens, etc, etc, etc, right?
>
> Note that this could still break depending on what CSS syntax looks like in
> the future...

Yup.  While there's no guarantee we won't change syntax in the future,
we are rightfully pretty conservative on this matter.  Particularly,
there are performance reasons to not expose new syntax that looks like
a property-name/value pair.

~TJ

Received on Monday, 11 April 2011 23:56:06 UTC