15:57:01 RRSAgent has joined #css 15:57:01 logging to https://www.w3.org/2020/09/16-css-irc 15:57:04 RRSAgent, make logs Public 15:57:05 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:57:11 present+ 15:59:07 dholbert has joined #css 15:59:25 vmpstr has joined #css 15:59:28 futhark has joined #css 15:59:32 chris has joined #css 15:59:39 present+ 15:59:47 ScribeNick: dael 15:59:52 present+ 16:00:12 present+ 16:00:14 present+ 16:00:17 present+ 16:00:23 present+ 16:00:36 present+ 16:00:38 Present+ antonp 16:00:43 Guest60 has joined #css 16:00:46 present+ 16:00:51 present+ 16:00:58 Rossen_: We're going to start in another couple of minutes 16:01:14 present+ 16:01:16 present+ 16:01:17 present+ 16:01:17 present+ 16:01:35 masonfreed has joined #css 16:01:43 myles has joined #css 16:01:53 GameMaker has joined #css 16:01:56 present+ 16:01:59 alisonmaher has joined #css 16:02:00 present+ 16:02:08 present+ 16:02:31 Rossen_: It's a couple past the hour 16:02:31 present+ 16:02:37 Rossen_: Let's get going 16:02:56 Rossen_: First, sorry I made a typo in the subject line. The call is indeed today. 16:03:08 Rossen_: I must have looked at the MathML call. That is happening tomorrow 16:03:15 present+ myles 16:03:21 Rossen_: As a reminder part 2 is happening tomorrow starting at 9:15PT 16:03:35 Rossen_: Details are sent by astearns to the private list 16:03:38 present+ 16:03:49 present+ 16:03:53 present- 16:04:07 present+ 16:04:11 Rossen_: Extra agenda items. One we'll take when we get going but I wanted to hear if there are any other items to discuss before we get going 16:04:20 fantasai: Process 2020 is in effect now 16:04:32 Rossen_: Woo! Congratulations, I know this was a big effort 16:04:38 bikeshed already supports it 16:04:46 If anyone's not up to date, change section here: https://www.w3.org/2020/Process-20200915/#changes-2019 16:04:53 Rossen_: Huge thank you to you and florian from this form for supporting it 16:05:12 Topic: Upcoming Joint Meetings 16:05:29 Rossen_: If this was a normal time we'd be meeting together for TPAC F2F. That's virtual. 16:05:43 Rossen_: As part of this we reached out to some of the more frequent joint meeting WGs. 16:05:45 Process 2020 for spec editors: https://lists.w3.org/Archives/Public/spec-prod/2020JulSep/0027.html 16:05:47 drousso has joined #css 16:06:03 Rossen_: So far we have joint meeting with i18n group and APA/A11y group 16:06:20 Rossen_: One more proposed by gregwhitworth is if interest to have OpenUI. gregwhitworth can you brief us? 16:06:34 present+ 16:06:57 gregwhitworth: It's a community group. Most things on the list we could do in CSSWG. Goal is we keep talking about form controls and styling and things that the group is talking about in a holistic view. 16:07:26 present+ 16:07:35 +1 16:07:37 gregwhitworth: I provided items to see if there was interest. Wanted to know if there was interest in getting together to talk about form control styling, possible improvements to built in controls with OpenUI and CSSWG 16:07:39 Rossen_: Thoughts? 16:07:50 +1 to meet with OpenUI 16:07:53 +1 16:07:59 gregwhitworth: Seeing stuff on IRC 16:08:13 present+ 16:08:14 Rossen_: That's what I was expecting for interest 16:08:19 +1 16:08:21 xiaochengh has joined #css 16:08:26 +1 16:08:37 smfr has joined #css 16:08:42 Rossen_: Let's call this one that we'll have a joint meeting. You astearns and I will work out details offline 16:08:47 present+ 16:08:54 Topic: [css-logical] Mapping of logical values in 'resize' 16:08:59 github: https://github.com/w3c/csswg-drafts/issues/3281 16:09:46 oriol: The thing is that as css logical spec added logical values for existing properties. For each question of if they should resolve using writing mode of element or its containing block 16:10:13 oriol: Some past resolutions on this. text-align we resolved we should use writing mode of element. Float and clear which effect element we use writing mode of containing block. 16:10:19 oriol: Question is on resize property 16:10:28 oriol: Impl don't agree with this. 16:10:48 oriol: FF doesn't obey previous resolutions. For float, clear, and resize they use writing mode of element. 16:10:55 oriol: They shipped 16:11:11 oriol: In Chromium I used containing block for these three properties but it's behind a flag 16:11:39 oriol: In issue fantasai provided some points to consider. resizing can effect size of box but also available space for contents. You can see it both ways and it's not clear which we pick 16:11:46 oriol: No strong opinion, just want to decide on something 16:12:04 bkardell_ has joined #css 16:12:15 Rossen_: Don't know if folks have read through 3 points from fantasai. Wanted to hear if there are strong opinions 16:12:23 florian: Weak opinion to favor element 16:12:24 TabAtkins: same 16:12:32 smfr: Any version where those are physical? 16:12:44 florian: Yeah, you can. Quesiton is when you say inline. 16:12:51 Rossen_: Also more inclined to element 16:13:03 present+ 16:13:03 Rossen_: Anyone who prefers to have inline refer to containing block? 16:13:39 Rossen_: Some of fantasai points are that layout and resize of element usually effect containing block and might make sense to have this as function of containing block. That's why other option is considered 16:13:48 I think I have a mild preference to containing block. 16:14:00 Use cases are things like sidebars and textarea 16:14:13 Rossen_: Still hear if we resize based on element's inline for same purpose I think that although this is layout effecting it makes sense to be element itself 16:14:28 smfr: Logical versions of overflow-x and -y? I can't find it. 16:14:31 florian: I think so. 16:14:39 https://www.w3.org/TR/css-overflow-3/#logical 16:14:40 q+ 16:14:40 smfr: Was thinking resize should match overflow. 16:14:54 oriol: Overflow uses element writing mode 16:14:55 AmeliaBR has joined #css 16:15:02 smfr: Argument for resize to do same 16:15:08 ack emilio 16:15:55 emilio: Did we decide...for float and clear computed value needs to be logical. What FF impl is these logical properties where logical value is computed to phsyical at computed time which doesn't work for containing block. Where we use writing mode of containing block computed value needs to be logical value 16:16:05 fantasai: Yeah. Value is always itself and never computes phsyical 16:16:18 emilio: Makes sense. Could effect inheritence 16:16:35 Rossen_: Obj to have the logical value of resize that of the element itself? 16:16:41 RESOLVED: have the logical value of resize that of the element itself 16:16:44 s/inheritance/inheritance, but most of these don't inherit/ 16:16:55 Topic: [css-text] Reconsider the resolution on #855 16:17:01 emilio: Logical values computing as-is was resolved in https://github.com/w3c/csswg-drafts/issues/2821#issuecomment-415092595 16:17:03 github: https://github.com/w3c/csswg-drafts/issues/5410 16:17:04 bradk has joined #css 16:17:20 oriol: great, just wanted to make sure that there was a resolution on that, thanks! 16:17:39 oriol: a bit odd that it behaves differently from logical props but maybe not too much :) 16:17:42 present+ 16:17:54 emilio, it would have been necessary for text-align to actually work as expected :) 16:17:55 florian: We resolved control characters are displayed visually. As part of that the CR character, carrage return, is supposed to be the same. Most of the time you can't notice b/c handled by HTML parser. But if you inject it you should see it. No one does it. 16:18:10 fantasai: fair enough :) 16:18:39 florian: Mostly can't see, Chrome sometimes replaces with ordinary space. Did testing to see what kind of invisible people do. It's all over the place. Everyone does a weird varient 16:19:19 florian: Suggestion is treat as ordinary space. Depending on whitespace property it may be collapsable. Partially matches Chrome. When whitespace is normal Chrome does that. When whitespace is not normal Chrome does different things. 16:19:33 florian: Suggestion is from fantasai and I think it's good. This is kind of an error case 16:19:47 emilio: filed it b/c wikipedia was complaining. Not sure about nobody uses it 16:19:54 florian: Do they want it to do something? 16:20:16 emilio: No, Gecko was doing something more weird. I fixed that more weird but when I looked how to handle it was all over the place as you said. 16:20:42 florian: So I think you for the opportunity to write fun tests. Now that I've had my fun how about we change to a space and move on 16:20:49 s/think/thank 16:20:59 emilio: Okay with that but a change for all engines 16:21:07 florian: Yeah. In main case it's what Chrome does 16:21:16 chrishtr: #2 on yoru option list always? 16:21:26 florian: Yes. It behaves as any space on whitespace:pre 16:21:30 bradk has joined #css 16:21:35 chrishtr: So Chrome just needs whitespace:pre to change? 16:21:42 proposed resolution is "treat as U+0020" 16:21:45 florian: Yeah, maybe other non-normal. I don't recall. 16:22:07 smfr: Makes me a little nervious b/c they're more common in mac. 16:22:25 florian: Yeah. Probably not shoing because actual carriage return is handled. It's an explicit escape 16:22:32 smfr: Worried files converted to user entities. 16:22:43 florian: Could. but what happens now is everybody is different 16:23:09 Rossen_: I see soft agreement by koji on issue. Sounds like emilio is fine for Gecko to try. 16:23:29 smfr: I won't object. I think we'd have to try it and see what happens 16:23:50 Rossen_: Let's try and resolve. If we see a lot more information saying this is causing crazy breaks we'll discuss again 16:24:23 florian: I think behavior in safari and FF isn't crazy but i could find so many ways to make something visual that this seemed a lot simpler 16:24:40 florian: Prop: Treat CR as an ordinary space 16:24:47 florian: I'll be more exact in spec 16:24:50 Rossen_: Objections? 16:24:57 RESOLVED: Treat CR as an ordinary space 16:25:06 Topic: Interoperable font metrics 16:25:15 github: https://github.com/w3c/csswg-drafts/issues/4792 16:25:47 myles: There's this problem. Problem is font files have a bunch of different metrics and many conflict. 16:26:09 jfkthame has joined #css 16:26:15 myles: Most egregious is there are 3 different asc and desc metrics in open type font files. All different numbers. Some browsers use some, others use others. 16:26:24 myles: Some use metrics not even in the file. It's the wild west 16:26:38 bradk has joined #css 16:27:05 myles: This is an interesting problem b/c all text is rendered with whatever metrics the browser happens to use. Any solution that's browser Y should switch is a pretty scary change. It changes all text on the web. So I think it's nto a good solution 16:27:50 myles: Looked for better. A few design principles I wanted to abide by. All text should not be changes. Browsers should not have to parse font files themselves, they should be able to delegate to lower level libraries. 16:28:26 myles: Last is that we don't want to have different metrics for some properties than others. If we do that you end up with inconsistent typography and poor design 16:29:21 myles: Given those requirements I think best way to solve is for CSS authors in CSS to override metrics inside font file. The mechanism for doing this is a new descriptor or set of descriptors in font-face block. A css author can override the font file metrics and say please instead use 80%em for asc. 16:29:47 myles: Satisfies constraints and gives consistency if authors use this. And if browser doesn't understand it falls back to font file. 16:30:04 q+ to wonder if Chrome is proposing or arguing against a descriptor 16:30:05 q+ 16:30:11 myles: For problem at hand I think this is a fairly good design. Interested to hear thoughts. 16:30:15 q? 16:30:35 q+ TabAtkins 16:30:42 ack chris 16:30:42 chris, you wanted to wonder if Chrome is proposing or arguing against a descriptor 16:31:13 chris: Reading thread I'm puzzled. I see people from chrome saying they don't want descriptors and existing ones should be removed. See others from chrome proposing descriptors. I appreciate opinions can change but would like to know their current opinion. 16:31:42 ack xiaochengh 16:31:51 xiaochengh: From chrome side we do want descriptors. Earlier comment opposing was mostly from impl side. We've prototyped the descriptors behind a flag so impl isn't an issue. 16:32:11 chris: Does that only apply to these descriptors or also to previous descriptors? 16:32:18 chrishtr: Which did you have in mind? 16:32:48 q+ to talk about descriptors vs properties 16:32:49 chris: Dominic pointed to other issues saying removed font-varient and would like to remove other overrides. Basically, are you now happy with these or still look at removing? 16:33:01 xiaochengh: Others aren't covered, should look independently 16:33:11 q+ 16:33:18 chrishtr: In favor of adding the ones xiaochengh mentioned as well as asc one from myles 16:33:34 q- 16:33:45 ack myles 16:33:45 myles, you wanted to talk about descriptors vs properties 16:34:01 strong +1 to using descriptors, strong -1 to using properties for this 16:34:02 una has joined #css 16:34:04 q- 16:34:09 present+ 16:34:22 myles: Talk directly about descriptor vs property. Descriptors are a direct natural fit to way metrics are handled by browsers. When you use a font face you have a font associated. Way to impl this is when you pull out metrics remove that and slot in from the rule. 16:34:58 I agree that descriptors seem like a good fit here, beter than propoerties as Myles said. I just didn't want a solution tht had been argued against in the past. 16:35:00 agreed, descriptors are a much better fit indeed. 16:35:09 myles: If we wanted to move to property not against but tricky problems like how does font fallback work if you have nested element with different font family. Multiplier on font size? A bunch of questions. If we can answer that's fine but descriptor approach means we don't have to. 16:35:18 chris: Agree they're a better fit 16:35:37 GameMaker has joined #css 16:35:39 q? 16:35:43 q+ 16:36:06 myles: I can also talk about the 2 additional descriptors from xiaochengh. line gap amkes a lot of sense. Advanced override I'm not against but unanswered questions about how interacts with letter-spacing. Letter-spacing is not a simple property. 16:36:39 myles: Would be unfortunate if we had 2 ways of effecting letter-spacing and they worked differently. So there's still some design work for that one. line-gap-override makes sense 16:36:52 futhark has left #css 16:37:18 q+ 16:37:23 TabAtkins: There is 2 separate mechnically things to do that are letter-sapcing like. Advance-override solves making sure monospace isn't screwed up with fallback. You want to effect advance of a letter to make sure they have exact width of primary font. 16:37:33 q+ 16:37:36 ack TabAtkins 16:38:06 TabAtkins: Nothing to do with variable width fonts. That wants to be more like letter-spacing so you don't have awkward spaces. Have to be different and separate. advance-override which is make monospace work with fallback is straightforward 16:38:26 myles: Yeah, proposal from 8 days ago says it adds additional space. I don't think it satisfies the use case 16:38:30 TabAtkins: Would for monospace 16:38:35 myles: Not for font fallback 16:38:56 TabAtkins: Yes, if you know width of primary and fallback you add the space. Using override is unfortunate name 16:39:04 ack xiaochengh 16:39:16 xiaochengh: proposal is add a constant to advance of glyph. I agree we should rename the descriptor. 16:39:41 xiaochengh: At this moment problem with variable width font is value of this descriptor has to be tried manually. Agree there's a design issue but we do want this descriptor 16:39:46 myles: We can open up a few issues 16:40:26 fantasai: I strongly want advance-override to be in a separate issue. Needs to be discussed in more detail. Monospace case also has a bunch of considerations. Not sure why adding a fixed value is right because ratio change.s It's a crude fixup. 16:40:34 Flashback to 1997 - all the widths in a descriptor https://www.w3.org/TR/WD-font-970721#widths :) 16:40:35 +1 to fantasai re:advance-override 16:40:45 +1 16:40:49 fantasai: On main prop for asc and desc it's fine. Had discussed similar for super and subscript metrics 16:40:51 +1 here too 16:41:11 s/change.s/changes depending on the exact font/ 16:41:22 s/ratio/ratio of advance widths for different letters/ 16:41:23 chrishtr: Agree we should split advance-override. I think this is appropriate to 2nd use case from xiaochengh more than the original one brought by myles. Split and continue to discuss 16:41:26 q- 16:41:36 ack florian 16:41:40 ack fantasai 16:41:53 Rossen_: Other comments? If not are we coming to resolution? 16:42:11 fantasai: Prop: add asc and desc and linegap-ooverride as fontface descriptors 16:42:16 myles: and they take %s 16:42:27 Rossen_: Objections? 16:42:35 chrishtr: sgtm 16:42:59 RESOLVED: Add ascent, descent, and lanegap override as fontface descriptors that take % 16:43:10 s/lanegap/line-gap/ 16:43:13 fantasai: While we're on topic should we add the super and subscript variants 16:43:18 +1 from me on @fantasais additions 16:43:24 chrishtr: Sound interesting, want to look more 16:44:24 fantasai: Briefly, font has metrics on amount to shipt up/down for super/subscript and says what size as function of font size. If font provides a glyph it's supposed to provide ones that match. If you don't have glyph UA can synth by resizing. IN order to get that to match you need metrics and a lot of fonts don't have 16:44:32 chrishtr: Is there difference between OS and browsers? 16:44:40 fantasai: No, font metrics are frequently wrong 16:45:03 chrishtr, see example in https://www.w3.org/TR/css-fonts-4/#font-variant-position-prop 16:45:08 Rossen_: This is very much related but I would prefer we open a new issue where more thought can be given. fantasai can you open that? 16:45:09 fantasai: Yep 16:45:20 Topic: [css-fonts] Proposal to extend CSS font-optical-sizing 16:45:27 github: https://github.com/w3c/csswg-drafts/issues/4430 16:45:52 Rossen_: A rather large issue 16:46:22 myles: This font-optical-sizing property takes 2 values, auto and none 16:46:28 q? 16:47:01 myles: Optical sizing is a way for letters to effect shape of outlines. On large sizes letter shapes are more delicate for visual beauty and when small serifs are elongated. Fonts can morph shape 16:47:24 myles: Impl with a variable feature. Inside the fonts the variable axis is set to the font size. 16:47:47 myles: Webkit sets to css pixel size. I think all browsers do, but not sure. 16:47:56 chris: They do not which is the problem 16:47:57 myles: Okay 16:48:47 myles: Another piece of information is open type spec which defines that axis says that this is supposed to be set to font size in points. Not css points, but points. Relevant to MacOS and iOS. 16:49:21 myles: Actual proposal is to extend syntax to not just be none and auto but add a number that's more expressive so authors can say if they want font size to be css pixels, css points, or something else. 16:49:31 myles: I have opinions but want to let others speak. 16:49:47 GameMaker has joined #css 16:50:17 myles: I guess I can mention why I think it's bad. There is a right answer which is what open type spec says. On MacOS and iOS the OSs have a coordinate system. Designed such that 72 typographic points = 1 physical pixel. 16:50:40 q+ 16:51:03 myles: In webkit we want integral sized pixel blanks on physical pixel boundaries. We have 1 css pixel = 1 typographic point. Gives crisp backgrounds. 1 css inch = 4/3 typographic inches. 16:51:55 myles: Means if you want length supplied in typographic points the way you get that on webkit is you supply css pixels. That's how we've defined it. It's correct though not intuitive. The spec...no reason to increase flexibility because we're doing it correctly. 16:52:46 chris: Backing myles up. He's explained how it comes to correct way. Others have seen that webkit sets in css pixels but don't have the rest so it comes out wrong. It's a problem. Easiest solution is for other browsers to fix it which is as simple has multiplying by 4/3. 16:52:48 ack chris 16:53:20 chris: I think the proposal which is on this thread and on opentype list they assume browsers won't change so they need to fix it in the spec. I would prefer the other browsers did it so they get correct size and then we don't need anything else. 16:53:44 chris: jfkthame did point out the way the others browser do it. I hope he's on. 16:54:35 fantasai: Quesiton. If I write a document in MS word and say font size is 12 pt and have optical sizing enabled, print it. export to HTML. print that. Sizes are 12pt in both cases. Do I get different results? 16:54:52 chris: Interesting. Size in both prints and size on screen. I don't know. 16:54:58 fantasai: Authors would expect to render the same 16:55:01 chris: Yes 16:55:17 fantasai: Can we make sure that happens? I'm confused as to what is happening but I think that should be a constraint. 16:55:32 There is no support in PDF or PostScript for variable fonts. So any optical-sizing axis adjustments are done before the print layer, in the application. 16:56:13 q+ 16:56:14 myles: Relevant piece here is the scale...on MacOS and iOS we have 1 typographic point = 1 css pixel. When you print that may not be true. COuld come out same even if you see on screen different for OS. 16:56:41 fantasai: Suppose I have a doc I'm looking at on screen. Optical sizing axis has significant differences. Will I get different shape text when print? Should I? 16:57:15 myles: You could, yes. CSS units to typographic units is different when printing. Could be because we've picked this scale because of screens. When printing don't have that. 16:57:38 fantasai: Optical sizing is change in glyph shape. What does it have to do with crispness of glyph? 16:59:00 myles: Sorry. We've scaled entire css coordinate system by 1/3. That's b/c in web today authros say 4px for things like border and margins. All over the place. If we made it such that 1 css inch = 1 typo inch the px length would not map to a physical pixel. Solved by scaling hte entire css coordinate system by 1/3 so things lie on pixel boundaries more often. 16:59:04 fantasai: ...okay 16:59:29 chris: True of original mac. Seems like high dpi devices there are more options. I guess these are micro-pixels? 16:59:37 myles: I'd like to not talk retina. 16:59:45 chris: I would because they're relevant 16:59:47 bradk has joined #css 17:00:15 Not every iPhone has a Retina display 17:00:29 myles: There's a 3rd system. There's phsyical if you measure crystal size. Not relevant b/c impacts by manufacturing process. More relevant is typographic b/c that's what OS is designed with. 17:01:07 myles: If I want something 1 inch big on an app I'll use pixels. Assumption is that because OS is designed with a coord system if you make something a certain number of points in the coord system it'll look close on the phsyical screen. 17:01:32 q- 17:01:40 Rossen_: At the hour and need to wrap. We're in the middle of the conversation. I see chris and fantasai on the queue so I encourage them to continue discussing on the issue and we can resume next week. 17:02:57 fantasai: Summary- What i'm saying is on the OS system level in different apps. Non web borwser 1pt = 1px. Within css 1 pt and 1 px and not same. So 1 css pt is different. When you print the points are equat to each other. We have inconsistent matchups. Issue is that WK choose to go along one set of eq. lines and hte people filing the issue picked a different set. 17:03:05 s/saying/understanding/ 17:03:12 Rossen_: Let's resume in issue. myles when you feel it's ready please bring it back 17:03:13 topic: end 17:03:21 Rossen_: Reminder there's a MathML call tomorrow. 17:03:51 MathML is same time +15m, right? 17:04:01 yes 17:04:02 jfkthame has left #css 17:04:44 Probably going to miss it. Interesting topic, but 1:15am isn't all that awesome, especially when it's the 3rd one in the same week 17:04:49 bradk has joined #css 17:18:18 go to bed florian 17:30:57 Karen_ has joined #css 17:54:51 zakim, end meeting 17:54:51 As of this point the attendees have been Rossen_, dael, futhark, oriol, chris, rachelandrew, florian, dholbert, antonp, chrishtr, miriam, faceless, dandclark, gregwhitworth, 17:54:54 ... plinss, GameMaker, alisonmaher, TabAtkins, myles, rego, Guest, jensimmons, emilio, cbiesinger, drousso, smfr, bkardell_, bradk, una 17:54:54 RRSAgent, please draft minutes 17:54:54 I have made the request to generate https://www.w3.org/2020/09/16-css-minutes.html Zakim 17:54:56 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 17:55:00 Zakim has left #css 18:31:40 Karen has joined #css