- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Dec 2019 18:16:07 -0500
- 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.
=========================================
Writing Modes L3
----------------
- RESOLVED: Move CSS Writing Modes L3 to PR.
- Issues #4026, #3095 and #2890 will be retagged to be addressed in
L4 and this will be noted in the DoC
CSS Fonts
---------
- RESOLVED: Remove font-variant @font-face descriptor from Fonts 3
(Issue #2531: Remove font-variant @font-face descriptor
from Fonts 3)
- RESOLVED: There should be a way to use true user-preferred font
sizes. (Issue #3708: Dynamic text size)
- The method of achieving true font sizes was not agreed upon,
just the intention to do it. There was a proposal for yet
another mode switch, but also a desire not to keep adding
permanently-used mode switches to the Web platform.
- RESOLVED: Adopt the proposal (
https://github.com/w3c/csswg-drafts/issues/4044#issuecomment-532052266
)
for font-stretch (Issue #4044: Vertical text doesn't
play nicely with font-style and font-stretch)
- There are concerns about removing access to local system fonts
as proposed in issue #4055 (Mitigations for font based
fingerprinting. Concerns include performance, breaking content
for minority language users, and requiring more data download
which is bad especially for users that have limited or metered
bandwidth.
===== FULL MINUTES BELOW =======
Agenda: https://wiki.csswg.org/planning/tpac-2019#agenda
Scribe: mstange
CSS Writing Modes
=================
Implementation Report and Open Issues
-------------------------------------
<florian> https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08
<xfq> Current open issues (for L3):
https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-writing-modes-3
florian: We've been working on the writing mode spec for some time.
I've updated it since I've showed it last month.
florian: Out of about 1000 tests, about 14 failed and 24 others
failed. (?)
florian: There will always be some tests that fail. We'll be fixing
things forever.
florian: Have we done enough fixing already to move on?
florian: There is a number of issues that are marked in yellow,
which are a not insignificant part of the remaining tests.
florian: They have some patches which are about to land in Gecko so
that they will pass.
florian: Some tests could be split up into two tests, both of which
will each pass in different browsers.
florian: There are a couple legitimate failures as well.
iank: Please don't remove tests that test intersections of features.
Those tests are useful.
florian: In this particular test, the two features are independent.
The intersection is not tested.
florian: The test results are from current Chrome Canary.
florian: We have not done enough work on writing modes to never
think about it again.
florian: But I don't think any problems are in areas we believe to
be wrong in the spec.
florian: It's my opinion that we can move on despite those failures.
fantasai: There are some issues about things where the spec is
unclear, and we should just do those clarifications.
florian: All issues are about things that ought to be better
defined. But we need help.
fantasai: I think it would be better to address these issues before
saying that writing mode L3 is done.
dbaron: I've been uncomfortable with some of the things about
intrinsic sizing.
dbaron: I think the third issue is more on the material and sizing
than on the material and writing modes.
dbaron: In response to being asked to implement something in
Firefox, I ran into a list of conditions that was unclear.
florian: Was this not partly answered by text that was restored?
dbaron: I think this was after it was being restored.
florian: fantasai discovered that some section had been lost and it
was recovered in late August.
dbaron: This is a specification pattern that is difficult for
authors. Rather than saying "You want to compute X", it says
"You calculate in the following terms".
dbaron: It is very hard to know what some of the terms mean in a
specific context.
florian: I agree that this specific text should be tweaked. But the
level of writing in L3 is higher than in L2. Raising the
bar of writing is good, but gating specs on that bar might
not be necessary.
florian: Can we address this in L4?
dbaron: I guess. L2.2 probably did not have backward references to
things that were poorly defined to the degree that L3 does.
Rossen: How do we move writing modes forward?
Rossen: Do we actually want to hold off and resolve on these issues
with additional spec works and re-enter PR at a later time?
fantasai: With the exception of some tweaks, Gecko seems to have
implemented this just fine.
fantasai: We are basically rewriting all of CSS 2, but we need to do
it in pieces. The current writing is not ideal, but it is
the best I could do without rewriting CSS2 chapters 8/9/10.
AmeliaBR: Given that fantasai has said that Gecko is right, could
dbaron suggest new text that describes that & addresses
his issues (in time for publication)
dbaron: The hard part is the edge cases. The question is not, "Do we
follow this list of things in simple case X which is being
tested", it's "what is the exact list of cases where we need
to do this list of things"
Rossen: We almost went into Rec two or three years ago. I think the
level of the spec is fairly high at this point.
dbaron: I'm ok moving forward if you want, but there are cases that
are not defined enough to be implementable in an
interoperable way.
fantasai: This spec was written assuming grid and flexbox do not
exist. We can't make this gate on defining exactly how
things work in grid and flexbox.
dbaron: It would be nice to give an example where this list doesn't
apply.
fantasai: I don't know of one.
dbaron: That's why I suggested stating in the spec that it always
applies.
fantasai: Ah, the case was about computing max-content inline-size
vs auto block box inline size: in latter case, it's not
well-defined what max-content computation is in CSS2, so
could be conceptually that available size is infinite, and
it's OK. But auto width computation needs definite length
to subtract margin/padding/border from and result in
non-infinite content-box width, so can't use infinity, so
have to use fallback size
Rossen: The proposal was not to resolve the issues, it was to move
them and retag them for L4.
Rossen: Any objects to retagging the three issues to level 4? Those
are 4026 3095 and 2890.
<astearns> and they will need to be added/updated in the DOC
Rossen: No objections. We will move these issues to be tracked
under L4.
Rossen: Are there any objections to move CSS writing mode Level 3 to
PR?
Rossen: No objections, resolved.
<xfq> \o/
RESOLVED: Move CSS Writing Modes L3 to PR.
CSS Fonts
=========
Remove font-variant @font-face descriptor from Fonts 3
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2531
myles: We have two text paths. In WebKit. The distinction which path
to go to has to happen before font fallback.
myles: Sometimes we detect something too late and can't go back and
re-do everything, so we just do our best.
myles: If this is not necessary for the web platform, let's remove
it.
fantasai: It does look like there is an implementation (faceless2
says it in the issue)
fantasai: If the feature doesn't have a problem, we should leave it.
We do not need implementations to move this spec at the
moment.
myles: When is the deadline? It's been years.
Rossen: This is a non-verifiable implementation. How do we evaluate
it?
drott: We would support removing it because the semantics are
unclear in some cases.
heycam: We would also be fine with removing it. We haven't heard
much demand from authors.
heycam: In principle it seems like a useful thing, but we would be
fine with removing it.
Rossen: Any objections to removing it?
Rossen: No objections.
RESOLVED: Remove font-variant @font-face descriptor from Fonts 3
Mitigations for font based fingerprinting
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4055
chris: The issue is that you can pretty much identify individuals
based on the set of installed fonts.
chris: For example, I have all CSS test fonts installed and some
fonts for languages I don't speak, and that identifies me
uniquely.
chris: One proposal was to only report fonts that are the standard
fonts for that platform.
chris: But this would cause you to re-download fonts you already
have.
chris: This consumes unnecessary bandwidth.
florian: On some OSes, even the set of default fonts can almost
uniquely identify you.
myles: It is impossible for the spec to describe the set of default
fonts.
myles: The proposal is to say in the spec that browsers must have
some affordances to protect user privacy by having some sort
of (?)
florian: On the performance vs privacy question, I lean towards
privacy. On performance vs internationalization, it's less
clear: If you don't have the font for a particular language
and can't read the text, that's bad.
chris: There is a strong web compat problem here. Things that used
to work should not break.
florian: When working means look pretty, there's a trade-off. When
it means you cannot read it, it's different.
<fantasai> It was also pointed out that downloading fonts can cost
money in some areas, and this is more likely to be the
case in areas which are more likely to use minority
languages and which have less money to spend
myles: WebKit has been doing this for over a year. We discard
user-installed fonts from lookup in CSS
florian: Mongolian without fonts is unreadable.
florian: When it is readable, removing the fonts breaks it.
myles: It's a trade-off.
thomas: How did you choose that list of fonts?
myles: I commented on the issue.
thomas: Rather than a bespoke list, could we come up with a list
that can be updated periodically? Some list that covers
languages for i18n use cases, as well as some fonts that are
installed on machines.
?: Why do we have an API to return list of fonts?
iank: The information about fonts is queryable by measuring the
bounds of boxes, without getting the list of fonts from an API.
Rossen: We will pause the discussion of this issue and unpause it
after the break.
Dynamic text size
-----------------
github: https://github.com/w3c/csswg-drafts/issues/3708
jcraig: For a long time we've had scalable fonts that are based on
the Desktop Web.
jcraig: It took us a while to make it work on all extreme cases.
jcraig: We would like to support low vision users who have extremely
large text sizes.
jcraig: But forcing such giant font sizes on web pages would make
most web pages unreadable.
jcraig: We would like to have a way to opt in to larger font sizes
jcraig: as an author.
jcraig: We would also like to propose a feature that allows web
pages to detect large font sizes and adjust the sizes of
other elements.
jcraig: We have some aspects of this that are available today: You
could detect based on min-width in ems, but that does not
work consistently.
jcraig: Right now there is no standard way to opt in to this that
works across all browsers.
jcraig: Most browsers on mobile systems don't want to break their
users' layout.
jcraig: We have examples where it would be very difficult or even
impossible to achieve the intended layouts today.
jcraig: [demo]
jcraig: I have applied iOS settings that render text extremely large
and bold.
jcraig: I can show how different apps deal with this setting.
jcraig: Calendar switches to 3 or 2 column layouts.
jcraig: The Books app switches from a 2 column layout to a single
column layout.
jcraig: In Mail, with larger font sizes, the title gets clipped but
the email's time is preserved.
<fantasai> These are all very easy to do if you have flexbox/grid
and correctly implement media queries in em units
<fantasai> or ch units
fantasai: Is the problem that we can't actually implement media
queries with accurate em and ch units because the web
would break, but you want to have media queries with
em and ch units?
fantasai: Everything you've demonstrated here is totally possible
with em and ch units in media queries.
fantasai: On mobile you're not returning the correct values because
that would break. So what you're saying is you want real
units?
jcraig: What we want is an ability for an author to say "I can
handle any font size you throw at me."
florian: How possible is that this signal becomes worthless over
time as it gets copied around, and we need to add still
another signal?
chris: People are rapidly going to find out that just copying this
around will break them.
jcraig: The reason we don't turn this on by default is that web
developers *don't* find out that it breaks them.
jcraig: They haven't turned on these large fonts on their system.
<chris> fair point, retracted
jcraig: The first part of what we need is the opt in to the higher
font sizes. The second part is the media query part.
fantasai: In order to do the kind of layout transformations you
want, you also have to know how many letters fit on the
screen. You'd use the min-width query with ch.
jcraig: That would get us some of the way.
fantasai: Having just a media query for the font size itself is not
enough if you can't relate it to the size of the viewport.
florian: You can't compare the font size and the viewport because
the lengths have different units.
florian: The thing you call an opt-in would also opt in the media
queries to behave properly.
florian: Whichever opt-in we have needs to opt in both to behave how
things were originally intended.
<AmeliaBR> `@media (min-height: 10em)` only works if the window root
em size is accurate. So if we don't reveal the accurate
preferred em value except in an environment value, you'd
need to use `@media (min-height: calc(10*env(
user-font-size)) )`
fremy: If you have a user font size variable, you can use calc to
obtain the right answer.
fantasai: As an environment variable, it would work out.
fantasai: But Firefox uses different font-sizes for different
languages, so it would be multiple variables, not one
variable.
fantasai: The size of ch is dependent on the initial font, not on
the font that is used.
florian: There is a number of ways you can use environment variables
to do what you want, but if the opt-in mechanism opted in
everything, it would also work.
florian: Is there reason to exclude media queries from the opt in?
jcraig: It should not be excluded.
fremy: You want to be able to opt in only parts of a web site.
fremy: If the developer in the iframe did the work to deal with
large fonts, if it is embedded in another website that does
not handle them, all the work is for nothing.
jcraig: The reverse is also true.
fantasai: If the widget is inheriting the font from the parent
document, then it's going to have problems if the parent
document picks a larger font, regardless.
fremy: You cannot say media queries behave differently for different
parts of the same document.
florian: Yes, if you put a responsive widget into a non-responsive
website, then yes, your responsiveness is wasted.
jcraig: It sounds like we're agreeing that it would be useful to
have an opt-in for websites to express that they can handle
large font sizes.
florian: And we do not agree on the media query part - depending on
how we do the opt-in switch, that switch may also opt in
media queries automatically.
florian: If we can't make the existing media queries work, we maybe
need to add more media queries.
jcraig: That sounds reasonable. Once we have an opt-in we can
experiment and see in what cases it's not good enough.
AmeliaBR: Having it in CSS would be better than having it in markup
because you can put it into one shared stylesheet.
AmeliaBR: In order to get useful media queries, the opt in has to be
outside of a property.
AmeliaBR: If somebody has explicitly set this opt in value, then the
existing font-size keywords that were supposed to be
relative to the user-chosen default font size can actually
do that.
AmeliaBR: Otherwise, the default size will be the legacy 16px.
jcraig: I think that sounds ok. But a new media query would be
clearer in terms of what we want to communicate to authors.
jcraig: Without that, the complexity of doing layouts based on width
and layouts based on font-size is going to result in lots of
media query blocks. (?)
Rossen: We need to work towards a resolution.
plinss: I'm concerned about adding yet another mode switch. Mode
switches are bad. Can we do the right thing without a switch?
fantasai: I hate meta tags because you can't put them in a
stylesheet and link them from everywhere.
fantasai: However, it seems to make the most sense to add this as a
meta tag because it affects media queries and the initial
containing block size.
fantasai: And once the mode has been switched, font sizes and
everything else can start working the way initially
intended.
fantasai: These things all belong together so we should just tack on
to the meta viewport tag.
Rossen: I do not hear agreement on exact technicalities.
Rossen: Let's have a resolution on having a way to opt in, even if
we don't have the exact way of doing it.
Rossen: Objections on opting in to true user font sizes?
jcraig: We (Apple) tried to do this without a mode switch, by
default, and all 200 000 apps broke.
jcraig: Even with an opt-in switch, it took years for all first
party apps to support this mode.
plinss: ...
fantasai: I don't like mode switches either, but the alternative is
to add an entire duplicate set of font-relative length
units. A mode switch is a lot simpler.
AmeliaBR: I came in with the same concerns as plinss, but one thing
I did bring up was that, at the user agent level, there
should be reflection of the fact that there are two
classes of users.
AmeliaBR: Some users want fonts that don't want broken web pages,
and some users want readable fonts even if pages are
broken.
AmeliaBR: It seems that most users will accept smaller fonts if it
means that pages are not broken.
plinss: I have no concerns with a user switch. I have concerns with
adding a switch to the web platform.
plinss: If we have to commit this in again of adding another mode
switch, let's add it in a way that it can fade away in the
future, and not such that content will break if authors
don't anticipate the switch.
plinss: There is real costs to adding mode switches.
myles: The resolution seems to be about intention, not
implementation. Let's try to agree on that.
Rossen: Objections to having the option to have true font sizes?
RESOLVED: There should be a way to have true user-preferred font
sizes.
<break>
Vertical text doesn't play nicely with font-style and font-stretch
------------------------------------------------------------------
Scribe: emilio
github: https://github.com/w3c/csswg-drafts/issues/4044
nmccully: CJK text differs from latin because of the multiple
orientations
nmccully: because of that multiple features related to the line
width become quite complex
nmccully: [explains example in the issue]
nmccully: depending on the glyph orientation glyphs get stretched in
different directions
nmccully: As a user is backwards, as an implementor you need to poke
at the internal characters
nmccully: while the feature is about stretching the whole line
myles: This was discussed in OpenType and there was some discussion
myles: The font can't know how to do it right and there's an
opentype feature that only gets applied to upright characters
myles: but it's pretty hard to set up
myles: So opentype would introduce a new axis
myles: have both vertical and horizontal width
myles: and the application would set the relevant vertical /
horizontal axis depending on whether the glyph is upright or
not
myles: No resolutions anywhere yet but need to move it together
myles: So we need font-face descriptor to say that it supports
stretching in the vertical axis or not
myles: So plan is to extend font-stretch to specify using a
`vertical` direction that it's stretched in the vertical axis
myles: The font-stretch property wouldn't change syntax, but it'd
change behavior
myles: rotating the font in the appropriate direction
myles: which means that writing-mode and text-combine and such would
also be inputs to the font selection algorithm
myles: because if it's vertical it'd need to download the font that
can expand in the vertical axes
myles: Thoughts?
fantasai: sgtm
leaverou: Would the property change?
myles: The property has no grammar change but has behavior change
nmccully: You may need it for TCY
myles: The system I'm describing would either select an horizontal
or vertical font, but it's important that fonts can support
both so you don't require different files for fonts that
support both japanese and latin scripts
myles: Everything I've said also applies to font-style (for the
italic angle)
koji: What's the syntax proposal?
myles: [explains proposal in the issue:
https://github.com/w3c/csswg-drafts/issues/4044#issuecomment-532052266
]
myles: The OpenType piece is that we need to standardize a new axis
for vertical width and for non-vertical font you also need a
vertical width
nmccully: Adobe has formed an opinion already and has a prototype
koji: Should it be physical or logical?
fantasai: For font needs to be physical
fantasai: When you're typesetting vertical text you mix both upright
and rotated characters, so stretch axis from the glyph's
perspective depends on the uprightness
fantasai: Upright chars get "longer" in the vertical axes, sideways
keeps the same height but stretches horizontally
fantasai: so for the font descriptor it needs to be physical and the
property is logical and only applies in the inline
direction
koji: So you're saying physical to line orientation not to glyph
orientation
fantasai: font-stretch is line-relative and the font-stretch
capability in the font file is physical relative to the
glyph orientation
myles: [explains that in a different way]
koji: agree
heycam: I think proposal makes sense, I'd like to understand how
authors can achieve this without this feature and how
difficult that is compared to the font
nmccully: The browser would have to know how each browser treats the
font (regarding upright-ness)
nmccully: Then go browser by browser and change fonts per rune
heycam: So part of the issue is that browsers disagree on that,
right? (fantasai mentioned punctuation before)
fantasai: Yeah, even by that is a per-codepoint thing
fantasai: The initial values of text-orientation is mixed by
default, the author would have to do the automated
determination of rotated vs. not for the particular font
fantasai: Way too much work to request on an author, requires lots
of inline markup around punctuation also
nmccully: It's mixing two things, whether something is sideways is
not the author decision
nmcully: it's automated based in unicode-range
heycam: Oh I assumed that authors would have expectations and
browsers would be consistent
fantasai: I think this is the right design, I think it works great
for font-stretch
fantasai: for oblique and such it may not
myles: There's another piece. Today if you say font-style: italic on
vertical text you'll get weird stuff
myles: this proposal will fix that
fantasai: Don't we have a resolution on that?
florian: I think hiroshi wanted to reopen that
florian: but didn't because nobody seemed to run into a spec
Rossen: Would this change this resolution?
florian: Only if we apply it to font-style
fantasai: I think we may have a font-stretch-vertical descriptor
rather than stashing it on font-stretch
fantasai: but that's more bikeshedding and I generally agree with
the proposal
Rossen: Objections to adopt this?
RESOLVED: Adopt the proposal for font-stretch
Mitigations for font based fingerprinting
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4055
TabAtkins: [introduces the issue]
TabAtkins: We expose a lot of PI data on the web
TabAtkins: Even if you plug fonts we're probably not below the level
where you cannot identify a single user
TabAtkins: to do that you probably need to do software rendering on
canvas for example
TabAtkins: so unless somebody comes up with a list of stuff and data
TabAtkins: I think we shouldn't do that
TabAtkins: A bit annoying from a PR standpoint to argue why it
doesn't really matter but...
myles: Our goal is to remove all the sources of fingerprinting on
the web
myles: We should reduce as much as possible
TabAtkins: You cannot remove all of them
TabAtkins: no media queries, etc..
TabAtkins: Unless you could reduce it to 20 bits or less, you haven't
accomplished anything
myles: Well you're closer to the goal
[funny metaphors]
TabAtkins: Going from "individually identify someone" to
"individually identify someone" does nothing
TabAtkins: there's a specific threshold we need to reach to do
anything
TabAtkins: and nobody can
myles: We'll try
dino: I really believe we should ask the question for each feature
of what the cost is
dino: I accept what TabAtkins says about the number of bits
dino: but it's this group's duty to do the cost of the feature vs.
the privacy impact
florian: Cost is breaking the web for minority languages, benefit is
not clear yet
TabAtkins: W3C has the privacy interest group working on this, if
their conclusion is that we can hit this range by doing
this
TabAtkins: then happy to
plinss: Every time we add a bit we make it that much harder, if we
throw our hands up in the air then sure, let's add
identifiers
thomas: There's also ways to alert the user it's being fingerprinted
nmccully: I'm hearing mostly that it's not the right fix. We
shouldn't make it worse but...
myles: Our job is to design CSS APIs and we have to weigh pros and
cons. We found that font-based fingerprinting is one of the
most unique ways users are fingerprinted. We also found that
it doesn't affect most users' experience
myles: so pros and cons seem clear here
emilio: I agree with myles
leaverou: Lots of old sites rely on common fonts like Calibri or
Cambria installed
leaverou: also there's a perf impact of always downloading the font
since sites tend to use `local()`
Glenn: Are we getting ahead of the game between standards and impls
myles: The spec can't do much here
myles: We are a standardization group, we can't do more that saying
in the spec that should have privacy considerations
myles: but browsers like Safari can and have gone further
florian: So you mentioned that you investigated the amount of sites
florian: that broke or not
florian: If you're removing language support minority users can't
use the web
florian: also bandwidth may be a concern
florian: I don't care if sites are slightly slower for Californians
myles: Having philosophical discussions is not particularly useful
myles: we need a concrete proposal
myles: and there's nothing to resolve on until there's one
myles: The spec already says that a UA may or not scan all fonts in
the system
Received on Tuesday, 3 December 2019 23:17:04 UTC