{"id":20964,"date":"2023-02-10T01:57:07","date_gmt":"2023-02-10T01:57:07","guid":{"rendered":"https:\/\/www.booksofall.com\/es\/?post_type=product&p=20964"},"modified":"2023-02-10T01:57:07","modified_gmt":"2023-02-10T01:57:07","slug":"dive-into-html5","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/es\/dive-into-html5\/","title":{"rendered":"Dive Into HTML5"},"content":{"rendered":"

Recently, I stumbled across a quote from a Mozilla<\/a> developer about the tension inherent in creating standards:<\/p>\n

Implementations and specifications have to do a delicate dance together. You don\u2019t want implementations to happen before the specification is finished, because people start depending on the details of implementations and that constrains the specification. However, you also don\u2019t want the specification to be finished before there are implementations and author experience with those implementations, because you need the feedback. There is unavoidable tension here, but we just have to muddle on through.<\/p>\n

Keep this quote in the back of your mind, and let me explain how HTML5 came to be.<\/p>\n

This book is about HTML5<\/a>, not previous versions of HTML, and not any version of XHTML<\/a>. But to understand the history of HTML5 and the motivations behind it, you need to understand a few technical details first. Specifically, MIME types.<\/p>\n

Every time your web browser requests a page, the web server sends \u201cheaders\u201d before it sends the actual page markup. These headers are normally invisible, although there are web development tools that will make them visible if you\u2019re interested. But the headers are important, because they tell your browser how to interpret the page markup that follows. The most important header is called Content-Type, and it looks like this:<\/p>\n

Content-Type: text\/html<\/p>\n

\u201ctext\/html\u201d is called the \u201ccontent type\u201d or \u201cMIME type<\/a>\u201d of the page. This header is the only thing that determines what a particular resource truly is, and therefore how it should be rendered. Images have their own MIME types (image\/jpeg for JPEG images, image\/png for PNG images, and so on). JavaScript files have their own MIME type. CSS stylesheets have their own MIME type. Everything has its own MIME type. The web runs on MIME types.<\/p>\n

Of course, reality is more complicated than that. The first generation of web servers (and I\u2019m talking web servers from 1993) didn\u2019t send the Content-Type header because it didn\u2019t exist yet. (It wasn\u2019t invented until 1994.) For compatibility reasons that date all the way back to 1993, some popular web browsers will ignore the Content-Type header under certain circumstances. (This is called \u201ccontent sniffing.\u201d) But as a general rule of thumb, everything you\u2019ve ever looked at on the web \u2014 HTML pages, images, scripts, videos, PDFs, anything with a URL \u2014 has been served to you with a specific MIME type in the Content-Type header<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"