Re: Proposition to change the prefixing policy

Since we're throwing proposals out there...

I'd rather we do the same as http headers. Any experimental feature gets an
x-prefix instead of a vendor prefix. That does mean that x-prefixed
features that get wide adoption may need to be reverse engineered by other
vendors and can't be killed. In practice that's not much different from
what happens now. The x-prefix also means that web developers don't need to
wade through vendor-prefix soup. There may be some incompatibility between
different vendors x-prefixed implementations that will be a burden on web
developers and browser vendors, but the unprefixed version can be made
interoperable. In practice web developers already have to deal with the
same pain with incompatible vendor-prefixed implementations, but browser
vendors are more able to not feel responsible to address it.

In that world, removing the prefix at CR seems fine to me. It doesn't carry
any of the problems of long-lived vendor-prefixed properties and gives the
WG the necessary time to really solidify the spec before removing prefixes.

There's no perfect solution to this problem. But the downsides of
x-prefixing are much milder than the downsides of vendor-prefixing IMO.

Ojan

On Fri, May 4, 2012 at 5:32 PM, Rik Schaaf <coolcat_the_best@hotmail.com>wrote:

>
> I agree on the problems the current prefixes have, but in stead of browser
> prefixes, woulden't it be better to use draft prefixes like -beta1-flexbox
> or maybe -23july2009-flexbox? (which I think is not as good as beta1)
>
> This way browsers always know what draft you try to use. Even the newest
> draft would have such a prefix and the unprefixed version would refer to
> the newest (supported) draft
> Only when the draft reaches a point when it becomes CR, the prefix for
> this version could be left out (but doesn't have to be)
>
> When a browser sees a working draft notation which is hasn't implemented
> yet, like -beta3-flexbox in firefox for example, it could skip it, just
> like it would skip -webkit-flexbox
>
> A CSS file would look like this again flexbox as example:
>
> .flexbox Div {
>   /*newest version uses the word flex, older ones use flexbox and the
> first version uses box. order: from  oldest to newest*/
>   /*first betas can be left out once beta3 is fully supported. New
> versions wouldn't give any problem since the stylesheet only asks for
> beta1-5*/
>   Display:-beta1-box;
>   Display:-beta2-flexbox;
>   Display:-beta3-flexbox;
>   Display:-beta4-flexbox;
>   Display:-beta5-flex;
>   ...
> }
>
> Div > div {
>   -beta1-box-flex: 0.0; /*no negative flex or width support :( */
>   width:  -beta2-flex(1 0 10px);
>   width:  -beta3-flex(1 0 10px);
>   -beta4-flex: 1 0 10px;
>   -beta5-flex: 1 0 10px;
>   /*the browser will always look for the newest supported draft and will
> ignore the other betas. */
>   /* When you think: “this is too much, I can not support all those
> drafts!”, you can just skip betas but keep in mind that not every browser
> will support it. If that's a problem, you shouldn't use this property in
> the first place. */
>   ... /* other properties like -beta*-flex-pack / -beta1-box-pack or
> background-color */
> }
>
> In the case of flexbox it would be enough only to use beta 1, 3 (, 4) and
> 5 since they are used most by the browsers and the differ the most, but the
> easiest thing is just to copy/paste the whole list of the 5 betas.
>
> Any opinions/comments on this proposition?
>
> -Rik
>
> On 4 mei 2012, at 19:29, "Florian Rivoal" <florianr@opera.com> wrote:
>
> > Warning: long mail. If you want to skip the rationale, and just want the
> > technical proposal, jump down to "==== Proposal ===="
> >
> > ==== Background ====
> >
> > I believe the current prefixing policy is hurting more than it helps, and
> > that the problems are fundamental to the policy itself, rather than
> > something that can be blamed on various parties for not following it
> > correctly.
> >
> > While the current policy is very clear and simple to follow for browser
> > vendors, the same isn't true at all for authors. Unless the simplest
> > and most obvious way to use something is also the right way, it
> > is bound to be misused. Here we can't even agree on what the right
> > way is.
> >
> > Some have argued that authors should not use prefixed properties in
> > production sites. I disagree that this is desirable. The web is
> > significantly more competitive as a medium when work-in-progress features
> > are used, especially given how long it takes to properly standardize
> > something. And this widespread usage also provides important feedback
> > to the designers of the spec.
> >
> > But if authors are to use prefixes, how should they use them? Some
> members
> > of the working group believe that authors should not include the
> > unprefixed property alongside the prefixed ones because it restricts the
> > WG's ability to make improvements that are incompatible with early
> > proposals, defeating one of declared goal of prefixes. On the other hand,
> > a great number of web pages are written during one-time projects, and
> then
> > used for many years without maintenance. Writing such pages without
> > including the unprefixed property either guarantees that the page will
> > eventually break, or that vendors will be unable to remove support for
> the
> > prefixed property even when they support the unprefixed one.
> >
> > Similarly, including the prefix of browsers who have yet to ship an
> > implementation of a new property discourages them from experimenting with
> > different behaviors, as doing so would break the content which was
> written
> > in anticipation that the behavior would be similar. But not including the
> > prefix means the page, unless maintained, will never work in that
> browser.
> >
> > On top of that, there is the obvious point, often raised by authors, that
> > the current system is painfully verbose and tedious to maintain, which
> > sometimes causes them to not include the prefixes that would be necessary
> > to support browsers with a smaller market share.
> >
> > The web is meant to be a universal medium, agnostic in terms of device or
> > UA. Of course, testing in several browsers is needed to iron out bugs.
> > But when authors have to write for one browser, then port to a few other
> > selected ones, something is wrong.
> >
> > All in all, there is no simple right way for authors to use prefixes as
> > they currently are.
> >
> > ==== Proposal ====
> >
> > When a browser vendor implements a new css feature, it should support it,
> > from day 1, both prefixed and unprefixed, the two being aliased. If a
> > style sheet contains both prefixed and unprefixed, the last one wins,
> > according to the cascade.
> >
> > Authors should write their style sheets using the unprefixed property,
> > and only add a prefixed version of the property (below the unprefixed
> > one) if they discover a bug or inconsistency that they need to work
> > around in a particular browser.
> >
> > If a large amount of content accumulates using the a particular vendor
> > prefix to work around an issue with the early implementation in that
> > browser, the vendor could decide to freeze the behavior of the prefixed
> > property while continuing to improve the unprefixed one.
> >
> > ==== Benefits ====
> >
> > The excessive verbosity and tediousness that authors complain about
> > today goes away, and unlike the current system, there is no question
> > about how authors are expected to use this, reducing confusion and
> > grief. At the same time, it gives them the tools they need to
> > work around the inconsistencies that are to be expected in early
> > implementations of work-in-progress specs.
> >
> > No browser, however new or obscure, would have the problem of being
> > excluded. Authors might not test in it, but if the browser does
> > a good enough job of implementing the property, sites will render as
> > intended.
> >
> > This approach also makes it significantly easier for vendors to drop
> > support for the prefixed variant once they pass the test suite of a
> > CR level spec, since uses of the prefixed variant were to work around
> > bugs it no longer has.
> >
> > Less importantly, under the current approach, browsers should use
> > prefixes until they pass the official test suite, but the test suite is
> > writen without prefixes, so you either need a special version of the test
> > suite or a special version of the browser to check compliance. With my
> > proposal, there is no such problem.
> >
> > Of course, this scheme means that a large body of content may accumulate
> > in the wild before a property is fully standardized, but I don't think
> > this would have any significant negative impact on standardization.
> >
> > First, there are a number of areas where the specs are far ahead
> > of implementations and real word usage. Work on such specs
> > would not be impacted.
> >
> > Even when there are implementations, if they are still too immature
> > for authors to use in practice, nothing will prevent the WG from
> > changing the features for the better.
> >
> > In the cases where implementations and real world usage are ahead of the
> > spec, then yes, it would limit the ability of the WG to make incompatible
> > changes. But this isn't necessarily bad. Even with the current prefix
> > system in place, the WG should be hesitant to change massively popular
> > features. These changes are costly no matter what, and should only be
> > done when there are very good reasons.
> >
> > This doesn't mean that the WG would just be a rubber stand body
> validating
> > de-facto standards. It takes a lot of effort to go from 'it kinda works
> > well enough to be used' to REC level quality, and the CSS WG would still
> > be the place of choice for that work to happen.
> >
> >
> > I hope we will get the chance to discuss this during the upcoming face
> > to face.
> >
> > Regards,
> >
> >   - Florian
> >
>