W3C home > Mailing lists > Public > www-style@w3.org > October 2017

[CSSWG] Minutes Telecon 2017-10-11 [css-grid] [css-break] [css-counter-styles] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Oct 2017 19:27:41 -0400
Message-ID: <CADhPm3sjGy=SR34Q2pV1xdzsfBzLSDRyGtvJbC2Cd-_SWOy+xg@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.

Reconsider the meaning of 1fr

  - RESOLVED: Close issue #1777 no change
  - fantasai will create a separate issue to investigate her proposal
      to reduce the confusion that lead to this issue (Her initial
      proposal is in this comment:

Clarify definition of widow and orphans

  - RESOLVED: We want the interpretation to be the first option in
              issue 1832

Invalid @counter-style should just not define a counter style, not be

  - RESOLVED: Treat invalid counter-styles the way we treat invalid
              font faces.

What to do with Shepherd test issues?

  - RESOLVED: Leave shepherd issues in shepherd, make it possible to
              mark them closed, file issues per test suite in WPT
              pointing at that test suite's issues in shepherd.

Sign up for Houdini at TPAC

  - Working group members were reminded to put their name on the wiki
      if they plan on attending the Houdini meeting on the Thursday of
      TPAC https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-November-2017

Obsoleting CSS1

  - The group will wait for the 'superseded' status that's a part of
      the 2018 plan.

Q length unit capitalization

  - RESOLVED: Use Q (upper case) in spec but add a note that it's
              serialized as lower case.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Oct/0022.html

  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Thierry Michel
  Michael Miller
  Theresa O'Connor
  Manuel Rego
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Sergio Villar Senin

  Rachel Andrew
  Robert Flack
  Vlad Levantovsky
  Lea Verou
  Greg Whitworth

Scribe: dael

  astearns: It's time to start though we're light on numbers. Thanks
            for calling.
  astearns: Anything extra to add to the agenda? I got Bert's on
            obsoleting CSS1.

Spec Rec Next Steps

  astearns: I want to talk about testing this week.
  astearns: We just republished CR of Backgrounds & Borders and it was
            missing some tests. That goes against our recent
            resolution to require tests, though the resolution to
            publish Backgrounds & Borders happened before the
            resolution so it was grandfathered. But we need someone to
            look through Backgrounds & Borders for tests.
  tmichel: I'm on it. The spec isn't published in CR, I'm waiting on
           edits from fantasai, but the request was accepted.
  astearns: Thanks for signing up. I'll get that added.

  astearns: There are other specs that need tests. If you look at the
            'needs test case' label in github there are many. I'll
            take care of values. Is anyone looking at writing modes?
  fantasai: Values test is more about we need information.
  astearns: I understand, but there are two issues that got edits in
            the draft that need test cases.
  florian: I am not signing up for all writing modes, but I have for a
           section of them. The one we discussed recently about height
           of scrollers I will do.
  astearns: I see the orthogonal flow and it is tagged. I've assigned
            it to you.

  astearns: I do see at least 1 flexbox issue. Can I get a volunteer?
  fremy: gregwhitworth was looking into it as far as I know. I think
         it's fair to assign to him.
  astearns: Okay, I've assigned it since you volunteered him.

  astearns: That's what I have for tests.
  astearns: To set expectations I don't plan on publishing any more
            CRs until their test suites are up to date.
  <tantek> +1

  astearns: Any other updates for spec progress?
  <florian> https://github.com/w3c/csswg-drafts/issues/1598
  florian: CSS UI. Last week I mentioned there's one issue left for
           not passing tests. fremy thinks it's maybe the spec
           instead, so please look at this bug ^
  florian: We can add it to agenda next week, but it would be good to
           look ahead.
  fremy: Feedback on that: we resolved the spec was right, but when we
         resolved I based it on the info in the issue which wasn't
         completely accurate. What I think spec should say was what's
         in the issue from dbaron not what's in the spec. I think it
         would be nice to look next week.
  florian: Spec text is older then issue. Issue was should we change
           and we said no, but issue discussion wasn't entirely

  astearns: Thanks. Anything else for rec progress?
  Chris: I noticed font-stretch didn't have tests so I wrote 18 tests
         for that.
  astearns: Great, thank you.

  astearns: Anything else on rec progress?

Reconsider the meaning of 1fr
  github: https://github.com/w3c/csswg-drafts/issues/1777#issuecomment-332683990

  astearns: There's a proposal TabAtkins summarized that was from
            fantasai apparently...?
  fantasai: That's a related issue. There's a problem which is
            unintuitive and flexbox has same problem. It's interaction
            of implied min size and overflow auto or scroll. What
            prompted this bug was running into that combo.
  fantasai: Having discussed with jensimmons it seems we don't want to
            change meaning of 1fr. I propose we close the 1fr issue no
            change and maybe discuss ways to make the behavior of
            overflow auto or scroll more intuitive.
  fantasai: It's a completely separate framing of problem. I'd suggest
            first close reconsidering meaning of fr.
  astearns: Is there a separate issue on overflow interp?
  fantasai: We'd need to open. We could change/re-title issue, but I'd
            like a resolution to not change 1fr.

  astearns: Manuel or Sergio have you had a chance to look?
  rego: I think that's fine. I didn't check this comment, but I think
        it's fine if we don't change. We raised it because people were
        confused, but probably not a good idea to change.
  astearns: You're fine closing no change?
  rego: Yes.
  astearns: Other opinions?

  jensimmons: I dropped a link at the bottom where Dave Rupert wrote a
              good blog post explaining the frustrations. I don't
              think changing 1fr is a good way to go. I sat and
              thought about this and the way 1fr works now is really
              good. I do think we should see what else we can do to
              help authors out besides education.
  jensimmons: Do something around overflow or add something else to
              grid to solve this, but I don't think changing 1fr or
              changing behavior between rows and columns is good. Keep
              it the same, keep it symmetrical, see what else we can
              do for authors.
  astearns: Is what fantasai spoke about with overflow does that
            address Dave's frustrations?
  jensimmons: I don't think he has the best solution, but he's talking
              about exactly those problems. He has one way to solve it
              and there are other ways to solve it that we list in the
              issue like minmax(0px, 1fr) would work. Authors don't
              know that because they don't understand what's a
              replaced element, but we can teach them that.
  astearns: I'm hearing consensus to close no change and then continue
            discussion on how to explain how overflow works with grid.

  RESOLVED: Close issue #1777 no change

  fantasai: We'll open a new issue starting with the blog post.
  astearns: Is that you fantasai or jensimmons?
  fantasai: I can do it.
  jensimmons: I'm happy to comment, but fantasai will do a better job

Percentages and intrinsic size (decide on indefinitely-sized
  github: https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096

  astearns: Sounds like we have everything resolved except dealing
            with indefinitely sized containers.
  astearns: I have not run through the presented options.
  fantasai: I haven't either.
  fantasai: I can describe, but rego made a lot of comments I haven't
  astearns: rego is here anything you can summarize or should we move
            this to next week?
  rego: I was commenting because some may not be possible, but
        realized the previous resolution...the issue was about
        percents in gutters or gaps. We resolved for percent tracks
        something that changes all impl and I'm not sure we really
        want to do that. Probably better to discuss more on github
        first and come back
  astearns: Sounds good to me. Anyone else have a comment now?
  rego: Would be good for other impl to look through the last comments.
  astearns: Definitely. Rossen is out this week but might have time
            next week. Anyone know what Mats is up to? [silence] Let's
            table for now and come back once this has been discussed
            more on github.
  * tantek reviews 509 discussion

Clarify definition of widow and orphans
  github: https://github.com/w3c/csswg-drafts/issues/1823

  florian: I realized there was ambig. in the definition. [reads from
           The orphans [resp. widow] property specifies the minimum
             number of line boxes in a block container that must be
             left in a fragment before [resp. after] a fragmentation
           If a block contains fewer lines than the value of widows or
             orphans, the rule simply becomes that all lines in the
             block must be kept together.
  florian: The reason I think this is ambiguous is that line boxes in
           a block container isn't clear if they must be direct
           children or indirect descendants. I don't think it intends
           indirect. If it did if you had a div with two paragraphs
           with widows and you'd end up gluing them together.
  florian: I think we clarify that we only mean direct children.

  TabAtkins: The usual intent is to set on a page box, correct?
  fantasai: No, this is about paragraphs, not page boxes.
  fantasai: The definition is about block containers with line boxes.
            You must have a min number of line boxes in each fragment.
            I thought that was clear, but if it's not we can clarify.
            This is only line boxes. And property inherits. If there's
            a block in your block that's a child to which widows can
            also apply. But you can break at the boundary.
  fantasai: You can always say break after at a block. Usually that's
            not an issue because a block inside a block is separate

  astearns: Intent is closer to #1 in the example.
  dauwhe: #2 in the example would be bad.
  dauwhe: Absolutely #1.
  florian: I think there are rare cases where you might want #2 but
           you should control that separately.
  astearns: If there is a case where you want #2 you would structure
            html differently.
  florian: Probably.
  dauwhe: Or the thing you're trying to fix would not be a widow.
  florian: I think we can address the rarity of #2 another time if we
           can resolve on meaning #1. An editor can change or I send
           a PR.

  astearns: I'm not certain an edit is required but that may be
            because I'm interpreting the language in a particular way.
  Bert: If florian finds it's unclear it probably is. I didn't imagine
        it in another way, but if florian reads it another way it
        needs clarification.

  astearns: florian, you'll do a PR to fix the wording?
  florian: Yes.
  astearns: Okay, we'll then look at wording and decide to take the
  florian: Or resolve on intent.
  astearns: Resolve that we want the interpretation to be the first
            one in your comment and then you write the pull.
  TabAtkins: Nope.

  RESOLVED: We want the interpretation to be the first option in issue

Invalid @counter-style should just not define a counter style, not be
  github: https://github.com/w3c/csswg-drafts/issues/1682

  TabAtkins: The problem is what precisely do we do with counter-style
             rules that are invalid due to either not having or
             missing required descriptors. Is it invalid or does it
             not define one?
  TabAtkins: Font face has some required descriptors and if you're
             missing them it just fails to instantiate a font face. I
             propose to mirror font face so they stay in the OM.

  florian: Any compat requirements?
  TabAtkins: No. FF is only impl and xidorn is okay either way.

  dbaron: Sounds good to me.

  astearns: Objections to treating invalid counter-styles the way we
            treat invalid font faces?

  RESOLVED: Treat invalid counter-styles the way we treat invalid font

What to do with Shepherd test issues?
  github: https://github.com/w3c/web-platform-tests/issues/5485#issuecomment-335326728

  astearns: We had planned to move all shepherd issues to GH but some
            people expressed skepticism it will be useful. Proposal is
            to keep issues in shepherd so people can work as required
            as we have time, but it's fine to store in shepherd
            instead of moving them to git.
  florian: I support that. Signal to noise ratio is really low.
           Hopefully as we get more integrated into CI tests will be
           done in a meaningful way and tests will be fixed up as we
           go. Elsewise we'll have lots of work for hundreds or bad
  <Chris> agree, best to clear them off as time permits. Probably
          duplicates in GH for some of them. And some should have been
          closed years ago.
  fantasai: Additional consideration is system status is kind broken.
            There was auto flipping based on commit and those were
            incorrect. So any automated copying would be problematic
  <Chris> +1 fantasai that the auto-flipping was problematic

  dbaron: Do we discourage new issues in shepherd?
  plinss: It's been read only for a while.
  florian: Full read only?
  plinss: I think so. I can tweak to close only if that's what we want.
  florian: If anybody wants to triage I don't think it should be
  fantasai: Reasonable, yes.

  fantasai: We might want a meta issue in the github saying there are
            a whole bunch of things filed and point people there.
  astearns: Maybe on a suite by suite basis?
  fantasai: That's brilliant. Yes.
  astearns: As people take on the work and someone plans on going
            through shepherd they can track their own work. git issues
            where no one is doing something isn't really useful
  astearns: Sounds like there's consensus to leave shepherd issues in
            shepherd. I like making sheperd issues able to be closed
            as people go through. Obj?

  RESOLVED: Leave shepherd issues in shepherd, make it possible to
            mark them closed, file issues per test suite in WPT
            pointing at that test suite's issues in shepherd.

Sign up for Houdini at TPAC
  <astearns> https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-November-2017

  astearns: There's a section in github for people planning to attend
            on Thursday, please add your name.
  <Chris> I have two other conflicts Thursday, unfortunately
  astearns: There may be some ad hoc earlier discussion for people
            leaving earlier.
  tantek: I think there's AC meeting Thursday afternoon too. Are we
          all day or just morning?
  astearns: In the past we haven't secured a room, we just grabbed
            tables and had a work session all day. Discussions aren't
            terribly formal. I doubt we'll get a room this year.
  tantek: Community group rooms are still being allocated so I expect
          we might be able to get a room.
  Chris: Community groups are in 2 hour blocks, though. It's worth
         trying, but don't assume it'll work.
  tantek: Preference for morning if there is a conflict.
  astearns: Can you add that to the wiki?
  tantek: Will do.

  <tantek> re: Houdini at TPAC - would prefer remote participation
           possibility, at least by phone. we have a dev working on it
           in New Zealand (who won't be at TPAC in person)

Obsoleting CSS1

  astearns: There is a new process and it's low effort so he suggested
            we do that for CSS1
  fantasai: In favor
  dbaron: One comment is there was some controversy for doing this for
          html things that were superseded and I believe next year
          process adds the superseded state.
  florian: Obsoleted may be better for something like speech.
  dbaron: Basically what happened is there was a ballot to AC for
          older HTML things because people were more comfortable
          calling those superseded.
  astearns: And the HTML spec are waiting for superseded?
  dbaron: I think so.
  <fantasai> wfm
  Chris: Obsolete can be flipped, but it may be better to wait for

  <dbaron> https://w3c.github.io/w3process/
  tantek: fwiw there is a 2018 process document public draft if anyone
          is curious to look.
  tantek: This is what the difference was intended for. Obsolete is
          something that never took off. There are probably CSS specs
          that fall there like some of the profiles. It's a good way
          to clean up. If there are specs never impl or never tested I
          think those are good for obsoleting.
  florian: Isn't obsolete or superseded only for REC not just anything
           on TR?
  tantek: Sure. It is only for REC.
  florian: Right, so we turn it into a note and discard if it didn't
           make REC.
  Bert: I think we made notes for everything. All the other REC are in
        use. Profiles never made it.
  tantek: TV profile, mobile profile
  Bert: They're notes.

  astearns: When we have superseded might we use that for lower level
            specs with a new module?
  tantek: I believe the goal is to include that as a part of the PR
          vote. So also say as part of the PR vote that we're
          superseding the previous.
  astearns: I don't think we have any with a new module that made it
            to PR.
  astearns: So let's wait for superseded process next year and then
            deal with CSS 1 as it's more appropriate.
  tantek: A list of specs that qualify would be helpful. I could take
          that to the AB.
  astearns: Definitely CSS 1.
  tantek: CSS 2.0. It's still a rec though it has those warnings.
  Bert: It's not superseded yet.
  tantek: Well, it is by 2.1
  fantasai: That happened because we merged the short name. It's
            effectively superseded.
  tantek: I recognize we've done good hacks, but there is a dated
          permalink that we could mark as superseded.
  fantasai: I don't know the permalink. What is that.
  tantek: The one with the date.
  fantasai: You can't change the dated draft status.
  florian: I think there is some plan via JS injection to mark them as
           "not the latest draft, look over here".
  astearns: Sounds like we've gotten to a stopping point for this

  astearns: That's the end of the agenda. One thing I remembered is if
            you haven't signed up for TPAC on the wiki please do. Stat
            adding agenda items as well.
  <tantek> https://wiki.csswg.org/planning/tpac-2017
  astearns: Anything else to talk about?

Q length unit capitalization

  ericwilligers: The case in the spec for Q length unit. It used to be
                 upper and lower, I changed it to lower, then I found
                 out it's upper in Japan. I then proposed upper and
                 got comments.
  ericwilligers: Chrome is about to ship support of Q and I thought it
                 would be culturally sensitive for Japan to do upper.
                 This is just for spec. I think it serializes as pixel.
  TabAtkins: You can get it back. I'm fine using upper case in the
             spec, I don't care.
  fantasai: I agree it serializes the same as other units. But in the
            spec using Q in the spec is fine.

  astearns: Maybe use it as upper in the spec and add a note it's case
  TabAtkins: That's the plan.
  astearns: We don't have examples of it as upper though.
  TabAtkins: Adding a note saying we're putting it in Q but it's case
  florian: Maybe Hz unit too?
  TabAtkins: Sure.
  fantasai: We can add a note in places with upper saying it's case
            insensitive. But it is a capital Q in V&U.
  astearns: Thanks ericwilligers.

  RESOLVED: Use Q in spec but add a note that it's serialized as lower

  astearns: That's it for the call. Thanks everyone.
Received on Wednesday, 11 October 2017 23:28:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 October 2017 23:28:39 UTC