Re: Dropping Prefixes Early on Transforms/Transitions/Animations

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.

> 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.

It makes more sense to me now that Microsoft and Apple are against
unprefixing, and Google and Mozilla are in favor.  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 16:36:24 UTC