I’ve heard the sentiment “HTML is easy” more times than I can count. And while I would agree that HTML is perhaps easier to learn than other programming languages, you shouldn’t take it for granted.
HTML is a powerful markup language which can be used to give our web applications structure and provide powerful accessibility benefits, but only when used appropriately.
Thus, today we’ll discover ten HTML elements you might not have known existed in the hopes that you can create more accessible, and structurally-sound web applications.
If you'd like to learn more about HTML, you can visit the W3Schools for more HTML elements.
Audio
The <audio> tag defines a sound, such as music or other audio streams. There are three currently supported file formats: MP3, WAV, and OGG.
Blockquote
The <blockquote> tag specifies a section that is quoted from another source.
Output
The <output> tag represents the result of a calculation. You can use the plus sign and equal symbol to indicate that the first and second input values should be “outputted” to the output tag; you can denote this with a for attribute containing the ids of the two elements to combine.
Picture
The <picture> tag allows you to specify image sources. Instead of having an image which you scale up and down depending upon the viewport width, multiple images can be designed to fill the browser viewport.
The picture tag contains two different tags: one or more <source> elements and one <image> element.
The source element has the following attributes:
-
srcset(required): Defines the URL of the image to display -
media: Accepts any valid media query that you might define within CSS -
sizes: Defines a single width value, a single media query with width value, or a comma separated list of media queries with a width value -
type: Defines the MIME type.
The browser uses the attribute values to load the most appropriate image; it uses the first <source> element with a matching hit and ignores the subsequent source elements.
The <img> tag is used to provide backwards compatibility if a browser doesn’t support the element or if none of the <source> tags match.
Progress
The <progress> tag represents the progress of a task.
The <progress> tag is not a replacement for the <meter> tag, thus components indicating disk space usage or query result relevance should use the <meter> tag.
Meter
The <meter> tag defines a scalar measurement within a defined range, or a fractional value. You can also refer to this tag by the name “gauge.”
You can use the <meter> tag to display disk usage statistics or to indicate the relevance of search results.
The <meter> tag should not be used to indicate progress of a task; these types of components should be defined by a <progress> element.
Template
The <template> tag contains content that is hidden from the user, but will be used to instantiate HTML code repeatedly.
Using JavaScript, you can render this content with the cloneNode() method.
Time
The <time> tag defines a human-readable date or time. This can be used to encode date and times in a machine-readable manner so that user agents can add birthday reminders or scheduled events to the user’s calendar. Additionally, this allows search engines to produce “smarter” search results.
Video
The <video> tag specifies a movie clip or video stream. The supported formats include MP4, WebM, and Ogg.
Word Break Opportunity
If you have a long block of text, or a long word, you can use the <wbr> tag to specify where in a body of text it would be ideal to break. This is one way to ensure the browser, upon resize, doesn’t break your text in a strange spot.
I hope these ten HTML elements gave you some new tools to build awesome applications!
Top comments (102)
Awesome Emma, thank you! I would like to add one of my favorites:
Nice. Needs a polyfill though.
True. But nice yet ;P
LOL
Great article Emma, I would just have liked to see what the html elements look like, side by side with the code. This is just my preference though !
I learnt a lot, a I must admit I didn't know most of the tags you have presented. Thanks !
I thought about adding that as well! Maybe I'll edit ;)
This would definetly add to the already high quality of the article, i found myself typing most of these into an online editor to check what they look like :D
Hehe cool I'll do that thanks :)
I added the ones I could!
So, one big thing I'd mention on this article in general is that you're using images to show the code, which isn't very accessible. It would be much better to use fenced code blocks (three backticks); for example,
The code for the above being:
True thanks!
Thanks a lot for the hint - is there an equivalent for this "trick" in HTML, please?
The three-backticks stuff is specific to Markdown, although it's usually handled by a library such as Pygments, which you can certainly use on its own as well.
YOu can also use the
<pre><code>...</code></pre>tag to preformat stuff although that won't do syntax highlighting and you'll need to convert<to<. (Technically you only need<pre>but that's a visual tag while<code>is the semantic tag to say what the text represents.)Thank you very much for your quick response.
Yes, it is the need to convert the angle brackets plus also keeping the indentation/readability intact that is kind of odd to do still "manually" in 2020. (Am sure there are online converters or we could write one ourelves, but still ... hoping for a more efficient way)
HTML is easy, but you're right, there are a ton of useful tags out there that people aren't aware of. The
<picture>tag is one I've never known about and it sounds like a very useful way to handle images in a responsive web page.And HTML does start getting complex when you start thinking in terms of semantics and accessibility.
Yes, a few people focus on semantics and accessibility. So, they say HTML is easy.
Thanks for sharing! One thing to note though is that if you have to support older browsers like Internet Explorer, some of these tags are not supported there.
Edit: Instead of avoiding these tags, you can use them as part of a progressive enhancement strategy. However that is more complicated and takes more time to test.
I think we can start forget about IE, because even Microsoft want's en it up
That would be very nice but it's still a looong way away. I just checked our numbers and IE is ~7% of our visitors. Almost all of them are IE11 which can be reasoned with somewhat. However, the numbers aren't going down at all.
Yeah, it's sad. But what if... What if just start campaign of ignoring IE?
On what grounds? The fact that developers don't like IE has almost no weight as an argument. The users with IE are not just drive-by's on the public site but they are actual paying users. In order to drop IE11 support, the percentage has to drop to a level where the cost of potentially losing them outweighs the cost of maintaining IE11 compatible code. Since we're usually not doing anything too crazy it's not a huge problem to support IE11, it's just annoying to work with when a problem occurs.
ignoring IE = ignoring users = ignoring customers = ignoring money. If you can afford it, do it, but that probably means you're running a charity.
There's a tradeoff. How much developer time does it cost to support IE, and how much revenue would you lose from not supporting it?
Or, if you are dealing with paying customers, tell them support is dropping, and tell anyone who screams and insists on the old browser that they have to pay for keeping support just for them. If they're just being ornery, they'll usually grumble and upgrade. If they are really stuck, they'll often pony up cash.
True, people who only used IE should have (at least) moved to Edge by now. There's little to no reasons as to why a user would still use IE.
I've never seen
<wbr>before, that's super helpful!Same here, thanks for that !
The
≤of theoutputtag blew my mind.I still lament the deprecation of the
<blink>tag.EDIT: Ah, that's because the opening element isn't
≤; it's=<, which is rendered in some typefaces with the single glyph.I noticed that too but I'm guessing it's a font like Fira Code that has ligatures in it.
Great stuff Emma. Would love to see browser support information. I know it's time-consuming to look up. I'm going to head off to MDN to look for myself, but I think the info would add something valuable to an already valuable article.
You should check out CanIUse!
I don't have enough ♥'s. And some kind person wrote a cli client for it too: github.com/sgentle/caniuse-cmd
I also see that
blockquotecan haveciteas a child element -- and then the citation is displayed nicely for the user. I'm definitely going to use that sometime. Thanks again for the awesome article (:You can also write scss code and compile it to css with vendor prefixes added automatically for the browsers you tell the compiler to support, based on caniuse.com data. A lot of the new HTML5 elements can be supported with js polyfills and normalizer css too.
I would avoid using the
pictureelement in 2019. It's mostly a remanent from the first responsive images implementation.imgnow also has access to easiersrcsetandsizesattributes and has a smaller footprint. See ericportis.com/posts/2014/srcset-s... , especially part 2.Yeah, came here to say the same thing –
img srcsetis supported everywhere, already gives you correct fallback "for free" (since you still declare asrcattribute for that purpose), and provides all of the CSS query selector stuff in a much more compact, easily-parsed and easily-generated format. For example, the article's code would be captured as<img src="img_kitten.jpg" alt="Kitten" srcset="img_cat_fat.jpg 650w, img_cat_fluffy.jpg 465w">Awesome post!
Just remember to check against caniuse.com
Some comments may only be visible to logged-in visitors. Sign in to view all comments.