Re: [vendor-prefixes] The system needs to be opt-out, not opt-in

I kinda like your proposal. However, that doesn't take in consideration that 
some properties may start as "vendor-restricted" and are then promoted to a 
real browser. Here's a man-in-the-middle proposal :

- a beta browser (or an app-engine browser) may ship with any property, 
including -vendor- prefixed ones.

- a RTM browser must ship a property only if :

    * any of those statements are true :

        (1) a public editor draft was sent to WG at
        least 2 months (61 days) prior to release

        (2) two UA (or more) that have different
        render engines have a partially interoperable
        implementation in beta builds

    * it recognizes both "-beta-property" and
    "-vendor-property" as aliases :

        (1) it allows simple cases to be handled by
        "-beta-property: value;" for all browsers

        (2) it allows to implement fixes for one vendor
        using "-vendor-property: vendor-value;"

- from the moment an RTM browser ships with an
unprefixed property, it has one year to remove
support for prefixed aliases, or remove support
for the unprefixed property.


Regards,
François


-----Message d'origine----- 
From: Lea Verou
Sent: Friday, February 10, 2012 12:23 AM
To: www-style list
Subject: [vendor-prefixes] The system needs to be opt-out, not opt-in

I think the main problem with vendor prefixes is being opt-in, rather
than opt-out. Authors have to explicitly opt in to support a certain
engine. The assumption being that implementations are usually different,
so there is no special consideration for the case where they are the
same. We just expect authors to copy and paste in the case of such
…coincidence. However, that case is not rare at all, and nobody likes
copying and pasting.

I think this misconception originates from the different kind of
exposure that WG members and standards enthusiasts have over regular web
developers. We are interested in edge cases or the interplay between
different new features and that's where most implementation differences
lie in. However, most authors just use the very basic case (e.g.
border-radius: 10px) and hardly experience any differences. Heck, my
experimental CSS usage is heavier and contains many more edge cases than
the average developer's and I've only needed separate declarations 1-2%
of the time!

It should be easier and quicker for authors to say "I want this to apply
to ALL engines" than to say "I want this for Gecko, this for WebKit and
this for Presto". We wouldn't have *any* of the problems we're
discussing these days if vendor prefixes were designed with this simple
principle in mind from the get go.

People are lazy. It's an established usability principle that you have
to design around people's laziness, rather than try to change them.
Good, usable UIs are the ones that allow users to indulge in their
natural laziness. In CSS, the UI is the code and the users are the
authors, but good usability still matters.

As for the syntax, no strong opinions. I think anything that follows the
above principle is OK. I'd personally suggest a single prefix (-x-, to
match the one commonly used in HTML) and vendor media queries for the
cases where we want to restrict it to specific engines. It doesn't offer
versioning, like some other suggestions, but neither does the current
system and I've almost never seen issues with that.


-- 
Lea Verou (http://lea.verou.me | @LeaVerou)

Received on Friday, 10 February 2012 10:07:42 UTC