[openable] how should we support find in page?

[lukewarlow]

Currently the openable explainer plans to use hidden=until-found attribute value pair with some special handling such that openables can be searchable.

Is this the correct choice?

The proposed UA styles were potentially naive based on how complex the hidden=until-found styling is in chrome.

1. Hidden attribute isn't implemented purely in UA stylesheet, as such the styles have a higher specificity than if they were, this means that my proposed styles won't actually work. In my prototype I had to use !important which is undesirable.

2. I used revert but that probably isn't the correct value for a UA style.

Given this complexity is it better off being a different mechanism such as openable=searchable? Would this have essentially the same issues given we'd probably share code between the two mechanisms?

[brechtDR]

Especially when going on the route of changing to openable based on viewport or other metrics. I think searching inside (and potentially automatically opening) when using find in page on the browser could be beneficial.

[brechtDR]

Just a note, I have two thoughts on this:

• Opening items when a user search could result into unwanted change on the screen which might not be nice for users
• Blocking it on the other hand, can have a negative accessible impact.

Providing an option would leave this choice in a developer's hands, but then the question would remain: which is the default?

[sorvell]

Relying on content-visiblity means generating boxes which seems potentially cumbersome since openable may be applied to elements that have unwanted default box styling (e.g. padding / margin / border).

I guess this is potentially contentious, but independent of a11y concerns, it seems really useful for UIs like tabs or chrome://settings.

which is the default?

IMO, the default should be findable.

[css-meeting-bot]

The Open UI Community Group just discussed [openable] how should we support find in page?.

The full IRC log of that discussion

<scott> q+
<hdv> lwarlow: we decided basically to allow searchable and non searchable. By default now the openable would be display:none on page load, if you want it to be searchable you can use the hidden until found attribute
<sorvell> q+
<hdv> lwarlow: the attribute won't be removed if you have hidden=untilfound
<bkardell_> does hiddenuntilfound work on a `<div style="display: none">`
<hdv> lwarlow: if it's openable and doesn't have hidden=until-found, we could undo the UA style
<hdv> lwarlow: when I looked at this in Chrome, hidden=until-found is not a UA style, which I expected, therefore has higher specificity
<masonf> ack scott
<masonf> q+
<hdv> scott: I don't have an answer to your question… but wanted to reiterate… I prefer 'not findable by default'… because in a lot of use cases I'm thinking of, are like expand/collapse navigation lists… the collapsing things would be things I would not want to find searching the page
<hdv> scott: a lot of authors don't think to change things beyond the default, so I'd like this feature to be optional, it's great to exist as something people _can_ do
<lwarlow> +1 to what Scott is saying
<masonf> ack sorvell
<hdv> sorvell: to me the content visibility thing seems broken to me, in this context specifically
<hdv> sorvell: seems problematic, because one of the reason we're adding this is so we can put it on elements like a table row or list item that have box styling by default, that would probably suck to have default to be on
<hdv> sorvell: if it's openable and not opened, I don't see a use case where you'd actually draw a box
<lwarlow> q+
<hdv> masonf: I see the point, downsides both ways… downside of not findable by default, it's 'I can't find stuff, I know it's here'… but downside of findable by default is to have bits of UI show up everywhere it could be weird and not what i'm finding for
<keithamus> qq+
<keithamus> ack mason
<masonf> ack keith
<Zakim> keithamus, you wanted to react to sorvell
<hdv> keithamus: to comment on 'frustrating thing': that's probably because it is the status quo… ?
<masonf> ack lwarlow
<masonf> q+
<keithamus> q+
<hdv> lwarlow: two points: the way in which we decide the default, should include what the user wants and what the author wants.
<hdv> lwarlow: based on use cases Scott mentioned I lean towards not doing it by default
<hdv> lwarlow: could potentially a browser setting too
<scott> q+
<hdv> lwarlow: where I'd consider to use this, is stuff where I wouldn't want it to show up
<scott> q-
<hdv> lwarlow: if I'm on a page and searching for 'proposal' I wouldn't want the sidebar that was visible until then to pop up in front of me because it happens to contain that word
<hdv> masonf: in any question re defaults… we see a lot of use cases… one way to deal with that could be that everyone has to choose every single time, eg when you add openable you must choose re findable in page
<sorvell> q+
<hdv> q+
<hdv> masonf: maybe could have a giant button to allow 'find everytihng'
<masonf> ack mason
<hdv> scott: I'd like that
<hdv> scott: eg using this on table rows, like tree grids. You could have a series of rows that you collapsed because you don't want to interact with them, if the search finds them that's not what you want
<masonf> ack keith
<hdv> keithamus: I do think it shouldn't be by default … in GitHub, for details, we use them all over the UI, in a lot of areas where we woulnd't want things to randomly open because of a substring match
<hdv> keithamus: but people can use it in our content editor too, people usually put a lot of content inside <details>/<summary> to make issue descriptions etc more clear, there maybe you would want to find
<hdv> keithamus: in this proposal, it's more of a primitive, so the use cases are less defined then details element
<masonf> ack sorvell
<hdv> sorvell: just wanted to reiterate again, the reason not to use hidden=until-found is because it has behaviour of content visibility
<hdv> q-
<hdv> sorvell: that seems problematic to me
<hdv> lwarlow: does it draw the box for hidden=until-found now?
<hdv> sorvell: yes
<hdv> masonf: but with details/summary?
<hdv> lwarlow: is a separate thing
<hdv> sorvell: don't think we should ever draw a box just for findability
<hdv> lwarlow: willl have a think on potential solutions
<hdv> lwarlow: optin would either be enum value, not going to break compat
<hdv> lwarlow: we can agree not searchable by defualt
<lwarlow> https://github.com//issues/1157

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.