Re: [css-lists][html] <summary> and ::marker

On Fri, Apr 22, 2016 at 2:24 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> This would let us swap the <summary> UA style back to just:
>
> summary e
>   display: block;
> }
> summary::marker {
>   content: disclosure-closed;
> }
> details[open] > summary::marker {
>   content: disclosure-open;
> }
>
> (We'd also redefine disclosure-open/closed from being counter styles
> to just being 'content' keywords with the same effect.)
>

Do we want to redefine other counter styles keyword like 'disc' other than
disclosure-open/closed to be a 'content' keyword? If we remove
disclosure-open/closed from being a keyword of 'list-style-type', won't this
cause a backward compatibility issue?

I'm a implementer for Firefox, so this is from the implementation point of
view.

Tab's proposal is cleaner, but I'm worrying about the implementation
complexity
for defining ::marker to be another universal pseudo like ::before for
solving
the issue for summary implementation. We do want the summary marker to be
stylable. However, from the current details and summary usage I saw,
authors are
either satisfied with the built-in rendering of the triangle, or they're
hiding
the built-in one, and replace it by stuff in summary::before. Needless to
say that if they want the marker position to be at the end of summary
they'll still need to hide the triangle, and provide ones in summary::after
like this page
<https://developer.microsoft.com/en-us/microsoft-edge/platform/faq/>. And
using summary::before is also the practical way for a decent
web page to work across browsers with or without details and summary
implementation.

Even though summary being a list-item is hacky, it did provide a clean way
to hide
the triangle by summary { list-item-type: none }.

I can live with hacks in browser implementation as long as we provide a
cleaner way for the authors to style the triangle, and a not-too-difficult
way for
vendors to start implement or adopt the standardized details and summary
feature.


> fantasai offers an alternate proposal: leave <summary> as is, leave
> the hack for the first problem, but make the list-style-* properties
> actually only apply to the ::marker pseudo, rather than to list items.
> Inheritance ensures that we maintain today's behavior, but HTML can
> then set list-style-position:inside directly on the summary::marker,
> and avoid the second problem entirely.
>

I feel changing list-style-* properties to *only* apply to the ::marker
could be
another source for compatibility issues. Other implementers who are familiar
with counter styles might want to comment this.

Ting-Yu