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

# Dael Jackson (2 days ago)

========================================= 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: w3c/csswg-drafts#1777 )

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

ignored

  • 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

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: lists.w3.org/Archives/Public/www-style/2017Oct/0022.html

Present: 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

Regrets: 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> w3c/csswg-drafts#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 accurate.

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: w3c/csswg-drafts#1777

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. Objections?

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 explaining.

Percentages and intrinsic size (decide on indefinitely-sized

containers)

github: w3c/csswg-drafts#509

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 reviewed. 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: w3c/csswg-drafts#1823

florian: I realized there was ambig. in the definition. [reads from spec: 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 break. [...] 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 content.

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 change. 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. Objections? TabAtkins: Nope.

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

ignored

github: w3c/csswg-drafts#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 faces.

What to do with Shepherd test issues?

github: w3c/web-platform-tests#5485

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 tests. <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 prevented. 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> 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 superseded.

<dbaron> 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 topic.

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> 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 insensitive. 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 insensitive. 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 case.

astearns: That's it for the call. Thanks everyone.

Contact us to advertise here

Want more features?

Request early access to our private beta of readable email premium.