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 11:23:51 -0700
Message-ID: <BANLkTi=ZMOrW6yec2jz7ptVSuQxWh-Of3w@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 10:11 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Tab Atkins Jr.:
>> On Tue, May 10, 2011 at 5:02 AM, Christoph Päper
>>> 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.
>>>
>>> Maybe, but selectors are ugly then, even for paired markers: …
>>> Some markers may be ambiguous, because they can be used paired inline or line-initial: …
>>> Inline plain text pseudo stylings are also not always applied in a start-tag / close-tag manner: …
>>
>> Ah, you're somewhat confused here.
>
> No, I’m not, but maybe I’m not making my point clear enough. The examples were intended to show that the concept of element name is not easily applied to some markup languages. Since element names are the most prominent type of selector you would need some other mechanism.

I don't understand.  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.

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.  All CSS knows
is that the source language hands it an element-tree, which CSS then
operates on.  The element-tree is composed of nodes like I described
in an earlier email, with no notion of "tags" or whatnot.


> Btw., to get this straight, Eduard Pascal is an alter ego of Tab Atkins Jr. (or vice versa)?

Huh?  No, not at all.  Eduard is just another productive contributer
to the mailing list.  It would be weird for me to contribute under two
names.  ^_^


>> (I'll assume for the moment that the language in your examples is Markdown.)
>
> Some of it is.
>
>> It would indeed be inconvenient for authors if Markdown created nodes in its element-tree with tagnames that need to be escaped.
>
> 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, for
example.  Languages without obvious tagnames for their nodes are at a
slightly disadvantage here, but that's the price you pay for
compactness, unfortunately.


>> it might be convenient to just give the same tagnames as the HTML equivalents.
>
> So, you think matching
>
>  /a text like this/
>
> with
>
>  em {foo: bar}
>
> or
>
>  i {foo: bar}
>
> is better than
>
>  :emphasis {foo: bar;}?
>
> I beg to differ.

Or maybe "emphasis { foo: bar; }" or "italic { foo: bar; }".
Whatever.  The use of a pseudoclass instead of a tagname is just
useless, though - the addition of the colon doesn't gain you anything.


>>>  ::keyword {color: blue}
>>
>> 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.


>> It's even easier to just use "em" or "emphasis" rather than ":emphasis".
>
> But ‘em’ (and possibly ‘emphasis’ too) is an element name in and therefore selector for at least one other markup language.

It doesn't matter that the selector may also match elements in another
language.  ".foo" can match elements in any language too.


> It is much cleaner to provide a generic mechanism.

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

There's no such thing as a generic set of semantics - the concept of a
"keyword" is useful when styling JS source, but it means something
different when styling CSS source, and it doesn't mean anything at all
when styling HTML source or HTML itself or Markdown.


>>> How would the selector for ‘[[Foo]]’ or ‘{Bar}’ look like?
>>
>> … a parser could make an element named "link" or "a" or whatever.
>
> ‘:link’ already exists.

Ok?  So the UA should probably make :link apply.  Note that :link only
exists in the first place for legacy reasons, as attribute selectors
didn't exist in CSS1, but people wanted to style links differently
from named anchors (which both used the <a> element in HTML4).  If we
were writing CSS from scratch today we wouldn't include it, as (a)
using @name to make anchors is deprecated, as @id on any element works
better, and (b) you can now just use a[href] to select <a> elements
that are specifically links.

~TJ
Received on Tuesday, 10 May 2011 18:24:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:40 GMT