Re: [Selectors4] Semantic Pseudo Elements

On Wed, May 11, 2011 at 5:41 PM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> 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'm afraid it's the other way around: with the burden of the mapping
on the markup language (which is inherently finite), the burden is
finite, and hence it's realistic to take on it. OTOH, with the burden
of the mapping centralized on CSS, a single spec would need to deal
with an arbitrary amount of arbitrary languages. Even if we start just
with a few, the list would keep growing on and on indefinitely. _That_
is unrealistic.

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

What would be wrong with that? If you are building a stylesheet for
Markdown content you'd just use Markdown's mappings, just like a
stylesheet for a DocBook document would be different than one for an
HTML document. In fact, XML dialect authors are making up element
names every now and then. In fact, you may find the same name used for
different semantics across dialects, and also different names used for
the same purpose.

If you want to go deeper, I can't try to dig up some discussions from
two or three years ago on the WHATWG list archives about the issues of
vocabulary centralization. As a very brief summary (that was a long
and heated debate), centralization can work for wide-spread
vocabularies, but niche vocabularies would need a distributed
mechanism anyway: on a centralized approach their relatively low usage
doesn't pay off for the volume of work they would require. (You can
replace "vocabularies" with "markup languages" in the previous text:
these languages are after all a kind of vocabulary.)

To provide an example: I'm working on a piece of role-playing software
that uses a well-defined syntax to describe spells. Eventually, I'll
grab some GPL'd CSS engine and map the "elements" of my spell syntax
to a tree structure so I can directly render each spell list (and even
allow players and GMs to customize the styles). So, should I request
the group to include some ":targeting-restriction", ":casting-cost",
":ongoing-cost", etc pseudo-classes? Definitely not: my game system
just doesn't deserve to change the CSS spec for everyone. But that
doesn't prevent me from using CSS, as I can map everything to an
element tree and hand it down to the CSS engine. The same applies to
any other language: the means to style it are already there, so are
there enough use cases to justify what would be nothing else than a
convenience?

Received on Wednesday, 11 May 2011 20:24:14 UTC