Webcomponents: Rename custom tag

[annevk]

A tag is a bit of syntax in HTML and XML. How about "custom named element". And perhaps "custom builtin element" rather than "type extension". That way both are more clearly derived from "custom element" too.

[domenic]

I don't like these that much, but they are probably an improvement over the current... Here are my vague thoughts:

• custom named element: is this custom-named element, or custom named-element? If the latter, all elements are named, so just shorten to custom element. If the former, then it seems weird that what we're emphasizing about this element's custom-ness is its name.
• custom builtin element: Must be custom builtin-element. But that seems like an oxymoron. "builtin element customization" seems more accurate, I guess.

[annevk]

A "custom element" is either a "novel element" or an "extended-builtin element"?

[domenic]

Those I like!

[rniwa]

I don't like the term "novel". That sounds like a patent related. How about "author-defined elements"?

[domenic]

I've never heard of a patent-related connotation for novel.

Authors prefer to be called developers. "novel element" is nice and short.

[rniwa]

https://en.wikipedia.org/wiki/Novelty_(patent)
"Novelty is a patentability requirement."

I don't think we should start calling authors as developers as the latter is ambiguous between Web developers and UA developers. We have author defined stylesheets, UA stylesheets, etc... so that ship has sailed two decades ago.

[domenic]

I think we should avoid the whole author vs. developer debate by going with "novel element."

If you're really worried about some kind of patent thing then maybe look through the thesaurus for "novel" and choose an adjective you'd prefer to propose as an alternative.

[jaubourg]

How about "tailored element"? Makes it sound like an element that has been
tinkered with.

On 14 March 2016 at 04:48, Domenic Denicola [email protected]
wrote:

I think we should avoid the whole author vs. developer debate by going
with "novel element."

If you're really worried about some kind of patent thing then maybe look
through the thesaurus for "novel" and choose an adjective you'd prefer to
propose as an alternative.

—
Reply to this email directly or view it on GitHub
https://github.com/w3c/webcomponents/issues/434#issuecomment-196127194.

[jaubourg]

Also, why not "new element" rather than "novel element"? Is there something
ambiguous about "new"?

Anyway, we would have: A "custom element" is either a "new element" or a
"tailored element". Good enough?

On 14 March 2016 at 05:02, Julian Aubourg [email protected] wrote:

How about "tailored element"? Makes it sound like an element that has been
tinkered with.

On 14 March 2016 at 04:48, Domenic Denicola [email protected]
wrote:

I think we should avoid the whole author vs. developer debate by going
with "novel element."

If you're really worried about some kind of patent thing then maybe look
through the thesaurus for "novel" and choose an adjective you'd prefer to
propose as an alternative.

—
Reply to this email directly or view it on GitHub
https://github.com/w3c/webcomponents/issues/434#issuecomment-196127194.

[domenic]

I prefer novel element + extended builtin element

[rniwa]

How about "specialized element"? I actually think "custom named element" is just fine in this context since the terminology is introduced just to distinguish type extension and regular custom elements.

Or we could just refer it to as a "custom element with its own localName". I really dislike making up terminologies like these in general because it needlessly increases the entry barrier for casual readers.

[annevk]

@jaubourg I wanted something distinct from new since new already means creating/constructing.

[domenic]

"Novel" seems to capture the fact that these are novel element definitions not in the HTML Standard better than "specialized". And as I said, "custom named element" is not great since the name is not really what we should be emphasizing; it's the whole element that's custom.

I think it's important to have nice simple terms to refer to common concepts. That actually increases the spec's accessibility to new readers. Instead of forcing them to be reminded of minutiae like the definition of local name every time we reference something, they can simply sum up that behavior in their brain by labeling it "novel element".

I'm hoping this is not some kind of blocking issue so I plan to make the change later today after a couple meetings. I'm still willing to accept a synonym for novel if there are patent concerns. Looking through http://www.thesaurus.com/browse/novel?s=t, "original" seems OK, although maybe people would convince it with "the original list of elements already in the HTML Standard." Novel still seems best.

[jaubourg]

The only problem I have with "novel" is that it can easily bring a false
notion of innovation. If an author create a new element very similar to
what another author created in the past, it's not an innovation yet it is
still new. Same goes with original, fresh, etc sadly so maybe it's
unavoidable. I tend to prefer more neutral terms myself. Now I can surely
understand Anne's concerns about the ambiguity with creation of the actual
object.

"extended builtin" does sound like a mouthful to me. Is that supposed to
include elements that are derived from other custom elements? Like an
author creating a customization of another author's new/novel element? Or
is it specific to extending builtins?

Anyway, I don't wanna block anything, I just felt like sharing my thoughts
and give some feedback.

On 14 March 2016 at 19:13, Domenic Denicola [email protected]
wrote:

"Novel" seems to capture the fact that these are novel element definitions
not in the HTML Standard better than "specialized". And as I said, "custom
named element" is not great since the name is not really what we should be
emphasizing; it's the whole element that's custom.

I think it's important to have nice simple terms to refer to common
concepts. That actually increases the spec's accessibility to new readers.
Instead of forcing them to be reminded of minutiae like the definition of
local name every time we reference something, they can simply sum up that
behavior in their brain by labeling it "novel element".

I'm hoping this is not some kind of blocking issue so I plan to make the
change later today after a couple meetings. I'm still willing to accept a
synonym for novel if there are patent concerns. Looking through
http://www.thesaurus.com/browse/novel?s=t, "original" seems OK, although
maybe people would convince it with "the original list of elements already
in the HTML Standard." Novel still seems best.

—
Reply to this email directly or view it on GitHub
https://github.com/w3c/webcomponents/issues/434#issuecomment-196450036.

[annevk]

Good point about extending custom elements with is="". If that's possible it should just be "extended element".

[rniwa]

I strongly object to using the term "novel" so please don't change the spec later this afternoon.

[domenic]

Wow, really? OK. If you really want to block things I guess we'll just stick with custom tag.

[rniwa]

Yes, "novel" is a terrible word to be used in any spec without implying it's related to a patent.

[domenic]

I would suggest you consult with your team internally to find if they share your opinion that this is really an area Apple wants to block the spec on. Usually these kind of spec-internal terminology decisions are left to the editor.

[rniwa]

@domenic : I would also suggest you consult with your team whether "novel" is the best word you can come up with. I'm fine with the current terminology (custom tag) as well.

Since this entire issue is about renaming that to use "novel element", I have to object.

[domenic]

Our team is happy to leave it up to the editor. If your team will block custom elements on this spec-internal naming issue, then that's a shame, but there's not much to do there.

[rniwa]

@domenic : There are plenty of other words in the English language. I'm not certain why you had to pick one word that has a clear association with patents. I'm literally fine with any other word but "novel".

[domenic]

I think the association with patents is not common. A lot of words are associated with patents, but novel is used mostly in contexts that don't have to do with patents. The legal profession repurposes a lot of words to give them special meaning but non-lawyers do not care.

See e.g. https://www.oxforddictionaries.com/us/definition/american_english/novel#nav2 (click "more example sentences").

[domenic]

I would be happy to add a _NOTE: this has nothing to do with patents_ if that would help you. (But, we would probably have to add that to a lot of words used in specs, if you have that concern, e.g. "process".)

[rniwa]

How about "regular custom element" or "ordinary custom element"? They are really the ordinary kind of custom elements as opposed to type extension since the latter one is the odd ball here.

[annevk]

@rniwa I don't think you'll be able to find many people on this planet whose association with "novel" is "patents". That's very far from its typical meaning.

I would be okay with "regular custom element" though. Should the other be "extended custom element" then?

[jarek-foksa]

Has it been decided that "type extension elements" are actually needed?

There is no point in using a term more specific than "custom element" if there will be only one way to create custom elements.

[domenic]

Yes.

[jarek-foksa]

I'm not sure if this is up for discussion, but it feels just wrong that something like <button is="fancy-button"></button> is represented in DOM with inheritance rather than composition.

I would make a clear distinction between (1) custom elements and (2) mixins/traits that can be used to augment standard elements.

The current approach makes it hard to reason about custom elements and I'm afraid that introducing new terminology won't make things much simpler.

[annevk]

Please stick that in a separate issue. The new terminology proposed here is to prevent us getting stuck with bogus terminology.

[annevk]

@domenic are you okay with "regular" and "extended" from https://github.com/w3c/webcomponents/issues/434#issuecomment-196704671?

[domenic]

Not really. It's not the custom element that's being extended. Still haven't seen anything better than "novel element" and "extended-builtin element". Since this is editorial, maybe we should just handle it while merging in to HTML.

[annevk]

Well, we do classify it as a custom element by virtue of giving it the custom flag, I think. Maybe "custom regular element" and "custom builtin element".

[domenic]

What's a "regular element"?

[annevk]

Regular is there to disambiguate from custom element, which we use for either... That's it. Could also be "normal", "ordinary", ...

[domenic]

What's regular, normal, or ordinary about <as-df>? If anything, <p> sounds more regular, normal, or ordinary to me. How did we go from "novel" to "regular"?

[annevk]

Ah, "regular custom element" (<tee-hee>) vs "custom regular element" (<p is=tee-hee>).

[zcorpan]

How about "autonomous custom element"? (and "extended-builtin element")

[domenic]

I'm going to go with "customized builtin element" and "autonomous custom element". Will append a commit to https://github.com/whatwg/html/pull/1012 (and won't squash it in, so that it is clear it is a post-upstreaming change).

[amiller-gh]

Jumping in late I know, but what happened to discussion around Original Custom Element and Extended Custom Element? Personally, those are my favorite options so far.

Also may want to look at synonyms for "first" or "main" as antonyms for extended: http://www.thesaurus.com/browse/first, http://www.thesaurus.com/browse/main

Some more options to consider:

• Primary Custom Element and Extended Custom Element
• Basic Custom Element and Extended Custom Element
• Fundamental Custom Element and Extended Custom Element

[domenic]

Although those are somewhat reasonable suggestions, I'd really rather not drag out this bikeshed too long. They don't seem sufficiently better than "customized builtin element" and "autonomous custom element" to be worth the churn. Each of them has something a bit strange about them, e.g. "original custom" is kind of a contradiction, "extended custom" is inaccurate since you're not extending a custom element, "primary custom" makes it sound like there can only be one, "basic custom" sounds like it should be distinct from "advanced custom" which doesn't exist, "fundamental custom" again implies some kind of non-fundamental custom element type.

I'd like to move on.

[rniwa]

customized builtin element and autonomous custom element seem fine. I agree we should move on since it's not like these names would be exposed to authors in any way.

[annevk]

This has been done.