Popular posts

Your made up tags could mean almost anything, it's more invalid code for the parser to try to turn into something valid

This is not the case, custom elements are something defined by the HTML specification. These are valid, and as native to HTML as any other tag it defines in the spec: html.spec.whatwg.org

I haven't branched out into using JS to define custom elements with custom behaviours, so right now I'm limiting my usage to things that otherwise would have been <div> or <span>, and otherwise blank canvases for whatever functionality and styling you wanted to add to them.

I am not sure why I waited so long to begin using custom elements, but now that I've begun writing <video-container> instead of <div class=video-container> it feels more correct, because really it wasn't a class of div, I might have <video-container> elements I want to add classes to, like <video-container class=wide> or <video-container class=shadow> or something like that, so I was already kind of thinking of <div class=video-container> tags like their own tag name, it feels better to write <video-container class=wide> than <div class="video-container wide"> where I'm using two class names, but I'm thinking about one more like a tag name, and the other more like a class usually is used.

Try it, you might like it :D

It's an interesting idea, but I believe that constraints are a blessing in disguise; I believe that working within pre-defined HTML specs eliminates a chance of running into unknown-but-potential issues and workarounds to remedy them in the future.

To me, the gains of slightly cleaner syntax and "better" language features are not enough for me to deal with extra steps described in the whatwg.org page you mentioned, more complicated development considerations and potential issues as a result of doing more work. I prefer to stick to the minimum viable set of the official HTML 4 Strict tags and prefer not to mess with something as foundational as HTML elements.

Furthermore, I am not a fan of the implication behind this kind of idea. It will be a matter of time before someone will start creating tags like <red-colored-container>, <all-text-italic-inside>, etc. all sorts of presentational crap, defeating the whole purpose of HTML as Jason Knight already explained earlier. Heck, I could even see some bozos crying out loud, "Wah wah I dunt wunna luarn how header tags work, so I'm creating my own!" and write <header-2-bold-italic> or something crazy like that.

Have you considered that the "headline" text that's marked up as <jumbo-headline> might not be a "jumbo" "headline" text in the next website revision?

I believe that working within pre-defined HTML specs eliminates a chance of running into unknown-but-potential issues and workarounds to remedy them in the future.

This is within the pre-defined HTML specs, I linked right to the section. The built-in workaround that makes this future-proof is that all custom element names must contain a dash and conform to a valid custom element name and all future HTML elements won't have a dash in the name. For example, custom element names like <row-> and <grid-> are valid and will always work, even if HTML someday gets native <row> or <grid> elements.

To me, the gains of slightly cleaner syntax and "better" language features are not enough for me to deal with extra steps described in the whatwg.org page you mentioned

To use an autonomous custom element, all you have to do is type it in HTML syntax <like-this>. There's nothing more you need to do. This is supported already in every browser that supports HTML5 (including IE).

This is what HTML is already for years, it's just that people haven't taken full advantage of it yet.

Furthermore, I am not a fan of the implication behind this kind of idea. It will be a matter of time before someone will start creating tags like <red-colored-container>, <all-text-italic-inside>, etc. all sorts of presentational crap

I guess we shouldn't have JavaScript because it's possible to write an infinite loop that will crash the browser. There are already tons of ways you can abuse HTML and write bad HTML without even making use of custom elements, but I think having a built-in way to extend the language is a powerful feature.

It certainly helps with web standardization efforts and R&D, and for those that want to make use of it, it provides a very clean way to build on top of what HTML already provides.

Check out the Extensible Web Manifesto to see the driving attitude behind custom elements, web components, CSS variables, Houdini, and a whole bunch of other technologies aimed at opening up HTML, CSS, JS and the browser and allowing developers to extend these things in a standardized way: extensiblewebmanifesto.org

This is not the case, custom elements are something defined by the HTML specification.

They are now. They didn't used to be and can wreak havoc in legacy UA's. Prior to recent changes to HTML 5 there was no such thing. In fact the entire idea of being able to make up any-old-tag runs contrary to the intent and purpose of HTML.

If it didn't, we wouldn't be using HTML, we'd be using SGML or XML.

To me, "wah wah, I don't want to type class=" is as silly as the painfully cryptic and aggravatingly annoying arrow functions in JavaScript. Something we don't need and makes working with websites harder. Particularly since the UA pretty much would have to just treat them as a DIV or SPAN since it has zero clue what your made up tag means. Semantic markup is supposed to be about labelling the content for what it means in a grammatical / structural setting in a manner the UA can convey. That's why DIV is neutral and the correct tag, so UA's can quickly go "Ok, I don't need to do that when conveying this to speech or braille or any other non-visual media".

Worse, it basically encourages the garbage practice of people using DIV for nothing and classes for nothing to slop in made up tags for nothing; just sleazing along with the same practices as the endless pointless tables for nothing of yesteryear.

But again, there's a reason when people do half-witted garbage like this:

<body class="home blog hfeed has-header-image has-sidebar colors-light">
<div id="page" class="site">
    <a class="skip-link screen-reader-text" href="#content">Skip to content</a>

    <header id="masthead" class="site-header" role="banner">

        <div class="custom-header">

        <div class="custom-header-media">
            <div id="wp-custom-header" class="wp-custom-header"><img src="s1.demo.opensourcecms.com/wordpress/wp-content/th…" width="2000" height="1200" alt="opensourcecms"/></div>        </div>

    <div class="site-branding">
    <div class="wrap">


        <div class="site-branding-text">
                            <h1 class="site-title"><a href="s1.demo.opensourcecms.com/wordpress" rel="home">opensourcecms</a></h1>

                            <p class="site-description">Just another WordPress site</p>
                    </div><!-- .site-branding-text -->

                <a href="#content" class="menu-scroll-down"><svg class="icon icon-arrow-right" aria-hidden="true" role="img"> <use href="#icon-arrow-right" xlink:href="#icon-arrow-right"></use> </svg><span class="screen-reader-text">Scroll down to content</span></a>

    </div><!-- .wrap -->
</div><!-- .site-branding -->

</div><!-- .custom-header -->


    </header><!-- #masthead -->

I typically would have this:

<body>

<h1>
    <a href="/wordpress/">
        OPENSOURCECMS
        <span>-</span>
        <small>Just another WordPress site</small>
    </a>
</h1>

With 99% the functionality since alternative navigation would let me jump to the first H2 or HR as the start of the flipping content, and because I understand selectors and the cascading part of cascading stylesheets I don't have this urge to mindlessly and pointlessly throw classes at everything. I also don't tend to vomit up scripting only elements all over the static markup just for goofy scroll effects, trying to compensate for the bad choices made in splash-page style designs.

So many things people are doing right now that have zero blasted business on websites in the first place, then jumping through massive hoops and throwing endless code at workarounds instead of just cleaning up the mess.

But again, there's a reason I say the folks at the WhatWG were unqualified to make HTML 4 strict's successor, threw almost all the concepts of proper semantics and structure in the trash because they never embraced STRICT, and have done nothing more than cater to the whims of HTML 3.2 / 4 Tranny style developers who never managed to extract their cranium from 1997's rectum.

As evidenced by the short-lived HGROUP tag that proved they didn't even understand what numbered headings were for, what they mean, or how they were supposed to be used. Gee, then we wonder why SECTION is an incompetent mess?

But again, with 90%+ of the code on the web failing to even grasp the most basic concepts of HTML such as why headings even have numbers... what did we expect?

Hence why that "extensible web manifesto" screams -- to me at least -- "you know what, to blazes with accessibility" in mindset; or at least once you get past the marketspeak doubletalk to find what little actual meat is there on the page. Pages / sites like that always leave me yelling like the little old lady in the Wendy's commercial: "Where's the beef?"

But hey, hot trendy bling bling...

I like to write terse, simple HTML and make use of 100% of the functionality built into the language, I'm definitely not reaching for things like custom elements because I'm lazy, or not wanting to apply myself to learning HTML, I'm using them here to extend HTML beyond what it includes definitions for, using the built-in mechanism to do so.

What I'm doing isn't hot and trendy, as you can see by the reaction here :D What's hot and trendy is to reach for JSX and define things like <Sidebar> which is neither valid in JavaScript (and has to be preprocessed first) and also isn't a valid HTML custom element name either.

That's what's hot and trendy right now, but I'd sooner make use of the web platform and it's built in features before I started using non-standard syntax in JS to output HTML for me.

I'm using them here to extend HTML beyond what it includes definitions for

The very thing that killed XHTML, and makes it far too easy for people to be duped into thinking semantics doesn't matter.

We already have more than enough tags without those making the specifications shrugging, going "whatever" and letting people just slop them in any-old-way.

Though said laissez-faire slop it out however attitude seems to have been much of the driving force at the WhatWG, as the "specification" itself -- assuming one can even call it that -- makes all too obvious.

More so with that ridiculous "living document" bull. Not a fan!

... and I consider it just as nonsensical as JSX so. Gah, JSX; as broken and silly as that XSLT nonsense.

Speaking of other dead-ends of pointlessly convoluted ways of destroying what HTML is even for whilst promoting bad practices...

The things people do with this stuff simply are not things I would ever even consider doing for the fact it's harder to maintain, harder to develop, confusing, cryptic, and more often than not rains down a yellow shower upon accessibility from so on-high you'd think the almighty just got back from a kegger.

Again, exactly the type of nonsense I've been paid to rip out of clients websites the past decade or so.

To use an autonomous custom element, all you have to do is type it in HTML syntax <like-this>. There's nothing more you need to do.

Not exactly. Try <name-claim> and style it. It won't work. Besides, the custom element's purpose is to aid with web app development. (Web Components, etc.) It's not for naming your version of HTML and claiming it as if all browsers natively support them without some extra work.

Again, as Jason Knight already explained, I dislike the implication behind this kind of idea. I don't see good enough reasons to use custom elements when it comes to authoring a website.

Speaking of Web Components and Polymer, it's not all rosy:

dmitriid.com/blog/2017/03/the-broken-promise-of-w…

I guess we shouldn't have JavaScript because it's possible to write an infinite loop that will crash the browser. There are already tons of ways you can abuse HTML and write bad HTML without even making use of custom elements

Absolutely. We have way too many frameworks and trickeries that put unnecessary giant weight on so many websites. JavaScript overuse is one of the significant reasons websites are often slow and buggy. I'm shocked to see the number of errors in my browser console nowadays. Let's start by removing that big Jumbotron slider, get rid of all the animated nonsense often done through JQuery, and remove all the stupid JavaScript files WordPress plug-ins inject on every friggin' page. Better, let's scrap WordPress, Bootcrap and countless CSS frameworks and make developers LEARN the foundations correctly.

Mindless extensibility is one of many reasons people abuse HTML and write bad frontend code. We need to advocate RESTRICTION of such "extensibility mindset" because it's way too easy for developers to get into "the more, the better" mentality. We ought to consider whether something is so compelling that its trade-offs are worth taking. I contend that such technologies come maybe once every decade at this point. Besides, most of us just need to learn the basics a lot more than we do before jumping into "fancy" stuff. I know that's been the case with me. Fundamentals go a very long way. Most of us think we know, but we don't, really.

Not exactly. Try <name-claim> and style it. It won't work.

<name-claim>What are you talking about?</name-claim>

<style>
  name-claim {
    display: block;
    background: purple;
    color: red;
    font-size: 100px;
  }
</style>

Of course it works like that, it's part of HTML5 which means it's supported in every browser like this already, including IE11!

Of course CSS can style HTML elements, that's what it's designed to do! You know what else works really well with HTML elements? JavaScript! You can select this with document.getElementsByTagName() and document.querySelector() just like you'd expect.

Did you even try it yourself in your own browser to see before you made that claim that it's unstylable? This is real HTML.

What are you talking about?

I'm talking about how it will NOT work until you specify its element type. You add a display property and then you style. It doesn't count as "it works" when a div and span tag don't require it. How is that better than adding a class name to a div tag?

Custom elements have no implicit semantics or keyboard support, and it is a massive problem, a massive middle finger for those who have accessibility needs. Millions of them, in fact. When you define a new tag, the browser really has no way of knowing if you’re trying to build a button, or a slider, or just a fancy text container. Adding these features requires a fair bit of work on the developer’s part and it can be difficult to reach parity with the native equivalents.

It is just like how people say it's cool to litter HTML with "<div class="color-danger look-like-this">" style presentational classes just because it's technically legal to do so. Just because you can doesn't mean you should.

I'm talking about how it will NOT work until you specify its element type.

What do you mean by this? Where did I specify the 'element type' in my example? I just wrote the tag in HTML and when the browser read my HTML it created a new HTMLElement for us.

You add a display property and then you style.

The only reason I added any styles at all is because you said: “Try <name-claim> and style it. It won't work. ” So I did try it, and it did work. What's your point about styling it again? I didn't have to give it any particular styles for this to be a valid HTML element. CSS doesn't make an HTML element valid, it just applies styles to elements.

How is that better than adding a class name to a div tag?

Just in the naming alone. The way this lets you work with these elements as elements, rather than as a class of other elements.

Custom elements have no implicit semantics or keyboard support, and it is a massive problem, a massive middle finger for those who have accessibility needs.

Do <div> and <span> tags have implicit semantics or special keyboard support? Are they a middle finger to people with accessibility needs? As with anything you build, you can define keyboard controls with things like tabindex and accesskey, or with JavaScript. That's no difference from anything else. Nowhere in anything I said was I talking about building interactive elements out of custom tags, I have been really specific about only using them for semantically meaningless wrappers.

When you define a new tag, the browser really has no way of knowing if you’re trying to build a button, or a slider, or just a fancy text container. Adding these features requires a fair bit of work on the developer’s part and it can be difficult to reach parity with the native equivalents.

Cool, but that's not at all anything related to what I've been talking about doing with custom elements.