Element Naming Conventions

[snuggs]

Current API

Element `tag-name`

Tasks

• - Naming conventions for element names.
• - Naming conventions for id. (colon) Reference here

Naming Elements

• https://w3c.github.io/webcomponents/spec/custom/#prod-potentialcustomelementname

TL;DR; use at least one hyphen - in tag name. (foo- is valid as well)
Below is the restriction set for custom elements naming conventions.

Suggestions

Custom elements with a single word name.

Similar to Custom HTTP Headers A convention when you don't have at least 2 words (i.e. <foo-bar>) would be to prefix custom element name with x-*. (i.e. <x-input>). That said #TodayILearned this has been deprecated in HTTP and has a bonafied spec for the deprecation So the following may be a better best practice. /cc @tmornini

Non-visual Components

Think a geo location component or a storage adapter. A Non-"Mixin" or... a "Mixin" that can be declared via HTML.

I kind of like the thought of the following:

<import- href=partial.html>

the <-*> styled elements say are for "non visual" components?

<geolocation- >

Would be a valid component name. Again we are just defining conventions around what's available to us within the spec.

Please note the intent is the name of the element not it's functionality.

Namespacing Elements (@snuggs + @robcole)

Had a conversation today with Rob and he discussed the need for namespacing.
I mentioned to him that in the W3C Specs and WHATWG specs they have gone out of
the way to preserve XML Namespacing due to the need to support XMLDocument parsing.
Perhaps we can borrow some conventions from there since they are already baked into the browser.

What is Namespacing

Namespacing TL;DR; example

Namespace Crash Course

"Namespaces are a means of identifying collections of reserved words of particular xml markup type so they can be combined with other markup without fear of conflict." - From this Youtube video.

It's not a "Location of something" but more a "grouping of ideas".

@tmornini especially curious of your input here on "namespacing" at a high level.

Resources and APIs

• Document.createElementNS - https://developer.mozilla.org/en-US/docs/Web/API/Document/createElementNS
• Element.namespaceURI - https://developer.mozilla.org/en-US/docs/Web/API/Element/namespaceURI
• Element.getAttributeNS - https://developer.mozilla.org/en-US/docs/Web/API/Element/getAttributeNS
• Element.setAttributeNS - https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttributeNS
• @namespace CSS declaration - https://developer.mozilla.org/en-US/docs/Web/CSS/@namespace
• XML Namespacing - https://en.wikipedia.org/wiki/XML_namespace

Discussion

• https://discourse.wicg.io/t/custom-elements-not-requiring-hyphens-in-names/1439

[snuggs]

@brandondees I think we should have the following in the "Conventions" docs. VERBATIM even:

@robcole looks like we have access to document.createElementNS therefore we have namespacing available to us. In the custom elements spec if you can define the element you can always create one the old fashion way document.createElement ('foo-bar') for backward compatibility scripts.

By the way... notice emoticons can be used as a valid name <this-is-valid-😍>

[brandondees]

is it best to namespace all snuggsi elements by default? or better to prescribe a default convention of app-namespacing all custom elements etc? i am going to go ahead and presume that for redistributable components namespacing should be an obvious best practice (import and and to use them side by side in an app, but the namespace way)

[brandondees]

should namespaces be human-meaningful / semantic? or is strictly programmatic better? (i'm looking at HTML id vs name attrs for comparison)

[snuggs]

@robcole & @tmornini would probably have better input on this @brandondees. He sparked the idea so interested in opinion. I'm just an implementor. ;-) Probably best to review references:

• https://en.wikipedia.org/wiki/Namespace
• https://developer.mozilla.org/en-US/docs/Namespaces

In a way this makes sense of S3 buckets. @tmornini and i discussed once how the "URL paths" are merely namespaces where the delimiter just so happens to be /. /foo/bar.html is really just /bar.html within the /foo domain.Nothing really related to actual file path. That's merely an implementation detail.

[snuggs]

@robcole @brandondees well there goes that theory of -element (Notice the hyphen prefix). HOwever <h1-> as a suffix is fine. Feeling a lil hackey now. Shoulda read the doc better. [a-z] means starts with a lettered character.

I think we can move on to "bonafied" namespacing.

[snuggs]

@brandondees @robcole @kurtcagle seems to have been a discussion to try to get hyphen removed. I agree that's a bad idea. https://discourse.wicg.io/t/custom-elements-not-requiring-hyphens-in-names/1439

[brandondees]

i have no problem with the hyphen requirement, as it's only a very minor inconvenience, and having a clear rule to follow is helpful

[grepsedawk]

It also prevents using tags that might be new tags, since most base tags are no hyphen

…

On Wed, Aug 2, 2017, 10:06 AM Brandon Dees ***@***.***> wrote: i have no problem with the hyphen requirement, as it's only a very minor inconvenience, and having a clear rule to follow is helpful — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#86 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGaPS3XleFOERjNa3ZnZNTRmLaUjqSbpks5sUJBtgaJpZM4OO8uk> .

[brandondees]

see that whole thread for the ins and outs of the rationale for the rule, and arguments against it as well. in short, that's the main justification for the rule.