Re: [Selectors4] Semantic Pseudo Elements

On Mon, May 9, 2011 at 7:44 PM, Christoph Päper <christoph.paeper@crissov.de
> wrote:

> CSS Selectors are currently designed mainly for mark-up languages that
> feature named elements and attributes, i.e. SGML, XML, HTML:
>
>  <element attribute="value">content</element>
>
> Some other languages might work, too, such as JSON, if some special
> conventions are followed:
>
>  { "name": "element",
>    "attributes": {"attribute": "value"},
>    "contents": "content"
>  }
>
> Some pseudo elements ‘::foo’ and pseudo classes ‘:foo’ amend this system
> with structural and semantic values. Some of them accept parameters in
> parentheses after them ‘::foo(bar)’, ‘:foo(bar)’. Structures not present in
> the markup ‘@foo’ are supported to some degree, too.
>
> I think we should add semantic pseudo elements (and classes):
> 1. To enable syntax highlighting (of computer code, especially).
>
Currently, syntax highlighting can be achieved by marking up the semantics
of the code (ie: marking up something as a keyword, a variable, a literal,
etc). Any step further would require either built-in knowledge for each
highlight-able language/format, or a way to define its syntax. None of those
seems reasonable for a styling language.


> 2. To support lean, non-verbose markup (e.g. Markdown, e-mail and wiki
> syntaxes).
>
Nothing prevents CSS from working on other markup. All you need is a parser
for whatever document language you want to use that builds something
resembling a tree structure from it (the DOM), and then you can go and
render that DOM applying CSS rules. For any given markup language, you'd
need to define what are elements and what are attributes (although
attributes don't even need to exist). The X/HTML, SGML, and XML language
families just have the advantage of this being already well defined. Just
because there isn't any widely known implementation of CSS for some unusual
language doesn't mean it's not doable.
As a matter of fact, the terminology on the CSS specs is rather generic when
referring to the "document language" just to avoid shutting down this
possibility (sure, examples and the like are HTML-based: nobody can change
the fact that CSS was designed for HTML after all).


>
> The first use case would require an extensive analysis of what coders’ text
> editors currently offer and what common constructs computer languages do
> use. This is a complex task and should probably done in a module or even a
> compatible specification of its own.
>
The first case requires a whole parser for each language to be supported,
unless you add markup around the code you'll want to highlight to define
what each fragment of the code represents. Once you make a parser, adding
the markup to do the highlighting through CSS is a piece of cake anyway. As
a matter of fact, there are many libraries out there that do exactly this
(either on the server or via JS). What exactly would you want to be handled
by CSS?


>
> I assume the second scenario to be less complex and hopefully it could be
> done within CSS / Selectors.
>
As a matter of fact, for the second scenario CSS already does what it does
(which is just being generic enough). What's left (a parser to build a DOM
for the unusual language) is entirely out of CSS' scope.