Re: Proposition to change the prefixing policy

On Sat, 05 May 2012 12:20:38 +0200, Daniel Glazman  
<daniel.glazman@disruptive-innovations.com> wrote:

> (not quoting a so long message)
>
> Florian, I think your proposal has one flaw only but that's a pretty
> big one... We introduced prefixes originally to be able to have preview
> implementations potentially differing from the final spec and
> implementations. Prefixes were supposed to allow vendors to start
> implementing, test, discover issues and hence feed the standardization
> process.

That's an important point indeed, since that's what prefixes were indeed
made for in the first place. But I don't think my proposal comes off
that badly compared to the reality of the current system.

When it comes to providing feedback to the standardization process, I think
my proposal actually has some very nice properties. Since the vast majority
of uses of prefixes would be to work around bugs or inconsistent behavior,
trivially simple crawls (think wget and grep) could be used to discovers
areas where interoperability is weak.

Based on that, we could focus TCs writting efforts on things where browsers
are actually bad at following the spec, or identify areas of the spec where
behavior is undefined despite being important to authors.

> If preview implementations are aliased without prefix, they
> will be adopted by web authors, and sometimes _widely_.

Prefixed implementations already getting widely adopted. Having them
unprefixed shouldn't make much of a difference when there is a single
implementation, or several incompatible implementations.

If there are several interoperable implementations, then yes, usage
could get more massive than it is today, as using the feature would be
less painful than today. But would that really be a bad thing?

Yes, it would somewhat constrain what we could do about it. But I don't
have strong feelings about being constrained about what we can do to
massively popular and interoperable features. We might have to settle
for good enough solutions instead of chasing perfect ones, a bit more
than we do today. "It's not exactly how I wish it was, but I can live
with that" is usually something I like to hear.

> Some browser
> vendors said they just cannot let web sites suddenly become broken
> when an implementation changes following spec changes. That concern
> remains. If property A is implemented prefixed AND unprefixed at date
> d, and the spec for that property changes at date d+1, how will vendors
> update their implementation AND preserve sites implementing date d's
> draft from breakage?

We already have that problem, due to the fact that is is considered a
best practice for authors to preemptively include the unprefixed variant
alongside the prefixed ones. When we ignore that reality, it reinforces
the problem of vendors finding them selves unable to drop prefixes. If
the prefixed variant has been frozen, and the unprefixed one has not,
the large number of web sites that contain both, using the same values
for both, would break if the prefixed property was dropped.

In that respect, I don't think what I propose would constrain
experimentation more than what we have today. It might just
make these constraints more visible, as vendors would come
back to the WG *while they implement*, saying "we can't do that,
it breaks too many sites", rather than years later when they
try to drop the prefixes and discover that same incompatibility,
at which point it is too late to back-peddle.

  - Florian

Received on Monday, 7 May 2012 12:28:32 UTC