0

In theory, I could use anything, anywhere and style a <table> into a <ul>. Or style an <imsocool> blue.

<style>
imsocool {
    color: blue;
}
<imsocool>HELLO</imsocool>

Sometimes the validator complains (not like I care - it complains about "parse error" when validating calc()s in css), but the browsers never do. The only problem I guess, is that browsers, screen readers, search engines, and everything else don't have any idea what <imsocool>s are. Unknown tags don't have are, well, unknown. So when is this ok?

Is it ok to make special widgets like this (with JS, of course)?

<calendar>
    <ctrlgroup>
        <ctrl class="left">&lt;-</ctrl>
        <ctrl class="left">-&gt;</ctrl>
    </ctrlgroup>
    <week>
        <day>1</day><day>2</day><day>3</day><!-- Etc. -->
    </week>
</calendar>

Do I need to use dashes? (as the spec says - it's supposed to prevent conflicts with future elements)

<calendar-widget>
    <ctrl-group>
        <cal-ctrl class="left">&lt;-</cal-ctrl>
        <cal-ctrl class="left">-&gt;</cal-ctrl>
    </ctrl-group>
    <calendar-week>
        <calendar-day>1</calendar-day><calendar-day>2</calendar-day><calendar-day>3</calendar-day><!-- Etc. -->
    </calendar-week>
</calendar-widget>

Or should I not use it at all?

<div class="calendar">
    <div class="controls">
        <div class="left">&lt;-</div>
        <div class="left">-&gt;</div>
    </div>
    <div class="week">
        <span class="day">1</span><span class="day">2</span><span class="day">3</span><!-- Etc. -->
    </div>
</div>

Ignoring browser support, what are the pros and cons of using unknown HTML elements? When is it appropriate?

What I can think of:

  • If no element in the spec fits the job good enough, there isn't going to be any semantic meaning lost - <div> doesn't mean any more than <imsocool>.
  • Classes are annoying.
  • It's a good idea to use the correct elements, if they exist (like use <em> for emphasis, not <big-and-red>)
  • Don't abuse existing elements. You shouldn't style a <table> into a <ul> - it'll confuse the robots (browser, accessibility software, google). So don't abuse possible future elements which might conflict?
Community
  • 1
  • 1
bjb568
  • 11,089
  • 11
  • 50
  • 71
  • I don't like custom tag in HTML at all. We don't need such a thing because HTML is not data structure (like XML), it's just for presentation. Doing like this will **mix** up data and presentation/ui which should be avoided. – King King Apr 09 '14 at 03:54
  • @KingKing But web pages now **are** mixed up. There is content, then there is header/footer, navigation. There is a million levels of divs (that don't group content - these are for presentation). There are UI-only sections. There are sections which require JS to function. The web is not just HTML, then CSS, then JS anymore - it's a mix of all in a big soup. – bjb568 Apr 09 '14 at 03:57
  • [BTW](http://www.w3.org/TR/2013/WD-custom-elements-20130514/) – bjb568 Apr 09 '14 at 03:59
  • 1
    @KingKing I'd argue that there's a lot of room for DSL in HTML. HTML Components, HTML templates, shadow-DOM and the glue to bind them together will allow for highly-modular apps, with high-level abstractions, DSL or otherwise, to keep markup relevant. – Norguard Apr 09 '14 at 04:08
  • If you learned XAML, you would see that a tag (or HTML element) can be considered as a **class**, and a custom tag can also just be seen as a **class**. So the logic is very strict. I like the inheritance hierarchy of classes in WPF/XAML but I don't see such a beautiful thing in the HTML world. Using custom tag will be something complicated while we're still happy enough with the current HTML standard. – King King Apr 09 '14 at 04:12
  • @bjb568 But just because Web pages do mix up presentation and data structure doesn't mean we should encourage it or do it intentionally. – Neel Apr 09 '14 at 04:13
  • Is there a choice? Interactive elements are not text content. HTML is text content. If you need JS, you're doing it wrong? Or just doing it in the **only way possible**? – bjb568 Apr 09 '14 at 04:15
  • possible duplicate of [Using custom HTML Tags](http://stackoverflow.com/questions/5970093/using-custom-html-tags) – Jukka K. Korpela Apr 09 '14 at 04:19
  • @Jukka I specifically mentioned that I didn't care about browser support and that dashes can be used to prevent future conflicts. – bjb568 Apr 09 '14 at 04:21
  • Still a duplicate. Questions like this have been asked several times. This one is also too long, with several vague questions instead of one targeted question that could be answered – a call for discussion rather than an SO kind of question. – Jukka K. Korpela Apr 09 '14 at 04:26
  • 1
    Here is my own opinion, I feel like that using custom tag is some way to extend the HTML, but I think to extend something in programming, using the **inheritance** is the best effective way to do, with **inheritance**, everything will grow unlimitedly and especially that it's very easy to maintain. All the object-oriented technologies have strict class hierarchy which looks like a tree. while I don't see how easy we can do such a thing in HTML, which I feel like as a flat world (not a tree having branches and depth). You can just add more elements to that flat world... that's how it grows. – King King Apr 09 '14 at 04:26
  • @Jukka That is "how do browsers like it?". This is "how is it semantically?". This is a longer question giving more detail. I just tried to make it clearer… – bjb568 Apr 09 '14 at 04:33
  • 1
    xhtml1.1 could maybe be the doctype to use. But before to start create funny custom tag, do you know all the tags avalaible and their purpose ? Is it only for styling ? if yes , use style and attributes like id, class, data. HTML is a standard. – G-Cyrillus Apr 09 '14 at 04:33
  • @GCyrillus Agreed. You need to know HTML to extend it. And don't make
    duplicates (so you need to know CSS and how to use it).
    – bjb568 Apr 09 '14 at 04:34
  • “How is it semantically?” is yet another question, and has the apparent answer that an element that has no meaning assigned to it is semantically empty. – Jukka K. Korpela Apr 09 '14 at 04:42
  • @Jukka Yes, of course. So is it acceptable to use those elements in terms of semantics? When? – bjb568 Apr 09 '14 at 04:43
  • @bjb568 - Acceptable to whom? – Alohci Apr 09 '14 at 07:24

2 Answers2

1

As with any deviation from a standard in the world of code, any non-standard way of doing things will yield undefined behavior because not every agent will agree on handling the situation the same way.

So, to answer your question, this is only okay if you are okay with having unexpected behavior from the browsers, etc. This means that not everyone that encounters your HTML will have the same experience. That is what following the HTML/CSS standards guarantees.

The examples you have provided actually seem to resemble XML, which gives you more freedom in terms of tag names. You could easily create XML documents with style sheets if that is more suitable for your preferences:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="mytest2.css"?>
<people>
    <person>
        <name status="real">Deron Eriksson</name>
        <birthdate>January 22, 1972</birthdate>
        <eyes>blue</eyes>
    </person>
    <person>
        <name status="imaginary">Bob Smith</name>
        <birthdate>December 25, 1989</birthdate>
        <eyes>brown</eyes>
    </person>
</people>

Also, there is a standard being developed for custom HTML tags.

Alex W
  • 37,233
  • 13
  • 109
  • 109
  • 1
    User agents won't handle it the same way? Do you have some examples? – bjb568 Apr 09 '14 at 04:00
  • @bjb568 I was speaking about agents in a general sense, however, I do have [an example](http://www.w3.org/TR/html401/appendix/notes.html#notes-invalid-docs) of the specific case of user agents for this scenario. – Alex W Apr 09 '14 at 04:11
  • So should I use XHTML? – bjb568 Apr 09 '14 at 04:12
  • use xml if you want to name your tags however you like, or use html valid tags . you have option around like aria, data attribute, microformat that can add some more meanings to a , or tag that have purpose :) – G-Cyrillus Apr 09 '14 at 04:23
  • @bjb568 Although it seems that XHTML is [more friendly](http://www.w3.org/TR/xhtml2/conformance.html#s_conform_user_agent) to custom tags, it does not necessarily recommend them. – Alex W Apr 09 '14 at 04:23
  • I've heard around the internet that XHTML is being replaced by HTML5. Is this true? – bjb568 Apr 09 '14 at 04:25
  • it is not in the way you might understand it. It is the latest version/standard of HTML . HTML 4.01, Xhtml1.0 still exist. – G-Cyrillus Apr 09 '14 at 04:35
  • But me likey HTML5 :( – bjb568 Apr 09 '14 at 04:39
  • @bjb568 - HTML5 includes an XHTML serialization (XHTML5) which you can use if you want, to get the best of both. – Alohci Apr 09 '14 at 06:47
  • @AlexW - XHTML2 is officially dead. I recommend that you don't link to XHTML2 spec documents. [XHTML5](http://www.w3.org/html/wg/drafts/html/master/the-xhtml-syntax.html#the-xhtml-syntax) is the future for XHTML. – Alohci Apr 09 '14 at 07:14
0

There is really no advantage to using custom tags. The only advantage is that it could increase readability, but classes are readable enough.

Here is another stackoverflow question that is similar: Is there a way to create your own html tag in HTML5?

Community
  • 1
  • 1
Neel
  • 597
  • 6
  • 19
  • No advantage? [This guy would disagree](http://www.html5rocks.com/en/tutorials/webcomponents/customelements/). – bjb568 Apr 09 '14 at 04:04
  • LOL I've read this article. Most of the article discusses how to implement custom elements. His reasoning? Making code look nicer (i.e., readability). – Neel Apr 09 '14 at 04:10
  • 1
    But readability is important. Readability is understandability is maintainability. – bjb568 Apr 09 '14 at 04:11
  • Right, but properly named classes are just as readable, if not more so. – Neel Apr 09 '14 at 04:15
  • Ok, you can like what you like, but is there anything *against* using it? – bjb568 Apr 09 '14 at 04:20
  • Other than IE handling it oddly and it possibly decreasing readability for others, I don't see any major reason not to. – Neel Apr 09 '14 at 04:27