- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 02 Jul 2013 17:02:22 -0700
- 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
http://www.w3.org/2013/06/06-css-minutes.html
Present:
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
something.
<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
dependencies.
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