CSS content-visibility property

[vmpstr]

Bonjour TAG,

I'm requesting a TAG review of:

• Name: Display Locking
• Specification URL: none at this time
• Explainer, Requirements Doc, or Example code:
  • new explainer
  • WICG thread with explainers
  • Our github
• Tests: none at this time
• Primary contacts: @vmpstr @chrishtr

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[kenchris]

At TPAC, it sounded as there is some overlap between this and the Invisible Searchable DOM proposals and that you needed to work out what solution to promote or whether you could come up with a new joined proposal.

In the light of that, are you still looking for feedback on this proposal at this time?

@rakina

[kenchris]

Given the opposition from Apple and Mozilla (see WICG/virtual-scroller#164) is this moving forward, and worth out time to review in details?

[kenchris]

The URL (and hashchange) could change/fire with the find-in-page especially with the new scroll to text fragment feature https://github.com/WICG/ScrollToTextFragment/

[vmpstr]

Just to clarify your last point here, do you mean that it already should fire on find-in-page and scroll-to-text, or that we should update hashchange spec so that it fires on find-in-page and scroll-to-text?

When considering find-in-page specifically, which is a primary use case for us, I think it would be somewhat awkward to have hashchange fire on a find-in-page match (mostly since the hash part of the URL doesn't change). In order to satisfy our use case, it would also have to fire on the element that contains the find-in-page match text (as opposed to on the window), which adds to the awkwardness in my opinion.

I think we can safely drop fragment-link navigation (ie #id navigation) from beforematch since that can be handled by hashchange for sure. Although in my mind it still feels like it is useful to include it in beforematch.

[kenchris]

Yes, it would probably have to be a fragmentchange event or similar as we are changing the url fragments. I don't know if there are any plans to change the fragments when selecting a match using find-in-page but it could make sense for copying the URL instead of having to select the text and then generate a url with the right fragment

[domenic]

Although in my mind it still feels like it is useful to include it in beforematch.

Strong +1. It's better to leave hashchange for being dedicated to handling hash changes, and not force developers to structure their code like

document.addEventListener("beforematch", handleBeforeMatch);
document.addEventListener("hashchange", () => {
  handleHashChange();
  handleBeforeMatch();
});

Letting "beforematch" be the one-stop-shop for this sort of handling is a much more elegant and decoupled design, instead of taking a dependency on the incidental fact that we already have an event for 1 of 3 cases.

[kenchris]

Maybe we can find a better name than beforematch - it wasn't really clear to me when it would fire. Like if I do find-in-page for "firefox" and it finds 3 matches, will it fire for the second one just as I click on "move to next"?

It is also not clear that match relates to find-in-page etc

[vmpstr]

Like if I do find-in-page for "firefox" and it finds 3 matches, will it fire for the second one just as I click on "move to next"?

Yes, that's the intended behavior

Maybe we can find a better name than beforematch

That's fair, we're discussing it here: WICG/display-locking#115

[dbaron]

Strong +1. It's better to leave hashchange for being dedicated to handling hash changes, and not force developers to structure their code like

Yeah, I think that's fine. But I think it's worth mentioning the existence of hashchange in the explainer where you mention that use case.

[vmpstr]

After further testing (with @josepharhar's help), I'm no longer sure that my position of keeping fragment navigation is correct.

Specifically, script can change the hash and expect that the scroll be changed immediately. The way we've been thinking about beforematch is that its handler can and sometimes will change something about the rendering of the page that may shift elements around. It might be desirable to delay scroll until the event handler ran, but we can't do that for fragment link navigation without breaking the web.

I've filed WICG/display-locking#135 to discuss this further.

[vmpstr]

Hello,

We'd like to focus only on the CSS content-visibility property in this issue (contain-intrinsic-size and beforematch events should be discussed separately if needed). The current version of the spec draft can be found here:
https://drafts.csswg.org/css-contain-2/#content-visibility

We would appreciate another pass at this review!

Note: If possible please file an issue in https://github.com/w3c/csswg-drafts/issues/ with your feedback

[kenchris]

@vmpstr the spec doesn't have the hidden-matchable which the explainer says will solve use-case 2. Was that dropped and should the explainer be updated?

[atanassov]

@dbaron @kenchris and myself took another look this issue, now scoped to content-visibility only. It would be good to update the explainer to match the CSS Containment module, ex. the value hidden-matchable is no longer part of the spec.

We advise you to continue working with the CSSWG in completing the rest of the spec.

[vmpstr]

The hidden-matchable value is something that we would still like to pursue in the future but it would require a separate discussion / design review, as well as require additional features like #511 to be useful.

For now, we're focussing on the values outlined in the spec draft. I will update the explainer to separate the proposed values here from the possible new values that we are thinking of proposing.

Thanks!

[vmpstr]

I've updated this in the repo, hopefully the separation of the features is more clear now. https://github.com/WICG/display-locking/