- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Nov 2020 18:01:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-2] Proposal: content-visibility: hidden-matchable`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-contain-2] Proposal: content-visibility: hidden-matchable<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5595<br> <dael> jarhar: Last time we talked on this some concerns on a11y on this. Simon mentioned browsers indexing pages<br> <dael> jarhar: What I talked in GH for a11y there was discussion with jcraig and Alice which I hope resolve the a11y concerns<br> <dael> jarhar: Anchro navigations is interesting. The thing about adding before the element anchors we can't have async behavior when scripting. Even doing it on nav is breaking. Probably best to keep sync scrolling for the fragments<br> <dael> jarhar: Could fire before-match but then it would have different behavior than find in page. Could be cases with an element frag scroll before the lement is revealed but find in page is okay<br> <dael> jarhar: Gave example on mobile wikipedia where element fragment navigation works where you expand the fragment. I see argument of a one stop shop but on the other hand depending on how handler impl it might not reveal it on time and that might not be great<br> <dael> jarhar: It would be cool is smfr could expand more on how browsers index. Interested in supporting more.<br> <dael> jarhar: We could talk more about if people think this is the right idea if that's fine<br> <dael> astearns: First thing, concerns about a11y. Any comments or concerns on that discussion to bring up?<br> <dael> astearns: Okay, we'll assume GH was enough<br> <dael> astearns: Second is indexing pages<br> <dael> smfr: I need to figure this out. May be Safari looks at DOM so not an issue. I need to research more on that<br> <dael> jarhar: Thanks, I appreciate it<br> <dael> astearns: Extending proposal to anchor naivagations. You're proposing not to<br> <dael> jarhar: We could make it a one stop shop but might break some websites which expect the async behavior and you'd get different for find in page vs element nav. Anyone with thoughts on which idea sounds better<br> <dael> fantasai: I just don't understand events model. I haven't dug into it.<br> <dael> jarhar: Elaborating a bit. In chrome when I impl when Iput before match event for find in page it was async. Between text adn scroll I added event. Some sites in before match change the style async where it reveals after the scroll. TO support that we changed find in page scrolling to be async. Nothing breaks if we wait 2 animation frames.<br> <dael> jarhar: Added async to support this<br> <dael> jarhar: With element fragments it's a little more brittle. Sync behavior is more baked in. Making async is likely to break. Could keep it sync but it might not work on all sites. Want to avoid pages not revealing content on time due to security mitigations. It would be bad to have a page miss expanding content in responce to before match<br> <dael> fantasai: I think it makes sense.<br> <dael> fantasai: Concern is that I don't want us to be in a world where the behavior of an element target or ID targetting element has substantially different behavior thenusing text fragment style of ID content<br> <dael> fantasai: Having one of those expand a collapsed section and the other not is weird<br> <dael> jarhar: Makes sense<br> <vmpstr> q+<br> <dael> fantasai: I don't know how to solve technical end, but having behave different is not good<br> <dael> jarhar: scroll to text frag we were in better place b/c newer. When I made it async it didn't break<br> <tantek> with fragmentions the URL also changes, which I think is correct because it is analogous to fragment-ID navigation<br> <dael> fantasai: There's scroll to text fragment which is in URL and find in page which isn't URL. Having those different is better than having 2 types of fragment be different. Clicking on a paragraph and if it has an ID determines different behavior is bad. I don't have a solution<br> <dael> jarhar: Good concern. I can dig more and see if there's a way to make scrolling async for navigations. Might not be clear if I break anything but hopefully there's tests<br> <astearns> ack vmpstr<br> <dael> vmpstr: I wanted to point out that you metnioned should be no difference if linking with a fragment link vs scroll to text. Currently pages can expand fragment link nav. Not mech to expand a section when there's scroll tot ext fragment.<br> <fantasai> https://www.w3.org/TR/selectors-4/#the-target-within-pseudo<br> <dael> vmpstr: This prop brings parity to same level. Not same API but capability is the same<br> <dael> fantasai: I understand from you can get same functionality. But if there's a doc with collapsed section, some has ID and some don't. Asking for the ID shouldn't change if it closes or not. If author is expected to have 2 impl chances are they're impl the thing they thought of and one will uncollapse and the other won't<br> <tantek> TBH this is one of the problems with Google's scrollToText as compared to fragmentions. Pages can expand both fragment link nav *and* fragmention link nav, but not scrollToText<br> <dael> fantasai: More understandable if targets are different. Less okay if 2 different types of target have different behavior<br> <dael> fantasai: We do have target in pseudo class and that should be matched by text fragments and selectors. Styling-wise it can be done. Don't know JS stuff<br> <fantasai> s/target/:target-within/<br> <dael> astearns: And we are at time. I suggest we go back to see if there is a solution for fantasai's concern. Let's keep this on the agenda and bring it up at the beginning of the next call to answer if this is a good thing b/c I'd like to get you that answer<br> <dael> jarhar: Sounds great<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-729856163 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 November 2020 18:01:46 UTC