- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 10 May 2011 11:23:51 -0700
- 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 UTC