The use case I was thinking about was something like this.

I want to make a calendar for a month as a custom element, and I don't think passing up all the event data as JSON or something is the best idea. So I thought about making some custom elements that don't actually render anything, they're just there to provide the calendar widget with necessary data. Something like this:

<cal-month month="4" year="2022">
  <cal-event date="2022-04-05" start="12:00" end="14:00">Dentist visit</cal-event>
  <cal-event start="2022-04-12" start="17:00" end="18:30">Job interview</cal-event>

The approach works, but I'm not sure if I'm doing a good thing or if it'll be the best to pass the data in some other way.

1 Answer 1


There is a risk with introducing your own HTML elements. The World Wide Web Consortium publishes the HTML standard that browsers implement. The custom elements API is available to do precisely what you did. According to the HTML5 spec, no new elements will be added with a hyphen in the name (see valid custom element names). The elements you defined shouldn't conflict with future HTML revisions because you prefixed the names with cal-.

You could also consider HTML data attributes as a means to embed application-specific information on standard HTML tags, which JavaScript can use. You can target these attributes in CSS files to provide additional styling. Microdata is another standard technique that allows you to provide additional semantic meaning to regular HTML elements. JavaScript can interact with this data, and CSS styles can target these elements.

Lastly, you can utilize the shadow DOM as a means to encapsulate components. In fact, the shadow DOM is used by modern browsers to implement interactive form fields like native date pickers.

Which one you choose is a matter of taste. If you need styling, behavior and markup combined into a single component, consider using the shadow DOM since this provides a natural way to encapsulate the component from the rest of the web page.

If defining your own elements is just a means to store data used by JavaScript, I would lean towards HTML data attributes. You can stuff JSON into them and use JSON.parse to turn it into an object in JavaScript. I've also used script tags with JSON as well. Not a standard way of doing it, but it also works:

<script type="text/json">
    "foo": [ ... ]

There is no single right way to do this. You have a number of options available, so choose the one that is the best balance between the HTML standard and getting the job done. Just know that if you don't adhere to the HTML spec, you risk breaking the page if future updates to the standard conflict with your custom HTML.

  • 1
    There will never be a standard HTML element with a hyphen in the name – that entire namespace is perfectly fine for use with custom elements or React components. I don't think Shadow DOM is relevant here. But your point about just using a script with JSON to provide the data is very good, if it is acceptable that the component hydrates itself only at runtime (server-side rendering would likely be impossible though).
    – amon
    Apr 29 at 7:07
  • @amon: the current standard describes tag names as being alpha-numeric (implying no dashes, colons or underscores). Don't confuse this with will never contain a hyphen. For instance, prior to the introduction of aria attributes, I don't remember any attributes with hyphens in them. They suddenly needed a "namespace" so they invented one. Same thing could happen with HTML -- especially with HTML's limited vocabulary. Apr 29 at 11:39
  • Of course this must all be balanced with the likelihood that <cal-month> will ever be added to the HTML spec. This is a pretty low chance for most application-specific custom elements. So ultimately it is a judgement call. Apr 29 at 12:00
  • from the same WhatWG spec: Valid custom element names “contain a hyphen, used for namespacing and to ensure forward compatibility (since no elements will be added to HTML, SVG, or MathML with hyphen-containing local names in the future).”
    – amon
    Apr 29 at 14:18
  • 1
    @amon: It's always the fine print that gets you, isn't it. ;) Let me try to amend my answer. Apr 29 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.