W3C home > Mailing lists > Public > www-style@w3.org > November 2016

[CSSWG] Minutes Telecon 2016-11-30 [CSS2] [css-grid] [css-align] [css-flexbox] [css-ui]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 30 Nov 2016 16:55:37 -0500
Message-ID: <CADhPm3vAJpW2y9ffq8E=j53o+JDkb-ivPtCE++GV5pP+t8CHfg@mail.gmail.com>
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.
=========================================


CSS2.2 plan to CR and test review request
-----------------------------------------

  - gsnedders and gregwhitworth offered to review the test suite.
      Anyone with interest in a section of CSS 2.2 was also asked to
      review at least that section.
  - In addition, anyone with interest was asked to review the edits
      made to CSS 2.2.
  - fantasai will start a thread on the member e-mail list to
      discuss how best to keep the CSS 2.X specs updated quickly as
      items become interoperability implemented.
  - For CSS 2.2 individuals should put issues in where they think
      there should be a link to another spec. In CSS 2.3 there will
      be work done to integrate all relevant links.
  - The group agreed to a goal of getting CSS 2.2 to CR within a
      week after the Seattle F2F.
      - Review requests will be sent to the appropriate groups
          noting that are errata only to help them prioritize.

Remaining Grid Issues
---------------------

  - Rossen & TabAtkins agreed to review the conversation on github
      around the new definition for 'normal'
https://github.com/w3c/csswg-drafts/issues/523

Need clarification on `auto` margins for abspos flex children
-------------------------------------------------------------

  - RESOLVED: For all layout modes when you're figuring out static
              position of an abspos child treat auto margins as 0
              regardless of normal positioning rules.

Computed value of currentColor
------------------------------

  - Everyone agreed that the proposed edits should occur, but
      Florian will bring his proposed text to the group as there are
      many specs that will need changes.

Should caret-color apply to any element?
----------------------------------------

  - RESOLVED: Change the applies to line to all elements
  - RESOLVED: Add an informative note as to what is a caret and what
              is not.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Nov/0115.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Bo Campbell
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Dael Jackson
  Brian Kardell
  Peter Linss
  Myles Maxfield
  Rachel Nabors
  Simon Pieters
  Anton Prowse
  François Remy
  Florian Rivoal
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth
  Steve Zilles

Regrets:
  Daniel Glazman

Scribe: dael

Note on the call: Due to problems with the conference bridge, the
     meeting began late. All conversation around the conference
     bridge has been removed, but specific topic discussion in IRC
     before a bridge was established is left as-is below.

CSS2.2 plan to CR and test review request
=========================================

  <astearns> SO - the first topic is CSS 2.2
  <fantasai> Wrt CSS2.2... I think dbaron said some of the edits are
             actually incorrect, so it needs to be verified that
             things are correct.
  <astearns> who will do that verification?
  <Florian> Were the incorrect edits identified?

  Bert: 2.2. My goal is to get a plan for getting 2.2 to CR and then
        PR.
  Bert: It's only FPWD officially but I believe everything is
        implemented or close to. To get there I made a number of
        items to discuss.

Test Suite
----------

  Bert: First is test suite.
  Bert: I tried to make tests for all things that are different in
        2.2 from 2.1 I submitted and saw gsnedders is reviewing.
  Bert: Are my tests correct? Do we need more tests?
  Bert: If gsnedders could weigh in on that.
  <astearns> gsnedders: have you been able to connect?
  [he has not, but is joining]

  <dbaron> is there a diff-marked version of the spec relative to
           2.1?
  <fantasai> dbaron: https://www.w3.org/TR/CSS22/changes.html

  Bert: Or can anyone check the test coverage? I think I have at
        least one test for everything normative but I may have
        missed.
  Rossen: Can we turn this into an action for people that want to
          review and give them a week or two?
  <gregwhitworth> I will review it in the next week or so

  fantasai: Bert can you link the tests from the changes page?
  fantasai: I think it would help because then this becomes the
            implementation report.
  Bert: Yes, I linked to the doc section, but I can link to the
        changes. That will take a few days.

  gsnedders: As far as to the tests they're in the 2.1 test suite
             because Sheppard doesn't know about the fragment IDs in
             the changes list.
  astearns: So are you asking if there should be a 2.2 suite?
  gsnedders: Most of our tooling is built around the test suite and
             at the moment most of these test wouldn't be put into
             any test suite because Sheppard doesn't know the
             fragment IDs
  plinss: We could have 2.2 but that would only include the 2.2
          test. Which may be sufficient.
  astearns: It might be preferable.
  plinss: That's trivial to spin up. I can do that today
  Bert: Do I need to do anything?
  plinss: If the tests have links to the 2.2 spec we're fine.
  Bert: Okay.

  <dbaron> Are the tests visible as files somewhere, or only inside
           the pull request in https://github.com/w3c/csswg-test/pull/1139 ?
  <gregwhitworth> yes
  <gsnedders> dbaron: http://csswg-test.org/submissions/1139/
  <gregwhitworth> I would love to look at just the tests for these
                  changes
  <gsnedders> dbaron: though obviously that's the whole testsuite
  <gregwhitworth> gsnedders: can you get me the link to the 2.2
                 tests, I don't run shepherd and there aren't many
                 here to quickly go through - I'd like to have bugs
                 filed on Edge for these
  <gsnedders> gregwhitworth: there's nothing better than
              https://github.com/w3c/csswg-test/pull/1139 and
              looking at the list of files there quickly
  <gregwhitworth> gsnedders: awesome thanks :)
  <gsnedders> gregwhitworth: I can probably create a quick list at
              some point later today, if that helps
  <gsnedders> gregwhitworth: like, list of links to the new tests
  <gsnedders> https://github.com/w3c/csswg-drafts/issues/412
              definitely needs edits

  Bert: Were the tests correct? gsnedders you were looking. I think
        I answered all your comments. Did you look?
  gsnedders: Not really. I also haven't looked to see if the tests
             matched the changes to the spec. I was doing a quick
             high level review.
  astearns: Are you planning on looking more detailed, gsnedders?
  gsnedders: I can...some of them I'm not competent to review.
  astearns: It would be useful if you can and it looks like
            gregwhitworth has offered to look.
  gregwhitworth: Yes, yes. I'll help as needed.

  Rossen: My ask for everyone is given that CSS 2.1 is what everyone
          on the web depends on it's in our best interest to make
          sure 2.2 is as interop as quickly as possible. Especially
          for implementors changing behavior to align better it's my
          ask to make sure these are testing what they're supposed
          to test.
  Rossen: Nothing new in the ask, but more action. I believe this is
          the largest impact to interop in the short term.
  astearns: Can anyone else commit to taking a look at these tests
            and see how well they match?
  astearns: If there is a particular errata in 2.2 you were involved
            in I'd like you to at least look at those bits.

Process for publication
-----------------------

  gsnedders: How many outstanding edits are there on 2.2?
  Bert: fantasai pinged me one thing. That's the only one I know of.
  fantasai: It was a baseline alignment issue. I don't think it's
            interoperability implemented and I just put an issue
            against the errata.
  fantasai: I'm happy this is happening and I think we need a
            process that lets us make edits on 2.2. If we try and
            address every thing, though, we'll never get there.
            Going forward we need a copy of css 2 that's only the
            changes implemented across browsers and a second copy
            that's changes decided and not implemented.
  <tantek> agreed with fantasai: need CSS2.x that reflects interop
           reality, and another CSS2.x that reflects that *plus*
           CSSWG consensus decisions on fixes/issues
  fantasai: We'll need a multi-stage release process. There's going
            to be a lot of issues not addressed in this draft. We do
            need to have a way of getting this draft to rec on a
            continuous basis. This is a good start to have the
            errata that are passed.
  <gsnedders> we have git cherry-pick and similar if we want to move
              edits, but that doesn't work with stacked edits,
              obviously
  astearns: I think this is important. I don't want to spend too
            much time talking process today. Could we do something
            like have these edits not implemented in as at risk and
            once they're implemented we take the at risk off. And
            once we move forward we move them out to the next level.
  <tantek> or go into the next +0.1
  Florian: When they're changes to a sentence how do you have a
           sentence at risk?
  fantasai: For the old process we used to be able to go from WD to
            PR if you had fulfilled the requirements. We may want a
            WD copy and a PR copy and only include the changes
            implemented in the PR and have a trunk branch with all
            the decided changes and cherry pick the ones implement.
  fantasai: We'll skip the CR cycle
  <gsnedders> https://www.w3.org/community/w3process/wiki/Rectracktimeline
              implies you need a CR
  <tantek>  or we use that CR cycle to set expectations of what is
           going into the PR, and have a convention of no at-risk
           items there
  <tantek> CR is only 4 weeks anyway
  <tantek> and that's good time to verify tests
  <tantek> and get broad review
  astearns: Let's start a thread on the member list to decide how to
            manage 2 going forward. fantasai can you start that
            thread?
  fantasai: Sure.
  <tantek> fantasai, in general I agree with your approach, see
           above for how a minimal CR could be useful
  astearns: Any more topic on 2.2 test suite?

Wide Review
-----------

  Bert: Two things more. 1 is to go to CR you have to prove wide
        review. There hasn't been a lot of comments, but that's not
        so strange. So we need some way to prove this has had enough
        review. If you have ideas for the arguments let me know and
        I'll put those in the transition request.
  astearns: Are there other groups we should notify and ask for
            review?
  tantek: Web platform.
  Bert: Yes. a11y normally.
  tantek: Yes, but with the note that these are errata only. Same
          with i18n.
  astearns: We can send out that standard e-mail for review.
  tantek: We didn't drop any feature either, right?
  Bert: I don't think so.

  astearns: Early in the conversation fantasai raised a concern
            about incorrect edits. Have we had internal review?
  fantasai: I don't remember what it is, I remember that last time
            we talked dbaron mentioned there were incorrect edits.
  Rossen: So in addition to reviewing tests, please review the
          changes.
  dbaron: I'll try and look. I may not have time in the next few
          weeks.

Linking to other specs
----------------------

  Bert: I was hoping that you could be more concise about the links
        of other specs requested. It's harder to make links from
        chapter definitions. I saw SimonSapin made rough links. How
        far do we go in making links to level 3 in the document?
  Florian: I think when we have a level 3 entirely replacing a
           section it should be linked. When it's a little bit it's
           more tricky.
  astearns: I wonder if this link replacement could go into 2.3
            since 2.2 is close to done. I'm not sure I want to add
            this to slow the CR and PR down.
  Bert: That's a possibility. Make a copy, call it 2.3 and start
        editing there.
  tantek: Depends on whether we can get CSS 2.2 into CR by next
          Tuesday (week?) right?
  fantasai: I think we should go with the edits here and not add
            anything. Mainly let's start and get a chunk through.
            That way this isn't a big issue and we can push though a
            set a year.
  gsnedders: We have interop on some of the changes in syntax so we
             may want to include them. We don't have interop on the
             2.1 and current 2.2 behavior anymore.
  fantasai: That's fair. we should fix them.
  astearns: Can they be issues?
  gsnedders: They are.

  gsnedders: Should we add a 2.2 label on github for things that
             should go in there?
  astearns: Makes sense.

  astearns: tantek mentioned postponing the links to 2.3 is
            dependent on getting 2.2 to CR on Tuesday. I'm not sure
            that's the case. If we don't make the deadline and have
            to publish the CR in Jan I think it's useful to get out
            as quickly as we can and postpone the link replacement.
  tantek: I think that's good in general. I think we should file
          issues for each link replacement and we can decide case by
          case. I was thinking of the box model width and height
          calc are strongly patched in the CSS3 UI box-sizing
          section which makes lots of changes and anyone impl should
          be reading that.
  tantek: I'm just raising that there may be things worth putting in
          if we aren't going to make the 2016 deadline.
  astearns: So we'll add the 2.2 label on github. I'm pretty sure
            we're not going to make the end of the year CR given
            that people are still reviewing edits and test suite.
  Bert: That's no problem. I didn't ask for CR by the end of the
        year, just something soon.
  astearns: Anything else on 2.2?
  Bert: That's the end of my list.

Timing
------

  tantek: Are we trying to CR before Seattle?
  astearns: I think that's achievable
  tantek: Or is that where we make a final decision on in or out?
  fantasai: I think the later is more achievable.
  astearns: Let's see what we can do before Seattle and anything
            left over we decide in person.
  tantek: So we're giving ourselves a deadline of publish CR of 2.2
          no later then a week after Seattle F2F?
  astearns: Yep.
  Florian: How does the asking other people to review work with that?
  astearns: We should ask for wide review now; there's enough bulk
            in the errata that people will take time. If we wait for
            everything is done it add another month to the process.
            I'd rather get 2.2 out and start on 2.3.
  tantek: Reasonable. Should we resolve to publish a WD that include
          the current status of all the edits and send that for
          review?
  Bert: I don't think I have anything different then current WD.
  astearns: So current WD has all the edits.
  Bert: Right.
  astearns: So that's what we'd send out.
  tantek: So no changes in the ED.
  Bert: I'll check, but I don't think so. no.
  <SteveZ> sending for Wide Review now is what we should do because
           the existence of Wide Review is an entry condition for CR

Remaining Grid Issues
=====================

  astearns: I'm not sure what's left. fantasai do you have things?
  fantasai: There's been discussion. There was a set of edits for
            new normal behavior; we resolved that normal preserved
            the aspect ratio. It used to be a synonym for stretch.
            There's been additional discussion on that. I've made
            the edits, I'm looking for review
  astearns: Do you have the issue link?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/523
  fantasai: There's discussion on what if you have normal in one
            direction and stretch in the other. Also just the edits
            are in and need review. I'm not caught up on the github
            conversation.
  astearns: Can someone involved in grid look at this?
  TabAtkins: Yes.
  Rossen: I'll do it on our end.
  <fantasai> thanks :)

  astearns: What else for grid?
  fantasai: I think that's the main thing. Let me flip through and
            look for anything else. You can move to the next topic.
  astearns: I think we just did the next topic. I'm going to take
            the "Grid Layout Issues" topic off the agenda; it had a
            lot of things. If we need those discussed let's raise
            them separately.

Need clarification on `auto` margins for abspos flex children
=============================================================

  <astearns> https://github.com/w3c/csswg-drafts/issues/665
  TabAtkins: Mats brought this up a while ago.
  TabAtkins: When you have an abspos child you lay it out like the
             container. Presumably that means they work like they do
             for flexbox. Chrome and Edge don't do that; they do it
             as 0. If an abspos child of a block container has auto
             margins it also gets treated as 0. This is just to
             determine static position.
  TabAtkins: Because everyone seems to agree, the proposal is in
             position draft or in flexbox we define that when
             finding static position the margins are 0.
  Rossen: I think I made that change and commented.
  TabAtkins: There wasn't anything on the issue.
  Rossen: I may be thinking about a different issue. [looks] I was.
  Rossen: I can take the action to make the edits if the WG agrees.
  fremy: works for me
  <tantek> sounds like it makes children that are abspos, their
           auto-margins more predictable / consistent, so that seems
           reasonable

  TabAtkins: prop res: For all layout modes when you're figuring out
             static pos of an abspos child treat auto margins as 0
             regardless of normal positioning rules
  fantasai: This also needs to go in CSS 2.1
  Rossen: Sounds like we need this in errata and positioning spec.
  TabAtkins: Yes.
  astearns: obj?

  RESOLVED: For all layout modes when you're figuring out static
            position of an abspos child treat auto margins as 0
            regardless of normal positioning rules.

  ACTION bert make the change to 2.1 for the abspos resolution
  <trackbot> Created ACTION-804

Computed value of currentColor
==============================

  <astearns> https://github.com/w3c/csswg-drafts/issues/741
  Florian: We've defined in css color 4 that currentColor is
           supposed to compute to currentColor, but css 3 UI doesn't
           invoke that text. It instead says that caret color
           resolves to inherit. Are we okay to fix it so that
           currentCcolor computes.
  <tantek> can we just update to reference css-color-4?
  TabAtkins: I agree the wording should be changed, but I don't like
             the actual wording. I would prefer we define an
             algorithm for doing the color like we do with links
             made absolute phrasing and you invoke that.
  tantek: I'd agree with TabAtkins.
  Florian: We have text in Color 4 that says how currentCcolor
           computes in general.
  Florian: Should I come back to the call once I have better
           phrasing?
  fantasai: Whatever you choose we need it to be same for a whole
            bunch of other stuff. So please bring it to the group.
  Florian: Are all the other specs inherited?
  fantasai: Text decoration does. Currently says as spec in computed
            value.
  Florian: Okay. I'll try and come up with a wording.
  fantasai: All the specs need to be updated, so please base it off
            of level 3 of color.
  Florian: I'll try. Useful wording is in level 4.
  TabAtkins: We can pull it back if we need to.
  fantasai: we'd resolved to update L3...not sure if it's done yet.
  Florian: I'll come back with a suggestion.
  astearns: My ask is for Florian and TabAtkins to work on the
            wording in the issue and have you both agree.
  Florian: yeah.
  TabAtkins: Sure.

Should caret-color apply to any element?
========================================

  <astearns> https://github.com/w3c/csswg-drafts/issues/725
  Florian: Currently the edit talks about caret. There's a bunch of
           browsers with a caret navigation mode. The question
           raised is if caret color applies to that. Since caret nav
           isn't defined we can be explicit and say it's undefined.
  TabAtkins: Just doing that doesn't work because the property says
             it applied to editable elements.
  TabAtkins: I'd prefer adding it to all elements and have a note
             that anything caret-like, for example nav caret, should
             be effected. Informative note.
  Florian: I don't think it can be normative because caret nav isn't
           defined.
  tantek: Tab are you asking for the normative change to change the
          applies to?
  TabAtkins: Yeah. Applies to doesn't have any normative meaning.
  <fantasai> +1 to fixing applies-to
  tantek: I'm just worried if we are in CR does this mean more tests.
  TabAtkins: Nope. You can't test an applies to line. It's
             impossible.
  tantek: I in general agree, but we did have a case in CSS 1 where
          that happened.
  TabAtkins: It's a behavioral change. The applies to doesn't case
             that.
  tantek: In CSS 1 it did happen.
  <fantasai> +1 to tantek
  <fantasai> It does make a difference. In some cases it's not
             detectable, and in others it is.

  Florian: There is no difference between applies to and applies and
           does nothing. If you have a caret for another reason we
           make it so it can apply.
  tantek: I'm concerned we'll mislead authors. If it applies to all
          elements and I see the text selection cursor I'd expect it
          to change colors.
  TabAtkins: But then that applies to current editable elements. It
             doesn't and we don't expect confusion.
  tantek: I'd add a normative note that it's only to the actual
          caret, not the text cursor.
  Florian: People are frequently confused between caret and cursor
           so that's not a bad idea.
  astearns: I headed three things. 1) normatively change applies to
            line 2) add an informative note able nav carets and
            caret-like things 3) add a note that says really only
            carets, not things like cursor.
  Florian: For the 2nd it is this may apply or should?
  TabAtkins: It's normative so it's pointing out there are other
             things like carets.
  tantek: Which is why I pointed out the text cursor.
  astearns: I think 2 and 3 should be one note.
  TabAtkins: That sounds reasonable.
  Florian: sgtm
  astearns: Objections to changing the applies to line?

  RESOLVED: Change the applies to line to all elements

  astearns: Objections to the proposed note?
  myles: Can we clarify should or may?
  TabAtkins: It's informative so doesn't matter.

  RESOLVED: Add an informative note as to what is a caret and what
            is not.

  astearns: Thanks everyone.
  fantasai: We're publishing an update to box alignment soon so if
            you're interested please take a look.
Received on Wednesday, 30 November 2016 21:56:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 November 2016 21:56:44 UTC