Re: [css-pseudo] Need a way to styling the disclosure triangle of the <details> (or <summary>) element

On Mon, Mar 7, 2016 at 12:19 AM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> On 03/03/2016 21:01, Tab Atkins Jr. wrote:
>>> The behavior is a convenience feature for selecting a list item's contents.
>>
>> Interesting.
>
> Sorry I am stepping in late. The above is correct, it's a feature many
> users are used to, coming from wysiwyg text processors.

Interesting, I was not aware that existed in text editors.

> All browsers
> also select the item when the marker is double-clicked.

No, they don't.  At least in Chrome, double-clicking the marker
selects *the first word in the list item*, which is just the normal
behavior when you double-click somewhere that isn't a word.  Set the
<li> to display:block and click in the same area, you'll get the same
behavior; it's not tied to the marker at all.

> One reason Gecko added the one-click behaviour eons ago to the marker
> was the editor where double-click is used to open element properties,
> in our case list properties.

Which editor? Does this still exist?  This certainly isn't the
behavior of the Inspector today.

> It also seems that none of Gecko, WebKit and Blink correctly applies
> 'display: list-item; list-style-type: square' to an element that is not
> a li, dt or dd.

No, it works perfectly fine.  Are you accidentally hiding the bullet
off-screen?  Switch to list-style-position:inside or add some
padding/margin so it has space to display.

> Gecko even seems to apply it only to li/dt/dd elements
> inside a ul/ol/dl. I haven't checked in the code itself yet.

I suspect this is the same thing.

>>> I don't think this issue is a CSS spec problem. However, it does highlight
>>> the fact that this feature -- the disclosure widget -- is being shoehorned
>>> into another feature -- list counters -- that clearly wasn't designed for
>>> this purpose.
>>
>> Other way around - this is a list-related feature (highlighting the
>> contents of the element when you click the bullet) being shoehorned
>> into a CSS feature (the "display:list-item" value) that isn't
>> restricted to lists.
>>
>> This is identical to automatically putting table-sorting functionality
>> on anything that specified display:table, which would be obviously
>> silly.  The Firefox behavior should be limited to the <li> element,
>> which is semantically a list item (if it's kept at all).
>
> I agree with Patrick. Even if the two features (list-item and has-a-
> disclosure-marker) look similar, they are not. When one sets 'display:
> table' on a non-table element, the expected rendition is a table. Here,
> the stylesheet author is going to set 'display: list-item' for a
> rendition that is not a list item.

I strongly disagree with either of these sentences; I"ll let you choose which.

A horizontal navbar is *not* a table, by any stretch of the
imagination.  It's a horizontal arrangement of boxes.  display:table
happens to achieve that, and luckily also has some nice size-balancing
behavior.

Or, if you want to say that a horizontal navbar *is* a table, then the
summary element is exaclty as much a list item.  It's a block element
with a bullet, exactly like a list item.

You can't have it both ways.  Either 'display' is non-semantic and its
values get used for all sorts of things unrelated to the original
naming, or 'display' is semantic *but* the "semantics" are way wider
than one would naively believe.  The first way allows <summary> to use
display:list-item.  The second way condemns people using display:table
for navbars.

>It's unfortunate but words convey
> semantics. And we still have the issues highlighted above: restrictions
> to 'display: list-item' in current engines that could have a side effect
> on existing web pages if lifted, click and double-click behaviour.

Aside from maybe the Firefox highlighting behavior (which should be
done based on tagname, not style, the current behavior is just a
layering violation), there's no restrictions on behavior here.

~TJ

Received on Monday, 7 March 2016 18:24:41 UTC