23:56:17 RRSAgent has joined #css 23:56:17 logging to https://www.w3.org/2021/03/03-css-irc 23:56:19 RRSAgent, make logs Public 23:56:20 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 23:58:43 present+ 23:58:50 argyle has joined #css 23:59:02 present+ 23:59:11 present+ 23:59:44 aja has joined #css 23:59:56 Morgan has joined #css 00:00:00 jfkthame has joined #css 00:00:23 present+ 00:00:25 present+ 00:00:44 chris has joined #css 00:00:46 heycam has joined #css 00:00:53 ScribeNick: fantasai 00:01:02 dlibby has joined #css 00:01:07 smfr has joined #css 00:01:11 present+ 00:01:13 present+ 00:01:16 alisonmaher has joined #css 00:01:18 xiaochengh has joined #css 00:01:21 present+ 00:01:22 present+ 00:01:25 present+ 00:01:48 present+ 00:01:50 present+ 00:01:53 present+ 00:02:28 sanketj has joined #css 00:02:28 present+ 00:02:35 present+ 00:02:39 present+ 00:02:41 myles has joined #css 00:02:44 present+ myles 00:03:06 present+ 00:03:45 Topic: advance-override details 00:03:49 github: https://github.com/w3c/csswg-drafts/issues/5983 00:05:11 fantasai: We decided we wanted to add an advance-override descriptor to the @font-face rule, but we didnt' define what it actually does other htan to say it takes a percentage that's resovled agains the advance itself 00:05:34 q+ 00:05:37 present+ 00:05:41 fantasai: A couple of points that would need to be resolved: 1. How are we increasing or decreasing the advance width? The size of the glyph in bohth axes together? Just x axis? Space around each glyph? left side? right side, start end, end end? 00:05:59 fantasai: There's been some discussion in the issue about what it should apply to and how it should apply, but no conclusions. 00:06:15 fantasai: I think the first thing we'd have to decide is how we increase the size of the glyphs 00:06:19 fantasai: to do text layout 00:06:32 myles: Shouldn't distort the outlines 00:06:44 ack chris 00:06:50 chris: We're changing the advance, not the bounding box of the glyph. Not changing the outline 00:06:59 chris: just changing the amount you need to move forward 00:07:03 chris: We're changing the advance, not the bounding box of the glyphs, n or teh geometry. We're changing the amount you need to move forward before painting the next glyphs. Changing spacing in the text advance direction 00:07:04 chris: very clearly not changing any glyph geometry 00:07:09 chris: There's also a size override, but there's separate 00:07:13 chris: There is a proposal to have a scale factor, but that's separate 00:08:04 myles: I think that the exact way that space is added, I think that's not a super important decision, so doing whatever makes sense is easiest. For us that would be applying to the right side always 00:08:24 Rossen_: Is that affected by directionality? 00:08:27 myles: No, always on the right side 00:08:30 chris: Why? 00:08:42 myles: it's just easier to implement. Base-level API renders text LTR 00:08:59 chris: So you're saying you do bidi reordering in the backing store and then apply space after that? 00:09:07 q+ 00:09:09 Rossen_: So proposal is to keep it uniform on one side 00:09:38 jfkthame: I would not like to specify that space is only applied on one side 00:09:44 jfkthame: if that's easiest to apply, maybe allow it 00:09:47 jfkthame: but I don't think that's the best behavior 00:09:56 jfkthame: browser should be able to apply equally across both sides of glyph 00:10:01 jfkthame: which is superior 00:10:08 ack jfkthame 00:10:12 ack fantasai 00:10:34 I'm a bit concerned about margins not lining up, with space at the margins 00:11:49 q 00:12:00 chris: could add space not at margins 00:12:18 myles: bleeds into my point. naive implementation is to just multiply the number in the font file 00:12:23 myles: but that applies before shaping 00:12:31 myles: when you apply shaping, have to match what's in the font file. 00:12:40 myles: Correct implementation of this needs to apply this after shaping 00:12:44 myles: which is a more complicated implementation 00:12:51 present+ 00:12:59 myles: doing something like what chris said is not hard, because you're already at the level of knowing that information 00:13:10 Rossen_: So sounds like we're aligning on adding space on both sides? 00:13:17 Rossen_: any other opinions? or resolve? 00:13:40 myles: If you do it on both sides, then alignment won't look good on either side 00:14:26 jfkthame: We're putting the space equally makes for a less-bad result than you will get than if it's all on one side 00:14:36 jfkthame: in practice, I don't think this is a feature that should be used for a large adjustment 00:14:47 jfkthame: it's for fine-tuning the metrics of a fallback font to match another font 00:14:59 jfkthame: so the adjustment is going to be a small fraction of a glyph width. Not too bad. 00:15:08 myles: I suggest leaving it undefined 00:15:11 we should put that wording from jfkthame into the spec - fine adjustments, not major ones. fine tuning 00:15:22 myles: Major point is that it makes text more/less compact 00:15:35 myles: Might be worth getting impl experience 00:15:50 jfkthame: Wrt trimming space at line boundaries, I'd be opposed. 00:15:57 jfkthame: This is effectively about modifying the metrics of the font 00:16:14 jfkthame: if you modify metrics of a glyph, should be everywhere that glyph occurs, not different based on position in the line 00:16:40 ack fantasai 00:18:08 q+ to remind that we're trying to better solve a case where people are *already* doing letter-spacing 00:18:09 AFAIK this feature is NOT about making things look good, it’s merely about reducing layout shift once a font loads 00:18:27 fantasai: Slight tangent, but 00:18:34 fantasai: This feature has a lot of badness to it 00:18:43 fantasai: First, as we've been discussing, it distorts alignment 00:18:53 fantasai: Second, it breaks complex and cursive writing systems 00:19:23 fantasai: Third, because it introduces uneven amounts of spacing between pairs of characters, it distorts the rhythm of the text and hence impacts readability in a negative way 00:19:43 fantasai: None of these problems apply if the font is scaled in both axes instead of adding space between characters 00:19:43 liam has joined #css 00:20:12 fantasai: And I think it would be harmful if we ship this feature without also shipping a scaling-factor descriptor that could be used in any cases where that would be usable in place of advance-override 00:20:21 jfkthame: Strongly agree with that. 00:20:26 q? 00:20:34 ack TabAtkins 00:20:34 TabAtkins, you wanted to remind that we're trying to better solve a case where people are *already* doing letter-spacing 00:20:54 q+ 00:22:17 TabAtkins: Keep in mind, the goal is not to define a new typographic feature for text. It's to replace existing hacks that people use to reduce layout shift when fonts load 00:22:26 TabAtkins: if we can reduce layout shift, even if it looks bad, still successful 00:22:37 TabAtkins: Want it to look good and make it work across writing systems 00:22:47 TabAtkins: but if not ideal, that's fine, because that's not the point 00:23:03 TabAtkins: should be for fonts that not there for very long, will be replaced by the real font later 00:23:17 TabAtkins: Want a solution that works across scripts and works OK, better than current hacks 00:23:27 ack xiaochengh 00:23:33 xiaochengh: Regarding scaling / font-size override 00:23:45 xiaochengh: we have prototyped in Chrome, and found it tricky to nicely specify 00:23:55 xiaochengh: This might affect ascent-override etc. 00:24:11 xiaochengh: they have a %, which font-size do these resolve against? resolve against the font-size property value of the element or used font size? 00:24:16 xiaochengh: Either way going to surprise some users 00:24:35 xiaochengh: since our main focus is to reduce layout shift, wouldn't want to introduce a blocking issue on top of advance override 00:24:52 fantasai: To reply to TAb, I udnerstand this is for reducing layout shift 00:24:56 ack fantasai 00:25:09 fantasai: But there's different way to do that, and I think in many cases scaling outlines without affecting resolution of length units would also have that affect 00:25:22 fantasai: wrt using it as a fallback, what happens if the other font doesn't load 00:25:33 fantasai: This isn't "onlya pplies in a fallback font" 00:25:49 fantasai: People on slow connections, etc are stuck with a font that's not just non-ideal but also has weird spacing 00:26:00 fantasai: And this doesn't work for complex or cursive script as specified today. 00:26:09 fantasai: You can handle those scripts if you scale, not if you intro space. 00:26:32 TabAtkins: if your fallback font plus scaling advance looks terrible, you chose a bad fallback font 00:26:48 TabAtkins: we don't need to protect author from that. They should tweak it to be closer. 00:26:55 TabAtkins: If it is, it's a bad page. 00:26:58 instead of `font-size-override`, suggest something like `glyph-scale-factor`, then it's clearer that it doesn't affect anything else 00:27:19 myles: What is the exist for this discussion? We've talked about several issues here. 00:27:25 s/exist/exit/ 00:27:25 TabAtkins: Trying to figure out how to fix this for awhile 00:27:31 s/exit/exit criteria/ 00:27:35 TabAtkins: keep getting objections that it's not ideal 00:27:43 TabAtkins: but nobody is helping making a better solution 00:27:53 TabAtkins: we did exploration with scaling, it doesn't lookg good 00:28:03 TabAtkins: maybe we need to scale on some scripts 00:28:10 TabAtkins: but essentially just letter-spacing works well 00:28:46 fantasai: letter-spacing applies evenly 00:29:08 fantasai: and if it's supposed to apply for temporary font, should shut off if you're not loading another font and sticking with this one 00:29:21 TabAtkins: but then you have a layout shift 00:29:37 fantasai: If downloading is turned off, then no layout shift 00:29:54 myles: rogue character with accent in the middle of a paragraph causes ... 00:30:24 Rossen_: Proposed path forward... not hearing a clear consensus around a) where the adjustment should take place or b) should we even have that 00:30:35 Rossen_: I think we resolve in backwards order 00:30:45 summary of myles: also useful if you have a fallback used for certain characters, which has an oddly different character size - this lets you adjust the fallback characters to feel better 00:31:21 Rossen_: First question, should we still pursue this? 00:32:09 OK so close this discussin with "needs proposal"? 00:32:44 fantasai: I can live with having this plus a scaling factor, but not having just this one, because if only have a broken option that's not good enough 00:32:54 myles: I think we should have both, changing scaling factor makes a lot of sense 00:33:22 TabAtkins: Not hearing any objections to what we're doing here, other than fantasai's point. 00:33:30 Rossen_: so no objection to continuing on this 00:33:48 Rossen_: So specific proposal here, fantasai mentioned adding scaling factor and then we have to decide where space is added 00:33:57 Rossen_: My proposal is to take back to the issue and iron it out there 00:35:04 ack fantasai 00:36:49 fantasai: suggest to take a resolution on a) adding a scale-factor descriptor that only affects the glyph outline b) add space on both sides, maybe *allow* (MAY) UAs to do one side only if it's an implementation problem c) apply it to all glyphs in all writing systems, d) warn about how that can break things in certain writing systems / if too much space is added 00:37:11 Topic: Consider clarifying Highlight system color, and maybe adding a new system color for control background 00:37:19 github: https://github.com/w3c/csswg-drafts/issues/6008 00:37:59 chris: emilio raised it 00:38:04 chris: I'm reluctant to add a new system color 00:38:25 Topic: Commas in color-mix() 00:38:32 github: https://github.com/w3c/csswg-drafts/issues/6066 00:38:51 leaverou: Since we have rule that ? reptition should use commas but not other things 00:38:59 leaverou: we removed commas from color-mix because not a list 00:39:09 leaverou: but it doesn't read very nicely, and not clear which color the percentage belongs to 00:39:13 leaverou: so thinking to add the colors back 00:39:14 q 00:39:22 leaverou: since we can't keep going back and forth about it, UAs are implementing 00:39:27 leaverou: Wanted to resolve this once and for all 00:39:33 leaverou: I also agree it's more readable with commas 00:39:38 q+ to agree 00:39:38 q+ 00:39:42 leaverou: I think it should have a comma to separate metadata from list of colors 00:39:45 to also agree (we need commas) 00:39:56 leaverou: clarify whether about the first color or the function as a whole 00:40:01 leaverou: Seem to have consensus on adding them back 00:40:08 leaverou: Also, do we still have 'in' for color space? 00:40:19 leaverou: Seems like only have color space in the beginning 00:40:30 ack TabAtkins 00:40:30 TabAtkins, you wanted to agree 00:40:37 TabAtkins: Agree with leaverou 00:40:46 TabAtkins: we're not attached to using commas everywhere like JS is 00:40:51 TabAtkins: only use it in some places 00:40:55 TabAtkins: It works reasonably here 00:40:58 TabAtkins: and helps with readability 00:41:15 TabAtkins: and we should also have the metadata in a single thought at the beginning, separated by comma 00:41:20 TabAtkins: consistent with gradients and shapes 00:41:32 TabAtkins: so +1 to what leaverou suggested 00:41:41 ack una 00:41:42 una: I agree that commas are needed here 00:41:45 una: much like gradients 00:41:57 +1 need commas 00:42:01 una: I also want to add, I don't think we need end keyword if we have this syntax 00:42:04 q+ 00:42:10 una: I think we are reaching consensus in the issue, and +1 to proposal 00:42:14 s/end/in 00:42:18 fwiw, emilio landed on nightly, used commas, & % applied to 2nd color, "in srgb" at start or end. willing to change 00:42:27 leaverou: I would argue for 'in' keyword 00:42:36 ack leaverou 00:42:45 leaverou: it reads better, and also lets us expand the syntax later to add more options 00:42:49 tantek has joined #css 00:43:02 leaverou: So, makes it more readable and makes syntax less ambiguous, so argue to keep it 00:43:11 Rossen_: Seems like we have consensus around adding commas, any objections? 00:43:23 great, emilio already implemented what we are about to resolve <3 00:43:26 RESOLVED: Add back commas 00:43:48 q+ 00:43:50 Rossen_: Next one is do we want to have the 'in' keyword 00:43:58 una: I would like to object to it 00:43:59 ack una 00:44:09 q+ 00:44:10 chris, except for which color the percentage applies to 00:44:17 Also object, we don't use these sorts of intro keywords except absolutely necessary for disambiguation. 00:44:19 una: Reasoning, I don't think it's necessary and we don't have a construct of 'in' elsewhere in CSS, so introduces new concept not seen anywhere else and I don't think it adds clarity 00:44:34 we have 'at' elsewhere 00:44:35 una: Don't want to add new syntax to CSS 00:44:35 Colorspace keywords are plenty clear and won't block our extensibility in the future. 00:44:47 Rossen_: OK, I suggest we open a separate issue for this 00:44:48 astearns, yeah, that's for disambiguation 00:45:02 because there are two positions 00:45:02 ack leaverou 00:45:16 leaverou: Using prepositions for metadata in functions is common in gradients as well, which is where I got the inspiration. But agree with separate issue. 00:45:32 present+ 00:45:39 TabAtkins: I'm happy to argue that gradients are special 00:45:45 Topic: More clarity around the percentage in color-mix() 00:45:56 github: https://github.com/w3c/csswg-drafts/issues/6064 00:46:30 gradients use "to" because it disambiguates whether the gradient comes *from* that direction or goes *to* that direction (and we flipped back and forth during dev, so there's no obvious answer). 00:46:31 miriam: In the middle space, single percentage value, and spec was conflicted on what that refers to 00:46:40 miriam: is it percentage color, or distance to second color 00:46:40 q+ 00:46:44 miriam: or percentage of second color 00:46:49 miriam: spec disagreed with itself 00:46:52 gradients use "at" to separate the from the possibly-preceding {1,2} 00:46:57 miriam: with commas, would be nice to do percentage in either color 00:47:05 note: the spec has since been fixed and does not disagree with itself anymore :) 00:47:10 miriam: so if you put in first color refers to weight of that color, second is weight of second color 00:47:14 q? 00:47:18 q+ 00:47:20 miriam: would have to decide what to do if 2 percentages are specified 00:47:31 miriam: SASS functions confusing as well, never clear to me which the percent refers to 00:47:32 q+ 00:47:44 ack chris 00:47:49 chris: My understanding was % is % of that color, and all examples (there were more examples before) 00:48:05 chris: there was just one sentence that was off, and Adam fixed ti 00:48:20 chris: Seems clear it's a % of that color, not along a blend between the two colors 00:48:32 chris: the color that it's next to 00:48:41 leaverou: mixing paints, makes sense % of first color 00:48:46 chris: ... that's confusign 00:49:15 chris: if % don't add up, scale to add to 100% 00:49:18 chris: does that make sense? 00:49:31 miriam: So % goes with a color between the commas, that makes sense to me 00:49:43 miriam: so % can be applied to either color, and can put it in one or both 00:49:57 leaverou: Should allow for ... 00:50:00 leaverou: and scale accordingly 00:50:07 chris: Have that in HWB, if too high scale it back 00:50:13 ack leaverou 00:50:33 TabAtkins: I think whichever syntax we go with, should be consistent between color-mix() and cross-fade() 00:50:37 +1 00:50:44 TabAtkins: cross-fade() matches up with what miriam suggests 00:50:50 TabAtkins: can add % with any of the images 00:51:01 TabAtkins: whichever one, if omitted, it's just 100% - [sum] 00:51:13 TabAtkins: if don't add up to 100%, we fill in the remainder with a transparent image 00:51:17 ack TabAtkins 00:51:32 TabAtkins: idk if we want to do with colors 00:51:33 prefer a rebalance like HWB 00:51:45 leaverou: 3-way mixes are confusing, too many ways to do it 00:52:05 TabAtkins: I agree with reasoning for not doing 3-color mixes, but adding in transparency doesn't suffer from same confusion issues 00:52:13 TabAtkins: not strong on either, but greater consistency with cross-fade() would be good 00:52:14 q? 00:52:42 chris, note that HWB does *not* rebalance for <100% sum 00:52:59 there it takes the remainder from the pure hue 00:53:19 >100% causing rescaling is uncontroversial and common between all the functions, yes 00:53:28 q+ 00:53:43 Rossen_: Can someone summarize the proposed resolution? 00:54:07 leaverou: Before we summarize, one last point 00:54:11 Proposed new grammar: color-mix(, #{2}), where = && ? 00:54:24 leaverou: if we handle percentages < 100% by mixing with transparent, it has special interpolation handling so [????] 00:54:43 s/[????]/we don't want to do that/ 00:54:50 q+ for the negative percentages 00:54:51 TabAtkins: Ignoring the < 100% sum and take it to the issue, think we can resolve on the rest 00:55:04 `color-mix(in lch red 80%, blue)` also `color-mix(in lch, red, blue 80%)` 00:55:11 `color-mix(in lch, red 80%, blue)` also `color-mix(in lch, red, blue 80%)` 00:55:13 TabAtkins: proposal above 00:55:18 TabAtkins: if above 100%, rescale to add to 100% 00:55:32 if below 100%, figure out in issue 00:55:46 Rossen_: any objections? 00:55:50 RESOLVED: color-mix(, #{2}), where = && ? 00:56:06 Topic: [css-color-5] How should negative percentages behave in color-mix()? 00:56:26 chris: ? who is implementing pointed out that can't do negative percentages 00:56:34 chris: una said why don't we flip it 0-100% 00:56:36 chris: nobody wants this 00:56:38 chris: I can define it 00:56:47 s/flip/clip/ 00:56:47 s/?/Sam Weinig/ 00:56:51 fantasai: Can you make it invalid? 00:57:00 TabAtkins: invalid matches behavior in other mixing functions 00:57:07 TabAtkins: we intend for it to be meaningless, so should be invalid 00:57:17 RESOLVED: negative percentages are invalid in color-mix() 00:57:25 sounds like calc() would get scary? 00:57:44 ack 00:57:47 q? 00:57:55 ack chris 00:57:55 chris, you wanted to discuss the negative percentages 00:58:06 ack lea 00:58:29 Topic: end 00:58:44 Rossen_: OK, end of meeting, we'll take the rest next week 00:58:54 present+ zoe 00:59:03 :) 00:59:27 Zakim, end meeting 00:59:27 As of this point the attendees have been plinss, argyle, Rossen_, miriam, fantasai, Morgan, dlibby, astearns, alisonmaher, chris, smfr, leaverou, heycam, jfkthame, sanketj, TYLin, 00:59:30 ... myles, dholbert, una, TabAtkins, tantek, zoe 00:59:30 RRSAgent, please draft minutes v2 00:59:30 I have made the request to generate https://www.w3.org/2021/03/03-css-minutes.html Zakim 00:59:32 I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye 00:59:36 Zakim has left #css 01:40:06 dauwhe has joined #css 04:03:09 liam_ has joined #css 05:44:10 florian has joined #css 07:32:28 florian has joined #css 07:34:51 florian has joined #css 07:40:59 florian has joined #css