- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Jul 2022 19:31:20 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
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
discount.
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
#7447)
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)
CSS UI
------
- 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
#7213.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jul/0002.html
Present:
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
Regrets:
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
pricing]
<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
feature.
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
pseudo-elements
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
same
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
interactions
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:
https://www.irccloud.com/pastebin/mBDWfxFT/
<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
#openui
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
point
astearns: so I wonder if we should take it to the issue again for now
astearns: does that sound ok?
[silence]
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`
property
<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
block
fantasai: on inlines it should follow the behavior of
box-decoration-break
fantasai: Negative values are allowed and would extend the
text-decoration
fantasai: Percentages were suggested to be relative to the
containing-block
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
`text-decoration-skip-inset`
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
extension?
<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
wanted
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
https://www.w3.org/TR/css-text-decor-4/#text-decoration-skip-inset-property
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
something
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
percentages
fantasai: Probably worth starting with length and add things
afterwards
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
effects
jensimmons: specially when combined with underline offset/thickness
jensimmons: There's the question of what happens with inline-box
breaking
<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
CSS UI
======
revert-layer rolling back to author origin should disable native
appearance
----------------------------------------------------------------
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
context-dependent
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