[CSSWG] Minutes Telecon 2017-01-04 [css-grid] [css-scroll-snap] [css-speech] [CSS2]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


F2F Meetings
-------------

  - The group was reminded to add topics to the wiki for next week's
      F2F.
  - The wiki for the Tokyo F2F is up.

Grid
----

  - RESOLVED: Accept the proposal explained here:
              https://github.com/w3c/csswg-drafts/issues/523#issuecomment-268095890
  - The proposal to address implied minimum size for grid items
      (https://github.com/w3c/csswg-drafts/issues/283#issuecomment-268125974)
      hasn't been reviewed enough yet and will be moved to the F2F
      agenda.

Fix errors in examples (scroll snap)
------------------------------------

  - RESOLVED: Re-publish Scroll Snap CR with these changes
              (https://github.com/w3c/csswg-drafts/commit/7a20d00238aac3ddbdd8d5dd7e74ff81dd29ba76)

css-speech issues
-----------------

  - RESOLVED: Make the change to speak value properties (to
              auto|always|none) and inform the a11y TF.
      - There is a possibility this resolution will need to be
          reversed because it was discovered later that webkit does
          already implement the speak property.
  - Having the auto value of speak also respond to the visibility
      property needs feedback from the a11y task force and from more
      people in the a11y community to ensure this change would be
      beneficial for everyone as there is a wide variety of reasons
      for using the speak property.

Proposed process for maintaining CSS2
-------------------------------------

  - The group reviewed the two proposed approaches for maintaining
      CSS2 (available here:
https://lists.w3.org/Archives/Public/www-style/2016Dec/0015.html)
  - A third approach was discovered over the call to have a Note
      that contains the items the WG has agreed to, but are not
      ready to pass the PR criteria and be in the PR CSS2.1 spec.
  - There were still concerns over how comments will be made and
      tracked on these two specs that weren't addressed by any of
      the proposals.
  - The group ran out of time on the call to reach a conclusion so
      this topic will be added to the F2F agenda. Also, fantasai
      will send a summary to the mailing list.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jan/0004.html

Present:
  Rachel Andrew
  Rossen Atanassov
  David Baron
  Tantek Çelik
  Alex Critchfield
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brian Kardell
  Peter Linss
  Myles Maxfield
  Rachel Nabors
  Anton Prowse
  Melanie Richards
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth
  Steve Zilles (IRC Only)

Regrets:
  Tab Atkins
  Angelo Cano
  Brad Kemper
  Vladimir Levantovsky
  Michael Miller
  Florian Rivoal
  Jen Simmons

Scribe: dael

F2F Meetings
============

  astearns: Let's get started. Does anyone have anything extra to
            add?
  astearns: Couple F2F things to start.
  astearns: On F2F is you're coming to Seattle and haven't added
            yourself to the list, please do.

  <astearns> https://wiki.csswg.org/planning/tokyo-2017
  astearns: Hiroshi put together the Japan meeting page so people
            can add to that as well.
  astearns: Please update the pages with your plans. If you have
            anything to add to the F2F agenda please do. It looks
            pretty full, but always glad to have more things.
  Rossen: The same applies for the Houdini attendance list.
  astearns: Yes, and Houdini topics would be good.

Grid
====

Stretching image grid items in both dimensions
----------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/523
  <fantasai> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-268095890
  fantasai: I wasn't on the last call, but there's a proposal in the
            github issue.
  fantasai: I can go over it if there are questions.
  astearns: Has anyone reviewed it and has questions or concerns?

  astearns: I saw jensimmons was okay with the direction.
  <rachelandrew> this makes sense to me
  <rachelandrew> I feel like this is a straightforward thing to
                 explain
  astearns: So...what do you think fantasai? Should we resolve on
            your proposal since the small amt of feedback has been
            positive.
  fantasai: That's cool. We can resolve if people object in the next
            week we can reopen.
  fantasai: I'm happy to resolve and move forward and take our time
            in shipping the new spec.
  astearns: jensimmons and rachelandrew are okay with this. From
            what I've looked over it's good to me.
  astearns: Proposed resolution: We accept the proposal in the
            linked comment. Objections?

  tantek: Can you summarize if there's any minority opinions in the
          thread?
  astearns: This has been going back and forth a bit. I'm not sure
            I'm prepared to summarize. fantasai?
  fantasai: Basic issue is that grid spec as was in the summery...if
            you put a grid item and assigned auto size in a fixed
            size grid cell it would take exactly that size. You
            could change behavior using alignment. Made sense for
            non-replaced, but things with aspect ratio this wasn't
            expected.
  fantasai: We came up with using normal as initial value and have
            aspect ratio preserved. But that no longer equated to an
            alignment keyword. Normal should be the default.
  fantasai: Problem with new normal since it didn't map it meant we
            now have 3 sizing behavior that you can switch between
            and you couldn't get aspect preserving as a default. You
            can't get it with center alignment because it would
            trigger different behavior. So we couldn't go with the
            previous solution.
  fantasai: So we came up with this behavior summarized in the
            comment I linked to. We took all the constraints,
            started over, and had this solution.
  tantek: Reasoning makes sense. Were there other opinions remaining
          or was this a check for reasoning?
  fantasai: It's please check our reasoning and if there's a
            different solution let's discuss. This is CR level so
            everyone should notice the change before we do it.
  tantek: Yes. This is exactly the kind of change to make in CR. It
          looks like Mats is okay with it.
  fantasai: We haven't heard from the Igalia folks. I'm happy to
            re-open if the implementors on the list have additional
            concerns.
  tantek: I'm fine with that. I like how you took the constraints.
          It doesn't sound like there are minority opinions
          remaining. You took them all into account.
  fantasai: We tried.
  astearns: Any other concerns? Objections?

  RESOLVED: Accept the proposal explained here:
            https://github.com/w3c/csswg-drafts/issues/523#issuecomment-268095890

Implied Minimum Size of Grid Items
----------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/283
  <astearns> https://github.com/w3c/csswg-drafts/issues/283#issuecomment-268125974
  fantasai: This one has been going back and forth. TabAtkins and I
            decided to take a step back and look big picture. We
            looked at the original goal which was prevent small
            images or items shrinking to nothing in the presence of
            larger content.
  fantasai: We wanted to avoid overflow that would make things more
            difficult to read. Let's not have overlapping content,
            let's have overflowing.
  fantasai: We said the only kinds of tracks that need to be
            influenced are auto-size. If you have fixed size we
            don't want to deal with auto min because it will overlap.
  fantasai: Fix sized should apply normal rules. We wanted to
            influence automatic tracks.
  fantasai: Proposed change was clarify that fixed track are clamped
            based on maximum size, not layout algorithm. Second is
            min-width: auto or min-height: auto only resolve to auto
            min size if item span one track with automatic.

  astearns: Has there been any response from Igalia?
  fantasai: No responses at all.
  astearns: Based on issue and comments do you think your proposal
            will satisfy their concerns?
  fantasai: I think it will because it will have a much simpler
            influence. I'd like their feedback before we finalize.
            But it would be good to get if anyone else has concerns
            or needs more time.
  astearns: Has anyone looked?
  Rossen: I wasn't able to, but would like to. If we can wait a week
          I'll take a look at it.
  astearns: We can add it to the F2F and I can ping Manual to come
            back to the thread and give comments.
  fantasai: Sounds good.

Intrinsic size of replaced elements incorrect
=============================================

  fantasai: I think this should push to the F2F.
  astearns: Sounds good.

Clarify how letter-spacing and word-spacing should affect tab-size
==================================================================

  fantasai: I responded in the message so I'm waiting on dbaron
  dbaron: I need to go write a bunch of tests.

Fix errors in examples (scroll snap)
====================================

  fantasai: There were errors in examples based on changes we made
            when merging.
  fantasai: The examples were missing hte required axis element. I
            wanted permission to republish with these fixes. No text
            changes. Just fixing these.
  astearns: So a resolution to republish. Objections?

  RESOLVED: Re-publish Scroll Snap CR with these changes.

css-speech issues
=================

  <astearns> https://github.com/w3c/csswg-drafts/issues/510
  fantasai: Two issues on speak property.

  fantasai: First is naming. Does anyone impl the speak property?
  fantasai: I'll take the silence as no.
  dauwhe: I looked at epub and didn't see any.
  <gsnedders> I think Presto may have had one. But that may have
              gone by the last release of Presto.
  <gsnedders> Though that's mostly a historical note.
  fantasai: So the suggestion was the auto|always|none were easier
            to understand properties. I think we should take it.
  <dauwhe> +1
  astearns: Looks good to me.
  astearns: Objections?

  Rossen: I would remind you that this spec is supposed to be worked
          on by the TF. So it would be good to give them a heads up.
  astearns: What's the venue for that TF?
  Rossen: I can send links.
  Rossen: Since we agreed to work together it would be good to let
          them know.
  astearns: Would it be better to loop them in before we make the
            change or make the change and inform them?
  fantasai: I would lean to make the change since the a11y suggested
            it.
  Rossen: I wouldn't hold the resolution. An FYI is nice.
  astearns: Proposed resolution: Make the change to speak value
            properties and inform the a11y TF.

  RESOLVED: Make the change to speak value properties and inform the
            a11y TF

  <astearns> https://github.com/w3c/csswg-drafts/issues/511
  fantasai: Next was that the auto value of speak should also
            respond to visibility property.

  myles: I'm looking at webkit and we at least parse the property. I
         don't know what we do with it.
  astearns: The speak property?
  myles: Yes.
  myles: I can't look at what it does on the call.
  fantasai: Okay.
  fantasai: So we'll make that tentative.

  astearns: So auto value responding to visibility.
  astearns: Seems reasonable.
  fantasai: We might want to ping the TF and see what they think.
  astearns: Seems like something they should weigh in on.
  astearns: Though it came from a11y people.
  bcampbell: I think it would be good to have other people review.
             Different people with different disabilities use these
             tools differently. I can show it to some people here.

  ACTION Bo to get more feedback on
https://github.com/w3c/csswg-drafts/issues/511
  <trackbot> Created ACTION-807
  ACTION Rossen to get the a11y TF people to look at the appropriate
         issues.
  <trackbot> Created ACTION-808

  ACTION fantasai create a a11y tag on github.
  <trackbot> Created ACTION-809

  myles: We implement the property.

  astearns: fantasai are you okay with not resolving on the second
            issue?
  fantasai: Yeah, as long as there an action to get feedback.

  <fantasai> created the Needs a11y tag, has follow-up request to WG

Proposed process for maintaining CSS2
=====================================

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Dec/0015.html
  astearns: proposal^
  astearns: Anyone have comments? Responses?
  * tantek reads
  gsnedders: Should someone summarize?
  astearns: Yes.
  gsnedders: I'll try.
  <tantek> I'm a fan of semantic versioning

  gsnedders: The question is what should we call future revisions of
             CSS 2. 2.x? New editions of 2.1?
  gsnedders: That's the fundamental question. All other issues come
             around that.
  gsnedders: What I said and Florian agreed calling it 2.1 versions
             makes it clear that no one should look at the old
             version. So 2.1 doesn't become referenced by rec, but
             no one should look at it. Especially since in principal
             we're not introducing anything that would cause
             incompatibility issues.
  astearns: tantek on IRC likes semantic versioning, but that does
            have the problem of linking. If we have 2.X you're
            linking to a specific thing, not the latest.
  tantek: I thought that's why we redirect CSS 2 links.
  fantasai: Yeah.
  tantek: If we're just doing bug fixes we can do 2.1.x but if we're
          doing a breaking change, which is a judgment call, but
          then I think it makes sense to bump the number to make it
          clear and put the giant warning at the top that there's a
          newer version.

  astearns: fantasai?
  fantasai: I don't have a strong opinion. I do think we shouldn't
            spend that much thought on naming past this discussion.
            There should be no more judgment calls. We should pick a
            numbering scheme now and then go.
  <dbaron> I thought we already picked, but now we're being asked to
           reconsider?
  <gsnedders> dbaron: AFAIK, 2.2 is currently called 2.2 by default
              with no WG input
  <dbaron> gsnedders, we did discuss it
  <gsnedders> dbaron: oh, okay :)

  fantasai: Another relevant question is do we want to used the
            proposed edit recommendation or do we want several rec
            track documents that replace each other. That's
            something to think about.
  fantasai: In either case we can go the same way wrt naming.
  tantek: On that question, one thing the AB did get done and I
          expect it to get published, is the process 2016 which
          fixes the bug, or the regression, that required any
          editorial change to go to AC. So anything editorial we can
          do without an AC vote.
  fantasai: But a lot of our changes are substantive. CSS2 isn't
            helped by that.
  tantek: Right.
  tantek: I guess we're always doing substantive changes?
  fantasai: I would say the majority are normative. Bug fixes,
            things we realize will block something we want to do in
            level 3. There's a number of reason we've made changes.
            Clarify, fix error, tighten prose. Very few fixes are
            purely editorial.
  fantasai: The process I propose is 2 ED. One with the PR ready
            changes and one that's the trunk that has all the
            changes we've decided to make and we'll cherry pick
            fixes from one ED to another.
  fantasai: The process to do that is either the PR process or
            WD|PR|REC and have a note to obsolete.
  tantek: Second draft sounds like a CR draft. If the group has
          consensus and there's intent to impl it sounds CR ready.
          Are there other categories?
  fantasai: Those are really the only two.
  tantek: Then those labels already communicate the behavior we're
          doing.
  fantasai: But they need to exist in parallel and cycle.
  tantek: Yes. That makes sense. And using the process you suggest
          makes sense.
  fantasai: We've got two decisions. Which process for updates and
            what do we call it.

  <gsnedders> Somewhat off the direct topic, but should we have
              changes to CSS 2 that don't have tests? Should we
              require tests for each change?

  gsnedders: My understanding that publish to CR you're meant to
             have evidence of wide review. Which I thought meant
             outside the group.
  tantek: I think the first time you publish to CR it requires wide
          review. I'm not sure if the intent is that's required for
          subsequent.
  gsnedders: My reading is that it is.
  astearns: At least of the delta between the CRs.
  <glazou> not sure the Process makes any difference between a
           "first CR" and a subsequent CR

  astearns: And gsnedders you had a question on tests in IRC. I
            think the answer is yes where possible.
  gsnedders: Yes. Most of the changes we made to CSS2 were fairly
             small and changeable.
  fantasai: In a lot of cases we'll see it's a problem, we decide to
            fix, and someone needs to write a test. I think the
            changes section of the CSS2 needs to be an impl report
            with links to tests. Then it's clear.
  fantasai: That's kind of a record keeping things. Whatever we're
            doing we have to update the REC. There's two ways to do
            it. Standard procedure to refresh the REC. Other one is
            to publish a FPWD and then jump to PR, get and AC review
            on that, and go to REC with that, adding a not to the
            old REC. In which case you need a new short name. BUt
            then you get a WD without AC review
  astearns: I haven't thought through this a lot, but I don't want a
            proliferation of short names.
  <dbaron> I don't feel like we'd have a huge number of shortnames.
  <dbaron> We should get all the pieces of 2.1 replaced by modules
           after a reasonably small number of these revisions...
  <gsnedders> https://www.w3.org/community/w3process/wiki/Rectracktimeline
              is kinda relevant here when it comes to going down the
              the FPWD route

  tantek: I want to understand what in an ideal world the right
          thing would look like and then the delta between that and
          what you feel compelled to do due to process and I'd like
          to take those as feedback on process.
  fantasai: I think for us for CSS2 as editors we really need two
            copies of the spec; one is REC qualified and one working
            toward that that includes all the changes. As soon as
            any change hits all the checkboxes it ports into the REC
            ready copy.
  fantasai: Both of these drafts should be on TR somewhere easy to
            update. I think both processes give us what we want. The
            PR is clearer I think, but we need a
            CSS2-things-working-on that's a perpetual WD.
  fantasai: The other one will have to be on a month long minimum
            cycle due to AC process. That's fine, though.
  tantek: Perpetual WD sounds like living doc.
  astearns: It's non-REC since we don't want that doc to go to REC.
  fantasai: Maybe it's a note. 2.1.next WG note. We cycle CSS 2.1
            into PR and back every month.
  astearns: We have a note that's proposed errata and things live
            there until edited in.
  gsnedders: Should the note be in TR? Normally errata are not.
  fantasai: Technically ED are unofficial and we should have
            official drafts of things we're working on. Historically
            we have a hard time keeping that up to date because the
            process to publish, but that's been fixed. We can push a
            draft to TR in 5 minutes. With bikeshed you do a command
            with the resolution link.
  fantasai: So all of our drafts should be 100% up to date and no
            one should look at ED unless you're in the middle of a
            change and you're discussing it with the person you're
            working with. We're not there, but we should get there.
  tantek: As soon as you have consensus on something it should go to
          TR.
  gsnedders: From that PoV we should put in TR a copy of CSS2 with
             the errata applied.
  fantasai: Yes, it should be a full copy of CSS2 with errata
            applied, not a list.
  astearns: Note can be a full copy with the errata applied and a
            list of the changes so they can be reviewed.
  fantasai: And we have the list and it just needs to be cleaned.
  astearns: Every time we push something to the PR it gets taken off
            the list in the note.
  tantek: Once both published.
  gsnedders: What's the point of notes instead of drafts.
  astearns: A note shows this is not a doc we're planning on taking
            to rec. It just gets republished on TR and the process
            has notes already in it.
  * gsnedders feels like he's missing something here
  fantasai: And there's a copy that's going to rec that will cycle
            back and forth.
  tantek: You can look at the note as where we're incubating the
          edits to CSS2.1
  fantasai: Yeah
  tantek: We're putting there until we get impl.
  astearns: And gsnedders, the only reason it's a note is that it's
            already in the process as a document that will not go to
            REC itself.
  tantek: This makes sense to me.
  tantek: You've got your ED that's whatever the editor drops in
          there. You've got your note that reflects the consensus of
          the WG but may not be implemented and you've got your PR
          that is tested.
  gsnedders: Does it make sense to have an editor draft? I thought
             PR was equivalent to PR.
  fantasai: But we've taken CSS2.1 to that part of the process. It
            doesn't have to go back to WD to edit.
  tantek: We're saying that everything in there has two interop so
          it has exited CR.
  gsnedders: My point is can't we just make it a WD of something
             that's gone to REC> IT's a WD that will go to PR.
  tantek: You don't need the extra step.
  gsnedders: I was just making a point of does it make sense.
  <gsnedders> But don't we have a PER and a REC with the same
              shortname, in principle, at the same time
  fantasai: It makes sense that...the stuff that's not ready needs
            to exist on the TR space. WE can't have a single draft
            exist in two states at once. ANy spec as a shortname can
            exist only in one state. WE need two states to exist so
            we're prop to have the one represent impl status be
            CSS2.1 and have it go between PR and REC depending on
            when AC looks. It will get two impl. Instead of the
            other being a WD we'll publish as a note which is the
            same, but says by status it's not planning to go on the
            rec track.

  glazou: I wanted to make one comment on the sentence from tantek.
          You said we have an ED and push to a note. I'm concerned
          about the comments made on these documents. Where will
          they go. How will we handle them. How will we connect them
          to the document they're related to. This will be hell.
  fantasai: I think this is the clearest path we've found.
  glazou: I'm not saying it's not clear. There's one detail [missed]
  glazou: I'm concerned about our handling of feedback from readers.
          How will we connect feedback to the right version.
  fantasai: All feedback will be against CSS2 and filed in github.
            It will be processed the same way. If it has 2 impl and
            a test it will go into PR & note. If it needs work it
            goes into the note.
  glazou: That doesn't address the question. The reader can comment
          on the ED, the note, and the CR/PR. WHich version will you
          consider as input.
  <tantek> labels?
  astearns: I think we need to have the comment son the PR and we
            work on replies through the ED and note.
  tantek: Impl will comment on the note.
  tantek: So glazou is right.
  <glazou> thanks tantek
  <dbaron> Implementors aren't likely to look at a document where
           the errata aren't incorporated into the document.

  astearns: We're out of time. We made progress and should address
            next week. fantasai can you reply with the added idea of
            the note and summarizing?
  astearns: We can finalize next week.
  astearns: Thanks everyone for calling in and I'll see you next
            week if you make it to Seattle.

Received on Thursday, 5 January 2017 01:26:24 UTC