[CSSWG] Minutes Telecon 2019-10-16 [web-animations-1] [css-sizing-4] [css-grid-2] [css-text-3]

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Web Animations -------------- - RESOLVED: Pseudo elements are targeted via a parent plus a pseudo selector (Issue #4301: Dependency on CSSPseudoElement) CSS Sizing ---------- - RESOLVED: intrinsic-size is the name of the new property and value set is 'auto', 'legacy' and a length (Issue #4229: Proposal: content-size CSS property) - RESOLVED: We are redefining the size property in @page to be called page-size. Also defining that size in the page context parses into page-size. The size property is a shorthand for width and height (Issue #820: Adding a 'size' shorthand for 'width'/'height') Grid 2 ------ - There is ongoing discussion on github for how to resolve issue #4411 with several proposed solutions. The proposals are: 1) Define that a subgrid subsets its parent grid’s template based on what part of it is covered, and ensures that its edges provide the requisite -start/-end lines at its edges. 2) Define that the grid-*-start property searches the implicit lines before the first line instead of the lines after the last line if a specified line name is missing, similar to how span foo searches in opposite directions based on whether its a grid-*-start or grid-*-end value. 3) Define that, while implicit lines have most names in the infinite space of possible names, only lines before the first line also have names ending in -start, and only lines after the last line have names ending in -end. 4) Don't handle template subsetting; the cases you describe will be a type of error. - Anyone interested should add their thoughts to the github issue. - RESOLVED: Serialize the subgrid template rows and columns to only include line names defined for the subgrid locally and not include names that came from the parent grid (Issue #4362: `grid-template-rows/columns` Computed / Resolved Values for 'subgrid' values) CSS Text -------- - RESOLVED: Space before a line break is removed even if reordered to the middle of line by bidi reordering (Issue #4308: Define break at space to remove a space explicitly) - Florian will get i18n feedback for issue #4283 (Need additional value of word-break for Korean) to see if the property has use cases outside of Hangul, but the group was generally inclined to add a property to support this use case. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2019Oct/0018.html Present: Rachel Andrew Rossen Atanassov Tab Atkins Amelia Bellamy-Royds Oriol Brufau Tantek Çelik Emilio Cobos Álvarez Dave Cramer Benjamin De Cock Elika Etemad Simon Fraser Dael Jackson Brian Kardell Chris Lilley Myles Maxfield Stephen McGruer Peter Linss Anton Prowse Florian Rivoal Jen Simmons Regrets: Lea Verou Scribe: dael Rossen: Let's get going. We have too much to discuss today so we should start Rossen: I will call for agenda changes or additions Web Animations ============== Dependency on CSSPseudoElement ------------------------------ github: https://github.com/w3c/csswg-drafts/issues/4301 smcgruer: I'm hoping this is a rubber stamp. Hopefully everyone has read smcgruer: We have a problem where CSSPseudoElement has a lot of questions. For animations events and objects want to specify pseudo element by target being parent element. Similar to animations and transitions smcgruer: We expect this is how all will have to for for pseudo elements. No way to change events that happen today. smcgruer: Want to make sure makes sense for group florian: There was another conversation on pseudo events for highlighting and discussed with editing TF. Opinion of the Editing TF is it was inadequate so let's be careful how we use/expose florian: Not expert, but there was discussion on changing how looks/ works Rossen: I think the discussion florian referring to for highlight API were close to what's being proposed. From last I heard they want to start taking more dependency on this proposed model. Another was inking input want similar exposure for various types of actions and states. Want to be able to target similar eventing model Rossen: I have read the proposal, I don't think it's controversial. Want to hear from more people working in this space. Rossen: Not hearing any. Rossen: Are you looking for a resolution smcgruer? That accepts the proposal? smcgruer: Yeah fantasai: I wanted to ask if birtles has weighed in and what's his position smcgruer: My understanding is he agrees. He was part of the discussion. But I can't represent him directly Rossen: I don't believe he was opposed. We can re-open and continue if it's not complete. It doesn't come across that birtles is against in the thread. Rossen: I propose we resolve and if there's additional conversations we can re-open fantasai: Okay with that if assumption is correct AmeliaBR: What's the exact proposal? smcgruer: Prop: Animations have a target element. We propose for animations targeting pseudo elements is the target is the parent and an additional selector that lets you know which the new element it Rossen: Pseudo elements are targeted via a parent plus a pseudo selector * flackr notes it is equivalent to AnimationEvent here https://www.w3.org/TR/css-animations-1/#dom-animationeventinit-pseudoelement AmeliaBR: Has anyone thought about forward compat for a pseudo element dom object? smcgruer: Not extensively. That's fair. Problem in general is event targeting in general will have to solve that AmeliaBR: True. We have events where event target is the element. Rossen: Even if go down path of exposing pseudo element as objects need to have a way to target through selectors. That way will have to work here. Only change to model is how to get to event target. Rossen: If we expand the pseudo family we have to figure out how to select. Not unique to this proposal Rossen: Objections? RESOLVED: Pseudo elements are targeted via a parent plus a pseudo selector CSS Sizing 4 ============ Proposal: content-size CSS property ----------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4229 <AmeliaBR> https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override TabAtkins: With fantasai help and later edits after review with impl we drafted the property the intrinsic size property in L4 TabAtkins: Sets intrinsic size of the content. We thought we could do it by manipulating contributions, but not workable so it explicitly sets the intrinsic size. Further discussion about how to interact with overflow. TabAtkins: This is what we discussed at TPAC and said it was cool. It's authored now, review if you're interested florian: Contribution vs intrinsic summary? TabAtkins: Are you familiar with difference? Contribution is what a child element will tell parent its size is when parent defines size. If the child has width 50px it will say that regardless of content Rossen: Important to know it's border box size of the child. Content is content size which is content-box. That trips a lot of people TabAtkins: Reason why we couldn't go with contribution is because it doesn't have effect on sizing of element itself. It only effects parent's size. As defined before this property contribution is how it wants to be sized normally. Had to switch to the intrinsic size so when it tries to size itself it uses those contribution AmeliaBR: I think new name helps clarify. It's using wording we have. As long as consistent that this new property does the intrinsic size it might help clear up confusion TabAtkins: fantasai and I concerned with spelling being tricky, but it's used throughout the language so we figured it was a lost cause and should use the same word AmeliaBR: One point from heycam at end of issue about naming of keywords. He has a good point that legacy and auto aren't informative. Before naming something legacy we want to make sure we're certain only use case is describing stupid existing behavior TabAtkins: fantasai and I are convinced this is bad old legacy behavior and you wouldn't want intrinsic size of a scroller to report a really wide size. Point of a scroller is it's scrollable. We believe this is legacy and we do not want it. Lost opportunity to fix it but we think it is a straight up mistake and naming reflects that <fantasai> Issue wrt legacy vs normal https://github.com/w3c/csswg-drafts/issues/1865 Rossen: Proposal? TabAtkins: No resolution now. We did resolve at TPAC. This is a request for review. AmeliaBR: Resolve to accept the new names? TabAtkins: Probably? Let's resolve on intrinsic-size as the name with 'auto' and 'legacy' values Rossen: Proposal: intrinsic-size is the name of the new property and value set is 'auto' 'legacy' emilio: Wasn't there a proposal to set intrinsic size and that's separate? Seems like it should be a size not a keyword AmeliaBR: Default is a keyword that is do what we normally do TabAtkins: And you can specify a length or 2 lengths Rossen: Objections to intrinsic-size is the name of the new property and value set is 'auto' 'legacy' and a length? RESOLVED: intrinsic-size is the name of the new property and value set is 'auto', 'legacy' and a length Grid 2 ====== Subsetting grid-template-areas in subgrids ------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/4411 fantasai: Presenting the issue: Mats pointed out don't have way to have subgrid...if you have a grid area that's named with template and a subgrid that partially overlaps it will have only inherited line names. Might have foo-n line in the middle, but foo-start not inside subgrid fantasai: If you try and place item in slot foo it can't find the start line fantasai: Can we get that to fit within the part of the slot where it overlaps fantasai: Multiple ways to impl with proposals in issue. One is template areas are handled specially and generate extra line as necessary in order to have both edges represented within the subgrid. fantasai: Disadvantage is if you created grid area using lines it doesn't behave the same as with template. fantasai: Another proposal was define that if we can't find and foo-start lines or any foo lines in subgrid as searching grid-column-start instead of going to the nth edge of the subgrid we search into previous area fantasai: Problem with this is it's a slight change to general way grids work; could be web compat fantasai: Another is change search direction only for line names that start with 'start'. Again a behavior change fantasai: Last is don't handle template subsetting and you have the case where n line exists but start doesn't fantasai: Active discussion in issue, I don't think there's a clear right answer. Easiest is we pull the line names and you get weird results if using name from parent template grid. AmeliaBR: I don't think anyone will have strong opinions without looking in great details. Are you just letting us know? fantasai: Wanted to collect opinions. If no one has anything to add we can come back later Rossen: I think we should continue on GH on this one AmeliaBR: Isn't this a bit of a rush b/c FF is shipping? fantasai: Yeah, we should aim to figure out in the next week Rossen: Once we have a proposed solution we can add it. `grid-template-rows/columns` Computed / Resolved Values for 'subgrid' values --------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4362 fantasai: Have a WG resolution, noted there is a minor point that...we took resolved value as used value similar to regular grid. What we didn't consider is we unroll repeat values and truncate line names list to number we have. Didn't consider if adopt parent names active on sub grid. Mats prefers to leave then out of resolved value TabAtkins: And we're fine either way AmeliaBR: Debate is return extra information about the computation rather keep simplest computed style? Rossen: In case of one line name in subgrid and that name comes from parent grid it will serialize to nothing. Is that proposal? TabAtkins: Yes, if subgrid didn't get line names it will resolve to enough empty line name sets to give number of lines. You won't see parents line name Rossen: This makes sense from model point of view. Trying to think through scenarios where you need awareness of names TabAtkins: If you're trying to do some modeling on your own based on line names you might want full set. You can walk up grid, but it is more work. I suspect that's a low value case. Given not reflecting them down is easier for impl I'm fine leaving off Rossen: Also I think it is a better model. We can later on if there's use cases we can add with a different serializer Rossen: It's a good clarification to the previous resolution oriol: I think current wording is confusing it says excluding those defined in parent grid. What if they define same name, do we want to include? I think you're trying to say only include the one locally TabAtkins: Yes, it's local names, not local names minus parent. We can reword to make it clear Rossen: Anything else? Rossen: Proposal: Serialize the subgrid template rows and columns to only include line names defined for the subgrid locally and not include names that came from the parent grid RESOLVED: Serialize the subgrid template rows and columns to only include line names defined for the subgrid locally and not include names that came from the parent grid CSS Text ======== Define break at space to remove a space explicitly -------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4308 florian: Turns out that it isn't exactly defined or interoperably implemented what happens with interaction of dropping collapsible whitespace and bidi. If something would have been at the end and bidi moves it do you still drop it? Fuzzily defined. Chrome and FF do one thing, Safari and Edge HTML is different. I think Chrome/Firefox makes more sense. Screenshots in the issue florian: I propose we adopt Chrome/Firefox behavior and task editors to define it myles: Webkit would be willing to change Rossen: Edge HTML this could be considered. It's reasonable behavior florian: Proposal: Adopt the Chrome/Firefox behavior and action the editors to spec it Rossen: Can you be more specific? fantasai: Space before a line break is removed even if reorder to middle of line by bidi reordering RESOLVED: Space before a line break is removed even if reordered to the middle of line by bidi reordering CSS Sizing ========== Adding a 'size' shorthand for 'width'/'height' ---------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/820 TabAtkins: Discussed in past. Useful because size often set together. @page rule has a size declaration and we can't collide names. TabAtkins: fantasai had a great suggestion to unblock. Rename @page declaration to page-size. Define @page has a parse time alias of size turning into page-size and that frees up size. TabAtkins: Any existing pages using size will work. Anyone using CSSOM to page @page will see a page-size property. I suspect that's almost 0 since @page is only useful in printing. Printing doesn't have much JS support. Almost no possible breakage and this will let us do the size thing we've wanted to do for at least a decade. TabAtkins: Clever way to get what we want. florian: I think you're slightly overstating lack of JS support, but I agree with the argument Rossen: It's a cool proposal. I'm in favor. Other opinions? dauwhe: I'll try and contact Prince about this dauwhe: They're a PDF formatter that uses @page and supports JS Rossen: Should we wait? dauwhe: No, go ahead Rossen: Thanks for the reach out florian: Since this is new aliasing should we be explicit about how it can be used? fantasai: It's defined at parse time and you never see the other name. florian: Of CSS file? AmeliaBR: Does become a question. If you use cssom method to pass a string that's parsed that is also parse time. Need defined somewhere. Need to define it somewhere for explaining relationship of MS prefixed force-colors vs new force-color florian: We have general aliasing, but this alias is weird TabAtkins: Normal is shorthanding based. Property then does show up in all contexts. This would be not that. Does need clarification. Happy to work to see exactly what to clarify. emilio: If can put width and height in @page this would be quirky because size means one thing in @page emilio: Can set width and height in @page rule. Means size does something different in @page then everywhere else. TabAtkins: That's why we can't overlap. Because size is not a shorthand in @page fantasai: Confusion from naming property anything other than 'size' is higher then size in @page not being width and height florian: Dev tools should be warning about this. If page-width exists and you try and use size you should be warned. TabAtkins: I don't think any browser respects @page size declaration florian: Chrome does TabAtkins: Okay. Cool. I think spec should clarify that it's page-size and it's required to do this parsing. And I'll file a bug on our dev tools that we should have a maybe use something else Rossen: Proposal: Add size as a shorthand for width and height for everywhere by @page? fantasai: Several things. 1) We are redefining the size property in @page to be called page-size. Rossen: Let's resolve there first fantasai: Also defining that size in the page context parses into page-size fantasai: Once that's resolved, then the size property is a shorthand for width and height Rossen: Objections to these three steps? RESOLVED: We are redefining the size property in @page to be called page-size. Also defining that size in the page context parses into page-size. The size property is a shorthand for width and height <AmeliaBR> (To clarify my earlier comment, the similarity to forced color was that any rule inside the `@media (-ms-high-contrast)` would include an implicit `forced-color-adjust: none` declaration added at parse time. But doesn't look like that got included in the spec, it was just a suggestion of how MS could handle internally.) CSS Text ======== Need additional value of word-break for Korean ---------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4285 florian: Reminding people: Korean traditionally written like Japanese without spaces. Now use spaces, but line-breaking has not changed where you can break like Japanese florian: Some typographers agree in many contexts it's nice to line-break Korean like English. Not everyone agrees with that. Discussion in GH shows that. florian: We need another value because the existing 'keep-all' only works if you can lang-tag. Do we care about allowing this behavior for Korean that can't be language tagged? I think we do. florian: If you're writing Korean in a text editor or from a database where you don't have language tags it's tricky to tag on the fly. Amount of magic you have to do is really obnoxious. florian: Either we say when editing this behavior is impossible or we say for the Korean alphabet you get the normal or we add keep-all-hangul myles: Putting Hangul in the value doesn't make sense when you use lang tag florian: But you can't put lang on contentEditable section because you don't know what will go in there. If they do a mix of languages you can't language tag. Adding spans on the fly depending on what user types is performance-wise terrible. myles: Seems wrong level of abstraction. Wish it could be generalized. Worried eventually have 100 different lang specific values. florian: Possibly. It's really that there are two normal behaviors so normal can't do the right thing. We need two normals. I don't think there are that many languages that need two normals AmeliaBR: That's my concern too. Before settling on language specific keyword do more research to see if more languages have this issue. How much input have you had from general i18n experts beyond Korean use case florian: Have not heard of any language. People who would probably know have been involved fantasai: I think if there were other languages they would need a separate keyword. It's separating Hangul from Chinese and Japanese. Most other writing systems don't mix in the name way and not that many that break everywhere like this. I'm not aware of any others that alternate in the same way as Korean jensimmons: I like what florian is proposing. I understand concern on break from purity, but I feel like one thing web didn't do well was support international languages. This is a way web can keep up with evolving graphic design changes. Feels like a way to make sure web supports a culture and its ability to evolve instead of saying it's complicated and we don't know where it's going to go chris: Good idea as long as clearly defined what this value does when don't meet Korean text. I think it's a thing we need. If web started in Korea we would have had this from the start florian: If you're not in Hangul you do the same as keep-all tantek: I want to re-raise something from AmeliaBR. AmeliaBR asked how much input we had from general i18n experts. I want to raise that and propose before we resolve we file and issue on i18n discuss ( https://github.com/w3c/i18n-discuss/issues ) to get input from broader experts. tantek: florian saying you haven't heard of other languages isn't quite sufficient florian: Reaching out to i18n, yes. But to have a modern language that has the exact same behavior so we can name the keyword something else we need a language who by defaults breaks between every language and want to move away from that and there aren't that many. tantek: I'm saying it shouldn't be dependent on just your expertise. You may be correct, but worth getting that group to take a look. myles: Wanted to ask if any thought given on how to impl? Like are there line breaking libraries that impl this behavior? florian: This would need to be impl in ICU. ICU seems amenable to this but if we expand ICU would have to expand as well. Rossen: I hear requests to get more from i18n. florian are you okay to do that this week? To get traction or a checkmark to say it's good? florian: Yes, I can look into this Rossen: That's it for today, have a great rest of your week.