Monumental week for the Web

Published on 26 Jan 2008 at 12:47 am.
Filed under Web stuff.

I cannot think of a week for the Web in all of the years that I have been a Web developer. Let’s go over the highlights.

  1. Ten years of Mozilla — I know that this is relatively minor, but it is worth pointing out that it has been 10 years since the birth of Mozilla from the Netscape Communicator 5 code branch. We have seen a rendering engine birthed by the dominant browser of the day flounder into near obscurity and then rise up as a Phoenix into the mighty Firefox Web browser. A browser that took away enough market share from Internet Explorer that Microsoft resurrected the development team after it had been discontinued. Thanks to a plethora of development tools, Firefox is the browser of choice in the Web development field.

  2. W3C publishes the first working draft of HTML5 — HTML 5 is the next step in the evolution of HTML. With the inclusion of a new DOCTYPE we will see a large number of new elements that finally standardize a number of very common page elements, such as navigation, headers, footers, and sections. More useful are an increase in the number of form input types to automatically validate input natively (like email and links), as well as define behavior like Google Suggests. Additionally, it provides a standard for embedding plugins onto a Web page, and even comes with audio and video elements which allow Web developers the ability to create controls through JavaScript, just like they can in Flash. This allows designers to create buttons that fit the style of a Web page with ease, and gives developers to do things like automatically pause or reduce the quality of a video if a user scrolls down the page so that the video is no longer even on the screen. There a great number of other cool things that are being created in HTML5. Sadly it will take a great number of years for the major browser makers to implement them all. 🙁

  3. the * hack is dead, long live the * hack — Using * html was a fairly well known CSS hack that caused a rule to be set in versions of Internet Explorer 6 and below, but did not work in Internet Explorer 7 or any other A grade browser. During a discussion Eric Meyer’s update of his Browser History Timeline he revealed that a new form of the * hack lives on in Internet Explorer 7 through the use of the adjacency selector (because IE7 sees the DOCTYPE as being adjacent to the html element). While CSS hacks are very bad in theory, they are very useful in practice.

  4. New Elements were found to exist in Internet Explorer 7 — it appears that through the use of VERY simple JavaScript, Internet Explorer 7 will follow allow Web Designers to create style rules for elements that it does not know exist, such as the HTML4 abbr element. Every other Web browser already lets you set styles rules for elements, even if the browser does not know about that element, so this revelation now moves IE7 more in line with the behavior of other browsers. Also, while it may not provide the behavior proposed in HTML5, it will allow Web designers the opportunity to design sites today that are forward compatible with Web browsers of tomorrow that do render HTML5.

  5. Let me start off by saying I hate WordPress and really wish that accidentally hitting a link and then hitting back did not cause me to lose everything I had just wrote on this next point….

    Microsoft’s announcement of Super Standards Mode in IE8 — under the premise of “Don’t Break The Web”, Microsoft has brought forth a proposal for a new way of determining the rendering mode that a browser should display a page with. In the past, if a DOCTYPE was missing all browsers would render the page in Quirks Mode, which is basically the same across all major browsers. Developing new pages in Quirks Mode is very difficult because there are a lot of undocumented bugs that causes weird rendering. The presence of Quirks Mode today stems from a need to keep pages written in the past still working today, and giving todays developers another mode to render in that does a better job at behaving sensibly during Standards Mode (through use of the (X)HTML Strict DOCTYPE) or Almost Standards Mode (using the Frameset or Transitional DOCYPEs) — a mode that is like Standards, but shrinkwraps table cells whose only element is a single image to the width/height of the image, leaving no padding. Unfortunately, Microsoft is in a unique position where they have had the quirkiest Standards Mode of any browser out there, and the largest user base. When they rolled out IE7 with hopes of catching up with all of the other browsers that had greatly past them up in terms of accurate rendering, they were met by a large number of (IMHO amateurish) organizations that claimed Microsoft “broke” their Web site. This claim has seen by many as to be disingenuous because it is not Microsoft’s responsibility that a Web page render the same in Standards Mode across each new version. This is not an action taken by any other Web browser, nor should it be. The only fair thing to do is to give the community the opportunity to beta test the browser before launching it so that necessary changes can be made before it is released to the masses, which was done with IE7.

    Because of this fear, Microsoft feels the need to introduce a stricter mechanism for determining the rendering engine. The proposed opt-in mechanism is to require either an HTTP header or a meta tag that contains a certain value stating what the page should render as. Because they do not want to re-release the furor that they received from organizations after they released IE7 with the release of IE8, they are proposing that the absence of this opt-in will result in pages (assuming they have a DOCTYPE) to render using the IE7 engine instead of the most recent engine available. This opt-in mechanism need not be specific to Internet Explorer, but so far the consensus from the other major browsers is that they do not feel that they need to implement this type of switch because the DOCTYPE switch works for them just fine.

    The Web Standards community has been fiercely divided upon whether or not this is a good approach. The detractors of the opt-in approach are angered that they feel that they are being punished for writing standards compliant code and need to muck around with their page structure (or reconfigure their servers) to use the best possible rendering engine that a user has available. They feel annoyed that Microsoft is coddling the, in their opinion, lazy and/or amateurish organizations by allowing them to never need to progress there sites beyond that capabilities of IE7. The supporters of the opt-in approach feel that this is the best compromise that they feel Microsoft can allow. Many argue that, through the use of Conditional Comments or CSS hacks, we are already mucking with our page layout for Internet Explorer and this proposal is merely a method of standardizing what we are doing. Seeing as how well educated, industry leaders cannot come up with any non-trivial page layout without the need for at least some form of convoluted markup or other hack-ish behavior to work flawlessly across browsers [I had this linked before I lost my content and cannot re-find the quote, but it was by Eric Meyer] I believe this is a strong argument.

    What wasn’t discussed in the initial announcement about the new mode was that there is a third mechanism for triggering the new rendering mode in IE8. Just one day after the publication of the A List Apart article Microsoft’s Chris Wilson announced that the HTML5 DOCTYPE will trigger Super Standards Mode in IE8. Given that this DOCTYPE was designed as to cause all present browsers to continue rendering sites using the best possible rendering mode when presented in browsers that do not yet support the new elements in HTML5, it feels to me that the HTML5 DOCTYPE is the optimal compromise for the Web Standards community. It falls in line with how mode switching has always occurred. It shows that the page was clearly developed for use in modern browsers by standards aware developers/designers that know that they will have to support older browsers that do not fully support HTML5 yet, and thus the designer/developer really does want the best possible rendering their client can handle without mucking up changes for a single browser, but rather for every browser.

Comments are closed.