Bug 20600 - [Shadow]: Custom Pseudo-Elements should follow the same convention as custom element names.
[Shadow]: Custom Pseudo-Elements should follow the same convention as custom ...
Status: RESOLVED WONTFIX
Product: WebAppsWG
Classification: Unclassified
Component: Component Model
unspecified
PC All
: P2 normal
: ---
Assigned To: Dimitri Glazkov
public-webapps-bugzilla
:
Depends on:
Blocks: 14978
  Show dependency treegraph
 
Reported: 2013-01-08 13:39 UTC by Anne
Modified: 2014-04-09 21:34 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anne 2013-01-08 13:39:32 UTC
Can we please not enshrine the x- convention into web standards: http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful

Why not have something like ::shadow(identifier) instead?

Introducing specific parsing rules in CSS For ::x-... vs ::... seems very icky too.
Comment 1 Dimitri Glazkov 2013-01-08 15:47:20 UTC
(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").
Comment 2 Anne 2013-01-09 11:37:11 UTC
Having x- mean "local semantics" (whatever that is, like data-*?) rather than experimental (which it has always meant) seems kinda confusing.
Comment 3 Tab Atkins Jr. 2013-01-09 18:30:22 UTC
(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.)
Comment 4 Anne 2013-01-09 18:44:12 UTC
This is not about elements.
Comment 5 Tab Atkins Jr. 2013-01-09 19:14:46 UTC
(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.
Comment 6 Dimitri Glazkov 2013-01-09 19:17:51 UTC
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.
Comment 7 Anne 2013-01-09 19:39:24 UTC
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.)
Comment 8 Mike Kamermans 2013-03-27 18:16:56 UTC
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)
Comment 9 Dimitri Glazkov 2013-05-07 22:34:20 UTC
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?"
Comment 10 Mike Kamermans 2013-05-09 01:49:33 UTC
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 =)
Comment 11 Tab Atkins Jr. 2013-05-09 17:24:19 UTC
(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.
Comment 12 Dimitri Glazkov 2013-05-09 21:36:33 UTC
Added a warning for now: https://dvcs.w3.org/hg/webcomponents/
Comment 13 L. David Baron (Mozilla) 2013-05-09 21:47:23 UTC
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.
Comment 14 Dimitri Glazkov 2013-07-17 22:11:19 UTC
Latest proposal is to use part(foo). We'll just use that instead.
Comment 15 brunoais 2014-04-09 18:27:49 UTC
Why not use namespacing-like way the same way xml does?

<somenamespaceyoumakeup:shadowtag></somenamespaceyoumakeup:shadowtag>

?
Comment 16 Mike Kamermans 2014-04-09 18:39:39 UTC
That would be trying to slip back in something that is finally expressly forbidden in HTML5 =)
Comment 17 brunoais 2014-04-09 21:34:09 UTC
thamn! :(