Re: [css-2015] Snapshot prose, prefixing policy updated

> On 20 Jul 2015, at 23:06, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
> Hi everyone,
> Tab and I just finished compiling a first draft of the 2015 Snapshot copy.
> We haven't incorporated the new specs into the indexes (it's still the
> 2010 set), but we updated the intro, the process summary, and most
> importantly
> 
>  We updated the prefixing policy to reflect the San Diego 2012 resolutions:
>    http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/
> 
> Many thanks to Florian Rivoal for the initial draft of the new policy.
> 
> Here's a link to the Editor's Draft:
>  http://drafts.csswg.org/css-2015/#experimental
> 
> We're hereby requesting that the CSSWG review and, if the wording is an
> acceptable representation of the resolutions, approve the new policy.


I've been through the text you propose, here are a few tweaks I would suggest based. I think they address some of the concerns raised last week.

A) Split section 2 into one section that says under which circumstances you can release, and and another one which says how you release when you do, so that we can easily refer to this separate "how to release unstable features" section.

In the first one, include the first paragraph without the last sentence ("Vendors should provide[...]"), with the first "why?", and with the following modification:
  "implementers may ship that feature unprefixed in
   release builds"
->
  "implementers may ship that feature in release
   builds provided they do so as described in
   section $X."

The second one could be something like:
  "X. When exposing an unstable feature to the Web in
   a production release, implementations:
   - must support the feature without a prefix
   - should also support a prefixed syntax in addition
     to the unprefixed one.

   Authors should use the unprefixed syntax alone
   (i.e. without also including the prefixed syntax
   for various vendors).

   Note: Why? This is so that authors [...]

   Vendors should provide spec-editing and testing
   resources to complete standardization of such
   features."


B) Rephrase section 1 to explicitly account for experimental feature flags and for vendors who cannot avoid releasing first and standardizing later.

  "Implementations of unstable features that are described
   in W3C specifications but are not yet interoperable,
   as well as implementations of CSS features which
   have not been brought forward for standardized,
   should not be included or activated in production
   software.

   Vendors who are unable to abide by this rule may
   release unstable features provided they do so
   according to the rules of section X.

   Experimental implementations may be included and
   activated in non-release builds, as well as in
   release builds provided that they are not active
   unless explicitly enabled via user settings.
   Such experimental implementations should not
   use a prefix."

C) The term browser is used instead of UA in section 2 in order (I believe) to only speak about UAs that are exposed to the web (i.e. not the runtime of Firefox's or iTunes' UI). Since the "exposed to the web" phrasing is used multiple times elsewhere in this document, I think we should use it there as well, and rephrase that first sentence as:

  "If at least three UAs implement a feature meant to
   be exposed to the web (or if a UA has broken the
   previous rule and exposed to the web an
   unstable or [...]"

As for actually defining "exposed to the web", although that would be nice, I am afraid this is a rathole of which we'd have a hard time finding the bottom, and it is more realistic to rely on common sense and good will here.

D) In section 3, I would say "MUST only be supported through a prefixed syntax and and MUST not be exposed to the web".  Switching from should makes it clearer that we are reserving the entire unprefixed namespace.

E) I think we should put some requirement on authoring tools to avoid producing stylesheets with unstable features, to be lifted as soon as a UA ships support in production builds.

 - Florian

Received on Wednesday, 29 July 2015 16:04:47 UTC