- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Dec 2019 20:01:08 -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.
=========================================
Summer 2020 Meeting
-------------------
- Dates will be finalized on the private list.
CSS UI L4
---------
- RESOLVED: Publish a new WD of CSS UI L4
CSS Fonts
---------
- The group discussed limiting the exposed fonts in order to limit
fingerprinting vectors (Issue #4497: Limit local fonts to those
selected by users in browser settings (or other browser chrome))
and was interested in creating possible spec text.
- Even though there are plenty of other vectors to fingerprint
users, a majority of the group felt that it was worth the
effort to chip away at the problem.
- There were different options as to what fonts to use; an
intersection of OS fonts, a union of them, or somewhere in
the middle where we accept that you'll still be able to know
basic information like OS from the font list.
- Though the spec shouldn't list exact fonts, there was a desire
to have an accompanying note-like document that does say
fonts which are known to conform to the spec text.
- In the current GitHub there is a proposed way to still allow
users to install and allow a font and that use case is
important to support as this is a common need for users that
consume content in a minority language.
- Though there's a desire to ensure this text strongly protects
users of browsers it may still need to be a SHOULD level
requirement as there are other use cases where
fingerprinting isn't a concern such as PDF renderers
CSS Lists
---------
- RESOLVED: Reverse previous blockification requirement and require
generating a block container (Issue #4448: How should
spaces be treated in markers?)
- RESOLVED: Use white-space:pre as the value in UA stylesheet with
text about possibly processing new lines (Issue #4448)
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Dec/0014.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Dave Cramer
Elika Eteman
Simon Fraser
Dael Jackson
Brian Kardell
Chris Lilley
Peter Linss
Stanton Marcum
Myles Maxfield
Devin Rousso
Christopher Schmitt
Pete Snyder
Jen Simmons
Alan Stearns
Lea Verou
Sean Voisen
Regrets:
François Remy
Scribe: dael
Year in Review
==============
astearns: I think we have enough to start
astearns: Any changes to the agenda?
Rossen: I wanted to add an item.
Rossen: I wanted to give a summary of the year we had.
Rossen: Here's some numbers
Rossen: We could resolve 176 items not counting the ones we
discussed without resolution
Rossen: Published 18 WDs, 9 CRs, 2 RECs. This is really amazing. I'm
inspired by everything we've done
<florian> yeah us !
Rossen: I get praise for the way the WG works and it's amazing.
We've done 10 REC this decade and 2 were this year. Inspired
by this year and looking forward to 2020
smfr: Do you have a decade summary?
Rossen: I couldn't get the decade for the WD and CR. /tr didn't go
back far enough
Rossen: It would be fun to do as a summary of the decade; especially
for those of you that have been here for the entire declare
2020 Summer Meeting
===================
astearns: Can we lock down dates
astearns: Two dates provided. One in July which was better for
spacing, June which was better for Mozilla
astearns: Does anyone from Google know if both dates are available?
astearns: Lacking that, are there Mozilla people that very much
prefer June dates?
<dbaron> btw, did Alan's view of the thread include the October
messages:
https://www.w3.org/mid/c8aababf-85c6-6406-8a32-e5c2a1e77784@inkedblade.net
and https://www.w3.org/mid/4e5672f3-475e-42ce-93ed-be4dff028160@www.fastmail.com
?
jensimmons: Can you mention the dates again?
astearns: I believe June 22-25 or...not sure July dates
plinss: I have week of 20-24 July
plinss: And the following week of August
dbaron: Thread was 22-24 June or 20-22 July
astearns: Right. And dbaron you thought June was easier for Mozilla
folks?
dbaron: Yes but heycam was okay either way and has longest trip.
astearns: Lacking strong opinions on the call let's go to the list.
CSS UI L4 WD
============
florian: Been under low pace maintenance, but we're 2 years from
last WD. One section with significant changes is on
appearance property. Thanks to zcorpan it's more fleshed
out and feels like could be impl
florian: Noticed how out of date it is I thought we should publish
astearns: Objections to new WD of CSSUI L4?
RESOLVED: Publish a new WD of CSSUI L4
astearns: Since this is a regular WD and I assume all changes came
from resolutions I think you could have published without
resolution
florian: I think some changes didn't have a formal resolution
fantasai: You can publish with editorial
astearns: I have not checked the draft but an up to date changes
section would be useful
florian: I'll look
CSS Fonts
=========
Limit local fonts to those selected by users in browser settings (or
other browser chrome)
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4497
pes: Right now font fingerprinting by most measurements is highest
entropy. Would like to address and solve
pes: Needs standards level because will require some degree of PR or
author notification or browser changes so everyone moves in
tandem.
pes: Couple proposals but in general need to limit types of fonts
websites can tickle are those that are useful for users
pes: Most recent proposal is let's figure out default fonts for OSs,
union those, websites can access those. If users want to opt in
other fonts you should be able to do those with a prompt from
the browser
astearns: One things about privacy discussions and opting in to
exposing information is the concern about messaging to the
user what they are doing. Is there possible a way to opt
in to that giving a good story to the user what they're
doing?
pes: Two thoughts; if users are doing this they already know
somewhat what they want. Conveying some of the functionality
without the meaning is easy. If there's the desire to convey
why I think that's easy to describe. I could put up text.
People usually follow defaults. From examples in GitHub is
moderately expert users and that's something two steps out of
the mean
pes: I think it falls nicely where browsers are doing things users
don't expect and taking it from default path is a win and
allowing users intentionally installing fonts is doable
myles: A couple points. 1) Fingerprinting based on set of available
fonts is real bad and we philosophically should try to solve.
myles: 2) There's a problem here issue is trying to address which
isn't stated yet. Safari already disallows user installed
fonts so we're similar to proposal but don't ask users to
allow. There's a problem with that where for some lesser used
scripts there may be no system font that can support so can
have unreadable pages
myles: This proposal has affordances to solve that where for those
scripts users can opt in. That's good. But there's a cost
which is throwing additional prompts to user they may not
understand and adding friction at OS install time is
something the entire company tries to minimize
myles: Realistically us adding a screen at OS install time is
difficult to do and generally not something we're comfortable
with
astearns: Clarification on scripts not supported- is Safari not
rendering some web pages it might otherwise be able to
with the script?
myles: Yes. Logic is it's a better situation for them to have to use
web fonts because it's better to require that then for every
user to install a font with a name because less websites then
web users
jensimmons: I was never aware Safari doesn't allow user installed
fonts. And I've never heard a web designer talk about
that. I agree it's complicated for users to understand a
browser setting. That's the kind of thing a webdev can't
count on. It may be something to think about but doesn't
seem core to solving
jensimmons: Looking at last part of GH issues I see intersection of
fonts vs union of fonts. Union is when you have all the
fonts on both even if they're only on some OS. Some
people are saying to do intersection where Arial is on
so it's allowed but Avenir is only on Mac so not
allowed. Intersection would be a massive problem. I
don't think it's a problem to limit to what's shipped
in OSs
jensimmons: If we try to limit to intersection it will break
millions of websites. I don't think people are counting
on some people might have fancypants font. But they are
counting on some people have Avenir but others Roboto
pes: Clarifying the proposal: Union of all fonts shipped by default
by all OSs that an be reasonably compiled. And the ones fed to
the website are intersection of installed and system fonts.
That is one option on Android, another on OSX, etc.
pes: Proposal isn't to say at install time let these fonts be
accessed. Proposal is for small set of users who expect these
fonts to be available because region of website allow user to
go into advanced and have a drop down of additional fonts.
Expectation is relatively few people do this, but communities
that needs this already install extra font so this additional
step isn't infeasible
chris: I wanted to say contrary to jensimmons not seeing it [user
installed fonts for uncommon languages] done, I have seen
this on some sites, particularly when Indian was worse. South
Indian it's common to install locally used fonts. It could be
there's a pack that installs a bunch of fonts. I don't want
to break web experience for those that have been using it
successfully
astearns: Is there a way to survey scripts and say these aren't by
default but everybody in that region installs these fonts
<jensimmons> +1
chris: It would be a valuable addition
myles: One other small things. Mechanically ability to discern
between fonts is not a public API on OS. I would love to hear
if any browser programmers wanted this exposed; I'd love to
know that
<Rossen> I'm not convinced that waiting for exposing such API on the
OS platform is worth it
<pes> https://github.com/Valve/fingerprintjs2/blob/master/fingerprint2.js#L557
<— example of fingerprinting via fonts
florian: I don't see TabAtkins on and I'd like to bring up a point
from him. this seems less drastic then others discussed so
down side not that bad. If we do the intersection of what's
installed it has a fair bit of variability. Besides font
fingerprint there are other means. The question to ask is
does it actually help. If we don't reduce it enough then we
haven't achieved anything even though we decreased it
florian: Downside isn't that bad if we include the language specific
common fonts, but there still is some cost. Are we paying
it for something or do we not reduce your uniqueness enough
<jensimmons> There are many other ways of fingerprinting, but many
of us out here are knocking them out one by one. I
believe we should also do our best to close such
security flaws. (in response to florian's comment)
plinss: Let's not let hte perfect be the enemy of the good. There's
a lot of fingerprinting surface and we need to make small
steps in every regard. We have to take small steps where we
can and get a cumulative effect where we can
<pes> +1000 for what is being said right now.
<jensimmons> +1 from me as well
florian: TabAtkins point is he doesn't think we can ever get there
<astearns> yep, if it makes fingerprinting at all harder, it's
progress
plinss: If we never try we won't get there
myles: I don't doubt we can get there so we have one vote on either
side so worth discussing
dbaron: Two comments. myles asked about the API on Mac. it's not
something we planned to work on but if we do get to work on
this it would be useful. Lack might cause us to have to do a
work around. If it's exposed it would make this sort of
thing more practical. But we don't have a concrete plan to
use it
dbaron: Other thing is that there's been a bunch of discussion about
intersection and union of fonts across OSs. I'm not
convinced we want either. There's an argument that we want
to allow vary between OSs. There's a set of fingerprintable
information we can hope to obscure but there's bits of
entropy we can be okay giving up on and one of those is if a
user is on windows or mac.
dbaron: Either way of addressing it makes the solution worse.
Intersection limits designers, Union is a bunch of
fingerprinting exposed if users install fonts that are
default on a different OS.
<myles> dbaron++
pes: Point about fingerprinting nihilism. Ping and those in privacy
community are trying to address it in many ways. You chip away
as you can. Nature of problem means different wins benefit
different people are different times.
<myles> pes++
pes: Chipping off entropy bits is valuable. Different fingerprint
endpoints yield differently as well. So adding noise is an
option in some places, but fonts is not one of those places.
Figuring out how to reduce problem to a subset seems valuable
here. I think every time we take a slice of the problem we're
benefiting some people. We're not throwing coins in a well
<plinss> +1 to pes
fantasai: Two points. 1) If we're going to do this we should
document which fonts are allowed on which OSs so all
browsers can align with interop. If we're going to do this
we should start a registry of allowed fonts so authors and
browser vendors can figure it out
astearns: To that I think yes and no. There should be a rule for
what's in and maintain it, but have the list generated
from rules. If we do a union the set will only ever grow
fantasai: Rule in fonts spec, document of fonts that conform to the
rule. In an OS API is nice, but an author won't find it
easily
astearns: We aren't saying browsers restricted to this for all time,
we're saying here's the set we're aware of and here's the
rule to add a new font
myles: There's a bunch of websites that list the fonts. Do we need
to maintain if it's out there?
AmeliaBR: Not in reliable up to date fashion
myles: Will ours be?
dbaron: Need something that reflects worldwide usage. Some of that
will need to be us.
fantasai: I don't want it in fonts spec. A note or a W3C registry
that's easily maintained and doesn't need our intervention.
fantasai: 2) I want to emphasize we need to address impact on
minority language population and limiting to default fonts
won't cut it. Need to not harm those communities. You
can't use web fonts for things like this. Places with
minority language are also where downloads are slower and
more costly. need to make sure we address that head on
<jensimmons> +1 to everything fantasai just said. It would be
incredibly helpful to Authors to have such a list.
astearns: Other points on this topic?
pes: I'd like to know how Ping or I personally can be most useful to
make sure a solution gets into the next part of the spec and
get this solved
astearns: I think being active on GH issues that are open and
reviewing spec text is most helpful. Anyone else can chime
in?
<pes> i can promise to do that :)
fantasai: Are we resolving to do this and if yes exactly what. If
not, when do we follow up?
<dbaron> I think we're a decent distance away from converging on a
particular thing to add to the spec.
astearns: I was thinking to draft a solution based on GH thread. I'm
not hearing objections to trying to solve this. Coming up
with something to put into Fonts spec to limit fonts
available to web pages
AmeliaBR: Have text saying browsers may limit what fonts are
exposed. Is the agreement at this point to increase the
normative standard of that or be more specific about which
you might want to limit or be specific about which fonts
are safe?
AmeliaBR: Have it defined that if a font meets these criteria the
browser should make it available and may block access to
all others
astearns: It would be yes on your first two. Increase to a must
requirements and more concretely define the restriction.
But we're not trying to come up with list of web safe
fonts, we're defining what browser should make available
in terms of locally installed fonts.
astearns: Registry we have won't have all safe, but might be
available
AmeliaBR: Using safe from privacy PoV not author guarantee
astearns: Yeah. Like dbaron said in IRC we don't have a thing for
the spec yet. Just an intent to solve the problem
<gsnedders> do some OSes still conditionally install fonts based on
locale? what should the behaviour be then?
myles: One point, I don't think can make a must because involves
non-CSS pieces of browser.
<fantasai> +1 to myles, this would have to be a SHOULD
astearns: Must would be font matching algorithm. Not about browser
that might make it less restrictive
fantasai: Should still be a should. There's CSS UAs that don't want
to limited in this way. Like a PDF renderer which is
trying to print local documents. This will have to be a
should.
fantasai: Browsers will probably follow because it makes sense to
them
chris: Agree it should be a should for that reason. They might have
to opt in but we shouldn't block it.
* fantasai notes that Ahem probably needs to be on the list
pes: In general a should doesn't mean too much when doing privacy
review. We're looking to see if a browser properly implements
will they be protected. Point taken where there are places
where privacy doesn't apply and those should be carefully
detailed out.
pes: The case discussed where needs to be a way to opt in is handled
in GH issue
pes: I've not written specs but I know in many places functionality
is described that hooks into browser chrome so might consider
examples like that
fantasai: I want to point out a couple things. One is we as a WG we
don't know all UAs that exist or will exist and we
shouldn't make a UA non-conformant just because satisfies
a non-browser use case.
fantasai: Technical definition of SHOULD is [reads]
<fantasai> RFC2119: 3. SHOULD This word, or the adjective
"RECOMMENDED", mean that there
<fantasai> may exist valid reasons in particular circumstances to
ignore a
<fantasai> particular item, but the full implications must be
understood and
<fantasai> carefully weighed before choosing a different course.
fantasai: I think that's appropriate in this case
<chris> +1 to the RFC2119 definition
astearns: I think we should go back to GH and hammer out exact
proposal and level of requirements. I think there's quite
a bit of work before there's something to put in spec, but
we should get to that. Maybe checkpoint in a month
<dbaron> "a month" is the face-to-face, btw
<myles> good idea, dbaron
AmeliaBR: Sample spec text drafts would be helpful so we can start
comparing
astearns: dbaron reminds me we have the F2F to hammer out the last
details and get it into spec
chris: Sounds good way forward.
chris: pes you should keep watching issue and we update EDs daily so
you can see evolution of text
astearns: Anything else on this?
astearns: Thanks everyone
CSS Lists
=========
How should spaces be treated in markers?
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4448
oriol: Revisiting a resolution we had. I said that browsers
seemingly do when you have an outside marker that's
blockified and we made it explicit in the resolution so that
if they don't have whitespace then trailing spaces are
reserved
<Rossen> we do the same in IE and EdgeHtml
oriol: I had been confused by internal terminology and in Chromium
they are inline blocks. Outside markers generate a block
container and that's what matters. If we want to reflect
reality maybe should weaken resolution. Say they should
generate block containers and then leave it to impl if it's
block or inline level
Rossen: This is same behavior we have in EdgeHTML so I support your
proposal
<fantasai> wfm
astearns: Proposal is modify previous resolution? I see point 3 in
previous resolution that outside marker box has display
value blockified.
oriol: It's generates block container not blockifies. It could be an
inline block containers.
fantasai: I think we might clarify outside display type is undefined?
<fantasai> https://drafts.csswg.org/css-text-4/#white-space-trim
might also be interesting
Rossen: Could be inline. Did that when we impl outside markers the
first time. In order to achieve good baseline alignment for
list items that best way to model this was to wrap the list
item markets in anon inline blocks with appropriate offset
and deal with them.
Rossen: Undefined or inline. Not sure if inline will make a
difference
fantasai: Markers have a particular interaction with positioning and
line positioned to. When we decide they might have their
own display:outside value. I'm happy to have it undefined.
fantasai: Haven't figured out the model
Rossen: I don't want display:undefined
fantasai: We can call it inline-block for now so gCS returns
consistently across UAs. Not sure if that matters
oriol: Firefox does blockify into a block box so it seems behavior
is different in impl
dbaron: I don't think difference is a big deal for us but should ask
Mats
<fantasai> I think the two options we have going forward is either
an outer display value of 'marker' or an outer display
value of 'inline' and a 'position' value of 'marker' ...
or something like that.
Rossen: Going back to the proposed resolution I think the
understanding is well defined
astearns: Proposal: An outside marker box does not have its display
value blockified, it generates a block container
astearns: Correct?
oriol: Should we cover what Firefox does?
oriol: You said it's not blockified, but in FF it is. Maybe should
say it may be blockified
astearns: Yes, sorry. Previous was it has its display value
blockified and we're not going to require that. Will
require it generates a block container.
<Rossen> sgtm
astearns: Then can figure out outside container later
astearns: Object to reverse previous blockification requirement and
require generating a block container
RESOLVED: Reverse previous blockification requirement and require
generating a block container
oriol: Whitespaces; want to preserve by default and resolved to do
this to assign whitespace value in user agent origin. Then
how to handle new lines. In SVG there way a value for this;
should we add to CSS or use White-space:pre
fantasai: We say the value is pre for now and UA may transform to
spaces and we can try and figure out what to do in the
future
astearns: Reasonable
<Rossen> wfm
astearns: Concerns about UA stylesheet uses pre as the value and let
browsers opt into processing new lines?
florian: Compat with browsers inside case? Or outside only?
oriol: Chromium outside markers get white-space:pre but inside
inherits. In legacy spaces were preserved. In FF if the
content property is normal then spaces are preserved like pre
but if you spec something other than normal it uses
whitespace inherited from list. It's probably compat because
Firefox and legacy chromium preserve
fantasai: We should reduce magic switching and make it a simple
control
florian: Would not necessarily be magic could have pseudo class, but
not convinced we need to
fantasai: No, let's keep it simple.
fantasai: Just make it pre. How many people are doing a custom
string? Almost nobody.
astearns: florian do you object?
florian: No, just wanted to get it out there
astearns: Objections to use pre as the value in UA stylesheet with
text about poss processing new lines?
RESOLVED: Use pre as the value in UA stylesheet with text about
possibly processing new lines
astearns: That's it for the year and the decade. Talk to you all
next year
fantasai: Can we get some FPWD published next year?
Rossen: We can and should
astearns: We've got next decade for that
Received on Thursday, 19 December 2019 01:01:41 UTC