How Web Browsers Parse HTML
<p>One final topic I want to talk about that affects modern web development is the implementations of various web browsers. As you'll recall, once the requested web page has been returned, it will be parsed by a web browser then displayed on screen.</p>
There are four major parsing and rendering engines that are popular today.
Trident, the web browser engine from Internet Explorer, is used by many applications on the Microsoft Windows platform, such as netSmart, Outlook Express, some versions of Microsoft Outlook, and the mini-browsers in Winamp and RealPlayer.
KDE's open-source KHTML engine is used in KDE's Konqueror web browser and was the basis for WebKit, the rendering engine in Apple's Safari and Google's Chrome web browsers.
Gecko, the Mozilla project's open-source web browser engine, is used by a variety of products derived from the Mozilla code base, including the Firefox web browser, the Thunderbird e-mail client, and SeaMonkey internet suite.
Opera Software's proprietary Presto engine is licensed to a number of other software vendors, and is used in Opera's own web browser.
<p>They are *mostly* the same, in so much that a web page will look mostly the same regardless of which web browser it is loaded into. However it is the differences between them that most people discuss because it provides design challenges.</p>
What do I mean when I use the terms "parse" and "render"?
<p>The term "parse" refers to the process of breaking apart the HTML document to better "understand" the instructions coded there in. During this phase, other resources, like external CSS files or JavaScript files, or images, must be requested so that the browser can get a complete picture of the code it is responsible for ultimately rendering. After all those external resources are downloaded and analyzed, they are typically loaded into the computer's memory as a tree, or hierarchy, of software objects then passed to the rendering engine component of the browser - more about that in a moment. When I refer to these hierarchical software objects, I simply mean that some objects "own" or are parents to other objects ... a simple example might be that a paragraph is a parent to each sentence, which is a parent to each word. There might be other tags and graphical elements that the paragraph owns as well. This is simply part of the process of deciding what technique the browser will use to ultimately render the HTML to the screen.</p>
Characteristics of HTML5 Web Pages
<p>Each web page should declare which standard it has promised to adhere to. This is called a DOCTYPE, and it is the reason that we typed this:<br>
<br>
<!DOCTYPE html>
<br>
<br>
... at the very top of our web page. This instruction told any web browser that may open it that it should be evaluated as an HTML5 document, as opposed to an HTML document of another version. Every instruction should adhere to the HTML5 specification (which we'll talk about in a moment). If it doesn't, the renderer may not know how to properly apply the rules of HTML5 to the document and must drop back into something called "quirks mode" where the browser will take a best guess on how to best render the web page. "Quirks mode" exists because there are plenty of poorly coded HTML page in the world and the web browser wants to try to the best of its ability to render something to the end user. If web browsers through up their hands and complained each time a web developer wrote bad code, the World Wide Web experience would be dreadful. Since writing HTML that doesn't validate against a standard can produce inconsistent results, web developers are strongly encouraged to take great care in the code they write. In fact, most tools that allow you to write HTML pages incorporate a validator to ensure the code you write validates against your chosen HTML specification. We'll use an HTML5 validator that's available on the internet for free in just a moment.</p>
<p>Once the document has been parsed, the browser can begin the rendering process. "Render" means that the code will be translated into visual elements on screen using algorithms and rules coded into the rendering engine, the components in the web browser responsible for this activity. The rendering engine will figure out how much screen space is available, and will begin to dole out the screen real estate equitably to lay out the various parts of the page onto the computer screen. There's much more to it than that, but again I'm just trying to speak at a very high level about what happens here.</p>
<p>And here is where things start to get messy, because I said all of that to say this: each rendering engine is written by different developers each determining how to satisfy the requirements of the specification in their code. Most of the time, your valid HTML5 code will look "close enough" on most browser vendor and versions. However, that's unfortunately not always the case and so it is important to set your expectations and give you a little heads up on how to deal with the inevitable situation where you want to use some new feature that is either supported differently in different browsers or is not supported at all in older browsers.</p>
<p>Let's start with the question if there's a standard in place, why do browser vendors implement functionality differently? Often this is a matter of interpretation of the specification. The specification details how something should work and provides some scenarios. From a technical perspective, there are situations not covered explicitly by the specification and vendors need to decide how THEY will handle it. In other cases, different vendors have different timeframes on when they plan on supporting the functionality. This has to do often with non-technical issues like budgets and resources and release schedules. For example, I saw a graphic comparing the number of features added to IE10 that were not in IE9. It was staggering, and strategically IE10 has a goal of supporting the release of Windows 8.</p>
<p>If you're not aware, you can build Metro-style Windows applications using HTML5, CSS3 and JavaScript via the WinRT API. Prior versions of IE9 did not have this requirement, and so the feature set it supported was decidedly smaller in preparation for a larger budget and team assigned to IE10.</p>
<p>Couple different interpretations of the specification with the fact that parts of the specification are not even complete, like I said in the first lesson, and you have a recipe for a divergence of implementations of the standards. Again, much of the standard works correctly.</p>
<p>So, what to do when you as a web developer want to make sure that your web page is rendered correctly in as many web browsers as possible? First of all, you need to become aware of those situations where implementations vary between the rendering engines. Testing your web pages in multiple browsers and on multiple devices will help identify those in your particular web pages, but over time, as you become more familiar with HTML and CSS you'll know where the potholes are. Secondly, you can take one of two approaches ... the first approach is called "Graceful Degradation" where you build your ideal web page to design at the latest version of a target web browser, then use CSS and JavaScript, images and emulation scripts that attempt to duplicate the features supported by the latest versions of one or more web browsers. Using this first technique, you are trying to get older browsers or current versions of other browsers to do things they are not capable of using copious sections of alternate HTML, CSS and JavaScript. You spend a lot of time wrestling with the site to get it as close as possible in older or less capable browsers.</p>
<p>Alternatively, you could take the "Progressive Enhancement" approach, meaning you start out by keeping the web page you're authoring as simple and straight forward as possible making sure the site looks as good as possible in baseline browsers ... in other words, you decide on a set of older web browsers as the baseline, make sure the web page looks good in those browsers, then add in features that are supported in newer browsers to enhance the web site. In this way you ensure that users with older browsers still have a good experience, you focus on writing good, solid HTML code, and for those who are running newer browsers you are adding features that will simply enhance their experience. Over time, you re-visit the web page's code, replacing those bits those older parts with those parts that were merely enhancements. People will eventually upgrade their browsers and as they do, your baseline can creep forward. This is an ongoing migration strategy. Most developers agree in principle that this is the right approach, even if the implementation can be tricky at times. You have to decide whether some of the things I'll demonstrate here are worth the price you'll pay in alienating potential users with older web browsers that don't yet support parts of HTML5 and CSS3. You should always be testing your work in multiple web browsers across many different versions to know exactly how your web page performs. And, do as I say, not as I do, because that is a time-consuming and therefore expensive process. Real professionals take this seriously and I would recommend you do so, too. You may see me cut corners at times -- do as I say, not as I do.</p>
If you have a captive audience, the experience is a little different. For example, In Windows 8, HTML5 developers can rely on Internet Explorer 10's expanded HTML5 support to build user interfaces that run as Metro-style applications utilizing the WinRT API. In this case, you know for a fact where your HTML5 will be rendered and by whom, and you are free to use the full set of HTML5 features IE10 supports without having to worry about other browser vendors and version. Another example might be that someday you're building web-based intranet applications that will run inside of your enterprise on an Intranet. In this case, your IT department may have standardized on a specific web browser. If this is the case, you are free to use the HTML features supported by that specific vendor and version of web browser.
Conclusion
Hopefully you can see the issues surrounding HTML5 and CSS3 with regards to their support by various versions and vendors of web browsers and two different thought processes on how to incorporate HTML5 into your own work.
Copyright © 2012-2014 Bob Tabor
No comments:
Post a Comment