[CSSWG] Minutes Telecon 2016-06-15 [css-values] [css-logical-props]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[CSSWG] Minutes Telecon 2016-06-15 [css-values] [css-logical-props]

Dael Jackson
=========================================
  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.