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

Re: [CSSOM] Searching/Navigating stylesheets

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 12 Apr 2011 21:46:06 -0700
Message-ID: <4DA52A8E.5030609@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
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...

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

Yep.  But no one really expects better from current CSSOM, so there 
isn't much disappointment.

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

That might be the way to go, yes.

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

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

Received on Wednesday, 13 April 2011 04:46:49 UTC

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