W3C home > Mailing lists > Public > www-style@w3.org > July 2022

[CSSWG] Minutes Telecon 2022-07-13 [css-2022] [css-highlight-api] [selectors-4] [css-text-decor] [css-ui] [css-mediaqueries]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 13 Jul 2022 19:31:20 -0400
Message-ID: <CADhPm3vYxmgJXyTX5_r3XH3ic4vp2n33LMfG4wr9ehFzQy+GtQ@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.

Upcoming Meetings

  - Please register for the F2F on the wiki as soon as possible.
  - TPAC registration is now open and there is an early registration

Snapshot 2022

  - RESOLVED: Add Color 4 to snapshot (Issue #7455: Add CSS Color 4 to
              "Official definition")

Highlight API

  - RESOLVED: Incubate this in CSSWG (Issue #7447: Incubating custom
              highlight pointer event handling in CSSWG)
  - RESOLVED: Create a highlight L2 spec, dandclark is an editor (Issue

Selectors 4

  - There were some cases raised in the comments of issue #1533 (Issue
      11: Introduce pseudo-class matching when user changed the value
      of an input) where the proposal wouldn't have the correct
      behavior. Discussion will return to github to answer the
      questions on handling.

CSS Text Decor

  - RESOLVED: Remove text-decoration-skip-inset, add
              `text-decoration-trim: <length> <length>?`, follow-up for
              improvements and issues (Issue #4557: Feature request -
              add a property text-decoration-length that modifies the
              length of the underline)


  - RESOLVED: For properties that disable native appearance, do all the
              reverting, take into account the origin of the final
              cascaded value (Issue #7239: revert-layer rolling back to
              author origin should disable native appearance)

Media Queries

  - RESOLVED: prefers-color-scheme in SVG rendered in secure animated
              mode is context-dependent (Issue #7213: Should
              prefers-color-scheme in SVG images be context-dependent?)
  - There will be a separate discussion on iframe handling for issue


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jul/0002.html

  Rachel Andrew
  Adam Argyle
  Tab Atkins Bittner
  David Baron
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Brian Kardell
  Brad Kemper
  Jonathan Kew
  Peter Linss
  Alison Maher
  Jen Simmons
  Alan Stearns
  Bramus Van Damme
  Lea Verou

  Miriam Suzanne

Scribe: emilio
Scribe's scribe: fantasai

Meeting Registration

  astearns: If you think you might come to the F2F, please register
            into the wiki
  <fantasai> https://wiki.csswg.org/planning/nyc-2022
  astearns: Also, TPAC 2022 registration just opened. There is
            registration both for in-person and remote attendance, so
            please register appropriately
  <fantasai> [note there's a cut-off date for early registration
  <fantasai> https://www.w3.org/2022/09/TPAC/

Snapshot 2022

Add CSS Color 4 to "Official definition"
  github: https://github.com/w3c/csswg-drafts/issues/7455

  <fantasai> +1 to adding to snapshot
  <TabAtkins> +1

  RESOLVED: Add Color 4 to snapshot

Highlight API

Incubating custom highlight pointer event handling in CSSWG
  github: https://github.com/w3c/csswg-drafts/issues/7447

  dandclark: Highlight API had some progress these last couple years
  dandclark: but no progress to be able to interact with highlights
  dandclark: Common use case is spellcheck
  dandclark: There's no way to interact with highlighted ranges
  dandclark: so a super useful addition would be to add pointer events
             to highlighted ranges
  dandclark: There's various ways to determine how they'd be routed etc
  dandclark: but I wanted to check whether this is the right place for
             this, since this is a bit more DOM-y
  dandclark: Some first steps would be moving some issues from the
             MSEdgeExplainers repo to CSSWG
  dandclark: We can do some spec PRs and prototyping

  florian: I think the use cases are numerous and compelling, and
           proposed API looks pretty good at first sight
  <TabAtkins> Agree the use-cases for the feature are good and worth
              developing. Fine with this group taking on the work; we
              do DOM-ish stuff sometimes, and it feels reasonable to
              handle this in the same group as the rest of the CSS
  florian: There are a number of interesting questions: things like
           dealing with overlapping ranges, and how to dispatch to the
           DOM in general
  florian: The other similar thing that comes up is other
  florian: Is this a missed opportunity to fix that too?
  florian: Anyways I think the best thing to do is bringing it in-group

  astearns: Is csswg the only place you have considered bringing in?
  dandclark: For now csswg, but we possibly also want to raise a tag
             review and other groups like whatwg

  emilio: My first question is whether, there's a Selection and Editing
          API WG, which already has a bunch of interop problems to solve
  emilio: Other question is, do we really need to dispatch new events
          on these, or can we re-use the existing machinery?
  emilio: Add a convenient way to check whether an event intersects
          with a highlight
  emilio: I don't know whether StaticRange has it as well
  emilio: there are ways to check interaction of pointer events
  emilio: It seems to me there's some other areas where this could
          benefit from, other groups that could also help here
  emilio: especially editingWG
  emilio: Lots of interaction with ShadowDOM and stuff
  dandclark: [missed]
  dandclark: But would think it's good to start here in CSSWG
  astearns: Emilio, any objection to starting here?
  emilio: No objection

  astearns: Any other comments?
  astearns: I suggest we take this as an incubation in the CSSWG,
            noting that it's merely an incubation
  astearns: Objections?
  * fantasai thinks this makes sense

  RESOLVED: Incubate this in CSSWG

  dandclark: There's a section in the existing draft about this, which
             is just a missing section
  dandclark: do we want to put it there?
  astearns: Seems like a reasonable place to start?
  fantasai: Do we want to put it into a L2 spec instead? Seems like
            highlight API is relatively stable
  florian: Was about to suggest the same
  <chris> A level 2 diff spec seems a better way, agreed
  dandclark: That works for me, might have some follow-up questions
             about process
  astearns: Who's the current editor?
  florian: I'm one of them
  <GameMaker> I'm the third editor
  fantasai: There's 5 open issues on L1, we should consider trying to
            fix them and move to CR
  astearns: dandclark, would you want to be an editor of L2?
  dandclark: Sure

  RESOLVED: Create a highlight L2 spec, dandclark is an editor

Selectors 4

Issue 11: Introduce pseudo-class matching when user changed the value
    of an input
  github: https://github.com/w3c/csswg-drafts/issues/1533

  emilio: I think this would mostly be an alias to a simple
          :is(:user-valid, :user-invalid)
  emilio: but maybe best to have this conversation with Sebastien
  fantasai: Comment pointing out a few cases where it's not exactly the
  fantasai: It's not exactly what emilio is suggesting, see last
            comments in the issue
  bramus: So this is to target inputs, proposed aliases :dirty /
          :changed / :user-edited
  bramus: Concept is when a user interacts with the input then it would
          become dirty
  fantasai: The other thing to note is that `:user-valid` /
            `:user-invalid` is that they trigger on submission, but
            this presumably won't
  <tantek> I feel like this has come up in the past but I can't recall
           what we called it.
  <argyle> https://angular.io/guide/form-validation#control-status-css-classes

  astearns: Should we resolve to work on this?
  bramus: There seems to be a minor difference between :dirty and
          whether the user touched it
  bramus: e.g., focusing the input would be touched, changing the value
          would be dirty
  tantek: In general looks like a good area to explore
  tantek: I think we have talked about in the past about this but I
          can't recall where
  tantek: one question is what happens with autofill and similar
  tantek: Does autofilling + clearing it out get special treatment?
  tantek: There's a bunch of questions about what other states do we
          need to design for
  tantek: We might want to do some more research on that
  <bramus> Good suggestion
  <argyle> I found these very helpful in the past:
  <emilio> +1, it seems there's a variety of different use cases that
           don't quite always match
  <tantek> I would also advise coordinating this exploration with

  flackr: I thought the autofilled text isn't exposed till the user
          interacts with the field
  flackr: which would suggest that naively that before you interact
          with the page it wouldn't be dirty
  emilio: You're right we don't expose it
  emilio: but we do match :autofill pseudo-class
  <dbaron> some of this may differ between password management autofill
           and more general autofill, too
  <tantek> +1 dbaron

  astearns: I'll raise an issue with openui so that they're aware
  astearns: but it seems we have more questions than decisions at this
  astearns: so I wonder if we should take it to the issue again for now
  astearns: does that sound ok?

CSS Text Decor

Feature request - add a property text-decoration-length that modifies
    the length of the underline
  github: https://github.com/w3c/csswg-drafts/issues/4557

  fantasai: There's been a variety of requests for controlling the
            length of underlines
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4517
  fantasai: We have some spec text to ensure that underlines break
            between words
  fantasai: but we've been asked to provide more control
  fantasai: Suggestion is to define a new `text-decoration-trim`
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4557#issuecomment-1117735704
  fantasai: which would take a `<length-percentage>`
  fantasai: and shortens the underline by the given amount
  fantasai: There's the question of what's the percentage relative to
  fantasai: so we could start with `<length>`
  fantasai: on block containers we could apply it to both sides of the
  fantasai: on inlines it should follow the behavior of
  fantasai: Negative values are allowed and would extend the
  fantasai: Percentages were suggested to be relative to the
  fantasai: There's some effect animating where that'd be useful for
  <fantasai> https://www.w3.org/TR/css-text-decor-4/#text-decoration-skip-inset-property
  fantasai: If we want to discuss percentages we can do that now but
            I'd like to add this to the spec and remove
  fantasai: as described above wrt inlines / blocks

  astearns: Is text-decoration-skip-inset implemented anywhere?
  fantasai: I don't think so
  astearns: Is trim the best word when negative lengths can be an
  <tantek> just like indent negative means outdent?
  <fantasai> yep
  fantasai: I think so since negative trim is to extend the same way as
            negative extend is trim, I think use case is mostly trimming

  florian: The property that would be dropped had an auto value
  florian: Should this have the same value?
  florian: If you want the browser to trim by the right amount
  florian: so we'd be losing this but we could reintroduce this if
  fantasai: Yes
  astearns: fantasai, would this go into your initial write-up? or
            should we decide later?
  fantasai: I don't think an auto value is particularly useful if you
            can specify lengths
  <tantek> +1 fantasai, worth documenting an actual use-case of for
           'auto', like what problem is it solving?
  <fantasai> it's solving the problem documented in
  florian: In CJK when you have a piece of content and they might be
           next to each other, and without skipping you might not
           notice that they're different words
  florian: you might want to say "browser, just do something"
  florian: You could do "3px" or something, but then why that?
  <faceless> Easy enough to define "auto" as "the width of the
             underline" perhaps?
  fantasai: I think the width of the underline was my initial thought
  fantasai: though might not be useful if the underline is very big? So
            might be more like `min(0.1em, underline-width)` or
  florian: Can we leave it as browser defined, or do we want browser
           guidance here?
  fantasai: I think we want to do that so people know what to implement
  florian: As one data point, I have authored CJK content where I've
           wanted this, without having a view as to how big it
           should be.
  fantasai: One of the problems we have with percents is that we have
            percentages for word-spacing etc to reference the font-size
            of the element? Maybe we can do that
  fantasai: Happy to start with `<length>` / `<length>|auto` / then add
  fantasai: Probably worth starting with length and add things

  plinss: Question, removing lengths from the end of the decoration, or
          also from the skipping between descenders and so
  fantasai: Just end
  astearns: We discussed that and run into implementation difficulties
  plinss: ok, just wanted clarification, would be weird if it trimmed
          from both
  <jensimmons> `text-decoration-trim: <length>` for the resolution
  jfkthame: One thing I wondered is whether we want two values, one for
            start, one for end
  fantasai: Makes sense
  <fantasai> -> illustration https://github.com/w3c/csswg-drafts/issues/4517

  jensimmons: Separate for start/end could be declared all at once
  jensimmons: Could see authors creating some kind of drop-shadow-like
  jensimmons: specially when combined with underline offset/thickness
  jensimmons: There's the question of what happens with inline-box
  <dbaron> Maybe also when combined with italic/oblique
  astearns: That's the part where it'd follow box-decoration-break

  tantek: Just wanted to add with potential interactions with
          text-overflow: ellipsis
  tantek: Do you want this always, only when there's no text overflow,
          do you want to trim from the ellipsis start...?
  fantasai: Can't even remember whether the ellipsis gets underlined or
            not atm
  astearns: If you're not using trimming at all, it seems this is a
            higher level question, you should get control for whether
            the underline applies to the end overflow
  plinss: My intuition would be that the end would be that the end
          would be where it'd be without text overflow
  fantasai: [missed], something about box-decoration-break
  plinss: I like separate start/end, provides more interesting
          animation possibilities
  <fantasai> box-decoration-break defaults to slice, which would get
             the behavior plinss describes

  RESOLVED: Remove text-decoration-skip-inset, add
            `text-decoration-trim: <length> <length>?`, follow-up for
            improvements and issues

  florian: Could I ask people familiar with in-design and similar
           software if they have auto values and how it works if so?
  astearns: Don't recall
  astearns: Will ask about in-design underlines
  fantasai: Should I add the definitions with auto / percentages in the
            first draft?
  astearns: I think it'd be good to add at least a note
  florian: Either that or put the value in with an issue on how to
           define it
  fantasai: If people are fine with me adding it in I'd just do that
            since it makes it easier to discuss


revert-layer rolling back to author origin should disable native
  github: https://github.com/w3c/csswg-drafts/issues/7239

  oriol: There are some properties than when set on author/animation
         origin disable native appearance unless `revert` /
         `revert-layer` is specified
  oriol: For revert it makes sense
  oriol: since it always reverts to user/ua origin
  oriol: but revert-layer can revert to author origin
  oriol: and in this case it should disable native appearance
  oriol: All implementations already behave like this
  oriol: so proposal is to align with implementations

  florian: I think it's over-correction, original spec forgot
           revert-layer but forgot taking this into account
  florian: If you have multiple revert-layers, how does this behave? Is
           it feasible to check all of them?
  oriol: I didn't test this more complex case
  florian: Could we spec that however many layers you revert you
           account for that, and revisit if it's problematic?

  emilio: I just wanted to say, you do need to revert all the layers
  emilio: you need to get to the original value
  emilio: so I think it makes sense to spec this, it's the sensible
          thing to do
  <emilio> so, +1

  RESOLVED: For properties that disable native appearance, do all the
            reverting, take into account the origin of the final
            cascaded value

Media Queries

Should prefers-color-scheme in SVG images be context-dependent?
  github: https://github.com/w3c/csswg-drafts/issues/7213

  emilio: I did check with the security folks at Mozilla, and they
          weren't concerned about making this apply even more generally
          to iframes
  emilio: Only attack is if a page is in an iframe and a top-level
          frame, can determine ???
  emilio: But no problem for SVG images
  emilio: I think it'd be nice to do it for iframes as well
  emilio: My discussion with them was that it's not a big concern, idk
          if other folks have an opinion

  smfr: On the WebKit side would be much more reluctant to do on
        iframes, but OK for SVG images
  smfr: Was having trouble finding text in HTML spec that SVG couldn't
        run script or load external images
  smfr: so part of this issue needs to clarify when SVG can load
        external resources or run script
  emilio: Why reluctant to make it work on iframes?
  emilio: We already communicate info about backgrounds
  [missed the detail on how]
  <dholbert> smfr: RE where it's defined that SVG Images don't run
             scripts, that's defined in https://svgwg.org/specs/integration/
  <dholbert> see https://svgwg.org/specs/integration/#secure-animated-mode
  <dholbert> "Secure animated mode"
  <smfr> dholbert: but HTML doesn’t reference that everywhere it
         needs to

  chris: SVG images in <img> tag don't run scripts or fetch resources
  chris: if they are in <object> they can fetch and run script
  chris: It's not a function of SVG, but function of SVG's integration
         in external environment and what it allows them to do
  astearns: When in <object> ...
  chris: They can do everything
  astearns: Are they SVG images?
  chris: Yes, just not using an <img> tags
  emilio: From implementation point of view, they are iframes
  chris: Also if displayed standalone, same thing
  chris: they can run scripts, fetch resources, etc.
  <TabAtkins> (as far as I recall) Chrome is fine with passing into any
              SVG that can't fetch or run script (aka <img> tags), and
              same-origin iframes.
  <TabAtkins> We just don't want to open up new cross-origin
              communication bits.

  emilio: Seems there would be no objection to doing on SVG images
  emilio: and maybe file an issue about iframes
  smfr: Sounds good

  TabAtkins: From what I recall, Chrome is fine with this so long as it
             doesn't open up new cross-origin communication bits
  TabAtkins: So SVG as img should be fine
  TabAtkins: and same-origin iframe should be fine
  smfr: That matches WebKit's preference, too
  emilio: OK, then we can discuss iframes separately
  emilio: I'm more interested in this SVG case
  emilio: It's not easy for the iframe to tell where the preference
          comes from
  emilio: we can discuss another time

  fantasai: Seems we have consensus on SVG as <img> and also
            same-origin iframe
  ???: what about SVG's that are rendered through CSS?
  fantasai: There's an embedding mode for SVG that does this, so
            anything in that embedding mode
  astearns: Maybe let's take a resolution on SVG first
  emilio: Draw background in iframes, that doesn't care about same vs
          cross-origin, so unsure how to do that
  astearns: Proposed that prefers-color-scheme in SVG-images is
  smfr: "SVG rendered in secure animated mode"
  <smfr> https://svgwg.org/specs/integration/#secure-animated-mode
  astearns: Objections?

  RESOLVED: prefers-color-scheme in SVG rendered in secure animated
            mode is context-dependent
Received on Wednesday, 13 July 2022 23:32:01 UTC

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