Meeting minutes
Upcoming Meetings
[css-2022] Add CSS Color 4 to "Official definition"
+1 to adding to snapshot
github: https://
<TabAtkins> +1
RESOLUTION: Add Color 4 to snapshot
<chris> great!
[css-highlight-api] Incubating custom highlight pointer event handling in CSSWG
github: https://
dandclark: Highlight API had some progress these last couple years
… but no progress to be able to interact w/ highlights
… common use case is spellcheck
… there's no way to interact with highlighted ranges
… so a super useful addition would be to add pointer events to highlighted ranges
… there's various ways to determine how they'd be routed etc
… but I wanted to check whether this is the right place for this, since this is a bit more DOM-y
… some first steps would be moving some issues from the MSEdgeExplainers repo to CSSWG
… 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
… there are a number of interesting questions: things like dealing with overlapping ranges, and how to dispatch to the DOM in general
<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: the other similar thing that comes up is other pseudo-elements
… is this a missed opportunity to fix that too?
… 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 buch 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: 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.
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?
RESOLUTION: Incubate this in CSSWG
dandclark: there's a section in the existing draft about this, which is just a missing section
… 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
RESOLUTION: Create a highlight L2 spec, dandclark is an editor
<TabAtkins> ol' D&D Clark, as I always read it
[selectors-4] Issue 11: Introduce pseudo-class matching when user changed the value of an input
github: https://
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
… 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://
astearns: should we resolve to work on this?
bramus: there seems to be a minor difference between :dirty and whether the user touched it
… 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: This in general sounds like a good area to explore
… I think we have talked about in the past about this but I can't recall where
… one question is what happens with autofill and similar interactions
<argyle> i found these very helpful in the past: https://
tantek: does autofilling + clearing it out get special treatment?
… there's a bunch of questions about what other states do we need to design for
… we might want to do some more research on that
<bramus> Good suggestion
+1, it seems there's a variety of different use cases that don't quite always match
flackr: I thought the autofilled text isn't exposed till the user interacts with the field
<tantek> I would also advise coordinating this exploration with #openui
flackr: which would suggest that naively that before you interact with the page it wouldn't be dirty
emilio: You're right we dont' 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
… but it seems we have more questions than decissions at this point
… so I wonder if we should take it to the issue again for now
… 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://
fantasai: there's been a variety of requests for controlling the length of underlines
https://
fantasai: we have some spec text to ensure that underlines break between words
… but we've been asked to provide more control
… suggestion is to define a new `text-decoration-trim` property
https://
fantasai: which would take a `<length-percentage>`
… and shortens the underline by the given amount
… there's the question of what's the percentage relative to
… so we could start with `<length>`
… on block containers we could apply it to both sides of the block
… on inlines it should follow the behavior of box-decoration-break
… negative values are allowed and would extend the text-decoration
… percentages were suggested to be relative to the containing-block
… there's some effect animating where that'd be useful for
https://
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`
… 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?
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
… should this have the same value?
… if you want the browser to trim by the right amount
… 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?
it's solving the problem documented in https://
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
… you might want to say "browser, just do something"
<faceless> Easy enough to define "auto" as "the width of the underline" perhaps?
florian: you could do "3px" or something, but then why that?
fantasai: I think the width of the underline was my initial thought
… 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 browsers want guidance here?
fantasai: I think we want to do that so people know what to implement
florian: I have wanted this without having an opinion on a specific value
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
… 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
jensimmons: separate for start/end could be declared all at once
… could see authors creating some kind of drop-shadow-like effects
jensimmons: specially when combined with underline offset/thickness
<dbaron> maybe also when combined with italic/oblique
jensimmons: there's the question of what happens with inline-box breaking
astearns: that's the part where it'd follow box-decoration-break
<Zakim> tantek, you wanted to ask about interactions with text-overflow
tantek: just wanted to add with potential interactions with text-overflow: ellipsis
… 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
box-decoration-break defaults to slice, which would get the behavior plinss describes
RESOLUTION: 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://
oriol: there are some properties than when set on autor/animation origin disable native appearance unless `revert` / `revert-layer` is specified
… for revert it makes sense
… since it always reverts to user/ua origin
… but revert-layer can revert to author origin
… and in this case it should disable native appearance
… all implementations already behave like this
… 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
… 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
so, +1
RESOLUTION: For properties that disable native appearance, do all the reverting, take into account the origin of the final cascaded value
[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent?
github: https://
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
smfr: I'd have to go back and ask the security ppl
chris: SVG images in <img> tag don't run scripts or fetch resources
<dholbert> smfr: RE where it's defined that SVG Images don't run scripts, that's defined in https://
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
<dholbert> see https://
astearns: When in <object> ...
<dholbert> "Secure animated mode"
chris: They can do everything
astearns: Are they SVG images?
chris: Yes, just not using an <img> tags
<smfr> dholbert: but HTML doesn’t reference that everywhere it needs to
emilio: From implementation point of view, they are iframes
<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.
chris: Also if displayed standalone, same thing
chris: they can run scripts, fetch resources, etc.
<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
<Zakim> fantasai, you wanted to propose resolution
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://
astearns: objections?
RESOLUTION: prefers-color-scheme in SVG rendered in secure animated mode is context-dependent
Meeting closed.
Meeting Registration (missed, goes first in the minutes)
astearns: If you think you might come to the F2F, please register into the wiki
https://
astearns: Also, TPAC 2022 registration just opened. There is registration both for in-person and remote attendance, so please register appropriately
[note there's a cut-off date for early registration pricing]