The point of this has always been to show the point of and promote such semantic HTML and web standards by showing how they serve to organize a site’s content before it is visually organized. This is an important reminder to those of us concerned with accessibility, search engine optimization, and the standards we’re promoting.

Obviously, this isn’t happening on any client sites, but it’s appropriate to put on one’s blog.

<?php if ($req) echo "aria-required='true'"; ?>

There is very little mention of this code as part of WordPress (because it is just the default theme, and most people do not use it), though there are a few questions of people who are concerned with why it doesn’t validate. Sometimes, people are encouraged to simply remove it. From one forum post, though:

From what I have read, aria-required is a handicap-man accessibility feature that allows folks with disabilities to know that certain fields are required by way of a screen readers voice alert saying, “hey moron, this is a required field”. Lots of browsers, well I should say some, do support it and some don’t…

So, for now the html W3 consortium is not going to accept aria-required until MS decides to play ball

Moron talk toward users aside, this is fantastic information for anyone who might run into the fact that their WordPress code no longer validates if they use a theme that adds this.

Occasionally, when I write I run posts through the validator to ensure that I haven’t forgotten or added something, and it was in one of these validations that I noticed the attribute. I’m keeping it in this new theme, even though it doesn’t validate, as accessibility is a desperately important and neglected part of high quality code.

Let this be a lesson, or a reminder, that valid code is not enough, nor is it always best: it can easily be inaccessible and non-semantic, and still be valid.

In the W3C’s specs, z-index is designed to affect the stacking order of positioned elements on a web page. So, an element with a z-index of 2 should always appear above an element with a z-index of 1.

In Internet Explorer, this doesn’t work like it should. Internet Explorer resets the stack when the positioned elements are separated from each other.

Example

So let’s say we have the following HTML. Fairly standard header, navigation, etc.

1. <div id="wrapper">
2. <div id="header">
3. <ul id="nav">
4. <li><a href="#">home</a></li>
5. <li><a href="#">item one</a>
6. <ul>
7. <li><a href="#">sub item one</a></li>
8. <li><a href="#">sub item two</a></li>
9. </ul>
10. </li>
11. <li><a href="#">item two</a>
12. <ul>
13. <li><a href="#">sub item one</a></li>
14. <li><a href="#">sub item two</a></li>
15. </ul>
16. </li>
17. </ul>
18. </div>
19. <div id="container">
20. <h1>Hi. This is a positioned H1</h1>
21. <p>This page is just some friendly content to show you just how bad IE really is.</p>
22. </div>
23. </div>

Then, we have the following CSS.

1. #wrapper #header {
2. position: relative;
3. }
4. #wrapper #nav {
5. clear: both;
6. margin: 0 5px;
7. padding: 0 5px;
8. width: 750px;
9. height: 30px;
10. list-style: none;
11. border-top: 1px solid #335a86;
12. border-bottom: 1px solid #335a86;
13. text-align: center;
14. position: relative;
15. z-index: 2;
16. }
17. #wrapper #nav li {
18. float: left;
19. margin: 0;
20. padding: 0 0 5px 0;
21. border: 0;
22. position: relative;
23. }
24. #wrapper #nav li a {
25. margin: 0;
26. padding: 7px 15px;
27. display: block;
28. text-decoration: none;
29. font-size: 1.2em;
30. }
31. #wrapper #nav a:link, #wrapper #nav a:visited {
32. color: #888;
33. }
34. #wrapper #nav a:hover, #wrapper #nav a:focus {
35. color: #335a86;
36. }
37. #wrapper #nav li ul {
38. background-color: #ccc;
39. width: 150px;
40. height: auto;
41. list-style: none;
42. margin: 0;
43. padding: 5px 0 10px 0;
44. border: 0;
45. text-align: left;
46. position: absolute;
47. display: none;
48. }
49. #wrapper #nav li ul li {
50. float: none;
51. margin: 0;
52. line-height: 30px;
53. height: 30px;
54. }
55. #wrapper #nav li ul a {
56. padding: 7px 10px;
57. white-space: nowrap;
58. display: block;
59. }
60. #wrapper #nav li:hover ul {
61. display: block;
62. }
63. #wrapper #container {
64. padding: 10px;
65. position: relative;
66. }
67. #wrapper h1 {
68. position: absolute;
69. left: 10px;
70. top: 10px;
71. height: 60px;
72. line-height: 60px;
73. vertical-align: middle;
74. font-size: 2em;
75. background: #335a86;
76. color: #fff;
77. }
78. #wrapper #container p {
79. margin-top: 60px;
80. }

This is very common code used to trigger a CSS dropdown menu in all modern browsers. Remember that IE6, of course, requires a small JavaScript. A good example is the Sons of Suckerfish. I do not have this JavaScript on my current example, since there are plenty of other great articles about that.

IE7 Example – click to enlarge

When the code below the navigation, in this case the absolutely positioned h1, is any positioned element (or a select element, Flash movie, etc.), all versions of Internet Explorer prior to version 8 will cause the dropdown menus to fall behind the content.

The Fix

The fix for this is very simple, but there are incredibly large websites that use jumbled masses of iframes, extra divs, and other horrors to get Internet Explorer to display the dropdowns above the offending elements.

For a fix, we use the following CSS for the header div. See the screenshot for an example of this (again, in IE7). Click it to see a larger version.

1. #wrapper #header {
2. position: relative;
3. z-index: 2;
4. }

Now, you will also need to make sure that your container div, whatever it is called, is styled correctly. In my example:

1. #wrapper #container {
2. position: relative;
3. }

This ensures that the header and the container, whatever you call them, understand their relationship to each other for the z-index fix to work.

IE7 Example – click to enlarge

This fix causes the dropdowns to appear above everything that is inside the content areas of the page. It works in IE7 and IE6. My example adds some code to show the <select> statement, which is another common offender.

Standards as a whole

Microsoft, especially in the last year or two, has made a lot of moves toward standards, web and otherwise. They announced the Interoperability Principles. They announced the ASP.NET MVC Framework, which finally allows programmers to control the HTML generated by ASP.NET. IE8 will pass Acid2, and any number of other things.

While I’m not optimistic that any of this will cause Microsoft to act in any unexpected ways with respect to its attempts to acquire Yahoo, it is clear that a shift is occurring, to whatever extent.

Noise from the web standards community

Advocates of web standards have made a lot of noise about the original decision, and it is clear that Microsoft listened. Many people made logical arguments for why IE8, especially from a long-term perspective, should not default to IE7 behavior, while understanding that the option for IE7 behavior was a good thing.

Legal issues

It’s entirely possible that this is partly related to Microsoft’s various legal troubles, and that they are trying to appear as a better business citizen to help their case.

Future versions of IE

I think one of the most significant benefits, both from the perspective of future versions of IE, as well as future versions of Firefox, Opera, Safari, etc., is that the need for version targeting will probably become much less because IE8 is the default behavior. People who create sites that break in IE8 will, certainly, have the option of targeting IE7, but in order to do that they’ll have to learn that they can.

Most people who will run into the issue will probably not have the interest (or the time, possibly) to find out this kind of solution. The ones who do find out about the solution will find out that Microsoft doesn’t see it as the ideal solution, and will probably feel at least some pressure to learn proper ways of doing things. Thus, in a few years, it is entirely possible that versions of Internet Explorer that follow version 8 will be met with a majority of sites that do not break.

That’s not to say that the majority of sites will follow web standards. I’ve seen innumerable websites that didn’t break when IE7 came out, because they had such disregard for web standards that none of the changes affected them. I suspect we’ll have to deal with this for a long time. But that’s fine with me, as the future of web browsers can continue to look forward.

IE8 has been significantly enhanced, and was designed with great support for current Internet standards. This is evidenced by the fact that even in its first beta, IE8 correctly renders the popular test known as 'Acid2,' which was created by the Web community to promote real-world interoperability,” said Ray Ozzie, Microsoft chief software architect. “Our initial plan had been to use IE7-compatible behavior as the default setting for IE8, to minimize potential impact on the world's existing Web sites. We have now decided to make our most current standards-based mode the default in IE8.

The web standards world has been abuzz for the last few weeks, following the announcement that Internet Explorer 8 (and, presumably, any number of future releases) would have the default behavior of rendering websites in the same way that Internet Explorer 7 does. Causing the browser’s behavior to advance would have required that designers and developers direct it to do so with a meta tag.

Many standards-aware designers and developers were very understanding of the decision to allow websites to target IE7, avoiding issues with badly-programmed websites that break when browsers move forward. However, many of these designers and developers made a lot of noise wishing that Microsoft would allow the default behavior of websites to advance as the browser does, and require those who want to target IE7 to read a little bit and find out about the meta tag.

Apparently, Microsoft listened to the noise. I’m amazed and pleased by this change in strategy. I hope they will be able to spread the word enough, so that websites that will break with IE8′s improved standards support will learn about their options (1. learn how to write standards-compliant code, 2. include a one-line meta tag). I feel pretty confident that this is unrealistic, but I hope that it will happen to the extent that Microsoft doesn’t have to go back on this decision.

…I'm delighted to tell you that on Wednesday, December 12, Internet Explorer correctly rendered the Acid2 page in IE8 standards mode. While supporting the features tested in Acid2 is important for many reasons, it is just one of several milestones for the interoperability, standards compliance, and backwards compatibility that we're committed to for this release. We will blog more on these topics.

Wonderful news. Web designers and developers everywhere agree with me that IE6 is the bane of our existence. There’s no need to discuss this further. IE7 is a massive improvement, and in general I’m pleased with the direction that the team seems to be taking for the future.

Acid2 compliance is, for me, an unexpected leap forward. Currently, Opera and Safari are the most widely used browsers that have achieved this milestone. Firefox 2.x does not reach this level, although Firefox 3 (which is in beta and, I’m sure, will be released well before IE 8 is) does.

I find this exciting. I have not been a fan of ASP.NET, due to the horrible HTML that it generates, and my lack of knowledge about how to separate the various parts of an application to have more control over the HTML. Evidently, this new system will give me that kind of control. I’m totally impressed by that.

As annoying as some of Microsoft’s projects can be with regard to standards and such things, I don’t envy the variety of developers that they have to try to please. They have to try to please the hardcore programmers that don’t care about the front end at all, and they have to try to please the designers who are really picky about the front end. Hopefully, this will help.