- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Wed, 28 Nov 2007 11:54:02 +0100
- To: public-html@w3.org
Joshue O Connor wrote: > Hi Olaf, > > Dr. Olaf Hoffmann wrote: > > 1. more semantical structure [...] > > User agents can simply derive the hierarchical structure of the headings > > (and their styling) from the hierarchical structure of section elements > > automatically. > > Is this from their placing within the document? Does it happen by the UA > counting the nodes in the DOM or similar? > This answered already Lachlan Hunt, it is mentioned in the working draft how to derive an index. > >If a screen reader or a viewer can make a difference > > between h1 and h2, it should be possible too to count section levels > > while reading/displaying it. > > Ok, but please clarify exactly how. Well, I only tried once an audible presentation of text from a computer in german (the native language I speak and understand), but I did not understand a word, therefore I'm surely not familar, how screen reader give notes to the audience about the importance of a heading. Even with a human reader (for example if someone read out a fairy tale to children) I think there is no standard way, what to do, how to style the presentation of hierachical structures. But if a reader has a method to 'style' audible a difference between h1 and h2, it should be possible to count headings outside sections and sections nested in each other with heading to derive the numbering as specified in the working draft. Then it is the same problem as to style h1 and h2 differently in an aural stylesheet. If the document only uses section structures and no h2...h6, I think, it is simple to create a default aural CSS stylesheet. But if both systems are mixed, indeed, this gets more difficult, but as far as I can see (from an author point of view) not impossible. And as we all know, this will happen, authors will not really care much about the intentions of the authors of a specification or about 'best practice', therefore they will use h1-h6 inside and outside of nested section elements in an almost arbitrary combination. From this point of view of course it would be simpler for implementors to separate the two methods either using section+h or using h1-h6. Separation of different functionalities is mostly a good idea to avoid more difficulties as necessary. From the point of backwards compatibility it is an advantage to have at least h1-h6 as known heading elements inside section, but this is paid with more complex rules for implementation. ... > > > 3. it is simpler to reuse content in different environments as done > > very often for example with server sided scripting or with chapters > > from different authors in one document or in anthologies. > > Yes. I can see how that could be very useful for content that is put > together on the fly - print on demand publishing etc. > > > This is an advantage for users, because now the user agent can > > derive the hierarchical structure, even if the author or the script > > did not care about it, author or script have only to use sections > > to get a sufficient structure in quite different environment without > > changing the content of text fragments. > > Again, I would really like to know how before I can "trust" that this is > the case. As I stated earlier I am trying to understand how this will > work for users of AT. If there was a "Sections List" in the JAWS or > other screen readers virtualisation features then this will be fine. For > example the number of <section> elements could be listed (Indexed from > 1) and then the document structure could be inferred and navigated by > the user in a dialogue box but then this kind of feature will need to be > implemented/supported by UA vendors. The <section> element would then > take the place of numbered H tags and remove the load on authors to have > to think about how their content could be structured. Also a real > benefit of this method is for dynamically generated content documents > can then be structured correctly on the fly by the UA reading how the > DOM has been constructed or similar. > > However this is a little "Tomorrows world" at the moment, I guess. > > Josh Well, HTML5 is today just a working draft. Looking at working drafts for other formats (CSS, SVG, XHTML2) it may take some years going forward and backward between WDs and WDs and CR and so on, depending on comments to the drafts, until it gets a recommendations. And there are maybe even more interests on HTML as on CSS2.1, therefore probably many comments and conflicts to solve, before it becomes usable. Therefore there is still much time for implementors to care about new elements before a large amount of authors will really use it ;o) And larger parts of HTML5 are still very similar to HTML4, not a completely new approach as XHTML2 is.
Received on Wednesday, 28 November 2007 10:58:14 UTC