Extra Particulars on `particulars` | CSS-Methods

A variety of chatter across the ol’ <particulars> and <abstract> components currently! I noticed Lea Verou lately tweet an commentary in regards to the aspect’s show habits and that sorta splintered into extra observations and utilization notes from of us, together with a revived dialogue on whether or not <abstract> must be allowed to comprise interactive components or not.

There are a number of dots to attach and I’ll do my finest right here to do precisely that.

Can we alter the show of components nested within the <particulars> aspect?

Tremendous bizarre! If we crack open DevTools, the consumer agent stylesheet tells us <particulars> is a displayed as a block aspect.

Discover the required <abstract> aspect and the 2 extra <div>s in there. We will override the show, proper?

What we would count on is that <particulars> now has an express peak of 40vh and three rows the place the third row takes up the remaining house leftover from the primary two. Like this:

Ugh, however the third row doesn’t… do… that.

Apparently what we’re coping with is a grid container that’s unable to use grid habits to its grid gadgets. However the HTML spec tells us:

The particulars aspect is anticipated to render as a block field. The aspect can be anticipated to have an inside shadow tree with two slots.

(Emphasis mine)

And a bit of later:

The particulars aspect’s second slot is anticipated to have its type attribute set to “show: block; content-visibility: hidden;” when the particulars aspect doesn’t have an open attribute. When it does have the open attribute, the type attribute is anticipated to be faraway from the second slot.

(Emphasis mine, once more)

So, the spec says the second slot — the 2 extra <div>s from the instance — are solely coerced into being block components when <particulars> is closed. When it’s open — <particulars open> — they need to conform to the grid show that overrides the consumer agent styling… proper?

That’s the talk. I get that slots are set to show: contents by default, however jamming nested components into slots and eradicating the power to type them appears off. Is it a spec concern that the contents are slots, or a browser concern that we can not override their show despite the fact that they’re within the field tree? Smarter folks can enlighten me but it surely looks like an incorrect implementation.

Is <particulars> a container or an interactive aspect?

A number of of us are utilizing <particulars> to toggle menus open and closed. It’s a observe popularized by GitHub.

Appears affordable. The spec certain permits it:

The particulars aspect represents a disclosure widget from which the consumer can acquire extra info or controls.

(Emphasis mine)

Alright, so we would count on that <particulars> is the container (it has an implicit position=group) and <abstract> is an interactive aspect that units the container’s open state. Is smart since <abstract> has an implcit button position in some contexts (however no corresponding WAI-ARIA position).

However Melanie Sumner did some digging that not solely appears to contradict that, however results in the conclusion that utilizing <particulars> as a menu most likely ain’t one of the best factor. See what occurs when <particulars> is rendered with out the <abstract> aspect:

It does precisely what the spec suggests when it’s lacking a <abstract> — it makes its personal:

The primary abstract aspect baby of the aspect, if any, represents the abstract or legend of the main points. If there isn’t any baby abstract aspect, the consumer agent ought to present its personal legend (e.g. “Particulars”).

(Emphasis mine)

Melanie ran that by way of an HTML validator and — shock! — it’s invalid:

So, <particulars> requires the <abstract>. And when <abstract> is lacking, <particulars> creates it’s personal, although it’s relayed as invalid markup. It’s all hunky-dory and legitimate when <abstract> is there:

All of which ends up in a brand new query: why is <abstract> given an implcit button position when <particulars> is what seems to be the interactive aspect? Maybe that is one other case the place the browser implementation is wrong? Then once more, the spec does categorize each as interactive components. You possibly can see how totally complicated all of this turns into.

Both method, Melanie’s final conclusion that we should keep away from utilizing <particulars> for menus is predicated on how assistive tech reads and publicizes <particulars> that comprise interactive components. The aspect is introduced, however there isn’t any point out of interactive controls past that till you, er, work together with <particulars>. Solely then will one thing like a listing of hyperlinks be introduced.

Apart from, content material inside a collapsed <particulars> is excluded from in-page looking (besides in Chromium browsers, which may entry the collapsed content material on the time of writing), making issues much more tough to search out.

Ought to <abstract> permit interactive components?

That’s the query posed in this open thread. The thought is that one thing like this might be invalid:

<particulars>
  <abstract><a href="https://css-tricks.com/more-details-on-details/...">Hyperlink aspect</a></abstract>
</particulars>

<!-- or -->

<particulars>
  <abstract><enter></abstract>
</particulars>

Scott O’Hara sums up properly why this is a matter:

The hyperlink is just not discoverable in any respect to JAWS when navigating with its digital cursor. If navigating to the abstract aspect through the Tab key, JAWS publicizes “instance textual content, button” because the identify and position of the aspect. If hitting Tab key once more, JAWS once more publicizes “instance textual content, button” despite the fact that keyboard focus is on the hyperlink.

[…]

There’s extra I might go on about with the assorted issues completely different AT have with the content material mannequin for abstract… however that might simply lengthen this remark out past what is critical. tldr; the abstract content material mannequin produces very inconsistent and typically simply flat out damaged experiences for folks utilizing AT.

Scott opened tickets to right this habits in Chromium and WebKit. Thanks, Scott!

But, it’s legitimate HTML:

Scott goes additional in a separate weblog publish. For instance, he explains how slapping position=button on <abstract> would possibly appear to be an inexpensive repair to make sure it’s constantly introduced by assistive tech. That might additionally settle the talk over whether or not <abstract> ought to permit interactive components as a result of buttons can not comprise interactive components. The one downside is that Safari then treats <abstract> as a normal button, which loses its expanded and collapsed states. So, the right position is introduced, however now its state is just not. 🙃

The place will we go now?

Are you scared to make use of <particulars>/<abstract> with all of those points and inconsistencies? I certain am, however solely insofar as to ensure that what’s in it gives the appropriate type of expertise and expectations for customers.

I’m simply glad these conversations are taking place and that they’re going down within the open. Due to that, you possibly can touch upon Scott’s three proposed options for a way the content material mannequin for <abstract> is outlined, upvote his tickets, and report your personal points and use instances when you’re at it. Hopefully, the higher we perceive how the weather are used and what we count on them to do, the higher they’re carried out.