W3C home > Mailing lists > Public > www-style@w3.org > October 2020

[CSSWG] Minutes Telecon 2020-10-07 [css-selectors] [scroll-animations] [css-fonts] [css-backgrounds] [css-box] [css-cascade] [CSSOM]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 8 Oct 2020 06:28:10 -0400
Message-ID: <CADhPm3t4VGk2He9gh=GfyD+wdGDHTKk0tyGKnVrnhtZNd8oOMA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:15 UTC