- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Jun 2020 18:42:22 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Color Adjust
----------------
- There was proposal for simplifying the solution to issue #4178
(More granular overriding of forced colors mode than
per-element) by allowing system-colors to stay in place for
forced-color mode. However, one of the primary motivating cases
was to allow an arbitrary color. This case will be better
captured in github and discussion will continue there.
- RESOLVED: Have color scheme use the same <meta> scheme as theme
color. (Issue #3846: What happens with multiple <meta>s?)
- RESOLVED: Ask HTML to specify this and move out of CSS specs
(Issue #3846)
CSS Values
----------
- RESOLVED: Specify we use host document behavior for URL types in
attr() (Issue #5079: attr()'s url type seems wrong)
Media Queries
-------------
- RESOLVED: Do testing in this area and specify values for this case
(Issue #3800: Precisely define which media features an
undisplayed page has)
- In general the group liked the idea of returning default
defined data but webcompat needs to be maintained for
existing values.
- Future media queries should have defaults defined in the spec
to prevent issues in the future.
- RESOLVED: Remove at-risk on these [hover, any-hover, pointer, and
any-pointer] media features (Issue #1989: Interaction
media features (any-pointer, etc) still at risk?)
CSS Align
---------
- RESOLVED: Change the fallback value for space-around and
space-evenly to safe center (Issue #5088:
Content-distribution keywords that fall back to "center"
can't be made safe)
Selectors/CSS Values
--------------------
- Anyone with interest in security or attr() was asked to review and
help solve the security concerns raised in issue #5136 (Hide
"sensitive" attributes from CSS)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jun/0021.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Christian Biesinger
Mike Bremford
Oriol Brufau
Dave Cramer
Elika Etemad
Simon Fraser
Chris Harrelson
Daniel Hobert
Dael Jackson
Brain Kardell
Brad Kemper
Jonathan Kew
Ian Kilpatrick
Greta Krafsig
Rune Lillesveen
Chris Lilley (IRC Only)
Peter Linss
Alison Maher
Tess O'Connor
Jen Simmons
Alan Stearns
Lea Verou
Regrets:
Amelia Bellamy-Royds
Megan Gardner
Stanton Marcum
Miriam Suzanne
Scribe: dael
astearns: I think we have enough people to go
astearns: Order of business: We are going to have a joint meeting
with media working group on 14 July over video MQ features
astearns: If interested look at the note on the private list.
astearns: We're going to skip item 8 at Chris's recommendation.
astearns: Any other changes?
CSS Color Adjust
================
More granular overriding of forced colors mode than per-element
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4178
TabAtkins: Had a bunch of discussions. In certain cases authors
might want to override forced colors. Hopefully for
useful purposes such as when forced colors removes
necessary distinctions.
TabAtkins: Lots of discussion in thread and talk on F2F.
TabAtkins: fremy came up with an idea that I and fantasai like. If
people use system colors already just don't adjust them.
TabAtkins: If people use own random brand colors we overwrite. If
system colors used don't override even if forced color
would use different system colors.
TabAtkins: That way people can work in palette of system color but
direct how it looks when precision is necessary
TabAtkins: Color function also has a fallback mechanism if your
color space is not loaded or out of gamut.
TabAtkins: Should consider all color spaces unloaded in forced
colors. This lets you in non-forced colors paint but auto
say what fallback should be to system so you don't have
to design with system colors from the get go, but rely on
them when necessary
<florian> I like it. Well done fremy.
TabAtkins: When doing forced color leave system colors as is
regardless of system color. I think that solves it
without all the complication in past
Rossen: If I have a selector that's intended to change color of
border-left to non-system and forced color MQ matches how
would that work? @media forced-colors and match
prefers-color-scheme:dark so I want to give left-border my
dark blue color. How would it work?
TabAtkins: It would not.
Rossen: That's the primary use case. That's why we went down
!override path. If people are using system colors that's a
no op. If I said canvas fine. I can fix from a system but
not my own.
TabAtkins: It's not a no op because you can choose a color that's
not forced color. You can invoke marked color for
example. But you can't choose arbitrary color
Rossen: I think that's main motivational case
TabAtkins: It wasn't clear in thread arbitrary color was required.
In that case let's shelve this because the suggestion is
not possible.
<fantasai> That was not in any of the examples that melanierichards
raised
Rossen: Sorry it wasn't clear in thread, example could be clearer.
Fine to move on. Thank you for introducing it.
astearns: Let's make sure that example is encoded in a recent
comment. We'll likely come back
What happens with multiple <meta>s?
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3846
TabAtkins: Have the <meta> name and equals color scheme. Page
declares color on root element in way that comes in early
on page without requiring load css file. Might have
noticeable delay while page has not great canvas
background
TabAtkins: What happens if you spec same meta multiple times
TabAtkins: Several options. Reviewing HTML where you can have
several <meta>s all possible patterns exist. No
consistency. Things that are most similar, especially
theme-color <meta> which adjusts color of UI on page has
a specific behavior. First one that's parse-able wins and
if things are dynamically updated we re-run selection algo
TabAtkins: Fine for me.
TabAtkins: Does mean you don't have standard css fallback behavior
where can specify newer color and a fallback. Trade off
is you don't have to wait several packets to make sure
there's no additional <meta>s.
TabAtkins: Trade-off is fine since this is designed to give a value
as soon as possible
<dbaron> You can do the CSS-like fallback behavior by doing it in
the reverse order, too, no?
TabAtkins: Suggest we unify with theme-color meta. First things that
parses in the document with the restrictions listed by
Dominic.
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/3846#issuecomment-577337007
<TabAtkins> last option
Rossen: You said...we prefer the first one if it parses and
subsequent do not trigger restyle. What about nested
documents? In an iframe do I need to know there was already
match in primary doc?
TabAtkins: In terms of selecting a <meta> no communication. Applying
theme colors I don't know if we inherit into other docs
but if we do it works same as CSS. iframe selection own
meta because separate document
Rossen: Okay. If based on main there was potentially some info leaked
Rossen: Second question, have you considered opposite where we treat
it more like style and continue to consider everything?
What's main reason to reject it?
TabAtkins: Not crazy to consider. Reason to reject is, first, nice
to reuse similar modal. Second, the purpose of this
feature is get a value as fast as possible without making
browser delay to get more stuff. Being able to see first
and know it's the color to display I think is valuable
because no need to run trade offs about should I delay
paint while I wait to see if there's overrides.
TabAtkins: If you need multiple values due to new color schemes you
can just put a style tag in. It's a bit more verbose and
depending on your exact csp set up it may not work
TabAtkins: Addressing exact use case I think we lean toward take
first one that matches over benefit of fallback
Rossen: Okay. It is more restrictive model. I can't tell if it will
be final, but we can also if there are compelling cases to
allow subsequent <meta>s we can scale out model.
TabAtkins: Ultimately, though we talked about more color schemes
like sepia, I don't think there's any plans now to add
them. At least for next several years we're stuck with 2
so we don't have to worry about it. If it changes
calculus is different
astearns: dbaron pointed out if you're concerned about not parsing
you can put in reverse order to get fallback order
TabAtkins: Yeah. Yeah. You can do that. It does have same fallback
as CSS. dbaron is right. You put 2 <meta>s, first has new
syntax. Modern browsers find the first and use, old can't
parse, skip, and then use old. Have fallback, opposite
order of CSS
dbaron: Only weird is it's non-conformant
TabAtkins: In older browser, yeah
dbaron: Conformance requirement says it's not allowed to have
multiple. Maybe that's not great
TabAtkins: Agree, value to loosen it.
astearns: Any more comments?
astearns: Comment from Rune about moving it to HTML spec
TabAtkins: Agree. Need to settle and than tell HTML what to put in.
TabAtkins: I think it's abstract theme-color algorithm and have it
apply to both
astearns: Proposal: Have color scheme use the same meta scheme as
theme color.
astearns: Perhaps changing conformance requirement to both.
Recommend this as change to HTML spec
TabAtkins: Yep.
astearns: Objections to the scheme?
RESOLVED: Have color scheme use the same <meta> scheme as theme
color.
astearns: Objections to have this spec entirely in HTML an not our
specs?
RESOLVED: Ask HTML to specify this and move out of CSS specs
<dbaron> it might still be worth linking to the HTML spec to point
it out
CSS Values
==========
attr()'s url type seems wrong
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/5079
TabAtkins: Anne reviewed changes to attr() and noticed I have it
defined as attr() with URL type it takes string and spans
into URL function using css resolution rules for relative
urls
TabAtkins: Unfortunate because if have a href and pull it out it
resolves different from if click a and if you pull it
into css.
TabAtkins: They're not concordant resolution mechanism
TabAtkins: Suggestion is when using url-type we should use same
resolution rules as HTML uses.
TabAtkins: Reasonable to me. Exact working needs to be worked out
with Anne.
TabAtkins: As long as no one objects to that I'm happy to have it
work
fantasai: Update L3 as well?
TabAtkins: Only to whatever version the new advanced attr() function
is in
fantasai: Right, yeah
fantasai: Also values 4 hasn't been published in long time
TabAtkins: Sure. Separate issue.
astearns: Other comments?
<fantasai> +1 to the change
<faceless2> +1 from me, it's a good idea.
<bkardell> +1
astearns: Proposal: When attr() function is using URL type use same
resolution rules as HTML
fantasai: I think take resolution rules for the element from which
took attr()
TabAtkins: Yes, but only one language that defines which is XML
fantasai: If you apply CSS to a generic XML document, then HTML
doesn't define that
TabAtkins: Yeah, generic HTML doc doesn't define either
fantasai: You should write spec so it works for whatever languages
TabAtkins: As long as not a huge pain of cross doc references sure.
If it is a pain I'll write it how it's readable. We'll
figure out details. Want to make sure general plan is
right
astearns: Objections to specify we use host document behavior for
URL types in attr()
RESOLVED: Specify we use host document behavior for URL types in
attr()
Media Queries
=============
Precisely define which media features an undisplayed page has
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3800
florian: Display:none iframes can run scripts. If you run script you
can run MQs. Spec doesn't say what to do in that case
florian: There are sites that depend on this and try to run it.
Gecko is trying to find answers that don't make web crash
florian: Do we want to define this? Yes if web depends on it. What's
best way to find answer? Is it in L4 or L5?
<fantasai> Put it in L5, if it stabilizes and we want to pull it
down to L4 later we can do that
florian: Is emilio on?
florian: emilio suggested dummy values that don't depend on
anything. That way you can answer something
florian: Appears Chrome answers non-dummy for some MQ. Resolution,
for example, they answer for the doc hosting the iframe
florian: Proper answer is write tests
astearns: Is that bad? Should iframes have access to that when
they're display:none?
TabAtkins: I suspect there might be issues or data structures not
created. Other than that I agree pulling information from
same screen as document is fine. If iframe is displayed
it's on the same screen and gets answers
florian: But if it isn't displayed it doesn't need to know. So maybe
a privacy leak. If you display it sure you get it.
TabAtkins: I don't think we should conclude display:none is info
boundary
florian: If there's a use case to expose the parent sure. If it's
just because why not we could also not expose why not.
rune: We're not exposing from parent document. I think we get it
from frame structure. We're getting it for frame that's
display:none because we have objects for the frame. It's not
exactly parent document but directly via the frame
florian: Asking in a different way, is there a valid use for a
display:none iframe to know screen resolution?
rune: No
TabAtkins: Really? I'd think it running scripts in preparing to
display might want information
rune: True
TabAtkins: If it's primarily display:none sure, but you can't tell
Rossen: Is there a use case here or just about giving correct
defaults
florian: Mozilla had crash bugs. They were responding with wrong
thing where frames caused crashes
Rossen: For me similar to how we resolved to answer gCS values for
docs in that category. Seems we should stick to whatever
defaults should be there and make them stable
florian: Dummy value like emilio suggested?
<emilio> gCS is defined to return an empty declaration, with
length=0
Rossen: Yeah. Exactly way did it for gCS. Return a bunch of default
initial values. Should match that. If we don't we're opening
inconsistency between
smfr: Some compat risk. Prefer we test existing browsers and than
decide if we want to change from current impl. Will be hard
because we don't know what a display:none iframe is doing now
TabAtkins: I thought some compat against 0 by 0 but it's against
only false devices. 0x0 fixes one of emilio bugs
<emilio> Right, 0x0 is alright. Its "never match" what breaks sites
bkardell: smfr said my point. I'm surprised by this. Seems
unfortunate that it's surprising and I'd like to know why
it is and if necessary to be surprising. But we can't
break anything so understanding today is good first step
fantasai: emilio said 0x0 is alright and never matches breaking site
astearns: For this case that we know of. So we do need a fix for
that.
astearns: Good to have interop.
<TabAtkins> my proposed resolution: Attempt to fix MQs in
non-displayed iframes to specific values, to be
determined by testing.
astearns: I think we need testing before we decide what's possible
in terms of interop values here
florian: I suggest for MQ specified but not impl I just pick a
default so that when they're implemented we don't get
complicated interop. For those that exist we have to test
florian: That's tricky b/c I don't have a display:P3 device
TabAtkins: Someone does. You can ask.
TabAtkins: I suggest we add default value to MQ blocks and make that
required in bikeshed
florian: Yep
<Rossen> +1 to mq default values
astearns: Objections to do testing in this area and specify values
for this case
RESOLVED: Do testing in this area and specify values for this case
* fantasai suggests speccing whatever emilio suggests, and adjusting
based on Web-compat
Interaction media features (any-pointer, etc) still at risk?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1989
florian: Limited tests, but they are implemented in multiple
browsers. I suspect we should remove at-risk label since
people mis-read it as "please don't use" If it's impl
at-risk is no longer justified
astearns: Objections to remove at-risk on these media features
RESOLVED: Remove at-risk on these media features
CSS Align
=========
Content-distribution keywords that fall back to "center" can't be
made safe
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5088
fantasai: Some content distribution keywords like space-around that
fall back to center. Fallback we chose was center not safe
center and author isn't expecting overflow but it happens
if screen is narrow
fantasai: Proposal is switch to safe center for these keywords
instead of true center
astearns: Mats had concern in issue
fantasai: Yes. The current spec if you don't say safe or unsafe
browser should find closest scroll container and make sure
it doesn't overflow. Not sure it's consistently impl or
expected for these keywords. No one is asking for center,
it's just a fallback. Making sure we don't trigger
overflow in impl without magic. It's more expected for
authors to overflow to the end side when too much content.
smfr: Sounds like there's a layout dependency on scrolling?
fantasai: On scroll container
smfr: If something overflows you might have different behavior?
fantasai: Default is if you say align-self:center and your
grandparent is a scroll container and your item is bigger
than viewport it shouldn't overflow left edge. Need to
figure out alignment container and left edge of screen
different and know you can't overflow more than that. No
dependency on scroll position
smfr: Say another element later in flow causes scroll container to
become a scroll container. Want to make sure it's not circular
fantasai: No
TabAtkins: The scroll containers are dependent on layout
iank: Does this introduce a double layout pass with arbitrary scroll
container on arbitrarily large entities
TabAtkins: Yes. Safe behavior is only in parent sub-tree. This can
go up to find a sub-tree
iank: A little concerned about that
fantasai: That's separate, though. The proposal here is not to
depend on that and switch to centering without being
dependent on scroll container
fantasai: Currently defined to use scroll container dependent
behavior. Not sure how impl
iank: I don't think anyone impl
fantasai: Which means a lot of sites will put it in un-scrollable
area. Proposal is to switch to safe center which doesn't
depend on scrolling
TabAtkins: I know of a site currently effected by this
dholbert: People can't choose between [safe and unsafe]. If we
address next issue sites could say safe or unsafe and
choose fallback so possible not introduce compat issues
fantasai: If authors want center they can request. This is content
distribution where they expect multi space elements.
Single item or too many items is not what author focuses on
TabAtkins: Even if we re-add ability to specify a fallback it
doesn't change the default unspecified being defined here
dholbert: There might be sites that have layout where settled for
true center as fallback and this changes the layout on
them. In some cases change for better. Could conceivably
break layout
fantasai: Unlikely to break. Majority of cases is where unreadable
content is now readable. This is all about cases with
overflow and where author didn't plan
<emilio> it may be content that was intended to be unreadable though
iank: webdev often put things in unscrollable and shift into view
<emilio> right, what iank is saying :)
fantasai: This is not that case. I'm not saying they don't do that,
I'm saying they don't do it with space-around
astearns: And only difference between center and safe center is when
content is in unscrollable
dholbert: It's just when stuff overflows
<dholbert> e.g. 50px tall flex container, 100px tall flex item
<dholbert> (far from the edges of the scrollport)
astearns: I share Mats' concern that changing this which something
that's been shipping for a while is bad. I like that it's
fixing unreachable content. I'm not that happy making the
change
TabAtkins: We have an example of a site that's broken and will be
fixed. We only have theory of sites that will be broken
by change
fantasai: It's unlikely to break things but not making this change
effects the user more substantially than something being
slightly crooked
dholbert: Could fix by option of author specifying safe
fantasai: No one thinks about overflow when specifying space-around.
We have a fallback that happens to be center. If you
switch between space-between and space-around you suddenly
get unreachable content and you won't see that unless you
have content that happens to overflow. If you see that you
would fix it so you're not testing for it. User seeing the
content should be number 1 priority
astearns: And changing the fallback doesn't lock us from being able
to specify
fantasai: If we want an opt-in to overflow we can do that. Default
should be make it readable
<florian> +1
astearns: Should we resolve to change? Anyone unhappy to resolve now?
dholbert: I'm a little uneasy without knowing what to do on next
issue. Not sure why we can't tell sites to use safe keyword
fantasai: Because sites won't fix and one of our principles is avoid
data loss
astearns: We can't assume people will fix things they might not even
notice. It does seem like a better default.
astearns: I expect there may be compat problems since it's been
shipping for a while. It's an improvement but we may be
stuck
fantasai: We have compat problems with current behavior but only
frustrated users have noticed
astearns: dholbert would you rather take discussion to github issue?
dholbert: I'm okay moving forward. I think we'll discover more
compat or angry authors. It's hypothetical
astearns: Proposal: Change the fallback value for space-around and
space-evenly to safe center
astearns: Objections?
RESOLVED: Change the fallback value for space-around and
space-evenly to safe center
Allowing fallback alignments without breaking shorthands
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1002
<fantasai> https://github.com/w3c/csswg-drafts/issues/1002#issuecomment-319634895
fantasai: Looks like there's a resolution and needs edits.
TabAtkins: Let's go fix it fantasai :)
astearns: So this is resolved to do something about previous
resolution.
TabAtkins: Yeah.
Selectors/CSS Values
====================
Hide "sensitive" attributes from CSS
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5136
TabAtkins: Review of this discovered it allows for a known attack.
Makes it a whole lot easier to do background URLs. Rather
than partly loading and building letter by letter you can
instead grab the whole thing and ship it out.
TabAtkins: Some bits can be crafted with spec language, but some
can't. Some attributes will host data and can be
extracted. This is a problem
TabAtkins: I'd like to be able to code this attributes. But I don't
want to expose arbitrary data attributes with sensitive
information.
TabAtkins: Some suggestions in the thread about how to solve. Mark
some as safe and unsafe and a mechanism for JS to swap
between categories so you can use some attributes safely.
TabAtkins: I don't know final solution. It's a blocker for attr
because makes attack easier.
TabAtkins: Anyone interested in security concerns please review and
help me figure out a solution that's not cumbersome or
weird.
astearns: Any initial thoughts?
faceless2: This is used already in lots of print engines. It would
be a shame to break everything by blocking href and other
common
TabAtkins: We should set up spec so that UA in secure spaces can
ignore this. I'm concerned about things like css
injection attacks. Print should be fine and will make
sure I allow it
astearns: Thanks for intro, we'll get back to this
astearns: That's time, thank you and we'll talk next week
Received on Wednesday, 24 June 2020 22:43:14 UTC