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

Re: [cssom] Unrecognized - request for more information

From: Brian Kardell <bkardell@gmail.com>
Date: Tue, 26 Jul 2011 16:06:36 -0400
Message-ID: <CADC=+jcxPYw0pHfkPaD7FuAYqQf9=GC-6_kxUrUqe_mhrmXCGA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style@w3.org
On Tue, Jul 26, 2011 at 3:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Jul 26, 2011 at 12:00 PM, Brian Kardell <bkardell@gmail.com> wrote:
> > 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.
> > > Nothing especially, it just seemed like you were suggesting opening up vendor prefix to anything not already "taken" (http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords), which seemed like as good idea as any.

> What do you want to do with the other prefixed properties?
> > 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).
> This can be done currently by using a preprocessor to transform the
> experimental syntax into vanilla CSS.  Is there a problem with that?
> > > What I am describing here could be done with a pre-processor probably, but I don't think we're talking about the same thing.  For clarity - I'm not suggesting turing something into vanilla CSS - rather I'm suggesting for things that couldn't be turned into vanilla CSS (someone mentioned people really innovating and experimenting which is a good point).  The practical upshot of this is that it could be used to  solve the first problem as well without the need for prefixing (its mime type is not CSS) as well being more generally useful for people to innovate with creating ideas that follow the "things that look like rules" subset of basic CSS (forward compatible) grammar rules.

As I said earlier, that probably seems like a lot to ask (or maybe
'the most radical') but the thing I like about it is that it seems
simple  enough to implement and allows for lots of potentially neat
ideas to develop without really adding much that is "new" (I think).

The prefixing might be enough, but there are definitely some things
that it wouldn't help with (an unsupported selector, for example,
unless we could catch that too) and it seems like it encourages you to
potentially "mix" things with your css which might look like CSS but
maybe technically aren't.  The later approach separates those nicely.
Received on Tuesday, 26 July 2011 20:07:03 UTC

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