RE: Dropping Prefixes Early on Transforms/Transitions/Animations


[Aryeh Gregor:]
> 
> On Thu, Feb 16, 2012 at 4:12 PM, Sylvain Galineau <sylvaing@microsoft.com>
> wrote:
> > I think it'd be more problematic to let browsers drop prefixes without
> > any concrete evidence of interop.
> 
> I don't think the prefixing makes the lack of interop any less problematic
> for authors in practice.

I think it can help somewhat, actually. If you need to work around one 
browser's bug or rendering issue by tweaking the value and the new value 
is still valid for the other UAs, you either end up falling back to what 
the buggy UA accepts across the board, or you'll do what prefixes do - browser 
sniffing - in much uglier ways. 

> 
> > No published test suite could be more accurate. I doubt we're the only
> > ones to write lots of internal testcases for our own work in that
> > area.
> 
> The same is true for transforms/transitions/animations.  I based my
> transform reftests off Gecko's internal tests (where "internal" means
> "available for public checkout" :) ), and am starting work on porting its
> transition tests now.
> 
> > This is not really about process. Some of us are OK with unprefixed
> > properties to have all kinds of bugs for months to come. If I shipped
> > every
> > 6 weeks and my users kept up, maybe I'd agree. But I still think it's
> > not author's job to QA our specs and establish a basic level of
> > real-world interop by filing bugs all over the place. I'd rather lose
> > some velocity and start from a higher quality level. I think the
> > general argument is that some folks think far too much velocity is
> > lost to achieve that quality. And I think that is something we
> > actually all agree on. But I don't think we need to think of them as
> > mutually exclusive. Maybe velocity and quality require smaller, more
> > focused specs, taking the success of a feature in existing content
> > into account, being aggressive about moving new ideas that haven't yet
> been implemented to a new level once some features in the module get
> traction etc.
> > We want to make it faster. But figuring out how is going to be no
> > easier a consensus-building exercise than any other complicated
> > feature with many moving parts. We'll keep at it. All input is
> > welcome, however radical some members may find it.
> 
> See, this would be a valid argument if we were talking about not releasing
> the feature.  But it's released, just with cumbersome syntax.  If release
> builds of a browser support a particular feature on public web pages,
> pages will use it, and it will be a compatibility constraint regardless of
> whether it uses prefixes.

I did not mean to imply we shouldn't talk about whether/when to release the feature.

> 
> It makes more sense to me now that Microsoft and Apple are against
> unprefixing, and Google and Mozilla are in favor.  

We're not against at all. We'd rather not unprefix features that still
have shaky interoperability as this has little value for authors. The 
latter are even likely to fall back or stick to prefixes to work around 
the UA-specific bugs they run into until the smoke clears. Prefixes are 
ugly, and a pain, but not having them and being aggressively optimistic
could be worse than we assume. Still, I'll listen to any proposal to
get rid of them as that would be ideal for all involved.

> But look on the bright
> side: if you can't change as readily, that just means specs will have to
> be biased toward your behavior.  I know I've seen Hixie spec IE's behavior
> over Gecko's/WebKit's more than once, just because we know old versions
> will stick around for a long time . . .
> 
> On Thu, Feb 16, 2012 at 8:41 PM, David Storey <fbnw74@motorola.com> wrote:
> > Have you filed the bugs with the other engines as well, or only Gecko?
> 
> I'm currently employed by Mozilla, so I only spent the time to isolate,
> report, and fix bugs for Gecko.  But the tests I wrote are hopefully clear
> enough that people working on other browser engines can track down and fix
> the failures without too much extra effort.  If anyone has questions about
> the correctness of any of my tests, or is having trouble understanding
> them, feel free to contact me.
> 
> > I'm pretty sure each browser vendor has their own tests when
> implementing the specs in question. If we can get some commitment from
> those vendors to release their tests, if they haven't already, then that
> would give us another stride. I suspect they're also written in a way that
> can be automated (maybe not in a way that can be used with another
> vendor's automation tools though).
> 
> My transform reftests are based on Gecko's.  I'm currently working on
> porting Gecko's transition tests to a more publicly usable form.
> These are all automated.  I've been told Opera is in the process of
> releasing its own internal transition tests too.
> 
> > Do we have a list of current issues we can go through together that we
> can decide if they cause interop problems if the prefixes are removed?
> >
> > For spec issues, I couldn't find any open issues on TTA:
> >
> > http://www.w3.org/Style/CSS/Tracker/issues/open?sort=product

> >
> > And only one raised:
> >
> > http://www.w3.org/Style/CSS/Tracker/issues/83

> >
> > Am I looking in the wrong place? (Sorry, I'm new on the group). The
> > issue above mentions "various issues" that the editor needs to split
> > out. That was in 2008. Was that ever done? If not can we start doing
> > that? This task seems somewhat related (from 2010)
> > http://www.w3.org/Style/CSS/Tracker/actions/214

> 
> There are a whole bunch of open bugs on all three specs in Bugzilla:
> 
> https://www.w3.org/Bugs/Public/describecomponents.cgi?product=CSS

Received on Friday, 17 February 2012 19:09:25 UTC