20600 2013-01-08 13:39:32 +0000 [Shadow]: Custom Pseudo-Elements should follow the same convention as custom element names. 2014-04-09 21:34:09 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED WONTFIX P2 normal --- 14978 1 annevk dglazkov brunoaiss dbaron fantasai.bugs jackalmage pomax public-webapps-bugzilla oldest_to_newest 81043 0 annevk 2013-01-08 13:39:32 +0000 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. 81049 1 dglazkov 2013-01-08 15:47:20 +0000 (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"). 81111 2 annevk 2013-01-09 11:37:11 +0000 Having x- mean "local semantics" (whatever that is, like data-*?) rather than experimental (which it has always meant) seems kinda confusing. 81136 3 jackalmage 2013-01-09 18:30:22 +0000 (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.) 81137 4 annevk 2013-01-09 18:44:12 +0000 This is not about elements. 81142 5 jackalmage 2013-01-09 19:14:46 +0000 (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. 81143 6 dglazkov 2013-01-09 19:17:51 +0000 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. 81144 7 annevk 2013-01-09 19:39:24 +0000 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.) 85061 8 pomax 2013-03-27 18:16:56 +0000 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) 87390 9 dglazkov 2013-05-07 22:34:20 +0000 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?" 87475 10 pomax 2013-05-09 01:49:33 +0000 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 =) 87500 11 jackalmage 2013-05-09 17:24:19 +0000 (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. 87517 12 dglazkov 2013-05-09 21:36:33 +0000 Added a warning for now: https://dvcs.w3.org/hg/webcomponents/ 87518 13 dbaron 2013-05-09 21:47:23 +0000 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. 90891 14 dglazkov 2013-07-17 22:11:19 +0000 Latest proposal is to use part(foo). We'll just use that instead. 103620 15 brunoaiss 2014-04-09 18:27:49 +0000 Why not use namespacing-like way the same way xml does? <somenamespaceyoumakeup:shadowtag></somenamespaceyoumakeup:shadowtag> ? 103621 16 pomax 2014-04-09 18:39:39 +0000 That would be trying to slip back in something that is finally expressly forbidden in HTML5 =) 103633 17 brunoaiss 2014-04-09 21:34:09 +0000 thamn! :(