Re: Procedural (non-technical) point about freezing the cat and hat combinators before they've even been defined (was Re: Shadow DOM: Hat and Cat -- if that's your real name.)

On Wed, Feb 5, 2014 at 10:58 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 2/5/14 1:47 PM, Dimitri Glazkov wrote:
>> On resolving outstanding issues: absolutely. The spec work doesn't stop
>> just because there's an implementation in the wild.
>
> That depends on whether the implementation is willing to adjust as the spec
> changes.  Historically UAs have not been terribly willing to do so, though
> some have been more willing than others.
>
>> My assessment of the remaining open spec bugs is that they all can be
>> addressed as evolution
>> of the current Blink implementation.
>
> Without breaking compat in the process?  Or will Blink be willing to make
> such breaking changes?  That's the part that is least clear, esp.
> considering the original mails in this thread explicitly talked about some
> breaking changes Blink would not be willing to make.

I don't know how much you've followed Blink's development in the past
year, but the project has turned out to be willing to change things to
a degree that I find personally shocking (in a good way).

In the past, compat pain was mostly about how we *felt* about it -
nowadays, Blink practice is to just drop a UseCounter on it, wait a
few weeks for data to come in, and then make a relatively informed
decision.  We have policies (kinda vague, but better than nothing)
about how much compat pain (in terms of web usage) we're willing to
accept in a change. (I think our limit is currently somewhere around
0.03% usage for dropping legacy crap.  The relevant numbers for other
categories of changes are less defined, just because we haven't had to
do them as often.)

Plus, we've been explicitly positioning things (through Polymer) in a
way that should hopefully let us be much more aggressive about pushing
changes.  Polymer (or the other major component-wrapping libraries)
can adjust to a lot of changes by just tweaking things internally, in
a way that doesn't break authors.

>> I think what Tab was trying to convey is the relative level of pain a
>> change in the API causes. For example, it's relatively easy to polyfill
>> and thus tweak DOM APIs.
>
> It's not really easy to polyfill the event path, unless I'm missing
> something?

I'm not aware enough of the details to be sure, sorry.

~TJ

Received on Wednesday, 5 February 2014 19:12:19 UTC