- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 8 Oct 2020 06:28:10 -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.
=========================================
Scheduling
----------
- The group will not have its regular call on the 21st of October
due to other TPAC calls. If anyone thinks the 14th or 28th
should also be cancelled please reach out on the private list.
Selectors
---------
- In order to make a decision on :blank (Issue #1967) more research
is necessary on if :empty can ignore whitespace. chrishtr will
help fantasai in getting a sample of pages to investigate if
sites using whitespace in :empty are relying on the current
behavior.
Scroll Animations
-----------------
- There was wide interest in improving the interaction between
scroll animations and prefers-reduced-motion (Issue #5321: TAG
feedback: interaction with prefers reduced motion). There were
some potential solutions that came out of the conversation:
- Have scroll animations move from their start state to their
end state without the animation in the middle, perhaps with
additional author controls to define some intermediate states
- Allow browsers to remove most scroll animations and rely on
!important for authors to still have their animation when it
was required.
- Don't trigger the animation immediately. Instead, suspend the
animation until the scroll action finishes, interpolate what
state the animation should be in at that point in the
scroll, and then display that state.
- There is a need to experiment with the approaches to see which of
them gives the best results. The Github issue will stay open for
further conversation around experiments.
CSS Fonts
---------
- RESOLVED: Add superscript and subscript descriptors using
'normal', percentages, and 'from-font' values (Issue
#5518: @font-face overrides for superscript/subscript
metrics)
CSS Pseudo
----------
- RESOLVED: Add target-text pseudo element (Issue #5522: Add a
highlight pseudo-element for scroll-to-text)
CSS Backgrounds/CSS Box
-----------------------
- RESOLVED: Add these terms [rectangular edges vs edges that have
had their corners shaped] but bikeshed names in GH issue
(Issue #5132: How to refer to the corner-shaped padding/
border/content edges)
CSS Cascade & CSSOM
-------------------
- RESOLVED: For aliased properties, the general rule is both sides
of the alias get new values as defined (Issue #4839:
Issues with legacy name alias)
===== FULL MINTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Oct/0000.html
Present:
Rossen Atanassov
Tab Atkins-Bittner
Hui Jing Chen
Daniel Clark
Elika Etemad
Brandon Ferrua
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Daniel Libby
Peter Linss
Alison Maher
Cameron McCormick
Myles Maxfield
Florian Rivoal
Devin Rousso
Jen Simmons
Miriam Suzanne
Greg Whitworth
Regrets:
Mike Bremford
Tantek Çelik
Chris Lilley
Lea Verou
Scribe: dael
Scheduling
==========
astearns: Let's get going
astearns: Does anyone have any changes to the agenda they would like?
astearns: I have a couple housekeeping items
astearns: TPAC is coming up. Please tag issues for the longer
meetings
astearns: I've added all the meetings and joint meetings to our
calendar. I'll also remind on the private list
astearns: Assuming we won't have meeting on the 21st but I'm
guessing we could on 14th and 28th unless somebody objects
astearns: If you think that we should drop more meetings than 21st
please start a thread on the private list
CSS Fonts
=========
@font-face overrides for superscript/subscript metrics
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5518
fantasai: Is myles on?
fantasai: Not useful without myles
Selectors
=========
Decide on :blank
----------------
github: https://github.com/w3c/csswg-drafts/issues/1967
fantasai: Previous discussion wanted to see if :empty can ignore
whitespace. Currently if you have any whitespace it's not
considered empty. Believed that was super confusing
because usually whitespace goes away. Collected compat and
lots of websites use :empty
fantasai: But no one did a random sample to see if anyone was using
:empty in a way that specifically expects whitespace to
not match empty
fantasai: My take is more investigation on web compat would be good.
Don't know if anyone else has opinions
astearns: chrishtr you commented?
chrishtr: Data we have so far is whitespace appears on 2% of page
loads. Without a bunch more work we wouldn't be able to
confidently change
fantasai: I didn't have the data. Is any way to create a random
sample of some pages with the data and I can do a human
look?
chrishtr: It's http archive which you can query. Have you used that?
fantasai: No
chrishtr: I'll point you to it offline
chrishtr: I don't have other context on this so I don't know how
critical it is and if it's fine to wait.
fantasai: I don't think it's urgent
astearns: Next step is analyze data?
fantasai: Yep
Scroll Animations
=================
TAG feedback: interaction with prefers reduced motion
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5321
Rossen: aboxhall was part of the larger TAG review and has captured
thoughts. aboxhall if you want to summarize outstanding
issues with this it would be great
aboxhall: I don't have a solution. Problem is we're looking at the
scroll animations proposal and it seemed to me that maybe
we can do better in this case then requiring authors to
take a specific action to support prefers-reduced-motion
given that most of the use cases for scroll animations
seem like they fall into bucket of things that will
trigger vestibular disorders and potentially problematic
aboxhall: In the issue the last comment I left tried to get into
that. I linked to blog post on webkit which listed those
potential triggers. Parallax and zoom use cases are
explicitly called out. Plane shifting in the blog post is
implied as scroll triggered
aboxhall: Seemed strong overlap between use cases and triggers.
Seems unsatisfying to leave it to authors to not harm
users in this case
smfr: Are there other cases where UA overrides author specified
animations when prefers-reduced-motion is in effect?
aboxhall: Don't believe so, but doesn't mean we shouldn't.
aboxhall: In issue Florian drew parallels with forced-colors where
UA overrides author's colors. There are escape hatches to
let author react. (
https://github.com/w3c/csswg-drafts/issues/5321#issuecomment-659185761
)
aboxhall: In that case Florian said we could use similar approach.
My hesitation with that is I don't think users will get an
extra switch any time soon. If someone checks the
prefers-reduced-motion switch...it's not for us to say if
it's just your opinion or because animations will trigger
migraines.
aboxhall: Given only one switch how can we react to that switch?
aboxhall: Potentially do we add...I don't know enough about
technologies to speculate the way forward
florian: I'm hearing what you're saying
florian: Wondering if you turn them off entirely you'd have problem
with state where animation in early and end are different.
Instead of turning off it can be step wise with one step
from start to end so initial and final is right but you
don't get the movement
florian: If one initial and final state is enough or we need a way
to declare multiple midpoints, I don't know
florian: Something like this allowing a snapping change instead of
moving change might work
aboxhall: Fantastic idea to begin experiments with.
Rossen: Just to make sure when we talk about animations here it's
CSS only or Web Animations?
aboxhall: scroll-linked animations
aboxhall: Just because it seemed like the use cases for that had
such a strong overlap with the potentially triggering
animations
aboxhall: Worth exploring how to more deeply embed that preference
into animation APIs
aboxhall: To start scroll-linked animations and florian's suggestion
florian: The overlap is there but not all scroll animation are pure
decoration. Maybe comics or long form articles. If it
doesn't move you don't understand what it's telling you.
Being able to reach end maybe with multi step is needed
Nicole: On mobile animations are meaningful to find drawers and
navigation. Shame to lose semantic animations that provide
that meaning.
fantasai: I wanted to mention we have 2 levels of author rules.
Normal and !important. If this is controllable with CSS
property it's possible we could auto override and we could
only do that for non-important rules. If an author thinks
it's important they can flag. Only helps to extent it's
expressible in CSS declarations but we can distinguish
between things that need to exist and nice to have
aboxhall: That's good, yeah
astearns: Hearing a lot of interest in solving this problem of
scroll animation when prefers-reduced-motion preference. I
don't hear a full idea of what we should be doing
florian: Not fully, but I propose when this preference is on, the
easing function of the animation is transformed to
step-wise and have an open issue if it's a single step
between start and end or if there's a control about how
many steps and where
astearns: Seems start to end step is easy to specify
fantasai: Scrolling...there's the time during active scroll and when
you have stopped scrolling. When you scroll halfway
through what happens? Might not want just start and end
because in middle you have to pick. Might suspend
animation, find interpolation point when scrolling stops,
and show that
fantasai: Similar to how we snap after you let go of scroll
controls. We step-wise animation to that interpolated
position after the scroll but not during
florian: Interesting
jcraig: We did a ton of research years ago when shipped
prefers-reduced-motion.
jcraig: On Android and iOS you can flip to scroll. We found a number
of users with the trigger sensitivity would page at a time.
Scroll and release but stop the finger for the after effect.
jcraig: Another result is the difference between animations that
happen based on user trigger vs those that follow
unexpectedly. We found a number of users if they're doing
page in and out prefer to keep that. Made that a separate
control in iOS. User can anticipate there will be motion and
it doesn't bother as strongly as when not expected
jcraig: A lot of contextual information. Reason we didn't do it
automatically is the contextual understanding
jcraig: Open to explore ideas to allow authors to mark up animation
as decorative vs. essential. Haven't found an appropriate
way to shut off animations automatically (without risking
breaking understandability and context) which is why it's in
prefers rather than force
<aboxhall> Anecdote: a friend of mine with a TBI said a lot of her
therapy was around "strategically shutting her eyes" in
cases like James was just talking about
florian: This is probably a topic where we won't finalize without
experiment. Both mine and fantasai's suggestions are
interesting. Probably need demos to see if people react
well to that
astearns: Can or should this be applied automatically or is this
author advice we give?
fantasai: Definitely give author advice. Maybe additional controls.
But definitely if you don't need a scroll animation when
prefers-reduced-motion is on don't do it
astearns: Anything else to discuss or leave to experimentation?
florian: Experiments and further thought is necessary but is anyone
signing up to do them?
florian: Just because TAG raised the issue doesn't mean we expect
TAG to experiment
Rossen: Certainly not
astearns: Lacking volunteers maybe the issue hangs until someone has
time to experiment?
astearns: Only forcing function is if and when scroll animations
needs those issues to close for progress
florian: We've have TAG people from MS, Google, and from Apple
discuss it today, and the same companies have editors on
this spec. Maybe they can find internal resources?
jcraig: One more thing from initial prefers-reduced-motion
discussion is we left it open to expand later. May be
extreme but I'll mention it. Text is left at reduce but
expandable so could be specific triggers we avoid
jcraig: Original proposal was prefers-reduced-motion: no-parallax
and get it very specific. aboxhall linked to original issue
jcraig: It could be reduce which is vague or more specific values if
necessary.
jcraig: I'll try and dig up old issue
astearns: Can you open separate issue since that's about MQ and I'd
like to keep this scoped to web animations
jcraig: Sure. Appropriate to mention in the issue
astearns: Sure
jcraig: I think we decided didn't need it until there's a use case
and this might be the use case
astearns: Okay, fine to just mention. If we do want to add values to
the MQ I'd prefer to break it out so we don't have a giant
issue
CSS Fonts
=========
@font-face overrides for superscript/subscript metrics
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5518
fantasai: There's a proposal to add super and subscript overrides
like ascending and descending overrides. That's the
proposal, was some confusion. Maybe that's resolved from
the list
myles: I wrote a long essay, but summary is probably it's a thumbs
up.
florian: I would be in favor. Wondering if we need to allow-list one
by one all vertical metrics of fonts or is there a clear
way to subset which metrics should be overridable? All
vertical things seem plausible in this model. Block
direction
myles: To get a cart blanche solution someone needs to list metrics
fantasai: We pick the ones authors would like to override for some
reason. It's not all. Let's do one by one.
florian: And model can scale so fine.
myles: Another thing koji mentioned worth discussion
myles: If we allow css authors to override, currently fonts have
values but browsers don't use them. Should we add for these
descriptors a new value to say use what's in the font?
fantasai: Makes sense to me
astearns: If you know what's in the font, why not repeat the value?
fantasai: I think you want it to be trust the font. If you change
font it's still correct.
astearns: I was thinking just for ease of impl
heycam: Wondering if these overrides would work if font-face
declaration has a local font in source. Especially if this
is from fonts keyword which is relying on locally installed
fonts. Gets different results in different pages
myles: I have had an external request from outside big tech who
thinks it's important for local fonts to work
fantasai: If author put local font using that is fine. These are not
things that will be make or break on well designed webpage.
myles: As for the different on different browsers that's what we
have today so not worse
heycam: Okay, although typing in numbers might be much more different
myles: Someone uses it on their browser, it's good, and then breaks
on other browsers
heycam: Yes, if they're using it at source level
myles: No strong opinion, will defer if you think it's important
heycam: Don't feel strong, wanted to mention
fantasai: We can disallow later if broken. Should bias toward
allowing since if you're specify that level it'll work well
florian: You said you wanted to allow browser to delegate to a font
library not in browser. How does that pay in here?
myles: Coretext exposes this information
florian: Okay
astearns: I think I'm hearing probably consensus for adding super
and subscript descriptors using percent and from-font
values
astearns: Is this what we're agreeing on?
florian: Think so
astearns: Also normal as a value
astearns: That's the proposal. Objections?
RESOLVED: Add superscript and subscript descriptors using 'normal',
percentages, and 'from-font' values
CSS Pseudo
==========
Add a highlight pseudo-element for scroll-to-text
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5522
chrishtr: Discussed other use cases. This is specifically text
fragment feature. Verified exact chrome behavior. Page
loads, scrolls, then highlights. When you click highlight
dismisses. Proposal is new pseudo-element to color
highlight for the site
chrishtr: Suggested target-text name from fantasai which is
analogous to target pseudo class which lets you style
anchor in URL
chrishtr: Same way text fragments extend fragment concept this is
related so good name.
<TabAtkins> +1 to name suggestion
florian: You said the highlight is shown until click. When it is
dismissed is it instant?
chrishtr: Yes
florian: So no fading so don't have to worry
chrishtr: Yes, investigated and it's instant
astearns: Proposal: Add a target-text pseudo element with behavior
as described in the issue
fantasai: Wouldn't over-prescribe behavior but have it things you
specify are honored and rest match UA
chrishtr: Saying we don't have to restrict like we did for spelling?
fantasai: Example if UA has a fade-out on the color styling
shouldn't make it go away, just fade out your color. Or
some other effect makes it so you're able to style CSS
fantasai: [missed]
florian: Valid but applies to all highlight pseudos. As a mechanism
if UA wants to fade go ahead on any of them
fantasai: Like UA might fade ::selection and that's fine
heycam: Might be a little strange target styles remain and it's
still in the URL
fantasai: If UA wants to continue highlighting that's okay.
Controlling that is different project. For :target author
has added but in this case browser is injecting
heycam: Okay, agree with that
astearns: Any concerns about adding target-text pseudo?
astearns: Prop: Add target-text pseudo element
RESOLVED: Add target-text pseudo element
CSS Backgrounds/CSS Box
=======================
How to refer to the corner-shaped padding/border/content edges
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5132
florian: A little while back, I believe in context of layout
containment, I needed to refer to border edge with its
rounded corners if they're rounded or with any future
shaping. Couldn't figure out if border edge implied the
shaping or if you need something else
florian: Backgrounds 4 suggests it is themselves shaped but other
specs say it's a rectangle. Worth having two terms for the
shaped and unshaped so can be specific. Keep the existing
term 'edge' so if it doesn't matter don't have to be
specific
florian: I think helpful because specs which have taken time to say
with the rounded corners would have to expand if we added
another edge.
florian: Proposal is shaped edge and unshaped edge definition maybe
in Box 4
smfr: Prefer to avoid confusion with other properties that use shape
florian: Sure. Not attached to the adjective. Just want terms to
refer to either
smfr: Rounded?
florian: Rounded is what we have now. If we do bezeled or notched
they're not rounded but affect the corners
Rossen: Can we refer to unshaped corner as bounds? border-bounds,
content-bounds which is the rectangle?
astearns: Padding border content edge bounds?
fantasai: A bit confusing with terms for fragmented boxes, though
Rossen: Too many terms :)
Rossen: I should be applying padding bounds.
florian: Not attached to particular adjective but I think it should
be adjective on 'edge'. We mention edge all over the place
and sometimes mean with and somethings without. Adding an
adjective to edge is easier because then we can amend
existing text instead of review all specs and making sure
not wrong one
florian: Overall hearing support for idea but not for the bikeshed
color so should we go back to GH or twitter and ask for
ideas?
astearns: Don't know if this is useful on twitter since it's a spec
term
florian: True
Rossen: I think letting more people chime in on GH is worthwhile
astearns: Proposal: Add these terms but bikeshed names in GH issue
astearns: Any concerns about adding? Objections?
fantasai: Good as long as florian mentions base term is same
RESOLVED: Add these terms but bikeshed names in GH issue
CSS Cascade & CSSOM
===================
Issues with legacy name alias
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/4839#issuecomment-700430018
fantasai: Issue is that we have legacy name aliases. Just name
changes. Question raised about if you add new values to
the new property does old property get those new values?
fantasai: Mainly use these for WK prefix but a couple others we did
an alias
fantasai: Question to WG is do we define the value space is
identical or freeze the value-space to what's needed for
compat?
<heycam> +1 to keeping the value spaces the same. I don't think
there's much benefit to preventing the new values from
being visible in the old property name.
<miriam> +1
TabAtkins: I agree in general with zcorpan where trying to freeze
makes it separate properties so sounds like effort with
no reason. Keep strict alias
astearns: Arguments against keeping same?
florian: Have a weak argument
smfr: Sort of depends on compat. I'm sure in WK there are both
implemented. If we decide a prefix which is aliased and it
should be there's compat risk because prefix doesn't support
new. Need compat research
florian: If we decide this and freeze now no risk. Risk is we fail
to incentive migration. Doesn't feel strong for legacy
names where we felt needed to be in spec. For ones we want
to fade away useful to freeze but those we've enshrined in
the spec we've decided we have to have and might as well
keep
smfr: We might need exceptions for properties where we have
divergence
fantasai: If substantially different we use a different mechanism
florian: If we find one we can always call it out
jensimmons: Responding to florian I don't think it's important to
motivate authors because they are motivated. Vendor
prefixes are gone in their minds and the ones out there
are on un-maintained sites.
jensimmons: More importantly I don't know if in every case old code
7 years ago can alias to new updated spec because too
much has changed
florian: I don't think this is should we alias everything. But where
we have aliased does a new value become available on
legacy. I think the answer is yes.
astearns: Proposal: For aliased properties both sides of the alias
get new values as defined in general rule
RESOLVED: For aliased properties both sides of the alias get new
values as defined as a general rule
Received on Thursday, 8 October 2020 10:28:58 UTC