Extra Particulars on `particulars` | CSS-Methods

Plenty of chatter across the ol’ <particulars> and <abstract> parts currently! I noticed Lea Verou just lately tweet an commentary concerning the ingredient’s show conduct and that sorta splintered into extra observations and utilization notes from of us, together with a revived dialogue on whether or not <abstract> needs to be allowed to include interactive parts or not.

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

Can we alter the show of parts nested within the <particulars> ingredient?

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

Discover the required <abstract> ingredient and the 2 further <div>s in there. We are able to override the show, proper?

What we’d count on is that <particulars> now has an express peak of 40vh and three rows the place the third row takes up the remaining area 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 conduct to its grid gadgets. However the HTML spec tells us:

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

(Emphasis mine)

And a bit later:

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

(Emphasis mine, once more)

So, the spec says the second slot — the 2 further <div>s from the instance — are solely coerced into being block parts 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 parts into slots and eradicating the flexibility to type them appears off. Is it a spec subject that the contents are slots, or a browser subject that we can not override their show though they’re within the field tree? Smarter individuals can enlighten me but it surely looks as if an incorrect implementation.

Is <particulars> a container or an interactive ingredient?

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

Appears cheap. The spec certain permits it:

The particulars ingredient represents a disclosure widget from which the consumer can get hold of further data or controls.

(Emphasis mine)

Alright, so we’d count on that <particulars> is the container (it has an implicit position=group) and <abstract> is an interactive ingredient that units the container’s open state. Is sensible 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 the very best factor. See what occurs when <particulars> is rendered with out the <abstract> ingredient:

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

The primary abstract ingredient baby of the ingredient, if any, represents the abstract or legend of the main points. If there is no such thing as a baby abstract ingredient, 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 results in a brand new query: why is <abstract> given an implcit button position when <particulars> is what seems to be the interactive ingredient? Maybe that is one other case the place the browser implementation is wrong? Then once more, the spec does categorize each as interactive parts. You’ll be able to see how totally complicated all of this turns into.

Both approach, Melanie’s final conclusion that we must keep away from utilizing <particulars> for menus relies on how assistive tech reads and declares <particulars> that include interactive parts. The ingredient is introduced, however there is no such thing as a point out of interactive controls past that till you, er, work together with <particulars>. Solely then will one thing like an inventory of hyperlinks be introduced.

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

Ought to <abstract> enable interactive parts?

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

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

<!-- or -->

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

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

The hyperlink shouldn’t be discoverable in any respect to JAWS when navigating with its digital cursor. If navigating to the abstract ingredient through the Tab key, JAWS declares “instance textual content, button” because the identify and position of the ingredient. If hitting Tab key once more, JAWS once more declares “instance textual content, button” though keyboard focus is on the hyperlink.

[…]

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

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

But, it’s legitimate HTML:

Scott goes additional in a separate weblog submit. For instance, he explains how slapping position=button on <abstract> may seem 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 enable interactive parts as a result of buttons can not include interactive parts. The one drawback is that Safari then treats <abstract> as an ordinary button, which loses its expanded and collapsed states. So, the right position is introduced, however now its state shouldn’t be. 🙃

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 make it possible for what’s in it supplies the fitting type of expertise and expectations for customers.

I’m simply glad these conversations are occurring and that they’re going down within the open. Due to that, you may touch upon Scott’s three proposed options for the way the content material mannequin for <abstract> is outlined, upvote his tickets, and report your personal points and use instances whilst 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 applied.