- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Feb 2020 19:51:13 -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.
=========================================
CSS Fonts
---------
- The group is very interested in addressing the privacy/
fingerprinting concern raised in issue #4497 (Limit local fonts
to those selected by users in browser settings (or other browser
chrome)), however agreed it will need to be a SHOULD
requirements since CSS-PDF renderers have a valid use case to
not conform to this requirement, and because it will take time
and experience to work out the requirements more exactly.
- An additional complication will be a need to define what the
system OS fonts are; each OS has this data available in a
different way.
- ChrisL volunteered to work with pes in drafting up initial
proposed text to add to the Fonts spec. The group will review
this text on the next call after the F2F.
CSS Text
--------
- RESOLVED: Disallow before hyphen in normal and strict. Allow break
between ID and hyphen in loose. This means Kanji+Hyphen
breaks; and Alphabetic+Hyphen doesn't break, unless
word-break:break-all makes Alphabetic behave like ID.
(Issue #4419: Line breaking for ambiguous characters;
e.g., U+2010, U+2013)
CSS Text Decor
--------------
- RESOLVED: Fully specify an algorithm that specifies ink skipping
that references other specifications that isn't
codepoint-by-codepoint (Issue #4276: Clarifying
skip-ink:auto behavior in relation to CJK text)
- jfkthame will write up the spec text for group review.
CSS Ruby
--------
- RESOLVED: ruby-overhang auto | none on ruby container (Issue
#4492: Ruby overhang control)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/galicia-2020
Present:
Rachel Andrew, Fronteers
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Amelia Bellamy-Royds, Invited Expert
Christian Biesinger, Google
Mike Bremford, BFO
Oriol Brufau, Igalia
Tantek Çelik, Mozilla
Emilio Cobos, Mozilla
Elika Etemad, Invited Expert
Javier Fernandez, Igalia
Koji Ishii, Google
Brian Kardell, Igalia and OpenJSF
Jonathan Kew, Mozilla
Ian Kilpatrick, Google
Chris Lilley, W3C
Stanton Marcum, Amazon
Myles Maxfield, apple
Cameron McCormack, Mozilla
Tess O'Connor, apple
Manuel Rego, Igalia
François REMY, Invited Expert
Florian Rivoal, Invited Expert
Hiroshi Sakakibara, BPS
Jen Simmons, Mozilla
Alan Stearns, Adobe
Lea Verou, Invited Expert
Scribe: faceless
CSS Fonts
=========
Limiting local fonts
--------------------
github: https://github.com/w3c/csswg-drafts/issues/4497
pes: This is talking about font fingerprinting by identifying the
computer based on which fonts are installed on the computer
pes: One suggestion is to list a document which describes a list of
specific fonts
myles: I asked about what pete wanted to discuss that wasn't on a
previous call
<astearns> (from the last discussion: 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: One of the questions was to what extent this would be
allowed vs recommended vs mandatory. I am comfortable with
recommended not sure about mandatory partly because we don't
know exactly what we're trying to do. open questions.
dbaron: I think we should allow this
myles: AT already does
dbaron: [...] to recommend this, and work on adding detail to the
recommendation. When we're comfortable with the level of
detail there, we can mandate this, but there are lots of
open questions
dbaron: eg. effects on linguistic minorities, across OSes, etc.
myles: If we don't make mandatory but do make recommended, would be
good to hear from all present if we should change behavior
pes: webkit is even safer than this, webkit won't load some fonts
off disk
dbaron: Maybe Jonathon can speak more authoritatively on this but we
support a larger number of platforms and on some of those
this might be more difficult to do on some platforms than
others
fantasai: I wanted to say there are classes of user agents where
this makes no sense. eg css-pdf renderers, which need to
access all fonts on the system
chrisL: localhost could have access to all of them
chrisL: css to pdf renderers have the ability to opt in to lists of
fonts per site, which makes it more possible to opt out (as
in opt out of fonts per domain)
<chris> although I wasn't just speaking of css to pdf renderers
myles: As an engineer I am always thinking about how we can test
this, but if there's going to be no changes on the file
system this will be untestable
pes: Initial proposal was all this should be dealt with by the
browser opting in
pes: If the takeaway is that the idea is useful but nothing is
required at this point, I don't think that's any change from
the status quo
fantasai: A SHOULD requirement is not a no-op
fantasi: It recommends action and it may be appropriate in this case.
myles: But if no-one acts on that recommendation what's the point of
it?
fantasai: User agents don't always act on hard recommendations
either.
<chris> 3. SHOULD This word, or the adjective "RECOMMENDED", mean
that there may exist valid reasons in particular
circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed before
choosing a different course.
<fantasai> https://tools.ietf.org/html/rfc2119
fantasai: Should means if you have a good reason not to do it, you
don't have to do it. But you need a good reason.
<TabAtkins> If necessary I can state this at some point, but I
believe Chrome's position is that we extremely want to
stop fingerprinting as an identification vector, but I
don't think that designing a solution in a committee
with this skill set is appropriate. (There are groups in
W3C (or elsewhere?) that are more appropriate and
contain people with the right set of skills.)
myles: To paraphrase fantasai: we can put a should and say all
browsers should do this, or we can make a partition and say
some browsers must, some must not.
myles: Pete said first option was a thumbs down
pes: If there's an option that is available to the user to access
all local fonts, that's ok
fantasai: I would imagine you would object to this being turned on
by default. But css-pdf renderers would have to turn this
on by default
pes: Doesn't have to be that way. If you're saving documents off
disk, for example, it could be off
chrisL: Could you explain the harm of the status quo where someone
on their own disk converts a file locally
pes: That's not what I mean
florian: So if we don't mean everyone has to do this, then lets not
say everyone
<fantasai> you MUST NOT use any fonts that are not either part of
the OS-default set or downloaded by the page itself
pes: It seems like this must not be a new idea - there are cases
where apps using HTML renderers have one set of rules, browsers
have others
heycam: We do
[but we don't like it]
<heycam> different conformance classes for selectors (fast profile)
florian: SHOULD means you have to do it unless there is a good
reason, but good reasons do exist and if you have them you
won't be non-conformant. You won't be arrested for not
doing it under SHOULD, but neither would you be under MUST
pes: Who's planning on doing what?
pes: It's pretty important we get this sorted out so we can get the
cross-browser expectations to users
TabAtkins: Especially given recent information fingerprinting in
side channels is a very tricky thing to do and we don't
have the expertise in this committee so I'd object to
putting a "must" on this as I don't think we have the
ability to do it ourselves
TabAtkins: While it's very important and needs doing, I don't want
to put anything binding on this committee
<astearns> and a 'should' allows all non-Chrome browsers to do the
thing and eventually make it more likely for them to bend
<tantek> note that "print formatters" are also "normal browsers" in
Print Preview mode
<florian> +1 to tantek
florian: We could put a note on this clarifying the intent to
explain why a should recommendation is there and who should
follow it
pes: Surely we do have the expertise
TabAtkins: I'm talking specifically about the CSSWG - the goal of
reducing fingerprinting is 100% our goal, but Chrome
doesn't want to bind themselves to a MUST resolution
pes: If you aren't the people to ask, who is?
<tantek> we really need to capture as much as we can in the issue,
and then reach out more broadly than the WG
TabAtkins: We have engineers who are working on this and have the
expertise on this, but none of this in this group have
the expertise
<tantek> sounds like this discussion is going in circles
hober: You have co-chairs of ping and the privacy cg in this room,
and Pete is not coming to us as an individual - this is a
concern from a number of people in this area. As a member
consortium it's the responsibility of this group that we have
people who can speak on these issues. So it's disheartening
to hear you don't want to consider this because we don't have
the expertise. Part of our role is to make sure the right
people are here.
TabAtkins: Yes I understand but this is the only privacy issues on
this point, it's not appropriate to invite the security
team to be here
TabAtkins: I'm not the right person, none of here are.
<TabAtkins> I think the PING/etc are the right venues for this
discussion, not the CSSWG.
<hober> TabAtkins, PING came to us with this!
<TabAtkins> This needs to be "privacy teams, with a font-related
engineer on call", not "a bunch of layout/etc engineers,
with a privacy engineer on call"
<TabAtkins> hober, Sure, and I'm saying that looking to this group
for binding resolutions on this topic isn't appropriate.
We own a spec with a feature that will be impacted; that
doesn't mean we should be designing the change, just
ensuring that it's integrated and well-explained when
it's finished.
* tantek reviews https://drafts.csswg.org/css-fonts/#priv-sec
<tantek> LOL: one-line S&P section in css-fonts 4: "The system-ui
keyword exposes the operating system’s default system UI
font to fingerprinting mechanisms."
<myles> tantek, I don't think I wrote that
<tantek> presumably we are talking about more than just system fonts
rossen: [calls order]
dbaron: Pete asked who are the right people. I think sort of a weird
question, given the response we're trying for. I think we
are the right people, but the misunderstanding that leads
Pete to ask this question is that it's not a short process
dbaron: We're trying to make a substantial change to the way this
works on the web platform. It's a process that requires
proposal, iteration, requirements
dbaron: [is more emphatic]
dbaron: We're trying to do this thing that requires iteration and
refinement of a proposal, and what we're saying is "yes,
we're accepting that this is the next stage of the process
and it's worth pursuing"
dbaron: but Pete is saying that's not the right thing - we need to
have a solution now. But we haven't had the conversation
that we need to have first. So we're basically saying yes to
it, but we have to begin the process
dbaron: I think that disconnect is why we're stuck
pes: With respect this was filed in June. There has not been
counter-proposal since then
pes: This is the #1 privacy issues on the web
rossen: We understand and we recognize the urgency but the reality
is there is a backlog
rossen: The fact it was filed a while back doesn't mean it's not
important to us
<TabAtkins> See, for example, how we were just spitballing about how
to design a font list and how to segregate it. We don't
have the expertise to do that; we can't get "close
enough". It has to be done *right*, and we're not the
group to do that.
pes: I want to know what the next steps are. If there's a process,
what is it, what is the timeline?
rossen: One of the proposals is to resolve with accepting this as a
SHOULD statement.
astearns: The spec has this currently as a MAY?
<chris> the current "MAY" has a lot less detail
myles: Yes, what Pete is aiming for is different
rossen: Can we take the resolution now that changing the current
definition to a SHOULD and live with that?
myles: Not unless someone can state what the SHOULD should say.
<tantek> agreed I want to see the full statement here in the minutes
florian: [agrees with myles]
<tantek> +1 myles
florian: You asked about next steps, the relevant user agents will
attempt to do it once the SHOULD has been framed properly
florian: After that, once the user-agents implement, we'll get
feedback and see what to do then
florian: Maybe we will find a line to draw to make a distinction,
i.e. user agents loading from the file system. but we don't
have that information now
chrisL: Pete if you're happy to make a first draft of the SHOULD
recommendation I'm very happy to work with you on this
pes: Happy to, but is there a rough timeline, and also the current
proposal points to a list maintained elsewhere. Is that the way
we want to keep things?
rossen: ok first issue. Do we want to stick with a list that is
maintained elsewhere
dbaron: A list of what?
TabAtkins: local fonts that are allowed
florian: The current spec is a list of things which are ok, - fonts
florain: I think we should write the list down, put it wherever,
once we have figured it out we can worry about where to put
it later
<heycam> +1 don't think where the list lives is the first thing to
worry about here
jkew: It's not clear whether this group maintaining a list is the
right approach or whether we should look into platform APIs
exist to determine which fonts are platform installed vs user
installed.
jkew: It seems like maintaining a list is a never-ending nightmare.
Maybe OS vendors should maintain the list? I'm not sure it's
realistic that we maintain it.
florian: No macOS API will give you that list. We should start with
a list and once we've written it, we can debate the proposal
rossen: Let's try to find something actionable
pes: I understand the reticence against a list and wanting something
easier to maintain.
dbaron: To respond to jkew and pes - list is maybe too specific a
term. We should be describing what we want to do and on each
platform there may be a different approach - an API, a list,
it's the intent that matters.
dbaron: The main thing is that we try this and see what works.
<tantek> +1 dbaron
dbaron: I don't think we know what the best thing to do is yet. We
can't specify this with the right level of detail on each
platform, we need to allow for feedback from each platform
to find the best solution
<pes> what is the road to get to the right answer then?
<tantek> pes, where's the proposal? can you link it?
<tantek> start with that
<pes> this is not a new issue / problem. An outcome that is “vendors
will look into it”, this is not progress
<pes> [tantek : initial issue / concern
https://github.com/w3c/csswg-drafts/issues/4055,
follow up proposal: https://github.com/w3c/csswg-drafts/issues/4497]
<astearns> pes this not a new issue/problem, but it is a new
solution. Looking into things is progress set against the
status quo
<tantek> pes, I think we're at the point where we need sample spec
text proposed in the issue. Just reviewed the proposal bits
and looks a bit scattered TBH
<tantek> pes, I'm not disagreeing with the issue. I read through
#4497 and the proposal there is more of an outline of
desired outcome
<pes> tantek: this might be closer to what you’re looking for
https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-565832611
<tantek> pes, that's a very good summary start. Now, where in the
spec would you put that, and can you reword it procedurally
as a set of steps that browser should/must follow?
<pes> tantek: on it :)
<tantek> pes, related, you may be interested in contributing to
https://github.com/w3c/csswg-drafts/issues/4697
myles: First, responding to florian: feels florian was assuming that
there was a single set of fonts common to everyone. We don't
do that - we have different sets for different parts of the
world.
myles: So even just for us, we can't have a single list that is
uniform.
myles: so we certainly can't across all OSes
florian: I was saying the current proposal specifies a single list,
but that's probably not ideal. But that's our start point
as it's in the spec.
myles: There is no list for our platforms about what the currently
available fonts are - we use an API.
rossen: Next steps. Pete is going to take a stab at moving the
current statement from a MAY to a more strict version of
SHOULD
rossen: and the technical recommendations of how to reference those
fonts, dbaron said this well - referring to this as a list
is not the full picture. But it is a start
rossen: Once we have the actual proposal we can try to narrow down
the technical solution
rossen: Anything else?
rossen: Pete, we're not trying to sandbag this - it's a normal
process. We are interested in this and that might not be
clear. Bear with us and once you have the actionable
definition we'll go from there
rossen: I suggest we end this and move on and will come back to it
once Pete has acted? On the next call?
pes: When is that?
rossen: Probably two weeks
rossen: Thanks for your engagement
<dbaron> The calls are Wednesdays at 9am California time / noon
Boston time / etc.
CSS Text Decor
==============
Clarifying skip-ink:auto behavior in relation to CJK text
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4276
jkew: The issue is about text-decoration-skip-ink, browser have
chosen generally not to apply this to CJK text because in
practice it clashes with most of the glyphs and looks terrible.
jkew: What troubles me is that the webkit/chrome have chosen to skip
this for a particular set of glyphs, but there's a disconnect
as to which glyphs are skipped. In particular Blink has chosen
to skip a number of punctuation characters
jkew: I was hoping that the spec could pin this down to work on a
sequence of script characters, so that punctuation surrounded
by CJK is CJK.
jkew: I'd like to settle on what we do in Firefox, which is better.
At the moment the spec doesn't define it
myles: Consistency is good but what the motivation? bug reports?
jkew: I'm sure we did have reports
myles: When you started implementing? Or was it issues around the
specific characters?
jkew: Initially we simply implemented and found the same issues in
CJK as everyone else
myles: In the absence of specific bug reports and users are not
complaining, maybe we should leave it as it is?
jensimmons: Can we perhaps specify it and see what comes from that?
jensimmons: Is the desire of one browser to not put in the effort a
reason to not spec interop. If interop on this is ideal,
we can spec it and then each browser can make decisions
about prioritization.
koji: I'm generally with myles on this. We had reports that our
slashes looked quite bad. When looking at gecko they don't
look bad
koji: So I believe we should add slashes to the list. So this is a
heuristic. It's not testable. But I understand that if gecko
gets reports that says the inconsistency is troubling then
this is an issue
florian: The spec is very vague, it says you can skip but not why.
Even if we don't go all the way to defining a list, we may
want to clarify the intent of this. That will not help with
the immediate concern about interop, but it will help for
anyone trying to understand or implement this
myles: I can add some text about that
dbaron: I think the situation today is if we don't define things,
everyone will just copy what Chrome does. So if what Chrome
does is right, let's put that in the spec as we're going to
copy it anyway. If not, put in the spec what is right.
myles: I'm not keen on that idea
TabAtkins: If we do whatever Chrome does, it should be an choice
made because Chrome is doing the right thing. I want
something written down because it will be a compat issue
myles: If no-one has bug reports, it's not a compat issue yet. Maybe
we wait until the first report
TabAtkins: We have enough issues to know that's not the best approach
dbaron: We've found that compat constraints get stricter over time.
The longer things are out on the web, they require interop
and expect it to get better over time. So if we find things
that aren't we should fix that early
dbaron: With the lack of bug reports, we have a cultural bias -
filing them requires that you speak English and this is not
the sort of bug report that English speakers will file
<tantek> ^^^ great FAQ answer for "Did you get a bug report?"
myles: I'm not going to push back on this. I would prefer that the
approach taken is that text describing this is a reference to
another spec, not a list of characters.
koji: I'm fine to have some text added that allows the UA to have
some heuristics. Our bug report was opposite. We had strong
opinions. People said "don't just disable skipping because
slashes look bad"
myles: How would you formulate that in a spec? a list that need to
be skipped and the rest are undefined? something else?
koji: Not strong on specifics, but if we got reports on a specific
code point we could add that, but leave others undefined.
rossen: Who's going to write this up?
myles: I volunteer jkew
rossen: Next action, jkew to modify the spec which - as myles
suggests, references unicode - with a suggested approach
that allows flexibility.
ACTION: jkew add specifics into ink-skipping details TBD. And that
it's done by reference.
ACTION: jkew fully specify an algorithm that specifies ink skipping
that references other specifications that isn't
codepoint-by-codepoint
RESOLVED: Fully specify an algorithm that specifies ink skipping
that references other specifications that isn't
codepoint-by-codepoint
fantasai: Who's doing this?
rossen: jkew
CSS Ruby
========
Ruby overhang control
---------------------
github: https://github.com/w3c/csswg-drafts/issues/4492
stantonm: I'll introduce this
stantonm: Bit of background - in Japanese text, in normal text all
the characters are solid text - there is no space between
the characters. Ruby allows this to change - if the ruby
is longer than the base text, it can push spaces between
the text.
stantonm: We've had feedback from authors that they don't always
want to allow for this overhang. The overhang can cause
confusion. We had feedback from JL task force and from
younger users
stantonm: Proposal is to add a new property to disallow overhang.
Default we be auto which is the current behavior. New
value would be none which would disallow overhang outside
the containing box?
myles: Question - which element do you apply this property to?
stantonm: You could apply to document root but the one it would take
effect on is the ruby tag
myles: The proposal give the value a length?
stantonm: The initial proposal was to be a bit more firm in the
value of the value of overhang JLREQ and JIS recommend a
value of 1, but none of the browsers actually do this
stantonm: The suggestion of auto was to allow more flexibility
myles: A length seems too fine grained. florian suggests auto vs
none, I agree. Second best option maybe large/small. Third
best is multiple of font-size. All better than a length
stantonm: Auto and none fits the use cases we see from authors
fantasai: Agreed with myles on auto vs none. Because the property
is inherited, lengths would resolve against the root
element's font-size which is less helpful
florian: We may well have different approaches later, maybe clarify
this or add more values later but for now, auto
rossen: So we are comfortable with auto and not-auto? any
objections? None? Resolved.
RESOLVED: ruby-overhang auto | none on ruby container
CSS Text
========
Scribe: emilio
Line breaking for ambiguous characters; e.g., U+2010, U+2013
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4419
koji: The current CSS spec says that if the language is Japanese and
line-break: normal there should be a break opportunity before
U+2010 and U+2013
koji: It can break strangely for English words within Japanese text
koji: Gecko fixed it by not breaking if the previous character is a
Latin character
koji: but I want to fix this in the spec
koji: and make sure all browsers agree.
fantasai: We got together yesterday and concluded in all languages
you want to disallow breaks before hyphens in normal
breaking mode but japanese wants to allow it in loose mode
<fantasai> https://github.com/w3c/csswg-drafts/issues/4419#issuecomment-577700150
fantasai: so word-break: break-all would allow between the Latin
letter and the hyphen
fantasai: so that's the solution outlined in the last comment (above)
myles: Are we going to contact ICU and CLDR?
koji: If we agree I'll do
florian: I support this
Rossen: Objections?
RESOLVED: Adopt the suggestion in
https://github.com/w3c/csswg-drafts/issues/4419#issuecomment-577700150
RESOLVED: Disallow before hyphen in normal and strict. Allow break
between ID and hyphen in loose. This means Kanji+Hyphen
breaks; and Alphabetic+Hyphen doesn't break, unless
word-break: break-all makes Alphabetic behave like ID.
Received on Thursday, 20 February 2020 00:52:00 UTC