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

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

In practice, editors are not as smart as we pretend them to be (W3C editors excluded :)). They’re “normal people” with zero knowledge about HTML and are not able/willing to handle this. It’s our job to make their lives easier.


At the same time, system administrators and the future of the web want to have good quality HTML. So we don’t want to have anything other than <li><del>My deleted text</del></li>, but still have the marker crossed out with the text.

> 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
> other.


Ofc. That was just an example. So just consider that in that case <strong> has semantic valid.

> 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.


Not doable in practical terms as it would result on different rendering and would exclude CSS applied to ::marker, including counters calculation.

> 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.


The issue is not just about rendering things right inside text editors. The same rendering should happen on published content. When it comes to web semantics we cannot make assumptions about the content consumers. All we can expect is that, as long as specs propose it, rendering will happen in a uniform way inside text editors, browsers, applications, etc.


> 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>.

Actually I’m proposing something a bit different. Right because of the case you have exposed, which shows that inheriting from C is not doable. That’s why I was talking about “styles” in my original message, not “elements”.

If we want to visualize it in terms of elements, the inheritance should happen over an additional pseudo element, which is built out of the contabilization of *styles* that apply to the whole contents of <li> (whitespace collapsed).  
  
> 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
> possible.

Unfortunately none of your workaround solve the problem. Really, we tried to figure out all possible solutions at our side before coming here and there is nothing we can do.
  

In the other hand you’re totally right. This is far from being a simple thing to handle. But I’m sure that the level of difficulty of it should not be a blocker, right?

Thanks again TJ.

Fred



On Tuesday, 17 December 2013 at 02:50, Tab Atkins Jr. wrote:

> On Mon, Dec 16, 2013 at 11:37 AM, Frederico Knabben
> <f.knabben@cksource.com (mailto: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
> > HTML.
> >  
>  
>  
> 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
> other.
>  
> 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
> possible.
>  
> ~TJ