Re: [Selectors4] Semantic Pseudo Elements

On Wed, May 11, 2011 at 2:36 PM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Tab Atkins Jr.:
>> This sounds like a problem we can avoid caring about until it actually appears.
>
> Perhaps. Selectors level 4, though, is not due tomorrow and this can also have benefits for languages like HTML, where explicit markup is missing, e.g. the proposed ‘di’ element surounding ‘dt’s with succeeding ‘dd’s.

We still shouldn't care about it until it's actually a problem we need
to solve.  ^_^  Right now the only significant languages we need to
care about are HTML, SVG, MathML, and arbitrary XML languages, all of
which are doing fine in this regard as their markup styles are closely
related.  In the near future we'll have to care about WebVTT, which
has already defined how it is mapped into an element-tree.


>> If multiple markup languages are supported that all have spans of emphasis, they can all agree that the tagname for it is "em" as easily as they can agree that they should be matched by the ":em" pseudoclass.
>
> This is only true for languages without inherent element names. ‘emph’ would not work well as a selector for HTML’s ‘em’ element type, but ‘:emph’ could.

That would suggest that a good tagname for that semantic for languages
designed to transpile into HTML should be "em" or "i", since HTML has
already named that semantic.


>> You talk about at least two classes of markup you want to style: plaintext markup languages
>> like Markdown and Wikitext, and source code.  These have a very disjoint set of semantics.
>
> Yes. CSS would use pseudo classes for lightweight, plaintext markup languages and it would use pseudo elements for code highlighting, because there is no markup at all in the source.

Huh?  There is exactly as much markup in these three examples:

<ul>
  <li>item 1
  <li>item 2
</ul>

* item 1
* item 2

for( var i = 1; i <= 2; i++ ) {
  print("item" + i + "\n");
}

"Markup" is not defined by angle-bracket tags, or other similar
things.  All of these could potentially generate a CSS element-tree,
if a UA chose to render them natively instead of transpiling them into
HTML.

~TJ

Received on Wednesday, 11 May 2011 22:31:15 UTC