- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 12 May 2020 19:06:21 -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 Grid & CSS Contain
----------------------
- A few items came up when discussing issue #4931 (Clarify that
contain:size affects track sizing) that need to be worked
through on github prior to reaching a resolution.
- Given the discussion before on an @container rule, do we
need to ignore sizing inputs like like grid-template-columns
so that they can be safely altered on a size-contained box?
- Contain spec may need to clarify that children are ignored
(such that intrinsic tracks are not generated even, in grid
layout) when calculating intrinsic sizing contributions, but
are considered (and do therefore generate tracks) when doing
layout within the box.
Generic Font Families
---------------------
- The group reviewed the proposed definition of what criteria must
be met for a generic font family (Issue #4910: Criteria for
generic font families) as well as the broader question of what
purpose are these generic font families serving.
See notes in https://wiki.csswg.org/spec/css-fonts
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-one-time-slot-a
Scribe: myles
CSS Grid
========
Styling of grid gaps and gutters
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2748
fantasai: I don't remember why I put this on the agenda.
Rossen: I don't know.
fantasai: <shakes head>
Rossen: It wasn't that long ago
fantasai: I don't remember this at all
CSS Grid & CSS Contain
======================
Clarify that contain:size affects track sizing
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4931
florian: Mats Palmgren and I were having a long discussion about
what the spec currently means. We are coming down to
agreeing what's desired, but not what the actual words in
the spec say. contain:size says that when you try to figure
out the size of an element or its intrinsic size, you treat
it as if it has no descendants, then you do layout. He was
wondering does this mean, you do track sizing of grid with
or without descendants?
florian: AFAIAC, track sizing for layout, it's not intrinsic sizing.
If you have no children, then you have no implicit tracks,
then you look at explicit tracks, then you know the grid,
and you lay out.
florian: But if there is intrinsic sizing of the tracks, should this
be canceled out?
florian: Earlier, number of tracks is not described as being sizing
florian: The conclusion is that no, you don't create implicit tracks
for the grid, because that would change the size of the
grid. But when you do a layout, you calculate the track
size property. We are now agreeing now. But we are
disagreeing on whether the words in the spec say that.
florian: If your track sizes have a fixed min number of pixels, then
you incorporate it, and do a full layout.
oriol: Currently in chromium, the contents are taken into account.
They are placed in the grid and they can create implicit
tracks.
oriol: This defeats the point of having size containment, since now
the size of the grid container can depend on contents. But
the dependency is not on the size of the contents, but
instead their computed style.
oriol: But instead this would be style containment... but I'm fine
with what florian is proposing.
florian: Size-containment means your own size is unaffected by your
children. Not that your children's sizes are contained.
florian: To achieve that, we need children not to create implicit
tracks.
<AmeliaBR> Size containment is supposed to prevent intrinsic sizing
from affecting parent/siblings. So shouldn't affect
internal grid layout beyond the size of the box.
<fantasai> +1 to AmeliaBR's description
iank: I agree with that model. However, we may want to consider
changing what size containment means, given container queries
we just discussed. Currently, your grid template columns will
affect the inline size of your element. In dbaron's proposal,
if you have a container query and it can affect some subset of
properties, grid-template-columns can't do that with this def.
iank: There are only 2 layout modes that are special here: grid and
multicol.
iank: So we could change size containment to act more like block and
flexbox, and ignore grid-template-columns. This means that
containment queries, if you can style a certain amount of
properties, grid-template can be one of these properties
dbaron: I think we're a few steps away from determining whether this
is a possibility at all. But it sounds reasonable. Not sure
we're ready to make decisions based on it, but also not sure
we want to foreclose it.
iank: I worry if we don't consider this soon, we'll start closing
off opportunities.
iank: This might be a better way to write the spec and avoid this
whole problem.
florian: I think this is compatible with the goals. If we do get the
ability to do container queries, that could make this
restriction worth it. Later, we might also want a stricter
kind of containment, if that's valuable
iank: I would push back against that. Having one grid+multicol ...
people understand what size containment does. It matches that
mental model. I don't think we should add unnecessary
complexity there.
florian: Thinking through this, if you have a grid that is a
block-level child of whatever's around it, it will be sized
with width, and everything is fine. But if its intrinsic
size ... [missed]
AmeliaBR: There seems to be a bit of confusion of whether the issue
is about which properties affect the calculated size that
you're containing to, vs once you've contained that size
which features are you restricting. Do these two
necessarily have to be the same? Are we allowed to look at
the column properties and figure out they determine a
minimum size, and say "okay that's the size we're
containing to we can figure out just by looking properties
on this element, no need to look at children"
AmeliaBR: But then in another case, the column properties might be
auto, or otherwise based on intrinsic size of the child
contents, and so in that case the size that would be
contained would be dependent on other properties on the
element we're containing. When we go to lay out the grid
inside that element, can we still lay out that grid based
on the children and if the results from laying out the
grid is larger than the container size, then we get
scrollbars
florian: The spec say you have to do that. That's what I was trying
to say when I wrote it. Mats disagrees that's what it says.
Perhaps either TabAtkins or I should rewrite it to make
sure it says that. But maybe if container queries happen,
this will need updating
florian: Notice that this is further along on the req track than
grid is, so maybe this text should be done in grid instead.
fantasai: I agree with florian. This is the most straightforward way
to define it.
fantasai: Even if we weren't tracking these specs process-wise. It
could be called out in contain.
florian: There's a note already.
fantasai: Yes. iank's point about wanting grid-template-columns to
be changeable is a good one, but if we're not doing that,
then if the idea that it doesn't create intrinsic tracks
[even during layout] is unworkable--we have to put them
in tracks somehow, we can't put them all on top of each
other just because the container has size containment
florian: There are two phases. 1. size 2. lay out. For the first
phase, pretend it has no children, don't consider implicit
tracks but do consider explicit ones. 2nd phase: Of course
we consider implicit tracks.
fantasai: Proposal: Clarify the contain spec about ignoring children
when doing intrinsic sizing, but don't ignore for layout
<fremy> (+1 to proposal)
fantasai: And open a second issue about whether grid should have
grid-template-columns be ignored for intrinsic sizing, and
put it in the grid spec
iank: It should go in the containment spec. The min- and max-content
size is affected.
florian: For multicol as well?
iank: Potentially. Columns won't affect intrinsic size of multicol.
florian: What if you say columns: 3 300 column-gap: 300, what's the
benefit of [missed]
iank: Inside the container query, you can change the size of the
contents, but you can't change the number of children
iank: This is a strictly better if we get container queries. Now is
the right time to do it.
Rossen: I see support in IRC by fremy
florian: This will also be a change in form controls, which are
weird and not completely replaced elements, and are not 0
when they are empty
florian: I ran into a bug about this. Dropdowns with no children are
big enough to not only have the arrow but also have some
space where its contents would be
Rossen: What is the summary?
florian: Proposal: Replace what we have in .1 of size containment,
where it says [reads]
florian: And to say that all elements are .... no. we don't want 0.
we still want to fill available width.
florian: If you're a block and you're size contained, you're
supposed to fill your container
iank: I agree it should be potentially an exception for replaced
elements and non-replaced elements
<fantasai> Kinda discussing 'contain: size' vs 'contain: children',
seems like...
<fantasai> ... where 'contain: size' treats min-content and
max-content sizes as `contain-intrinsic-size`, and
'contain: children' pretends there's no children for
purpose of intrinsic sizes...
Rossen: Let's take these one by one
Rossen: For the contain spec, we are going to add a clarification of
ignoring children for intrinsic sizing purposes and not
layout
florian: We're either going to tweak the wording editorially, or
we're changing that min-content and max-content width and
height are 0
dbaron: I'm nervous about addressing min-content and max-content
only without also saying what the effects on layout are.
Size containment affects both of them.
florian: There is no effect on layout.
dbaron: I think there is from one layout model to another. That's
correct for grid, but I don't think every layout model lays
out that way. For example, block does in one dimension but
not the other
AmeliaBR: How about "for the purposes of determining size,
min-content and max-content are 0, but they go back to
normal when laying out children?"
dbaron: I'm trying to think through it again.
dbaron: Don't wait on me.
Rossen: It's valid to not resolve on this if we're not ...
florian: We've uncovered something new and significant. There is a
benefit to simplify the definition for the purpose of
container queries, then we can go back to github to see
what it would be.
Rossen: It would be great to consider more than grid in here. Would
this ever be possible in tables?
florian: Size containment does not apply to various table parts
iank: Table size containment is broken in many browsers
Rossen: Let's end here.
Rossen: florian, you have lots of feedback here to put into the
issue. Let's continue making forward progress there. Feel
free to open the grid-related issue if we need to go that
way.
Rossen: That's everything for this one. Thank you!
Generic Font Families
=====================
github: https://github.com/w3c/csswg-drafts/issues/4910
chris: Myles started a wiki for criteria for new generic fonts
<astearns> https://wiki.csswg.org/spec/css-fonts
[Archived at https://lists.w3.org/Archives/Public/www-archive/2020May/0000.html
]
chris: I changed that to "what are generic fonts *for*"
chris: Started in a very different, Latin-centric CSS1 world
chris: Where we didn't know what fonts were available, etc
chris: Need to revisit
chris: Bunch of issues about generic fonts, but until we decide what
they're for, we can't progress
chris: One answer is we take an axe to them
chris: Another is "for writing system X you need to distinguish
between 3 things, generics only do 1, we need more" so we end
up with bunches of generics
chris: Fine with either solution, but we need to decide and not get
a mix
<leaverou> Not sure if this issue is appropriate, but it would be
good to have generic font families that are subcategories
of the current ones, e.g. rounded-sans, slab-serif, etc.
r12a: So chris outlined two possible routes.
r12a: There's a third option from Kida-san - "it's so hard to
predict what fonts would exist on someone's machine, I'd
prefer to use generic fonts all the time"
r12a: So the third option is to deprecate non-generic local fonts
entirely
r12a: Currently the generics are very Western-centric, and people
can't decide whether they're about style or substance.
r12a: I think generics could be about allowing people in various
different writing system to ensure they get a particular type
of font, which can be important for different things - like
how we use italics for emphasis, they might use a different
typeface style.
r12a: Other situations where if you're writing content in Kashmiri
or Urdu, and it falls back to a plain Naskh font, you lose
the cultural signifier, and it becomes hard for Kashmiri/etc
to even read it.
r12a: So if a font doesn't exist on the system you, want to go back
to a particular type of font, not a random one.
r12a: Big concern is that people could think up zillions of
different types of fonts.
r12a: I see a gap for i18n [internationalization].
r12a: For just a few things, not a huge number
r12a: The things I listed in the thread are pretty fundamental to
users of those scripts
<xfq> r12a's list ->
https://github.com/w3c/csswg-drafts/issues/4910#issuecomment-619342561
myles: I'm sympathetic to Kida's argument
myles: Scrapping all generics seems like the wrong direction
myles: Content blockers commonly disallow all webfonts
myles: So it would be cool for sites without webfonts to still have
some control
myles: So let's not delete the entire generic feature
chris: Fair
chris: Another thing that hasn't come up yet is, to what extent is
this mapping from the browser, vs. from the user?
myles: Let's say we gathered this evidence, what would that inform?
chris: If the browser, we need a registry saying what types of fonts
map to each generic.
chris: Otherwise we just describe what they do, and the user chooses.
chris: But most users don't customize, so I'd be wary of that
solution.
<xfq> Should we start a registry for additional generic fonts? ->
https://github.com/w3c/csswg-drafts/issues/4566
myles: Right, the spec right now has some examples and descriptions.
myles: I think that's sufficient, and we don't need a registry of
specific fonts.
fantasai: I think Richard's point about fonts used for
differentiation, similar to Latin use of italics, is a
really important point.
fantasai: We need to solve that problem for all the writing systems
that need it.
fantasai: Whether through generics or other mechanism, there just
needs to be controls for that kind of differentiation.
<chris> good point that this could be done by new font-style values
<xfq> to be pedantic, latin italics is controlled by a different CSS
property
fantasai: Myles' point in his wiki draft, that it needs to be
something that there are at least two fonts that do it,
seems like a base level of requirement [but doesn't
describe the goal]
fantasai: For the concern about cultural identity between different
linguistic groups, I think that should just be the browser
taking language into account when it maps generic fonts.
fantasai: I don't think we need to add generic font families for
every cultural variation, the lang attribute can handle
it. That might reduce the number of generics.
fantasai: So we mainly need to hit where a document uses the same
type of text in two or more styles.
myles: When you have a single element with two different langs, and
you style it with a single generic...
myles: If we want generics to have a meaning across langs, they need
to be similar
myles: So like 'sans-serif' with an Arabic character inside, it
would need to have a reasonable "sans-serif-ish" font for
Arabic
myles: So it makes sense to overload the term and use it for various
writing systems.
myles: But in Richard's list, I don't see much overlap.
myles: So don't think we can come up with one token that works
across those writing systems.
fantasai: I think you're addressing a different point.
<fantasai> https://wiki.csswg.org/spec/css-fonts
fantasai: I think the stuff that Myles wrote is two good tests; I'd
shift the second one to not just be pre-installed, but
include "commonly installed", to handle language packs.
fantasai: Otherwise I'd say that's a good test.
fantasai: But we also need goals for new ones. One we should
consider is where a single doc needs to differentiate
between two kinds of text.
myles: About the pre-installed vs not, the reason I picked that term
is that it's clearly testable.
myles: You can point to an OS that has it.
myles: The vaguer it gets, the harder it is to test.
myles: Hopefully we can come up with a more general term that's
still testable.
<chris> +1 to testability
<fantasai> Like, what does "preinstalled" mean for a Mongolian user
on Linux? It needs to handle common configurations of
operating systems, not just pre-installed.
dbaron: We've had some discussion about "does the user choose" vs
"does the browser choose"
dbaron: In a rough approximation, users don't configure their
browsers, so we shouldn't depend on that.
dbaron: Third option though is that the font designer chooses.
dbaron: It would take a longer amount of time to make the feature
work well, but I think it's something we should think about.
dbaron: Something we could design towards in the long run even if it
doesn't work in the short run.
dbaron: "Browser chooses" has more power on some systems, where the
browser vs OS has more control over installed fonts.
dbaron: On Mac you can make stronger assumptions than on Linux or
Android
dbaron: On a different topic, another question about generics is, is
it meaningful to fall back past a generic?
dbaron: In CSS2 it was not meaningful to fall back past serif, etc,
because there wasn't anything else.
dbaron: But we could think of generics as covering part of the
character space, that could still trigger fallback.
chris: We did change to allow that
myles: We changed it to match browsers in fact; the names are just
aliases, so fallback can happen normally.
myles: I think that makes sense with my earlier point about the
proposed new names not being generic.
myles: Best way to handle writing-system-specific names is to allow
the browser to fall past sans-serif and hit nastaliq, etc.
florian: Same with say "nastaliq" on Japanese.
chris: We can close a lot of issues of "how to match X on Y" with
"it doesn't"
<faceless2> +1 to allowing fallthrough, solves lots of problems.
stantonm: Use-case of ebooks too.
stantonm: Licensing structure for shipping fonts on ebooks is...
hard. Often charge per copy, cost prohibitive.
stantonm: So a lot of people want to use generics.
stantonm: That way they can get around these licensing issues but
still have interesting styles in their books.
r12a: I'm not so sure I agree with fantasai where she says identity
isn't that important, I think it's very important.
r12a: I think it's equally important to the other things she
mentioned, matching content to the right font.
r12a: I'm generally dealing with the long tail of the web, watching
languages struggling to get onto the web because we haven't
catered to them.
r12a: Many of those, requiring two fonts could be problematic,
because they might only have one font for a while, or at least
only one good one..
r12a: So that could prevent these languages from being equal
partners on the web.
r12a: So in the thread I was playing with the idea of users making
the assignment of installed fonts to generic names.
r12a: I take the point that users don't mess with prefs much
r12a: But if you're in northern Nigeria, and everyone around you use
a kano style of Arabic, you're quite motived to get your
browser to produce that type of font
r12a: So I think we shouldn't deny users the ability to make that
association.
fantasai: I'm not saying it isn't something we should address, I'm
saying it should be automatic when you choose a generic
font, by taking notice of the lang of the document.
fantasai: So if you have a writing system with two variants,
language A and language B, if the doc says it's in
Language B you should get an appropriate style.
fantasai: Shouldn't require the author to specify a new keyword,
should be built into the way generics behave generally.
r12a: My concern is that people developing browsers don't understand
the reqs to make that work.
fantasai: Agree, so I agree that users should be able to configure;
I just don't think that's a reason for new generic names.
r12a: Also note that shoehorning some of these into the existing
generics doesn't work, too many differentiations and they
don't map well to serif vs sans-serif anyway.
<AmeliaBR> +1 to using names that are actually relevant to the
writing system
atsushi: Calling from i18n wg and jlreq
atsushi: So for CJK fonts, quite a drudge to make it available via
webfonts, particularly since they can be many megabytes in
size
atsushi: Similar generic fonts already in OSes
atsushi: So defining generics for CJK could help webdevs a lot.
atsushi: And also for epub, it's widely used in Japanese publishing
industry. Additional generic fonts beyond serif/sans-serif
would help a lot for Japanese book publishers.
florian: I don't have a strong view as to *how* to address the
identity question, but agree it's very important
florian: Easy example for Latin speakers - what if the system fell
back to Fraktur when the fallback failed? That's what
people are living with in other languages.
florian: So about "what if there's only one font"? In that case you
can use it by name.
florian: And when there are multiples, we can come up with a generic
name as needed.
florian: So we could come up with an at-rule that lets authors
specify a font that can get overridden by UAs later
myles: That's just a @font-face with a local() source, right?
florian: Hm, if there's no real parsing differences, maybe
fantasai: What about blocking local fonts? Then it wouldn't work
myles: Still discussing balance of privacy vs minority fonts, yeah
florian: Also, letting fonts decide which category they go in - what
if it matches multiple categories? Which do you pick?
faceless2: I think the list Myles came up with to restrict choices,
requiring 2 versions etc, it strikes me that if we make
the cost of adding generics much cheaper (like 3rd party
registry), a lot of these restrictions wouldn't need to
be there
faceless2: I'm a big fan of the counter-styles registry, for example
faceless2: Wondering about the interaction there
faceless2: myles, you said you were against a registry
myles: No registry can cover every OS/browser combo.
faceless2: Sure, but interested groups could maintain that.
myles: OSes change yearly, who's gonna maintain that?
florian: I think this is effectively happening decentralized now -
if I want the right font in Japanese, blogs say "if you
want to handle these version of Windows, Mac, Linux, here's
the big font stack to use in your stylesheet"
dbaron: If we do something like "Window 10 has a new Japanese font
we want to use for serif", changing Firefox to do that is
sometimes involved, there's webcompat issues, etc.
dbaron: So maintaining that set of stuff is part of maintaining a
browser, it's not just "we can change that and everything's
fine"
<r12a> for clarity: I was talking about a registry for generic
names, but not for assigning fonts to those generic names
myles: Quick mention - atsushi mentioned CJK fonts in particular can
be big
myles: WebFonts WG is currently in the middle of investigating
options for streamable fonts, so the browser only downloads
the glyphs it actually needs from a font file.
myles: Some early exploration suggests this is orders-of-magnitude
speedup.
<faceless2> @myles actually we've implemented the ability to
download parts of fonts already - it's a variation on a
loading technique used for PDF. Doesn't work for WOFF2
but for regular OpenType it does. No proper figures on
performance but I can look into this
<r12a> (there are also pages like this https://r12a.github.io/scripts/phrases
that would involve downloading LOTS of fonts to display)
chris: I think we still haven't really solved what generics are for,
but we're some ways toward that. I think we can continue in
the issue. Shouldn't close the other generic issues until we
work out an overarching strategy
Received on Tuesday, 12 May 2020 23:07:04 UTC