This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 18863 - [Custom]: Consider only restricting naming to contain a dash
Summary: [Custom]: Consider only restricting naming to contain a dash
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 17103
  Show dependency treegraph
 
Reported: 2012-09-12 22:11 UTC by Dimitri Glazkov
Modified: 2013-04-10 20:40 UTC (History)
5 users (show)

See Also:


Attachments

Description Dimitri Glazkov 2012-09-12 22:11:13 UTC
" 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?
Comment 1 Dimitri Glazkov 2012-10-24 20:52:49 UTC
Daniel, WDYT?
Comment 2 Daniel Buchner 2012-10-25 05:08:05 UTC
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?
Comment 3 Scott Miles 2012-12-10 20:41:43 UTC
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
Comment 4 Daniel Buchner 2012-12-10 22:52:02 UTC
(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.
Comment 5 Scott Miles 2012-12-10 23:14:45 UTC
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
Comment 6 Daniel Buchner 2012-12-11 00:05:41 UTC
(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 :)
Comment 7 Dimitri Glazkov 2012-12-11 00:10:16 UTC
(In reply to comment #6)
> 
> I'm punting to Dimitri :)

Oh crap.
Comment 8 Daniel Buchner 2012-12-11 21:53:06 UTC
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.
Comment 9 Dimitri Glazkov 2012-12-11 22:45:33 UTC
(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.
Comment 10 Ian 'Hixie' Hickson 2012-12-14 22:45:31 UTC
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.
Comment 11 Dimitri Glazkov 2012-12-16 03:13:17 UTC
(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).
Comment 12 Dimitri Glazkov 2013-04-10 20:40:07 UTC
The spec has been updated to relax the name to have only dash a while back.