HTML

Learn web development on the Mozilla Developer Network

Welcome to the MDN Learning Area. This set of articles aims to provide complete beginners to web development with all they need to start coding simple websites.

The aim of this area of MDN is not to take you from “beginner” to “expert” but to take you from “beginner” to “comfortable”. From there you should be able to start making your own way, learning from the rest of MDN and other intermediate to advanced resources that assume a lot of previous knowledge.

If you are a complete beginner, web development can be challenging — we will hold your hand and provide enough detail for you to feel comfortable and learn the topics properly. You should feel at home whether you are a student learning web development (on your own or as part of a class), a teacher looking for class materials, a hobbyist, or someone who just wants to understand more about how web technologies work.

You can't parse [X]HTML with regex

If you enjoy Lovecraftian horror mixed hilariously with nerdy advice, this might be your thing:

You can’t parse [X]HTML with regex. Because HTML can’t be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions. Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes. HTML-plus-regexp will liquify the nerves of the sentient whilst you observe, your psyche withering in the onslaught of horror. Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow it is too late it is too late we cannot be saved the trangession of a chi͡ld ensures regex will consume all living tissue (except for HTML which it cannot, as previously prophesied) dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of regex parsers for HTML will instantly transport a programmer’s consciousness into a world of ceaseless screaming, he comes, the pestilent slithy regex-infection will devour your HTML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fight he com̡e̶s, ̕h̵is un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo͟ur eye͢s̸ ̛l̕ik͏e liquid pain, the song of re̸gular expression parsing will extinguish the voices of mortal man from the sphere I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful the final snuffing of the lies of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL IS LOST the pon̷y he comes he c̶̮omes he comes the ichor permeates all MY FACE MY FACE ᵒh god no NO NOO̼OO NΘ stop the an*̶͑̾̾̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ

Have you tried using an XML parser instead?

WebSlides: Create Beautiful HTML Presentations

WebSlides makes HTML presentations easy.
Just the essentials and using lovely CSS.

[…]

Each parent <section> in the #webslides element is an individual slide.

Code is clean and scalable. It uses intuitive markup with popular naming conventions. There’s no need to overuse classes or nesting. Making an HTML presentation has never been so rewarding.

Image

Hiding DOM elements - ally.js

This document explains the various ways of hiding things and the implications that come with that.

When we say an element is hidden, we usually mean it is not visible. However, the screen is not the only output mechanism we may need to hide content from. Systems like screen readers and braille displays rely on a document’s representation in the accessibility tree. For disambiguation we’ll use the following terms:

Completely hidden
The element is not rendered on screen, not exposed in the accessibility tree, not accessible to keyboard navigation.
Semantically hidden
The element is rendered on screen, but not exposed in the accessibility tree, and still accessible to keyboard navigation.
Visually hidden
The element is not rendered on screen, but exposed in the accessibility tree, and still accessible to keyboard navigation.

[…]

How to hide elements completely

Completely hiding elements can be done in 3 ways:

  • via the CSS property display, e.g. display: none;
  • via the CSS property visibility, e.g. visibility: hidden;
  • via the HTML5 attribute hidden, e.g. <span hidden>

While each of these techniques has the same end result, i.e. content is not rendered and not exposed in the accessibility tree, they have different behaviors.

[…]

How to hide elements semantically

To hide content from the accessibility tree but retain the content on screen, we may use the attribute aria-hidden="true".

[…]

2016 edition of .visuallyhidden

[…]

Code language: CSS

.visuallyhidden:not(:focus):not(:active) {
  position: absolute;
 
  width: 1px;
  height: 1px;
  margin: -1px;
  border: 0;
  padding: 0;
 
  clip-path: inset(100%);
  clip: rect(0 0 0 0);
  overflow: hidden;
}
  • It works in all modern browsers including Internet Explorer 9 - 11.
  • It side-steps the need to re-style everything for focusable elements such as skip-links.
  • It accounts for the deprecated clip property.

Keyboard navigation

The techniques to hide elements only visually or semantically come with a caveat. Focusable elements like <a href="…"> remain keyboard navigatable, even though the element is not visible on screen or not exposed in the accessibility tree.

To make sure sighted keyboard users do not end up focusing elements they can’t see, and screen reader users not focusing element’s that don’t exist for them, we need to make sure that partially hidden content is not accessible to keyboard navigation using the Tab and Shift Tab keys. To accomplish this, we can add tabindex="-1" to the elements we want to hide from the keyboard.

Recap

  • Use the hidden attribute to completely hide an element.
  • Use the aria-hidden attribute to hide an element from the accessibility tree.
  • Use the .visuallyhidden class to hide an element from the screen.
  • Use visibility: inherit; instead of visibility: visible; to avoid accidentally showing content.
  • Do not attach any CSS styles to the aria-hidden attribute.
  • Take care of keyboard focusable content that is partially hidden by adding tabindex="-1".