DEV Community

Discussion on: Stop using so many divs! An intro to semantic HTML

Collapse
 
kenbellows profile image
Ken Bellows

Thanks, fixed!

By custom tags, do you mean custom elements? Those are a whole other ball of wax. They're part of the Web Components API, which requires JavaScript and a ton of extra domain knowledge. This article is just an introduction to an important feature of HTML5, and Web Components are not a part of HTML5, so that would fall pretty far outside the scope of this article.

To be honest, I'm pretty unfamiliar with custom elements myself, so I'm not the person to write that article. Sounds like you have some background, so maybe you are! I'd love to read it!

Collapse
 
tygari profile image
Tygari

Yes custom elements are what I mean.

Though there is far more to it than I know or understand (for now). In it's simplest form you can just write a tag as < box>< /box> (or any word you choose) and be able to target that tag as you would any other.

JavaScript:
document.getElementsByTagName("box")

CSS:
box{display: none;}

All without understanding anything else of the API.

The greatest thing about a custom tag is it is blank.
No pre-attached css or code like 'p' or 'div' have. Your free to write without having to remember what has what attached.

I use this kind of coding extensibly in my Browser Game "EVO Idle". As well as some new Dynamics to manipulate information quickly and easily. (Be warned some are considered against the standard.)

Thread Thread
 
kenbellows profile image
Ken Bellows

RIght, that's the thing. Those aren't so much "custom elements" as they are "nonstandard elements", because the browser doesn't understand them, and they don't have any functionality backing them. It is true that you can write arbitrary tags in your markup, and IIRC the browser treats them like <span>s by default (which is to say, as generic inline elements), but this isn't standard practice, and it's usually considered a bad idea.

A custom tag name indicates to other developers that there's something special about this tag, that it's a component or a proper Custom Element with some JS behind it or something, and it can be very confusing to read markup with lots of nonstandard elements that aren't backed by any other code, especially if they're mixed with actual components that are backed by code. So my recommendation is to instead use a standard element with a class="..." instead of a custom tag name. The only thing that changes in your selector is an extra . before what would have been the element name, and is now a class name.

Just my two cents, take it or leave it 😊

Thread Thread
 
moreurgentjest profile image
more-urgent-jest
Thread Thread
 
kenbellows profile image
Ken Bellows • Edited

Yep, that's a nice summary! They distinguish there between "non-standard elements", arbitrary tags that have not been added to the CustomElementRegistry, and "custom elements", which have:

Custom elements provide a way for authors to build their own fully-featured DOM elements. Although authors could always use non-standard elements in their documents, with application-specific behavior added after the fact by scripting or similar, such elements have historically been non-conforming and not very functional. By defining a custom element, authors can inform the parser how to properly construct an element and how elements of that class should react to changes.

(My emphasis added.)

The word "defining" is linked to the portion of the standard that describes how to define a custom element, which begins as follows:

Element definition is a process of adding a custom element definition to the CustomElementRegistry. This is accomplished by the define() method.

Thread Thread
 
tygari profile image
Tygari

I disagree. If people wish to make assumptions about everything than it is their own fault for messing up.

A simple Google check will verify if a tag is standard or custom.

Using custom tags with or without javascript makes the document more readable. Which is the point you were making.

Not everything needs to be predefined.
If it were the language would never have evolved in the first place.

It is people pushing out of the standard practice that evolve the language.

If you wish to be confined by such limitations that is your choice.
I choose to evolve my coding style by trying new things and creating new concepts. Even in the face of the people's backward concepts of what is and is not proper coding.

Thread Thread
 
kenbellows profile image
Ken Bellows • Edited

Alright, please read what I have to say here in full. I need to say something that I feel is very important.

I fully respect that you have a different opinion from me on how best to write your markup. And I'm perfectly cool with that; you can write your HTML in whatever way you see fit, and I'll be happy to hear how it works for you, and what benefits you find in it. Genuinely, reading about alternative viewpoints on web development is one of my hobbies, and I almost always find something I like in every one I explore.

But please do not turn around and label my attempts to explain the existing standards and best practices of the web platform as "backwards concepts of what is and is not proper coding". Because these are not some arbitrary whims handed down from some oligarchic hierarchy of web gods. These are standards with a huge amount, literally decades, of research, community-wide debate, and iterative revisions behind them, and there are are very good reasons why they exist.

It honestly hurts to be accused of trying to "confine" and "limit" people from "trying new things and creating new concepts" simply because I'm explaining the background and advantages of the specs that are out there. My point was never that nonstandard tags are evil and you should feel bad for using them. But you started the conversation by suggesting that I should have promoted nonstandard elements as a good practice that "help[s] so much in pushing this to the next level." The fact that you said that nonstandard tags can build on the techniques that I discussed in my article tells me that I did a poor job of emphasizing the reasons why we use standardized semantic tags. Semantic tags are not primarily about improving code readability. If that was the case, there would have been no point in defining a spec for them; we could just standardize the use of arbitrary tag names and let common patterns develop within the community, like we have with CSS class names.

My point in this thread was to let you know that there is a very real difference between arbitrary nonstandard elements, which have no defined semantics or behavior and can't be used by assistive tech or web crawlers, and true custom elements, for which the developer has explicitly defined the behavior and semantics for the browser.

Because here's the thing: the semantic web isn't just a matter of preference or style or convenience. It has a huge direct impact on the lives of many, many users, those who rely on assistive technology, which in turn relies on the semantics it can parse from the text to help those users.

If you've never tried to use the web with a screen reader before, please do. I think every web developer needs to do this periodically in order to better understand how many of their users interact with the web, and how honestly horrible a lot of the web can be for users who rely on assistive tech. If your site is built with nonstandard elements with no defined semantics, then the best that a screenreader can do is read the text top-to-bottom, with no way to let the user easily navigate the page. But if you use the elements I talked about in this article, a screen-reader can add build an outline of the page to give to the user, and it makes it a hundred times easier to navigate the page.

And microdata specs like RDFa help fill in the rest of the semantics that aren't expressible in HTML alone. Seriously, browse a little through schema.org/docs/full.html and look at all the options. And that's all stuff that assistive tools can potentially utilize to give users more context about what the page represents. (And by the way, it can dramatically help your SEO on top of this.)

In my experience, there's a tragic lack of attention paid to semantics in web development training, and this knowledge gap actively hurts the users that actually need it. That's a big part of why I wrote this article. Using semantic HTML and microdata formats improves the lives of many people much more directly than you might expect. Nonstandard tags, unfortunately, don’t, and I worry they may redirect devs away from the standard methods that do because nonstandard tags require fewer characters and zero research.

Maybe I should have emphasized the a11y aspect of semantics more strongly in my article, and maybe I'll write a follow-up to do just that. But please, please don't think that I or anyone else is trying to enforce some arbitrary restrictions that stifle innovation by recommending that devs avoid nonstandard elements and use existing semantics frameworks instead. What I'm trying to do is help one of the most underserved and ignored groups of users on the web.

Thread Thread
 
jonlauridsen profile image
Jon Lauridsen

This feels like a hugely under-appreciated comment, it’s a very good reply. I seriously think you can turn this comment into its own blog.

Thread Thread
 
kenbellows profile image
Ken Bellows

Thanks 😊 I may do that

Thread Thread
 
rhymes profile image
rhymes

Please do :-)

Thread Thread
 
kenbellows profile image
Ken Bellows

For posterity, since new people seem to keep finding this article and this comment thread, I did write that follow-up: