18863 2012-09-12 22:11:13 +0000 [Custom]: Consider only restricting naming to contain a dash 2013-04-10 20:40:07 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 17103 1 dglazkov dglazkov danieljb2 esprehn ian sjmiles sorvell public-webapps-bugzilla oldest_to_newest 73728 0 dglazkov 2012-09-12 22:11:13 +0000 " The custom element name must start with a U+0078 LATIN SMALL LETTER X, followed by U+002D HYPHEN-MINUS" Why not just: 1) any name that contains a dash; 2) and hasn't been registered before? 77071 1 dglazkov 2012-10-24 20:52:49 +0000 Daniel, WDYT? 77085 2 danieljb2 2012-10-25 05:08:05 +0000 I would go with 'x-' for the following reasons: 1. Consistency in View Source browsing is important for discover/hack-ability. 2. Is there any chance HTML itself will ever have a native tag that contains a dash causing an issue in the future? 3. What is the benefit of enforcing only the presence of a dash? Why should we make the tokenizer/parse code more complex if it yields no significant benefits? 79860 3 sjmiles 2012-12-10 20:41:43 +0000 In a world with numerous custom components, the tag namespace will become a crowded place. Therefore, vendors are likely to prefix anyway, and it's much nicer to have: g-button jq-button yui-button vs x-g-button x-jq-button x-yui-button For that reason, I'm very much in favor of eliding the "x-". Since there are no HTML tags that contain HYPHEN today, I hoping we can grab up this rule for custom components. Scott 79874 4 danieljb2 2012-12-10 22:52:02 +0000 (In reply to comment #3) > In a world with numerous custom components, the tag namespace will become a > crowded place. > > Therefore, vendors are likely to prefix anyway, and it's much nicer to have: > > g-button > jq-button > yui-button > > vs > > x-g-button > x-jq-button > x-yui-button > > For that reason, I'm very much in favor of eliding the "x-". > > Since there are no HTML tags that contain HYPHEN today, I hoping we can grab > up this rule for custom components. > > Scott I am not really a fan of this for a few reasons: 1. <x-____> is immediately recognizable to anyone viewing source, as opposed to scanning for a dash somewhere in a name 2. Do we really want to end up with this: <-sometag> or <sometag->, if not, are we going to institute another restriction that the tag cannot begin or end with a dash? 3. Is namespacing for tag names really as much a concern as JS variables? I would argue that it isn't, because 99% of the time you know what tags are included in your app. 4. The Firefox implementation is basically 3 feet from touching down on the tarmac, and though this isn't a huge change (I'm guessing), is it really providing a significant value? Let me know what you folks thing about the above. 79876 5 sjmiles 2012-12-10 23:14:45 +0000 My $0.02 > 2. Do we really want to end up with this: <-sometag> or <sometag->, if not, > are we going to institute another restriction that the tag cannot begin or > end with a dash? I'm of the mind that we don't need to worry about this. If some developer does this they will either have a good reason or they will be ridiculed. > 3. Is namespacing for tag names really as much a concern as JS variables? I > would argue that it isn't, because 99% of the time you know what tags are > included in your app. Does this not conflict with your argument #1? In any case, I'm not sure what you mean. If YUI provides "x-button" and JQuery provides "x-button", there goes the lovely interoperation we seek. Almost certainly it will become standard to prefix your tags. Then we have alphabet soup. > 4. is it really providing a significant value? I know you need more opinions than just mine, but I still say yes. S 79883 6 danieljb2 2012-12-11 00:05:41 +0000 (In reply to comment #5) > My $0.02 > > > 2. Do we really want to end up with this: <-sometag> or <sometag->, if not, > > are we going to institute another restriction that the tag cannot begin or > > end with a dash? > > I'm of the mind that we don't need to worry about this. If some developer > does this they will either have a good reason or they will be ridiculed. > > > 3. Is namespacing for tag names really as much a concern as JS variables? I > > would argue that it isn't, because 99% of the time you know what tags are > > included in your app. > > Does this not conflict with your argument #1? > > In any case, I'm not sure what you mean. If YUI provides "x-button" and > JQuery provides "x-button", there goes the lovely interoperation we seek. > Almost certainly it will become standard to prefix your tags. Then we have > alphabet soup. > > > 4. is it really providing a significant value? > > I know you need more opinions than just mine, but I still say yes. > > S One last, real concern: are we 100% sure we'll never have an HTML element native to the spec that has dashes in it? If there was ever a natively-dashed tag name, would this create a problem? All in all, I'm not passionate about it - it's just another nit in the way of landing the patch in Firefox and a odd way of inferring that an element has super powers. I'm punting to Dimitri :) 79884 7 dglazkov 2012-12-11 00:10:16 +0000 (In reply to comment #6) > > I'm punting to Dimitri :) Oh crap. 79966 8 danieljb2 2012-12-11 21:53:06 +0000 I took a little time today to go around to a significant number of web devs in the office (not our low-level platform guys, the ones who work on sites and apps), and not one of them liked the idea of a random dash anywhere in the name being the magical indicator that something is a custom element. The immediately cited markup clarity and it that it "seemed arbitrary" like a "magical dash". Not sure if that helps. If we want the Firefox patch to land this week, we need a decision on this so I can get them to drop the code into the tree. 79974 9 dglazkov 2012-12-11 22:45:33 +0000 (In reply to comment #8) > I took a little time today to go around to a significant number of web devs > in the office (not our low-level platform guys, the ones who work on sites > and apps), and not one of them liked the idea of a random dash anywhere in > the name being the magical indicator that something is a custom element. The > immediately cited markup clarity and it that it "seemed arbitrary" like a > "magical dash". Not sure if that helps. > > If we want the Firefox patch to land this week, we need a decision on this > so I can get them to drop the code into the tree. This shouldn't block the patch. Since the "-" is less restrictive than "^x-", we shouldn't stress about this too much right now. 80212 10 ian 2012-12-14 22:45:31 +0000 I still think that this whole thing of allowing authors to just make up element names is a REALLY BAD IDEA. It's the whole XML fiasco all over again. People are just going to make up their own elements, with no fallback, no semantics, no way for search engines to know what's going on, no way for accessibility tools to work out what's going on, no way for older UAs to work out what's going on, no way to quickly swap out one widget set and swap in a new one, etc. I really think this is the single biggest mistake of the Web Components work. 80246 11 dglazkov 2012-12-16 03:13:17 +0000 (In reply to comment #10) > I really think this is the single biggest mistake of the Web Components work. This change was made as a response to bug 18669. Let's discuss it there. I reopened the bug. This bug is only talking about the constraints around the actual name of the custom element (whether it's a custom tag or an "is" attribute value). 85877 12 dglazkov 2013-04-10 20:40:07 +0000 The spec has been updated to relax the name to have only dash a while back.