[go: up one dir, main page]

Re: [CSSOM] Searching/Navigating stylesheets

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.

>> 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?

>> 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.

Well, "last" would be the one that affects the element you care 
about.... modulo !important, of course.

>   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.

Right.

> 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....

>> 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).

> 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>

?

> 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...

> If the content preceding the colon matches the property-name production

That's a pretty fundamental assumption, yes.

-Boris

Received on Monday, 11 April 2011 22:34:35 UTC