[CSSWG] Minutes Telecon 2016-10-12 [css-syntax] [css21] [css-inline] [css22] [css-multicol]

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

Upcoming 2017 Meetings

  - There is a move to finalize the April/Japan dates so anyone with
      conflicts should put them on the list.

Merge csswg-test into web-platform-tests

  - RESOLVED: Keep our should/must/may testing in place and put it
              into the web documentation.
  - RESOLVED: We start the list of steps given at
              keeping the test harness in working order as each step
              is done. We let gsnedders and those doing the work
              decide when to move steps.

url parsing contradiction between 2.1 and Syntax

  - RESOLVED: Remove CSS grammar section in CSS 2.2 and have a
              pointer to CSS syntax

Definition of line-height calculations contradicts itself

  - fantasai will write up proposed spec text to describe Blink and
      Gecko do.

The minimum and preferred width of a multicol is not defined anywhere

  - The definition is in Syntax spec.

Positioning boxes with { float:left; width:0px; }

  - The topic will wait until next week to give people time to
      review the github comments.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Oct/0089.html

  Rachel Andrew
  Tab Atkins
  David Baron
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Vladimir Levantovsky
  Chris Lilley
  Peter Linss
  Liam Quin
  François Remy
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Steve Zilles

  Rossen Atanassov
  Myles Maxfield
  Theresa O'Connor
  Anton Prowse
  Hiroshi Sakakibara
  Greg Whitworth

Upcoming 2017 Meetings

  astearns: We should start. Does anyone have anything extra to add
            to the agenda?
  astearns: We have definite plans for the Seattle meeting in
            February so people should start making travel plans.
  <jensimmons> astearns: you just said Feb — but you meant Jan, yes?
  astearns: Seattle is Jan 11-13.

  astearns: We're confirmed for Tokyo in April and we're trying to
            fix on which day. 3rd week in April does not have
            mentioned conflicts. If you have things going on that
            you would like to avoid overlapping, please respond to
            the thread.
  astearns: Are there any April days we should avoid that people on
            the call know about?
  <tantek> avoiding weekends and M/F is good :)
  <dauwhe> April is the cruelest month, schedule-wise
  astearns: If you do come up with something please respond on this
            list. We're trying get get those days fixed ASAP.

Merge csswg-test into web-platform-tests

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Oct/0088.html
  astearns: gsnedders put this up right after TPAC. I summarized the
            responses here ^
  astearns: Basically, details on step 5, we have to make sure
            everything is documented and the test harness must keep
            working while we transition.
  astearns: Any further comments on this transition?

  ChrisL: What happens about reviewing? I understand there's a new
          model for web platform where tests aren't accepted until
          people feel they're good enough. Is that correct?
  gsnedders: We have 2 review models. Through mercurial we add it to
             the repo and it gets reviewed eventually maybe. Through
             github the pull request only gets merged after review.
  gsnedders: In web platform tests in principal we'll only merge
             after the pull is approved.
  <tantek> One review path for tests? Why not two review paths for
  ChrisL: I guess that's clear. The tests I wrote for the spec I'm
          writing I just put them in there. Should that be done
          differently while we're still using the test harness? I
          want tests to show up and flag bad tests.
  gsnedders: In general things have gotten merged quickly in web
             platform tests.
  astearns: I think it makes sense to use web platform tests model
            for simplicity but we'll have to step up the working
            group's reviewing game to make sure our pull requests
            are getting merged. We can't reply on the people
            reviewing now to review CSS tests.
  ChrisL: Right.

  tantek: I've got a policy question. Since we're talking about
          review models I heard a rumor at TPAC that only MUST are
          tested in web platform tests and that's in strong
          disagreement from my understanding.
  tantek: I wanted to get it on the record that we as a group...my
          understanding is we find it to be good policy to have
          tests on any SHOULD or MUST statements in our specs.
          That's my understanding.
  <Florian> I agree with Tantek
  tantek: If that's wrong I'd like to know.
  fantasai: We accept tests for MUST, SHOULD, and MAY if the MAY is
            the direction we'd like to go to. It's distinguished
            using metadata. There's a flag showing what it is so
            that when it is in conformance test results it shows.
  <Florian> Agree with Fantasai as well.
  tantek: I like that we accept tests for any MUST, SHOULD, or MAY.
          That's right and we should document that explicitly for
          using web platform tests. We should also push that
          upstream to web platform tests in general.
  tantek: I'm requesting it because the rumor was strong enough I
          was concerned and I would like to push in the other
          direction that we as a group have experience increasing
          interop by doing tests on MUST, SHOULD, or MAY. That
          should be documented and pushed upward.
  tantek: That's my request.
  astearns: Sounds good to me. gsnedders do you see a problem with
            keeping that for our tests?
  gsnedders: Not really, I don't think so.

  tantek: I checked web platform tests for a policy and that
          documentation is a maze. If I was a new comer I'd be
          totally lost. Whomever works with that group this kind of
          policy needs to be explicit in the docs.
  gsnedders: That's item 3 on the list of things to do.
  tantek: This is a specific improvement. I realize that the
          documentation is a larger task. This is one thing that
          would make a difference.

  RESOLVED: Keep our should/must/may testing in place and put it
            into the web documentation.

  ACTION astearns put the bit about should/must/may tests in the
  <trackbot> Created ACTION-797

  <tantek> Thank you very much astearns. Really appreciate it.

  <gsnedders> tantek: (I don't think this is worth doing on the
              call, but basically my objection to small changes is
              that they don't help anyone because nobody will find
  <gsnedders> tantek: (objection is too strong)

  plinss: Are we resolving that we're doing the migration now?
  astearns: I'd like now?
  plinss: We're not ready on the harness to shut down now.
  gsnedders: We should follow the steps laid out on the e-mail.
  astearns: Yes, I meant start the steps now.
  plinss: That's fine.
  gsnedders: And resolve to do each step.
  <ChrisL> I would not want to put tests into a repo where we can't
           get test results and run tests.
  astearns: It would be better to resolve on the entire list and do
            them in order. We don't need to wait on decisions for
            each step.
  Florian: I want to go through all the steps and I'm wondering if
           we need to check if we're ready for the next one.
  plinss: I'm okay with the people doing the work decide each step
          is done. My concern is I don't want to move tests out of
          our repo until the infrastructure changes are in place.
  ChrisL: Yes, I would be concerned about that as well.
  astearns: And that's what I was getting at in my summary that we
            should maintain test harness on each step.
  plinss: Yes, I just didn't see that explicitly listed.

  astearns: Any other discussion?
  astearns: Proposed resolution: we start the list of steps keeping
            the test harness in working order as each step is done.
            We let gsnedders and those doing the work decide when to
            move steps. Obj?

  RESOLVED: We start the list of steps given at
            keeping the test harness in working order as each step
            is done. We let gsnedders and those doing the work
            decide when to move steps.

url parsing contradiction between 2.1 and Syntax

  <astearns> https://github.com/w3c/csswg-drafts/issues/412
  astearns: fantasai added this a month ago.
  gsnedders: We postponed it because you wanted dbaron on the call
             is my memory.
  astearns: And is dbaron on?
  dbaron: Yeah.

  TabAtkins: The issue from gsnedders is there are a few tests in
             CSS2.1 that exercise URL parsing. That changed in the
             syntax spec in ways brought up by dbaron and from what
             I recall he was fine with those changes. It means it's
             different from 2.1 and normally we backport but in this
             case it would be extraordinarily difficult to do so.
  TabAtkins: 1) We need to change the 2.1 test and I think gsnedders
                wants a resolution he's allow to do so
  TabAtkins: 2) Resolve we don't need to change 2.1 because it's too

  astearns: While editing the change would be difficult would a note
            make sense?
  ChrisL: That's what we're doing with 2.2 right? We're removing
          parts and pointing to specs
  TabAtkins: I'd be for 2.2 removing CSS grammar and pointing to CSS
             syntax. We shouldn't imply CSS is parseable with a
             grammar approach.
  ChrisL: I agree. Can we resolve on that?
  astearns: Proposed resolution: to remove CSS grammar section and
            have a pointer to CSS syntax.
  astearns: Objections?

  RESOLVED: Remove CSS grammar section in CSS 2.2 and have a pointer
            to CSS syntax

  gsnedders: Are we ignoring 2.1 because 2.2 draft will be different?
  dbaron: In the old tests we want a syntax version of those tests
          and then 2.1 can go away.
  TabAtkins: I don't think we need to get rid of, but the page
             testing syntax quirks there's a handful that are
             slightly wrong. We can just fix those and keep the rest.
  plinss: If you're changing tests so they're not 2.1 compat we
          should remove those and link to syntax.
  fantasai: We should backport. 2.1 should be errata-ed
  ChrisL: TabAtkins said we can't backport.
  gsnedders: And 2.2 will match syntax so the tests will be right by
  gsnedders: They will follow the level 2 spec.
  fantasai: Okay.
  astearns: It makes sense to remove 2.1 links as we update the
            tests to remove confusion.
  astearns: gsnedders you'll make the edits?
  gsnedders: I presume so.
  astearns: Anything else on this topic?

Definition of line-height calculations contradicts itself

  <astearns> https://github.com/w3c/csswg-drafts/issues/391
  astearns: There's been discussion on the issue since it was
            agenda+ by fantasai. I don't know if things got resolved.
  fantasai: I believe not. There needs to be some cleanup of that
            section judging by antonp's comments. Issue itself
            stands. antonp pointed out the intention of the spec.

  astearns: You're looking for a resolution to make this change?
  fantasai: Yes.
  astearns: Would it make any sense to put this edit into 2.2
  fantasai: Probably into both. I'm not sure what we're doing with
            2.1 in terms of maintenance.
  fantasai: I think it's up to Bert if he wants to maintain the
            errata. We're supposed to technically.
  ChrisL: There's no point in doing so. 2.2 has been published and
          2.1 says don't look at this.
  fantasai: That's fine.
  fantasai: So it needs to be updated in level 2 and level 3.
  astearns: Proposed resolution: make this change into 2.2?
  fantasai: Let's call it 2. Say the line height is a box equal to
            the line height value and doesn't get adjusted by
            fallback fonts shifting baselines.
  <tantek> if browsers are all already doing this, why not errata

  astearns: Objections to making this clarification to 2.2?
  ChrisL: I'd like to check it's clear enough with Bert.
  ChrisL: Is Bert on?
  ChrisL: I guess we need to minute carefully.

  dbaron: I think...this was prose we explicitly decided to add to
          2.1 despite lack of implementation of the concept.
  <tantek> yes - what dbaron is saying
  fantasai: The spec contradicts itself.
  dbaron: Okay.
  <tantek> fantasai, that's an even stronger reason to errata 2.1.

  SteveZ: Can you clarify the contradiction?
  fantasai: In the first comment it says [reads]
  fantasai: If the height of the inline box includes all glyphs and
            half leading it'll be more than one. The last sentence
            contradicts. Either it's exactly line height or it
            encloses all glyphs.
  dbaron: Or you determine half leading based on the expanded height.
  fantasai: You do it per glyph and half is above a and the other
            below d.
  dbaron: I didn't think that's what you were supposed to do.
  fantasai: It's not what people do or spec intent, but that's the
            result of the prose.
  fantasai: That's the initial comment, 3rd has a test.

  dbaron: Is it worth trying to find out what implementations do?
  fantasai: Blink and Gecko use first available font metrics and
            it's exactly line height. It ignores shifts from
            fallback fonts. I didn't test Edge.
  astearns: Proposed edit is make the last clause of the last
            sentence correct that it's exactly line height and
            remove taking all glyphs into account.
  SteveZ: My memory may be bad, but I would have thought the last
          sentence was incorrect. Line height never produced a line
          that was line height high so lines won't collide.
  fantasai: That's because it adjusts for children. In a single
            inline box where you're only dealing with fallback the
            height of that box is exactly line height in blink and
  SteveZ: Should be clear it applies if there's no font change.
  fantasai: Yes. It's not talking about the children.
  SteveZ: If I have a list of fonts and one of those has italics
          with a huge over-swing I'd like the ascenders to take
          effect. That's not fallback. I don't have a font that does
          all the stuff.
  fantasai: I think this is a case where if you're making an
            explicit change in font we'll accommodate your new
            metrics. If you're falling back we don't want that to
            make any changes in line height. If we changed to adjust
            for the slight shifts anything trying to precisely align
            text might break.
  fantasai: I think this is an opportunity to fix the spec to be
            consistent with implementations and cause less jitter.
  SteveZ: I think the case you outlined I agree. I don't know how to
          distinguish between when I have a lot of fallbacks because
          nothing has everything I want. I want to use the metrics
          of everything I'm using. The list if the order in which I
          want characters searched for, not the metrics used.
  fantasai: You want line to line height to be consistent. You
            wouldn't choose very different line height fonts as your
            fallbacks in your case.

  astearns: In any case, I think it would make sense to have to spec
            say what browsers are doing with line height. And from
            the test case the fallbacks are not being taken into
  SteveZ: I would like to hear Bert's opinion before we decide.
  astearns: How about this. fantasai has outlined the problem but
            haven't come up with the text you would put into the
            draft. Can you update the issue with that prose and
            we'll discuss there?
  fantasai: Sure.

  ACTION fantasai come up with the prose fix for the definition of
         line-height calculations contradicts itself issue (#391)
  <trackbot> Created ACTION-798

The minimum and preferred width of a multicol is not defined anywhere

  <astearns> https://github.com/w3c/csswg-drafts/issues/420
  frremy: I discovered this because in Edge we have a strange way of
          computing. When I tried to find out the spec behavior I
          couldn't find it so it would make sense to decide what to
  TabAtkins: It looks like it is defined now in Sizing. Min and max
             are defined there and it matches FF.
  frremy: So it's in Sizing spec. Okay.
  fantasai: It's in sizing because multicol wasn't being maintained
            and this was significant stuff. We put it in sizing and
            it got pushed to level 4.
  frremy: That's fine. If you have it defined that's perfect.
  Florian: If we do want to push in multicol I'm an editor but I
           think it's better where it is now.

Positioning boxes with { float:left; width:0px; }

  <astearns> https://github.com/w3c/csswg-drafts/issues/576
  frremy: Basically this is a strange case. When you have a
          float:left and it's 0px it effects the line. The problem I
          have, technically you can put the float there and edge
          does it but it seems like blink decided it's not big
          enough to fit the float.
  TabAtkins: I discussed with my team and we think ours is right
             behavior. It's when the proceeding float is = or > than
             size. Same size everyone agrees. When it's bigger we
             shift the float and I prefer that because it matches
             the general way you would define line breaking,
             especially it matches the flexbox algorithm.
  TabAtkins: It gives you the exact behavior Chrome has if you apply
             it to inline and floats. If one thing on the line
             overflows the 0px thing goes to the next place.
  dbaron: We had made a bunch of edits to 2.1 that FF hasn't
          implemented. That's not the best of indicators.
  dbaron: I'd like a change to read antonp's reply.

  Florian: In addition to the similar there's also an argument that
           pushing to the next line minimizes the chance of things
  astearns: Proposal to have this moving to the next line behavior
            when the line has already consumed more than the
            available space. Would it go into the box module or is
            this a css 2 edit?
  TabAtkins: I hadn't digested antonp reply, but from my reading 2.1
             doesn't fully define and therefore should be edited.
  <ChrisL> 2.1 or 2.2?
  <tantek> do we not already have a documented / agreed WG policy
           for 2.1 errata vs. 2.2 additions/changes?
  <astearns> I believe the policy is to errata 2.1
  <tantek> astearns: for all changes for 2.2?
  <TabAtkins> ChrisL 2.2, sorry.
  <TabAtkins> I just read whatever's at drafts.csswg.org/css2
  <tantek> is just trying to understand if we're case-by-casing
           everything, or if there is a general 2.1 vs 2.2 policy

  dbaron: It defined the case except for what the definition of
          shortening a line box.
  frremy: [missed] I'm fine saying we should match Chrome and Gecko,
          we should make sure we properly state it in the spec.
  dbaron: This area is a little dangerous because the reasons impl
          are doing things in test cases are mostly related to other
          bugs, not what we're discussing.
  frremy: What's the plan? Take more time? Resolve today? I'm fine
          with pushing back if we need more time.
  dbaron: I'd like more time to read antonp's reply.
  astearns: Can I put it on next week's agenda?
  frremy: Yeah.
  astearns: dbaron is that enough time?
  dbaron: Sure.
  <dbaron> This is just the case of Anton replying here because he
           saw it on the agenda, and me not seeing his reply because
           I looked through the agenda before he replied.

Trying to find a topic

  astearns: We didn't do Test DoC issues because Myles wanted to be
            on. There's 6 items from the TPAC agenda and 12 minutes.
            Anyone see anything in the overflow that could be
            usefully discussed in 12 minutes?
  Florian: I think the CSS Containment Terminology question can be
           removed from the agenda?
  astearns: Okay. I'll take that off the list.

  astearns: @apply item?
  TabAtkins: I don't believe it's ready right now. I need more
             private discussion before it's worth going public.
  astearns: I'll take that off and wait for it to be agenda+

  fantasai: We still have first/last baseline issue open.
  fantasai: It needs to be resolved before we can complete alignment.
  frremy: Do you have a link?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/210
  astearns: ^
  fantasai: It's a syntax and property interaction issue.
  fantasai: It would be good to get thoughts/comments/reasons why
            one is better. We have 3 options so far.

  fantasai: Another alignment was if we should add a shorthand for
            align-content and justify-content. Two 2 names were
            place-content and arrange-content.
  <jensimmons> link?
  TabAtkins: Were did that come from?
  fantasai: Another issue.
  TabAtkins: I haven't seen that one.
  astearns: I'm not seeing an align issue that mentions place in
  fantasai: I'll try and file it maybe it was just draft.
  <fantasai> align-foo + justify-foo = what-foo?
  fantasai: We're bikesheding.
  TabAtkins: Yeah, we need to find it. I can't find it in issues or
             the draft. We shouldn't discuss until it's exposed
  <jensimmons> yeah, I’d love to help with that…
  astearns: Let's put the first/last baseline issue on for next
            week. We'll find the discussion about a shorthand and
            maybe put that on as well.

  astearns: What is the pseudo element issue?
  fantasai: I don't know.
  TabAtkins: There are issues with the draft to go through.
  fantasai: I don't think any are ready.
  TabAtkins: Right.

  astearns: Table wrappers we couldn't do.
  astearns: Last is clip-path
  TabAtkins: I discussed with a team mate, but we're not ready.
  astearns: I'll do agenda wrangling for next week. Anything else?
  <tantek> appreciates astearns agenda-wrangling, especially for
           items for drafts we're trying to take to CR by end of 2016

  <fantasai> https://lists.w3.org/Archives/Public/public-editing-tf/2016Apr/0005.html
  fantasai: I posted the URL to the copy/paste issue and I'll add it
            to the DoC
  fantasai: Look that over, that's on the Text list.
  astearns: Okay. Could this be opened as an issue on a draft?
  fantasai: I believe it was filed in email but I can add it to
            github. I'll do that.
  astearns: Anything else?

  astearns: Then I think we're done for the week.
  astearns: Thanks everyone for calling in.

Received on Thursday, 13 October 2016 00:28:33 UTC