Chapter 4. HTML
One of the first challenges you’ll face as a frontend architect will be to tackle the markup you want your developers to be writing and your CMS to be producing. The Web doesn’t exist without HTML. Strip away your CSS and JavaScript and you will be left with raw content and controls.
Text, images, links, forms, and submit buttons: this is all the Web really needs, and it is the foundation of anything you’ll ever create on the Web. Start off with bad markup, and you’ll be writing bad CSS and bad JavaScript to make up for it. Start with great markup, and you’ll be able to write more scalable and maintainable CSS and JavaScript.
Markup of the Web’s Past
It wasn’t that many years ago that our approach to HTML markup was something quite similar to laying out a page in a brochure, magazine, or newspaper. It isn’t much of a surprise, though, as many of us came from a print background, or were working with designers or product owners with a print background. Before responsive design became the standard (and even some time after), most web properties were treated like a multipage print project. When the work was divvied up, you’d be assigned a page and you would start at the top and work your way down the DOM.
In the past, our markup typically fell into one of two camps: procedural or static. Let’s take a look.
Procedural Markup: 100% Automation, 0% Control
In the world of web publishing, it was pretty common for the frontend team to have little to no control over the ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access