Are Custom Elements Valid Html5

Are custom elements valid HTML5?

The Custom Elements specification is available in Chrome and Opera, and becoming available in other browsers. It provides a means to register custom elements in a formal manner.

Custom elements are new types of DOM elements that can be defined by
authors. Unlike decorators, which are stateless and ephemeral, custom
elements can encapsulate state and provide script interfaces.

Custom elements is a part of a larger W3 specification called Web Components, along with Templates, HTML Imports, and Shadow DOM.

Web Components enable Web application authors to define widgets with a
level of visual richness and interactivity not possible with CSS
alone, and ease of composition and reuse not possible with script
libraries today.

However, from this excellent walk through article on Google Developers about Custom Elements v1:

The name of a custom element must contain a dash (-). So <x-tags>, <my-element>, and <my-awesome-app> are all valid names, while <tabs> and <foo_bar> are not. This requirement is so the HTML parser can distinguish custom elements from regular elements. It also ensures forward compatibility when new tags are added to HTML.

Some Resources

Example Web Components are available at https://WebComponents.org
WebComponents.js serves as a polyfill for Web Components until they are supported everywhere. See also the WebComponents.js github page & web browser support table.

What are valid HTML5 custom tags?

TL;DR: There are no valid custom HTML5 tags.

I think you may be referring to this Custom Element Working Draft proposed by the Web Applications Working Group, which describes this:

The custom element type identifies a custom
element interface and is a sequence of
characters that must match the NCName
production, must contain a U+002D HYPHEN-MINUS
character, and must not contain any uppercase
ASCII letters. The custom element type must not
be one of the following values:

annotation-xml

color-profile

font-face

font-face-src

font-face-uri

font-face-format

font-face-name

missing-glyph

Additionally, according to HTML5 specification, HTML tag names can only start with ASCII letters. If we assume that the Custom Element proposal does not propose any changes to the HTML Syntax specification, then elements starting with hyphens-minus character is not a valid HTML tag name. If we combine what the Custom Element Working Draft proposal and the HTML5 Syntax specification says, then we can conclude that <-custom> is not a well-formed HTML and so cannot be a valid Custom Element because the tag name does not start with ASCII letter. On the other hand, custom- is both a well-formed HTML and a valid Custom Element.

Note that Custom Element is a Working Draft, not a W3C Recommendation. This means that Custom Elements is not valid in HTML5. Don't get your hopes up either, a lot of Working Drafts that are proposed in W3C never got anywhere (and for good reasons too, not all of the proposals are good).

<rant>Personally I hope that this proposal got shot down. I spent some time reading this proposal, it looks like this proposal tried to reinvent XML Namespace and SGML poorly, and probably forgot about what HTML and the semantic web is supposed to be. In any case, HTML5 syntax already allows authors to use elements that aren't specified in HTML5 specification, I don't see any need to standardize how to create custom elements any further than that. I hope that there would be people in HTML5 working group sane enough to realize how bad this proposal is and vote this proposal off. Keep HTML5 closed from author-defined custom modifications.</rant>

If you want to define your own custom vocabularies, I suggest you should write an XML application with XHTML5, which actually specifies how you can define your own custom elements with XML namespaces. Unlike HTML, XML is designed to be extensible.

As for your question about custom data attribute, this is what the HTML5 specification says:

A custom data attribute is an attribute in no namespace whose name starts with the string "data-", has at least one character after the hyphen, is XML-compatible, and contains no uppercase ASCII letters.

So with your examples, these are valid data-* attributes:

data-my-attribute

while these are not:

my-attribute

As far as I can tell, the Custom Elements Working Draft does not specify any additional syntactical requirement for custom attributes on Custom Elements, nor does it explicitly permit using arbitrary non-data-* attributes and how custom attributes interacts with existing HTML attributes, although we can reasonably infer that allowing custom attributes is probably the intent of the proposal.

As for your question about CSS, yes you understood correctly, those are valid CSS selectors to target those Custom Elements. CSS can be used to style any elements, not just elements defined by HTML, but also other markup languages like SVG, MathML, as well as arbitrary XML vocabularies when using XHTML. The CSS Selectors specification does not actually depend on HTML vocabulary in any substantial way (although HTML is used heavily in the examples, as it's what most people are most familiar with). It is for this reason that CSS Selector syntax can be used to refer to any elements in the document, including custom elements that aren't specified in the HTML specification. Styling custom tag already works in all major browsers today. You can use any arbitrary tag names, and select them with the selector that you expect, and CSS will style them as you would expect them to be. There is no requirement for having hyphen-minus in the tag name for this to work.

Is it safe to use Custom Elements today?

TL;DR; Yes, Web Components is a standard ... no polyfills required

Custom Elements API
shadowDOM
Templates

Are the 3 technologies what we also call "Web Components"

each can be used without the other!

HTML Imports was scrapped
Some include ES Imports

"Web Components" are a W3C standard and supported in all modern Browsers:

Chrome (and Edge, Brave and others running on Chromium), Safari and FireFox

They are as much a standard as any other ES technology

Don't get misguided by old blogs discussing (what we now call) the "V0" standard; which mainly was a Google lets-throw-something-against-the-wall-and-see-what-sticks party only; with input from Mozilla and Apple.

Web Components V1 (since early 2018) is a solid joint effort by Apple, Mozilla and Google.

Microsoft joined the party when they decided to swap Browser engines and make Edge run on Chromium

(Historically) there are 2 types of Custom Elements:

Autonomous Custom Elements, extend from HTMLElement
Customized Built-In Elements, extends from any HTML Element (eg: HTMLButtonElement)

Apple has stated, since 2016, they won't implement the latter! (and most who dig deeper, say Apple is right on this one)

It also worth to note, in august 2019, the W3C signed an agreement that the WHATWG

(that is: Apple + Google + Mozilla + Microsoft) is in charge of all HTML and DOM developments; the W3C will only give final approval on standards.

Setting standards is a slow (but steady!) process, because all 4 companies have to agree now.

But just think... Web History has been nothing but (browser) wars...

have you ever seen co-operation like this in the Webs 30 year history?

So what will the future bring?

One new war is already being fought... oblivious to many developers

Note the one big "front-end" name missing...

and the WHATWG is "By invitation only"

Also read: main differences React, Lit, Web Components

Is it bad practice to use custom elements in HTML5?

The W3C says you should not. It is bad practice.

Authors must not use elements, attributes, or attribute values that
are not permitted by this specification or other applicable
specifications, as doing so makes it significantly harder for the
language to be extended in the future.

Furthermore, HTML5 is not XML. You should only use the elements outlined in the official spec.

Proper way to apply CSS to HTML5 custom elements

You can apply CSS to custom elements just like you can to standard HTML elements.

There's nothing wrong with scroll-content { ... }, as written in your code.

A Little Background

The browser, at a basic level, has no clue what elements exist. It doesn't recognize anything... until it is exposed to the default style sheet (sample).

The default style sheet introduces the browser to HTML elements.

Custom elements can therefore be defined as elements that are not included in the default style sheet. (Elements that exist, but are unsupported by the browser, could share this definition.)

Custom elements could, however, be introduced to the browser in author styles.

Here's something important to consider:

If the browser doesn't recognize an element (i.e., it's not in the default style sheet), it will apply CSS initial values.

6.1.1 Specified
values

User agents must first assign a specified value to each property based
on the following mechanisms (in order of precedence):

If the cascade results in a value, use it.

Otherwise, if the property is inherited and the element is not the root of the document tree, use the computed value of the parent
element.

Otherwise use the property's initial value. The initial value of each property is indicated in the property's definition.

As outlined above, if an element is unrecognized (#1 & #2 don't apply), use the initial value from the property definition (#3 applies).

So in your case:

Your custom element is: <scroll-content>
Your CSS is: scroll-content { overflow: hidden; }
You say in your question that this code does what it's supposed to do. But unless the framework you mention provides additional styles for custom elements, it cannot work (demo).

Here's why:

Since <scroll-element> is not in the default style sheet it will use CSS initial values.
Well, the initial value of the display property is inline.
But the overflow property only works on block elements.

So there's no way this HTML/CSS combination could work – the overflow property would be ignored, as would height, width and any other properties that don't apply to inline elements.

A custom element would need to have display: block applied for overflow to work (demo).

Similarly, the only reason body, div, h1, p, ul exist as block elements is because they are defined this way in the default style sheet (sample).

So, putting aside the arguments for and against custom elements, here's the bottom line:

Add display: block to your custom elements and you're good-to-go.

Are Custom Elements Valid Html5