Re: [cssom] Unrecognized - request for more information

On Tue, Jul 26, 2011 at 12:07 PM, Anne van Kesteren <annevk@opera.com>wrote:

> 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!
>
 >>  Should we move this to [cssom] then?


>  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.
>
 >> Absolutely.  This is exactly what would have to be in such a proposal.
Doable though - right?


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

>> I think that it is mostly a red herring for a few reasons but maybe I
can't convince anyone on that point.  Here is my rationale for this:  1) It
is a non-issue by comparison with what we have today (ie, it isn't creating
a new problem or making the current problem worse) 2) It's already not the
case that the same module does exactly the same thing natively.  We have
even seen spots in the past where some minor ambiguity in the spec causes
two different, but technically conforming implementation.  The idea that it
is possible that a shim be implemented not quite in line with the spec is a
possibility - but there is also an advantage in that it is within the user's
ability to fix it without submitting a bug, hoping that it gets fixed and
waiting for the next release of the browser.  Even with the extensible model
there is the same problem going from shim to shim or version of shim to
version of shim.  Still, this is what people expect today, it's why we test
code, etc.  It's not perfect - but it's what seems to be working in the real
world.  I think you could say the same about CSS or HTML as whole...  3) An
extensible model had occurred to me and I had actually typed and then erased
the idea of something like "web-" or "shim-".  I guess it would be better
than nothing but a module might not be the only thing - right?  If we had
this kind of thing today we could (at least largely) make up for missing
selector or function support.   I agree - it probably wouldn't be perfect,
but again, most of the implementations being used today aren't either, but
they usually note their limitations and that's generally enough.  Or, I
suppose it would be possible to take it to the nth degree and develop the
ability to _be_ shimmed with perfect parity somehow - but I think that that
is actually a very difficult problem that would take years to work out.



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