Meeting minutes
<JakeA> TabAtkins: I guess the "(if it exists on the element)" bit is redundant then
Keyframe offsets outside of the animations
github: https://
Rossen_: Proposed resolution linked in the agenda
flackr: with sla, especiallyw ith dynamicly defined keyframes, you can end up with offsets outside the range
flackr: Proposed solution is to allow these. They don't change the animation's active duration, but their effects still apply and just get clipped to the end of the animation duration.
flackr: But don't allow it for classic animations, due to possible compat (negative %, >100%)
+1 to this
we allow overshoot in other places like gradients
RESOLUTION: Accept proposal to allow keyframes outside of the animation's duration.
JS API for view-timeline-inset
github: https://
flackr: Proposal was to allow insets in the ViewTimelineOptions object as either a string or a pair of CSSNumericValues
flackr: But I recalled on other issues there were parsing concerns for things other than idents
flackr: So i pinged Tab on this issue
flackr: So yes we should add this attr, but should it support strings?
TabAtkins: While we aren't 100% consistent, we try to avoid doing CSS parsing on small instances of CSS values
… in APIs like this
… because in the rare cases where you need to do an escape, it needs to be double-escaped
… The general rule for identifiers is that we don't parse stirngs [missed]
… You can express any string as an ident if it's properly escaped
… [something else]
… So I proposed not allowing string-based values here, and just sticking with the TypedOM objects
… They're easy to work with
flackr: should still allow string for auto
TabAtkins: especially because we need to allow identifiers, we'd need to do string parsing in identifiers
… if you wanted a name with a weird thing, would need to double-escape
… would have string just be the literal value of the string
… which means we can't mix keywords with other values in strings
fantasai: I think the arg for wanting to allow string-based is that you can pipe getComputedStyle() right back into it
fantasai: and just easier to write as a literal "2px" rather than CSS.px(2)
fantasai: re ident escaping concerns, there's no custom idents in this API so escapes are never necessary anyway
flackr: I'm a little curious - if we want to use typedom objects going forward, is there easy ways to get that?
TabAtkins: There's a TypedOM for computed style
… not all values have that defined, but for simple things it should work
… for more complex ones, will just get a string
flackr: so maybe that alleviates some simple concerns
fantasai: Well what's the computed style of -inset? It's one or two values, so what will we get out of typed om computed style?
flackr: this is a new property, we can define it to be what we want for the input
fantasai: So what would that be?
flackr: A sequence of numeric or identifer values
<dbaron> https://
flackr: So I propose we onlya ccept the typedom representation, and specify the computed typed om for the property to give the same values, to support passthru
dbaron: is the API not gonna work right if the impl wants to do this without typed om?
dbaron: I ask because typedom is implemented right now in chromium but not gecko or webkit
flackr: sounds like it would be an issue
<iank_> I believe webkit has an implemtnation just not shipped yet
fantasai: What's the downside of stringbased?
fantasai: If we have both you can use whichever is easiest
<ydaniv_> +1 for both
TabAtkins: my only concern is impl complexity, and slightly being more consistent about parsing css vs taking strings literally, but i can go either way
Proposed to accept both string and TypedOM 2-value sequence inset within ViewTimeline Options
PROPOSED RESOLUTION: Insets accept either a string or a sequence of typedom values
chrishtr: Do we need to specify how the string is parsed?
flackr: Matches the CSS property
RESOLUTION: Insets accept either a string containing CSS, or a sequence of TypedOM values.
Proposed that existing ViewTimeline.startOffset and .endOffset attributes incorporate inset calculations (so that they continue to accurately represent the start/end scroll offsets of the ViewTimeline within the scroll container).
<flackr> +1
<ydaniv_> +1
<bramus> +1
RESOLUTION: Existing ViewTimeline.startOffset and .endOffset attributes incorporate inset calculations
fantasai: final, do we expose the inset values on the timeline itself? doesn't seem to be use-cases. But we *could* add an inset or startInset/endInset to the timeline if we wanted to.
<flackr> +1 to deferring for now
<flackr> (this is resolution 3 from https://
fantasai: not sure if it needs to be done or not, so unless someone thinks it's important we recommend resolving not to do it for now
RESOLUTION: Defer adding inset properties to the timeline object
Declarative anchor fallback positioning
github: https://
TabAtkins: At previous meeting when introduced anchor positioning
TabAtkins: Emilio brought up that XUL had similar functionality, and had a simple declarative way to express fallbacks
TabAtkins: This is good, current fallback is very complex
TabAtkins: I have a proposal in this thread for solving that
TabAtkins: Can still use full complex positioning if necessary, but this should solve common cases
TabAtkins: Not looking for resolution right now, just wanted to get attention for review and comment
iank_: Can you briefly describe this mode?
TabAtkins: The way you opt into it, rather than declaring a side to align to in the anchor
TabAtkins: Instead you say "auto", and it will automatically choose the opposite side of the property you're setting
TabAtkins: but if you would trigger fallback positioning, we flip around
TabAtkins: and align your bototm edge to the top edge
TabAtkins: so we can do this positoining without affecting layout
TabAtkins: then if neither works, we go to normal fallback rules
iank_: idk that you need auto on opposite side
iank_: how does this interact with maximum number of fallbacks?
TabAtkins: need auto on other side because if not, there's nothing to fall back to
TabAtkins: If you specify this for your top property, we can't switch to using bottom if your bottom is zero
iank_: ok
TabAtkins: wrt maximums, this will be part of that list
TabAtkins: effectively position fallback will have an extra entry, so this will be factored into that maximum
iank_: does this mean you need to set on both insets?
TabAtkins: no, set one to anchor and the other to auto
TabAtkins: it will be naturally sized
TabAtkins: we'll swap the properties if we need to for fallback reasons
[note that auto is the initial value]
iank_: You can embed an anchor inside of a calc() expression
iank_: so if you're not using the ?? anchor, what does that calc expression resolve to?
TabAtkins: after doing the flip?
TabAtkins: it resolves to the appropriate other edge
TabAtkins: Luckily because insets are specified in opposite directions
TabAtkins: if you use calc() to put you 10px from bottom edge, that same calc will work against the top
iank_: so you're taking the whole calc() and putting it in the other property, and the other property becomes auto?
TabAtkins: yes, we resolve exactly as if you'd done it on the other side
TabAtkins: just as position fallback already works, but we make it automatic for obvious placement
iank_: sounds fine, just concerned about magical swapping of computed values at layout time
TabAtkins: This is exactly position fallback, the same feature, we're just giving you one for free
iank_: not exactly, because you're taking e.g. top is auto, bottom is calc expression with anchor
iank_: the position fallback then is like the top becomes that calc function and bottom becomes auto
iank_: oh, and I see, you're saying that this will automatically populate a fallback position entry with those two things
iank_: okay, that makes sense
iank_: if you can write that as a note, this is how it should be implemented, that would be helpful
fremy: Small question
fremy: because I believe this would be common
fremy: what happens if you do it for top and left, and if so what happens?
TabAtkins: what exactly will happen is a great question, which I have not thought through the implications of!
TabAtkins: I don't have an answer for you yet.
TabAtkins: I don't think it's hugely important what the answer is... worst case maybe generate 3 fallbacks, generating vertical flip, horizontal flip, or both
TabAtkins: will think about it
<iank_> likely want the flips in the logical space vs the physical?
fremy: I guess maybe we can check what tooltips do on iOS/MacOS/Windows
<iank_> block flip vs. vertical flip
+1 iank
TabAtkins: just wanted to get feedback, this was helpful
well, doesn't matter, point is you flip to the opposite side of wherever it's specified
Add view() to animation-timeline
github: https://
PR: https://
flackr: so we defined scroll() for anonymous timelines, but htere was no convenient way to describe an anonymous view timeline
flackr: I believe elika already has a PR for this, so asking for resolution to use that
https://
<bramus> +1 on resolving.
TabAtkins: I assume that anonymous view timelines work similar to anonymous scroll timelines? Just look in the tree for the nearest obvious thing?
fantasai: Yes, it looks up to the nearest scroll container
+1
ACTION: fantasai: clarify that it applies to the element it's specified on
RESOLUTION: Accept fantasai's PR for adding view() function to animation-timeline
Additional resource-state pseudo-classes for img/picture
fantasai: someone asked about pseudos for images to indicate whtehr they're loading, failed, stalled
fantasai: So does the WG think this is reasonable?
<dbaron> I think Gecko has internal pseudo-classes that do this
fantasai: do we make loading & buffering both amtch when a video is trying to buffer and when an image is loading?
TabAtkins: Like allow both to apply to either condition?
fantasai: Yeah they're both loading, tho i'm not sure if the words are appropraite
TabAtkins: I'm happy to defer that to editors
<bradk> applies to any element that can take time loading, eg iframes?
Rossen_: Sounds like there's general approval, should we reoslve on "yes, details TBD"?
<bradk> +1
<bramus> +1
<chrishtr> +1
fantasai: We can propose edits and come back.
Allow more pseudo-classes after pseudo-elements
TabAtkins: Currently, pseudo-elements allow a few pseudos to be put after them, :hover etc.
TabAtkins: question is whether to allow combinatoric ones (:is()/:not()/:where()) to be applied as well
TabAtkins: Further, some pseudo-elements represent specific elements elsewhere in the DOM
TabAtkins: wondering if specific pseudo-elements can opt into allowing additional pseudo-elements
TabAtkins: but that's a different issue
TabAtkins: but first issue, allowing combinatoric ones
TabAtkins: Contents are still restricted to the user-action pseudos
JakeA: we're interested in this for view-transitions
JakeA: want to know if old or new view is only-child
JakeA: so allowing that would be useful
fantasai: two issues, one is we have a set of pseudos that are already allowed, and do we allow them to be put in :is()/etc
fantasai: second is allowing other pseudos on case-by-case basis, we should talk about that separately
fantasai: for is/not/where, it's about whether we can express the combinations of the user action pseudos
https://
<tantek> could see this being useful for webdevs
oriol: these use forgiving parsing, would invalid pseudos be valid within them?
TabAtkins: yes
TabAtkins: this would allow more safely adding more pseudo-classes to a selector in the future
Rossen_: any other opinions?
TabAtkins: proposed, allow the "logical combination pseudo-classes" after pseudo-elements, with their contents having the same restrictions as the pseudo-elements themselves otherwise would have
RESOLUTION: allow the "logical combination pseudo-classes" after pseudo-elements, with their contents having the same restrictions as the pseudo-elements themselves otherwise would have
fantasai: and more generically i want to resolve that the logical-combo pseudos can be used *anywhere* their contents are allowed
TabAtkins: I agree with being more generic if we can get away with it
fantasai: wanted to ask if anyone saw a problem with that
<tantek> no objection
(Don't think there's much issue beyond just implementing it.)
RESOLUTION: Allow the logical-combination pseudo-classes generically, anywhere their contents are allowed.
TabAtkins: Second part of issue, should we allow additional pseudo-classes other than user-action pseudo-classes to be put after pseudo-elements?
fremy: On previous resolution, does that mean you can change styles on ::before:hover ?
TabAtkins: yes
fremy: what if you create a loop with ::first-line:hover?
TabAtkins: hover loop, we already have that problem
Consider p:hover ::first-line
fremy: ok
<JakeA> I'm still +1 this
<bradk> +1
TabAtkins: back to issue, should we allow lifting restrictions on pseudo-elements followed by pseudo-classes?
<argyle> +1
<miriam> +1
fantasai: Okay as long as we do it as an allowlist, rather than blanket allowing
JakeA: would folks be happy with us using :only-child for view transitions?
TabAtkins: As long as it matches intent
TabAtkins: defined as up to two children, and this one says if you have only one
JakeA: But usually it doesn't count pseudos...
JakeA: but I guess if we're appying it to a pseudo
<bradk> :only-pseudo-element?
TabAtkins: pseudo-elements live in the tree
RESOLUTION: Allow pseudo-elements to define additional pseudo-classes they allow to be placed after them.
Paired defaults
gitub: https://
delan: This issue won't affect implementation complexity much, about what makes sense to authors
delan: some highlight pseudos have default background color and default color
delan: e.g. ::selection has default colors
delan: and ::target-text
delan: but it's not true for e.g. spelling/grammar error, where default styles add squiggly lines but don't change colors
delan: ::selection has special behavior called "paried defaults"
delan: rule is there for compat reasons
delan: means that those default colors only get used
delan: if neither color nor background was set by the author
delan: beside compat, has some other benefits
delan: prevents illegible combination of colors
delan: e.g. some browsers have light text for selections, and some have dark text
delan: so question is, should these apply to other highlight types?
delan: or only to ::selection?
florian: Point about default colors being relied on makes sense, so I would say yes it should apply to all
emilio: Gecko doesn't have this magic if the author specifies selection styles
emilio: do you know the state of interop?
delan: it's also in Gecko
emilio: if you specify ::selection { background: green ; color: green; } we wouldn't magically infer the color
delan: that's separate
delan: this is if the author only sets one of these properties, does it get the UA color or does it get transparent/currentcolor
delan: inverting is a separate issue
florian: If we don't do it we have a risk of browser-dependent illegible things, and that's bad
fantasai: I think propsoed resolution is, do we apply paired defaults to all highlights
fantasai: so do we have any objections? if not we can resolve
delan: so resolution is that they would apply to all fo the highights?
fantasai:
florian: we have delan, fantasai, and myself agreeing and nobody is pushing back
Rossen_: I'm not hearing any objections, so let's resolve
Rossen_: if anyone thinks about this we can come back and change if necessary
RESOLUTION: paired defaults apply to all highlights
Rossen_: Happy Thanksgiving for those in the US
Rossen_: Remember next week is a long call, starts 7am Pacific for 3 hours
Meeting closed.