- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Aug 2019 19:05:37 -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 Fonts
---------
- The group continued discussing the proposal to add
system-ui-serif, system-ui-monospaced, and system-ui-rounded
(Issue #4107).
- The main focus was if there is a valid use case to support these
new values instead of having Apple expose these as named fonts.
- The primary use case is for web apps where they want it to
look as native as possible including using the same fonts as
the system uses.
- There was disagreement in the group as to if this is really
useful since not all systems have fonts that map to these
three values.
- If this proposal is accepted, the group also discussed how to
handle fallbacks. The two options are to fallback to a regular
system font or to allow these values to be a part of a font
family so authors can control the fallback.
- Discussion will continue on github to try and reach a consensus.
CSS Text/CSS Sizing
-------------------
- Issue #3440 (When to/not to include preserved trailing spaces) has
clearly defined proposals and PRs and anyone with an interest
was requested to review them and weigh in on github.
CSS Grid/CSS Sizing
-------------------
- Having sizing available for aspect-ratio only boxes (Issue #4228:
aspect-ratio-only boxes should be able to size to grid
container) was a desired behavior.
- However there were concerns about this adding significant
complexity to the layout algorithm for implementors, especially
when there are nested grids or when subgrid is introduced.
- Comments on github are welcomed, especially from implementors of
layout to see how large of a concern the algorithm changes
present.
Media Queries/CSS Sizing
------------------------
- The group's direction was to not simplify values when aspect-ratio
is <number>/<number> (Issue #3757: Support <number> (and
therefore calc) as a <ratio>). There wasn't time to discuss
other problematic cases (such as negative numbers and 0 in the
denominator) so discussion will continue on github.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Aug/0011.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Henricus Cabanier
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Thierry Michel
Anton Prowse
François Remy
Devin Rousso
Florian Rivoal
Christopher Schmitt
Jen Simmons
Alan Stearns
Lea Verou
Regrets:
Tab Atkins
Christian Biesinger
Chris Harrelson
Scribe: dael
CSS Fonts
=========
system-ui-serif, system-ui-monospaced, and system-ui-rounded
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4107
myles: We started talking about this last call
myles: Refresh memories: 3 new system fonts in macOS and iOS.
Question in last call if we add a keyword and platform
doesn't have this what happens
myles: Because this is designed to be used in system UI having a
fallback to match system UI would be best way for it to work.
Proposal is if you're on a platform that doesn't support
requested font, the font is rendered as system-ui rather then
system-ui-serif or whatever is requested. Proposal and open
to change
myles: Other thing from last week is which platforms support these.
macOS and iOS support all 3. Android has serif and mono.
Windows has sego-script which I think is a good match for
rounded.
myles: Love to hear thoughts.
AmeliaBR: Good point on issue discussion: We have well defined
fallback in font spec. If there isn't a match reasonable
to not match anything and let author say where they want
it to fallback. Author can decide if it's more important
to match system or have a style feature.
AmeliaBR: Using fallback in the font stack author can decide
<chris> fallback to fallback to system-ui seems good to me, but I
also appreciate amelia's point about flexibility
AmeliaBR: Similar, I don't think we should stretch to match system
fonts. Sego scripts are very different then the rounded.
If we encourage browsers to randomly attach fonts they'll
end up as useless as current generic keywords. No one uses
"cursive" or "fantasy" because don't know one device to
the next
Rossen: Other thoughts?
* tantek is leaning towards the proposal
myles: To reply. Your first point is fine for fallback. There was
support on issue for both directions to either is okay
myles: Second point I defer to people working on Window OS what's a
good match
Rossen: Fair
Rossen: I'm going to have to defer responding until have a chance to
discuss with windows fonts team and see if they have a
suggestion and if they want to take dependency on
Rossen: High level I don't think we should have a problem to match a
font provided to resolve to accept this
<chris> agreeing with the side point that cursive is almost useless,
and fantasy should really be removed from the spec!
<bradk> Good point about cursive and fantasy fonts
<tantek> bad design of past generic families is not a reason to
block an improved modern way to access system-ui variants
<AmeliaBR> tantek, no, my point is that we should be careful not to
repeat the mistakes of the past!
myles: If people are done discussing feature request there is
related discussion on syntax to trigger. If we're done we can
migrate to syntax.
Rossen: First being if we want to do this?
myles: Exactly
Rossen: Based on GH issue discussion it feels like we're ready to
take on this feature?
myles: Looks like that to me
Rossen: I want to resolve on this and then sweat the details.
tantek: I have an opinion with historical view. Traditional system
fonts were derived directly from windows UI. When impl on
mac didn't map well and weren't good design.
tantek: I read github and I don't think old system font names should
block having this be considered.
tantek: Similarly, the fantasy and cursive fonts I agree no one uses
them because unpredictable. If I recall they came from
truetype fields. That was before we incubated specs. We took
values from another spec with no demand. I wouldn't count
either of those against this proposal
tantek: I looked at github examples and do present a strong case for
having those 3 ways act as system-ui variants if fallback is
system UI font. Seems safe and useful, especially for mobile
web UIs. That's a strong priority for the web platform,
higher fidelity mobile web design
tantek: I lean strongly toward proposal. Having worked on CSS UI for
20 years I like minimalism
fantasai: I would like clarity on if we use keywords for generic
font family or if they are different kind of keyword that
can say I don't exist
myles: Proposal is generic font family names. If you're on a
platform where meaningless they're the same as the system UI
font family
AmeliaBR: But there isn't agreement that's way to go
fantasai: I feel like that makes sense for rounded, but monospace
you want to fallback to monospace font
<tantek> that would be sensible (fallback to monospace)
<astearns> +1 to mono point - we should just have authors add
`system-ui` to their font stack if that's the intent
leaverou: Small comment, people don't use cursive because it's ugly,
not just unpredictable. Second, these keywords seem like
they're centered around something Apple did. Not sure what
need is or how they work in other platforms. I'm failing
to see use cases. In github most of the discussion is
fallback and not why this is needed.
leaverou: We should have a generic rounded font family, not
system-ui-rounded. Seems like we're doing this because
apple did something and needs to expose and not because
author want
myles: We have plenty of requests form people that have attended
events and they want to use these fonts.
leaverou: That's a different point.
AmeliaBR: That people want to use these fonts is different then
people wanting an OS tuned rounded font on every OS
AmeliaBR: If you expose these fonts as a keyword that's mac specific
that would be something that could be in a normal font spec
leaverou: system-ui-monospace has a semantic difference. I'm using
the system's monospace. If people are telling you they
want these fonts they would use them if they're exposed.
They're not saying they want a system UI
myles: On macOS and iOS there is nowhere in the OS where you can
type New York and get these. They're described by the token
of rounded, serif, etc. And that's because we're allowed to
change these fonts with the future of OS. That's intentional
<tantek> I like the system-ui- prefix from an authoring perspective
because it clearly communicates the UI use-case and
discourages use in just "content" (body copy etc.)
fantasai: Not sure why that means we can't expose the names to the
web platform
myles: Second piece is these are designed to be system UI fonts and
not document fonts.
Rossen: You're exposing them to be document fonts
myles: Not intentionally. No way to use them only in a UI context in
web platform
fantasai: Also a number of kinds of fonts. There's fonts only for
title. Different fonts for different functions is not a
new thing. There's plenty of fonts that don't have special
keyword.
florian: And if there's a bunch of people wanting the pretty font
and give a keyword that returns it not but not in the
future you haven't given what they wanted
<tantek> To me the use-case is building mobile web UIs that fit in
with the platform. This is a good proposal for solving that
use-case.
<tantek> You don't want to use specific named fonts for UI
<tantek> We have plenty of things in the platform that can be
misused/abused, that in itself is insufficient as an
argument. The point is whether a feature is designed to
nudge authors toward the positive use-cases, and if so,
then it's at least a good feature.
Rossen: Want to timebox to 5 minutes then back to GH. There's a
queue. Challenges about exposing font on web layer vs having
them exposed behind a keyword was recorded and myles
addressed it. Want to go to queue
leaverou: People who said fonts are pretyt, did they mention their
use case? How do you know they'll use it right? And people
at WWDC much more likely to make Apple specific and I
don't want that.
Rossen: That point was made leaverou I think myles addressed. myles
more to add?
myles: Group is right, it's possible to expose using names like any
font. We brought this up to try and be good citizens of web
platform and try and figure out if there's interest in having
platform non-specific way to get these system ui variants. If
group doesn't want we can pick names for them. It will have
to be similarly generic, but it's a valid path if group
thinks this is not desirable
myles: Platform conventions of macOS and iOS this is best match of
design intent for these fonts
<tantek> The GitHub issue already addressed how to do Android
interop with this too
<tantek> feels like people are not reading the GitHub issue existing
comments
Rossen: Please keep comments as to if we're interested in a feature
to have generic system fonts
florian: Two points. If we decide against doing this generic and
apple does it I would encourage a normal fallback mechanism.
florian: Second, maybe I misunderstanding use in native system.
Increasing ability to mimic native OS seems like a spoofing
mechanism for me to make it look more like it's part of the
native app. Already somewhat possible, but maybe not easier
<tantek> so add it to the Security Considerations section
myles: It is common in web view apps and on the web to display UI as
would natively look if native app. One person "spoofing"
system UI design is another person's feature
<tantek> ^^^ this, making mobile web UIs that look native to the
platform is a *good thing*
<tantek> I feel there's a bit of mischaracterizing going on of
myles's use-case
fantasai: I'm still not clear what the strength of use case is for
special keywords vs exposing font. Use case you've given
us is fonts are pretty. But that's not use case for
system-ui-rounded, that's a use case to let people specify
the font. If these fonts were exposed with a name, would
there still be a need for these keywords? If so, where is
demand from?
myles: I don't have anything new to add
<fremy> @fantasai @myles: I guess if you are making a book-reading
experience, you might want to pickup the native serif font
florian: I don't think you need to report why you don't want to. But
if you had been okay exposing them, would there still a
separate need for the special name?
myles: Two reasons is 1) they have applicability to other platforms
2) Even on apple platforms they are not IDs by name so
meaning might change
fantasai: Keyword can have a meaning change. Font by name you do
change the name if you change the style of the font
<tantek> when you author a UI with the web platform, you DONT want
to have to specify the specific font by name for each
platform, because that's A LOT of extra work. consequence:
authors pick 1 or maybe 2 platforms to look good, then
others look poor
<tantek> you really want these kinds of generic font names for web
UI, to encourage/enable cross-platform UIs rather than
making non-majority platform second-class
fantasai: I don't see the second and a thing that needs to be
considered, it's a quirk of the platform.
fantasai: First case there's a lot of cases where it's not clear if
there is one.
jensimmons: Can I answer that?
Rossen: I'd like to close. Please make it quick
jensimmons: I think from author prospective it would be good if they
had access to fonts. If we have system-ui-serif,
system-ui-monospaced, and system-ui-rounded as an author
they will expect it's different on different OSs. If
Apple redesigns it would automatically update. People
might want to do that as they're making web apps. It's
why people like material design. It gives quick access
to Google design
<tantek> +1 jensimmons. thank you for making this point clearer
jensimmons: I think this would be similar where if you want
something to look like OS this is how you do it. Authors
might think it's a shortcut to get the pretty fonts, but
the primary use case is you want to look like system
software
<fantasai> I would be OK with that if it wasn't the only way to get
access to these fonts.
<fantasai> So that if someone wanted to use the font, they didn't
have to use a system-ui keyword if they didn't want it to
change.
<tantek> no I don't want that (apple- prefixed fonts), because THAT
is how you get apple only designs. a generic system-ui-
font is how you get at least *a chance* of cross-platform
nice looking web UIs
<jensimmons> I would say yes, you need to expose them in this way if
Author’s can access them directly. In the past, people
could use a font stack that would give them the same
result — but without an ability to name these new fonts
directly you can’t use the old techniques.
Rossen: We keep repeating this; do we need to expose specific system
fonts and figure out if they will be mapped to what author
wants to expose
<dauwhe> the jensimmons comment was helpful to me and did not sound
like repetition
AmeliaBR: I was going to suggest can we have font keywords that are
apple prefixed. Used across browser to match apple font on
their system. After this I don't think that's a good idea
AmeliaBR: I do think it's a use case to have a system-ui font that
works on android and apple and will work on windows in
future if they add serif. Important not to force systems
without these fonts to match they keywords and instead
have normal fallback where authors have control
myles: If these don't turn into system-ui we would probably expose
as apple prefix.
tantek: And that's worse in my opinion
AmeliaBR: Let's discuss on issue
<jensimmons> In fact, this makes it *easily* for Authors to
specified OS fonts directly, instead of having to go
learn what they are… update when they change… figure
out a font stack that works.
<tantek> I kind of want to see examples from folks here actually
building UIs in HTML+CSS, especially those arguing
*against* the proposal
<tantek> I see this proposal as *improving* the situation vis-a-vis
existing system fonts. That's good enough for me.
Rossen: I want to close this discussion. Issue is alive and healthy.
Let's cover there and bring back maybe next week
Rossen: First thing is: is there a need to have a way to target the
system fonts for UI purposes.
Rossen: jensimmons summary of the use case is excellent. That's in
the notes. Please engage on github. We'll come back next week
CSS Text/CSS Sizing
===================
When to/not to include preserved trailing spaces
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3440
florian: Is koji on?
[he is not]
florian: Comment to rest of group. We resolved on this about half a
year ago. I worked on a PR to apply resolution and found a
weakness. I proposed a close alternative to the design. I
asked fantasai to review.
florian: koji is other person close on that discussion. I'm not
clear why he disagrees. He sees both options as a
regression to what was there before. But I think the
requirements are what he expressed in the past and now
calls regression. I could be confused.
florian: It would be helpful to have more people looking. You have
white-space: pre-wrap and there's whitespace at the end.
There's detailed PRs and examples. If you have any interest
I would very much appreciate someone looking and seeing if
I got it right or if there's a problem
florian: It would be helpful to have people look. We can't resolve
without koji
Rossen: And there's always TPAC
CSS Grid/CSS Sizing
===================
aspect-ratio-only boxes should be able to size to grid container
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4228
fantasai: I think case where we found as we audited sizing rules.
When we don't have definite available space, could provide
grid-container size. Currently undefined or infinity. You
have an item and an auto-sized grid track. Tries for
max-content. Row doesn't have size so when we try and size
we say infinite. Maybe we should provide grid-container
size
fantasai: This would be change to way grid works
fantasai: How it finds the max-content size of an item in a row that
is not fixed
jensimmons: When fantasai talked this through I liked what she
proposed. Image should fill what's available. I was +1
to it
fantasai: When trying to find max-content width and item needs to
know height to resolve it then we need to take into
account height to find width. If we don't have one we try
and shift to container size. In grid container case the
container is the grid area and if it's auto it doesn't
have a size we can pass to algo
fantasai: So it ends up as infinity or undefined and not a number.
fantasai: Proposal: in case of grid if row doesn't have a size you
can use then you look up to grid container and use that
<fantasai> https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes
fantasai: Applies in sizing of image with aspect ratios ^
Rossen: Every time we try and make a dependency all layout algorithm
become difficult. All layouts are defined to operate on a
single container item relationship basis. Breaking that rule
and defining this layout type you will be defining a size
based on an ancestor things become difficult
Rossen: We have made that exception before like orthogonal flows,
but it is implemented as an exception to find the ancestor
with a defined size. This is an exception and usually ugly
at cost of artifacts.
Rossen: You can always create cases where this becomes inefficient
fantasai: Not looking at ancestor, grid row looks to grid container
Rossen: But you have a grid inside a grid inside a grid. Always a
case where these exceptions fall and people think it's just
a few above. Already one ancestor, why not more?
fantasai: It's not an ancestor. It's grid container
Rossen: Layout PoV we're going through area that's used for layout
considerations for resolving positioning. We are proposing
to escape layout area and go to container which is next
level ancestor of grid item
fantasai: Containing block corresponds to actual box in other layout
cases. Grid has abstract containing block as a sub part of
grid. When using that to calc max content when itself
isn't fixed we look at grid container sizing property. I
think this is reasonable to do
Rossen: In case where grid container has undefined size?
fantasai: No change to that case
Rossen: But the point I was trying to make is grid container could
be a grid item. It needs to go to its container grid
fantasai: Not doing that for writing modes so not doing for aspect
ratio. If the grid container was height 100% and 400px
it's fixed and would pass down to its children. It's child
to parent but in grid there's a structure which is the
grid. Grid is containing block of grid child but doesn't
look at containing block to get a size
fantasai: Proposal is to say that even though parent is not
containing block it takes a size from it when it needs a
size
Rossen: That's my point
fantasai: You're arguing we'd walk up chain, but we're doing child
to parent directly
Rossen: Once we add things like subgrid we'll have to keep that use
case in mind and continue thinking bout this exception case
where we defer to a different level. You will face that case
all the time if we make an exception now
Rossen: Would prefer if we're using the grid item's type
contribution. I think it was second proposal? max-content
size from available space
fantasai: That's what we're trying to define here
AmeliaBR: Might be helpful to look at breaking this algorithm to add
more detail. It's true that there are very simple cases
where you gave explicit grid-row height and you want grid
items with aspect ratios to fill explicit dimension and
auto-size in other and that should happen automatically
AmeliaBR: Rossen concern about what if you have rows dependent on
parents and other children and how to define non-circular
I think there will be using the existing grid text and
text with flexbox and aspect ratio where we redefined how
aspect ratio boxes worked because initial behavior wasn't
useful.
AmeliaBR: I suspect we have necessary sub algo defined
fantasai: We do this for the orthogonal dimension. If the available
space when sizing a grid item is taken from row with
constraint it looks to grid container. Just not with
aspect ratio
fantasai: For aspect ratio we need to take from inline dimension and
that's not designed
<fantasai> https://drafts.csswg.org/css-grid-1/#algo-overview
<fantasai> "If calculating the layout of a grid item in this step
depends on the available space in the block axis, assume
the available space that it would have if any row with a
definite max track sizing function had that size and all
other rows were infinite. If both the grid container and
all tracks have definite sizes, also apply align-content
to find the final effective size of any gaps spanned by
such items; otherwise ignore the effects of track
alignment in this estimation."
<fantasai> We need to do this in the inline dimension
AmeliaBR: Are you able to break down where in all existing layout
algorithm there would need to be new rule? That would make
it less scary
fantasai: Yes, right now depends on available space in block axis.
We would address it in this section [above] if you don't
have definite row we can provide by grid container
fantasai: If people want to look more we can come back
Rossen: Own this more thinking, it's a fundamental thing and careful
what to select
Rossen: My pushback is based on working on a lot of it and making
such an exception requires adding a lot more information
that needs to be kept track of and that complicates layout
algo tremendously
Rossen: Need to see if this manifests as super common use case with
adverse effects or if this is something most people won't
hit.
Rossen: I'd prefer to let others comment, especially other people
implement layout
Rossen: That work for you fantasai?
Media Queries/CSS Sizing
========================
Support <number> (and therefore calc) as a <ratio>
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3757
emilio: A contributor implemented this in FF. Couple issues related
to thing we didn't resolve on. Resolved to allow syntax as
<number> but not on serialize, if you can do two negative
numbers. Regular aspect ratio we only allow positive int
[audio problems with emilio]
Rossen: While we wait on emilio to reconnect...
AmeliaBR: I can fill in
<emilio> thanks AmeliaBR!
AmeliaBR: Resolution we had previously was to loosely allow any
number over a number or a single number as valid syntax
AmeliaBR: Simple question of serialization we've got backwards
compat on people expecting int/int Anything spec that was
should continue to serialize that way
AmeliaBR: Options from there are remember if it is spec with a / and
keep that or always serialize with a / and add /1 if it's
single number
AmeliaBR: As emilio points out there are other questions about how
much do we simplify, if you've got -int/-int does it
simplify or clamp. /0 is valid according to syntax, how to
deal
AmeliaBR: One option is treat like calc but in serialization we add
in the /1. Can lose numeric precision in some fractions
AmeliaBR: If you specify 2/3 to get 0.6667/1 that would be a problem.
AmeliaBR: If we're not simplifying into fractions what to do with
arbitrary numbers. Keep as two separate? Lean to keep 2 as
separate and if isn't spec insert a 1. Simplest approach
and least likely to surprise
fantasai: Shouldn't reduce everything to over 1. Have principle we
serialize to most backwards compat and shortest, not just
shortest. The older form serialization will need both
numbers. Shouldn't simplify fractions down.
fantasai: Could do 9/3 to 3/1 but don't see a benefit to doing that
jensimmons: For clarity, is this visible to authors or is this in
the calculation when you get to computed
fantasai: For getComputedStyle
AmeliaBR: Effects both reading back value from dom, simple
serialization, and serialization from getComputedStyle
fantasai: Important to note values from getComputedStyle need to
roundtrip without loss. Simplifying 1/3 to 0.667 isn't in
keeping with those principles. Not appropriate to do here.
AmeliaBR: We do it with calc, though
AmeliaBR: Worth mentioning for backwards compat the syntax is
currently only in MQ. Not sure how much people are reading
back values, but I'm sure someone is somewhere.
Rossen: Couple minutes overtime. I don't believe we can resolve on
this. Again, I invite folks to engage on GH and we'll pick
up next week
Rossen: Sorry we couldn't make any resolutions today, let's hope
it's different next week. Thank you all for calling and
we'll chat next week. It's APAC time.
Received on Wednesday, 28 August 2019 23:06:39 UTC