- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 16 Dec 2013 17:50:08 -0800
- 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 > 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
Received on Tuesday, 17 December 2013 01:50:58 UTC