W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: [css3-lists][css3-content] Proposal for styles inheritance on list markers (actually on :marker, :before and :after pseudo-elements)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 16 Dec 2013 17:50:08 -0800
Message-ID: <CAAWBYDAdYS8pKJOTzJq1Nc+sURiY9h+fPNE5h682EOVp2gnZ4Q@mail.gmail.com>
To: Frederico Knabben <f.knabben@cksource.com>
Cc: www-style list <www-style@w3.org>
On Mon, Dec 16, 2013 at 11:37 AM, Frederico Knabben
<f.knabben@cksource.com> wrote:
> I'm afraid that this is an oversimplified way to see and solve the problem.
> Note that users creating content out there don't have access to CSS editing.

I know, I was specifically referring to editors.  If they're making
their own content, they can handle the situation easily on their own.

> Imagine that the user is producing this content currently (in an editor,
> selecting text and applying "bold"):
> <li><strong>Text</strong></li>
> Then we say that a way to "solve" the problem is, if the user selects the
> whole list item and apply bold, we could produce this instead:
> <li style="font-weight:bold">Text</li>
> Rendering problem solved! Well… no:
> - Who said that <strong> should render as "font-weight:bold"? This can be
> modified and even suppressed on different devices.
> - We loose the whole semantic value added by <strong>, producing bad quality

You really shouldn't be adding a <strong> tag when the user hits
"Bold".  People bold text for lots of reasons, only some of which are
covered by the semantics of <strong>.  The correct way to bold
something in HTML is to use <b>, which has only barely more semantics
than "font-weight: bold;", so it's not too bad to swap one for the

Another way to handle this is to use the abilities introduced in the
Lists module to position an arbitrary element the same way as a
marker.  This way the editor can simply set lists to "list-style:none"
and then manually add list markers inside the content.  That way the
list marker can be made a child of whatever element you want, and
picks up the right styling automatically.

Finally, the editor can just style the ::marker pseudo-element
directly.  Just examine the children of the <li>, and if they look
like they should be styling the marker too, just copy the styling
over.  This is easy to do programmatically, and you never have to care
about the semantics of markers, beyond "being a marker", which is
already expressed by them existing.

Ultimately, the problem here is that you're trying to mess around with
the process of inheritance in a fragile way.  Your proposal is that
*if* a parent element P has a single child element C which contains
all of P's content (except for, possibly, collapsed whitespace), then
we should make P's pseudo-elements inherit from C instead.

This breaks as soon as P has *two* children, or a child and some text,
or anything else like that which disturbs your exact structure.  This
kind of thing can happen very easily in a visual editor; it might not
even be possible for the user to tell the difference between two runs
of colored text being siblings and being parent/child, since the end
result is the same.  One of them, however, would make the list marker
the color of the first element, while the other would make it the
color of the <li>.

All of my proposed workarounds avoid this fragile behavior, or at
least put it in the hands of the editor to deal with, rather than
trying to get it "right" in the browser, which I don't think is

Received on Tuesday, 17 December 2013 01:50:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC