Re: [Selectors4] Semantic Pseudo Elements

Eduard Pascual:
> 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 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).

I was not talking about foreign code embedded in a markup language, but about the code itself.

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

Of course. The (primary) application of this part of Selectors (or a separate spec or module) would not be a browsing environment, but source view – where browsers need to support HTML, CSS and JS at least – and text editors, which currently use proprietary syntax to store styling information, if it is changeable at all.

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

Maybe, but selectors are ugly then, even for paired markers:

  \_   {text-decoration: underline;}
  \=\= {font: bold large sans-serif;}

Some markers may be ambiguous, because they can be used paired inline or line-initial:

  \*   {font-weight: bold;}
  \n\* {display: list-item;}

Inline plain text pseudo stylings are also not always applied in a start-tag / close-tag manner:

  _This text is underlined_, this text is not, but _this_one_is_.

  == This may be a headline ==
  == This is a headline, elsewhere
  Yet another headline format
  ===========================
  
> For any given markup language, you'd need to define what are elements and what are attributes

It usually already is well-defined and parsers exist. Browsers would not necessarily support this, though.

> Just because there isn't any widely known implementation of CSS for some unusual language doesn't mean it's not doable.

BBCode, for instance, would be doable quite easily. The various wiki dialects, Markdown and Textile are probably a little bit more complicated.

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

The styling of the highlighted source code.

  foo

  ::keyword {color: blue}

instead of

  <span class="keyword">foo</span>

  .keyword {color: blue}

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

If ‘/’ instead of ‘<em>’ starts an emphasized inline portion of text, it would be easier for authors to write

  :emphasis {font-style: italic;}

than

  \/ {font-style: italic;}

if that is the correct way of escaping anyway. How would the selector for ‘[[Foo]]’ or ‘{Bar}’ look like?

Received on Tuesday, 10 May 2011 12:03:36 UTC