Re: [cssom] Unrecognized - request for more information

On Tue, 26 Jul 2011 08:41:41 -0700, Brian Kardell <bkardell@gmail.com>  
wrote:
> Sorry for the topic confusion - but here's why against my better  
> judgement I posted to cssom-view... CSSOM draft says:** [...]

Oops, that is my fault. Fixed. Thanks!


> It kind of sounds to me like what you are saying is that it is likely to  
> be dead on arrival, but here are some comments/food for thought anyway  
> just in case.
>
> On point #2: "The main problem with doing this is how this works together
> with grammar-generated parsers."
> I can appreciate the fact that this wouldn't be automatically handled by  
> the existing parsers, and this is probably the best argument... But it  
> seems to me that it's not necessarily so difficult to add something that  
> gives us
> "just enough" without over-complicating things.  The parsers are already
> smart enough to ignore bits if they don't understand them -- all we   
> would really need here is to collect them and provide some basic subset  
> of the
> parse on them (selector, module, property, value(s))...  The parsing  
> aspect could probably be done on request rather than upfront too..  
> Perhaps this is wrong, but maybe someone else could chime in and give  
> their thoughts.

The main problem here is getting this defined in sufficient detail. I.e.  
that for each error (these are errors) each parser collects an identical  
sequence of characters.


> On point #3:  "Inheritance, cascade, etc. will not function so there is
> still a lot that would have to be implemented by scripts."
> True enough, but currently they have to do them all.  This would be one  
> less - and to be clear, it's a big thing.  Comparatively the others are  
> much
> closer to the kinds of things that are more easily accomplished via  
> existing libraries...

Okay.


> On Point #4: "If we expose this we run the risk that native  
> implementations
> of said properties will start breaking sites. Basically the problem HTML  
> is facing whenever it wants to introduce a new attribute or element."
> If a feature were implemented it wouldn't appear in this set because it
> would be recognized by the browser so no shim would have the chance to be
> applied.  Currently that's not how it works in any library I have seen -
> rather they depend on detecting some other related feature.  This seems  
> more straightforward.  I presume that you are saying that this may cause  
> a
> problem if the shim does not conform to the spec in a way that the author
> has come to rely on.  It seems reasonable to me to say that this adds no
> additional risk as people are currently trying to shim and that at least  
> to some extent this is not so very much different than how it is with
> namespaced in css modules, though with a good api here it might be  
> possible to shim more than just those.

Yes the problem would be when the library provides a different  
implementation from the standard one. We could work around this by instead  
making this some kind of extensible model.

E.g. only allow site authors to use properties prefixed with "web-" and  
only expose those to scripts.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 26 July 2011 16:08:08 UTC