Brief   Full   Jump  


High contrast


[CSSWG] Minutes Telecon 2018-05-23 [css-grid-2] [css-text-decor] [css-display] [css-text-3] [css-contain]

1 message.

[CSSWG] Minutes Telecon 2018-05-23 [css-grid-2] [css-text-decor] [css-display] [css-text-3] [css-contain]
Dael Jackson   Wed, 23 May 2018 20:09:58 -0400

www-style > May 2018 > 0036.html

Received on Thursday, 24 May 2018 00:10:56 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to:

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Grid L2 ------------ - RESOLVED: Add fr unit support as min arg inside minmax for Grid L2. (Issue #2611) - Having a three value syntax for minmax (Example: minmax(5em, 2fr, 250px)) will be considered later and separately from the rest of Issue #2611. - RESOLVED: Accept the edits in around subgrid and grid-gap (Issue #2285) Text Decor ---------- - RESOLVED: Accept the proposed changes (to skip unicode punctuation characters for emphasis marks with a few exceptions)and follow up with unicode [on why there are exceptions] (Issue #839) - RESOLVED: updated publication of css-text-decor-3 CR CSS Display ----------- - RESOLVED: Accept proposal in (A block container that establishes a new block formatting context is considered to have a used display value of flow-root.) - RESOLVED: Defer to css-pseudo-4 to address [interaction between display:contents and ::first-line] as part of more rigorously defining ::first-line cascading/inheritance. (Issue #1310) - RESOLVED: Defer #1810 and #2365 to later. - There are only a few issues remaining for CSS Display so the editors plan to request CR possibly as early as next week. Anyone planning to do a spec review before that transition should do so soon. CSS Text 3 ---------- - RESOLVED: Accept the proposal in Issue #2682 (make the existing word-wrap/overflow-wrap property affect intrinsic sizing) CSS Contain ----------- - RESOLVED: Accept the edits: [to clarify various meanings of 'formatting context'] (Issue #1457) ===== FULL MINUTES BELOW ====== Agenda: Present: Rachel Andrew Rossen Atanassov David Baron Tantek Çelik Emilio Cobos Álvarez Dave Cramer Alex Critchfield Elika Etemad Tony Graham Dael Jackson Brad Kemper Chris Lilley Peter Linss Myles Maxfield Thierry Michel Anton Prowse Liam Quin Melanie Richards Florian Rivoal Eric Willigers Regrets: Tab Atkins Benjamin De Cock Manuel Rego François Remy Dirk Schulze Alan Stearns Lea Verou Scribe: dael CSS Grid L1 & L2 ================ Applying 'justify-content' content distribution is in the wrong place in the overall grid sizing algo --------------------------------------------------------------------- github: Rossen: I think Manuel sent regrets. fantasai can you take this? fantasai: There was a bunch of discussion on github since adding to agenda, so I need to go back over before I could describe where it's at. [agenda wrangling] [debate if can do agenda item #2 without leaverou] [we can't] Allow fr units as min --------------------- github: fantasai: Based on rachelandrew's comment I say we allow length or percent but not content based keywords <fantasai> fantasai: We limited what you can put in min position of minmax in L1 because the requests came late. One of the use cases was I want fr with a cap of 250px fantasai: We wanted that to work. Figured out it's straight forward if there's not content based keywords. fantasai: Open questions are 1) do we want to allow this, I think yes. 2) allow percent in max position and I think we should. 3) Should we allow content based keywords in max position- no clear use case and complex to impl so I think start with no fantasai: 4) Do we want to allow a 3 argument minmax where you have some kind of explicit min like a content keyword or a length and then an fr unit in the middle and a max in the top. Rossen: Let's go separate. fr unit as a part of minmax first and see if we can resolve. Then 3 value. Rossen: Are there additional comments or ideas about support of fr units? Rossen: Proposed addition of fr unit support inside minmax for Grid L2. Objections? RESOLVED: Add fr unit support as min arg inside minmax for Grid L2. <fantasai> minmax(1fr, 250px) is accepted Rossen: Secondary issue is should we allow an additional 3rd functional value in the middle of min and max used for flexing and how that behaves <fantasai> question is now minmax(5em, 2fr, 250px) Rossen: Additional comments? Rossen: What's the primary use case for 3 value? fantasai: Right now you can control min or max of fr unit, column has to be at least this, but I want 1fr. Or you can say 1fr but cap. You can't do both. You might want a 0 minimum and you want 1fr and a cap of 250px Rossen: Basically you want...I see an example...min 5em, max 250px, and then 2fr in this case will... fantasai: We can come back to this. Rossen: Yeeeeeaaah...I'm not sure. Rossen: Why isn't that covered by min width? fantasai: In a sense it is. You can't do min width on column Rossen: Ah this is for columns fantasai: Yeah, since fr have implicit auto minimum if you set min width on any items we'll use that. So you can kind of get there. rachelandrew: I've had people ask for this. That's the advice I gave is put something on item. Rossen: It's achievable using items as a spacer and fr as the min. Rossen: I'd be happy to come back. I want to think a bit more on this. Rossen: If others are ready? [silence] Rossen: Should we come back to this? fantasai: We'll close this and consider the 3 value syntax in the future. subgrid and grid-gap -------------------- github: <Rossen> fantasai: Initially when we created subgrid we said you can't control the gaps in the subgrid. Request was to be able to control. What we're doing is we added text to explain. If the subgrid's gap value is different then parent we add fake margins to the edges of the items adjacent to one of the gaps. fantasai: We're kind of doing this for outer edges of items on subgrid. fantasai: Using the same technique we're handling the differences in grid-gaps. afaict this is the behavior authors want. Allows gap control, simple from impl view. <fantasai> fantasai: It's checked in and you can read text here ^ fantasai: This is a question of does it sound good to everyone? Rossen: I did read this ahead of the call. Doesn't seem difficult to impl. Valid use cases. I support. Rossen: Other opinions? Rossen: Objections to proposed edits? RESOLVED: Accept the edits. <Rossen> Rossen: These the edits? fantasai: Yeah Text Decor ========== Characters to skip for emphasis marks (text-emphasis) ----------------------------------------------------- github: fantasai: We discussed and resolved to skip punctuation for emphasis marks because that's default expected. There was discussion with i18n. I checked in edits to impl that decision. fantasai: We skip characters in punctuation from unicode with a handful of exceptions. fantasai: I asked florian to talk to typographers in Japanese community. florian recommended adding another character. fantasai: Definition is straight forward. There's symbols in unicode punctuation so we're effectively re-categorizing. Things like @ aren't really punctuation. <fantasai> fantasai: Definition at end of ^ fantasai: That's where we're at. tantek: If we're going to diverge from unicode can we at least file a bug against unicode to say we think you made a mistake and we're patching it in CSS. To give them strong feedback. Elsewise seems bad to diverge. chris: Agree. tantek: I'm not saying it's wrong, I'm saying push the disagreement upstream. fantasai: Happy to explain, but because I think unicode general category is required to be stable I don't think unicode will be able to fix. tantek: Let's not assume failure. Let's try. Rossen: Okay. It's a valid point. Let's give them the feedback. Thanks tantek. <dbaron> Unicode has split categories in the past <liam> [the feedback may help Unicode in future too] florian: I'm in favor of this. As fantasai mentioned I reviewed. I reviewed and discussed details with Japanese people and according to them it's very subjective. The conclusions fantasai came to are in line with the rational they gave. Rossen: Great. Any other opinions? Rossen: Objections to accepting? RESOLVED: Accept the proposed changes and follow up with unicode Request to update css-text-decor-3 CR ------------------------------------- Rossen: Objections? Rossen: What's in this update? fantasai: There's a DoC and changes list. Rossen: Awesome Rossen: People can go look <fantasai> fantasai: DoC^ fantasai: Quite a lot <fantasai> fantasai: Changes ^ fantasai: DoC is colorful so may have questions, but everything should be accounted for chris: There's no objections. There's a few with no commenter response but as long as we made an effort. fantasai: Yeah Rossen: I'm not hearing objections to update css-text-decor-3 CR RESOLVED: updated publication of css-text-decor-3 CR chris: fantasai you'll raise an issue on transitions GH? fantasai: Yes. florian: fantasai do you want updated WD of L4 too? Or later? fantasai: I think L4 needs more work before it's publishable. CSS Display =========== 'flow' inner display type should never establish a BFC ------------------------------------------------------ github: <fantasai> fantasai: Comment ^ fantasai: We made an edit "a block container that establishes a new block formatting context is considered to have a used display value of flow-root." fantasai: We believe this is editorial and we wanted to flag the WG to confirm it's editorial [everyone reads] <dbaron> I think this may be hard to know until somebody tries implementing this... Rossen: You're saying a block container establishing a new fc inner display is flow-root fantasai: Used inner display of flow-root Rossen: Unless multicol? fantasai: I don't think we have a display type for multicol. It would presumably have same. We're not changing computed value, just used. Currently that's just a concept. Only effect of flow root is it establishes a BFC. florian: I think multicol is described as establishing BFC and I think I filed a bug saying that's weird. Rossen: Editorial part seems fine. Rossen: I'll re-read the spec for multicol. Rossen: This particular one seems good. fantasai: Multicol is difficult because it's a new type of FC. It's not really BFC but there's no display that aligns to it. fantasai: I'm wondering what dbaron is concerned about. dbaron: I just think...I'm not aware of an impl and I think it's complicated and there will be side effects you discover once anybody tries to impl fantasai: At the moment I think no effect on impl. Only time it will start to have an effect is if we start to expose used values through OM Rossen: As it stands... fantasai: That's the intent. If there's a different effect on impl it's not editorial. Rossen: At the moment it's editorial because there's no impl. Rossen: Objections to accepting the proposal RESOLVED: Accept proposal in <rachelandrew> ED of multicol says "A multi-column container establishes a new block formatting context, as per CSS 2.1 section 9.4.1." <Rossen> rachelandrew, right, the BFC part is understood, the inner display value is what will be interesting to define... since it's not really a flow-root <rachelandrew> there's no other mention - was trying to find the issue florian mentioned - which I think is this one <florian> rachelandrew, I was not referring to that issue <florian> rachelandrew, I was thinking about this one: Interaction of 'display: contents' and ::first-line --------------------------------------------------- github: fantasai: Proposal is defer to pseudo spec. Rossen: I support it. dbaron: Flip is display: contents is new and ::first-line has been around since css 1 Rossen: Then it's easier to spec in ::first-line dbaron: I don't think that's true. I proposed in the past removing ::first-line and first-letter...they're very complex fantasai: Part of the issue is inheritence and cascade of ::first-line and that's underspecified. I think solving here means we have to solve in pseudo first so it makes sense to solve together. fantasai: Either way both features are impl. It's a question of which spec do we tackle in. tantek: Impl with scare quotes. I'd be interested in seeing any interop tests fantasai: It's impl for other things, just not this combo of things. florian: Regardless of history, fantasai's point there's a dependency means we can push it there or be stuck. We can't just define in display. So I support the proposal. Rossen: Objections to defer to css-pseudo-4 to address as part of more rigorously defining ::first-line cascading/inheritance. ??: Which spec depends on which? fantasai: Defining interaction of display: contents and ::first-line is both. display:contents has no open issues. ::first-line has "someone please define inheritence" and defining how they combine requires that. fantasai: Proposal is defer the interaction definition to pseudo spec so that it can hold until inheritence is defined better. emilio: I would say claim ::first-line and display:contents is [missed] I think we need to define ::first-line earlier because if people want features that mess with layout modal emilio: I think if we want to start defining more complex features that mess with layout modal we should define these things earlier rather then later. Rossen: I sympathize. Only counter argument is that for the more complex features/layout systems it's not uncommon that we would push other horizontal features to the specific areas so that they define their own extension rather then trying to lump into one spec. Rossen: In this case I'm inclined to push complexity of display:contents to ::first-line into pseudo because it will take longer to define and no reason to hold back display:contents for ::first-line. emilio: Agree, but shouldn't defer defining infinitely. Rossen: Agree. If you have time to work on that people would support it. emilio: Fair enough. Rossen: Other opinions about this? If not we can try and resolve tantek: Only other make interaction a CR blocker. I'm fine with the proposal if we define that defining it blocks CR. fantasai: Not okay Rossen: Why is that the case? tantek: If you've impl ::first-line then the interaction is a new thing introduced by this spec and therefore must be defined or it's an outstanding issue which we're not to have when enter CR. florian: Assuming that other then display:content ::first-line was well defined I'd agree. But it's not so I don't. <fantasai> +1 to florian emilio: Yeah I think the... <emilio> I think the undefinedness is on ::first-line tantek: Whether or not it's well defined adding another thing makes it worse. We have to force resolution. fantasai: It'll be forced when trying to move pseudo to CR. It's on the to do list. Rossen: tantek your point is on the record. We're not close to CR. Once we're close we'll try and untangle. tantek: I'm worried about another semi-broken feature but I accept your approach <fantasai> tantek, it's already introduced, so putting it in CR is just doing our best to document reality Rossen: Objections? RESOLVED: Defer to css-pseudo-4 to address as part of more rigorously defining ::first-line cascading/inheritance. Clarify element tree definition ------------------------------- github: fantasai: Most information on how the DOM interaction is speced somewhere. It would be nice if we were more coherent and had an overview somewhere. But the interactions are defined so this is editorial issue fantasai: I'm not even sure what parts go into display spec. We have to figure out how to fit all the parts together to make understandable. fantasai: Proposal here is not to tackle that, but defer this and #2365 to later rather then block. Rossen: Reasonable. Rossen: Other opinions? Rossen: Objections? RESOLVED: Defer #1810 and #2365 to later Publication ----------- fantasai: That's it for display. There's 3 more editorial issues. At that point we should be done with display unless we get more issues. fantasai: Planning to compile DoC and changes and ask for CR maybe next week. If you want to review spec now is a good time to do that. Rossen: Fantastic. I support fantasai CTA to please look at display spec. It's been a while since work started and it's so big for functionality we should have it done sooner rather then later. CSS Text 3 ========== word-wrap/overflow-wrap: break-word should affect min-content ------------------------------------------------------------- github: fantasai: Issue is that...there's a number of cases where authors are frustrated with elements being bigger then they ought to be. Some are because they put overflow:scroll. Other set are related to I thought I told the text to be able to wrap if it needs to, why is element so big fantasai: That's the word-wrap/overflow-wrap:break-word which doesn't effect min-content. fantasai: There was discussion about word-break:break-word from webkit that does effect intrinsic size. We decided we wouldn't add that unless FF or Edge said they needed. fantasai: proposal is to solve several things. Give the authors the behavior that they're expecting so content can shrink down in the way they expect since right now if you're auto sizing the width is too big to break. It also means we can address reasons for the other syntax existing without adding the other syntax. fantasai: Having the syntactic mess is an awful situation to get in. florian: Canonical example is when there is a piece of text in a table cell with a long word and the put the overflow-wrap:break-word and the word stays long. fantasai: It's probably getting more frustrating because effects min-content in grid or flexbox. You put a URL in and say you can break, but it pushes out 1fr column for no good reason. It's not just in table cells. Flexbox and grid are relying on the min-content size. florian: Overall if we can do this it's a good idea. Can we or do we break compat with negative effects? I'm not too pessimistic but want to make sure. fantasai: It's a concern in general, but I think there's enough cases where changing behavior gets authors to where they want more then it breaks. Cases that will break is when you set overflow-wrap to a place where it allows breaking but then you're not expecting a break. fantasai: Most layouts aren't dependent on longest word. They asked for wrapping. I think more likely to fix then to break. ??: Seems fair Rossen: To be clear blink and webkit have this? fantasai: Under a different syntax. We've pushed back on adding that syntax. Only difference between them is how the effect intrinsic sizing. It's small but super confusing for authors. Even if they weren't syntactically similar it's still confusing to think in terms of intrinsic size Rossen: word-wrap:break-word you take all breaking content? fantasai: Just in min size florian: word-break controls other things as well, so with word-break:break-word you can't do that. With this approach you could. Rossen: Just wanted to clarify expectations. Rossen: Other opinions? Sounds reasonable way forward. Have to see what interop looks like Rossen: Or compat risk rather florian: Yeah fantasai: Yeah fantasai: Authors will be happy if we fix this. This is a major source of frustration with grid and flexbox. Sometimes allowing breaks...things get too big Rossen: I'm with you. Rossen: I'm mostly worried about older content in tables and whatnot out in the wild. All the sudden we introduce an adverse effect. But I'll let blink and webkit engineers spearhead since they have this behavior. Rossen: Objections? RESOLVED: Accept the proposal in Issue #2682 CSS Contain =========== Establishing independent formatting contexts -------------------------------------------- github: fantasai: There was an action to clarify what a formatting context is and how established. <fantasai> fantasai: re-wrote the definition ^ and added a definition for independent formatting context. Example ruby isn't really independent. Inline isn't independent of block. fantasai: Created the new term, did a lot of edits. Independent is what css-contain is trying to do. <fantasai> changeset is florian: I reviewed it, I like it. Rossen: Anyone else review? Rossen: Anyone want to review before resolving? [silence] Rossen: Objections to accepting the edits RESOLVED: Accept the edits Rossen: That's it for today. Have a great day, talk to you next week.