Re: Proposition to change the prefixing policy


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
>

Received on Saturday, 5 May 2012 00:33:23 UTC