W3C home > Mailing lists > Public > www-style@w3.org > July 2013

[CSSWG] Minutes Tokyo F2F 2013-06-06 Thu AM I: CSSWG Priorities

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 02 Jul 2013 17:02:22 -0700
Message-ID: <51D36A0E.5050807@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
CSSWG Priorities

   Philippe Le Hégaret, W3C's Interaction Domain Leader, presented on the
   metrics W3C Management (W3M) has about the CSSWG's progress over the
   past charter period. Discussed what was accomplished and whether that
   fits with the CSSWG's own interests and priorities.

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

Meeting: Cascading Style Sheets (CSS) Working Group Face-to-Face, Tokyo, Japan
Date: 06 June 2013
<RRSAgent> http://www.w3.org/2013/06/06-css-irc


   Glenn Adams (Cox)
   Rossen Atanassov (Microsoft)
   Tab Atkins (Google)
   David Baron (Mozilla)
   Bert Bos (W3C)
   Rik Cabanier (Adobe)
   Jim Dovey (Kobo)
   Justin Erenkrantz (Bloomberg)
   Elika Etemad (Mozilla)
   Daniel Glazman (Disuptive Innovations)
   Rebecca Hauck (Adobe)
   Ivan Herman (W3C)
   Richard Ishida (W3C)
   Koji Ishii (Rakuten)
   Dean Jackson (Apple)
   Phillipe Le Hegaret (W3C)
   Peter Linss (HP)
   Cameron MacCormack (Mozilla)
   Larry MacLister (Adobe)
   Thierry Michel
   Israel Noto (Adobe)
   Liam Quin (W3C)
   Simon Sapin (Mozilla)
   Dirk Schultze (Adobe)
   Alan Stearns (Adobe)
   Shane Stevens (Google)
   Leif Arne Storset (Opera)
   Jet Villegas (Mozilla)
   Masataka Yakura
   Kazutaka Yamamoto(NTT)

CSSWG Priorities
Scribe: fantasai

   <plh> Slides: http://www.w3.org/2013/Talks/0606-css-plh/#/
   plh projects title slide
   next slide lists RECs and dates
   plh: Only 6 RECs
   Last 12 months:
      1 REC (MQ),
      2 CRS (flexbox, conditional rules)
      18 WDs updated
      FPWD x 5

   Bugs: last 12 months
     Transforms, bugs from 11 to 6
     Transitions from 29 to 25
     Animations from 45 to 20
   plh: Huge controversy over these, staring with Opera suggesting to
        remove prefixes
   glazou corrects the record
   plh: Decided to move faster, but this is the result
   plh: Only 5 bugs fixed for Transforms, 4 for Transitions, 25 for Animations
   plh: Animations is more than 50% better
   * sgalineau would disagree with this statement
   * sgalineau all bugs are not equal; some of the animations bugs left
               are still around because they're hard
   dbaron: some metrics are a little funny. Went through bugs, most
           deferred to next level
   plh: Why not in LC?
   dbaron: Because 2 left
   plh: Fact is, drafts still not in LC despite controversy last year
   * sgalineau accepts blame for underestimating remaining animations work.

   plh: If we look at priorities from December 2011, these are top 3 drafts:
        css3-background, css3-ui, css3-values
   plh: Still in this cycle
   plh: Think css3-background still held up on implementation issues and tests
   plh: css3-ui went backwards rather than forward
   plh: css3-values went forward
   plh: One metric, not only one

   plh: Last fall, CSS chairs committed a survey
   plh: In terms of priorities, top 5 were flexbox, transforms, animations,
        conditional rules, transitions
   plh: Coremob profile
   plh: CSS2.1, MQ, Selectors 3, Color, Flexbox, Transforms, Animations,
        Transitions, CSS3 Text, CSS3 Fonts, CSS3-backgrounds and Borders,
        CSS3 Images, CSS3 Values, CSS Device Adaptation, CSSOM
   plh: Normative references HTML5.0
   plh: Fonts, Images, Values, Selectors 4, CSSOM, CSSOM View, css3-ui,
        Style Attr, Fullscreen (?)
   plh: Some of this can be tweaked
   plh: But some, e.g. View Module, can't break the dependency
   plh: Style Attributes
   fantasai: Style Attributes stuck on one failed test
   plh: Is it important test?
   fantasai: No.
   plh: Then send a PR request soon

   glazou: Whatever you do, browser vendors will implement and ship it.
           What's the point of breaking the dependency?
   glazou: Browser vendors will implement, ship, try for workable interop,
           and the spec describing the behavior of the current market will
           not be available
   glazou: I find it a little bit sad
   glazou: We had this discussion in AC form, chairs, wrt what is a
           normative reference
   glazou: I said a spec like HTML5, which is based on living standard,
           needs an intermediate status between informative and normative
   glazou: That is another way of solving your issue

   glazou: If I take that list, to finish everything including tests,
           is enough work for this WG for the entire year
   glazou: You want us to do everything by 2014?
   glazou: Each member of this WG has individual strategy and priority.
           if I read your slides, I think you forget it.
   dbaron: Another problem is that REC track doesn't reflect how industry
           really works
   dbaron: Talk of reforming REC track for a while
   plh: Several ways to approach this. One is to remove dependencies from HTML5.
   plh: Third question is what does it mean to be normative ref for HTML5
   plh: Some of those references, perhaps part referenced by HTML5 is
        perfectly stable and implemented.

   fantasai: you could solve most of this is to allow REC to normatively
             reference CR, treating PR like transitional phase just like LC.
   fantasai: This is relatively minor change to the process, would solve the problem.
   plh talks about stability
   dbaron: This is a discussion in the TAG list
   dbaron: I think the way W3C manages normative references is broken
   plh: Do believe this has process problems

   <sgalineau> glazou, I accept blame but it's not like i did nothing either.
               Same for dbaron. I think we made a decent effort to pick those
               back up from where they were… It sounds like we were lazy or
   <glazou> sylvaing, I will make sure plh understands that, no worries

   plh: If I look at F2F agenda, this is list of things that were on the agenda
   plh projects some questions
     1. Are we getting the right balance between day-to-day borwser
        implementers needs and what's needed?
     2. What's happening with Fall 2012 Priorities?
     3. Will CSS prevent HTML5 from moving to REC by 2014?
     4. What is WG expectation for its next Charter?
   plh: Last, main question we have,
   plh: This group needs to be rechartered, what's the expectations?

   glazou: First one, you should define better what's needed. What's needed
           for who? This WG? Other WGs? The Press? I don't care about the
           Press. We make technology for billions of people. I don't care
           about their opinion. We should make sure everything works.
   glazou: browser vendors are the deciders in this WG
   glenn: We have input from others
   TabAtkins: input, yes, but ultimately what browsers implement is what
              we spec

   glazou: 2nd point, TTA and Flexbox were highest priorities during most
           of our conference calls during 12 last months
   plh: Only 6 bugs?
   glazou: Do you have any idea how complex these bugs are?
   glazou: Take a look. Don't rant.
   * stearns notes that the interaction between TTA and !important was a
             big topic yesterday

   glazou: 3rd point, well, the day the HTMLWG pings us to tell us they
           need that spec to be a REC, maybe it will change
   glazou: I told HTMLWG and W3C more than a year ago that we have problems
           with normative refs of HTML5. No response.

   glazou: WG expectation, I don't know. We did not discuss next charter yet
   glazou: Mine is to reduce the number of specs we're working on
   glazou: Priorities can change a lot, and strategies can change a lot,
           over 2 years.
   glazou: E.g. Firefox was not in mobile space before. Now they are working
           a lot on apis
   glazou: If I knew what was going to happen in CSS world 2 years from now,
           would be billionaire
   glazou: So, do some cleanup, try to serve best CSS and the Web, help the
           HTMLWG if we can. But don't know if we can solve everything.

   glazou: Date of 2014 has been set by HTMLWG without looking at the
   glazou: After choosing date, look at dependencies. It is not fair.
   TabAtkins: Even if we ignore dependencies, there is no way HTML5 can hit
              REC in 2014 without bending rules.
   TabAtkins: You're going to need like a million tests. It's not going to
              happen in 1.5 years.
   glazou: They lowered expectations.
   TabAtkins: By honestly reaching REC like everyone else does, will need
              to lower what it means to be REC.
   TabAtkins: Doesn't make a difference if we are a process-holdup. They
              have a process-holdup anyway.

   glenn: I don't agree with Daniel's characterization of how this group
          should work. Should take into account people who are using our
          specs, including ppl who normatively reference our specs.
   glenn: Think it's impractical perspective.
   glenn: Would encourage us to not take that we work in a vacuum.
   glenn: Of course, since volunteer activity, depends on people putting
          their energy into specs customers care about. Should request
          customers to bring resources to WG if what we do isn't funded.
   glazou: One of the largest users is Ebooks. And we have an acceptable
           cooperation with IDPF.
   glazou: I think not perfect, but acceptable cooperation.
   glazou: They send us requests, they discuss CSS on their group.
   Bert: You and I are working on it, but not rest of WG
   [side discussion of css3-page, css4-page]

   glazou: Where is HTMLWG to discuss with us their needs?
   glazou: Problem is communication
   glazou: I find it easier to ping users, outside W3C, than to ping some
           other committees within W3C.
   [discussion about cross-wg communication and HTML5 date]
   plh: If you tell me none of those specs reach REC by 2014, that's one
        kind of input.
   dbaron: Why do members care about pushing to REC?
   dbaron: Doesn't have any benefit for us
   TabAtkins: REC and interop don't have a strong correlation.
   plh: That's one reason, other people have other reasons.
   dbaron: It's the reason why people here do the work.
   plh: You're trying to get the documents perfect before REC. You won't
        get there.
   glazou: Documents that don't move now are blocked on difficult technical
           issues (other than style attr).
   glazou: Open issues for TTA are really complex
   glazou: Question of availability of people. Only a few experts on each topic.
   glazou: Even if a large group, made of subgroups. You seem to forget that.
              are interested in working on.
   Bert: Why don't we finish things we promised to finish 5 years ago?
   glazou: Ask them! (gestures to WG)
   <jdaggett> I do think we lack the ability to prioritize some specs
   <jdaggett> We seem to work as a group on whatever individual members
   <jdaggett> and that effectively crowds out work on other things

   TabAtkins: Can't go to PR without testing everything in the spec
   glenn: No, don't need to test everything in the spec
   TabAtkins: Then I have no idea what you mean by test suite.
   plh: I've never seen browser vendor that has full test suite for
        everything they implement
   <jdaggett> Why don't you need to test what's in the spec?!? That makes
              no sense.
   <jdaggett> existing browsers have lots of legacy stuff
   <jdaggett> but the quality of testing efforts is vastly improved over
              the past five years

   dbaron: Philippe admits that REC doesn't need to be perfect
   dbaron: One problem we have with process is that we want to maintain
           specs, and continue to maintain them as ppl bring up issues
   dbaron: Problem with process is that it's much harder to update a REC
   plh: Don't see why
   plh: Just need to have a test for each change
   plh: You are setting a bar for REC that is way too high
   dbaron: You act as though publishing a doc is trivial thing
   dbaron: Publishing CR requires editor to spend days pinging various
           people for permission.
   dbaron: It's not worth a week of my time to get document published on /TR

   <dbaron> LC of css3-conditional took 28 days from publication request
            (November 15) to publication (December 13)
   <dbaron> so it's not just CRs
   <fantasai> dbaron, that was largely because I didn't notice that the
              document wasn't published when it was requested to be published
   <fantasai> dbaron, and so wasn't able to follow up and get it published
              the next day
   <dbaron> it didn't help that there was a 5 day delay from 15th to when
            it was supposed to be published, and then a week from noticing
            that it wasn't published to it actually being published

   glazou: Pages of spec:
             12 pages for CSS1
             258 for CSS21
             ~4000 for CSS3
   glazou: It's a lot of work.

   Bert: Seems like we always want things to be in flux.
   TabAtkins: Want to always be refinining / correcting things.
   TabAtkins: 100% stability is an illusion
   [discussion of bureaucracy]
   [and how to allocate resources to it]

   glazou: 2 passing implementations for each testable assertion
   glazou: That's the way it should be. Otherwise test suite has no value.
   glazou: I understand HTML5 has different requirements. And I agree with
           Tab that that test suite has no value. It's pure marketing.

   jet: Sounds like W3C wants REC documents
   jet: Group says cost to REC is too high, and CR is good enough
   jet: Perhaps the product expected of this group should change
   plh: If I go to AC and say CR is the new REC, AC will not happy
   Bert: We used to have no testing requirement
   Bert: Process changed
   glazou: So process can change. These people are telling you process
           needs to change.
   plh: You're saying we should have no test suite requirement, other say
        they want more testing requirement.
   glazou: HTML has lower expectation because want to release fast,
           because marketing impact and press, releasing HTML5.
   glazou: You lowered the bar to meet that date
   jdovey describes IDPF process, which is fast and loose
   liam: Pragmatic, and on programming end pragmatism is important.
         But e.g. governmental standards requirements are different

   glazou: These 4 questions
   glazou: To answer these 4 questions, we need to know what you want.
   glazou: What does W3M want about the priorities?
   glazou: What do you think we should do wrt dependencies?
   dbaron: Why does W3M have to make those decisions?
   glazou: Don't say they make decisions, just want their input.
   plh: ...

   r12a: IDPF has been really keen on vertical text and ruby
   r12a: Ruby CSS module is way off the bottom of the scale in terms of
         work being done.
   r12a: I know that's partly because ppl don't have time to work on it
   r12a: But what's the process the WG has, for discussing with IDPF,
         and allowing them to raise what they want?
   glazou: Question I discussed with Markus Gylling.
   glazou: We don't have a real process.
   glazou: We discuss technical issues sometimes, but not really how can
           we answer, address important requests from their point of view.
   glazou: E.g. ruby, which is best example
   glazou: We have no one
   glazou: When we tell them we have no resources to work on that right now,
           they say they'll wait. Members unwilling to join this group
   ivan: digital publishing interest group  ...
   ivan: Not chartered to develop specs, but may come up with priorities
         and requirements, and maybe find ppl to do the work here.
   r12a: What is the process for CSSWG for re-evaluating priorities and
         discussing stakeholder requirements?
   dbaron: Need to communicate that we don't have resources, and let them
           work on it if they want to put those resources in.
   Bert: Bert: Daniel and David refer to new requirements that we don't
         have resources for. But in many cases people are just waiting
         for things that we already had in our charter.
   glazou: Strategy of the market changes

   Ivan: Whole issue of membership fee etc.
   Ivan: Let's say 3-4 ppl form task group within this wg to develop
         technolgy XYZ
   Ivan: Do you have structure of task forces?
   Ivan: What's the decision procedure?
   glazou: We have FXTF with SVGWG
   Ivan: Can they work on it and push to REC?
   glazou: Sure
   jdovey: What happens if TF comes back to WG and 80% WG says they don't
           like it?
   dbaron: Need to get feedback earlier
   <jdaggett> um, i don't think task forces are magic, you need people
              capable of actual tackling issues with developing something
   * fantasai agrees with jdaggett
   <jdaggett> the EPUB way of coming up with a laundry list of "we needs"
              is actually very disruptive
   Ivan: We have a community not browser vendors, willing to do work,
         will they be shot down because browsers don't care?

   dbaron: If you have a need for something in 6 months, but don't care
           about quality for stability of long term, that's an issue.
   jdovey talks about implementing ? in WebKit and politicking and sitting
          on the patch and stuff.
   jdovey: We keep running into roadblocks
   <jdaggett> maybe because shoving code for a feature into webkit before
              ironing out the spec is not a constructive approach...!
   dbaron: I think you can't say you want something in 6 months and the
           not put the work into it to really do it right
   dbaron: Having a patch in WebKit is different from having a standard
           that can be interoperably implemented and everyone agrees with.
   jdovey talks about JLREQ requirements, and trying to implement those.
   jdovey: [..., ruby, ...]
   dbaron: Don't see how you can implement a requirements document.
   dbaron: If you want a technical spec, need to describe what the technology is
   jdovey: Describes how characters should be laid out
   dbaron: Gives requirements, not a model
   <jdaggett> and you have to make that fit into existing features!!!!!!!!!!!!!!
   <jdaggett> example: webkit's crazy two-path text handling structure

   plh: Current charter is coming to expiration
   plh: Could say, perfectly happy way we are working
   plh: You guys are doing the work
   plh: I cannot just say, this is what you will do, you have no choice.
        You'll walk away if I do that.
   plh: Think you need to figure out what you want to achieve
   plh: If the group's believe they're doing what they want to achieve, and
        AC doesn't agree, then AC has to figure out who to appoint to the WG
   dbaron: he's talking about how WG members are appointed by their AC reps
   dbaron: Which is mostly an administrative fiction.
   plh: Ok, I don't want to hold this group further. You guys have work to do
   dino: what was the point of this discussion?
   dino: Not trying to be rude, really want to know
   plh: Just want to make sure you understand what you're doing and are
        happy with how you're operating.
   plh: And if ppl come to me with complaints, I will redirect them to you
        saying you're doing this intentionally :)

   <jdaggett> I think lots of folks will always be dissatisfied because
              their individual feature request isn't satisfied.

<br duration="900s">
Received on Wednesday, 3 July 2013 00:02:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC