W3C home > Mailing lists > Public > www-style@w3.org > March 2021

[CSSWG] Minutes Telecon 2021-03-17 [css-cascade-5] [css-sizing-3] [css-fonts-5] [css-variables] [css-color-4] [css-contain-2]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 18 Mar 2021 19:07:36 -0400
Message-ID: <CADhPm3uBtwUd08nEL+QuoYc5oScTkGfFMRmmEKTEMFSzkjg9FA@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.
=========================================


Publications
------------

  - RESOLVED: Republish WD of Cascade 5 and move open feature requests
              to L6
  - A request for wide review of Cascade 5 will be sent in preparation
      for a CR request
  - RESOLVED: Republish Sizing 3 WD
  - In 2 weeks there will be a CR request for Sizing 3. Everyone is
      encouraged to review the spec in advance of that in case there
      are uncaught issues with intrinsic sizing.

CSS Fonts 5
-----------

  - RESOLVED: Reverse the resolution and drop advance-override (Issue
              #5983: advance-override details)
  - RESOLVED: Add a size-adjust descriptor to @fontface, accepting a
              percent. Applies a scale factor. Impacts all associated
              metrics of the font, including the outline. Because it
              does not affect a computed fonts size it does not affect
              em [it does affect normal] (Issue #6075: Add glyph
              scaling override descriptor to @font-face)
  - A new question will be opened for if we should deprecate
      font-size-adjust based on the above resolution

CSS Variables
-------------

  - There is a new proposal for addressing issue #5624 (Higher level
      custom properties that control multiple declarations) which
      would create a new type of custom property which creates a new
      cascade pass to resolve. Anyone with interest in this problem is
      asked to participate on the GitHub issue to reach a solution.

Color 4
-------

  - RESOLVED: Remove color() function fallback (Issue #5931: Concerns
              about color() function fallback)

CSS Contain 2
-------------

  - It remains undecided if the content-visibility: auto subtree
      elements should be visible in the accessibility tree (Issue
      #5857). Exposing the content could mean a performance hit only
      for those using the accessibility tree and therefore be
      considered discriminatory. On the other hand, not exposing the
      content could lead to them not getting to some content which
      should have been reachable. Conversation will continue on GitHub.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Mar/0015.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins Bittner
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Elika Etemad
  Brandon Ferrua
  Robert Flack
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Sanket Joshi
  Jonathan Kew
  Vladimir Levin
  Daniel Libby
  Chris Lilley
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Stanton Marcum
  Myles Maxfield
  Tess O'Connor
  Manuel Rego Casasnovas
  Cassondra Roberts
  Jen Simmons
  Miriam Suzanne
  Lea Verou
  Greg Whitworth

Scribe: dael

  Rossen: Let's get started
  Rossen: As usual, any extra agenda items or things we should change
          on current?
  TabAtkins: fantasai had a request to push a few to the top
  Rossen: Besides what I did?
  TabAtkins: She replied to the thread
  Rossen: I added the first two items. Anything else?
  TabAtkins: I'm not looking at whatever you updated
  Rossen: Got it. Agenda is the topic and the first two are what
          fantasai requested
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2021Mar/0014.html
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2021Mar/0013.html
  fantasai: I've got sizing 3 and cascade 5.
  Rossen: What do we need to discuss?
  fantasai: Publishing
  Rossen: Okay
  Rossen: First is a WD?
  fantasai: Sizing or cascade

  leaverou: chris and I had a schedule request. Could we move color
            fallback before negative percentages since that will be
            bikeshedding?
  chris: And Safari is stalling on impl waiting for this
  leaverou: Should be quick
  chris: Issue #5931
  Rossen: 15 in the agenda. Okay. Will keep that in mind

Publications
============

Cascade 5
---------

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2021Mar/0014.html
  fantasai: We updated spec with WG resolutions for cascade layers
  fantasai: 2 open issues which are bikeshed on syntax
  fantasai: Want to publish new WD and re-target open requests against
            cascade 6
  <chris> 6!!
  Rossen: Definitely should republish
  <miriam> 🎉
  Rossen: When you say re-target existing issues to 6 does that mean
          that will be part of republish?
  fantasai: No, publication will be new WD. At that point cascade
            layers has only 2 syntax issues. Appropriate to request
            wide review and try for CR. All open feature requests
            should target against 6
  Rossen: Awesome. Objections to republish WD and move open feature
          requests to L6

  RESOLVED: Republish WD of cascade 5 and move open feature requests
            to L6

Sizing 3
--------

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2021Mar/0013.html
  fantasai: Tab and I did edits, posted ^
  fantasai: Would like a new WD to get edits in. Tweaked to be as far
            as we can tell correct
  fantasai: Also think this should go to CR, but because intrinsic
            sizing is complicated we want to ask WG for other to do
            top to bottom review before we transition to CR
  fantasai: This is republish and ask for review before we transition
            to CR. Sent wide review request with no issues returned
  Rossen: Could be good, could be no one looked
  fantasai: Yeah
  Rossen: Thanks. Let's publish updated WD and that will help people
          get a good snapshot of what's going to go into CR and nudge
          feedback
  fantasai: Resolution to publish and ask for WG how long should we
            wait before CR for review? How much time do you need?

  Rossen: Objections to republish sizing 3 WD

  RESOLVED: Republish sizing 3 WD

  Rossen: Let's put 2 weeks to get feedback before CR transition. That
          will put a bit of urgency and hopefully someone comes and
          reviews

CSS Fonts 5
===========

advance-override details
------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5983

  <fantasai> https://github.com/w3c/csswg-drafts/issues/5983#issuecomment-800123577
  fantasai: Where we're at is jfkthame's last comment ^
  fantasai: Suggestion is reverse a resolution, drop advance-override
            and focus on scaling descriptor in 6075
  chris: Good proposal. Had a lot of problems with advance-override.
         This seems better approach
  TabAtkins: Last I heard from chrishtr yesterday, this is reasonable
             to us
  fantasai: And xiaocheng agrees
  Rossen: Objections?

  RESOLVED: Reverse the resolution and drop advance-override

Add glyph scaling override descriptor to @font-face
---------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6075#issuecomment-799915767

  fantasai: Proposal add a descriptor to fontface which accepts
            percentages. Scales computed fonts size before select font
            face. Effects all metrics and glyph outlines, but not
            computed font size.
  fantasai: size-adjust is suggested name because same as
            font-size-adjust in working
  florian: Do you mean used font size is scaled?
  fantasai: Yes
  fantasai: Take computed font size, scale, but don't change computed
            font size
  fantasai: 2 use cases. One is what advance-override tried which is
            the pitch of the font on the page scaling.
  fantasai: The other reason to add is the glyphs in a different font
            for same font size look different sizes. We have
            font-size-adjust to equalize x-height, but only works for
            writing modes where x-height matters. Having a manually
            managed scaling allows authors to do size normalization
            for other writing systems and other aspects of font design
  fantasai: Doesn't have a11y or i18n problems advance-override had

  TabAtkins: Making nearly identical to font-size-adjust. Can we fold
             it in?
  <chris> no we can't
  fantasai: This is a descriptor.
  TabAtkins: Nevermind. Cool

  chrishtr: fantasai, there's an issue about multiplying ascent and
            descent
  chrishtr: When used with line-height:normal
  fantasai: Yes, ascent and descent would get multiplied. If you want
            stable line-height you shouldn't use normal since that
            pulls things out of the font.
  chrishtr: You would expect authors to apply ascent overrides to
            counter effect?
  fantasai: size-adjust needs to scale all font metrics. Not just used
            for font-fallback, but other purposes. In case where; if
            you don't want to scale the advance for some reason you
            would unscale using ascent and descent override properties
  fantasai: Most places where people care about this level of
            precision they are likely to not be using normal because
            you would have different line-heights for fallbacks. If
            you care a lot about precision of typesetting you'll use
            line-height:number

  chris: I wanted to point out we should have example in spec. I can
         create one. Should show with unicode range. For Arabic
         bigger, Thai smaller...that's an interesting use case. Want
         different normalization depending on script and this allows
         it. Interesting additional use case.

  myles: We're going to have to make sure we define what happens when
         @fontface has this and ascent-override. Not hard, just have
         to decide
  fantasai: For that question, all metrics overrides you apply as if
            they are what came in font and size-adjust is right before
            you select your font. You want to do that because when
            setting ascent override you're trying to match to a point
            on the glyph, not arbitrary, and that needs to scale with
            glyph. If you scale the glyph and not ascent it will be
            weird
  myles: A few minutes ago you descent there were problems with
         font-size override property
  fantasai: You mean advance-override?
  myles: font-size-adjust
  fantasai: Yeah, scales based on x-factor which doesn't help with
            something like Thai
  myles: I check mdn and only one browser supports font-size-adjust.
         Should we deprecate that?
  chris: It's a bit different. This is a percentages. We could
         harmonize. Could do in new descriptor rather than property.
         Not sure it makes sense to harmonize.
  chris: If suggesting deprecate font-size-adjust I think it's a
         separate issue, but reasonable maybe
  myles: I can open a separate issue
  Rossen: I was about to ask if these are additional clarifications we
          can work separately and sounds like they are

  Rossen: Any additional comments?
  Rossen: If not, summary of proposal?
  fantasai: Proposal: Add a size-adjust descriptor to @fontface,
            accepting a percent. Applies a scale factor. Impacts all
            associated metrics of the font, including the outline.
            Because it does not affect a computed fonts size it does
            not effect em
  Rossen: Objections?
  jfkthame: Can we bikeshed name?
  Rossen: On the issue?
  jfkthame: Okay

  myles: Note sure I agree it wouldn't effect line-height
  fantasai: Doesn't affect computed fonts size. Line-height is
            calculated against that. That's intentional
  myles: I'll open an issue
  Rossen: Thanks myles. If you are concerned for the current
          resolution and don't think it's separate we can discuss now
  <florian> [I think it would affect line-height: normal, but not
            line-height otherwise]
  myles: I don't think need to now.
  myles: I'd appreciate removing that part from resolution
  fantasai: Integral to getting this to work. line-height is a number,
            not a number per font. this is a per font scale factor.
            You can't have it scale line-height. You can have it scale
            ascent and descent but line-height has to be single, not
            array
  myles: Thinking about normal
  fantasai: Does affect normal
  myles: Okay. Doesn't affect line height with a number. Does affect
         normal
  Rossen: Objections?

  RESOLVED: Add a size-adjust descriptor to @fontface, accepting a
            percent. Applies a scale factor. Impacts all associated
            metrics of the font, including the outline. Because it
            does not affect a computed fonts size it does not affect em

CSS Variables
=============

Higher level custom properties that control multiple declarations
-----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5624

  Rossen: Before we go into details, leaverou is this ready?
  leaverou: Is TabAtkins on?
  leaverou: To remind people use case is web components forced to use
            presentational attributes, even though there's an AG
            guideline. Custom properties can only contain fragments
            and often need higher level keywords
  leaverou: Been exploring how would be possible. First idea was to
            have an @if block. Had a breakout with fantasai and
            TabAtkins and realized what if block was trying to do is
            replicate selector logic because can't use selectors for
            computed style. Had an idea which might make more impl-able
  leaverou: TabAtkins suggested new type of custom property resolved
            earlier in cascade which only has keywords or numbers.
            TabAtkins do you want to describe it?
  TabAtkins: Preface this that it's a possibility here. I think it's a
             useful use case.

  Rossen: Let me pause you. Is this issue ready for resolution? Or to
          bring WG back to point of current thinking?
  TabAtkins: Get people informed about issue to get more eyes. Not
             seeking resolution
  Rossen: Thanks

  TabAtkins: Idea I have is, new custom property: const property
  TabAtkins: Can be set like custom property, but can be selected on.
             Can do < or >.
  TabAtkins: Way you avoid problems is do separate cascade pass to
             resolve const properties and treat them as not matching.
             You set const and then do everything else. Avoids loops,
             but lets you pass properties through the tree
  TabAtkins: Can set them on the light dom, will fall into shadows.
             Can match based on them.
  TabAtkins: This is a possibility. Would like eyes. Fear is 2nd pass
             like this is a lot of expense.
  TabAtkins: Possible other ways to solve. Lots of space there, want
             help exploring and finding how to make this better for
             users of custom elements
  leaverou: Hope we can solve without resorting to attributes since
            we're trying to move away from those. Making attribute
            selectors more powerful doesn't solve issue
  TabAtkins: Open to a lot of possibilities. Would like attention paid
             so we can progress

  Rossen: Anything else we can do to attract attention?
  Rossen: Please take a look. Important issue and worth solving

CSSOM
=====

Serialization for declaration block with variable reference in
    shorthand may not be useful
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2515

  Rossen: Do we have the right people?
  Rossen: Doubt we have xidorn. Can anyone represent this?
  TabAtkins: This was put on by fantasai, presumably because needs to
             be addressed. Not certain we need to address on a call.
             It's for me and emilio to work on
  Rossen: I'm fine moving forward if we don't need group consensus.
  TabAtkins: Not yet. May come back later.

CSS Color 4
===========

Concerns about color() function fallback
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5931

  chris: Concern expressed about the syntax. I explained came from SVG
  chris: Doesn't have much value, complicates parsing and typedOM.
         Seem to be consensus on removing. People that implemented
         like BFO are fine dropping
  chris: Since then discussion has drifted to what to use instead. I
         sense consensus on dropping, would like resolution
  <faceless> Big +1 from us
  leaverou: Fine to remove as long as we add in-gamut MQ so authors
            can do fallbacks that way. I think we have consensus on
            that too
  chris: Agree with leaverou that's good to solve, but separate issue
  Rossen: I want to separate the two. To your earlier point the other
          mechanism must be worked on and we need to figure out CSS
          way, but is there objections to removing this?

  RESOLVED: remove color() function fallback

  Rossen: I would urge you to fork the other discussion into a
          different issue
  leaverou: There is a different issue

CSS Contain 2
=============

Clarify whether content-visibility: auto subtree elements are visible
    in accessibility
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5857

  vmpstr: We have content-visibility:hidden as not visible in a11y.
          The auto value does not explicitly state if it should/should
          not be exposed. Some dev concerns that chromium does not
          expose. Would like to clarify in spec that
          content-visibility: auto elements should be exposed to a11y
  vmpstr: They would be essentially visible in a11y. Offscreen
          elements in subtree of content-visibility:auto are visible
          in a11y.
  <fantasai> seems fine to me, given auto seems to be mainly about
             delaying rendering of elements until they're on-screen
             and not about actually hiding the content

  Rossen: Which is the case with visibility, but not display:none
  Rossen: Sounds reasonable. Any other opinions?
  florian: I think it's different than visibility:hidden. Not all
           elements in subtree are accessible. In this case they would
           all be
  chrishtr: Yes, would make all visible even if display:none ancestor
  vmpstr: aria label would be respected so can hide
  fantasai: Seems weird
  Rossen: This is a bigger issue. If could to disable hammer of
          display:none which does nothing, if we destabilize that
          promise that's a different conversation
  florian: We don't want to ignore display:none, but we're ignoring
           styles and display:none is a style
  fantasai: But if treating as shown you have to look at styles
  vmpstr: Expose nodes to a11y. Any action taken to explore, once the
          elements come on screen they're rendered. In that case if
          something is display:none it would disappear from a11y
  Rossen: Which is the problem. From a11y PoV what you have in your
          a11y tree and available to user will be different than what
          is visible in the view
  <fantasai> +1 to Rossen

  Rossen: Let's say you have a quiz and quiz has answers inside
          display:none the right answers will be available to those
          with access to a11y tree
  Rossen: Breaking display:none for a11y or css is bad
  florian: Case you talked about probably not an issue. Different
           issue, once things are on screen you would maybe see answer
  Rossen: Not true. a11y tree and text could get to those without
          moving tree
  florian: Yes. Typical case screen reader not reading what's on
           screen but the outline of doc with hidden outline of doc
           when presented to user it would claim there's a section and
           when you try and go there it's gone
  Rossen: Point here is we're presenting information that shouldn't be
          presented
  vmpstr: Alternative is to not expose it which also exposes different
          information to a11y uesrs. If there are section headings
          that should be visible, can't be accessed through header nav
          which is bad
  florian: Wondering about implementability. a11y tree largely from
           box tree so you need to have a box tree which is working
           off some style. Isn't it?
  [missed]
  vmpstr: Combo of dom and box tree
  Rossen: Different view, think of it that way. Starts with dom,
          predominantly dom.
  chrishtr: Two options are err on side of not making a mistake on
            display:none or err on side of expose as much as possible

  fantasai: Stuff under auto is under a11y tree but other properties
            that cause to not be there would remove that. You're
            saying that's not possible and we need to choose
            everything or nothing?
  chrishtr: Exactly. Not possible because purpose is performance. We
            don't want to just do it for a11y because would expose a
            timing difference
  florian: Since would need specialized code could it only style the
           relevant properties for a11y tree?
  vmpstr: Thought about it. Number of properties isn't the cost, it's
          resolving all of your classes to figure out what styles. Not
          much cheaper to just apply some set of styles as opposed to
          full style resolution
  Rossen: Going back to chrishtr point. This is not a good idea for
          a11y users because that will effect timing
  chrishtr: Partial recalc thing
  Rossen: I agree the proper solution is for purposes of a11y
          content-visibility:auto needs to resolve all the styles and
          then not effecting a11y pre-computation.

  Rossen: That said, want to go back to point this effecting the
          timing. Can you tell a bit more?
  chrishtr: Why the timing shouldn't be different?
  Rossen: Timing for a11y users is different already
  chrishtr: One of the main concerns raised during dev of
            content-visibility is introducing vectors that make timing
            different was not okay
  Rossen: That's a worthy discussion to be had. a11y computation
          compared to visual is more expensive today.
  Rossen: a11y users...those of you who have worked with them must
          have seen they're more patient about getting to their
          content. For them it's about fidelity of getting to content,
          but patience is way better. Arguments about timing in favor
          of fidelity is always bad for time
  chrishtr: Not about patience, it's about discrimination. That's the
            concern raised
  Rossen: I see

  dlibby: I think chrishtr answered my concern. Wanted to add
          typically it's privacy and not exposing vectors for screen
          readers to be detected
  Rossen: Anyone from Mozilla here that could represent these points?
          Doesn't feel right to push the resolution at this point
  dholbert: I wasn't part of the discussion so I don't know exactly,
            but could be because unbounded content in this that author
            assumes is free. If a11y has to display it could be
            unbounded time to process. That could be a concern. Not so
            much a factor longer, but unbounded time where something
            like complete works of Shakespeare where a a11y user has
            to see
  Rossen: Right, but then we're back to content-visibility:hidden that
          hides the content from a11y readers.
  dholbert: Not sure we have great option. That's the concern with
            forcing a11y to style that content

  Rossen: Do you have any experiments on this?
  vmpstr: Have dev feedback for hiding. An article that said be
          cautions about using. Advice was to take the headers out
          because otherwise they're hidden.
  vmpstr: This issue was in response to that article
  chrishtr: We changed chrome behavior for more a11y, but can change
            back if that's the resolution
  <chrishtr> https://web.dev/content-visibility/
  <chrishtr> See note about accessibility - updated last week
  chrishtr: It's linked to from that blog post
  <vmpstr> https://marcysutton.com/content-visibility-accessible-semantics

  Rossen: Hearing some lines of concern. One is we don't want to
          penalize a11y users in a disproportionate way compared to
          those that don't depend on a11y tree.
  Rossen: Other concern is from PoV of what would be there will be
          different than what it should be had styles been computed
  Rossen: That dilemma doesn't seem to be resolved. We're trying to
          force a resolution to validate one or the other and we want
          to validate both.
  fantasai: Blog post talks about putting headings inside the tree is
            problematic. What if we hide everything from the a11y tree
            but if there's headings resolve the styles on the heding
            and ancestors. Maybe that would allow minimal style
            resolution.
  fantasai: You could nav to heading but hide most of it
  Rossen: A little more. It's heading, but it's links and tables and
          paragraphs. Everything indexable by AT today should be
          indexed tomorrow. AT industry has differentiators they're
          depending on
  Rossen: On top of that aria capabilities which could be referencing
          content-visibility subtree still need to resolve
  Rossen: We can take a whole sale don't expose or expose it the right
          way. Anything outside of that will be broken behavior for
          a11y
  Rossen: We're at top of the hour. I don't want to force resolution.
  Rossen: This discussion will go into GH. Will hopefully prompt more
          discussion and we can bring back next week. Is this urgent?
  vmpstr: That's fine, can wait a week

  Rossen: That's all the time for today. Thank you for calling in.
          Have a great rest of your week
Received on Thursday, 18 March 2021 23:08:18 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 18 March 2021 23:08:19 UTC