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

Re: [CSSOM] Searching/Navigating stylesheets

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 13 Apr 2011 10:35:43 -0700
Message-ID: <BANLkTimKsYvP-fDKOcCkd9TfJY=t-g7-aQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style list <www-style@w3.org>
On Tue, Apr 12, 2011 at 9:46 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 4/11/11 4:55 PM, Tab Atkins Jr. wrote:
>> 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.
> If browsers ship every 6 weeks, then we probably learn that there is a
> problem after two releases have shipped...

And then we can fix it 6 weeks later, rather than a year or two later. ^_^

>>> 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.
> We can, sure.  But if all the use cases for one are also use cases for the
> other, then we should ask ourselves whether we need a web API for the former
> if the latter won't be doable with web APIs anyway.

So you're arguing that disabling rulesets is possibly reasonable for a
web API, but disabling individual properties is probably only useful
for full-on editors which will need specialized non-web-facing APIs
anyway, so can just put the functionality in the latter APIs?

>> 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.
> Really?  I'm not aware of any offhand....

For example, assume you're defining some sort of ruleset nesting, like this:

div {
  color: red;
  font-face:hover a a a a a a a a a {
    color: blue;

The intention here is that this desugars to:

div { color: red; }
font-face:hover a a a a a a a a a { color: blue; }

But to the parser it *looks* like you're just setting the font-face
property (to a font name starting with "hover a a a..."), up until the
point the { is seen, at which point you have to backtrack an arbitrary
amount.  This is apparently a problem, given how much effort we spent
on trying to eliminate arbitrary backtracking from url() and comment

Received on Wednesday, 13 April 2011 17:36:32 UTC

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