Brief   Full   Jump  


High contrast


Minutes Telecon 2018-07-18 [css-fonts-4] [css-display] [cssom-1] [css-overflow] [css-text]

1 message.

Minutes Telecon 2018-07-18 [css-fonts-4] [css-display] [cssom-1] [css-overflow] [css-text]
Dael Jackson   Thu, 19 Jul 2018 05:01:13 -0400

www-style > July 2018 > 0017.html

Received on Thursday, 19 July 2018 09:02:13 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. ========================================= Fonts 4 ------- - RESOLVED: Add Chris Lilley as editor to fonts 4 CSS Display ----------- - RESOLVED: Keep it that blockification and establishing formatting context are independent (Issue #2673) - As a part of the discussion for issue #2673 it was raised that part of the reason blockification and establishing a formatting context were requested to be linked is the earlier resolution to make inline flow-root and inline block the same. Over the next week people will re-look at that decision ( ) and re-open it if necessary. - Unless there is a new issue opened, next week there will be a CR publication request. CSSOM ----- - RESOLVED: Have the PR as the start of a set of constraints with Gecko algorithm as an example in a note CSS Overflow ------------ - RESOLVED: Keep current definition such that we could all lines in overflow:clip descendant (Issue #2421) CSS Text -------- - RESOLVED: Handle percent text-indent in intrinsic size box same as percent in padding and margin (Issue #1597) - RESOLVED: Defer this issue (#2390: Implement or unship word-break:break-word) for now [to Level 4] ===== FULL MINUTES BELOW ====== Agenda: Present: Rossen Atanasso Tab Atkins David Baron Garrett Berg Oriol Brufau (IRC Only) Tantek Çelik Emilio Cobos Álvarez Dave Cramer Tony Graham Dael Jackson Brian Kardell Brad Kemper Peter Linss Thierry Michel Anton Prowse Liam Quin Manuel Rego Casasnovas Florian Rivoal Jen Simmons Alan Stearns Regrets: Rachel Andrew Benjamin De Cock Chris Harrelson Chris Lilley Michael Miller Melanie Richards Lea Verou Greg Whitworth Scribe: dael Fonts 4 ======= astearns: Let's start astearns: Does anyone have any last minute changes/additions? fantasai: Resolution for chrisl to be editor of fonts 4? Editing fonts 3 and not fonts 4 seems like an oversight astearns: We didn't get one, but I'm happy to now. Is myles on? <myles> yes astearns: myles is this okay with you? myles: Yes RESOLVED: Add Chris Lilley as editor to fonts 4 astearns: I believe that's in the draft already so it's now official CSS Display =========== Blockifications should establish BFC in block containers -------------------------------------------------------- github: TabAtkins: Oriol has been asking for if blockification should auto establish bfc rather then occasionally explicit. fantasai and I disagreeing because they don't happen every time TabAtkins: If anyone disagrees and things blockification should auto be a BFC, great let's talk. If not looking for resolution of support Rossen: You saying that blocification doens't force BFC? TabAtkins: Not intrinsically. Rossen: Example? TabAtkins: Have to look. TabAtkins: Any time we blockify and inline-block does not cause it to become a FC it just goes to block fantasai: That's true in that it does not change the display computation. That's required by backwards compat. fantasai: We could change to not change display and also make it a formatting context. We do that for float abspos and others fantasai: Right now when we do blockification in cases where new element will establish new FC anyway. If we apply blockification in flow blocks I don't think we'd want new FC. Grid items currently blockify and a subgrid isn't a new FC Rossen: does subgrid blockify? fantasai: If we did we'd need an exception. It has to blockify because if it's an inline grid it becomes not an inline. When it's a grid item...if you have an item inside a grid that element is blockified. Blockification if it says display inline it becomes block. inline-table become block, inline-grid becomes block. But a subgrid isn't a new FC because it intertwines with grid outside. Can't say it's a new FC, but it is blockified fantasai: I don't think we can tie these two concepts together. block makes it a block. They almost always coincide but I don't think the concepts are intrinsically bound and shouldn't be tied in spec * emilio agrees with fantasai florian: Exception of subgrid this is an editorial twist as to if you describe separately or together. So it's editorial. <Oriol> But I think a BFC is desired if you have `display: inline flow-root`. CSS DIsplay says it becomes `flock flow`, and a future feature might blockify without forcing BFC. Then the flow-rootness will be lost dbaron: I think one other point in the issue from Oriol. I think Oriol trying to put in IRC too dbaron: Current blockification remove flow-root nature. If blockification always makes things FC it's fine. If it doesn't then maybe blockification rules need to be fixed so if you say flow-root you don't lose that fantasai: So far cases where lose flow-root is converting inline flow-root or a run-in flow-root. In case of inline-block we can't change how display is computed due to backwards compat. fantasai: Every other case where flow-root is blockified it establishes a new FC anyway. fantasai: We're flowing it, we're abspos it, putting it in a grid or flexbox. These are cases where element that is a block container it establishes a new FC dbaron: So in subgrid it's not possible to be a new FC? fantasai: Matter of terminology, but fundamental idea of a new FC is there's no intertwining between new and old FC. If there's info passed through the boundaries when you do something like whitespace collapsing it's porous. Same is true for display:block, margins collapse through boundary. The contents inside and outside participate fantasai: New FC creates a barrier without that bleedthrough. The justification and alignment doesn't pass through the inline-block boundary. Same as a block element with new FC. fantasai: For a grid, if you nest a grid inside a grid same thing applies. No interactions between grid tracks inside a nested grid. Subgrid you do have negotiation between inner subgrid context and outer parents and siblings. They participate together in sizing algo fantasai: The size declarations and names of lines on parent pass to subgrid. There is fundamental bleeding through of the content and the layout calc. To say it's a new FC doesn't make sense. dbaron: Makes sense to me. Some point earlier I thought you said that...something about how these were still block formatting context. fantasai: Grid items are considered grid level, not block. They participate in grid FC. But there is blockificaiton process that changes display values to make them block-like. We convert anything with a non-block outer display to a block dbaron: And one of the blockified things can be a subgrid? fantasai: You run blockification on every grid item. You run it through blockification Might be a no-op, but you run through. fantasai: Was we decided to do subgrid with a new type the display-type of a subgrid needs to be declared. If you say grid or inline grid doesn't really matter. fantasai: Blockification process turns inline on subgrid to grid. dbaron: I worried you said display: block could be subgrid fantasai: No, you can't florian: Blockification is really dis-inline-ification fantasai: In a sense. We have outer display type which says how your behavior is when in flow layout. Outside of flow layout distinction between inline and block has no meaning and is ignored. Each display value corresponds to a state. fantasai: If I take subgrid and put it in a bfc it will not behave as subgrid, but it'll be the fallback behavior. <TabAtkins> Core point tho: grid items are blockified, subgrids are grid items (by definition) but aren't FCs (by definition), so blockification *cannot* imply FCification in general. fantasai: Whether declared inline or block grid it'll make a difference in participation once in block container astearns: Back to original issue: We have a choice of keeping things as we are where blockification and formatting context are discussed separate. Or we changes that blockification implies a FC but it can be overwritten in places like subgrid astearns: Argument that 2 things are separate is compelling to me because having both explicit sounds easier to comprehend. I like that it's explicit astearns: Argument to tie together is that there may be situations in the future where we might forget about forcing FC in blockification case where we need it to happen. Benefit for the explicit call outweighs danger of forgetting to make that call in the future. <florian> since this makes no behavior difference, this is editorial, and I like to leave it up to the editors to describe it the way they want. That helps the whole prose be coherent <AmeliaBR> Is there any consequence of blockification that *is* necessary for subgrid? Or can it just be that "grid-items are blockified (and create a formatting context), *except* for those with `display: subgrid`"? <fantasai> AmeliaBR, inline-grid needs to be converted to grid <fantasai> ('display' value) dbaron: Blockification without FCification doesn't work in a block context. In grid it's fine, but in block context it removes the things that are supposed to be FC. I think that's a piece Oriol doesn't like. Maybe it's that we never will use and so it's okay. Might be worth noting. astearns: Make sense to call that out in all current cases you need the 2 in a block context <Oriol> Yes, the problem is with flow layout <fantasai> dbaron, I missed exactly the sense of what you said, and the first sentence of the minutes doesn't make sense... * dbaron thinks the minutes are right <fantasai> ... ok, I think I understand. Disagree somewhat, though. <myles> are we discussing a behavior change, or just wording in the spec? <astearns> myles just wording, afaik Rossen: fwiw, from impl experience we've had this model inside our engine since IE9. During style computation we independently decide inner layout type, outside layout placement (where you will be placed), and 2 auxiliary ones, based on the layout placement and type we compute if you're a BFC and if you require a stacking context. Rossen: What I can tell you is they're all independent. But I don't see why we should unless from inline-block PoV we have to. fantasai: Address point from Oriol and dbaron where if you happen to use blockification for block level items question...example is an inline-block when blockifies turns into display:block which is porous. Argument is inline-block should be a block flow-root and a new FC. Not convinced of that being the expectation. fantasai: I think that's part of why it's not in CSS 2.1...distinction between block, block layout, and bfc is not huge. inline-block vs a block do form a pair. fantasai: Formatting context establishment is a side effect because they just want this as a block to be a FC, not something they specifically needed. <Oriol> I think it may be OK if inline-block doesn't become a flow-root, but if you explicitly specify flow-root, you shouldn't lose it fantasai: I'm not sure what you would expect, but becoming display:block isn't necessarily unexpected. If you said inline flow-root it's clear you wanted that but we're getting into fiddly cases and we decided inline-block and flow-root are identical dbaron: I think this is a negative side effect of that. Prob fine for inline-block, but weird if flow-root. dbaron: I think I'm okay just concluding here astearns: And close no change dbaron ? dbaron: I think no change and a note pointing out that it isn't great if if you do blockification without FC and people used flow-root explicitly astearns: Need to ask Oriol if he's okay closing with a note. <Oriol> OK, but note that if a future feature allows blockification without BFC, then it will be more difficult to change astearns: And would anyone else objects to resolve no change except adding a note fantasai: 3 ways forward, to be clear. fantasai: 1) close no change FC and blockification are independent fantasai: 2) blockification implies FCificiation so inline-block converts to block flow-root and we will need an exception for subgrid fantasai: 3) revert resolution where we said inline-block and inline flow are identical and say they're independent and have same behavior except if you blockify. fantasai: That lets you when you blockify inline flow-root it becomes display: flow-root <dbaron> I'd be fine with (3) based on this discussion but I don't know why we made that resolution to begin with. astearns: We're 30 minutes on this issue. My preference would be close no change and raise a new issue on inline-block and inline flow-root fantasai: We had an issue and resolved on the current. Only reason to re-open is if people want option 3 which gets you independence for blockification and FCification but also clarifies the inline flow-root. astearns: Reopening that with this in mind makes sense and doesn't change how we'd resolve here. fantasai: Fair enough astearns: I'd like to close this. astearns: Let's resolve that blockification and establishing FC are independent and we will add a note on the flow-root issue which can become a github issue to change our previous decision <Oriol> Works for me fantasai: This is last open issue before CR so we need to open the issue or go to CR astearns: Objections to keep blockification and establishing FC are independent RESOLVED: Keep it that blockification and establishing FC are independent astearns: Anyone think we should take up an issue about inline-block and inline flow-root? florian: Rather not dbaron: Don't know context of original decision so hard to know <fantasai> dbaron, discussion at astearns: Let's leave at that this week. Those in the discussion please decide if open new issue. Rossen: Should we resolve on to CR? astearns: Let's give another week and go to CR next week. CSSOM ===== Replace steps of set a CSS declaration with some constraints ------------------------------------------------------------ github: emilio: Issue is that the latest resolution on how set property behaved: it always appends to end of declaration so it's sane with logical prop. It's a nightmare of webcompat and perf for Gecko and Blink emilio: We turned it off in Gecko and backed out in Blink. xidorn had this proposal to let a set of properties in a logical group and in a UA dependent way that's in same logical group it need to appear after so setProperty behaves correct emilio: I think frremy...what xidorn did in gecko which we haven't landed is that if you get to the case where a prop and there's another from the group that defers we append the new prop emilio: xidorn proposes to define in terms of constraints which I'm okay, but prefer define properly. Only reason not to do is proposal from frremy. We need to decide if we're fine resolving like this or if fine to say it's constraints and UA can do what they want or define algorithm in spec frremy: From what I recall my proposal was pretty in line with constraints. I'm fine with them as defined. Good to have UA experiment. If it's fine we can refine further. Fine to go with xidorn proposal for now. It makes a lot of sense. emilio: Okay astearns: I agree, emilio. It's good to have things properly defined once we have impl experience and can determine the constraints. Happy starting with the PR and adding emilio: People fine with gecko algorithm as an example? florian: Sounds okay astearns: As a note? emilio: Pretty much. astearns: Objections to having the PR as the start of a set of constraints with gecko algo as an example in a note? frremy: Sounds good RESOLVED: Have the PR as the start of a set of constraints with Gecko algorithm as an example in a note astearns: Anything else on this? CSS Overflow ============ How does max-lines interact with hidden content? ------------------------------------------------ github: florian: This started much broader and we're almost done. Just a corner case we haven't decided explicitly. florian: The broad topic is which lines do we count when we have max-lines and a decedent or BFCs or a child also with max-lines. We resolved we skip when you nest max-lines. Resolved for most of overflow. Remaining bit is overflow:clip florian: overflow:clip is not a BFC so it implies you could the lines inline overflow:clip. I think close this with no more changes needed. Rossen: Is the issue different if overflow:clip is applied to max-lines container? florian: This is on descendant Rossen: How is it different then when on max-line container? florian: On container it doesn't do anything special and overflow not terribly relevant. Rossen: But then you can extract same thing happens with child. florian: So you're okay no change? Rossen: Yes astearns: We could lines in descendant with overflow:clip, but only not overflowing? florian: Count all the lines Rossen: Overflow:clip doesn't effect count of lines florian: Right astearns: Gotcha astearns: Objections to keep current definition such that we could all lines in overflow:clip descendant? fantasai: I think this is correct. Might be initially confusing but it's the right model RESOLVED: Keep current definition such that we could all lines in overflow:clip descendant CSS Text ======== Percentage of 'text-indent' against intrinsically sized box? ------------------------------------------------------------ github: florian: Had previous discussion about text-indent and % and we resolved which element to resolve % against. Not that discussion. This is what do we do when intrinsic sizing. If indent grows the size and depends on the size we've got a loop florian: I think we got close to consensus but ran out of time. I remember that no one had a use case for % text-indent on an intrinsic size thing so easiest is to say % resolves to 0 and there's no loop. florian: Alt is min-content. That works for me too. I don't think this is use case driven. florian: Only thing to push us toward not-0 is people might want large negative % to hide stuff. Dunno if done much with text-indent. So I'd go with 0, but min-content is okay <Rossen> +1 to 0- <fantasai>!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22float%3A%20left%3B%20border%3A%20solid%3B%20text-indent%3A%2050%25%22%3EThis%20is%20a%20test dbaron: I think normal thing in these cases is we resolve to 0 during intrinsic-width computation and then resolve width during layout. Is that what you mean with 0? dbaron: I think that's how we treat % padding and % margin. <Rossen> what David said ^ florian: I think that's fine astearns: Prop: Handle % text-indent in intrinsic size box same as % in padding and margin Rossen: This is current behavior as well, we resolve % against containing block so we can't resolve them during intrinsic sizing. astearns: Other opinions? <dbaron> (I think this is also what Mats was asking for in the issue.) <tantek> what Rossen said astearns: Obj? RESOLVED: Handle % text-indent in intrinsic size box same as % in padding and margin fantasai: % padding and margin on a child of the element dbaron: I think it's the same as on that element fantasai: No if you set explicit width resolves correct Rossen: Not really. Element is being intrinsically size. That's the same so text-indent can't resolve just like you can't do min-width etc. fantasai: But when you do resolve it's the size of the element, not the size of the parent. Which is different then margins and padding which look at parent Rossen: Don't see how child comes into play. But let's move on. We're on same page Implement or unship word-break:break-word ----------------------------------------- github: fantasai: I think it's that we have issue open about adding non-standard word-break:break-word to CSS. Not word-break:break-all. This allows you to wrap if you run out of room. Should have a property with same behavior where word-wrap:break-word effects intrinsic size of element <tantek> can we get intent to unship by whoever supports it if it's not a compat problem? fantasai: We were asked to add new value word-break:break-word for web compat and we pushed back because it's confusing. We said we'd add value if FF and Edge found themselves compelled for web compat to impl. They have not so far. To not go down that path we made word-wrap:break-word have the same behavior that they would have gotten from word-break:break-word * myles is not following <tantek> myles does Safari/Webkit support word-break:break-word? And if so, can you unship? fantasai: I recommend close no change for the moment. If our attempts to stem the webcompat problem is not successful we'll assume Edge or FF will file an issue saying we need this. astearns: tantek asked on IRC [reads] fantasai: For the moment I don't think we should ask. We should give time for impl to catch up with word-wrap:break-word behavior change so authors can use that in place of word-break:break-word fantasai: I think we need to give a year or 2 before we ask blink and webkit to unship so the web can adapt to standards compliant way. florian: Also a chance this transition will be less painful since in browsers that don't have it, the least bad fallback is to use the property we recommend. florian: But we can't unship until we ship alternative. <emilio> Gecko just implemented, fwiw <dbaron> emilio, implemented what? <tantek> emilio: oh well, sounds like we're screwed then <fantasai> dbaron, <emilio> tantek: dbaron: The new behavior, I mean, sorry: tantek: I wanted to comment that the process that we should wait on compat is orthogonal because compat has nothing to do with what authors want. Compat is are we screwed by what's in the past. If we're screwed waiting won't change it. If we're not waiting can make it worse. If you're serious about dropping you need to do it asap regardless of if the authors have an equivalent feature. You won't avoid compat in the future by introducing a future feature. The reasoning is poor <astearns> +1 to tantek florian: We're inbetween. This is sufficiently used... tantek: Is it on the record? I want blink and webkit to say here's why we can't unship. Let's not presume unshippability florian: I think we have it. Need to find it frremy: It was discussed at a F2F and Google said won't unship. tantek: Do we have a % number to justify not unshipping? frremy: I think they did. tantek: If they did did they give us a % for if it drop below they'll unship? That's what we need for this to be numbers based <Rossen> +1 to tantek fantasai: Blink contacted site owners asking them to change. Site owners didn't want to change because they needed specific property behavior. We need time for that. <tantek> emilio can you link the FF impl bug or FF intent to ship? <emilio> tantek: fantasai: florian was saying that we're in-between. Usage is not high enough that Edge and FF need to impl, but too high for chrome and blink to unship. Gecko has implemented new property behavior and not non-standard thing fantasai: We need to wait for that change to deploy across browsers so site authors will change and then reduce web compat impact and then let them unship <fantasai> <tantek> where is the commitment to implement the new property/value behavior from others? <tantek> is FF the only implementation? astearns: We're overtime. Whether or not we can get unship for non-standard...Well, this issue is impl or unship so I think we can resolve not to add non-standard property but unship question is in the air. fantasai: My recommendation is we close or defer this issue so it's not sitting tantek: Let's defer frremy: Defer to next level. I like this florian: Defer good astearns: Objection to defer this issue for now? RESOLVED: defer this issue for now