- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 12 Apr 2011 21:46:06 -0700
- 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.... -Boris
Received on Wednesday, 13 April 2011 04:46:49 UTC