IRC log of css on 2020-09-16

Timestamps are in UTC.

15:57:01 [RRSAgent]
RRSAgent has joined #css
15:57:01 [RRSAgent]
logging to https://www.w3.org/2020/09/16-css-irc
15:57:04 [Zakim]
RRSAgent, make logs Public
15:57:05 [Zakim]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:57:11 [Rossen_]
present+
15:59:07 [dholbert]
dholbert has joined #css
15:59:25 [vmpstr]
vmpstr has joined #css
15:59:28 [futhark]
futhark has joined #css
15:59:32 [chris]
chris has joined #css
15:59:39 [dael]
present+
15:59:47 [dael]
ScribeNick: dael
15:59:52 [futhark]
present+
16:00:12 [oriol]
present+
16:00:14 [chris]
present+
16:00:17 [rachelandrew]
present+
16:00:23 [florian]
present+
16:00:36 [dholbert]
present+
16:00:38 [antonp]
Present+ antonp
16:00:43 [Guest60]
Guest60 has joined #css
16:00:46 [chrishtr]
present+
16:00:51 [miriam]
present+
16:00:58 [dael]
Rossen_: We're going to start in another couple of minutes
16:01:14 [faceless2]
present+
16:01:16 [dandclark]
present+
16:01:17 [gregwhitworth]
present+
16:01:17 [plinss]
present+
16:01:35 [masonfreed]
masonfreed has joined #css
16:01:43 [myles]
myles has joined #css
16:01:53 [GameMaker]
GameMaker has joined #css
16:01:56 [chrishtr]
present+
16:01:59 [alisonmaher]
alisonmaher has joined #css
16:02:00 [GameMaker]
present+
16:02:08 [alisonmaher]
present+
16:02:31 [dael]
Rossen_: It's a couple past the hour
16:02:31 [TabAtkins]
present+
16:02:37 [dael]
Rossen_: Let's get going
16:02:56 [dael]
Rossen_: First, sorry I made a typo in the subject line. The call is indeed today.
16:03:08 [dael]
Rossen_: I must have looked at the MathML call. That is happening tomorrow
16:03:15 [myles]
present+ myles
16:03:21 [dael]
Rossen_: As a reminder part 2 is happening tomorrow starting at 9:15PT
16:03:35 [dael]
Rossen_: Details are sent by astearns to the private list
16:03:38 [rego]
present+
16:03:49 [Guest60]
present+
16:03:53 [Guest60]
present-
16:04:07 [jensimmons]
present+
16:04:11 [dael]
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 [dael]
fantasai: Process 2020 is in effect now
16:04:32 [dael]
Rossen_: Woo! Congratulations, I know this was a big effort
16:04:38 [chris]
bikeshed already supports it
16:04:46 [florian]
If anyone's not up to date, change section here: https://www.w3.org/2020/Process-20200915/#changes-2019
16:04:53 [dael]
Rossen_: Huge thank you to you and florian from this form for supporting it
16:05:12 [dael]
Topic: Upcoming Joint Meetings
16:05:29 [dael]
Rossen_: If this was a normal time we'd be meeting together for TPAC F2F. That's virtual.
16:05:43 [dael]
Rossen_: As part of this we reached out to some of the more frequent joint meeting WGs.
16:05:45 [fantasai]
Process 2020 for spec editors: https://lists.w3.org/Archives/Public/spec-prod/2020JulSep/0027.html
16:05:47 [drousso]
drousso has joined #css
16:06:03 [dael]
Rossen_: So far we have joint meeting with i18n group and APA/A11y group
16:06:20 [dael]
Rossen_: One more proposed by gregwhitworth is if interest to have OpenUI. gregwhitworth can you brief us?
16:06:34 [emilio]
present+
16:06:57 [dael]
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 [cbiesinger]
present+
16:07:35 [TabAtkins]
+1
16:07:37 [dael]
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 [dael]
Rossen_: Thoughts?
16:07:50 [astearns]
+1 to meet with OpenUI
16:07:53 [miriam]
+1
16:07:59 [dael]
gregwhitworth: Seeing stuff on IRC
16:08:13 [drousso]
present+
16:08:14 [dael]
Rossen_: That's what I was expecting for interest
16:08:19 [jensimmons]
+1
16:08:21 [xiaochengh]
xiaochengh has joined #css
16:08:26 [dandclark]
+1
16:08:37 [smfr]
smfr has joined #css
16:08:42 [dael]
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 [smfr]
present+
16:08:54 [dael]
Topic: [css-logical] Mapping of logical values in 'resize'
16:08:59 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3281
16:09:46 [dael]
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 [dael]
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 [dael]
oriol: Question is on resize property
16:10:28 [dael]
oriol: Impl don't agree with this.
16:10:48 [dael]
oriol: FF doesn't obey previous resolutions. For float, clear, and resize they use writing mode of element.
16:10:55 [dael]
oriol: They shipped
16:11:11 [dael]
oriol: In Chromium I used containing block for these three properties but it's behind a flag
16:11:39 [dael]
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 [dael]
oriol: No strong opinion, just want to decide on something
16:12:04 [bkardell_]
bkardell_ has joined #css
16:12:15 [dael]
Rossen_: Don't know if folks have read through 3 points from fantasai. Wanted to hear if there are strong opinions
16:12:23 [dael]
florian: Weak opinion to favor element
16:12:24 [dael]
TabAtkins: same
16:12:32 [dael]
smfr: Any version where those are physical?
16:12:44 [dael]
florian: Yeah, you can. Quesiton is when you say inline.
16:12:51 [dael]
Rossen_: Also more inclined to element
16:13:03 [bkardell_]
present+
16:13:03 [dael]
Rossen_: Anyone who prefers to have inline refer to containing block?
16:13:39 [dael]
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 [fantasai]
I think I have a mild preference to containing block.
16:14:00 [fantasai]
Use cases are things like sidebars and textarea
16:14:13 [dael]
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 [dael]
smfr: Logical versions of overflow-x and -y? I can't find it.
16:14:31 [dael]
florian: I think so.
16:14:39 [fantasai]
https://www.w3.org/TR/css-overflow-3/#logical
16:14:40 [emilio]
q+
16:14:40 [dael]
smfr: Was thinking resize should match overflow.
16:14:54 [dael]
oriol: Overflow uses element writing mode
16:14:55 [AmeliaBR]
AmeliaBR has joined #css
16:15:02 [dael]
smfr: Argument for resize to do same
16:15:08 [Rossen_]
ack emilio
16:15:55 [dael]
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 [dael]
fantasai: Yeah. Value is always itself and never computes phsyical
16:16:18 [dael]
emilio: Makes sense. Could effect inheritence
16:16:35 [dael]
Rossen_: Obj to have the logical value of resize that of the element itself?
16:16:41 [dael]
RESOLVED: have the logical value of resize that of the element itself
16:16:44 [fantasai]
s/inheritance/inheritance, but most of these don't inherit/
16:16:55 [dael]
Topic: [css-text] Reconsider the resolution on #855
16:17:01 [oriol]
emilio: Logical values computing as-is was resolved in https://github.com/w3c/csswg-drafts/issues/2821#issuecomment-415092595
16:17:03 [dael]
github: https://github.com/w3c/csswg-drafts/issues/5410
16:17:04 [bradk]
bradk has joined #css
16:17:20 [emilio]
oriol: great, just wanted to make sure that there was a resolution on that, thanks!
16:17:39 [emilio]
oriol: a bit odd that it behaves differently from logical props but maybe not too much :)
16:17:42 [bradk]
present+
16:17:54 [fantasai]
emilio, it would have been necessary for text-align to actually work as expected :)
16:17:55 [dael]
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 [emilio]
fantasai: fair enough :)
16:18:39 [dael]
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 [dael]
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 [dael]
florian: Suggestion is from fantasai and I think it's good. This is kind of an error case
16:19:47 [dael]
emilio: filed it b/c wikipedia was complaining. Not sure about nobody uses it
16:19:54 [dael]
florian: Do they want it to do something?
16:20:16 [dael]
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 [dael]
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 [dael]
s/think/thank
16:20:59 [dael]
emilio: Okay with that but a change for all engines
16:21:07 [dael]
florian: Yeah. In main case it's what Chrome does
16:21:16 [dael]
chrishtr: #2 on yoru option list always?
16:21:26 [dael]
florian: Yes. It behaves as any space on whitespace:pre
16:21:30 [bradk]
bradk has joined #css
16:21:35 [dael]
chrishtr: So Chrome just needs whitespace:pre to change?
16:21:42 [fantasai]
proposed resolution is "treat as U+0020"
16:21:45 [dael]
florian: Yeah, maybe other non-normal. I don't recall.
16:22:07 [dael]
smfr: Makes me a little nervious b/c they're more common in mac.
16:22:25 [dael]
florian: Yeah. Probably not shoing because actual carriage return is handled. It's an explicit escape
16:22:32 [dael]
smfr: Worried files converted to user entities.
16:22:43 [dael]
florian: Could. but what happens now is everybody is different
16:23:09 [dael]
Rossen_: I see soft agreement by koji on issue. Sounds like emilio is fine for Gecko to try.
16:23:29 [dael]
smfr: I won't object. I think we'd have to try it and see what happens
16:23:50 [dael]
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 [dael]
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 [dael]
florian: Prop: Treat CR as an ordinary space
16:24:47 [dael]
florian: I'll be more exact in spec
16:24:50 [dael]
Rossen_: Objections?
16:24:57 [dael]
RESOLVED: Treat CR as an ordinary space
16:25:06 [dael]
Topic: Interoperable font metrics
16:25:15 [dael]
github: https://github.com/w3c/csswg-drafts/issues/4792
16:25:47 [dael]
myles: There's this problem. Problem is font files have a bunch of different metrics and many conflict.
16:26:09 [jfkthame]
jfkthame has joined #css
16:26:15 [dael]
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 [dael]
myles: Some use metrics not even in the file. It's the wild west
16:26:38 [bradk]
bradk has joined #css
16:27:05 [dael]
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 [dael]
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 [dael]
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 [dael]
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 [dael]
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 [chris]
q+ to wonder if Chrome is proposing or arguing against a descriptor
16:30:05 [xiaochengh]
q+
16:30:11 [dael]
myles: For problem at hand I think this is a fairly good design. Interested to hear thoughts.
16:30:15 [Rossen_]
q?
16:30:35 [Rossen_]
q+ TabAtkins
16:30:42 [Rossen_]
ack chris
16:30:42 [Zakim]
chris, you wanted to wonder if Chrome is proposing or arguing against a descriptor
16:31:13 [dael]
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 [Rossen_]
ack xiaochengh
16:31:51 [dael]
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 [dael]
chris: Does that only apply to these descriptors or also to previous descriptors?
16:32:18 [dael]
chrishtr: Which did you have in mind?
16:32:48 [myles]
q+ to talk about descriptors vs properties
16:32:49 [dael]
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 [dael]
xiaochengh: Others aren't covered, should look independently
16:33:11 [faceless2]
q+
16:33:18 [dael]
chrishtr: In favor of adding the ones xiaochengh mentioned as well as asc one from myles
16:33:34 [TabAtkins]
q-
16:33:45 [Rossen_]
ack myles
16:33:45 [Zakim]
myles, you wanted to talk about descriptors vs properties
16:34:01 [fantasai]
strong +1 to using descriptors, strong -1 to using properties for this
16:34:02 [una]
una has joined #css
16:34:04 [faceless2]
q-
16:34:09 [una]
present+
16:34:22 [dael]
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 [chris]
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 [florian]
agreed, descriptors are a much better fit indeed.
16:35:09 [dael]
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 [dael]
chris: Agree they're a better fit
16:35:37 [GameMaker]
GameMaker has joined #css
16:35:39 [Rossen_]
q?
16:35:43 [TabAtkins]
q+
16:36:06 [dael]
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 [dael]
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]
futhark has left #css
16:37:18 [xiaochengh]
q+
16:37:23 [dael]
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 [florian]
q+
16:37:36 [Rossen_]
ack TabAtkins
16:38:06 [dael]
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 [dael]
myles: Yeah, proposal from 8 days ago says it adds additional space. I don't think it satisfies the use case
16:38:30 [dael]
TabAtkins: Would for monospace
16:38:35 [dael]
myles: Not for font fallback
16:38:56 [dael]
TabAtkins: Yes, if you know width of primary and fallback you add the space. Using override is unfortunate name
16:39:04 [Rossen_]
ack xiaochengh
16:39:16 [dael]
xiaochengh: proposal is add a constant to advance of glyph. I agree we should rename the descriptor.
16:39:41 [dael]
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 [dael]
myles: We can open up a few issues
16:40:26 [dael]
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 [chris]
Flashback to 1997 - all the widths in a descriptor https://www.w3.org/TR/WD-font-970721#widths :)
16:40:35 [myles]
+1 to fantasai re:advance-override
16:40:45 [florian]
+1
16:40:49 [dael]
fantasai: On main prop for asc and desc it's fine. Had discussed similar for super and subscript metrics
16:40:51 [jfkthame]
+1 here too
16:41:11 [fantasai]
s/change.s/changes depending on the exact font/
16:41:22 [fantasai]
s/ratio/ratio of advance widths for different letters/
16:41:23 [dael]
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 [florian]
q-
16:41:36 [Rossen_]
ack florian
16:41:40 [Rossen_]
ack fantasai
16:41:53 [dael]
Rossen_: Other comments? If not are we coming to resolution?
16:42:11 [dael]
fantasai: Prop: add asc and desc and linegap-ooverride as fontface descriptors
16:42:16 [dael]
myles: and they take %s
16:42:27 [dael]
Rossen_: Objections?
16:42:35 [dael]
chrishtr: sgtm
16:42:59 [dael]
RESOLVED: Add ascent, descent, and lanegap override as fontface descriptors that take %
16:43:10 [fantasai]
s/lanegap/line-gap/
16:43:13 [dael]
fantasai: While we're on topic should we add the super and subscript variants
16:43:18 [faceless2]
+1 from me on @fantasais additions
16:43:24 [dael]
chrishtr: Sound interesting, want to look more
16:44:24 [dael]
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 [dael]
chrishtr: Is there difference between OS and browsers?
16:44:40 [dael]
fantasai: No, font metrics are frequently wrong
16:45:03 [fantasai]
chrishtr, see example in https://www.w3.org/TR/css-fonts-4/#font-variant-position-prop
16:45:08 [dael]
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 [dael]
fantasai: Yep
16:45:20 [dael]
Topic: [css-fonts] Proposal to extend CSS font-optical-sizing
16:45:27 [dael]
github: https://github.com/w3c/csswg-drafts/issues/4430
16:45:52 [dael]
Rossen_: A rather large issue
16:46:22 [dael]
myles: This font-optical-sizing property takes 2 values, auto and none
16:46:28 [Rossen_]
q?
16:47:01 [dael]
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 [dael]
myles: Impl with a variable feature. Inside the fonts the variable axis is set to the font size.
16:47:47 [dael]
myles: Webkit sets to css pixel size. I think all browsers do, but not sure.
16:47:56 [dael]
chris: They do not which is the problem
16:47:57 [dael]
myles: Okay
16:48:47 [dael]
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 [dael]
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 [dael]
myles: I have opinions but want to let others speak.
16:49:47 [GameMaker]
GameMaker has joined #css
16:50:17 [dael]
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 [chris]
q+
16:51:03 [dael]
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 [dael]
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 [dael]
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 [Rossen_]
ack chris
16:53:20 [dael]
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 [dael]
chris: jfkthame did point out the way the others browser do it. I hope he's on.
16:54:35 [dael]
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 [dael]
chris: Interesting. Size in both prints and size on screen. I don't know.
16:54:58 [dael]
fantasai: Authors would expect to render the same
16:55:01 [dael]
chris: Yes
16:55:17 [dael]
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 [faceless2]
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 [chris]
q+
16:56:14 [dael]
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 [dael]
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 [dael]
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 [dael]
fantasai: Optical sizing is change in glyph shape. What does it have to do with crispness of glyph?
16:59:00 [dael]
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 [dael]
fantasai: ...okay
16:59:29 [dael]
chris: True of original mac. Seems like high dpi devices there are more options. I guess these are micro-pixels?
16:59:37 [dael]
myles: I'd like to not talk retina.
16:59:45 [dael]
chris: I would because they're relevant
16:59:47 [bradk]
bradk has joined #css
17:00:15 [bradk]
Not every iPhone has a Retina display
17:00:29 [dael]
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 [dael]
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 [chris]
q-
17:01:40 [dael]
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 [dael]
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 [fantasai]
s/saying/understanding/
17:03:12 [dael]
Rossen_: Let's resume in issue. myles when you feel it's ready please bring it back
17:03:13 [dael]
topic: end
17:03:21 [dael]
Rossen_: Reminder there's a MathML call tomorrow.
17:03:51 [florian]
MathML is same time +15m, right?
17:04:01 [bkardell_]
yes
17:04:02 [jfkthame]
jfkthame has left #css
17:04:44 [florian]
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]
bradk has joined #css
17:18:18 [TabAtkins]
go to bed florian
17:30:57 [Karen_]
Karen_ has joined #css
17:54:51 [astearns]
zakim, end meeting
17:54:51 [Zakim]
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 [Zakim]
... plinss, GameMaker, alisonmaher, TabAtkins, myles, rego, Guest, jensimmons, emilio, cbiesinger, drousso, smfr, bkardell_, bradk, una
17:54:54 [Zakim]
RRSAgent, please draft minutes
17:54:54 [RRSAgent]
I have made the request to generate https://www.w3.org/2020/09/16-css-minutes.html Zakim
17:54:56 [Zakim]
I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye
17:55:00 [Zakim]
Zakim has left #css
18:31:40 [Karen]
Karen has joined #css