For a language so simple and easy to learn, HTML surely offers an unexpected amount of useful features, many of which most of us don’t even know about. It’s hard to keep up with times and you may think that all “you might not know” articles must be about the most recent tags, HTML also has some quite helpful features that are already around for a while.
From checking spelling to adding keyboard shortcuts, in this article, I’ll show you five less-widely known HTML features.
spellcheck attribute prompts browsers to check spellings while a user is typing an element. This attribute is global, meaning, you can add it to any HTML tag.
However, it only works on elements that can take text input. Having it global is useful because it can be inherited by child elements. For instance, add it to a
<div> tag and all of its child elements that take text input will inherit this attribute.
Spell checking works on all text
<textarea>, and editable elements (elements with
Its value can be an empty string,
false. The empty string and
true will enable the spell checker.
<input type="text" spellcheck="true" placeholder="Type something here"> <p contenteditable="true" spellcheck="true"> Type something here </p>
In the above code, both the
<p> tags will check spellings when a user is typing into them.
If the user has disabled spell checking in the browser settings the spelling won’t be checked, even if
spellcheck was added.
It is pretty common to host resources, such as scripts and stylesheet files, through CDNs. But, if the CDN gets compromised, so do those hosted files, and if any fetched resource is compromised on your website, so does your site!
See what Mozilla Developer Network says about the problem:
… using CDNs also comes with a risk, in that if an attacker gains control of a CDN, the attacker can inject arbitrary malicious content into files on the CDN (or replace the files completely) and thus can also potentially attack all sites that fetch files from that CDN.
To prevent this, Subresource Integrity (SRI) was introduced in early 2014 by W3C. This scheme compares the hash value (the result of applying a hash function to an input) of a resource to validate it.
https://example.com/example.js. First, you apply a hash function to that file, then add the produced hash value to the
integrity attribute of the
<script> tag that imports
example.js to your website.
<script src="https://example.com/example.js" integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7" crossorigin="anonymous"></script>
Now, whenever a web page of your site with the above code has to load
example.js, the browser first applies the hash function, and loads and runs
example.js only when its hash value matches the
example.com was compromised and
example.js was interfered with then the hash value of
example.js won’t match the
Most common CDNs already provide SRI
integrity values, but you can also generate one here.
You’re most likely familiar with the
target attribute, the one that decides where a hyperlinked resource opens, for instance on the same page or in a new tab. You might also know that the same
target attribute used in the
<form> tag decides where the response from the form submission is shown.
In one of the early drafts of HTML5,
formtarget was defined along with four other form submission attributes:
These attributes can be used with submit buttons, and they override their respective attributes in the
<form> tag to which the buttons belong to.
So, when a form is submitted using a button that has a
formtarget attribute, the response is shown according to the
formtarget value, instead of the
target value of
<form action="/save" target="_self" > <input type="submit" name="save" /> <input type="submit" name="print" formaction="/print" formtarget="_blank" /> </form>
In the above code, when the form is submitted using the second submit button (
When it comes to hiding elements, we all went through different phases of hiding elements: using
text-indent:-999px in our CSS file.
Each method has its purpose, none of them are redundant, and so isn’t this one: the
hidden HTML attribute. If an element has
hidden specified on it, it’ll be hidden.
It works the same way as the
display:none; CSS rule; the element with the
hidden attribute doesn’t get rendered on the page. Any script inside the element will be executed, and if it’s a form control it’ll be submitted along with other form controls during form submission.
However, the benefit of
hidden is that it’s semantically appropriate, after all, HTML5 is all about semantics and
hidden is part of the HTML5 entourage!
Moreover, when an element is hidden, it’s to be hidden in all platforms, not just in web browsers but in screenreaders, TV, projectors, etc.
It’s also not style-dependent, even if you strip away the author CSS from a page, the element will remain hidden. Whereas in the case of
display:none; that won’t happen. So, think of
hidden as the ironclad version of
accesskey global attribute was already defined in HTML4 and it creates a keyboard shortcut with which the user can operate an element on the page.
The key combination for a shortcut will depend on two things:
accesskeyvalue that we give to an element
Take this example:
<button accesskey="v" onclick="alert('View Click')"> View </button>
In Firefox, if you press the key combination Alt + Shift + V (or Alt + Control + V in macOS) you’ll get the alert “View Clicked”.
Since the predefined browser keys varies with each browser and OS, it is recommended you let the users know of the key combinations used for the shortcuts.
Read Also: 10 Cool Things HTML Tags Can Do