Zakim, start meeting

present+

present+

ScribeNick: dael

present+

present+

present+

present+

present+

present+

Present+ antonp

present+

present+

Rossen_: We're going to start in another couple of minutes

present+

present+

present+

present+

present+

present+

present+

Rossen_: It's a couple past the hour

present+

Rossen_: Let's get going

Rossen_: First, sorry I made a typo in the subject line. The call is indeed today.

Rossen_: I must have looked at the MathML call. That is happening tomorrow

present+ myles

Rossen_: As a reminder part 2 is happening tomorrow starting at 9:15PT

Rossen_: Details are sent by astearns to the private list

present+

present+

present-

present+

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

fantasai: Process 2020 is in effect now

Rossen_: Woo! Congratulations, I know this was a big effort

bikeshed already supports it

If anyone's not up to date, change section here: w3.org/2020/Process-20200915/#changes-2019

Rossen_: Huge thank you to you and florian from this form for supporting it

Topic: Upcoming Joint Meetings

Rossen_: If this was a normal time we'd be meeting together for TPAC F2F. That's virtual.

Rossen_: As part of this we reached out to some of the more frequent joint meeting WGs.

Process 2020 for spec editors: lists.w3.org/Archives/Public/spec-prod/2020JulSep/0027.html

Rossen_: So far we have joint meeting with i18n group and APA/A11y group

Rossen_: One more proposed by gregwhitworth is if interest to have OpenUI. gregwhitworth can you brief us?

present+

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.

present+

+1

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

Rossen_: Thoughts?

+1 to meet with OpenUI

+1

gregwhitworth: Seeing stuff on IRC

present+

Rossen_: That's what I was expecting for interest

+1

+1

Rossen_: Let's call this one that we'll have a joint meeting. You astearns and I will work out details offline

present+

Topic: [css-logical] Mapping of logical values in 'resize'

github: w3c/csswg-drafts #3281

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

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.

oriol: Question is on resize property

oriol: Impl don't agree with this.

oriol: FF doesn't obey previous resolutions. For float, clear, and resize they use writing mode of element.

oriol: They shipped

oriol: In Chromium I used containing block for these three properties but it's behind a flag

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

oriol: No strong opinion, just want to decide on something

Rossen_: Don't know if folks have read through 3 points from fantasai. Wanted to hear if there are strong opinions

florian: Weak opinion to favor element

TabAtkins: same

smfr: Any version where those are physical?

florian: Yeah, you can. Quesiton is when you say inline.

Rossen_: Also more inclined to element

present+

Rossen_: Anyone who prefers to have inline refer to containing block?

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

I think I have a mild preference to containing block.

Use cases are things like sidebars and textarea

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

smfr: Logical versions of overflow-x and -y? I can't find it.

florian: I think so.

q+

smfr: Was thinking resize should match overflow.

oriol: Overflow uses element writing mode

smfr: Argument for resize to do same

ack emilio

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

fantasai: Yeah. Value is always itself and never computes phsyical

emilio: Makes sense. Could effect inheritence

Rossen_: Obj to have the logical value of resize that of the element itself?

RESOLVED: have the logical value of resize that of the element itself

s/inheritance/inheritance, but most of these don't inherit/

Topic: [css-text] Reconsider the resolution on #855

emilio: Logical values computing as-is was resolved in w3c/csswg-drafts #2821#issuecomment-415092595

github: w3c/csswg-drafts #5410

oriol: great, just wanted to make sure that there was a resolution on that, thanks!

oriol: a bit odd that it behaves differently from logical props but maybe not too much :)

present+

emilio, it would have been necessary for text-align to actually work as expected :)

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.

fantasai: fair enough :)

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

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.

florian: Suggestion is from fantasai and I think it's good. This is kind of an error case

emilio: filed it b/c wikipedia was complaining. Not sure about nobody uses it

florian: Do they want it to do something?

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.

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

s/think/thank

emilio: Okay with that but a change for all engines

florian: Yeah. In main case it's what Chrome does

chrishtr: #2 on yoru option list always?

florian: Yes. It behaves as any space on whitespace:pre

chrishtr: So Chrome just needs whitespace:pre to change?

proposed resolution is "treat as U+0020"

florian: Yeah, maybe other non-normal. I don't recall.

smfr: Makes me a little nervious b/c they're more common in mac.

florian: Yeah. Probably not shoing because actual carriage return is handled. It's an explicit escape

smfr: Worried files converted to user entities.

florian: Could. but what happens now is everybody is different

Rossen_: I see soft agreement by koji on issue. Sounds like emilio is fine for Gecko to try.

smfr: I won't object. I think we'd have to try it and see what happens

Rossen_: Let's try and resolve. If we see a lot more information saying this is causing crazy breaks we'll discuss again

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

florian: Prop: Treat CR as an ordinary space

florian: I'll be more exact in spec

Rossen_: Objections?

RESOLVED: Treat CR as an ordinary space

Topic: Interoperable font metrics

github: w3c/csswg-drafts #4792

myles: There's this problem. Problem is font files have a bunch of different metrics and many conflict.

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.

myles: Some use metrics not even in the file. It's the wild west

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

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.

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

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.

myles: Satisfies constraints and gives consistency if authors use this. And if browser doesn't understand it falls back to font file.

q+ to wonder if Chrome is proposing or arguing against a descriptor

q+

myles: For problem at hand I think this is a fairly good design. Interested to hear thoughts.

q?

q+ TabAtkins

ack chris

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.

ack xiaochengh

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.

chris: Does that only apply to these descriptors or also to previous descriptors?

chrishtr: Which did you have in mind?

q+ to talk about descriptors vs properties

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?

xiaochengh: Others aren't covered, should look independently

q+

chrishtr: In favor of adding the ones xiaochengh mentioned as well as asc one from myles

q-

ack myles

strong +1 to using descriptors, strong -1 to using properties for this

q-

present+

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.

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.

agreed, descriptors are a much better fit indeed.

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.

chris: Agree they're a better fit

q?

q+

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.

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

q+

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.

q+

ack TabAtkins

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

myles: Yeah, proposal from 8 days ago says it adds additional space. I don't think it satisfies the use case

TabAtkins: Would for monospace

myles: Not for font fallback

TabAtkins: Yes, if you know width of primary and fallback you add the space. Using override is unfortunate name

ack xiaochengh

xiaochengh: proposal is add a constant to advance of glyph. I agree we should rename the descriptor.

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

myles: We can open up a few issues

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.

Flashback to 1997 - all the widths in a descriptor w3.org/TR/WD-font-970721#widths :)

+1 to fantasai re:advance-override

+1

fantasai: On main prop for asc and desc it's fine. Had discussed similar for super and subscript metrics

+1 here too

s/change.s/changes depending on the exact font/

s/ratio/ratio of advance widths for different letters/

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

q-

ack florian

ack fantasai

Rossen_: Other comments? If not are we coming to resolution?

fantasai: Prop: add asc and desc and linegap-ooverride as fontface descriptors

myles: and they take %s

Rossen_: Objections?

chrishtr: sgtm

RESOLVED: Add ascent, descent, and lanegap override as fontface descriptors that take %

s/lanegap/line-gap/

fantasai: While we're on topic should we add the super and subscript variants

+1 from me on @fantasais additions

chrishtr: Sound interesting, want to look more

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

chrishtr: Is there difference between OS and browsers?

fantasai: No, font metrics are frequently wrong

chrishtr, see example in w3.org/TR/css-fonts-4/#font-variant-position-prop

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?

fantasai: Yep

Topic: [css-fonts] Proposal to extend CSS font-optical-sizing

github: w3c/csswg-drafts #4430

Rossen_: A rather large issue

myles: This font-optical-sizing property takes 2 values, auto and none

q?

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

myles: Impl with a variable feature. Inside the fonts the variable axis is set to the font size.

myles: Webkit sets to css pixel size. I think all browsers do, but not sure.

chris: They do not which is the problem

myles: Okay

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.

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.

myles: I have opinions but want to let others speak.

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.

q+

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.

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.

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.

ack chris

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.

chris: jfkthame did point out the way the others browser do it. I hope he's on.

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?

chris: Interesting. Size in both prints and size on screen. I don't know.

fantasai: Authors would expect to render the same

chris: Yes

fantasai: Can we make sure that happens? I'm confused as to what is happening but I think that should be a constraint.

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.

q+

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.

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?

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.

fantasai: Optical sizing is change in glyph shape. What does it have to do with crispness of glyph?

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.

fantasai: ...okay

chris: True of original mac. Seems like high dpi devices there are more options. I guess these are micro-pixels?

myles: I'd like to not talk retina.

chris: I would because they're relevant

Not every iPhone has a Retina display

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.

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.

q-

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.

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.

s/saying/understanding/

Rossen_: Let's resume in issue. myles when you feel it's ready please bring it back

topic: end

Rossen_: Reminder there's a MathML call tomorrow.

MathML is same time +15m, right?

yes

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

go to bed florian

zakim, end meeting