- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Jun 2016 19:30:07 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSSWG Charter
-------------
- The charter will have all specs listed here:
https://www.w3.org/Style/CSS/current-work except those that
are listed as re-writing or abandoned.
- GCPM and Box Model will be in the charter, even though
they're both listed as re-writing.
- There was a desire to move some of these to the incubation
process, but that conversation was postponed until after
the charter is renewed.
- The original proposal of just putting a date on Writing Modes,
which is relatively certain to go to REC was viewed as not
enough.
- There was a general feeling that the group had good control over
getting specs to CR, but that getting to REC was more
complicated.
- There was a split between those who felt that REC dates
would help the group improve and those that felt the dates
would be mostly ignored.
- astearns will make a proposal on the private mailing list to
continue the conversation with a goal of concluding on the
mailing list and renewing the charter before next week's call.
- TabAtkins will do the automation for charter update by the end
of the day.
Values & Units
--------------
- RESOLVED: Add this section: https://drafts.csswg.org/css-values-3/#compat
including using pixels as canonical length
- RESOLVED: Use dppx as the unit for <resolution>
- Everyone was asked to review which option is more readable from
this e-mail:
https://lists.w3.org/Archives/Public/www-style/2016Jun/0029.html
- Hopefully there will be a new publication resolution on next
week's call.
Logical keywords for float start/end vs inline-start/inline-end
---------------------------------------------------------------
- Florian and/or johanneswilm will start an issue on github
summarizing the previous discussion in order to move the
conversation forward.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jun/0112.html
Present:
Rossen Atanassov
Tab Atkins
Tantek Çelik
David Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brian Kardell
Philippe Le Hégaret
Peter Linss
Michael Miller
Anton Prowse
François Remy
Florian Rivoal
Alan Stearns
Johannes Wilm
Greg Whitworth
Steve Zilles
Regrets:
Rachel Andrew
David Baron
Daniel Glazman
Chris Lilley
Edward O'Connor
Lea Verou
Scribe: dael
CSSWG Charter
-------------
astearns: Let's start
<astearns> https://lists.w3.org/Archives/Member/w3c-css-wg/2016AprJun/0232.html
<astearns> http://w3c.github.io/charter-drafts/css-2016.html
astearns: Our current charter expires today. I don't expect we'll
have the new one ready by EoD but we may be close.
astearns: There was a lot of discussion on the ML that seemed to
conclude on most of the yellow items. We have a message
from Rossen on what we're going to do and that he'd make
the edits. No one has objected.
astearns: The main bit remaining is to come up with the new 2.1
section which is a lot more detailed than the previous
charter.
astearns: We'll have a list of all specs worked on with a concrete
description, the draft state, and an expected completion
date. We'll have to go spec by spec for completion and
come up with dates.
astearns: Is there anything besides dates that people would like
to discuss on the charter?
Rossen: Do we have ChrisL or plh?
astearns: ChrisL was at a conference. I haven't seen Bert or plh.
astearns: But I assume we'll have to talk to them about finalizing
bits and extending the charter if need be.
<astearns> https://www.w3.org/Style/CSS/current-work
astearns: In terms of dates we have ^ and it has sections for
stable, testing, refining, revisiting, and exploring
drafts.
astearns: I think the charter needs a list of all those in there.
We don't need re-writing or abandoned. Anyone disagree?
fantasai: Generated content is under rewriting. It's no longer
severely outdated. Basic box model should be in the
charter because ideally it will get worked on. I don't
know we'll have the resources, but you never know.
fantasai: Someone picked up tables.
Rossen: Tables had a reason to pick it up. No one suffers from not
having a box model. Having it on the charter won't force
attention.
fantasai: No, but it should be in scope. Basic box model is really
the description of the block formatting model. It does
need some updates. Margin stuff goes in there. I think
it should be in the charter but in a section saying
we're not expecting much progress.
astearns: I'm happy to have it in the charter. Makes sense if we
roll around to working on it.
astearns: I see in exploring template layout and generated content
for paged media.
dauwhe: There's still stuff in GCPM I'm interested in pushing
forward, though maybe just for pdf formatters. It's not
abandoned.
Rossen: We should start pushing some of these to the incubation
process. If they're not going through they should move to
incubation.
<gregwhitworth> agreed
Florian: What does it mean here other than I don't want to hear
about it?
TabAtkins: It means find people who do want to hear about it.
Florian: Someone is working on it today and there are
implementations, including me.
astearns: For today's purpose let's assume things any of us are
working on will go into the charter. We can move to the
incubation discussion in the future.
Rossen: Sounds great.
astearns: plh is now on the call.
astearns: plh, the last time we chartered we tried to do so
without dates and couldn't. Is there any chance we can
avoid doing dates today?
plh: If you don't put in dates I'll got to the ACs and be shredded.
It doesn't mean we need dates on everything, but for example
flexbox do you mean there's no desire to move to REC?
Florian: Desire doesn't mean when it'll be done. Saying things are
moving to REC or somewhere else we can do. Doing dates
exactly is hard.
plh: Flexbox is implemented everywhere. So you can't REC flexbox.
Florian: REC means interop and full test suite.
plh: The messaging we want is people should use flexbox and moving
the doc to REC is part of that.
fantasai: If you don't want to do dates you can take my notes from
IRC on last call.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jun/0026.html
<fantasai> scroll to bottom of the charter discussion
plh: I won't tell you what dates, but saying no dates is telling
me I'll be shredded into pieces by the AC because I can't get
the group to commit. I'll get calls from members saying it's
not acceptable.
astearns: What if we had a charter that only had dates for the
stable and testing items. Things in CR already and need
to get to REC with test suites.
plh: That would be perfect for me. I realize that we have a lot of
modules and they won't get to REC, but I need some dates.
Florian: Predicting CR is different than RECs.
Rossen: I think we need a balance. plh is bringing a good point
that there needs to be more date-driven commitment we need
to show and we're the ones who know what is progressing
fast and what is not. We need to be able to show a
legitimate enough commitment to the work we're doing in a
calendar format. If we're not able to that's our failure.
fantasai: glazou had a great idea that the date will be the end of
the charter for a bunch of things. So what will be REC
in 3 years: I only expect writing modes because no one
owns the testing process for any other spec. We can say
next year it'll get to REC and the rest of the stuff in
CR will stay and a bunch of stuff will get to CR. That
gives us 5 dates at least and the rest we can say we
don't know they'll stay in WD.
Rossen: The end of draft was something I brought up, it can be a
before or after, but it will be a weak message to the AC
or whomever looks at those dates. Having a strong
statement of what will/won't happen isn't the expectation.
These dates are a best guess. But not making a guess on
the charter would be sending a weak message. And saying
this is the only one that will happen for sure...who knows.
Maybe writing modes won't.
Rossen: If we don't have any dates we can re-prioritize as editors
feel responsible for them.
<fantasai> Does anyone have a problem with the dates proposed in
that link or do we need to keep discussing how we're
going to get dates?
tantek: I think what fantasai is saying is sensible. Since we have
some specs go to CR is there any historical data we can
look at to say this size module took x time and use it as
an estimate?
fantasai: It's pretty random. It's complexity, if it's layout,
implementor interest, time of person working on it.
tantek: Okay, I can believe that.
tantek: Getting out of CR is the harder thing to address. Getting
implementation reports and tests is historically the pain
point and I don't know how to predict that.
Florian: I'd draw a small difference. On the test side we don't
have a visibility problem; we know we're not doing enough.
For implementation I don't think, for example, Apple or
MS are putting out a roadmap for the features they're
putting out in the next 3 years. Without implementation
intention it's hard to predict. I'm not picking on them.
tantek: I don't think Google or Mozilla publish road maps either.
Florian: Not really.
Rossen: We can flip that around and say without a clear timeline
we won't commit because what the group is doing won't
terminate any time soon. Without a time table we don't
know when it will go anywhere. One way to invite more
commitments is to show commitments.
<bkardell> but isn't this a lot like chrome status or similar
things where the closer we get the clearer the picture
gets? when you are talking about multiyear plans of
anything it's just fuzzy, as long as we're getting
participation the best we can do is have a best guess...
who could reasonably expect more
<fantasai> Proposal:
<fantasai>
<fantasai> Writing Modes -> REC in 3 years
<fantasai> Other CR specs -> Stay in CR
<fantasai> All Refining specs -> Move to CR
<fantasai> Grid, Box Alignment, Selectors 4, Display 3, MQ4 ->
Move to CR
<fantasai> Scroll Snap, Pseudo-ELements 4, Inline Layout 3 ->
Likely move to CR
<fantasai> Other specs -> Stay as WD
astearns: fantasai your proposal talks about when things go to CR,
but I'm not sure if the charter needs CR dates, just REC.
plh: There's no definitive rule. But if you have no expectation to
ship anything in 3 years the AC will say you're kidding me.
astearns: So saying here's the one thing that will go to REC in 3
years won't work.
fantasai: I just pasted this list.
astearns: One date for one spec is not sufficient.
Florian: Than we need resources on tests.
tantek: We can have dates for CRs. There's nothing that says we
can only do dates for REC. In social web we had dates from
FPWD to REC. It's clear the REC is the clearest and we put
near the end of our charter there. We have control over
FPWD and CR.
tantek: The group has a good record of getting to CR. If you think
things can be done by the end of the charter, put that
quarter in for REC. For CR you can do that one quarter
before.
<tantek> How many RECs did we produce in the current charter
period?
Florian: astearns was saying not enough RECs are in that time scale.
fantasai: astearns, you can either be realistic or be hopeful.
astearns: I agree with your view that it's very likely only
writing modes goes to REC. But if we go with that view
that's all will be done. If we put in things like
flexbox that should go to REC we should put a date on it
and it might help push the testing.
Rossen: To add to that, at the end of the day shipping these specs
and getting them to a milestone is no different than
shipping software. Anyone who has done a substantial
product launch everything is date driven and without a
date you feature creep for the sake of feature creep.
Sometimes dates are artificial, but they are a really good
yardstick to assess progress.
Rossen: I don't think just saying put a fictional date is good.
I'd say put dates that we think might be correct and if we
flip the dates we flip the dates.
* fantasai notes that most of the work in this group gets done by
people who aren't date-driven. The only exception is
the Japanese effort on Writing Modes
<tantek> I like fantasai's ways / specifics of estimates for CRs.
then add 6 months for getting to PR/REC.
plh: Florian was saying we don't have implementor agreement, but
we have implementations of some of this stuff, such as
flexbox. Why not REC? Is it corner cases or test lack? From
what I know you can ship without the pieces missing and if
it's not stable you can ship a new REC. Saying we can't do
anything for 3 years....
astearns: For flexbox we're lacking tests. That's the main thing.
fantasai: We're lacking someone to collect the tests from the
implementations that are out there. Same with
backgrounds and borders.
astearns: And that's work someone should be actioned to do in the
next charter period.
fantasai: And do you put it in assuming you'll find someone or not.
astearns: I'd like to put it in assuming we'd get it done.
Florian: In regards to date driven scheduling, that assumes that
you have the team under control. If the people doing the
tests don't feel bound by the charter it won't work. Or
we put in one thing and the AC screams and plh can say if
you want it faster you should put resources.
astearns: So plh...Chris is out and he was the one working on
this, Rossen has some edits, we need dates and maybe the
section on deliverables. I doubt it will be done today.
Can we get an extension to next week?
plh: I'm not going to extend...without a draft charter in my hands
I don't want to go before the group.
Florian: Can we list the one spec as will get to REC and list the
rest saying if things go well they can but we're lacking
resources so we might not. Is that okay?
plh: I'm disappointed people are more interested in writing spec
than stabilizing the web. If you're telling me you're only
getting one thing something has gone wrong.
Florian: Yes, we have a problem.
Rossen: Tests aren't the only blocker.
Florian: But it's a big one
Rossen: Yes. And also bikeshedding tiny details is another fault
we have. We need to start moving forward more speedy.
Florian: But that's not blocking specs to CR
Rossen: It is. For example we take flexbox and we move all the
things added in the last two years out. That could be to
REC today. If we push fragmentation to level 2 we'd have a
REC. There's plenty of tests. That's one example of a
major spec which is arguably going to make a huge
difference that's held back by our own process.
Florian: You're claiming fragmentation is holding flexbox back?
Rossen: It's one of the things that has taken a long time.
astearns: And hasn't been impl everywhere.
<tantek> Please list the others that will get to *CR* as well.
FYI: schedule roadmap from SWWG:
https://www.w3.org/2013/socialweb/social-wg-charter.html#roadmap
certainly far from perfect, but we did link to a place on
our wiki with updated milestones for each deliverable
(which I'm now going to update some more :) )
<Florian> We've not even gone as far as agreeing Editors are
expected to review tests on their specs. I have strong
doubts we'll be able to designate volunteers for writing
tests.
astearns: So there's work to do on the charter over and above the
dates. TabAtkins you were talking automation on that,
can you do that in a timely fashion?
TabAtkins: The information was in the specs. It's simple for
plinss to grab that and put it in Shepherd and then I
can grab it. I can reproduce that list of tables with
up to date information.
plinss: The data is in Shepherd.
astearns: Can you put that together by EoD?
ACTION TabAtkins put together the information on specs by EoD
<trackbot> Created ACTION-779
astearns: I suggest we move the rest of the conversation to the ML
and we can come up with a list of dates to resolve on on
the ML so we can have a draft early next week.
<fantasai> +1 to ML for dates
Rossen: How long can we slip the charter expiration?
plh: 2 weeks? After that it will be hard to justify why the group
is publishing.
Rossen: But if we come back in two weeks we'll be fine.
plh: Yes. And it's somewhat my fault for not bringing this up
earlier.
Values & Units
--------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jun/0029.html
fantasai: There's two proposals for fragment URL handling, please
let us know the best. Canonical values needs review.
fantasai: There's a bunch of things that need review and I'd like
to hear from people more before we publish. The only
real decision is the one of the <resolution>
<fantasai> https://drafts.csswg.org/css-values-3/#compat
fantasai: To do calc() serialization we had to deal with what are
compatible units. So we added that section so we need a
resolution to add it and need to decide what should be
the canonical unit of <resolution>: dppx or dpi?
astearns: So that was all the issues...what to respond to?
fantasai: Canonical values for serialization...should we have this
section?
TabAtkins: Currently it's mostly undefined but CSSOM has lengths
to mm which no one does.
astearns: Is there something more browsers serialize to?
TabAtkins: Pixels.
astearns: Any reason not to?
TabAtkins: I think not. Should we add this to values 3 is the
question. It's stable so we need a resolution to add.
astearns: Anyone object to resolving on pixels?
fantasai: This is for the whole section, degrees for angles,
pixels for length etc.
<astearns> https://drafts.csswg.org/css-values-3/#compat
astearns: It's the compatible units section?
fantasai: Yes and some additional prose under each value type
which says which is the canonical unit.
<fantasai> Plus some prose in each section defining the canonical
unit
<fantasai> px for <length>
<fantasai> Hz for <frequency>
<fantasai> deg for <angle>
<fantasai> ? for <resolution> (TBD)
astearns: Anyone object?
RESOLVED: Add this section: https://drafts.csswg.org/css-values-3/#compat
including using pixels as canonical length
astearns: Anything else?
fantasai: We need canonical unit for <resolution>.
fantasai: We're proposing dpi or dppx as the canonical unit, but
no strong opinion.
plinss: If you're using px everywhere else you should use them,
but I'm not happy about px.
TabAtkins: dppx and dpi are related.
plinss: Whatever we do should be consistent.
fantasai: So dpi?
astearns: Yeah. I think dppx would be adding another factor.
TabAtkins: I don't know a way to test for this, though I'd like to.
I think this is arbitrary decision. We just want to
define it for completion.
astearns: That's a bit weird. I understand completion but not
having a use is weird.
TabAtkins: I was wrong. We have the image-resolution property.
TabAtkins: I don't think it's widely implemented but let me see.
Florian: caniuse.com doesn't know about it to it might be rare.
<gregwhitworth> caniuse is always behind though
TabAtkins: Chrome doesn't implement it yet.
Florian: It's not on MDN.
smfr: In webkit there's contributed code, but not enabled.
astearns: If it will be used it's fine to have.
RESOLVED: Use dppx as the unit for <resolution>
astearns: What's next?
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jun/0029.html
fantasai: Basically, we did a bunch of edits to support
resolutions and it needs review. On the readability
issue (above) we're evenly split.
fantasai: It would be useful to have more opinions on that.
astearns: Okay.
astearns: Everyone please look and see if one option is more
readable. Look at calc() serialization to see if it
makes sense. I expect an issue from glazou.
fantasai: We did resolve and need to know if the edits follow the
resolution.
astearns: I understand. glazou needs to be convinced it's the way
to go.
fantasai: Other than that everything is completed in the DoC. So
we should republish CR. The readability issue is the
last thing; the wording on the URL issue.
astearns: That's great. Hopefully we can resolve on the next call.
Logical keywords for float start/end vs inline-start/inline-end
---------------------------------------------------------------
astearns: Has this happened?
TabAtkins: Not yet.
<johanneswilm> I'm here as well
Florian: We were supposed to look. Primarily us but other people
way want to.
Florian: johanneswilm is on board, can we do it in 6 minutes?
TabAtkins: I doubt it.
Florian: Anything to help us for next week?
TabAtkins: Open an issue with a summary of the thread.
astearns: johanneswilm anything you wanted to add?
johanneswilm: It was a problem initially, but I thought we had
resolved through discussions before.
Florian: I think we had come close, but hadn't reached it. If you
want to dig and figure out where we ended it would be
useful.
astearns: Anything else anyone wanted to bring up?
fantasai: On the canonical units issue it would be good if zcorpan
could look and remove anything redundant from cssom.
astearns: Maybe you could reach out to him over e-mail or IRC.
fantasai: Sure.
astearns: So TabAtkins please do get the stuff we need to insert
into the draft charter done today. I will start the
discussion on dates on the ML soon.
TabAtkins: Will do.
astearns: Thanks everyone.
Received on Wednesday, 15 June 2016 23:31:08 UTC