- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Sep 2020 19:26:36 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Upcoming Joint Meetings
-----------------------
- In addition to the planned meetings with the Internationalization
and ACR/Accessibility groups there is a desire to meet with the
Open UI community group. Rossen, gregwhitworth, and astearns
will coordinate on a time.
CSS Logical
-----------
- RESOLVED: Have the logical value of resize be that of the element
itself (Issue #3281: Mapping of logical values in
'resize')
CSS Text
--------
- RESOLVED: Treat CR as an ordinary space (Issue #5410: Reconsider
the resolution on #855)
CSS Fonts
---------
- RESOLVED: Add ascent, descent, and line-gap override as fontface
descriptors that take percentages (Issue #4792:
Interoperable font metrics)
- New issues need to be opened for some of the other descriptors
raised in issue #4792. One would be to further explore the
proposal for advance-override and the other would be to evaluate
handling the superscript and subscript values with a similar
override.
- Before issue #4430 (Proposal to extend CSS font-optical-sizing)
can reach a resolution there needs to be more discussion and
research into how the various pixel and point conversions are
handled when moving between print and digital displays.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0014.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Christian Biesinger
Mike Bremford
Oriol Brufau
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Xiaocheng Hu
Dael Jackson
Brian Kardell
Brad Kemper
Jonathan Kew
Una Kravets
Rune Lillesveen
Chris Lilley
Peter Linss
Alison Maher
Myles Maxfield
Anton Prowse
Manuel Rego Casasnovas
Florian Rivoal
Devin Rousso
Jen Simmons
Miriam Suzanne
Greg Whitworth
Regrets:
Tantek Çelik
Lea Verou
Scribe: dael
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.
Rossen: As a reminder part 2 is happening tomorrow starting at 9:15PT
Rossen: Details are sent by astearns to the private list
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
<florian> If anyone's not up to date, change section here:
https://www.w3.org/2020/Process-20200915/#changes-2019
<gregwhitworth> woohoo - congrats fantasai and florian
Rossen: Woo! Congratulations, I know this was a big effort
<chris> bikeshed already supports it
Rossen: Huge thank you to you and florian from this forum for
supporting it
<fantasai> Process 2020 for spec editors:
https://lists.w3.org/Archives/Public/spec-prod/2020JulSep/0027.html
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.
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
Open UI. gregwhitworth can you brief us?
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.
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
[email with possible topics:
https://lists.w3.org/Archives/Public/www-style/2020Sep/0005.html ]
Rossen: Thoughts?
<TabAtkins> +1
<astearns> +1 to meet with OpenUI
<miriam> +1
<jensimmons> +1
<dandclark> +1
gregwhitworth: Seeing stuff on IRC
Rossen: That's what I was expecting for interest
Rossen: Let's call this one that we'll have a joint meeting. You
astearns and I will work out details offline
CSS Logical
===========
Mapping of logical values in 'resize'
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3281
oriol: The thing is that in CSS logical spec added logical values
for existing properties. For each there's a 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: Implementations don't agree on this.
oriol: Firefox 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. Question is when you say inline.
Rossen: Also more inclined to element
Rossen: Anyone who prefers to have inline refer to containing block?
Rossen: Some of fantasai's 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
<fantasai> I think I have a mild preference to containing block.
<fantasai> 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: Are there logical versions of overflow-x and -y? I can't find
it.
florian: I think so.
<fantasai> https://www.w3.org/TR/css-overflow-3/#logical
smfr: Was thinking resize should match overflow.
oriol: Overflow uses element writing mode
smfr: That's an argument for resize to do same
emilio: Did we decide...for float and clear computed value needs to
be logical. What Firefox impl is these logical properties
where logical value is computed to physical 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 physical
emilio: Makes sense. Could effect inheritance, but most of these
don't inherit
Rossen: Objections to have the logical value of resize that of the
element itself?
RESOLVED: Have the logical value of resize that of the element itself
<oriol> emilio: Logical values computing as-is was resolved in
https://github.com/w3c/csswg-drafts/issues/2821#issuecomment-415092595
<emilio> oriol: great, just wanted to make sure that there was a
resolution on that, thanks!
<emilio> oriol: a bit odd that it behaves differently from logical
props but maybe not too much :)
<fantasai> emilio, it would have been necessary for text-align to
actually work as expected :)
<emilio> fantasai: fair enough :)
CSS Text
========
Reconsider the resolution on #855
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5410
florian: We resolved control characters are displayed visually. As
part of that the CR character, carriage return, is supposed
to be the same. Most of the time you can't notice because
handled by HTML parser. But if you inject it you should see
it. No one does it.
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 variant
florian: Suggestion is treat as ordinary space. Depending on
whitespace property it may be collapsible. 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: I filed it because 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 thank 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
emilio: Okay with that but a change for all engines
florian: Yeah. In main case it's what Chrome does
chrishtr: Is the proposal #2 on your option list always?
florian: Yes. It behaves as any space on whitespace:pre
chrishtr: So Chrome just needs whitespace:pre to change?
florian: Yeah, maybe other non-normal. I don't recall.
<fantasai> proposed resolution is "treat as U+0020"
smfr: Makes me a little nervous because they're more common in mac.
florian: Yeah. Probably not showing 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 the 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 Firefox isn't crazy but I
could find so many ways to make something visual that this
seemed a lot simpler
florian: Proposal: Treat CR as an ordinary space
florian: I'll be more exact in spec.
Rossen: Objections?
RESOLVED: Treat CR as an ordinary space
CSS Fonts
=========
Interoperable font metrics
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/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 ascending and
descending 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 because 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 not 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
ascending.
myles: Satisfies constraints and gives consistency if authors use
this. And if browser doesn't understand it falls back to font
file.
myles: For problem at hand I think this is a fairly good design.
Interested to hear thoughts.
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.
xiaochengh: From Chrome side we do want descriptors. Earlier comment
opposing was mostly from implementation side. We've
prototyped the descriptors behind a flag so
implementation isn't an issue.
chris: Does that only apply to these descriptors or also to previous
descriptors?
chrishtr: Which did you have in mind?
chris: Dominic pointed to other issues saying removed font-variant
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
chrishtr: In favor of adding the ones xiaochengh mentioned as well
as ascent one from myles
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
implement this is when you pull out metrics remove that and
slot in from the rule.
<fantasai> strong +1 to using descriptors, strong -1 to using
properties for this
<chris> I agree that descriptors seem like a good fit here, better
than properties as Myles said. I just didn't want a solution
that had been argued against in the past.
<florian> agreed, descriptors are a much better fit indeed.
myles: If we wanted to move to property not against it 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
myles: I can also talk about the 2 additional descriptors from
xiaochengh. Line-gap-override makes a lot of sense.
Advance-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
TabAtkins: There is 2 separate mechanically things to do that are
letter-spacing 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.
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
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 of advance
widths for different letters changes depending on the
exact font. It's a crude fixup.
<myles> +1 to fantasai re:advance-override
<florian> +1
fantasai: On main proposal for ascent and descent it's fine. Had
discussed similar for super and subscript metrics
<jfkthame> +1 here too
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
Rossen: Other comments? If not are we coming to resolution?
fantasai: Proposal: Add ascent and descent and line-gap-override as
fontface descriptors
myles: and they take percentages
Rossen: Objections?
chrishtr: sgtm
RESOLVED: Add ascent, descent, and line-gap override as fontface
descriptors that take percentages
fantasai: While we're on topic should we add the super and subscript
variants
<faceless2> +1 from me on @fantasai's additions
chrishtr: Sound interesting, want to look more
<myles> fantasai: what about text-decoration-position and
text-decoration-thickness? Those properties accept
from-font, and this would affect that value
fantasai: Briefly, font has metrics on amount to shift 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 synthesize
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
<fantasai> chrishtr, see example in
https://www.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
Proposal to extend CSS font-optical-sizing
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4430
Rossen: A rather large issue
myles: This font-optical-sizing property takes 2 values, auto and
none
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: Implemented 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.
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.
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.
* fantasai wonders if jfkthame is on the call
chris: jfkthame did point out the way the others browser do it. I
hope he's on.
fantasai: Question. 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.
<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.
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 because in web today authors say 4px for things like
border and margins. All over the place. If we made it such
that 1 CSS inch = 1 typographic inch the px length would not
map to a physical pixel. Solved by scaling the 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
<bradk> Not every iPhone has a Retina display
myles: There's a 3rd system. There's physical if you measure crystal
size. Not relevant because impacts by manufacturing process.
More relevant is typographic because 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 coordinate
system if you make something a certain number of points in
the coordinate system it'll look close on the physical screen.
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 understanding is on the OS system level
in different apps. Non web browser 1pt = 1px. Within CSS 1
pt and 1 px and not same. So 1 CSS pt is different. When
you print the points are equivalent to each other. We have
inconsistent matchups. Issue is that WK choose to go along
one set of equivalent lines and the people filing the
issue picked a different set.
Rossen: Let's resume in issue. myles when you feel it's ready please
bring it back
Rossen: Reminder there's a MathML call tomorrow.
Received on Wednesday, 16 September 2020 23:27:21 UTC