- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 16 May 2020 06:41:10 -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.
=========================================
CSS Align 3
-----------
- There are two potential solutions to issue #4957:
1) Abspos descendants are shifted by content alignment, so they
maintain the same positioning relative to the alignment
subject.
2) Abspos resolves its insets against the scrollable area,
unmodified by the content-alignment properties.
- The test case to understand the current behavior (option 2 above)
is http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8069
[note: scrolling/scrollbars aren't part of this discussion,
just the initial view; there's lots of bugs on scrolling]
- More thought needs to be done on what the expected behavior is for
this case so discussion will continue on github.
- dbaron will review the open issues with baseline alignment to see
if it's possible to keep baseline alignment in level 3 (Issue
#4660: Punt baseline-alignment to level 4). Since flexbox refers
to baseline alignment it's preferable to leave it in level 3
with undefined sections if that doesn't create future problems.
- There's no use case listed in issue #4545 (Apply align-content to
replaced elements) so a request for use cases will be added to
the issue in order to determine if it's something worth putting
effort into specifying.
CSS Fonts
---------
- Everyone agreed that "Rounded" was a good candidate for a generic
font family (Issue #4605). However, given the conversations
prior about deciding if there's a purpose for generic font
families or if they're too prone to becoming a fingerprinting
vector (see April 29 Part II), the group will hold on agreeing
to add a new generic font family until they've decided the
future of local font families.
- RESOLVED: The first available font is the first available in the
font-family list whose unicode-range includes the space
character (Issue #4796: Reconsider the definition of
"first available font")
- RESOLVED: Issue #3691 (Suggest allowing a list of font-family
values in @font-face) is easy syntactic sugar, but we don't see
evidence of a need for it, so closing as no change.
CSS Font Loading
-----------------
- RESOLVED: Publish Updated WD of css-font-loading-3
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-four-time-slot-3b
Present:
Rossen Atanassov, Microsoft
Tab Atkins, Google
David Baron, Mozilla
Amelia Bellamy-Royds, Invited Expert
Mike Bremford, BFO
Oriol Brufau, Igalia
Tantek Çelik, Mozilla
Emilio Cobos, Mozilla
Dave Cramer, Hachette Livre
Elika J. Etemad, Invited Expert
Simon Fraser, Apple
Javier Fernandez, Igalia
Chris Harrelson, Google
Daniel Holbert, Mozilla
Dael Jackson, Invited Expert
Brain Kardell, JS Foundation
Jonathan Kew
Ian Kilpatrick, Google
Chris Lilley, W3C
Peter Linss, Invited Expert
Myles Maxfield, Apple
Theresa O'Connor, Apple
Xidorn Quan, Mozilla
Florian Rivoal, Invited Expert
Devin Rousso, Apple
Jen Simmons, Mozilla
Alan Stearns, Adobe
Lea Verou, Invited Expert
Scribe: dael
CSS Align 3
===========
Abspos in an end-aligned scroll container?
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4957
TabAtkins: While fantasai and I were doing the position re-write we
found an inconsistency
TabAtkins: 2 ways to resolve
TabAtkins: When you do align-content: end, it aligns end of content
with end of container. If container is scrollable don't
don't want to do that, because can't scroll to the
overflow (which is now on the start side of the
container). Instead, we adjust scroll position for same
visual effect.
TabAtkins: If you flip overflow from auto to visible you should have
content looking the same.
TabAtkins: However abspos position themselves in a way that doesn't
work well. If you say top:0 it's positioned against top
edge of scrollable area. If you set align-content: end to
start at bottom of scroll abspos is out of view. If you
turn overflow back to visible abspos is now attached to
top and in view. Different results.
TabAtkins: Two ways to deal.
TabAtkins: 1) say that's fine and overflow is slightly different
positioning model. I think I prefer this.
TabAtkins: 2) We do adjust how abspos is positioned when it's
non-start alignment so abspos containing block is moved
in the scroll container to allow to sit in same spot
wrt content as when not scrollable
TabAtkins: Requires some fixup but not too complicated. Another
thing in there. Not sure authors expect. When they say
abspos 'top:0' they expect top.
<fantasai> https://www.w3.org/TR/2020/WD-css-align-3-20200421/#overflow-scroll-position
<fantasai> whiteboard:
https://www.w3.org/TR/2020/WD-css-align-3-20200421/images/scroll-align-padding.jpg
<fantasai> ^ is what happens with in-flow content
<fantasai> Now we're talking about interaction with abspos
Rossen: Inner border box edge?
TabAtkins: Scollable area edge when scrollable.
Rossen: Top and left logical establish origin and you don't go past
that
TabAtkins: Yes
<dbaron> I think I understand the question here, and I don't yet
have an opinion on which behavior seems better -- and given
that I think it's preferable to go with the simpler one as
Tab suggested. But it's possible thinking about it more
would make me have a different intuition for what "should"
happen.
fantasai: One key point is the origin of the scrollable overflow
area is not necessarily the initial scroll position.
Initial scroll position can depend on alignment. Separate
concepts.
Rossen: I'm unclear in your definition when they expect it to be
aligned to top important to define what top means. If we
allow abspos elements to redefine scrollable area as they
extend past the origin in the negative before the start than
your statement is circular
TabAtkins: We're saying the opposite
TabAtkins: In the thread there's 100px high scroll container and
abspos with top:0 inset. 200px of content. If you set
align-content: end, scroll container starts at bottom.
TabAtkins: Right now abspos still connected to top of area so it's
not visible. Attached to 0 position.
TabAtkins: That means difference in render for visible and
scrollable overflow. We try and avoid that with normal
content.
TabAtkins: Is that okay? For abspos position to jump depending on if
visible or scrollable?
TabAtkins: That vs where authors expect abspos to be. Does it push
down to always be visible?
iank: Concerned if this flipped on overflow status because webdev
will change that to disable scroll for example. A bit
concerning.
TabAtkins: Not sure which you argue for in that case
Rossen: My expectation is the behavior would be closer to how we
handle static in-flow layout. Favor stable rather than
jumping with the overflow toggle
TabAtkins: You prefer we redefine abspos position to rely on
alignment. So top:0 within align:end would be visible
within the original scroll position
iank: No, the other one.
TabAtkins: It maintains stable position relative to static content
but visually jumps based on if you flip overflow on/off
iank: Yes. It's not jumping, just that the initial scroll position
is set differently.
TabAtkins: It's jumping visually. align-content:end and you have the
abspos top:0 Either top of container or top of scrollable
area. align-content:end top of the scrollable is above
TabAtkins: Glad the answer wasn't obvious
<fantasai> testcase -
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8069
fantasai: I made a test case if you want to load the testcase and see
fantasai: [shares testcase]
fantasai: Blue double border is abspos and aqua box is in-flow.
First two examples is typical flexbox where both origin
and scroll are top left
fantasai: In first example, same code as second, but it's not a
scroll container. First has visible overflow, is all.
fantasai: First and second have same layout inside the container.
fantasai: First is abspos and an item and you can see they align.
fantasai: Second is overflow auto. In otherwords we clip. Layout is
same.
fantasai: Third we have the flex-flow changed to be reversed in both
axes so it overflows to top and the left. abspos doesn't
care about flex-flow, stays to top left of block.
iank: There's something slightly different in [missed]
fantasai: This is about expectations
fantasai: Rendering for first 3 is correct.
iank: No vertical scroll in 2nd?
fantasai: This is just layout and position. There's lots of bugs
about scrollers. Let's not pay attention to them.
fantasai: I can switch to overflow: hidden if you prefer.
fantasai: 4th example is same code as 3rd but we applied hidden or
auto. Ends up clipping around the behavior.
fantasai: Question from TabAtkins is- is this what we should see or
something different? Important to see aqua box is top and
left in 3. We defined alignment to allow people to align
to bottom. Don't want clip so you can't scroll to them.
Goal of def is you should be able to scroll to upwards and
leftwards to see content.
fantasai: Description in spec to say you do the alignment... instead
of align to bottom left you keep everything and change
initial scroll position
fantasai: Scroller in 4th should be able to scroll to the left and
up. Question we have is for an abspos element depending on
how we describe it: do we want to have it layout so that
when you're in its initial scroll position it's in its
described position? Or describe it so when you scroll to
origin you get the describe position?
iank: Clarification: How you're calculating the layout overflow...
If you've got a scrollable overflow container. Calc layout
overflow from right to left. Starts on right. But initial
position is still 0.
iank: With align-content:end are you assuming layout overflow calc
starts from bottom or start at top and scroll to bottom?
fantasai: That's what we're trying to figure out
Rossen: Mental model when I implemented containing box edges defined
by inner border box. That inner border box defines origin.
You may or may not allow scrolling into the negative for
purpose of accommodating alignment. Third case here
illustrates using alignment you may create situations where
overflow has to allow scroll to negative
Rossen: Origin is always well defined and not redefined. Position
always in respect to that box.
Rossen: That makes both the layouts stable because adding or
removing scrollbars doesn't change position of abspos
elements. Always everyone has expected top/left is in
respect to border box
Rossen: Otherwise a little unstable
fantasai: 2 renderings we're looking at for last case is what you're
seeing in FF where you can scroll to see everything. One
possibility is you see this initially and scroll in both
directions
Rossen: That's overflow not positioning
fantasai: Other is the same rendering as the second case but initial
scroll position is to bottom right. See bottom right
corner but can scroll to everything.
iank: Maybe different way to do align-content:end. Maybe in 3rd the
aqua box should overlap and then when container is big enough
the aqua box sticks
fantasai: Distinction between safe and unsafe. You can request
overflow to always bottom but that's not the default.
Rossen: We've been at this for 25 minutes. I think we have 2
choices. We can contain working on the issue or make a
resolution here
fantasai: I'm not sure. I can see that it's a nice invariant to be
able to flip overflow on and off and have thing you see
the same. I can also see authors surprised if they
position top-left and it's not there, it's in the middle
of the scrollable content.
Rossen: How I'm reading conversation is top left is defined by
origin established by inner border box of containing block.
If it's overflow and has scrollbars in that case there might
be additional mechanism that require scrollers to enable
going negative but that's separate. Shouldn't redefine size
for overflow
TabAtkins: No one has mentioned scrolling negative
Rossen: With the aqua box aligned bottom and right, it's overflowing
to the negative of the origin of the dark containing block.
Do we agree? Overflow is the negative in the inline and block
TabAtkins: Aqua is inflow box? If that's unscrollable that's blink
bug
Rossen: Do we agree here aqua overflows in negative?
TabAtkins: Nothing in spec makes it go negative
fantasai: I think Rossen is talking about negative in respect of top
and left of border box of scroll container. You're talking
negative coordinates of scrollable area, which makes it
unscrollable
fantasai: We all agree aqua box extends out to left and top of
container just like ex 3. Impl not considering that as
scrollable and that's a bug.
iank: One thing good to clarify is...when blink does reverse we
treat similar to a [missed] container so overflow starts in
top right. reverse we start from bottom
iank: That will influence decision
dholbert: We intend to be same in Firefox
iank: For row:reverse and column?
dholbert: Yeah
iank: The question is how do you want align-content to work. Start
overflow from bottom and right and scroll position in initial
or you start top left and scroll position is at end. That
influences this decision
Rossen: We're getting into the weeds. I suggest we continue in the
issue and bring back for resolution
Rossen: 2 clear choices that were well articulated. I'd encourage
you to continue discussion there.
TabAtkins: Last bit. Because one behavior falls out if we don't
resolve on anything we're in effect choosing one.
fantasai: Showing this whiteboard (
https://www.w3.org/TR/2020/WD-css-align-3-20200421/images/scroll-align-padding.jpg
)
that's around concept in spec. Wanted to make sure we
didn't mix up scroll to bottom of scrollable vs making
extra space you need.
Punt baseline-alignment to level 4
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4660
fantasai: We can punt. We had resolved to push baseline alignment
out to L4. Looked into it and I think it's awkward and
confusing.
fantasai: Baseline keyword is part of initial flexbox keywords.
Implemented across all browsers. Pushing I think is
confusing to authors
fantasai: A little uncomfortable with that resolution. I don't think
we're that far from fixing remaining baseline issues. If
we started from scratch sure, but since it's been in
flexbox from the beginning hesitant to pull it out.
Rossen: Opinions? Concerns?
<astearns> would prefer to keep it in level 3
fantasai: Main concern is there's some issues with definition of
intrinsic sizing and sizing algorithms interacting with
baseline alignment. Not sure how to deal. Not clear errors
in spec. That's main thing we're stuck on.
Rossen: I know of some issues that will be... or dependencies from
grid. What other sizing algorithms affected?
fantasai: Flex, grid, and tables
fantasai: Not aware of significant concerns from implementors about
implementability. That's the one thing we're stuck on.
Everything else is fixable soonish so we can take whole L3
to CR
fantasai: Just my thoughts. That's why I haven't edited it in
dbaron: Alternatives in space of keeping baseline alignment in but
saying x is undefined
fantasai: Not sure what should be undefined.
dbaron: I'd need to dig in more.
dbaron: Issue 1409 is about how baseline alignment changes intrinsic
sizes. Example might be spec saying that it's undefined.
Need to dig more to see if it makes sense
fantasai: Would you be willing to take a look into what it would be
acceptable for spec to say?
dbaron: I can look
Rossen: So we hold on pushing to L4 until then?
fantasai: Yes, goal is dbaron to come back to something and we take
it to CR
ACTION: dbaron take a look at baseline alignment and how to keep it
in L3 by undefining things
Apply align-content to replaced elements
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4545
TabAtkins: Mats wants the content alignment property to apply to
replaced elements. It adds magical padding. Replaced
elements can have padding on them. Easy theoretical model
there's nothing wrong with having content alignment work.
TabAtkins: Seems fine to me. We hadn't thought of it. Similar to
object fit and position, but separable because this
adjusts outside content box
TabAtkins: I'm fine adding this in. Want to make sure; check
temperature of group
fantasai: Size of replaced element when not stretched?
fantasai: In order to align something within something need size of
container and thing being aligned. Know container. Size of
thing being aligned what's the size?
TabAtkins: intrinsic of content
fantasai: Is that useful? What does it mean if something w/o
intrinsic size
TabAtkins: Stuff w/o intrinsic doesn't work. How useful, I don't
know. Works in the model
<tantek> does this actually enable any new use-cases that aren't
already solved by object-fit etc.?
fantasai: It's possible, but I don't know if it's useful. If not
useful why do we spend time to define and test and
implement. What new use cases does this enable? Gotta do
something or not worth effort.
<tantek> right if it's not useful (new use-cases, or great
simplification of existing use-cases), we should not do it
TabAtkins: Unless anyone has ideas perhaps push back until we get a
use case. Looking over issue from Mats there isn't one
<tantek> I'd leave the issue open to allow gathering of new use-cases
<tantek> or ways to simplify existing use-cases. I trust mats had
something in mind
jensimmons: Wondering what reason was to file issue
dholbert: Might be easier to have it work than add an exception
Rossen: If we don't know the reasoning it's a fair ask to go back
and see what he replies with.
Rossen: If it's pure theory it's one thing but if there's actual use
cases... grid is a common layout that's being used more and
more with replaced content for various image and media
presentation. Ideally he'll have an example
Rossen: Let's continue in the issue.
CSS Fonts
=========
Proposal for a new generic font family "Rounded"
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4605
Rossen: myles can you summarize?
myles: Sure.
myles: We got a bunch of font families, add a new one.
myles: 2 reasons in the issue. First, we have ui-rounded already.
Makes sense to add rounded font family
myles: 2nd argument is it's common typographic style in Japan. If
we've got serif/sans serif for the west this makes sense in
Japanese context
myles: Backing up to talk about what rounded is.
myles: It's a typographic style where terminals of letters are
circular
<fantasai> http://www.identifont.com/similar?MZ
<TabAtkins> Note particularly
https://github.com/w3c/csswg-drafts/issues/4605#issuecomment-619318179
which talks about "rounded" having a simple consistent
definition, and which is used as a typographic style
across many languages.
florian: ui-rounded not particularly Japanese, right?
myles: Correct
florian: My feeling is this interacts a bit with a thing the spec
says is possible, but not done, which is map generic font
families to a set of fonts
florian: If you say rounded I would expect it in Japanese and Latin
fonts, but what I think would happen is one or the other
myles: Not sure I agree. ui-rounded is a UI style font. I don't
think type of fonts here are for UI, but for other purposes
fantasai: I think separately florian wants 'rounded' to reliably
give rounded font, whether glyphs needed are Latin or
Japanese, not give rounded for one and fall back to e.g.
serif for the other.
Rossen: I want to channel a question on the issue, do we expect
different fonts between rounded and ui-rounded. I'm aware of
some fonts for windows cjk that are way optimized for small
and thinner to allow better fit for overall UI that's closer
between different scripts. That's where ui-rounded and
rounded will map differently.
TabAtkins: Last week talked about larger issue about generics.
TabAtkins: Rounded satisfies any reasonable constraints for
generics. Sounds reasonable to me
myles: One proposed criteria was 2 major OSs have built in rounded
fonts. Is that true?
AmeliaBR: I think at least arial rounded is on Windows. Might be MS
office pack.
Rossen: I'm not sure off the top of my head. Could get back to you.
florian: I think this is a good idea. Support it. Might be a generic
font family that's meaningful across multiple scripts.
That's why I raised point that spec says you can map to
sets of fonts. In this case you should. Spec I'm fine,
hoping people will do what spec allows
<fantasai> +1 to florian
myles: I understand your point now
fantasai: I support what florian said
jfkthame: I just checked windows standard list and there's nothing
rounded there. I guess that must come from office.
myles: Are installations of office common enough that it should be
considered built in?
florian: Yes
Rossen: No comment
myles: Serious about the requirement, though. I think it's legit
that 2 OSs should have it built in.
fantasai: Clarify to say not necessarily built in, but a common
config of OS
myles: Yes
florian: If you buy a computer and it's on it it counts
fantasai: Windows with MS Office installed is very common.
Installations will vary by region and language also
Rossen: From PoV of addition to generic fonts I'm hearing this makes
sense. Some questions about how this will be impl and actual
behavior. Not sure we need to define this now.
Rossen: Question here is does new generic rounded make sense to add
myles: If it can't be demonstrated there are 2 common config with
rounded fonts I think I would object
<dbaron> My Windows 10 system does not have a font called "Arial
Rounded", if that's what I'm supposed to be looking for...
<Rossen> Arial Rounded is certainly part of Office fonts
<TabAtkins> https://docs.microsoft.com/en-us/typography/font-list/arial-rounded-mt
Confirmation that Arial Rounded is shipped with Office
jfkthame: Hesitant adding any generic while we're hesitant what
generic fonts are for.
AmeliaBR: Agree with that. Whatever we think about rounded it's
worth first discussing syntax and general overall design
goals with CSS and what generic keywords mean
AmeliaBR: No pressing demand to add right now so let's take time and
do right
jensimmons: Web front end dev use generics constantly, usually as a
fallback font. Try and use something tightly controlled
but generics are used as fallbacks constantly
<TabAtkins> +1 to Jen
<jensimmons> if "rounded" starts to mean something (if) — Authors
will use it, gladly
<fantasai> https://github.com/w3c/csswg-drafts/issues/4605#issuecomment-619318179
fantasai: Draw attention to Kida-san's comment^. They have been
working on i18n and on jltf. Pointing out rounded is more
significant in Japan and East Asia. Need to consider it.
Also unlike other generics rounded is a style that exists
across writing systems so makes sense in that way as well
fantasai: He mentions both macOS and windows have those
florian: You may want to look for maru which is Japanese for rounded
if you're searching for default rounded fonts
fantasai: Fonts in other writing systems it's likely to be much more
common to find rounded. Shouldn't be biased to only
consider if it's common in European installations.
<jensimmons> +1 to that — need for international thinking
Rossen: Are people convinced we should add this or not right now?
florian: I think we should add this, but we haven't decided the
syntax. We might want to wrap a new family in a function so
might want to wait a bit
myles: Rossen is right we don't need to decide on that. We can say
we want a way to trigger a rounded font without deciding
syntax
myles: I'm also willing to accept MS office as a common config so
we've passed the criteria and typographically it's valuable
so I'm on board
fantasai: We draft spec and we mark issue so we can draft it and say
we're not sure if it's compat yet.
jfkthame: If we're going to add a generic based on a font from MS
Office that might be in tension with work going on to
reduce fingerprintability with fonts shipped by system
myles: Two ideas on surface in tension but if goal is putting users
in buckets and making sure none of small all users with MS
Office is a pretty big bucket.
<dbaron> Windows version * office version might be smaller buckets
though
Rossen: We're at time for a break.
fantasai: Should we resolve?
AmeliaBR: On the general concept?
fantasai: Yeah
Rossen: Proposal: Add the ability to have rounded fonts and we
decide on syntax later
fantasai: Placeholder syntax and separate issue
Rossen: Proposal: Add ability to expose and target rounded fonts.
Syntax TBD
dbaron: Little nervous about fingerprinting. May need to consider
versions. Office by version is small buckets and office
version + windows version is small.
myles: Font is only from office it's not a matrix, just office
version
dbaron: Windows version from other things
dbaron: So we expose office version which might be a matrix against
windows version
florian: Broader, though. It's maybe all versions before 2008 vs
after.
Rossen: dbaron enough of a concern to hold off on resolution?
dbaron: Given discussion about font fingerprinting I'd prefer to hold
dbaron: To respond to florian fonts have revisions. They're not
atomic and unchanging. Could have differences across versions
florian: Yes. I would expect larger buckets than each version,
though.
myles: How do we make progress on this?
AmeliaBR: Gets to issue of general purpose of generic fonts and how
to move forward. If we add new generics rounded is
logical. Security concerns are part of discussion about do
we want more generics
Rossen: We're going back into generic fonts topics. I want us to
stop here. It's a fair point dbaron is raising to hold off.
Sympathize with myles to find a way to progress.
Rossen: Let's have additional conversations about if this can be
unwedged by what the font metrics look like and are the
buckets small enough to concern? If not we can resolve later.
Rossen: Outside the fingerprint issue people are fine
Rossen: We won't resolve for now.
<br type=10min>
Reconsider the definition of "first available font"
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4796
AmeliaBR: fantasai's comment is resolution from a couple months ago
was illogical so we should take it from there
fantasai: We rescinded the resolution in the same session because we
said it should be 0.5 em or a glyph, but a font is neither
a length nor a glyph so it makes no sense. I think we start
at the top.
Rossen: What's the proposal?
florian: It's okay if the first available font does not contain all
glyphs. I think ch unit uses 0 glyph, ic uses a particular
character. If the glyphs are missing the units can say I
default to 1em or whatever. But we should still figure out
what the first available font is.
AmeliaBR: So one proposal is the first font in the font stack with
any valid glyphs is your first available font?
myles: That's what we do in WK. The first font is the primary font
and if it doesn't support the characters we'll use another one
florian: Problem in the spec is it says first font if it doesn't
contain space it doesn't count.
florian: One reason is common to put first font and reduce it via
the unicode range. You're just using that font for & or
something and want rest of the stack for the rest.
florian: As jfkthame pointed out it's if the font contains. If the
change to if the unicode range it's webcompat.
dbaron: Suggestion in issue is change it to be if unicode-range
matches the space and then it was added what to fallback to
if there's not a glyph
fantasai: Sounds like it's what we did before is for the value of ch,
and then need to amend the algorithm for first available
font to see if space is in its unicode-range
florian: And for ch unit it already says that. It says in [reads]
florian: Could be interpreted as if not in first available font.
<fantasai> https://www.w3.org/TR/css-values-3/#ch
<fantasai> "In the cases where it is impossible or impractical to
determine the measure of the “0” glyph, it must be
assumed to be 0.5em wide by 1em tall."
<fantasai> "Equal to the used advance measure of the "0" (ZERO,
U+0030) glyph found in the font used to render it."
AmeliaBR: Can someone type up a resolution text for the proposal?
<myles> Proposed Resolution: The first available font is the first
font in the font-family list whose unicode-range supports
the space glyph
<dbaron> I think a more specific proposed resolution is to accept
jfkthame's proposal at the end of
https://github.com/w3c/csswg-drafts/issues/4796#issue-568427691
dbaron: I don't quite understand what happened last time, though we
did retract original resolution in that discussion
florian: Because it made no sense. We said font becomes 0.5em which
makes no sense.
fantasai: I put in chat the text from Values. It says ch is the
advance measure of the 0 in font used to render it. Which
is not same as first available. So that's separate. Need
to resolve what first available font is. If there's an
issue with ch it's separate.
fantasai: We should take proposal from myles and if there's an issue
for definition of ch that's separate issue against values
and units.
AmeliaBR: On proposed resolution do we have concept in spec what
unicode-range means for system and generic
myles: Assumed to have definite range of every unicode-range
character. Spec lists it out.
florian: Another clarification. If the first font in stack doesn't
have space we skip it. If it does do we look if it has the
glyph?
myles: We do not.
Rossen: Thoughts or objections to "The first available font is the
first font in the font-family list whose unicode character
includes the space glyph"
dbaron: There was wording in issue
jfkthame: Should be talking about character not range
RESOLVED: The first available font is the first available in the
font-family list whose unicode-range includes the space
character
Suggest allowing a list of font-family values in @font-face
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3691
faceless2: I couldn't see a reason not to
faceless2: It expands to multiple fontface blocks. Not sold on need
for it, but struck me as a why not. I think Chris is
trying to clear issues.
myles: I think AmeliaBR brought up a problem with it.
TabAtkins: Problem is same as if you do multiple font faces still.
Possibly not what author intends, but well defined what
would happen.
TabAtkins: You can define multiple faces that are identical except
name.
myles: If 2 font face blocks, one with a one with a,b should they be
combined together
TabAtkins: Should be exactly as if a,b was to separate faces
AmeliaBR: One related question is will this only apply to font
family name or other descriptors
faceless2: Only intended name. Easiest to leave at that
AmeliaBR: I think the example of something like a black font which
is sometimes referred to with black or as 900 weight
generic is a good example
AmeliaBR: Question for me if it's sensible syntax
myles: Mike said it's a why not instead of use case. If this is
valuable you would see authors having to duplicate and I
don't see it on the Web.
faceless2: That's there I got to as well
AmeliaBR: Sounds like we lean no change?
faceless2: If there's an argument against change for change sake
that's it. Might be a localization argument to give fonts
Japanese and English name. I'm not qualified for that.
florian: This is just syntactic sugar for repeating
fantasai: So unless we see that happening already, no good reason
to change
florian: Is there a css preprocessor that does it?
faceless2: Not that I know of
Rossen: Then let's hold now and come back if there's use cases
myles: Let's close it.
RESOLVED: Close no change, for lack of compelling need to change.
CSS Font Loading
================
Updated WD of css-font-loading-3
--------------------------------
Rossen: Any reason why not? Outstanding issues that need to be
worked in?
AmeliaBR: If it's just update WD and editor asked for it it's a +1
from me.
Rossen: That's how I read it. The draft has drifted from current ED
AmeliaBR: We've got a list of changes
TabAtkins: Yes, there is still a chunk of open issues but the draft
as stands is worth publishing.
<astearns> font-loading change list is incomplete, yes?
TabAtkins: At minimum the current TR draft has a definition for
promise interface and if nothing else I'd like to remove
that
florian: Also we linked to it from the snapshot b/c progress
RESOLVED: Publish updated WD of css-font-loading-3
Received on Saturday, 16 May 2020 10:41:59 UTC