Re: [cssom] Unrecognized - request for more information

>
> re-posting this because the formatting got messed up and it was
unreadable...



Oops, that is my fault. Fixed. Thanks!
>
> Should we move this to [cssom] then?


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?


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