W3C home > Mailing lists > Public > www-style@w3.org > May 2011

Re: [Selectors4] Semantic Pseudo Elements

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 10 May 2011 09:38:28 -0700
Message-ID: <BANLkTi=3mkUKo+kUVDjqeXVdD5g6TwFSUA@mail.gmail.com>
To: Christoph Päper <christoph.paeper@crissov.de>
Cc: W3C style mailing list <www-style@w3.org>
On Tue, May 10, 2011 at 5:02 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Eduard Pascual:
>> On Mon, May 9, 2011 at 7:44 PM, Christoph Päper <christoph.paeper@crissov.de> wrote:
>>> 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
>  ===========================

Ah, you're somewhat confused here.  Like I said, CSS doesn't care what
the markup language is, all it cares is that the markup language
somehow converts itself into a CSS element-tree, which it uses for
selectors, inheritance, and eventual transformation into a box-tree.

(I'll assume for the moment that the language in your examples is
Markdown.)  It would indeed be inconvenient for authors if Markdown
created nodes in its element-tree with tagnames that need to be
escaped.  There's no need for it to do so, though.  It can make up
appropriate names on its own; since it maps to HTML, it might be
convenient to just give the same tagnames as the HTML equivalents.
That is, your examples could create the exact same CSS element-tree as
the following HTML would:

<p><u>This text is underlined</u>, this text is not, but <u>this one is</u>.</p>
<h2>This may be a headline</h2>
<h2>This is a headline, elsewhere</h2>
<h1>Yet another headline format</h1>

So, if a UA natively understood markdown, you could style all the
underlines, for example, by just using a "u" selector.

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

If you have a UA that natively understands the source language, it can
do this properly by exposing keywords as a "keyword" element, so you
could just do:

keyword { color: blue; }

Using a pseudo-element instead is needlessly complex and fragile.

If you don't have a UA that natively understands the source language,
then you can't create regular elements *or* pseudo-elements
automatically anyway.  You're stuck with parsing it yourself and
transforming it into a source language that the UA does understand
(like HTML).

>> 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;}

It's even easier to just use "em" or "emphasis" rather than ":emphasis".

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

I think [[Foo]] creates a link to an internal page named "Foo" in
wikitext, right?  If so, then a parser could make an element named
"link" or "a" or whatever.  I dunno what "{Bar}" is, but it would do
something similar.

Received on Tuesday, 10 May 2011 16:39:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:52 UTC