23:56:24 RRSAgent has joined #css 23:56:24 logging to https://www.w3.org/2018/12/05-css-irc 23:56:26 RRSAgent, make logs public 23:56:26 Zakim has joined #css 23:56:28 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 23:56:28 Date: 05 December 2018 23:56:57 zheng_xu has joined #css 23:59:29 present+ 23:59:34 ScribeNick: dael 23:59:34 present+ 00:00:39 present+ 00:00:51 present+ 00:01:24 present+ 00:01:36 present+ 00:01:45 Rossen: We've only got a few people on the line. We'll give it a few more minutes for people to join 00:01:56 Rossen: Let's say we'll start in 2 minutes 00:02:31 present+ 00:02:51 Rossen: One more minute and we'll go 00:03:32 Rossen: It's 3 minutes past. We'll try to make progress on as many issues as we can 00:03:44 Rossen: As usual, any additional agenda items or changes to make? 00:03:50 present+ 00:03:55 present+ 00:04:01 Topic: Request for a FPWD for CSS Break 00:04:05 dbaron_ has joined #css 00:04:08 myles_ has joined #css 00:04:26 I’ll be in IRC only today 00:04:42 https://drafts.csswg.org/css-break-4/#changes-level-4 00:04:44 Rossen: Fragmentation L4. Only 2 changes from L3- margin break property and the always and all values added 00:04:50 BTW, I was briefly on the teleconference but it was too noisy here for me to hear, so I gave up 00:04:57 Rossen: With that I'll call for opinions or objections 00:05:29 Rossen: Objections to FPWD for CSS Break L4? 00:05:42 RESOLVED: FPWD for CSS Break L4 00:05:56 Topic: Request to publish FXTF specs under csswg 00:06:39 Rossen: We have already recorded resolutions to take over and get this under CSSWG. I wanted to know if anyone had reasons to object to this. 00:06:46 Rossen: If no, we'll resolve on each 00:06:50 Rossen: Filter Effects 00:06:56 +1 to republishing all 00:06:56 Rossen: Obj? 00:07:08 RESOLVED: Publish Filter Effects under CSSWG 00:07:09 ro 00:07:14 Rossen: Web animations L1 00:07:21 RESOLVED: Publish Web Animations under CSSWG 00:07:31 Rossen: Composition and Blending. Objections? 00:07:41 RESOLVED: Publish Composition and Blending under CSSWG 00:07:48 Rossen: Fill and stroke. Objections? 00:07:53 smfr has joined #css 00:07:54 also +1 to republishing everything 00:07:56 RESOLVED: Publish Fill and Stroke under CSSWG 00:08:03 Rossen: Masking. Objections? 00:08:09 RESOLVED: Publish Masking under CSSWG 00:08:16 Rossen: Motion Path. Objections? 00:08:22 RESOLVED: Publish Motion Path under CSSWG 00:08:31 Rossen: Geometry Interfaces. Objections? 00:08:41 RESOLVED: Publish Geometry Interfaces under CSSWG 00:08:53 https://drafts.csswg.org/css-box-3/#margin-trim 00:09:13 fantasai: astearns points out we should point ^ as a WD to get margin trim published 00:09:18 Rossen: WD? 00:09:29 RESOLVED: Republish CSS Box 3 as a WD 00:09:36 Topic: cursive shaping breaks needs better scoping 00:09:44 github: https://github.com/w3c/csswg-drafts/issues/698#issuecomment-437944436 00:09:54 Rossen: Reopened a couple weeks ago. 00:10:50 fantasai: This was an issue where Richard asked us to clarify or change where we have breaks across element boundries or not. I think he was asking for it to not break when there's a border. There's a span mid-word. Current spec requires if you have border, margin, or padding we don't shape across that boundry 00:11:20 fantasai: Richard asked to have that changed. Asked Jonathan for his opinion and that FF does that is a problem. We're keeping current set of rules is that latest on the issue 00:11:40 fantasai: Wanted to ask if there's anyting to add. If not I'll close editorial for clarifications, but no change 00:12:01 Rossen: I support the no change. Change would be nontrivial and i'm not sure how it would impact web compat. 00:12:06 Rossen: Objections? 00:12:15 RESOLVED: Close issue #698 no change 00:12:22 Topic: Clarify what ligatures are optional 00:12:30 github: https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-432774658 00:12:31 s/no change/no shaping across positive margins, borders, pading/ 00:12:57 https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-422075536 00:13:04 fantasai: This one I committed some changes to CSS Text to define what myles_ suggested is correct. myles_ posted ^ 00:13:06 * rlig is required, no other ligatures are required 00:13:25 fantasai: Then text engine heuristics might apply other features 00:13:28 * text engines have heurstics for broken stuff, spec shouldn't override 00:13:43 fantasai: Committed that. 00:13:51 fantasai: There was discussion about needing update to font 00:13:52 https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda 00:13:58 fantasai: Commit for CSS 3 Text ^ 00:13:58 https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-437085666 00:14:32 fantasai: Ccomments about changing fonts to clarify interactions. Wanted WG to discuss. Changes are largely that the section that defines how font features interact. There's a section that says [read] 00:15:05 fantasai: Should say optional ligatures as is in spec. Then clarify that if you set letter spacing later it disables all ligatures, not just common 00:15:33 fantasai: Also a suggestion there should be step 6 that says if the engine does stuff under the hood it might take precedence. 00:15:42 fantasai: I don't know about that, it's beyond my knowledge. 00:15:55 fantasai: Clarification to which ligatures are disabled should go in. 00:16:03 Rossen: What's in the PR of the 6? 00:16:43 fantasai: Changes made to text are committed. Basically clarifies optional ligature. I didn't think that text should spec what that means. 00:17:05 fantasai: Making sure text doesn't conflict with font and says go look for exact details. I think that's correct. 00:17:24 fantasai: [reads commit] 00:17:53 fantasai: I'm guessing no issues with this one. Need to figure out font spec and if there should be a step 6 00:17:54 https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-437085666 00:18:16 fantasai: If you look at ^ there's a list of precedence of parts of CSS that inject font feature settings. 00:18:23 fantasai: Proposal to make changes to that list 00:18:42 fantasai: Wanted to bring that up to see if we should make those changes to font. If so it should be fonts 3 as well as 4 00:18:51 Rossen: 3? Isn't that too late? 00:18:59 fantasai: Clarification to what's happening 00:19:13 Rossen: I know myles_ is reading on IRC. Hoping he'll chime in 00:19:27 Rossen: For CSS Text L3 would any additional changes be required? 00:19:42 Rossen: I know we need to take to font 3 and/or 4. What about Text 3? 00:19:49 fantasai: Nothing more. The commit went in. 00:20:23 Rossen: To close CSS Text discussion, are there any objections to proposed changes in the commit https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda ? 00:20:45 myles_ has joined #css 00:21:03 RESOLVED: Accept changes in https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda 00:21:03 +1 00:21:18 Topic: Publish an updated WD of css-text-3 00:21:26 Rossen: Anything else before we republish? 00:21:29 https://github.com/w3c/csswg-drafts/issues/337#issuecomment-444316214 00:22:16 fantasai: There's another issue florian and I tried to figure out. Ran into a problem with emoji. line break tranformation dependent on east asian width. Emoji are very inconsistent in east Asian width so line break is different depending on emoji. 00:22:44 fantasai: florian figured out unicode we can use. Pushed that in. If people are interested they may want to look more deeply 00:23:01 fantasai: Might want to review, but if people need more time we can give it 00:23:12 Rossen: florian isn't on, but I'm assuming you support his point 00:23:13 fantasai: Yeah 00:23:41 Rossen: I would rather have koji and others look 00:23:44 fantasai: Yeah 00:23:50 Rossen: We can republish again 00:24:14 Rossen: Obj to republish? 00:24:16 RESOLVED: Publish a new WD of CSS Text L3 00:24:36 fantasai: That brings us to all issues closed and waiting for review from commentors 00:24:45 fantasai: I wanted to set a target for transition to CR 00:24:48 Rossen: Awesome 00:25:01 fantasai: When I post that we published, what date should we set as deadline for review? 00:25:41 Rossen: Given holidays are upon us I expect less people will review. What would be normal time frame. I think a couple weeks. Do we have actual target dates that we set before asking for transition? 00:26:03 Rossen: I don't recall us setting a precedent for 2 weeks 00:26:30 fantasai: Usually post an announcement saying we plan on going to CR soon, please send comments. Usually a case of what day do we want to say 00:26:43 Rossen: Last call of this year is likely 19th. Is that a good target? 00:26:51 fantasai: Enough for me, don't know anyone else 00:26:59 Rossen: Let's try. If there's pushback we extend 00:27:22 Rossen: 19th is deadline for additional comments or issues before we transition 00:27:28 fantasai: I'll post an announcement 00:27:42 Topic: The tokenizer input should probably be a stream of scalar values, not codepoints 00:27:48 github: https://github.com/w3c/csswg-drafts/issues/3307 00:28:23 TabAtkins: This is a small change, no change for FF and minor for others. Turns out when I wrote syntax I didn't know scalar vs codepoints distinction 00:29:03 TabAtkins: When I wrote I said codepoints. Every algo produces only scalar except for when you assign a domstring. All other methods like decoding or escaping produce only scalar values. 00:29:27 TabAtkins: Seems like I don't want non-scalar values; would be more consistant to block the codepoints in all places. 00:29:57 TabAtkins: I propose we add a new step to codepoint filtering that says they are replaced and all entry points work on pure scalar 00:30:16 TabAtkins: FF does this already, Chrome does allow surrigate codepoints in because we're suing domstrings 00:30:21 TabAtkins: Simplifies model. 00:30:33 TabAtkins: Yea or Nay, trivial change on my part 00:31:07 Rossen: I'm assuming FF people will be okay. They're mostly out, but I'd be surprised if they oppose. Chrome is in favor. I don't thinkw e have Apple 00:31:14 Rossen: Objections to the proposed change? 00:31:18 +1 00:31:34 RESOLVED: Add the additional codepoint filtering 00:31:46 Topic: Why \"Pseudo-elements cannot be represented by the matches-any pseudo-class\"? 00:31:55 github: https://github.com/w3c/csswg-drafts/issues/2284 00:32:31 fantasai: I wanted to ask if this is something we should try and define or close as no change 00:32:39 TabAtkins: Valid. 00:32:54 TabAtkins: I know that safari allows pseudo elements, but it doesn't make sense and I don't know why 00:32:56 .foo:matches(::before):hover 00:33:02 TabAtkins: This selector ^ bothers me. 00:33:20 TabAtkins: Unclear if it means before when foo is hovered or when foo.before is hovered. 00:33:52 .foo:matches(::before).bar is invalid, then 00:33:58 fantasai: If we're going to define we have to define if a selecotr ends in a pseudo element and has same meaning as if you placed element outside of matches. 00:34:03 .foo:matches(::before, .baz).bar is invalid, too 00:34:15 fantasai: That's invalid, right. 00:34:24 TabAtkins: Reasonable sort of thing to define on 00:34:37 TabAtkins: It's weird and I don't like it, but if it's what we want I'm okay 00:34:43 ericwilligers: What's the need for this? 00:34:51 .foo:matches(::before, ::after) 00:34:53 TabAtkins: Safari does it for selectors like ^ 00:35:20 TabAtkins: You want to assign a style to multiple psuedo elements. Can't do that with matches right now. That's annoying, I agree 00:35:38 TabAtkins: Reasonable thing. Even bikeshed stylesheet would like to do a selector like this. 00:35:44 s/matches/is/ btw ;) 00:36:01 .foo:matches(::before, .bar) 00:36:03 ^ invalid 00:36:07 TabAtkins: Another option is we're more limited and you can put psuedo elements in if they're the only thing in the selector. All options have to be pseudo elements 00:36:12 .foo:matches(::before:hover) is valid 00:36:26 TabAtkins: That would be okay way to deal 00:36:48 .foo:matches(::before):matches(:hover) ? 00:37:02 would be valid by my rule I think 00:37:04 fantasai: Thing that's tricky is different pseudo elements can be followed by different things. No need to make first example invalid b/c each branch is valid. If any branch is invalid whole is invalid. 00:37:21 Pseudo elements seem like they might differ in what is allowed after them 00:37:28 fantasai: More restrictive I'm not sure that gains us a whole lot. You'll still need contextual checking. 00:37:40 s/checking/checking, even if they're all pseudo-elements/ 00:38:04 TabAtkins: ericwilligers we don't support pseudo elements in matches right now, correct? 00:38:06 ericwilligers: Correct 00:38:12 It seems like you might want to ensure that all branches of the :matches end in the same restriction state 00:38:40 TabAtkins: FF or Edge, how does this sound. Should I close no change and Safari violates spec? Or do we want? 00:38:44 dbaron_, I agree with that as a good restriction if we go this way 00:38:50 Rossen: Curious to hear from Safari folks. 00:38:56 Rossen: dbaron_ is on IRC [reads] 00:39:19 (where we need to be conservative about what is the same, e.g. before and after OK but not selection) 00:39:29 :matches(::before, ::spelling-error) would be invalid 00:39:30 TabAtkins: before and after are fine, but before and spelling wouldn't work because allow different things 00:40:13 ericwilligers: Safari uses different selector name. So it doesn't matter too much. 00:40:27 TabAtkins: Not a backwards compat concern. It's what we want to do for the future 00:40:35 TabAtkins: I'm perfectly fine saying close no change 00:40:37 Still have mixed feelings about whether to allow pseudos in v1 00:40:55 TabAtkins: dbaron_ is unsure. We can relax restriction later 00:41:02 (typing on phone, BTW) 00:41:13 Rossen: smfr said Safari folks can't follow because they're in a meeting 00:41:25 Rossen: Objections to resolving no change? 00:41:30 fantasai: I think deferred 00:41:44 fantasai: Close no change means we don't want to accept. We might accept in future 00:42:07 fantasai: I'd prefer...if we're going to consider in the future we leave it open for selectors 5. If it's a baad idea we close no change. 00:42:13 Rossen: Don't disagree 00:42:31 Rossen: objections to defer to L5? 00:42:38 RESOLVED: Defer this issue to L5 00:43:07 Topic: publication 00:43:18 fantasai: We just published. Nothing has changed since then 00:43:28 Rossen: Okay, that'sfine 00:43:31 Topic: Are text decorations visual overflow or layout overflow? 00:43:44 github: https://github.com/w3c/csswg-drafts/issues/3272 00:43:54 Rossen: Raised by myles, fantasai added 00:44:10 fantasai: myles and I agree it should be ink overflow. Wnat to confirm with WG. I think add to L3 and L4 00:44:58 Rossen: Implication is if you're editing and at the end of a scrollable paragraph and what I type in becomes underlined because syntax I won't be able to see that by scrollbar. 00:45:17 fantasai: If you choose and offset that places underline outside of linebox. 00:45:44 fantasai: Underline typicially in linebox and that's within scrollable. You'd have to place the underline below the line height before it disappears 00:45:52 Rossen: Trying to understand if we're okay with that 00:45:59 It might also be fun to define what element they're overflow from. 00:46:08 fantasai: I think it's fine. If you're placing the underline that low you're asking for trouble 00:46:17 But happy with ink overflow, I think 00:46:23 Rossen: [Reads dbaron_ ] 00:46:41 fantasai: Given painted at same layer as text, should overflow from element painting the text 00:46:55 Rossen: Certainly content layer of the scroller...let's see 00:47:05 https://www.w3.org/TR/CSS2/zindex.html#each-box 00:47:19 Rossen: Should be container of element with text. 00:47:49 Rossen: Objections to resolving on definition that text decoration is considered ink overflow and not layout 00:48:03 RESOLVED: text decoration is considered ink overflow and not layout 00:48:24 Topic: font-display says it's valid in @font-feature-values but it isn't an at-rule 00:48:41 Rossen: Do we have people for this? 00:48:56 Rossen: Or defer until myles and chris are around? 00:48:59 TabAtkins: Let's defer 00:49:10 Topic: Should first/last baseline values of `vertical-align` belong to `alignment-baseline` or separate longhand? 00:49:18 github: https://github.com/w3c/csswg-drafts/issues/861 00:49:52 Rossen: fantasai can you summarize? 00:50:29 fantasai: There is a question of if these values should be incorporated into alignment baseline or a sub prop of vertical align. Vertical-align is a shorthand of baseline shift and alignement baseline 00:51:03 fantasai: Adding a switch to say if we care about first or last baseline. Is it a sep prop so it cascades? I'm not sure how to think through this problem 00:51:20 Rossen: Anyone on the call or IRC with an opinion? 00:51:29 Rossen: If not we can defer 00:51:58 github: none 00:52:05 Rossen: Defer to next week 00:52:20 Rossen: 2 issues, seems like 1st we can discuss 00:52:27 Topic: vertically align to nth-child 00:52:35 github: https://github.com/w3c/csswg-drafts/issues/1339 00:52:54 fantasai: Top ask from MathML folks to say this element will proide baseline rather then first or last 00:53:10 s/MathML folks/math on web pages folks/ 00:53:23 fantasai: Similar to first/last switch. It's a prop so element says "I'm providing baseline". Needs a more concrete proposal then what's in issue 00:53:46 Rossen: Okay. If we can't make progress here, not going to be able to do next one either 00:53:49 github: none 00:54:02 Rossen: We can wrap up early unless there's something else we can discuss 00:54:28 fantasai: Trying to think if there's anything to publish. We can do CSS Align- it is only minor change to it. 00:54:36 Topic: CSS Align Publication 00:55:06 Rossen: What's the change? Looking at changes section 00:55:08 https://github.com/w3c/csswg-drafts/commit/52f193c852b19616019df8f30d67cf2d67146a8a#diff-fe8d087fed2ccda3bdf57954b3ac8d75 00:55:12 fantasai: Minor clarifications. Mainly ^ 00:55:23 Rossen: Okay. 00:55:38 Rossen: Objections to publishing CSS Box Align L3 WD? 00:55:48 RESOLVED: Publish CSS Box Align L3 WD 00:55:56 Rossen: Anything else? 00:56:18 astearns: Given we have resolutions for FXTF spec publication and taking them to CSS, should we close FXTF mailing list? 00:56:31 Topic: FXTF logistics 00:56:49 Rossen: Anything remaining between new SVG and CSSWG that needs to be FXTF? 00:57:06 astearns: Only part of charter I'm aware of is working on the bits of SVG that map to our properties 00:57:23 Rossen: Don't nec. need FXTF for that, do we? 00:57:25 astearns: Nope 00:57:41 Rossen: Anyone on the call with a reason to keep FXTF ML going? If no we can reach out to SVG. 00:57:44 [silence] 00:57:55 Rossen: Sounds like no one wants to hold onto it 00:58:04 plinss: Shut down FXTF server too? 00:58:08 Rossen: Yes 00:58:17 plinss: Whoever migrates ping me when you're done 00:58:18 can we keep redirects alive? 00:58:21 Rossen: Okay, sounds good 00:58:24 yes, plinss said that 00:58:27 Rossen: Anything else? 00:58:33 s/that/so/ 00:58:46 yes 00:58:56 Rossen: I'll give us 2 minutes back. Thanks for calling, next week will be a regular call. Thank you 01:02:05 trackbot, end meeting 01:02:05 Zakim, list attendees 01:02:05 As of this point the attendees have been dael, dauwhe, zheng_xu, ericwilligers, Rossen, astearns, fantasai, plinss, TabAtkins 01:02:13 RRSAgent, please draft minutes 01:02:13 I have made the request to generate https://www.w3.org/2018/12/05-css-minutes.html trackbot 01:02:14 RRSAgent, bye 01:02:14 I see no action items