(In reply to comment #0)
> Can we please not enshrine the x- convention into web standards:
> http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful

That's a completely different situation, right? "x-" in HTTP headers meant implementation-specific or experimental. "x-" means "local semantics" (as opposed to "public semantics").

Having x- mean "local semantics" (whatever that is, like data-*?) rather than experimental (which it has always meant) seems kinda confusing.

(In reply to comment #2)
> Having x- mean "local semantics" (whatever that is, like data-*?) rather
> than experimental (which it has always meant) seems kinda confusing.

If you have a better suggestion that is similarly short, feel free to suggest something.

(It's a virtue that the prefix looks slightly ugly, as it makes it less likely that the elements will be overused for inappropriate purposes, like people inventing "more semantic" names for existing elements, but it can't be too long/ugly, or people might ignore the mechanism entirely.)

This is not about elements.

(In reply to comment #4)
> This is not about elements.

Sorry, brain fart.  In that case, we'd still like to avoid having something too inconvenient, but it's less of a problem.  I think we're using x- just because it parallels the element-name prefix.

BTW, I suggested using a function for this early on, but Hyatt was strongly against it (because WebKit and Gecko already have a de-facto standard using ::foo for matching elements in shadow trees). With that, we need _a_ prefix for separating author-defined pseudo-elements from those specified in CSS. As Tab said, "x-" is here just for consistency.

Is hyatt okay with a prefix though? It seems either way you're changing the design he intended. Using a function seems much cleaner and there's much more precedent for that in CSS than prefixes. (CSS only has prefixes with a leading - and those are for proprietary extensions.)

just speaking up as a normal user who will end up having to write CSS declarations for style hooking, "x-" is just a little nudge forward towards the mess that CSS has become =)

If a prefix is absolutely necessary, can it be made indicative of what it's for, like "custom-" or something, so that CSS keeps making sense to people who have to write/read it?

(I have no idea how to battle the syntax that lands in CSS left and right as just "a person who has to write CSS"; the style hook syntax involving adding +, for instance, makes perfect sense to me as a programmer, but as a user I hope never to have to use it because it just makes CSS less human-unreadable. So hopefully "x-" isn't kept as prefix, at least)

Okay, custom elements shrugged the "x-" prefix and it may be time to do the same for custom pseudo elements. However, we can't go with just "dashes-in-name" constraint, since CSS already has a bunch of pseudo elements like that. What do you guys think about "should start with a dash?"

I'm not sure that would be a good idea. People are going to have to write and read these structures a lot, making pseudo elements start with a dash will not be pleasant. Given the established nature of CSS pseudo-selectors, would it make sense to go with dash-in-name anyway, and either leave the collision up to the client (with an application warning that an established pseudo-class is being redeclared, much like how an unknown CSS propertie will throw warnings in all modern browsers). This will even allow a graceful degradation where new pseudo-selectors are added to CSS, and sites that don't use them, but were already using their own now-name-colliding custom pseudo-elements now get a warning from the browser. The behaviour will be the same as before (the pseudo-element wins), but the site will do the same as it always did, and the maintainers can decide to either move with the times, or ignore the problem without loss of function =)

(In reply to comment #10)
> I'm not sure that would be a good idea. People are going to have to write
> and read these structures a lot, making pseudo elements start with a dash
> will not be pleasant. Given the established nature of CSS pseudo-selectors,
> would it make sense to go with dash-in-name anyway, and either leave the
> collision up to the client (with an application warning that an established
> pseudo-class is being redeclared, much like how an unknown CSS propertie
> will throw warnings in all modern browsers). This will even allow a graceful
> degradation where new pseudo-selectors are added to CSS, and sites that
> don't use them, but were already using their own now-name-colliding custom
> pseudo-elements now get a warning from the browser. The behaviour will be
> the same as before (the pseudo-element wins), but the site will do the same
> as it always did, and the maintainers can decide to either move with the
> times, or ignore the problem without loss of function =)

We prefer to avoid these kinds of "graceful" name collisions anyway, because it interferes with people trying to use the "real" versions as we add them in the future.

Added a warning for now: https://dvcs.w3.org/hg/webcomponents/

What about the issue of CSS implementations being required to drop selectors containing unknown pseudo-elements?  (Modulo some non-conforming implementations where this is red:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%2C%20%3A%3Ax-foo%20%7B%20background%3A%20red%20%7D%0A%3C%2Fstyle%3E )

Exactly which pseudo-elements does this make considered to be known?

I agree a function would be a better solution.

Latest proposal is to use part(foo). We'll just use that instead.

Why not use namespacing-like way the same way xml does?

<somenamespaceyoumakeup:shadowtag></somenamespaceyoumakeup:shadowtag>

?

That would be trying to slip back in something that is finally expressly forbidden in HTML5 =)

thamn! :(