That would go a long way IMO. You could let through all of the dash-prefixed properties and not limit it to web-* right? If so, you could allow the method that accesses it to provide a prefix filter. This might be too much to ask, but I think it would be possible to create a way for people who really did want to "experiment" as you are saying with true innovation with a CSS-like grammar in a way that couldn't mix with CSS... All that would be necessary would be to allow allow the parser "parse" but not respect a file via a mime type pattern or something (say like type="text/css-xxx"). Then could never overlap but people could take advantage of a good / fast native parser. This last approach, actually, could solve both problems fairly well and without much change - it would just require people to keep the "new" stuff in a separate sheet and use feature detection or something to determine which ones to shim (not unlike today). On Tue, Jul 26, 2011 at 2:36 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote: > Regarding unknown things that look like rules, WebKit parses and keeps > those things around and only filters for the recognized stuff later. > This is done so our Inspector can usefully flag invalid values for the > author. So, it wouldn't be difficult for us to expose them. > > However, I wouldn't actually want to do so. Allowing authors to > innovate in property names and values means we'll have much greater > compat risk when we introduce any new properties or values. It's > always possible for them to do so (for example, by XHRing the > stylesheet and parsing it themselves), but keeping it slow, expensive, > and difficult limits the spread of those methods. > > The idea of a web-* set of user-defined properties, though, seems > totally fine. That cordons off the potential damage into a space that > we can easily avoid in the future. > > Similarly, I don't think we should expose things that don't look like > rules either, for the same reason. > > ~TJ >Received on Tuesday, 26 July 2011 19:00:34 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:02 UTC