- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Nov 2021 19:38: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.
=========================================
Meeting Scheduling
------------------
- The meetings for next week and the last 2 weeks of December are
cancelled due to holidays.
- There is interest in doing an extended call on 8 December to make
it through more of the agenda+ topics. A decision will be made on
the mailing list.
CSS Fonts
---------
- In continuing to solve for issue #4497 (Limit local fonts to those
selected by users in browser settings (or other browser chrome)),
the group reviewed a proposed solution from Felipe
( https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-763459971
).
- The proposal doesn't specifically call out using a
locally-installed font which does have use cases. This could
also be a fingerprinting mechanism.
- There is concern on using a permission prompt to inform the
user since fingerprinting is complex to explain and there is
already user fatigue around permission prompts.
- RESOLVED: format() serializes with strings (Issue #6328: @font-face
src: url() format() keywords vs. strings ambiguous in
spec)
- RESOLVED: font/ MIME type registry manages valid values of format()
(Issue #6328)
CSS Cascade
-----------
- RESOLVED: Accept proposal [
https://github.com/w3c/csswg-drafts/commit/dfe47f62fe70c6f5d3958805d4bb318980b24cdb
]
(Issue #6776: When an import rule fails to load or has an
unsatisfied condition, does the layer still count?)
- RESOLVED: Republish css-cascade-5
CSS Values
----------
- RESOLVED: Accept edits, expand to allow aliased functions (Issue
#6193: define parse-time value aliasing)
- RESOLVED: Add this to the Value Definition Grammar (Issue #5728:
Clarify that function component values need to be
followed by parentheses)
CSS Position
------------
- RESOLVED: Semi-replaced elements stretch in both directions in
abspos (Issue #6789: Behaviour of semi-replaced elements)
Transforms & Backgrounds
------------------------
- The group was leaning toward resolving that background on root
elements are not affected by transforms for issue #6683 (
Transforms and backgrounds on root element). dbaron will look
into the effects of filters on root element before the group
resolves on it.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Nov/0009.html
Present:
Rachel Andrew
Adam Argyle
David Baron
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Peter Constable
Elika Etemad
Simon Fraser
Megan Gardner
Daniel Holbert
Richard Ishida
Brad Kemper
Jonathan Kew
Daniel Libby
Chris Lilley
Ting-Yu Lin
Peter Linss
Morgan Reschenberg
Jen Simmons
Miriam Suzanne
Lea Verou
Regrets:
Tab Atkins-Bittner
Chris Harrelson
Scribe: fantasai
Scribe's scribe: emilio
Meeting Scheduling
==================
astearns: Cancelled meeting next week and last 2 weeks of December
astearns: due to holidays
astearns: but we have a lot of Agenda+ items
astearns: so maybe want to add extra meeting time
astearns: Could add extra time in December, or in January
astearns: Please let me know if any preferences on this
astearns: or if there's a set of topics for a breakout session
astearns: So far, topics seem mostly mixed, but open to suggestions
fantasai: My suggestion would be to extend Dec 8th into a vF2F
fantasai: Well after Thanksgiving and well before Christmas, and
avoids topics dragging into January
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
astearns: Topic is about local fonts needed for i18n particularly
[side discussion about positioning of Agenda Item 9]
smfr: Myles isn't here, probably should be here also
astearns: Other browsers than Safari probably need to sign on for
whatever local font access we decide on here
chris: It would be good to get some movement on this.
chris: Felipe made a good suggestion, and thumbs up in thread
[Felipe's suggestion at
https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-763459971
]
chris: Richard confirmed he liked the suggestion
chris: Maybe we can resolve to accept the suggestion, and then work
out the details in the spec
chris: The general principle seems sound
astearns: Summary is having some sort of permission interface, where
if a web page tries to use a local font and browser notices
local font is in system, UI would come up
astearns: timed to make fingerprinting more difficult
astearns: allows user to enable font access
r12a: Then can have a checkbox for "don't ask me about this font
again"
jfkthame: Interested in Gecko
jfkthame: Doing some foundational work towards potentially
restricting font access
jfkthame: One aspect not directly talked about, seems there are
several senses in which a website could want to use a
locally-installed font
jfkthame: worth highlighting the distinction
jfkthame: might be font name is given in font-family property
jfkthame: so that specific font family is specifically requested, and
page would like to use, and might or might not be allowed
jfkthame: But what about font fallback? Character that is not in
other fonts
jfkthame: Would that trigger requests like this?
jfkthame: Should there be a user request for fallback, when the
character is not available in other fonts?
jfkthame: I think the fingerprinting implications are different
jfkthame: I think for fallback, I think it's particularly concerning
for minority languages
jfkthame: For such users, any font that supports the language would
be helpful
chris: For fallback case, script can know that fallback was used, but
doesn't know which one
chris: so imo shouldn't require a user permissions font
jfkthame: Well, you are exposing the fact that the user has *a* font
that supports these characters
smfr: In general, we don't believe permission prompts are useful
solution to this kind of problem
smfr: One reason is user fatigue; users don't read the dialog, just
want it out of the way
smfr: Then it's really impossible to explain to users what
fingerprinting means and implications
smfr: ....
smfr: Then users don't understand whether web page or browser is
showing the dialog
smfr: Long-term approach should be that system fonts have support for
these minority languages
smfr: so that we don't need to run into this problem in the first
place
<tantek> +1 smfr, permission prompts are not a reasonable answer to
this (users can't be expected to make informed consent)
chris: The page gets laid out without the font, the dialog box pops
up asking permission to allow this, so that next time come to
that site (per origin) not bothered by it
chris: so rapidly not going to run into this problem
chris: A font on system that covers the charset vs specific font that
gives the right design is different
chris: ....
r12a: There is somewhere a long post on one of these issues where I
addressed the question of system fonts being able to display
the text
r12a: there are certain scripts and orthographies where not only does
it not look good, but it actually causes problems in
representing semantics
r12a: Might end up with wrong kind of glyphs, doesn't look the way
you expect as a user of type script
r12a: Don't see any way to rely on system fonts here
r12a: Also people like font designers have a problem, they can't
check their fonts if they can't see them
<chris> suspect r12a is referring to this:
https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-594521142
<chris> with Western Syriac example
r12a: Noto fonts are not a panacea
r12a: They are often in need of significant repair to do the job
r12a: Sometimes missing for certain minority scripts
r12a: Not coverage of characters, sometimes not the right glyph shapes
r12a: A dialog box in front of the user is not great
r12a: But it's better than not being able to get the font that you
want
r12a: I couldn't think of any better solution to it
r12a: It will probably help if we have the ability to say "don't
remind me, about this particular font"
r12a: I don't think there's a good solution here
r12a: If you're creating web pages, you are checking your page using
localhost
r12a: and in that situation, there's not going to be any phishing
r12a: major pain in the butt if you can't spin up the page with the
font you'd like to see
r12a: So I'd like to argue that if you're working on localhost, then
that should not prevent you from seeing fonts
<chris> localhost is just one example of an origin
astearns: My current take is that we're not ready to resolve on
anything
astearns: but encouraged by the fact that Gecko is interested in
figuring out
astearns: Sounds to me that there are some valid concerns about
permission interfaces
astearns: but also valid concerns about not doing anything and just
relying on system fonts
astearns: so I hope that people engage on the issue, because this is
something that we need to solve
astearns: Thanks, r12a, for joining us
CSS Cascade
===========
When an import rule fails to load or has an unsatisfied condition,
does the layer still count?
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6776
miriam: A few questions in here
miriam: All related to establishing layers inside of an @import
statement.
miriam: One question is what to do if the import fails
miriam: Other question is what to do if the conditions of the import
don't match
miriam: Consensus in the thread was that we should conceptualize this
to "layer is wrapped around contents of the import, even if
empty due to failure, and condition is wrapped around the
whole thing"
miriam: We added language to spec to express it that way
miriam: Layer is still added to layer order if import fails
miriam: but not added if the conditions don't match
miriam: That matches the behavior of if you had import inside of
layer inside of condition
miriam: Wanted to check with WG if this is acceptable
jensimmons: Makes a lot of sense from authoring point of view
<fantasai> +1 from me
RESOLVED: Accept proposal
miriam: This allows us to republish
RESOLVED: Republish css-cascade-5
<chris> miriam: is the changes section up to date?
CSS Values
==========
define parse-time value aliasing
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6193
fantasai: Added value aliasing section to cascade-4/5
emilio: Weird that it is scoped to keywords
fantasai: We didn't see any examples of not keywords, but could
certainly reword to be more general
emilio: `-webkit-image-set()`-> `image-set()`
emilio: Same with a bunch of gradient functions
fantasai: So functions and keywords, anything else?
<emilio> I don't _think_ so of the top of my head
astearns: So proposed to take edits, with additional change to add
functions
fantasai: sgtm
emilio: sgtm
RESOLVED: Accept edits, expand to allow aliased functions
Clarify that function component values need to be followed by
parentheses
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5728
fantasai: So tab added bikeshed functionality in which he can link to
a function definition using `<ident()>`
fantasai: but this is not actually valid according to our value
definition grammar
<fantasai> <'property-name'>
<fantasai> <keyword>
fantasai: That has quoted property references and terminal kws (^)
fantasai: So should we add this to the value-definition grammar and
update all specs to use this convention?
fantasai: A subtle thing is that only terminals that represent a
function will use this
fantasai: Historically we haven't done this, e.g., `<url>`
fantasai: so the question is do we want to extend our syntax in this
way
chris: I would find this useful, have needed <foo> vs <foo()>
astearns: So proposal is to add <name()> to our grammar for specs
astearns: Will that require going back and fixing everything?
fantasai: I think it would be useful to make things consistent
fantasai: but I wouldn't do it for <url>
astearns: If not required, it's better; would prefer not to mess with
old things
astearns: Any other opinions?
RESOLVED: Add this to the Value Definition Grammar
CSS Position
============
Behaviour of semi-replaced elements
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6789
iank: After last week's meeting dholbert did an in-depth
investigation, which was great to see
iank: test page with a whole bunch of replaced elements, and looked
at behavior
iank: We both agreed that it's probably reasonable to stretch in both
directions for all semi-replaced elements
iank: There's no browser which does something consistently, so every
browser would need to change
iank: but this is a straightforward path forward
dholbert: Every form control is stretched in at least one browser
dholbert: but not every form control is shrunk in at least browser
iank: e.g. we stretch in block direction but not inline
iank: webkit and FF together have complete coverage of stretching in
inline direction
astearns: Change is to stretch in both directions in all browsers
eventually?
iank: Correct
astearns: Any other opinions?
fantasai: Tab and I are in favor of this
RESOLVED: Semi-replaced elements stretch in both directions in abspos
iank: We'll likely make this change in the next few months, and will
report back if any web-compat concerns
astearns: Thanks, dholbert, for your investigation
Transforms & Backgrounds
========================
Transforms and backgrounds on root element
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6683
dbaron: Obscure passage in the spec, wrote a test for it, and ended
up wondering if we really want spec to say this in the first
place
dbaron: [quotes spec] [Fixed backgrounds on the root element are
affected by any transform specified for that element. For all
other elements that are effected by a transform (i.e. have a
transform applied to them, or to any of their ancestor
elements), a value of fixed for the background-attachment
property is treated as if it had a value of scroll. The
computed value of background-attachment is not affected.]
dbaron: Basically, this is describing a special behavior for fixed
backgrounds on root element, saying that transforms apply to
that fixed background
dbaron: Interesting because normal rules for background on root
element say that backgrounds get propagated to canvas
dbaron: and backgrounds on canvas, nothing says anywhere that they
are affected by transforms
dbaron: so if you read between lines in spec, I think what it says is
that non-fixed background are not affected by transforms
dbaron: could probably make other arguments, though
dbaron: What I think the spec is saying is that fixed backgrounds are
affected by transforms, and scrolled backgrounds are not
affected by transforms
dbaron: What my tests found, is that in chromium do the exact opposite
dbaron: i.e. fixed background not affected, but scrolled backgrounds
are
dbaron: In Gecko neither is affected by transform
dbaron: and in WebKit both kinds are affected by transform
dbaron: So 4 possible behaviors
dbaron: and every browser fits into a different possible behavior
<dholbert> as a see-also, we have
https://bugzilla.mozilla.org/show_bug.cgi?id=1724471
filed on some WPT tests failing due to Gecko's behavior here
dbaron: It's not clear to me we want what the spec says
dbaron: I wanted to see if anyone has an opinion here
smfr: Don't have a clear memory about why spec is the way it is,
might have been ease of implementation
smfr: We do special thinks for fixed backgrounds
smfr: but I would expect that it would have been easiest to *not*
apply transforms for fixed backgrounds
smfr: so I'm pretty confused
dholbert: [...]
fantasai: So what do authors expect to happen here?
dbaron: part of what I was wondering
fantasai: so canvas is infinite...
smfr: Think about rotate(45deg); does the background rotate?
dbaron: Unsure anyone cares here, so maybe do the easy thing?
dbaron: so not apply transform
smfr: So if author wanted background to move around, they could put
it on body and prevent propagation with different style on the
root
smfr: and then transform the body
dbaron: Might not cover the same area though
smfr: What happens to gaps revealed by e.g. rotating 45deg?
smfr: Are they filled, or ...?
dbaron: WebKit has some bugs around that
astearns: Anyone looked to see if any bugs filed against engines on
this?
smfr: Don't recall any for WebKit
dbaron: I feel like this is a combination that nobody actually cares
about
astearns: So suggestion of never honoring transform, is that ok smfr?
smfr: My concern there is, naively, if root gets transformed, whether
background is transformed with it depends on details of impl
smfr: if we end up with behavior change, might force us to do
additional work to handle
smfr: I'm OK resolving background never gets transformed, and if
hard, we can revisit
astearns: So chrome would need to change also
dbaron: Haven't looked into what's needed for that, but I'm OK
looking into it
astearns: Proposed that we change spec to say that background on root
element are not affected by transforms
dbaron: I think current spec is unclear about scrolled backgrounds
dbaron: You have to infer based on propagation rules
smfr: We've talked about effects of filters on root element in the
past
smfr: Chris came up with a proposal for rendering model that allows
filters to affect root background
smfr: so maybe review that and see if any of it applies to transforms
dbaron: Ok, so let's come back to this later
astearns: So let's review filters and come back to this later
CSS Fonts Continued
===================
@font-face src: url() format() keywords vs. strings ambiguous in spec
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6328
chris: Grammar here is complicated due to allowing strings and
keywords
chris: but most compatible form is string
chris: So we should support string and serialize as string
astearns: Do we want to accept keywords as well?
fantasai: Let's split into 2 questions, first is resolving on
serializing as strings because they are the most
backwards-compatible syntax
astearns: does drott have any concerns?
...
astearns: most backwards-compat usually winning argument
RESOLVED: format() serializes with strings
jfkthame: What are we intending to do with font-technology(), will
that take keywords or strings, and will that be confusing?
chris: That will take keywords as currently specced. Though that can
change.
chris: There's no back-compat concern with technology()
astearns: Since we have back-compat issue with one, maybe all of them
should serialize as strings
jfkthame: I'm not sure what I favor
jfkthame: I recognize the back-compat issue
astearns: Let's take that as a separate issue
astearns: and resolve to use strings for format() and then find out
whether drott agrees, or whether we can do something more
complicated, and if string serialization format sticks can
decide on consistency for rest
astearns: Any other concerns about serializing format() with strings?
RESOLVED: format() serializes with strings
chris: There weren't font MIME types at IANA, so we faked it by
creating our own names
chris: Now there is a fonts/ registry for MIME types
chris: fantasai suggested that we just use that registry
chris: but the RFC says that it is informative, and css-fonts-3 is
normative
chris: I think we'd like to change that so that they are normative,
and we are informative, and they can handle registration of
new formats so we don't have to
astearns: So we would normatively refer to their spec?
chris: And then errata the RFC so that it no longer says our spec is
normative
astearns: ...
fantasai: Shouldn't have different keywords allowed between string or
keyword in format()
RESOLVED: font/ MIME type registry manages valid values of format()
PeterConstable: What's involved in getting IETF updated?
chris: I will contact the chair and ask if this is in scope of errata
or not
chris: Unsure if publish a new RFC or not
chris: If errata, then errata submission form
chris: If not then will need to spin up a very small wg to make the
change
chris: but anyway I'll deal with it
astearns: Last thing is whether we accept unquoted keywords
chris: Does any implementation currently accept keywords for format()?
jfkthame: IIRC webkit does, but haven't checked
chris: And do we want to continue to allow that and allow other
browsers to do so, or get them to fix that?
astearns: out of time, so let's leave issue open on this question and
ask for feedback
<chris> fair enough
astearns: Meet again in 2 weeks, please discuss whether to have a
long meeting on Dec 8th to get through the agenda
Received on Thursday, 18 November 2021 00:38:51 UTC