W3C home > Mailing lists > Public > www-style@w3.org > August 2012

[CSSWG] Minutes and Resolutions San Diego F2F 2012-08-15 Wed AM I: Experimental Features Policy aka Prefixing

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 29 Aug 2012 17:33:35 -0700
Message-ID: <503EB4DF.3070006@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Experimental Features Policy

The CSSWG discussed the various problems being handled currently by the vendor
prefixing policy and how to solve them better. A rough consensus was adopted
around a variant of dbaron's proposal, which is summarized from the minutes
below. A more formal version will be written up for formal adoption in the
near future.

Section A
   If it's not Web-ready, and must ship, ship it prefixed and don't expose to Web.
   (Prefixes here avoid clashes with future Web features.)

Section B
   For Standards-track features:
     1. Experimental features ship only in non-release builds
     2. Release if 3 browsers implement, and we have rough interop,
       and we agree it's a good idea
     3. If a browser breaks the rules and ships a release anyway,
       and we have rough interop and agree it's a good idea,
       ship in release.
     4. If we haven't satisfied current criteria (CR + some respectable if
       incomplete set of passing tests), ship both prefixed and unprefixed
       versions so that authors can tweak the input to specific implementations.
     5. If current criteria are satisfied, ship in release unprefixed. (Obviously.)

====== Full minutes below ======

Experimental Features Policy
Scribe: TabAtkins

   dbaron: I think the first thing is that we shouldn't think of it as
           prefixing policy, but rather as an "experimental features" policy.
   dbaron: Because the right solution may not involve prefixes.
   florian: Two problems with the current policy.
   florian: There's no clear good way for authors to use it.
   florian: And not even just clear - I think there's no good way at all.
   florian: A common "best practice" is to list all the vendors followed by
            the unprefixed, which lets you write your site and forget about it.
   florian: This matches most author's workflow.
   sylvaing: Until we renamed things.
   florian: Yeah, but if we don't change things, that works.
   tantek: I think your first statement was flawed.
   tantek: I think that "making it work" isn't necessarily something the WG
           should be committing to, if it's experimental.
   florian: There is no good way to use these, so people use them in bad ways.
   glenn: Modernizr helps make this less painful, right?
   tantek: This is why I think that David's way of reframing the problem is

   florian: the things that we consider "experimental" are being used.
   florian: And with the current way we prefix things, there's no good way
            to use it, thus they do it in bad ways.
   glazou: Note that when browsers introduce a new experimental feature,
           they don't say it as an "experimental" feature - it's just a feature!
   glazou: "Now you can do border-foo!"
   sylvaing: Is it really experimental if we have multiple browsers shipping
             interoperable implementations?
   sylvaing: Authors are using it because it's in production releases
   florian: This is true, but I think we should be careful about drawing
            conclusions from it.
   florian: If we refrain from shipping too many half-ready things, we get
            around the issue, but we harm the competitivity of either the
            browsers doing it, or the platform as a whole.

   tantek: I think that Daniel's point is important, and calls to attention
           that we don't just have experimental features, we also have
           vendor-specific features, that are being shipped.
   tantek: And the vendors are saying "you can use this, because we will
           support this". And this is a different class of problems.
   tantek: Sometimes vendor-specific features are loved by web authors and
           then the WG has to figure out how to spec it, and that's similar
           to experimental, but usually they're separate.
   florian: I want to be careful about calling these things "vendor-specific".
            If apple introduces something that is meant to write the UI of
            itunes, or Moz introduce something meant for the UI of Firefox,
            etc., this is vendor-specific.
   florian: But if you write a feature that you have no particular intent
            to share with other brwosers, but you serve it from arbitrary
            web servers to arbitrary brwosers, this is not vendor-specific.
   florian: Opera has no reason to try and implement the things for iTunes,
            but it needs to implement the things used on iPhone, because
            they're exposed.
   tantek: I think that problem has been previously characterized as "once
           you've leaked it to the web".
   hober: canvas, for instance.
   tantek: Once you've leaked it, you can't take it back.

   florian: For those things that aren't meant to hit the web at all, it's
            fairly easy to define the policy for them.
   hober: A bit difficult, because there may be an initial use for a property -
          it's specialized for a certain client - but after they work with it,
          it turns out to have general applicability.
   hober: So I think it'll prove difficult to use a different mechanism for
          the two cases.
   florian: I think that if something's not meant for the web, it just
            shouldn't be exposed to the web at all.
   florian: If you later think you should expose it to the web, you can
            flip that switch later.
   florian: If you have a context switch that lets you hide it from the
            browser when it's in "web mode", we'd avoid a lot of issues.
   florian: They should probably be prefixed, to avoid accident collisions
            with WG stuff.
   glazou: I'm not sure there's a firm line.  Standalone web apps are
           becoming more prevalent.  Nobody knew initially that iTunes
           was built in web stuff.
   <hober> Of course, vendor-prefixed properties get created for several
           different purposes.
   <hober> See https://lists.webkit.org/pipermail/webkit-dev/2010-July/013534.html

   glazou: Hiding stuff behind a pref isn't going to happen, or only for a
           few months until the standalone app is turned into a web app.
   glazou: The proprietary CSS extensions we know of, only the ones designed
           for *very specific* things, like for MS word, don't eventually
           hit the web.
   dbaron: There are plenty of vendor-prefixed things that haven't taken off.
   glazou: Sure, but these are the no-question things.  Others, vendors may
           at least consider it.
   tantek: What do you mean by "things for ms word don't eventually hit the web"?
   glazou: The -mso- stuff never even considered to hit the web.
   tantek: You can find tons of mso prefixes on the web.
   glazou: Yes, but no one ever implemented them, or even intended to.
   florian: I think you're not disagreeing with me - if you create mso or
            itunes things, and you initially isolate them...
   florian: If someone else realizes they're not specialized and would be
            generally useful, someone can bring them to the WG.
   glazou: *If* someone brings them to the WG. People don't do that.
   jdaggett: About the mso stuff, that's just "gluck". The presence of a
             prefixed property in public isn't indicative that it's meaningful.

   TabAtkins: a problem you brought up is that we are making things exposed
              to the public without bringing them to the WG
   sylvaing: Can't do it.
   sylvaing: It's a matter of corporate disclosure
   glazou: It's a problem of strategy.
   sylvaing: People have public bits they don't want to expose.
   TabAtkins: That means that browsers are using the web and the WG as a
              means to bless their actions after they've blasted the web,
              so they retain first-mover advantage.
   leif: The WG can bring things up on their own, yes.
   sylvaing: Sometimes it's not even mentioned. There are things in W8 that
             aren't even submitted yet - just using CSS.

   jdaggett: Some of these are proprietary properties - not really intended
             to be part of CSS.
   jdaggett: And that's part of the problem. Authors don't see that distinction.
   jdaggett: Many marketing departments - there's a tendency to take feature X
             with a prefix on it and say that it's part of CSS3, even if the
             only thing that backs that up is a blog post or a private draft.
   florian: MS has probably extended CSS to make Metro UIs possible. Some of
            these features may be intended for the WG later, but not yet ready;
            others may not be intended for the web at all.
   florian: For the ones not intended for the web at all, I say just don't
            expose them at all.
   florian: For the others that you intend to be on the web, it would be useful
            to ship them (because you have to), but not expose them to the web.
   florian: This is similar to iTunes, and other types of things.

   florian: So what happens when you actually expose things to the web.
   florian: As long as you don't, you should have them prefixed, so that
            whatever ends up on the web (a standardized version of it, or
            something independent with the same name), we don't get name
            collisions between these two.
   florian: Which the web doesn't care about, but the private app would stop
            working if a same-named feature started doing something else.
   szilles: So I think you're saying that we own the unprefixed space, and
            anyone else must prefix.
   florian: I think whether or not random people introducing random things
            to the web should or shouldn't prefix is a separate question.
   florian: But for the things that *aren't* meant for the web, don't expose
            them, and prefix them.
   glazou: Again, I think the idea to "don't expose them to the web" is
           unworkable.  More apps move to webapps.
   glazou: I don't think it'll happen.  Browsers will want to expose them
           to the web sot hey can write webapps.
   plinss: I think it's reasonable for webkit to understand epub stuff, but
           only when reading epub files.  Not when doing normal web content.
   glazou: When I'm downloading a random epub file from the web, should it
           or not render epub properties?
   florian: If you can recognize it as epub...
   glazou: There's no difference between epub and a random html file.
   hober: I think it's unreasonable to expect epub authors to have a different
          workflow than regular html workflows.
   plinss: If it can't tell, it can't tell. But if it can tell one way or
           the other, do or don't respect epub properties.
   glazou: I don't think that's reasonable. Right now on the web you have
           some epub readers. They're just webapps.
   jdaggett: You're advocating a bad idea.
   glazou: Not advocating - describing.
   jdaggett: You're saying that any group that wants to create their own flavor
             of HTML or CSS, those things are their own entity. Whether any
             particular UA shows it in the way that's intended is a private
   szilles: Browsers aren't the only thing that can display web content.
   szilles: They may accept different things than what the browser accepts.
   szilles: If those other things become popular enough, there may be pressure
            to adopt what they do.
   szilles: So I'm hearing daniel say that it's a market force that we can't
            do anything about.

   sylvaing: In W8, we try to have a clean separation between web and app.
   sylvaing: But quickly, the Facebooks and Netflixes of the world, just
             build an app with a web container.
   sylvaing: And quickly they want the full set of things that apps can do.
   florian: But at that point we get to the point where you're deciding that
           things are appropriate for the web, not just for siloed content.
   jdaggett: I think the epub process is a perfect example of how we should
             not try and act.
   jdaggett: Where you take a laundry list of features that someone says
             they want, and stick it into a document with no attempt to
             distill or worry about interactions or do the hard work.
   tantek: Regarding epub - I think they're a great example of the *reality*
           that other groups will try to extend or fork the web platform.
   tantek: Before epub we had chtml, though that's an example of something
           that died.
   tantek: Other groups will try to extend.
   tantek: We can try to outcompete them, or we can get outcompeted.

   glazou: Epub is a nice extensions because they have public documents
           detailing everything.
   hober: epub tried to track us as well as they could, given our schedule,
          and they tried to be good actors in this case.
   glazou: yes, it's a good case.
   glazou: It's not the best thing to do, but they tried to do good.
   dbaron: They had a schedule, and no intention of putting in enough
           resources to meet that schedule properly.
   szilles: I think it's important that such experiments are identified
            as such.
   szilles: But I think we should adopt a "fast follow" approach, so that
            when something looks important, we can produce a similar version
            of it.
   szilles: Not necessarily identical - one of the problems with the fast
            actors is that they often don't think about interactions,
            which slows us down.
   jdaggett: It isn't just a matter of slow and burearcratic, as tantek
             puts it - it's just a damned hard problem.

   glazou: It can be fast and agile and not disclosed because of competitive
   tantek: Often bureaucracy and process has gotten in our way historically.
   tantek: We're aware of and trying to fix that problem.
   jdaggett: Prioritization is crucial.
   jdaggett: If we aren't prioritizing the right thing, if we're spending
             lots of time on exotic things here an there, that's a problem.
   florian: I think it magnifies the problem - it's not a root cuase.
   szilles: I think making it possible for us to do fast follow is how we
            should address this problem, not changing the way we identify
   szilles: How we label is a red herring.
   plinss: It alleviates some of the pressure.

   plinss: There's no disagreement in the group that things come up that
           we need to work on more aggressively.
   glazou: From my perspective the problem is about getting the technical
           information about a property implemented by one of the members
           and not yet disclosed, such as text-size-adjust.
   tantek: People brought up a bunch of examples.
   fantasai: Examples:
   fantasai: text-size-adjust was not disclosed and became super-popular
   fantasai: border-radius
   fantasai: microsoft's grid layout proposal...
   fantasai: Looking at different ones of these, you'll make different
             suggestions about what's best.
   fantasai: border-radius - why have prefixes? We all did the same.
   fantasai: grid layout - if MS shipped what they had unprefixed, we'd
             have had no chance to fix the problems in it.
   fantasai: So we shouldn't focus on just one of these examples, we
             should look at all of them.
   fantasai: Like T&A is more of a border-radius case.

   tantek: More general examples.
   tantek: There was the UI example - UI of iTunes or Firefox.
   florian: Slight break - we don't all agree on the exact details of the
            problem, but we all have a shared idea of what it is generally.
   florian: So rather than get the details more, let's talk about solutions
            and see if it turns out good.

   fantasai: Starting proposal! Based on dbaron's proposal + discussions
   fantasai: Section A.
   fantasai: If it's not web-ready, ship it prefixed and don't expose it
             to the web.
   fantasai:  Section B.
   fantasai: For standards-track features, ship only in non-release builds.
   fantasai: ...unprefixed.
   fantasai: If another browser ships a release and we have some level of
             good interop and we think it's a good idea, everyone ship as release.
   dbaron: The way another browser "ships a release" is by breaking these
           rules in the first place.
   fantasai: If three browsers total implement (non-shipping) and we have
             interop and think it's a good idea, everyone ship.
   fantasai: If it's not a solid spec and we don't have a testsuite, but
             we're still forced to ship, ship both prefixed and unprefixed
             so authors can turn things off that are broken in a particular

   glazou: This does not solve the text-size-adjust problem.
   szilles: What problem does this solve?
   TabAtkins: The bit where we have multiple prefixed versions living for
              a while and making authors lives hard.
   szilles: In order to do that, you still need a test suite and therefore
            why not go through the process we have now.
   florian: If you want to test *strict* interop, you need a test suite.
            If you just need a rough idea, you don't need that - subjective
            judgements are possible.

   tantek: Response to steve - what we have seen with T&A&transforms,
           these exampels have disproven your statement.
   tantek: In practice, we have not needed a testsuite to get interop,
           as evidenced by author adoption.
   tantek: if they weren't "sufficiently interoperable", authors wouldn't
           be using them so much.
   tantek: This is a pretty strong bar.
   glazou: "perceived interop", not "interop".
   szilles: My concern is that, left to the vendors to declare interop,
            this won't work.
   szilles: Marketing departments have a strong idea to do that.
   plinss: I don't think anyone is suggesting that a single vendor declaring
           interop is sufficient.
   plinss: I think the current process we have, where someone suggests we
           have sufficient interop and then asks the group for unprefix,
           is sufficient.
   dbaron: But we did that with TTA, and the group said no the first time.
   florian: When we asked the group "can we release TTA", we were aiming
           for a different level of interop.
   <dbaron> hmmm, maybe I'm misremembering and thinking of something else
   <tantek> dbaron - no you're remembering correctly
   <tantek> we asked to unprefix TTA in Paris in February and were told no
   <fantasai> no, the first time we decided not to unprefix, largely because
              MS did not want to
   <fantasai> and then when they decided to unprefix, that gave us consensus
              in the WG
   <tantek> I'm sure we can look that up in the minutes
   florian: We were asking for full interop.  We're now not shooting for
           that - we want "sufficient interop".
   florian: Now, between these two stages, you should ship prefixed *and*
            unprefixed, so individual authors can use the unprefixed if it
            works for them, and provide brwoser-specific styles using
            prefixes to work around problem in specific browsers.

   glazou: I'm seeing two cases.
   glazou: I don't think that this process is the difficult one.
   glazou: I think the hard one is the browser vendor developing a proprietary
           feature and then everyone else discovers it by surprise, and we
           have to implement.
   florian: If text-size-adjust was released under this process, it would
            not be in a webkit prefix.
   florian: It would put us in mostly the same difficulty as now, except
            that browsers who decided to implement it wouldn't be forced
            to implement it with a webkit prefix, which is today's situation.
   florian: This system doesn't prevent the bad things from happening, but
            it untaints  them.
   florian: All the things we're trying to do with text-size-adjust now,
            we'd mostly have to do anyway.  It won't go away.
   florian: But at least we're not stuck with the webkit prefix name that
            everyone has to support.
   florian: It's not fantastic, but it's an improvement.

   tantek: There's a bunch of different problems here.
   tantek: I like the proposal as developed. It doesn't solve all the problems,
           but it solves some of them well enough
   florian: I think it doesn't solve all of them, but it solves some of them
            better than the current world.
   szilles: If you publish anything unprefixed before you have a reasonable
            belief that it's reasonably interoperable, you're going to get
            uninteroperable things, and it will become unusable.
   szilles: Or everyone will follow the bad design.
   TabAtkins: The reality is that everyone follows the bad design *and*
              puts a webkit prefix on it.
   szilles: But it prevents us from doing better under a better name.
   <tantek> "if it works, the author will use the unprefixed version because
             it's shorter typing"

   glenn: A random remark - I noticed a posting that "the point of the vendor
          prefix is to assert the instability of a feature".
   glazou: A corollary of that is that purely proprietary things shouldn't
           use a prefix.

   dbaron: I don't think we should try to come up with a master plan for the
   dbaron: We should be figuring out how to adjust what we're doing.
   dbaron: And I think it will require continued adjustment in the future.
   dbaron: We won't do it all today.
   dbaron: I think a few directions in which we should be adjusting things...
   dbaron: (1) ship less prefixed stuff on the web
   dbaron: (2) unprefix things faster when we get interop
   florian: I think we need to acknowledge that not everyone will follow
            the policy.
   florian: This will happen, so our policy should just not make things
             worse when this happens.
   <tantek> "when we get interop" - what level of interop? authors vs. test

   hober: Note that dbaron's #2 is something we can do right now without
          changing policies.
   fantasai: Actually, the current policy is just the "legacy content" excuse.
   fantasai: That's what we used for TTA.

   TabAtkins: for the one issue of let's unprefix faster, let's formally
              adopt fantasai's stated proposal (from dbaron)
   szilles: I can live with that
   glenn: That's reminiscent of the language that Maciej required for CR-exit.
   glenn: For HTML.
   szilles: I like that it's not individual manufacturers making that decision.
   <hober> glenn was referring to this email:

   tantek: One thing I'll raise is that one recent RFC deprecated the use of x-.
   tantek: But they drew a strong line between vendor-specific and experimental
   tantek: They think that using x- for vendor-specific still works.
   tantek: But not for experimental, because in the end everyone implemented
           it anyway.
   tantek: So let's consider that work and analysis done by IETF.
   plinss: Let me assert that, while learning from IETF is useful, we might
           not want to follow them exactly - they have a different problem
   * hober suspects we've exceeded our timebox for this topic

   TabAtkins: So are there standing objections to fantasai's proposal?
   glazou: No objection, but I'd like to see it written out formally in an
           email, as it's nearly unreadable here in the minutes.
   glazou: We'll post to email, and formally resolve in a few days if there
           are no objections.
Received on Thursday, 30 August 2012 00:34:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:20 UTC