Can you define your own self-closing tag in HTML5?

Question

I have read this topic, but I still have doubts. Is there any way to define void tag?

I tried this:

<icon class="home"/> (know that slash isn't obligatory)

But, if there is any text content after this tag FF closes them.

<icon class="home"/> Go home

Makes

<icon class="home">Go home</icon>

Should I define somewhere that tag is void-element? Or is it impossible to do with HTML5?

The short answer is that you shouldn't. Point in case, Twitter use the `i` tag for icons – it's 'wrong', but it works. However, there is some really cutting edge stuff that will allow you to do this. In short, if you are asking academically, it's an exciting new part of HTML, if you asking in practice, don't! :) — Rich Bradshaw, Jul 17 '13 at 13:43

t.niese · Accepted Answer · 2013-07-17T13:46:49.143

This is currently not an answer because it does not fully address the question, but it did not fit into the comment section.

The / in /> is ignored by the browsers if parsed to the html5 specs (except foreign elements of MathLM and SVG, because for the elements of this modules their specs has self enclosing element, so there it needs to stay valid)

Relevant parts of the specs:

(The relevant part how browsers should handle missing tags and that they ignore / is missing, i need to look this up)

If the element is a void element no closing tag is generated, because it does not require one.

For the other elements the closing tag is created if it is missing. So if you write something like this:

<div>
    <div/>test
</div>

It will result in

<div>
    <div>test</div>
</div>

Because the / is ignored.

Custom elements are non-void by default. I know there is a draft for Custom Elements but honestly i don't know if it is already supported in some browsers. But even if it is, you will have the problem of backward compatibility. So i would not recommend to use it.

Even so defining a tag name not prefixed with an x- is a bad idea because if later an element is added by the specs with the name you choose and if that has another meaning you will have a problem.

As soon as i have time to look up the specs i'll provide the corresponding missing parts to proof this.

This answer gets some stuff wrong. The HTML5 spec defines its own rules for parsing foreign elements, which does not observe the XML, SVG or MathML specs. For example, XML tag names are case-sensitive, but inline SVG and MathML tag names are not. — Carl Smith, May 26 '18 at 23:49

score -3 · Answer 2 · answered Jul 17 '13 at 13:46

-3

You shouldn't define your own HTML tags, period.

HTML is useful because it's a set of agreed meanings for tags.

(For example, browsers make links clickable because we've agreed (via the HTML spec) that the <a> tag is a link to another page.)

You can create your own tags, but they won't have meaning to anyone except yourself.

For a given purpose, that might be fine, but you're not really using HTML any more.

answered Jul 17 '13 at 13:46

Paul D. Waite

96,640
56
199
270

But if I define all display stuff in CSS (and JS) then tag will be friendly for all, and browser will parse it properly. – l00k Jul 18 '13 at 11:19
1

@non: yes, but as I said, it won’t mean anything to anyone except you. (Which, as I also said, might be fine for your purposes — I’m not clear what your purposes are.) – Paul D. Waite Jul 18 '13 at 11:29
I think this opinion has already been superseded as witnessed by the Custom Tags initiative. You give meaning to custom tags by choosing the Right Names, by adding appropriate styling and/or JavaScript behavior etc. "Not really HTML" was true until custom tags became a viable option in browsers and have become standardized (as a procedure) in themselves. HTML5 *has* custom tags, and it *is* HTML, even semantically valid HTML provided tags are properly defined and used. The alternative is a `
` soup.
– flow Mar 02 '15 at 16:21
@flow: “You give meaning to custom tags by choosing the Right Names” — unless you describe somewhere what that meaning is, you haven’t reliably given it meaning to other humans. – Paul D. Waite Mar 02 '15 at 20:29
@PaulD.Waite Humans aren't the primary target audience of HTML, are they? As long as you keep your code clean, what's wrong with, say, `` as opposed to ``? I would probably avoid such custom tags in regular websites but if you're making a hml5 app, I don't see why custom tags would do any harm. – jpeltoniemi Jun 21 '17 at 04:29
@Pichan: “Humans aren't the primary target audience of HTML, are they?” How so? Computers have no idea what a given tag means; it’s humans that program computers to tell them what to do with HTML. So in your html5 app, I’d humbly suggest that `` misses out on the widely-shared understanding of interaction design and functionality (already baked into browsers and screenreaders the world over) that you’d get with ``. – Paul D. Waite Jun 21 '17 at 07:49
@Pichan And if your icon actually represents something, both of your examples would be better like this: ``. – Paul D. Waite Jun 21 '17 at 07:51
@PaulD.Waite Only if screen reader support is required. And whether your example is better or not is a matter of perspective. I sometimes use custom tags with javascript as a form of abstraction. It's way cleaner(and more maintainable) to type `` and have it expanded programmatically into various other tags than repeat the whole bunch every time you want a button with an icon. When you keep things consistent and documented, you'll be ok. – jpeltoniemi Jun 21 '17 at 08:36
@Pichan: you will. Screen reader users won’t. But hey, we can reassure them that our web apps, although unusable by them, are *way cleaner*. And it’s not just screen readers: it’s any app that was written, by humans, to understand HTML. Your custom tags mean nothing to those applications. Which is fine, but because the one thing that HTML actually does is assign a specified, agreed meaning to tags, you’re not really using HTML any more. – Paul D. Waite Jun 21 '17 at 10:40
@PaulD.Waite I have never had to write screen reader friendly code when working with web apps or even websites. The budget is usually so limited that you just can't afford to care. If I had to, I'd take screen readers into consideration but if it's not a requirement, why waste time(and money) on developing and testing something no one will probably ever use. My point still stands that you can expand clean custom tags into meaningful, though much more verbose standard html. Don't know though how screen readers handle javascript. – jpeltoniemi Jun 22 '17 at 05:45
@Pichan: sorry you’re stuck working on projects run by people with a mindset like that — in my experience, it isn’t more expensive to write meaningful (and therefore accessible) HTML than it is to write non-meaningful HTML. More sorry for the visually-impaired users who can’t use these apps because, apparently, they aren’t worth spending any time or thought on — but of course, that does free up more time to document the custom (but so clean!) languages you can inventing for each project. – Paul D. Waite Jun 22 '17 at 08:12
@PaulD.Waite You must be sorry that visually impaired people can't drive cars either, huh? Among many other things you fail to understand that sometimes it just is as useless to create software for as it is to design a car for the visually impaired. Though this should be cleared already, somehow I feel I need to explicitly state that I don't work on software targeted to the general public. Now get off that high horse and get a normal sized one. – jpeltoniemi Jun 26 '17 at 22:21
@Pichan: sarcasm: well, as long as it’s just a small section of visually-impaired people you’re discriminating against, [*that’s fine*](https://www.gov.uk/rights-disabled-person/overview). Non-sarcasm: depending where you are in the world, my horse is pretty normal-sized these days. – Paul D. Waite Jun 27 '17 at 10:00
@PaulD.Waite Yes, let's spend time making sure the in-house software is screen reader compatible on the off chance the company might some day hire someone who is visually impaired to do a job that consists mostly of looking at the screen. And because we're not playing favorites, we'll of course consider every other minor and major disability, e.g. missing limb(s), color blindness and all kinds of cognitive impairments. Don't get me wrong, I'm all for making things easier for disabled people - where it counts. Sometimes it just doesn't. – jpeltoniemi Jun 28 '17 at 09:59
@Pichan: in the UK, it’s illegal to discriminate against employees on grounds of accessibility. So yes, that’s what UK law says to do. – Paul D. Waite Jun 28 '17 at 11:37
@PaulD.Waite I'm sure you're taking it too literally. I just refuse to believe you'd be guilty of discrimination if you chose not to hire someone whose disability would noticeably affect their work performance. Software designed for that kind of work therefore couldn't possibly be discriminatory. If I'm wrong, how is any kind of work involving Photoshop even a thing in UK? – jpeltoniemi Jun 29 '17 at 07:47
@Pichan: sure, but I think you’re conflating visual disability with any kind of disability. Just because there’s a specific disability that your app can’t cater for, it doesn’t mean that you ignore all accessibility concerns, or stop using meaningful HTML. – Paul D. Waite Jun 29 '17 at 09:23
@PaulD.Waite I don't intend to ignore all accessibility concerns. I just don't go out of my way to find potential accessibility issues before they actually are becoming issues. And I still argue a single custom tag that is more meaningful and readable than a bunch of nested divs, especially when said custom tag will be expanded into standard HTML / bunch of nested divs. – jpeltoniemi Jun 29 '17 at 15:59
@Pichan: standard HTML is meaningful, because we have an agreed meaning, in the HTML spec. A custom tag doesn’t have that agreed meaning, until it’s turned into a standard HTML tag. Non-meaningful HTML, when there’s a meaningful alternative, is an issue. – Paul D. Waite Jun 29 '17 at 16:33

Can you define your own self-closing tag in HTML5?

2 Answers2

Linked

Related