Summary
XHTML 2 could have the solution to ensure that headings are delivered in the correct order, and not used for their presentational effects.
Author: Gez Lemon
Checkpoint 3.5 of WCAG 1.0 requires that header elements be used to convey the structure of the document. The correct use of headings helps your visitors quickly determine the structure of the document by providing a clue to the importance of a section. Assistive devices like JAWS and Home Page Reader (HPR), allow visitors to navigate a document by the headings.
The working group for XHTML 2 are still undecided about dropping the h1 - h6 elements in favour of using an h element, used in combination with a section. Personally, I think it's a really good idea to drop h1 - h6, as the level of heading should get its meaning from its section. It will eliminate the problem of skipping headings (h1, h4, h1, etc), from developers who use headings purely for the font-size effect, and ensure the structure of the document is correct.
<h>Top Level Heading</h>
<section>
<h>Second-level heading</h>
<p>... bla ...</p>
<h>Another second-level heading</h>
<p>... bla ...</p>
</section>
<section>
<h>Second-level heading</h>
<p>... bla ...</p>
<section>
<h>Third-level heading</h>
<p>... bla ...</p>
</section>
</section>This is even more beneficial with dynamic content where a particular section could appear in one or more pages, and the heading level can't be determined at design-time. Obviously, it's a simple enough task to generate heading levels dynamically, but how many developers bother? Having the heading take its level from its section makes a lot of sense.
Category: Markup.
[nested-headings.php#comment1]
One thing bugs me about the example. The top-level heading should be in section element, too, right? I suppose that h could be a child of either body or section, but it strikes me as a little bit inconsistent. Am I alone on this? Love that headings are finally nested, though.
Posted by James Craig on
[nested-headings.php#comment2]
Backwards compatibility will be an issue here. Screen readers have finally caught up with the <hn> code - JAWS for example announces the heading level before reading the heading text. Keeping track of section nesting will be a whole new thing for Assistive Technology developers to incorporate, so again we will have a lag in usability for the folk who often benefit most.
Also, it seems that training and convincing developers and/or content managers to code for sections is going to be as difficult as getting them to code different heading levels.
Posted by Andrew Arch on
[nested-headings.php#comment3]
I can see James' point, but I'm undecided. In some ways it does make sense that headings not in a section are considered top-level headings, and also saves having to have a redundant container section.
It will be a long time before XHTML 2 is widely used, but essentially you're right. There should be enough time between now and when it goes mainstream for assistive technology developers to encorporate these features. Utlimately, pages that are sectioned correctly will make it much clearer for people using assistive devices to get the structure of the document.
Posted by Dave Ryan on
[nested-headings.php#comment4]
But what about all those people that will take a LONG time to update their browsers (let alone those that will use Microsoft Internet Explorer that is unlikely to update anything any time soon)? Their browsers will not be XHTML 2.0 aware, and <h> tags would just get ignored? Perhaps the h1...h6 tags need to remain for backward compatibility. Come to think of it, I guess that will just be an extra DTD/XHTML 2 module that you can add? But that still doesn't address older browsers and the millions of pages that likely will not change much.
Posted by Bob on
[nested-headings.php#comment5]
Bob,
The argument you've put forward is why the working group for XHTML 2 are undecided about dropping support for hn. XHTML 2 will be an uncomfortable balancing act between moving forward and maintaining support for old browsers.
Posted by Alex on
[nested-headings.php#comment6]
Madness. I thought one of the idea of introducing XML into markup was to *reduce* tag soup? Why have extra tags when what we have now works just fine? Seems to me a bit less autocratic enforcing of 'patches' and a bit more education about what already works if implemented properly would be more sensible.
Posted by Kev on
[nested-headings.php#comment7]
The longer I think about it, the more I agree with Kev (# 6) and Bob (# 4).
Billions of existing pages will not be changed. So browsers and screen readers will have to cope with both H1...H6 and H within SECTION. Experience shows that additional complexity leads to bugs, and bug-ridden user agents hang around for a long time.
Users of screen readers will still need to have the level number read out to them, because humans are not good at keeping track of nesting levels - I assume SECTIONs can be nested ?! So screen readers would have to count nesting levels - more complexity and opportunities for bugs.
If it ain't broke, don't fix it. The standards bodies are anything but infallible:
* W3C DOM 1 makes a pig's ear of defining mouse position in event handlers. This has led to incompatibilities between compliant browsers!
* Arguably CSS 1 should have had both box models.
* Strict HTML and XHTML don't allow a TARGET attribute for links and forms. I know we debated the usability of targetted links a while ago, but I think it was arrogant of the standards bodies to assume they could anticipate every possible situation and deny developers the opportunity to make up their own minds in each case.
Posted by Philip Chalmers on
[nested-headings.php#comment8]
Hi Kev,
XML hasn't been introduced into markup; XML is a markup language where each element is supposed to have semantics to provide meaning for the content. The reformulation of HTML into an XML application was to ensure that all content is given meaning by ensuring it's marked up in appropriate elements.
What we have now doesn't work well. It's relatively easy to find existing documents that do not nest headings correctly. I agree with you that it's mostly a case of educating content developers that headings should be nested correctly, but there are also exceptions where the same content is used in a different scenario and the headings are no longer nested correctly. In this scenario, it relies on the content developer adding programming constructs to ensure that the heading is given an appropriate level. A very simple task, but one that's rarely executed by content developers.
The section element provides the semantics for the heading, so that developers will no longer need to concern themselves about the level of heading. I fail to see how that's a bad thing.
Madness to me is mixing presentation with content, having two tags to include a flash movie in a document, and many other weird markup conventions that developers accepted without question.
Posted by Gez on
[nested-headings.php#comment9]
Hi Philip,
And if it is broken? Personally, I don't think there's any doubt that the current means of specifying headings for an HMTL document is broken. It's unstructured, messy, and prone to abuse.
Resistance to change is natural, and rife in computing. I started my computing career as a Fortran programmer. I was only programming in Fortran for 6 months when the company decided they wanted to rewrite their applications (Computer Aided Design packages) in C. The reason the company gave was that it was a more elegant programming language, and would reduce the size of the resulting executable. The Fortran version of the programs worked fine, so 4 members of the development team left in disgust at such an irrational decision. If it isn't broke, don't fix it.
Four years later, C++ came along. As well as subtle syntax changes, there was a paradigm shift in how developers tackled programming tasks. C++ took an object-oriented approach to programming, promoting reuse and faster development times. Consequently, a lot of C programmers decided the benefits of C++ over C weren't worth the effort so never bothered learning it. If it isn't broke, don't fix it.
There are three possible outcomes for C programmers faced with C++; embrace the new paradigm and learn C++, carry on writing traditional C in a C++ project, or ignore C++ and carry on working with traditional C. A parallel can be drawn between the developers who decided to carry on writing traditional C in a C++ project with developers who write classic HTML in an XHTML document using a transitional DOCTYPE to hide the flaws.
HTML is a defined standard, will be around for ever as HTML 4.01, and no one frowns upon its use. There will always be browsers that are able to display HTML content, but that's no excuse to call a halt to advancements in other markup languages.
Posted by Gez on
[nested-headings.php#comment10]
Thanks for those responding to my point about the billions of pages. One clarification: I am not sure I think it is a bad thing to have the section and h tags. In fact, maybe that is quiteuseful for those documents that might beyond 6 levels of headings, for example!
Also, as has been pointed out, as documents might get edited, or used in other documents, the the correct nesting is maintained without changing this.
In all, the idea is good. But my concern is about _deprecating_ the h1-h6 tags... What when Mozilla/Opera/Safari etc supports it and has hopefully at least 50% market share (!) but Internet Explorer figures it doesn't need to support this... What are web developers to do?
I would have thought XHTML 2 has to be backward compatible. One major argument (amongst many others) about supporting standards is the longevity of pages. That is, as standards evolve, you are more likely to have your page be visible by newer browsers. Standards are more likely to stand the test of time than proprietary implementations. To me it suggests that at least in this case we have to live with the old tags and not deprecate them? Perhaps browsers in the future can just treat them like the new h tag. Don't know what complications that might introduce.
Once Internet Explorer (or whatever it will be by then) is at version 10 or something, the whole world, including the third world typically use computers where XP is way too old like MS DOS 6, then we could start to think about getting rid of the h1 to h6 tags...
I don't have answers/alternatives really, but am interested in this question.
Posted by Bob on
[nested-headings.php#comment11]
Hi Bob,
You raise some interesting points.
A conforming user agent would render the page according to the DOCTYPE. User agent manufacturers play a part in the standards, as it's in their interest to ensure their particular product is successful. Many of the advancements of XHTML 2 ensure that the document is better able to be machine readable than the previous versions of the relatively free-format HTML. Current user agents work particularly hard to ensure that content is rendered correctly, and they'd obviously like to make it as easy to render as possible.
XHTML 2 is only a draft specification at the moment, and there's little chance it will be used anytime in the near future. By the time it is ready for public consumption, the mechanisms for its use should be in place. The benefit for developers is having machine readable content, making it easier to create different views of the underlying data suitable for a semantic web and more search engine (or any automated discovery program) friendly.
There's no reason why XHTML 2 has to be backwards compatible with XHTML 1.0. It makes sense that user-agents that support XHTML 2 when it's finally released are able to render previous versions of (X)HTML, but no reason why XHTML 2 should be restricted by previous markup specifications.
It's in the interest of user-agent manufacturers to ensure that standards compliant pages render correctly. HTML 4.01, XHTML 1.0, and XHTML 1.1 are all valid standards. Pages written to those specifications should render how the author expected them to. The longevity of non-standards compliant pages is questionable, as they're the exact pages that existing user-agent manufacturers struggle to try and support. Hopefully, lessons learnt in the past will ensure the transition of moving to new markup specifications will make the process as easy and pain-free as possible.
I doubt anyone has any definitive answers, but they are interesting questions.
Posted by Gez on
[nested-headings.php#comment12]
Yeah but I'm a simple guy. XML + HTML = XHTML to me and thats all I can cope with
But we're basically in agreement- if designers were better educated then this extra lot of tags would be unnecessary.
No arguement there
. It amazes me how little emphasis I used to put on markup back when I was primarily doing Flash work but this is my wider point re: education. I think that there genuinely is a groundswell of movement amongst designers to be more open-minded about standards and to understand why they're important but I also think that a lot of XHTML 2 is a massively retro-grade step. Maybe not by its own lights but in terms of the amount of designers who were coming 'on board' who will simply not use it and possibly begin to wonder why they used XHTML at all.
Posted by Kev on
[nested-headings.php#comment13]
Gez,
You also make some interesting points. You are right, XHTML 2 does not need to be backward compatible in that sense. User agents should support those standards, and XHTML or other HTML variations that have h1 to h6 should themselves not be deprecated! Thanks for that clarification.
Re: the longevity of pages -- yes, I meant longevity of pages that are standards compliant.
Given your point about it being in the user agents interest to support the newer standards, I hope you are right. I have been thoroughly disappointed with IE though (I even used to think it was the best browser out there at one time!), and am not as hopeful that they will support newer standards fully enough... That is where my main concern about h tags come from. You mentioned, "User agent manufacturers play a part in the standards, as it's in their interest to ensure their particular product is successful." You are right. But, I am not convinced by Microsoft's current practices that they will have a need or want to keep up. They are so dominant that they can afford not to keep up... (At least until I hope the other guys get major browser share!)
Perhaps I am being slightly hypocritical or inconsistent -- I am criticizing MS for not being fully standards compliant etc, and, while believing in the idea of web standards, I fear the impact of removing h1-h6 because of MS not being fully on board...!
Bob
Posted by Bob on
[nested-headings.php#comment14]
Bob,
I share your concerns over whether Internet Explorer will adopt XHTML 2. Microsoft has a dominant user base, but not necessarily a dominant developer base. It would be possible for developers to force Microsoft's hand on this issue, but it's an unreasonable request as developers are quite rightly more concerned with reaching as wide an audience as possible. Microsoft are currently developing XAML http://www.xaml.net that would result in documents not working in any browser other than Microsoft's. They even have the arrogance to describe XAML as a "de-facto" standard. No one knows for definite what the future of the web has in store, but all the time there's a glimmer of hope of an accessible, non-proprietary web, that's the direction I want to follow. Maybe as developers, we should be more active in making users aware that there are far better browsers than Internet Explorer?
Posted by Gez on
[nested-headings.php#comment15]
Hi Kev,
We're in agreement that education may solve the immediate problem of headings being poorly deployed on some existing documents, but I think that the benefits of not having to concern myself with the level of headings is an even better option. If content is used in static pages, then determining the level of a heading is simply a case of the content developer specifying the appropriate heading level. If the same content can be used on several pages, the developer will need to change the heading level depending on the document that includes the content. If you give permission to someone else to scrape your content, they'll need to change the heading level to suit their pages. It's a very simple task, but the section and h elements completely eliminate these issues. As for the extra lot of tags, we're talking about replacing 6 tags with 2.
Rather than debate this here, I'll start a new topic on what I perceive the benefits are of XHTML 2.0 over XHTML 1.0. I'll have to write it tomorrow, as I'm dead knackered, and have had too much to drink to be coherent. My initial reaction is, so what if designers decide they'll never use XHTML 2? If their documents are standards compliant, I will still be able to view them if I choose. If those pages are inaccessible to emerging technologies that require documents to be in XHTML 2 format, that's their loss - not their visitors', as the service would never have been available to be missed.
Posted by Gez on
[nested-headings.php#comment16]
Gez,
Careful, you're in danger of making me sound like a dinosaur (# 9). I recognised the advantages of relational over non-relational DBs when non-relational were still the majority (yes, I was around then!) and fell in love with OO when I first used VB, and again when I started using Javascript.
Your comparisons of Fortran with C and C with C++ don't convince me because it was always obvious that C could do things Fortran couldn't and C++ could do things C couldn't - things which offered clear benefits to both developers and users.
It's less obvious that XHTML 1 Strict or XHTML 2 offers similar advantages, and more obvious that they're taking away facilities and / or introducing incompatibilities. Hopefully your article on XHTML 2 will change this impression.
I really don't understand your comments (# 14) "Microsoft has a dominant user base, but not necessarily a dominant developer base. It would be possible for developers to force Microsoft's hand on this issue, .." and "If those pages are inaccessible to emerging technologies that require documents to be in XHTML 2 format, that's their loss - not their visitors', as the service would never have been available to be missed."
IE won Browser War 1 because:
A) It came on the Windows CD, was ususally pre-installed and did not have to be downloaded.
B) It was so superior to Netscape 4 (the only real competition at the time) that nobody had an incentive to download Nestscape 4.
IE is now the least capable browser in common use, but how many users will download an alternative? The majority are not developers, and may not even know there are alternatives.
So most sites will continue to do what they've being doing - develop for the least capable browser / user agent which can present what they want the way they want. Power is in the hands of users, not developers.
Standards which fail to recognise this will be ignored or will have to back-pedal (like CSS 3's proposed box-sizing:border-box).
I don't think there will be a Browser Wars 2 - IE will remain dominant.
Posted by Philip Chalmers on
[nested-headings.php#comment17]
Sorry, mate
I feel like a dinosaur myself at times.
You surprise me. You must have incredible insight, as VB's OO capabilities are very basic, and generally underused because of the limitations. VB.Net has much better OO capabilities.
The advantages of C++ over C, for example, may be apparent to someone approaching the languages with an open mind, but not so apparent for someone who's been programming in C for several years. The initial advantage was that you could have user-defined structures that defined objects in terms of data and behaviour (classes). As far as a lot of C programmers were concerned, you could write the same programs using structured programming. I've worked alongside several very capable C programmers who didn't want to switch to C++ because they just didn't get the advantages, or didn't think learning a new approach to programming was worth the effort. I also know a few whose hand was forced on the issue, and more or less use traditional C in a C++ project. Also, it has to be said that there are situations where C is a more suitable programming language than C++. The point is that a capable developer would understand what options are available, and choose the correct tool for the job.
The design goals of XHTML 2 are consistent with the original version of HTML that was designed to describe a document's structure, rather than the presentational elements introduced by browser manufacturers. The result of completely removing presentation capabilities and ensuring a document is semantically correct is that documents will be more machine friendly. Machine friendly documents create an opportunity to completely change the way the web works. Any electronic device could be engineered to connect to the web. I think there are developers that assume this can be achieved with the current markup specifications, and even when the flaws are pointed out to them, suggest we live with it. In several years time when XHTML2 is a recognised standard, I think those advantages will be clearer to people approaching it with an open mind.
I completely agree. Power will always be in the hands of users all the time that developers are prepared to compromise standards in favour of IE. By being united, developers could change this situation through education and not pandering to IE. The whole concept of not pandering to IE is absolutely ridiculous, as developers are not united on this issue. That was the point I was trying to make, albeit badly; and probably not much better now
Personally, I don't care whether or not developers decide to follow the standards route or the IE route. I've made my feelings known in the past of how I feel about the web development industry in general. I think it's a cottage industry, swamped with people who don't have a clue about standards and accessibility. I'm not suggesting that everyone has that attitude, as there are clearly plenty of people trying to make the web a better place. The fact is, there are several more people who couldn't give a toss, and would produce inferior websites for a fraction of the price of companies that do care about these issues. A major factor in this is that the people who commission websites have very little understanding of what they require, and trust the companies they employ to ensure they're legal, as shown by the result of the recent formal investigation of UK websites by the DRC http://juicystudio.com/drc-invesitigation
You could well be correct, although I sincerely hope not. If IE continue to remain dominant with their proprietary new browser, there will be no point anyone bothering with the W3C as a standards organisation; Microsoft de facto standards would be more appropriate. The Web will only be accessible to Microsoft operating systems, or what bits they open up to competitors to ensure they can compete fairly. Judging by Microsoft's past performance, they won't do that; why should they? If developers don't see that as a bad thing, there's no hope really.
Posted by Gez on
[nested-headings.php#comment18]
Gez,
Somewhat off topic - perhaps more appropriate to "Old coders never die, they just just switch languages".
I did not have extraordinary insight to notice the OO leanings of VB - my first working language was IBM mainframe assembler. Assembler languages have the same memory and pointer manipulation capabilities which C has and which are the technical foundation of OO. The control blocks which abound in assembler programs lool like primitive objects because they contain both data and sub-routine pointers which vary depending on each control block's "sub-class".
Posted by Philip Chalmers on
[nested-headings.php#comment19]
But we're not really. Not for use within pages. We're talking about replacing
With
I get that but surely the point about new technologies is that they're progressive? I'm concerned that we're going down a one-way street where only those who care passionately about every new standard thats released use these new standards. Surely it would be better to have genuine improvements that make a real difference. I'll not go on about it though as I'm drifting into the realm of the new topic you posted
Posted by Kev on
[nested-headings.php#comment20]
Hi Philip,
I'll stay off topic too, as this is an interesting topic.
I see your rationalisation, but I still think you have a good insight to recognise that as being a good thing. The power of OO to me is inheritance, whereas VB's implementation was merely to provide a mechanism to encapsulate data and behaviour into a single object, and support interface inheritance, which is very limited compared to true inheritance. Despite the limitations, I do recognise this as being a good thing, but I don't think I would if I'd never used an object oriented programming language before. I've had very little exposure to assembly language programming, but found it useful for an appreciation of how the programming constructs for high-level structured programming language were formed. I would never have made the association between control blocks and objects had you not pointed it out.
Posted by Gez on
[nested-headings.php#comment21]
Hi Kev,
In that example, the section element isn't required, but I take your point that sub-headings would be required to be within a section. I see the section element as being similar to the div element, except it has more semantics as it has the capability to automatically determine the heading level.
It's not so much whether people care passionately about new standards; it's more a case of whether they have a use for those new standards. Apart from the extremely curious, I doubt there are many people, including standards activists, that have used MathML or SVG, unless they have a genuine need to describe mathematics or graphics in XML format.
Posted by Gez on