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

[CSSWG] Minutes Telecon 2021-03-24 [css-contain-2] [css-highlight-api] [css-pseudo] [css-syntax] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 24 Mar 2021 19:34:05 -0400
Message-ID: <CADhPm3utsFUv-VGLy-vTCVJPruu2QNwgMsDka0JN2xYoJ_9ppA@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.
=========================================


Administrative/Reminders
------------------------

  - dbaron will be added as editor of Transforms 2
  - Please indicate on the wiki (
https://wiki.csswg.org/planning/virtual-april-2021 )
      if you'll be able to attend any sessions for the virtual F2F
  - Everyone is encouraged to help clear out the old PRs in the repo

CSS Contain
-----------

  - A decision on how to handle content-visibility:auto content for
      accessibility (Issue #5857) will wait until there is more
      feedback from the AT developers and accessibility teams.
  - RESOLVED: Animation work is skipped in content-visibility subtrees
              when they're not rendered. creating, taking, or ending
              animations. Animation is refreshed if recalculate (Issue
              #5611: content-visibility should pause css animations in
              subtree)

CSS Highlight API
-----------------

  - RESOLVED: Custom highlights will always go below native highlights
              (Issue #4595: Position of the custom highlights relative
              to the built in ones)
  - RESOLVED: Leave custom highlight properties in the api as
              currently written in spec (Issue #4591: Priority by
              number or some other method)

CSS Pseudo
----------

  - No one is pushing for a fast solution for issue #4398 (Semantics
      of CSSPseudoElement : EventTarget) so people will continue to
      think on the best way to solve the issue.
  - RESOLVED: Add sub-pseudo elements [to style punctuation before or
              after ::first-letter]. Bikeshed names (Issue #2040:
              Problems with styling ::first-letter with punctuation)

Syntax & Values
---------------

  - RESOLVED: Add quirky hex color and quirky unitless lengths to
              Values & Units (Issue #6100: Upstream parser quirks to
              syntax)
  - RESOLVED: Add a quirks mode flag to parsing algorithm and syntax
              which is passed to property specific parsers (Issue
              #6100)

====== FULL MEETING MINUTES =====

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

Present:
  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  Christian Biesinger
  Oriol Brufau
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Sanket Joshi
  Brad Kemper
  Una Kravets
  Vladimir Levin
  Daniel Libby
  Ting-Yu Lin
  Peter Linss
  Morgan Reschenberg
  Florian Rivoal
  Cassondra Roberts
  Miriam Suzanne
  Lea Verou

Regrets:
  Brian Kardell
  Chris Lilley
  Greg Whitworth

Scribe: dael

  astearns: Still a little light, but let's get going
  astearns: Item #3 was put on the agenda mistakenly so we'll skip
  astearns: Any other changes to the agenda?

  fantasai: Reminder Sizing 3 is up for review. 1 open issue we need
            help on
  astearns: You'd like people to look at issue or general review?
  fantasai: Both
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2021Mar/0013.html
  <fantasai> https://github.com/w3c/csswg-drafts/issues/5665#issuecomment-797046688

  astearns: Additional thing from me, dbaron has volunteered to help
            co-edit transforms 2. Happy to take him up on it.

April virtual long-form meeting
===============================

  <astearns> https://wiki.csswg.org/planning/virtual-april-2021
  astearns: I have set up a long for meeting. Wiki page ^
  astearns: If you can attend please put yourself on the participant
            list. We'll put and agenda together

Ancient PRs that need attention
===============================

  astearns: Have very old PRs, some back to 2017
  astearns: I'd like everybody who contributes to repo to look at PRs,
            see if they can be folded in or closed. If you close put a
            comment why
  astearns: Would be nice to have only PRs from current year
  <fantasai> https://github.com/w3c/csswg-drafts/pulls

CSS Contain
===========

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

  vmpstr: Continuation from last week
  vmpstr: Question is what do we expose to a11y when
          content-visibility:auto element is offscreen
  vmpstr: Had a bit of discussion on the issue. Don't think we have a
          good front runner. Wanted to continue discussion
  dholbert: I spoke to Mozilla a11y folks and they prefer expose
            everything approach for offscreen content we haven't
            computed style for
  vmpstr: That would include exposing things that would otherwise have
          display:none?
  dholbert: Correct. And when we compute style they may be hidden to
            a11y tree
  vmpstr: Okay. That was initial proposal. Rossen raised concerns. I
          don't know if he is on or someone can represent.

  Rossen: I'm here but sounds like we're recurring back into
          discussion. Not sure what is the new part of discussion
  florian: Has been new stuff on GH. Clarifications. I think everyone
           agrees painting can be skipped. For styling the difficulty
           is for search in page or tabbing or indexing the page then
           you do need to style the content to find out what's
           available
  florian: For most of these you can do so lazily.
  florian: Ideally you could do same for a11y tree if we had a lazy
           build a11y tree. Could exist in theory, but not what we
           have. It's build synchronously.
  florian: Either we require you always compute the style so that we
           have consistent state that makes sense or we have a
           problem. Requiring computing the styles is more expensive
           then being desired
  vmpstr: Also dlibby mentioned that there is work to have a notion of
          lazy generated content in a11y content.
  vmpstr: Agree with florian that problem what is exposed to a11y is a
          view on the whole doc. Hand it off to a11y tech and user can
          explore in totality
  vmpstr: If we do that I don't know how we solve with either not
          expose the content or always style which I'm against
  florian: You could skip painting, so not completely useless
  vmpstr: Design was to skip work and style takes a significant chunk
          of work so would reduce effectiveness
  florian: So that's a summary of where we're at in GH. Haven't
           figured out what to do from there

  chrishtr: Sounds like a11y team of chrome and mozilla have deemed
            current chrome is okay which is to always include a11y
            things that are offscreen
  florian: Include everything
  chrishtr: Yep
  florian: script, style tags, everything
  chrishtr: Things with a11y roles
  chrishtr: That are offscreen are included in a11y even though we do
            not yet know their styles
  smfr: You'll have a significant change in tree if something triggers
        content-visibility to render. So something would disappear
  chrishtr: Yep, might occur
  florian: Landmarks could even be a problem. But a11y tree doesn't
           only contain landmarks so it would contain script and style
           tags which are not meant for display

  Rossen: I was able to catch up on thread. I think this is still very
          much in progress in thread. We seem to be repeating from
          previous call. I wanted to see besides looking for more
          engagement you're looking for.
  vmpstr: Making progress was my hope. If engagement is what it takes,
          that's what I'm looking for
  vmpstr: We're stuck with same ideas. We have to start agreeing and I
          don't think we are
  Rossen: Do we know if "JAWS test" user that commented is from the
          JAWS team? The comment they added on May 17
  vmpstr: I'm not sure who that is
  vmpstr: Comment they mentioned is if it's offscreen it should be
          exposed and if it's hidden it should not. This is the whole
          middle section of the issue. If it's offscreen it is hidden.
          It's unclear what to do
  Rossen: Reason I asked is I think this is going to be common
          representation of AT devs. I'm not going to make a statement
          on their behalf. Having worked with them I know a lot of
          innovation and differentiation for ATs, especially those
          working behind more restrictive platform APIs, they tend to
          be very susceptible to these kinds of changes
  Rossen: Given they don't have full access to the rendered tree this
          for them becomes ground. And if we give them something
          that's not representing reality we will confuse because
          they're building caches based on what's available. Think
          about it lighting up different features that should be there
          in presence of content. We're saying the content is there
          kinda sorta but we're going to say it's there.
  Rossen: Reason I'm saying it we are repeating conversation from last
          week with added clarification. Not seeing the level of
          engagement. I want to see what Dominick from chrome teams
          and a11y team says. Also waiting on [missed] to hear back
          from the MS AT partners
  vmpstr: Chrome a11y team did look and they were okay with what I
          mentioned earlier
  Rossen: That's a good signal. Thank you
  astearns: Rossen can I task you to get feedback from your AT partners
  Rossen: Not just our partners will have impact. But based on
          comments Daniel Levy is contacting them
  astearns: I'll take agenda tag off. Let's put it back on when we
            have enough to have a yea or nay vote

content-visibility should pause css animations in subtree
---------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5611

  vmpstr: Hard to talk about this without previous one in mind. This
          is about skipping css animations in subtrees that are
          unrendered by content-visibility
  vmpstr: Building toward making sure we can skip the animation work
          if elements are not rendered
  vmpstr: Have agreement from a couple people on issue who I believe
          are animation experts
  vmpstr: I think we should still resolve, though we haven't solved
          the previous issue
  astearns: What's the resolution they agree on?
  vmpstr: Animation work is skipped in content-visibility subtrees
          when they're not rendered. creating, taking, or ending
          animations. Animation is refreshed if recalculate
  astearns: Reasonable to me. Any concerns?
  astearns: Objections?

  RESOLVED: Animation work is skipped in content-visibility subtrees
            when they're not rendered. creating, taking, or ending
            animations. Animation is refreshed if recalculate

CSS Highlight API
=================

Position of the custom highlights relative to the built in ones
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4595

  sanketj: CSS pseudo spec specifies the order of highlights.
           selection is on top, then target text, spelling error,
           grammar error. Where does custom highlight fit?
  sanketj: Proposal is below the native ones. Wouldn't want author
           defined highlight to suppress
  <fantasai> wfm

  florian: Sounds good for default terms. If it's possible to override
           is more subtle. Being at the bottom by default makes sense.
           At least on one Apple system you can't draw over selection
           highlight
  florian: As to if it should be overrideable...going over selection
           you can't. For spelling error you can imagine author
           wanting custom spelling but default grammar. Without
           ability to go on top of some native you can't
  sanketj: Fair. Did experiment to see if wanted to support
           interleaving. If you want to go above others we can't find
           scenario and don't have requests so thought we could solve
           that down the line and define the option later
  fantasai: Agree. I would note effects of highlights to stack so some
            effects will override but some will stack
  florian: I'm fine with proposal. I want to make sure we talk now
           because we have related issues about the API to determine
           what's on top. There were suggestions for negative to go
           under and positive above, if we say never above we rule
           that out. Knowing if we want to enable now or later is
           relevant
  sanketj: I think priority stuff which is next issue is about how
           they stack relative to each other. This is to custom
           highlights. I think slightly tangential. I think there's
           somewhat separate problems

  astearns: Proposal: custom highlights will always go below native
            highlights
  astearns: Objections?

  RESOLVED: custom highlights will always go below native highlights

Priority by number or some other method
---------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4591

  sanketj: Within these custom highlight overlays there's default
           order based on order registered. Highlights added later are
           painted on top
  sanketj: Problem we're trying to solve is what if author want
           earlier registered on top
  sanketj: Couple of options
  sanketj: First is what we have in spec which is define priority
           property on highlight OM type. Number you can set >0 to
           give priority
  sanketj: Example: If you have foo and bar highlights and bar
           registered later, bar paints on top. If you want foo on top
           set priority=1 and we would get that effect
  sanketj: Another approach is not use priority but use highlight
           registry as source of truth. Introduce additional APIs like
           insertBefore which lets you change the order. Don't need
           additional concept, but means we can't re-use API surface.
           Seems like a lot of overhead
  sanketj: Not super happy about that approach. I prefer what's in
           spec. Want other thoughts.
  <fantasai> +1 to not using CSS property
  sanketj: On more approach listed is similar to first but use a css
           property for priority. Don't think it works because it sets
           individual pseudos not for the overlay. Shouldn't be able
           to stack per pseudo element differently

  florian: Agree. I don't think anybody loves similar to z-index but
           everything else seems worse
  florian: Separate issue, if we go with number is it int or float and
           are negatives allowed
  sanketj: Right. If we have time we can go in to that. Want to get
           resolution of should we allow a number at all

  astearns: Side conversation between fantasai and TabAtkins on IRC
  fantasai: I just asked TabAtkins what he thinks. I'm not super
            familiar.
  fantasai: Question, between options 1 and 3 if there was some kind
            of standard interface for a lengthless type set what would
            your preference be?
  sanketj: If we had something we could reuse?
  fantasai: Yeah. One of hesitations is we would need custom
            implementation. If that wasn't the case, what is
            preference?
  sanketj: Highlight registry seems more about registration. Seems
           weird to manipulate that because then it's about control
           not just registering. I think I'd still prefer priority by
           number
  florian: Agree. Having explicit manipulation would be clunky. Maybe
           a little more powerful. But if you're developing all
           highlights you pick a number. If using libraries you'll be
           satisfied with neither direct numbers or direct manipulation
  florian: I think the simpler thing is better
  florian: Maybe you want some sort of constraints but we don't want
           to bake that into browser. That's on 3rd party library
  fantasai: I think that order used as registered is tiebreaker is
            useful. Within library you can register back to back and
            they'll file together. With other method that's trickier
  astearns: If you have 2 and concerned about way they overlap you
            register with numbers that have relationship you like. As
            others are registered that doesn't change order you
            register in
  florian: You can register both at 733 in the right order and even if
           someone uses that number they won't be able to interject
           between
  florian: I think there's been a bit of back and forth and no one
           loves numbers, but everything else is worse in some way
  fantasai: Seems reasonable
  astearns: Positive int or allowing float so you can fit in between

  plinss: Going back for a second. If answer is this will not satisfy
          anybody why don't we do the highlight manager?
  florian: You'll need a manager if you have multiple libraries with
           multiple highlights. If you just write 3 yourself you give
           a number then you're fine
  sanketj: Agree
  fantasai: If the library accepts a parameter you can pass in a
            number unless you want to interleave. If you pass in to
            register at 6 that's straight forward.
  plinss: Isn't that a common case? Isn't it common libraries won't
          bother to care about others that always use highlights
  plinss: In order for multiple libraries to work they have to be
          aware of each other. I don't think that's common case
  sanketj: Common to have spell check extension to have highlights,
           paging to have highlights. Uncoordinated use cases. For
           that there's no good solution. They could manipulate
           priority or the highlight registry. I don't think anyone is
           trying to solve that problem that a manager would do.
  sanketj: Trying to provide a middle ground so uncoordinated access
           is not an issue and let authors manage the highlights they
           want
  florian: Even if libraries don't coordinate you can do it after they
           set. Only if they're trying to fight each other. You can
           fix it for them if they don't care
  GameMaker: Can we change priority after?
  florian: It's an attribute you can set
  GameMaker: Okay
  plinss: Not the hill I want to die on, but concerned platform has
          half solutions that require 3rd party library to work
          consistently. Don't want to add another
  florian: I don't think you need a manager

  astearns: Since plinss won't die on the hill, sounds like we have
            consensus to add to API as a priority
  florian: Can we resolve on that? There's a separate issue for type
           of number
  sanketj: There are. Not on agenda.
  florian: They're separable
  astearns: Prop: Keep what is in the spec for priority
  astearns: Objections to leave custom highlight properties in the api
            as in spec

  RESOLVED: Leave custom highlight properties in the api as in spec

  astearns: Lots of other items on agenda. Hash out number type in
            issues?
  sanketj: Yes, we can do that

CSS Pseudo
==========

Semantics of CSSPseudoElement : EventTarget
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4398

  fantasai: I don't know what to do with it. I'm asking for help from
            the WG
  astearns: Anyone want to jump in?
  astearns: Might be better to tag particular people
  fantasai: Don't know who
  florian: Punt while we figure out event handling for highlight APIs?
           Might influence here
  florian: Until that's resolved we leave this hanging. Unless someone
           has better idea
  sanketj: I think we discussed similar on a different call. I don't
           think there's implementor interest in this area
  dbaron: My reaction to the issue is probably worth going slow. One
          suggestion is this is only for animation events and that
          might be reasonable way to start
  dbaron: Not a good idea to make intent to change event handling in
          non-backwards compat ways. Difference in how click events
          are handled is probably not what we want
  florian: Even handling on pseudos we haven't attacked precisely, but
           want to handle it generally. I agree
  astearns: Let's leave it here. We have highlight issue linked. This
            will go into issue
  astearns: As dbaron says we can go slowly on this.

 Problems with styling ::first-letter with punctuation
 -----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2040

  fantasai: Basically a requirement that punctuation associated with
            first-letter is styled independent of the letter.
            Sometimes punctuation is in font of paragraph, sometimes
            in between. Sometimes not colored when letter is
  fantasai: Need pseudo elements to select first letter different from
            punctuation
  <fantasai> https://github.com/w3c/csswg-drafts/issues/2040#issuecomment-669614648
  fantasai: AmeliaBR posted ^ which is adding pseudo element which
            attaches to first-letter pseudo and attaches to only
            letter and only punctuation so you can style separate
  fantasai: Other comment is ::marker has similar structure with
            counter, prefix, postfix. Might want to use same system
            and maybe same names
  fantasai: Not going to get through bikesheding, but want to ask WG
            if this is how they want to go about it
  astearns: Not sure about parallel between this and marker. Seem
            different kinds. But I do like idea of tacking on another
            pseudo element to first-letter

  fantasai: Do we like idea of one name for punctuation on both sides
            with before/after params or separate pseudo?
  florian: Common to style before and after same?
  fantasai: Don't know
  florian: I think that's the answer. If it's common it's useful to
           style both
  astearns: Less common to have following punctuation. I would guess
            when you have both style same
  florian: In French it's not rare. "J' is plausible. I don't know
           style, though. If want to style ' same as letter you may
           want before punctuation different
  <florian> example: “J'aime…
  fantasai: I can see cases where you want different. Things like em
            dash you want aligned to center of letter but smaller
            size. But might not want the vertical align on the
            apostrophe
  astearns: Agree with examples. I'm wrong about not having cases
  astearns: Other thoughts?
  astearns: Could resolve to have a pseudo element with way to pick
            apart pieces
  fantasai: pseudo-sub-element. And we can bikeshed later
  florian: If a shortname falls out we can have it, but we shouldn't
           explicitly try to have one
  astearns: Shouldn't make the same syntax for marker
  fantasai: prefix and postfix perhaps
  <fantasai> ::prefix / ::postfix

  astearns: YOu'd like resolution?
  astearns: Objections?
  fantasai: Add sub-pseudo elements. Bikeshed name

  RESOLVED: Add sub-pseudo elements. Bikeshed name

Syntax & Values
===============

Upstream parser quirks to syntax
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6100

  TabAtkins: 2 simple bits
  TabAtkins: Anne pointed out there's parser quirks for hashless hex
             and unitless length
  TabAtkins: In quirks spec
  TabAtkins: Agreed in past we should try and upstream to relevant
             specs
  TabAtkins: Agree can move in. Don't need to do anything in syntax
             because don't parse normally so should be in V&U where we
             define hashless hex and unitless length production
  TabAtkins: Notes about when in quirks mode we accept these
  TabAtkins: One syntax change is let you pass in that you're parsing
             in quirks mode into syntax parse. Parsing algorithm
             generically evokes do what you need to parse and that
             should get quirks mode flag explicitly so it knows to
             accept quirky hex and length
  TabAtkins: Asking for 2 resolutions. Add quirky hex color and quirky
             lengths to V&U
  TabAtkins: Add an explicit quirk flag for parsing algo in syntax
             that is invoked at point syntax spec asks you to parse
             these

  florian: I believe I know answer, none of these quirks could
           disappear?
  TabAtkins: No, have been around for forever. As long as quirks mode
             exists, they will
  fantasai: Fine, but shove into an appendix
  TabAtkins: Happy to do that
  astearns: Other comments?

  RESOLVED: Add quirky hex color and quirky lengths to V&U

  TabAtkins: Add a quirks mode flag to parsing algorithm and syntax
             which is passed to property specific parsers
  astearns: Objections?
  florian: Questions - what passes it to parsing algorithm?
  TabAtkins: Callers. Things don't generally invoke those, but now
             they exist they can if necessary pass a quirks mode flag
  astearns: Objections?

  RESOLVED: Add a quirks mode flag to parsing algorithm and syntax
            which is passed to property specific parsers

  astearns: Nothing that's 3 minutes so we'll be done early
  astearns: Thanks everyone for calling in
Received on Wednesday, 24 March 2021 23:34:47 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 24 March 2021 23:34:48 UTC