Re: [Selectors4] Semantic Pseudo Elements

Tab Atkins Jr.:
> On Tue, May 10, 2011 at 10:11 AM, Christoph Päper
>> Tab Atkins Jr.:
> 
> Yes, CSS was obviously designed with HTML in mind, and thus some types of other source languages don't mesh perfectly, such that you may want to invent tagnames for nodes in the CSS element-tree that don't perfectly match up with what the source language actually looks like.

And that’s what seems utterly wrong to me.

The Selectors3 spec currently says:

  A type selector is the name of a document language element type …
  …
  ns|E  elements with name E in namespace ns …

> You started talking about the source language not having the same notion of "start tags" and "end tags" as HTML, though, which is irrelevant - CSS has no notion of these things either.

Yes, that I might have left unclear. What I meant was that the “name of a document language element type” is not always as obvious as Selectors makes it seem. Take this (probably hypothetic) snippet:

* This is an *emphasized* example of a list item with a [[link]].

Therein the asterisk ‘*’ hardly can be such a name, because it is used in two very different manners, and it is just as unclear whether the name for the link element type would be ‘[’, ‘[[’, ‘]’, ‘]]’, ‘[]’, ‘[[]]’ or something else entirely. 

You effectively say to put the burden on markup language creators to design a mapping to element names in a document tree which Selectors, type selectors specifically, can work on. That is unrealistic. It is not as unrealistic, though, that there is a quite limited set of semantic or stylistic keywords that pretty much every plain text markup language could easily be mapped to. Other languages, such as HTML, could be accessed with them, too, obviously.

I don’t want to have Textile map “_foo_” to ‘emph’ and Markdown map the same to ‘i’, while HTML would use ‘em’. Instead I want a single token that implementers, authors and users can rely upon, e.g. in a common default stylesheet. 
Whether that token be ‘emphasis’, ‘:emphasis’, ‘::emphasis’, ‘@emphasis’ or something else is really a secondary point. I just believe that pseudo classes, i.e. one preceding colon, make the most sense, also given the link precedent.

>> Btw., to get this straight, Eduard Pascal is an alter ego of Tab Atkins Jr. (…)?
> 
> Huh?  No, not at all.

I hadn’t seen your earlier reply when I read:

>>> Ah, you're somewhat confused here.  Like I said, CSS doesn't care what the markup language is


Thus arose that confusion.

>> I suggested semantic pseudo elements or classes to avoid inventing new names for every language out there.
> 
> Why do you want to avoid that?  Every XML language has new names,

Those are obvious and are easily matched by the type selectors. My whole point is languages where that is not the case.

> Languages without obvious tagnames for their nodes are at a slightly disadvantage here, but that's the price you pay for compactness, unfortunately.

I proposed a solution to that, fortunately.

>>> keyword { color: blue; }
>> 
>> Yes, that could work, although it it probably works worse with namespaces.
> 
> I don't understand what problem with namespaces you're referring to.

Me neither. I guess I meant documents in a markup language where you would either want to highlight the source code or render the parsed tree, where “keyword” could mean very different things in them, although the namespace is the same.

That means with

  <keyword>foo</keyword>

you would either get just a blue string “foo” or the two strings “keyword” marked blue, since semantically they’re keywords.

> Why are source-language-specific pseudoclasses more generic than source-language-specific tagnames?

The pseudo classes would be generic, their binding would be language-specific.

> There's no such thing as a generic set of semantics

To validate that assessment I suggested to study what text editors do today.

> Note that :link only exists in the first place for legacy reasons,

It does not, as Øyvind Stnhaug already pointed out, and furthermore “a[href]” is not even the same as “a:link, a:visited”, because the former just requires the presence of the ‘href’ attribute, while the latter needs it to have a valid value, too.

The least I hope to get from this thread is a note in an upcoming level of the Selectors module which says how to handle markup languages that don’t have obvious, inherent names for their element types.

Received on Wednesday, 11 May 2011 15:41:59 UTC