Re: [cssom] Unrecognized - request for more information

Sorry for the topic confusion - but here's why against my better judgement I
posted to cssom-view... CSSOM draft says:**

The (archived <http://lists.w3.org/Archives/Public/www-style/>) public
mailing list www-style@w3.org (see
instructions<http://www.w3.org/Mail/Request>)
is preferred for discussion of this specification. When sending e-mail,
please put the text “cssom-view” in the subject, preferably like this:
“[cssom-view]"
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.

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

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.




On Tue, Jul 26, 2011 at 10:46 AM, Anne van Kesteren <annevk@opera.com>wrote:

> On Tue, 26 Jul 2011 07:37:21 -0700, Brian Kardell <bkardell@gmail.com>
> wrote:
>
>> It seems that toward the end of 2009 Mike Wilson asked for a rationale as
>> to why the ability to access unrecognized/dropped rules via CSSOM was
>> dropped:
>>
>> http://lists.w3.org/Archives/**Public/www-style/2009Nov/0285.**html<http://lists.w3.org/Archives/Public/www-style/2009Nov/0285.html>
>>
>> There are currently several projects and shim libraries in exactly the
>> situation he describes in his defense for retaining such an interface...
>> Personally I am not sure that that was the greatest interface anyway, but
>> it really would be great to have something _like it_.   Does anyone in the
>> relevant W3C group have any feelings on whether they could get behind a
>> good proposal to reintroduce some means of accessing at least "mostly
>> processed" meta-information already parsed by the considerably better and
>> faster native parser - or would it be likely to be DOA?
>>
>> It seems that this would drive CSS itself forward by leaps and bounds by
>> making it considerably more practical to use new features in a reasonable
>> time frame without unnecessarily complex gyrations by simply adding a good
>> shim.
>>
>
> 1) cssom-view != cssom
>
> 2) The main problem with doing this is how this works together with
> grammar-generated parsers.
>
> 3) Inheritance, cascade, etc. will not function so there is still a lot
> that would have to be implemented by scripts.
>
> 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.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>