W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

Re: [csswg-drafts] [css-contain-2] Proposal: content-visibility: hidden-matchable (#5595)

From: vmpstr via GitHub <sysbot+gh@w3.org>
Date: Wed, 28 Oct 2020 21:55:00 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-718231170-1603922098-sysbot+gh@w3.org>
To recap, the proposal is to add a new keyword to `content-visibility`, called `hidden-matchable` which acts like `hidden` but allows searchability (find-in-page and scroll-to-text) and the [`beforematch`](https://github.com/whatwg/html/issues/6040) event.

------

In addition to @josepharhar's comments, I want to address another common question: should the default behavior of the beforematch be to un-hide the content automatically?

We've considered this in the past, and I think it adds to the complexity of the feature. I don't think there is an elegant way to un-hide the element when it's hidden by a css property: we can't modify the style sheet since the rule may be coming from some large class applied to a number of elements; we can either 1. add a pseudo class to keep the 'expanded' state or 2. modify inline style (ie set the style attribute on the element).

For 1, we then need a way to clear the pseudo class in order to hide the element again: Element.clearPseudoClassX? We can also clear it automatically if we remove the hidden-matchable property which means to hide something the script has to remove and re-add the property, which isn't ergonomic.

For 2, I think modifying inline style is awkward, especially if the page is using the style attribute for its own purposes (ie appending a new value to an existing string).

I think that requiring script to remove the value as a response to beforematch is the simplest approach. It also allows script to modify any other styles (e.g. change the orientation of the arrow in the section heading to indicate that its expanded), which is a common use case already.

------

For the details element, I think we can add an attribute to opt-in the details element into the behavior that it would essentially apply content-visibility: hidden-matchable and have a default handler that effective would remove it. In other words, we can make the details element be searchable and expandable with one attribute, but I feel that it is a separate discussion

-- 
GitHub Notification of comment by vmpstr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-718231170 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 October 2020 21:55:01 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:21 UTC