[CSSWG] Minutes and Resolutions Telecon 2012-02-15

Summary:

Discussed -webkit- prefixing situation and how to move forward on Transforms.
Considerations included:
   - whether to exceptionally unprefix transforms immediately or follow
     through with the process to CR
   - whether Transforms spec needed to be split into SVG/CSS or 2D/3D or
     some other way
   - whether to move to CR while deferring all issues raised by the merge
   - whether to publish LCWD immediately, how long of an LC period would be
     required, and how long it would take to finish resolving the issues
No consensus positions were found, and all parties left the telecon
frustrated.

Time estimates for finishing work on Transforms however were agreed
to be within 2-3 months if appropriately prioritized. (This of course
assumes future telecons are dedicated to making progress rather than
arguing process.)

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

Present:
   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   David Baron (partly via IRC)
   Bert Bos
   Tantek Çelik
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Koji Ishii (late)
   Håkon Wium Lie (mostly via IRC)
   Chris Lilley (mostly via IRC)
   Peter Linss
   Divya Manian
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Alan Stearns
   Daniel Weck (mostly via IRC)

   + several people who did not identify themselves >:|

<RRSAgent> logging to http://www.w3.org/2012/02/15-css-irc
Scribe: TabAtkins
Note: Several people were having trouble dialing in, including Håkon Lie,
       Chris Lilley, Peter Linss, Daniel Weck, and David Baron

Administrative
--------------

   glazou: Any extra items for today?
   Florian: Not sure howcome is here today; if not, shouldn't talk about
            GCPM
   glazou: I noted that fantasai posted clarifications about the selectors4
           requests.
   glazou: Let's move to the first item on our agenda today.
   glazou: It's about -webkit- prefix.

-webkit- Prefix Problem
-----------------------

   glazou: I had a lot of chats between the first day and yesterday.
   glazou: That ended with the proposal I made to Brendan.
   glazou: A compromise about what we could do in this WG.
   glazou: Brendan Eich.
   glazou: This was discussed between Brendan and Jeff Jaffe on Monday.
   glazou: I don't know the details, but apparently the compromise goes
           in the right direction.
   glazou: So we need to discuss and find a plan here.
   glazou: If it's so urgent that the three browser vendors raised in
           Monday, we need to move forward quickly.
   <smfr> linky please
   <florianr> http://www.w3.org/mid/4F391911.307@disruptive-innovations.com
   <tantek> to be clear - I was at that meeting with Jeff Jaffe and
            Brendan on Monday
   glazou: That's not a decision, it's a proposal to discuss.
   glazou: It merely seemed reasonable at the time I wrote it.
   glazou: I'd like to discuss this, and if you have counterproposals,
           discuss those.
   sylvaing: What's the connection between this and what Brendan and
             Jeff discussed?
   glazou: No idea.
   tantek: I was at the meeting.  We discussed Daniel's proposal.
   tantek: I don't think anything new came out of that; it was just
           Jeff gaining a broader understanding.
   tantek: The key point is the one I made in email - we don't have a
           specific list yet, and I don't think anyone has yet.
   florianr: I don't think anyone has a final list, but we should be
             able to give a top-5 list or something.
   tantek: I can put it in a more coarse-grained fashion. We're still
           analyzing our data, and we don't have specific properties
           to propose yet.
   tantek: It would be very helpful for us and the group if certain
           specs were made to advance more quickly.
   tantek: Because the syntax is stable.
   florianr: I have a question about your studies.
   florianr: It seems that with even a little bit of study, it seems
             easy to come up with a simple list of stuff applicable
             everywhere.
   florianr: So what info are you looking for?
   ...
   tantek: We also find that when -webkit-border-radius is used,
           there's also the other prefixes or unprefixed.
   tantek: So the result is, how much difference would it make to
           implement -webkit-border-radius?
   tantek: if the answer is "not that much difference", it's not
           worth doing.
   tantek: So it's the question of what it's used with.
   tantek: If we can avoid supporting -webkit-, great.
   tantek: When we do find a property that seems to be -webkit-
           prefixed only, the question is:
   tantek: Is it affecting the user, and how much?
   tantek: And that's a hard question to answer without manually
           looking at the site.
   tantek: If you can't tell the difference, what's the point of
           implementing it?
   tantek: So we're trying to be conservative here.
   tantek: The coarse data alone, though, provides us enough clues
           to recommend to the WG which specs to advance faster.

   florianr: I've done some studies here.  I don't think there as
             details as yours, but I've looked for whether -webkit-
             is used with or without something else that opera supports.
   glazou: Can you share this data?
   florianr: I've sent it to the private list.
   <florianr> http://www.w3.org/mid/op.v9n5gsan4p7avi@localhost.localdomain

   glazou: Are you making a big difference between border-radius,
           which is specified and implemented everywhere, and
           between properties that are more experimental, have little
           or no spec, and not implemented anywhere else.
   glazou: For the former, the decision to implement -webkit- is only
           in your hands. There's nothing we can do on the standards
           side.
   glazou: For the latter, we need more specs, we need faster movement.
   florianr: There's a third case, which is important - things that
             are on progress, but not unprefixed yet.
   glazou: For the second case, I think we have a problem. Most of
           them come from Apple.
   glazou: The current specs available online are really light, to
           say the least.
   florianr: Like text-size-adjust?
   glazou: Not only that, but yes.
   glazou: I think the definition is underspecified, to say the least.
   florianr: From my data, text-size-adjust comes first among things
             without a spec, -webkit-appearance is next.

   sylvaing: When you crawl, what UA string are you using?
   florianr: wget's UA string.
   sylvaing: On the mobile web, you get very different content based
             on the UA string.
   sylvaing: If you pretend to be webkit, the results are completely
             different.
   sylvaing: So we're trying to figure out which method to use to report
             the numbers.
   <smfr> [time check: 2 mins left on this issue; what are we trying
           to achieve?]
   florianr: I've seen people doing more sophisticated analysis, and
             the numbers were higher if they spoofed as webkit, but
             the ordering was pretty similar to my method.

   glazou: So, what are we going to do *now*?
   glazou: We need specs for the underspecified properties, and we
           need analysis for the ones that need to go faster.
   tantek: I think there are 3 specs that the WG needs to publish as
           LC asap.
   tantek: And consider dropping prefixes early since the syntax is stable.
   tantek: Transforms, Transitions, and Animations.
   glazou: 2d or 3d?
   tantek: I think 2d.
   tantek: Based on the wG discussion to split 2d and 3d.
   sylvaing: I think we agreed to try and advance them together,
             because it would be more work to pull them apart.

   florianr: going back to the things without a spec, I think we're
             counting on webkit people to submit a spec for
             -webkit-text-size-adjust.
   florianr: And appearance was dropped from CSS3 UI with the intent
             to be in CSS4 UI.
   florianr: Analysis suggests it's being used.
   <dbaron> I don't think appearance was dropped with intent to be
            in css4-ui.
   tantek: I agree that it would be good to see proposals from Webkit
           about text-size-adjust, at least a simple draft.
   <dbaron> I think it was dropped because some people objected to
            the principle.
   tantek: On appearance, based on my prop there's very little interop.
           Most seem to be using it for appearance:none. But I don't
           think there was much actual impact of using it.

   tantek: So I think the highest impact is text-size-adjust and the
           three specs I mentioned.
   glazou: So let's focus on those three specs and text-size-adjust.
   glazou: It seems that the syntax is not going to change.
   glazou: So can we unprefix and move them forward fast?
   smfr: At the f2f we decided *not* to split the transforms specs.
   <dbaron> I think we should just try to move all of transforms
            forward quickly.
   smfr: And we have some demands for Transforms syntax changes.
   Tab: Let's move transforms forward. We can adjust syntax later.
   <dbaron> We should reject the demands for syntax changes
   glazou: So do we agree to move the Transforms spec without the
           syntax change?
   smfr: Are you talking about combined 2d/3d/svg transforms spec?
   glazou: Yes.
   smfr: Are we going to wait for feedback from SVG, or define some
         conformance classes?
   tantek: Has anyone shipped support for the new features?
   smfr: No.
   Dirk: The only difference is the three argument rotate(), so I
         don't think it makes sense to split from SVG right now.
   <glenn> presumably transforms will go to LCWD before CR, yes?
   <fantasai> glenn, yes, that's required
   <dbaron> I think the three argument rotate() should be reverted.
   <ChrisL> In the context of a spec jointly edited by SVG and CSS
            folks, how are you "waiting for feedback" from SVG
   tantek: I'm not opposed to new things in the future, but I think
           it should be at minimum split into a separate WD and
           published later.
   tantek: Or marked it as at-risk and keep moving, knowing it might
           not exit CR.
   * fantasai prefers the at-risk option

   smfr: The other issue is that we can't drop prefixes on 2d unless
         we start prefixing the 3d functions.
   smfr: Which will be confusing for authors.
   tantek: Why is it difficult if we have interop on 2d?
   <ChrisL> all the options are confusing to authors in some way
   <ChrisL> prefixing 3d seems the least confusing option
   florianr: The prefixes are on the property, not the value.
   florianr: so to unprefix 2d only, you'd have to prefix the 3d
             functions
   glazou: I think the 3d functions are already too spread on the
           web to worry about it.

   sylvaing: I would like a testsuite before we claim interop.
   TabAtkins: Do you expect any lack of interop to affect the syntax?
   [unminuted talking over each other]
   <ChrisL> +1 to tantek's proposal
   <ChrisL> tantek proposes moving to lcwd asap and dropping prefixes
            at lcwd for this spec
   sylvaing: It's just about splitting 2d/3d.
   <smfr> is there anything new here that we didn't discuss at the F2F?
   tantek: I'm not talking about exiting CR right now, just unprefixing.
   sylvaing: Are we making an exception to the unprefixing rule?
   tantek: Yes.
   glazou: Last week we discussed de facto vs de jure standards.
           These are de facto standards already.
   [minuter declares bankruptcy]

   sylvain: We have rules for dropping prefixes and I'm asking why
            we're making an exception?
   TabAtkins: Back to the discussion. Transform, Transitions, Animations.
              Drop prefixes?
   TabAtkins: Can we poll on this? Discussion seems to be going nowhere.
   Poll options:
   1) Move Transforms/Transitions/Animations to LC and allow unprefixing.
   2) No exception, just try to move the specs fast.
   <fantasai> If we're making an exception to the process, we should
              document that in the Snapshot *as an exception*
   glazou: 1
   chris: option 1
   glenn: 2
   astearns: 1
   bert: 2
   florianr: 1
   dirk: Does option 1 mean no more syntax changes?
   TabAtkins: Yes.
   smfr: 2
   sylvaing: 2
   nimbu: 1
   plinss: Torn, but 2.
   antonp: 2
   tantek: 1
   Rossen: 2
   TabAtkins: 1
   howcome: 1
   dbaron: 1
   hober: 2
   arronei: 2
   krit: 2
   davidStorey: 1
   * fantasai votes for 3

   fantasai: I don't agree with ignoring the issues and just pushing
             to CR, as some people seem to be advocating here. I also
             don't think any syntax change should be pushed to L4,
             because as sylvain says they need to be fixed now if at all.
   fantasai: My preference would be to list the transforms functions
             we're trying to unprefix in the Exceptions clause, and
             work on the spec knowing that we are syntax-constrained.
             I would like to see all the issues addressed prior to CR.
   fantasai: If people want to cycle through mutliple LCs because they
             feel that somehow makes it better, fine.
   <ChrisL> fantasai is voting for a modified 1 which may allow syntax
            changes if there are issues to avoid multiple last calls
   <ChrisL> I agree with fantasai
   <dbaron> Yes, I'm happier with fantasai's modified (1) than with
            the original (1).
   <Bert> (I think 3 is like 1, except that we explicitly reserve
           (and warn!) the right to change the syntax again.)
   * hober thought 3 sounded a lot like 2
   <ChrisL> 3) move to LCWD, try to freeze syntax, unprefix, but still
               correct issues if they arise in LCWD
   * Bert stays with option 2
   * dbaron but fantasai's proposal and (1) have in common that we're
            making an exception regarding the unprefixing rule

   sylvaing: I don't think the process is blocking us here.
   tantek: In practice it is rarely a few weeks from first LC to CR.
   ChrisL: Often it takes way longer to process results.
   tantek: How long a LC do you want, Sylvain?
   tantek: So we have a proposal for, what, 8 weeks LC?
   <glenn> does that include time for processing? 8wks seems long for
           comment period
   ChrisL: Seems like 8 weeks for dealing with issues, not actually
           the comment/review period.
   <glenn> 3-4 weeks should be enough for comments...
   * hober notes that we're still on the first agenda item
   sylvaing: I think 3 for review, 8 for dealing seems fine.
   sylvaing: I think we can realistically take this to CR in 2-3 months.
             If we don't think it's doable, what are we doing dropping
             prefixes?
   dbaron: I think that in some cases, the specs are in bad shape where
           impls interop.
   dbaron: Not saying everything, but several cases where we have
           interop but the spec doesn't describe it properly.
   smfr: Can you give an example.
   dbaron: Not off my head.
   tantek: When that happened in css2.1, we just changed the spec.
   dbaron: I'm not even saying the spec is different, but rather that
           it's unclear.
   <dbaron> (Though I'm thinking of some aspects of the model for animations.)
   <Rossen> text-size-adjust is a good example of what dbaron just said

   glazou: And that should be fast.
   tantek: So, Sylvain, you want to drop prefixes in 11 weeks, not
           tomorrow, is that right?
   sylvaing: I think so, yeah.
   sylvaing: I don't want to make precedents for anything.
   tantek: No precedent, this is an exception.

   <glenn> where is "unprefixing rule" documented?
   <fantasai> http://www.w3.org/TR/CSS/
   <smfr> glenn: the green text:http://www.w3.org/TR/CSS/#experimental
   <glenn> tnx

   sylvaing: We have a spec with four impls, but there hasn't been an
             urgency.
   [unminuted discussion consisted of Sylvain arguing for just going
    through with the process rather than making an exception, and others
    arguing for making the exception]
   [other unminuted discussion about daniel ruling that there is no
    consensus, and we should therefore dedicate our time to solving
    the issues and moving the spec forward]

   glazou: I suggest the 3 browser vendors that want to unprefix discuss
           amongst themselves.
   glazou: No consensus is emerging, despite all the discussion that
           has already happened.
   glazou: We are *moving on*.
   ChrisL: Since we don't have consensus on dropping prefixes, I think
           the chair should discuss moving LC forward.
   glazou: Agreed.
   glazou: So what are we going to do to address the issue asap.
   smfr: It seems we need to split into 3 and 4, where the new SVG
         stuff goes into level 4.
   smfr: With the remaining issue being 3d transforms.
   tantek: I agree with smfr.  I think that the problem here is not
           being properly understood. We'd like to implement unprefixed
           at the same time.
   tantek: Let me make it clear. If the WG cannot unprefix quickly, we
           (firefox) will implement -webkit- prefixes.
   Dirk: Because of level 3/4 splitting, I don't think it makes sense
         to do the SVG stuff in two levels.
   Dirk: I don't think SVG is blocking 2d transforms, maybe 3d transforms.
   <sylvaing> I understand webkit-only properties being an issue for
              mobile; transforms is not in that category for us
   TabAtkins: sylvain, that's different from what you said at the f2f
   sylvain: No, it's consistent.
   <fantasai> Sylvain said that -webkit-was a problem. He did not say
              that transforms was a problem.

   <glenn> wouldn't it be better to go to a common prefix rather than
           reimplementing vendor specific prefixes? e.g., instead of
           simply dropping rule, encourage all vendors to support
           -w3-wd-... or some such?
   <TabAtkins> glenn, no, that doesn't solve the problem, and introduces
               new and exciting ones.
   <glenn> would prefer a common w3c sanctioned prefix over no prefix
   <tantek> I want to hear from everyone who voted (2), what issues do
            you see as blocking LC for those 3 specs?

   ChrisL: We know what the differences are between SVG and CSS transforms.
   tantek: For transitions and animations, you do?
   sylvaing: No, I don't think any of those are killer.
   sylvaing: I don't think 3 months will make a difference. I want to
             prioritize and move on.
   tantek: If the option is between -webkit- and unprefixed, or -webkit-
           and nothing else, I prefer the first option. But delaying
           unprefixed will not delay the decision we're making.
   florianr: This seems USELESS to continue discussing, since this is
             not working here.

   glazou: Moz, MS, Opera, discuss together next week and bring a
           COMMON position to the WG.
   glazou: If we end up with multiple positions in our call next week,
           this is a *waste of our time*.
   glazou: So start that immediately in the mailing list.
   glazou: tantek, can we try that?
   glazou: Today we came for discussion, and I thought the 3 browser
           vendors had a common position.  Apparently that's not the case.
   glazou: So please get your positions together and bring it to the
           group, so we don't waste our time again.

   tantek: I've put our position on the table.
   tantek: I think the burden is on the objectors.
   tantek: Anyone who objects, please bring reasons for why they're
           opposing unprefixing, or why they're opposing LC.

   glazou: I suggest we adjourn on this failure status, and we work on
           the issues RIGHT NOW in the mailing list.
   glazou: I can't declare any consensus with a 9-8 vote.

Meeting closed.

Post-meeting IRC logs:
   http://krijnhoetmer.nl/irc-logs/css/20120215#l-508

Received on Wednesday, 15 February 2012 23:56:32 UTC