- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 29 Aug 2012 17:33:35 -0700
- 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
useful.
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
matter.
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
reasons.
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
things.
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
impl.
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
future.
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
suites
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:
http://lists.w3.org/Archives/Public/public-html/2012Aug/0190.html
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
features.
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
space.
* 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.
[consensus]
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