- From: James Graham <jg307@cam.ac.uk>
- Date: Tue, 16 Nov 2004 13:33:41 +0000
(I tried to send this yesterday) Laurens Holst wrote: > James Graham wrote: > >>>> Well, <h> wouldn't be backwards compatible at all. At least <h1> would >>>> look like a heading of sorts. >>> >>> >>> I give you one abbreviation: CSS. >> >> >> Sure one can make anything look like a heading. But no HTML4 UA would >> recognise <h> as a heading whereas <h1> would, at least be considered >> to be a heading element. > > > Is that important? I mean, for the user browsing the page it's about > how the page looks, isn't it... Well it depends what kind of browser they're using. One that uses the sematics of the page to enhance the user experience will not work as well if it meets new elements. > And obviously newer browsers will understand <h> just fine. In > addition to that, if the page author finds backwards compatibility a > concern, he can just use the <h1>...<h6> tags, they're not even > deprecated. OK so I really don't understand your position. As far as I can tell, the problem is this: We want a heading model that is more structured than that in HTML 4. The introduction of <section> allows documents to be structured in a way that is robust and should be able to support a heading model that reflects that structure. For backwards compatibility we need to also support the HTML4 heading "model" with <hn>. For interoperability, it is necessary to define how a UA can derive structure from the heading model. This has to be rather precise and not the vauge comment in HTML4 that heading levels reflect 'importance' and that UAs could produce a document outline from headings. Given this list of constraints, what is the advantage of introducing yet-another-heading-element <h>? I don't understand what it does that <h1> through <h6> do not do. As far as I can tell, all that needs to happen is that we specify the interaction of <h1> through <h6> with <section> (and <section>-like) elements. This should be clear enough that, given a set of markup, everyone can agree what the structure it is. It should be error-tolerant enough that using headings out-of-order or other such things don't break the model. >> ware products go to maintain backward compatibility, there is some >> evidence that the XHTML2 path is a mistake. > > > If you'd look at the facts instead of supposed design goals... They > have kept <h1>...<h6>. That's all very useless unless they specify how <h1> through <h6> interact with <h> > They have adopted <quote> in favour of <q> which was suggested here as > a proper solution to 'the <q> problem'. > > I think it is worth investigating a possibility of adopting XHTML 2.0, > and not discard it on beforehand based on 'design goals' without even > looking in to it. (some general objections to this) Adopting XHTML 2 wholesale sounds crazy. It is being written by an entirely different team to meet entirely different requirments. It may change at any moment for any reason without any consideration being made for the needs of the Webapps spec. Blindly copying another effort, into which you have had little input, and which has no regard for you is not the way to produce a coherent, useful, requirement fufilling spec. That's not to say that some features of XHTML2 aren't worth examining. But it does mean that "it's like that in XHTML2" shouldn't be any sort of standalone argument. >>> Now try making a tree view based on h headings. >> >> >> Well it's impossible unless you explicitly support HTML5 i.e. not >> backwards compatible. > > > Where is the HTML 4 support for a 'tree view' then? > > I have never seen a 'create TOC here' tag in HTML. I';ve never seen the <render-here> tag in HTML either but HTML documents can be rendered... it's the job of the UA to interpret the document, not the document itself. > > >>>> 2. It has to be possible to write new documents that use the section >>>> elements and have the headers be automatically styled to the right >>>> depth (and maybe automatically numbered, with appropriate CSS), >>>> and yet still be readable in legacy UAs, without having to think >>>> about old UAs. Basically, the header element has to be header-like >>>> in old browsers. >>> >>> >>> Let me just refer to my first (two) paragraph(s) here. >> >> >> "Basically the header element has to be header-like in old browsers". >> If 'header-like' means anything other than 'has a heading-like >> appearence (in which case <font size="24"> might be heading-like) >> you've totally ignored this point. > > > font-size: 24px IS heading-like, as far as visuals are concerned. CSS > can also be used to specify an aural style for it, creating the same > resemblance for visibly impaired people not using a supporting browser. Heading-like != heading. You can't use style as a backward-compatibility argument - it doesn't work for people with CSS off, for people with user stylesheets, for people with text-only browsers, for people using aural browsers with no CSS support (i.e. all of them apart from EmacsSpeak), people using UAs that care about sematics (e.g. search bots) and so on and so on. > > > >>>> 3. It shouldn't be too easy to end up with meaningless markup when >>>> doing either of the above. So a random <h4> in the middle of an >>>> <h2> and an <h3> has to be defined as meaning _something_. >>> >>> >>> This is no different than the existing spec. This would mean a 4th >>> level heading between a second- and a third-level heading. >> >> >> HTML 4 doensn't really specify how this should work. > > > HTML 4.01 says: > "Some people consider skipping heading levels to be bad practice. They > accept H1 H2 H1 while they do not accept H1 H3 H1 since the heading > level H2 is skipped." > > XHTML 2.0 says: > "The practice of skipping heading levels is considered to be bad > practice. The series h1 h2 h1 is acceptable, while h1 h3 h1 is not, > since the heading level h2 has been skipped." > > Its use is considered bad practice ([by some]), however that is still > a choice for the page author to make. It does not form an obstacle for > UA implementation and the DTD/Schema allows it. That's not "specified". That paragraph may as well say "we didn't want to think very hard about the problem of out of order headings". It's impossible for vendors to produce interoperatble document structures from that text (this would be useful so that e.g. an autogenerated table of contents at the top of a document matched the outline view presented in a browser). >>> , or use the highest level of either the section or the heading. I >>> don't see a need to define this more specificly, as h1...h6 just >>> don't go very well with sections. >> >> >> In a backwards-compatible world, they have to interact somehow (if >> the XHTML2 people haven't defined this yet they will have to or their >> heading model will be totally broken). > > > XHTML 2.0 says: > "There are six levels of numbered headings in XHTML with h1 as the > most important and h6 as the least. The visual presentation of headers > can render more important headings in larger fonts than less important > ones. > > Structured headings use the single h element, in combination with the > section element to indicate the structure of the document, and the > nesting of the sections indicates the importance of the heading. The > heading for the section is the one that is a child of the section > element." > > So it considers h elements more structured. Great. But we don't need to know the philosophy of the spec authors. We need to know how to create interoperable implementations of the spec. > > For searchbots, I already mentioned them and said that if page authors > consider that a problem they can use <h1>...<h6>. However, there are > many cases where using <h> instead would not be really problematic, > for example for pages which don't care about Google rankings as much > (many non-commercial / amateur sites come to mind, and besides, > Google's ranking is mainly based on the 'pagerank' technology and only > in a lesser amount on stuff like headings). Do you have any actual evidence about the way google works? Do you think it's acceptable if we produce a spec that by-design will only be used by small-little visited sites? Will that help improve the general user experience on the web? > Also, would there really be a need to declare that semantically? Yes. It's important e.g. to a aural browser to know how such content is related to the main page content so that they may read it at the appropriate time. > Nevertheless, I'd say an :or pseudo-selector (like XSLT's |) would be > a viable addition to CSS. That sounds good. > > > People who would actually like to write XHTML 2.0 but be able to > benefit from HTML 5 support and compatibility would :). > > >>> At least if you don't try, you can be sure they never will. In any >>> case h1...h6 would not be deprecated so there is no reason not to >>> use them if you want to. >> >> >> But how would they interact with <section>? That's the question, no? >> I feel I'm missing something here... > > > I'd say that's indeed a bit ambiguous. > > However, wanting to give a clarification for this wouldn't obstruct > the adoption of <h>, which I am trying to make a case for (in the > context of adopting XHTML 2.0 as a whole). > > As far as <section> is concerned, <h1>...<h6> are just headings inside > a section. They could be treated like a <h> tag by e.g. a TOC > generating transformation. This is quite logical, because the whole > problem is that 'HTML 4 headings' are not attached to the document > text, and the best approach to solve that is to assume all the text > inside the same <section> (or in HTML 4 terms, until the next > <h1>...<h6> heading, which is obviously a quite fragile assumption) > belongs to it. However, it all also depends on how the author intends. > After all, why on earth would an author create headings which don't > match the sections :). > > When rendering, they should be rendered just as they currently are in > HTML 4.01. > > Basically <section> and numbered headings don't go well together and > that's why it's so important to have a really unambiguous tag like <h> > available. I disagree that we need a new heading tag. I think that will generally be worse than reusing existing ones. I also have no probelm with <h1> to <h6> being styled as in HTML 4; that should encourage authors to use them in a backwards-compatible way.
Received on Tuesday, 16 November 2004 05:33:41 UTC