Meeting minutes
[css-anchor-position] Rename `anchor-default` to `position-anchor`
TabAtkins: We've set up a dichotomy in names for properties: the things that apply to positioned element start with position-*, the things that apply to the anchor start with anchor-*. anchor-default is the exception.
TabAtkins: so for better consistency and easier author handling of the mental model, we want to shift its name. The name from the Apple proposal was position-anchor.
<fantasai> +1
TabAtkins: so proposal is to rename anchor-default to position-anchor and leave everything else the same
kizu: as I mentioned in issue 30 mins ago, small issue is we have another proposal for position-container, which could potentially accept dashed ident. If both end up in shorthand for position there's a clash of 2 dashed idents. Otherwise seems like a good thing.
TabAtkins: we don't have a proposal for making a position shortand (yet), so I'm happy to leave that as a problem for future Tab to solve
fantasai: we should resolve whether or not the position property resets this
fantasai: that determines whether it could be in the shorthand in the future
fantasai: I think we should.
fantasai: In terms of shorthand syntax, we could use slashes to disambiguate, like we have in background shorthand.
TabAtkins: but position shorthand is a separate issue, we can resolve on the naming change first.
fantasai: I think we should decide whether it's reset by position.
TabAtkins: whether it's reset by the position shorthand won't changed based on what my call it.
fantasai: more or less natural based on name
TabAtkins: I'm trying to make incremental progress.
fantasai: then we definitely need a fololwup issue
Proposed resolution: rename anchor-default to position-anchor
RESOLUTION: rename anchor-default to position-anchor
ACTION: Tab: open a new issue about resetting of position shorthand
[css-anchor-1] Need ability to say "don't render" when anchor is off-screen
<fantasai> w3c/
fantasai: we discussed use cases about not rendering when stuff doesn't fit
fantasai: 3 major use cases (repeating the comment in the issue)
fantasai: (describes bullets 1-3 from w3c/
<fantasai> position-visibility: always | [ anchors-valid | anchors-visible ] || no-overflow
fantasai: (describes position-visibility suggestion from w3c/
fantasai: (finishes describing proposal)
una: I think this is really important for a lot of anchor psoition use cases. I don't want to block this but I wonder if position-visibility is the best name. Sounds like describing different behavior for position... maybe call something like position-behavior. When you said it it was clear, but looking at the names/keywords it wasn't as clear to me.
una: I don't want to bikeshed this forever but wondering if there are better names.
dbaron: When you said "like visibility: hidden", wondering if that was correct, or if stronger
… it normally contributes to overflow, can be overridden by descendants
TabAtkins: not "display: none" ish, because that modifies box tree
TabAtkins: stronger in that children can't turn off
TabAtkins: chrishtr suggests it does contribute to overflow, just turns off paint
TabAtkins: not display:none-ish because that changes the box tree. Shouldn't be stronger in that children can't turn it off (?). But chrishtr asking below for it to not suppress overflow. The argument seems reasonable to me. So I'm going to suggest we remove that part of the proposal and just suggest it turns off paint.
fantasai: I don't understand reasoning for that.
TabAtkins: The thing that it's overflow and the thing that it's setting its containing block might not have relation to each other.
TabAtkins: so being able to avoid setting contributing to overflow doesn't help too much anyway.
TabAtkins: There are several ways to raise the positioned element further up the box tree for these purposes so it won't care about sub containers anyway. e.g., a fix pos or top layer, or move higher in the dom. Can avoid scrollability issues that way.
There are ways around if there is a scroll problem. Even when you are not moving it around... in a place where it's potentially subject to it, not a strong connection there.
fantasai: I think wrong about not impacting scrollable overflow.
astearns: The conversation TabAtkins mentioned with chrishtr was about not having the no-overflow value?
TabAtkins: not about changing the values, just removing the rule about not contributing to scrollable overflow when it's hidden.
emilio: The "like visibility" thing made me think ... making it just suppress paint seems suspicious to me, you can still have things like focused elements inside. visibility:hidden does prevent focusability, but I don't think we want determining focusability to need layout. Has this been considered?
fantasai: That's why it should be like visibility, not just paint suppression: we want it to block hit testing, focusability, rendering into speech. And we don't want children to override it.
emilio: do you really want it not to be accessible?
fantasai: Yes. If it's not visible to sighted user, it shouldn't be accessible
emilio: it's accessible depending on the scroll position -- you're supposed to be able to scroll down and see it
TabAtkins: so why woud ???
emilio: also about search, find-in-page, etc.
emilio: a11y client may want to see contents of popup even if it's not visible
fantasai: If it scrolls off the screen that's fine, you can still access it. This is for cases where you want to hide it when it scrolls off.
fantasai: these are cases where you don't want the popup to be visibile based on where it lays out
TabAtkins: If you find-in-page... it still doesn't fit, it won't be displayed.
TabAtkins: not sure how we'd want to present the find-in-page result.
TabAtkins: It's possible moving things around might reveal it, but there's no straightforward way to determine how to do so. Depends on how fallbacks are set up. So I don't think there's an automatable way to expose the text inside to the user.
emilio: It would be exposed if it was clipped by... we don't have other precedent for scroll position affecting focusability. You can totally find-in-page and focus clipped and overflow:hidden text.
TabAtkins: You can scroll that in
emilio: you're never going to see it.
emilio: you have the same problem... but you still have the same problem.
emilio: a11y hacks rely on pushing stuff away from the viewport.
emilio: I think that and making element.focus() require layout are concerning. element.focus() is hot. Every engine goes through hooks to try to avoid work there.
chrishtr: why does it cause more layout?
emilio: You may be focusable if you're visible but not focusable if you're not.
emilio: you can't determine focusability only with style any more -- you need layout
chrishtr: if it's hidden but focusable then a sighted user could a thing they can't see is focused
emilio: That's my question -- a lot of things to do here. Just act like visibility. Maybe remove from a11y tree based on layout not a big deal?
TabAtkins: Container queries already put us in a situation where layout can affect a11y tree.
emilio: but they affect style
emilio: so different from an implementation perspective
TabAtkins: ...
emilio: engines try to avoid reevaluating ??? when CQ are in use.
emilio: I don't know at which stage you'd bring stuff back to live for a11y tree.
emilio: It's slightly different implementation-wise. You want it to keep generating boxes.
chrishtr: if you scroll so anchored element has to disappear because of offscreen, then you go back. And anchored element was focused before visible. You'd want it to retain focus when back on screen. That's what user would expect.
emilio: not what would happen when working with visibility
<vmpstr> this is what content-visibility: auto would work like fwiw
chrishtr: what if there was script that applied inert and removed it... does the focus come back if it's lost?
chrishtr: I don't think focus remembers?
emilio: There's a focus fixup in the spec. It checks whether the current active element is still focusable and blurs it if not... but doesn't remember the previous one.
<Zakim> jcraig, you wanted to ask if focus would scroll to visible and then cause render? and to ask or would search cause scroll-to-visible and then render
jcraig: Maybe a naive question... but curious if the view is in a state where if the user would tab to it, it would be a state where it would be focused and hidden. Would the focus cause it to scroll into visible and then render? Would in-page search have similar effect, would the search cause it to scroll into visible and then render? If so I wouldn't consider it a problem... but if scrolling wouldn't cause it to render that would be a
problem.
TabAtkins: 2 of the values not affected by scroll position or not. The third requires the anchor to be scrolled, which isn't the same as scrolling the popup into view and might not be possible anyway.
jcraig: if there's no scenario where a sighted user would expect focus to changge the visibility, then you'd probably want them hidden by AT by default as well.
<Zakim> dbaron, you wanted to react to emilio
dbaron: I wanted to say something close to what jcraig said
dbaron: my understanding is that you want AT to show similar to what's shown in other modes
… because you don't know what combination of things the user is using
dbaron: consider they might be using a mix of things, and want to be consistent
futhark: Wrt overflow contributing to overflow, wouldn't you get circularity?
futhark: if you remove scrollbars then it changes the anchor's position, gets more space, becomes visible, -> cycle
futhark: I can a comment on a separate part -- the overflow contributing to overflow. If it stops contributing to overflow, won't you get circularity with scrollbars? Or does that go into normall scrollbar handling?
TabAtkins: that is a possibility of circularity, but possibly solveable same way as tall element with aspect ratio
TabAtkins: That is a possible circularity, but maybe solvable like a tall element with an aspect ratio.
chrishtr: is that the same issue I mentioned in issue?
chrishtr: my suggestion was tooltip always contributing to scrollable overflow so you don't have layout circularity
<Zakim> vmpstr, you wanted to mention c-v
vmpstr: I wanted to mention content-visibility as one of the things that has semantics of not painting when offscreen but is still available to AT. Focus and find-in-page work in similar ways -- you do the rendering just-in-time to make sure the content is available. I fully realize here you're scrolling a different thing, but that's the only difference I see.
vmpstr: So I think there's a precedent for hiding this that are still available to assistive technologies.
kizu: I think both for an element impacting overflow and for a hidden element being able to be searchable/accessible -- both things we could want to control not just for popovers/anchors but for anything. Might want element to be there but not contribute to overflow (decorative). The same for searchable: you want to search something that's hidden by display:none/visibility:hidden/etc., want it to be present in search.
<Penny> I need to drop
kizu: I agree if it behaves like visibility:hidden should be hidden -- this ability to hide is for some optional thing that doesn't necessarily need to be displayed. For most use cases removing focus and not returning it back seems ok.
kizu: Can thingk of 2 ??: one is scroll driven animations.
kizu: I think it's possible to detect anchor outside of current overflow. ??
kizu: If you have a cursor and then scroll, cursor could affect elements based on :hover pseudo class.
kizu: I think it's ok for tooltips to disappear and lose everything inside because you don't see them anymore.
<Zakim> fantasai, you wanted to comment on why we need not contributing to overflow
fantasai: We don't these to contribute to scrollable overflow when they're hidden because it's an optional tooltip-ish thing that's nice to have if there's room. If it's overflowing the scrollport you don't want to introduce scrollbars to accomodate an invisible thing the user can't see.
<masonf> Don't those scrollbars indicate to the user that there might be something down there to scroll to?
fantasai: That's not a good user experience. The point of hiding this is that when the condition occurs, the item isn't relevant enough to display it.
<masonf> (Like the hidden popover?)
fantasai: If it's not display it should behave like it's not there.
fantasai: We didn't want to make it display:none because that has side effects we don't want.
fantasai: But we want the page to behave as if it wasn't there for visible rendering and for layout. suprress rendereing, events, being in a11y tree. That includes not contributing tos crollable overflow.
flackr: I heard a bunch about scrolling the anchor into view: I think we might want to spec that focusing something in the anchored thing, we might want to scroll the anchor into view. Should think whether that makes sense in all conttexs.
<TabAtkins> If we did "scroll the anchor into view", we'd have to key it off the default anchor.
flackr: For contributing to scrollable overflow: there may be use cases on theo pposite side. May be some cases where you want to have room to show. I thought we have another CSS property for whether thigns contribute to scrollable overflow.
<chrishtr> w3c/
TabAtkins: Don't have it yet, have an open issue for it.
flackr: yeah, meant we have an open issue.
flackr: If we resolved on that issue we'd have a way for authors to choose one method or the other.
astearns: in the proposal it mentions the new overflow value would apply even when using abs pos or fixed pos. Maybe that's an indication it belongs in the more general property.
<Zakim> jcraig, you wanted to respond to vmpstr comment re: content-visibility "not painting when offscreen but is still available to AT."
jcraig: Responding to earlier comment about precedent for having hidden contents interactable with AT. Typically what's available when something's off screen is the ability to find it and bring it on screen when the user interacts with it. If you have negatively positioned content, e.g., way off to the left, that isn't something we can ever scroll to. If you use that for the old "skip to main content" link. Then there's a time when...
jcraig: AT is interacting with something offscreen. Exposure to AT often means ability to search/find and bring into view, at which time its rendered and the AT user can interact with it. So I think there's a distinction between "available for AT to bring something into view" and "available for an AT user to interact with while still offscreen/unrendered".
chrishtr: I think I'm convinced by kizu's comments about developers intentionally making things hidden. I think anchored element is important to the user in relation to other thing, that's no longer on the screen. If tha were scrolled back onto screen, then it would be on the screen and things would be consistent. So I think I agree it makes sense to hide it for all of them, or bring it back for all of them.
chrishtr: Re scrollable overflow: the anchored element contributes to scrollable overflow whether hidden or not hidden. So the issue about scrollabrs that might not make sense would potentially apply in either case.
chrishtr: as TabAtkins mentioned there are ways to avoid that problem and meet needs of anchor positioning.
chrishtr: So I think that's not a necassiry feature for useful anchor positioning on the web
chrishtr: I think worth considering another CSS property about whether element contributes to overflow.
chrishtr: another use case is transformed elements
astearns, we'd like to get a resolution to republish before closing the meeting, even if these issues stay open
emilio: I wanted to ask flackr if other use cases for contributing to scrollable overflow or not -- but afaict the separate property wouldn't allow to not contribute only when hidden.
<astearns> fantasai: ack
flackr: I was saying if you set the property to not contribute to overflow, then you'd always be in the case where there wasn't sufficient space to match the position-try blocks
emilio: not sure i follow, but maybe not important
emilio: other thing: not sure if we have a similar issue for ... gecko has a mechanism to hide something visually but not from AT. I guess that could also be useful here.
khush: Did I understand chrishtr correctly: if anchor is offscreen which causes anchor to be hidden -- you can't use find-in-page to search fortext in anchorede elemnt?
<flackr> To be more specific, I was arguing that I don't think authors need to conditionally contribute to overflow, either always contribute or never (and sometimes not be possible to show the anchored element).
chrishtr: yes... reasoning is that the anchored element is important only in relation to the anchor. If developer specifies hidden thing then developer says it's not relevant when offscreen.
chrishtr: default value of this property would still be visible always
khush: Definitely cases where want to search for text in anchored element... but seems find given default.
chrishtr: polyfills sometimes put visibility:hidden which has same effect as what we're discussing
astearns: A few ways forward. I think we mostly agree this is useful and needed for some use cases.
astearns: I think we could continue discussing in issue. Could resolve on putting proposal in spec or opening separate issue in the spec. Or could resolve on adding a subset that we agree on into the spec.
fantasai: my impression is that there's a lot of confusion about what this is and what it ought to do.
fantasai: I think TabAtkins and I need to clarify that or explain it better or work with bramus on demos or something.
fantasai: I don't feel strongly about putting in draft or not.
fantasai: but I would like to publish the current draft as is.
fantasai: so maybe we add this into the editor's draft after we publish
TabAtkins: I didn't see much confusion -- but also don't see how we can subset it.
TabAtkins: so my preference is either to continue discussing, or put it in the spec with inline issues.
astearns: I like the idea of publishing as-is and adding to ED right after
chrishtr: should we resolve on what should be in ED spec? everything hidden?
astearns: guessing having a particular position in the ED may make it easier to discuss alternatives. Having a stake in the ground in the ED can be a good way forward.
astearns: so what exactly would we add to the ED?
fantasai: My suggestion is adding what TabAtkins and I originally proposed, and then mark the open questions against it.
chrishtr: would you mind removing the scrollable overflow part, or prefer not to?
fantasai: I'd prefer not to... but happy to mark that as an issue. Issue largely around circularity.
Proposed resolution: Add position-visibility as proposed in the issue with concerns noted as issues in the draft, to the editors draft *after* publication of working draft.
RESOLUTION: Add position-visibility as proposed in the issue with concerns noted as issues in the draft, to the editors draft *after* publication of working draft.
<khush> One more sub-issue that can be done in a follow up, define what "offscreen" means for the anchor.
Republishing Tasks Permathread
Proposed resolution: publish an updated WD of anchor-positioning
RESOLUTION: publish an updated WD of anchor-positioning
fantasai: so we'll fold in the position-anchor/anchor-default rename and then publish
[5 minute break]
github-bot, topic w3c/
[css-view-transitions-2] Allow changing `types` using JS after (MPA) transition started?
<github-bot> OK, I'll post this discussion to https://
noamr: These issues are related, and not very big, just finishing up
noamr: We want to make types mutable.
noamr: Refresher, types let you define a "masterclass" for the whoel transition. Set a type when you start the VT, can pass types to the function, then can select based on that type with the VT pseudos
noamr: So you can use several transition styles in the same page without having to manually swap them out with JS
noamr: So we wanted to allow changing those types on the VT object.
noamr: Proposed resolution has details, but it's to have .typeList on the VT object, a DOMTokenList like .classList
noamr: And it works just like changing classes
noamr: We foudn this useful for cross-document VTs
noamr: sometimes, only after you get the reveal event you know what the type is gonna be
noamr: maybe some image you expected has or hasn't loaded in the new page, etc
noamr: So changing the types seems flexible enough
astearns: when you change the typelist in JS, it will no longer match what was specified in your CSS for the VT
astearns: I'm guessing that's okay and intended, because as the VT is going you maynot have access to that CSS anymore
noamr: Right. First for SPA VTs you define the types in JS anyway. For cross-doc tho, you're correct
noamr: We read the VT from CSS in exactly two places - when you're ready to leave the old doc, and ready to present the new doc.
noamr: In these cases we'll read the CSS, then in the events you can change the types via the VT object
bramus: Like this in general.
bramus: Maybe we should also rename the types property that we pass into the VT starting function
bramus: it's "types" in one function, "typeList" on the VT object
noamr: Yeah, it's called "type" when you start the VT, but there it's an array, here it's a token list. This is equivalent to "class" and "classLIst"
bramus: Ah then there's a typo in the spec saying "types"
noamr: Ah I'll fix
astearns: proposed resolution: mutable .typeList on the VT object. Objections?
RESOLUTION: Add a mutable .typeList to the VT object
github-bot, topic w3c/
[css-view-transitions-2] Behavior of mismatching types between old and new document
<github-bot> OK, I'll post this discussion to https://