Re: Comments about the 2002-08-05 XHTML 2.0 WD

On Wednesday, Aug 21, 2002, at 12:50 Europe/Helsinki, Chris Mannall 
wrote:

> > The Draft says 'Apple systems, one generally has to press the "cmd"
> > key in addition to the access key.' The command key is the
> > accelerator key for the keyboard shortcuts of the browser's own
> > functions on Mac, so another modifier key (eg. ctrl) would have to be
> > used in order to avoid conflicts.
>
> I agree that conflicts can arise, but don't think it is an issue - 
> which
> key is used as the modifier is not a matter for the specification to
> decide, but for the browser.

I agree it is an implementation detail. My point was that the example 
isn't a good one.

> > I like the <section> and <h> arrangement a lot. However, I think
> > including <h1> through <h6> unnecessarily complicates things. I'd
> > like to suggest including only one way of marking up headings (the
> > <h> and <section> way) instead of including two incompatible ways.
>
> Half agree, half disagree. My view is that the *functionality* of <h1>
> through <h6> is still useful, despite the new h/section mechanism, yet 
> I
> would prefer to see a "level" attribute on the h element.

What's the functionality of h1 through h6 in this case? They provide a 
more direct mapping from other flat heading structures but that's about 
it. However, even the flat model can be converted to the h/section 
model. MS Word, for example, uses the flat in the style UI but uses a 
h/section-like view in the outliner.

> > The definition of <link/> includes the old HTML 4 style sheet
> > linking. Since there is a general processing instruction for
> > associating style sheets with XML documents, I think requiring user
> > agents to support <link/> style sheets is unnecessary.
>
> No thanks. I don't want to be forced to use the processing instruction
> for XHTML. There are historical reasons for it's existence - basically,
> a mechanism for attaching stylesheets to generic XML was required,
> within a very short timeframe, and processing instructions were seen as
> a "quick fix" for this problem [3].

I don't quite understand the security issues referenced in [3] when it 
comes to W3C-defined xml-foo PIs. One could argue that different UAs 
react differently to different elements as well. As for namespaces, the 
xml-foo PIs are about as much namespaced as xml:foo attributes.

PIs made it into the XML and the DOM so dealing with them isn't too 
difficult. OTOH, having two methods for doing the same thing (PIs and 
vocablulary-specific elements) tends to add both bloat and confusion.

> > I'd like to suggest disallowing the use of document.write() with
> > XHTML 2.0 and with XML-based languages in general.
>
> Not an XHTML issue; I suggest taking it up with the DOM working group.

Some issues have an impact on the work of the HTML WG even though 
they'd officially be working items for the DOM WG or the TAG. Problems 
arise if the issues are just tossed over the fence because they are out 
of scope in every WG. (Compare with media types.)

If, in this case, the DOM WG chooses to endorse the Mozilla-style 
non-support of document.write in XML (which I think would make sense), 
allowing the script element in XHTML 2.0 outside the head element would 
be moot (more below) and would just complicate implementations.

In any case, if this is an issue for another WG to tackle, I think the 
spec shouldn't include document.write in the examples, because 
experience shows that Web authors tend to base expectations and 
authoring practices on examples even if the examples were specifically 
labeled non-normative.

> There are still uses for having script elements inside the body, with
> or without document.write(). For example, some server-side technologies
> allow document fragments to be included dynamically on the server-side;
> it is useful to be able to bring in the entire fragment in one piece,
> rather than having to remember both to bring in a script and bring in
> the document fragment. For example, if I have a heavily-scripted menu
> system that occurs on multiple pages, I may store this as a separate
> server-side component that I reference on those pages. For example, in
> ASP.NET:
>
>   <body>
>     <myCustomControls:Menu runat="server" />
>   </body>
>
> At server-side runtime, the Menu element is replaced with the contents
> of the Menu control - which can include scripts.

Personally, I think the simplicity of user agent implementations should 
outweigh the simplicity of server-side scripting when it comes to 
markup language design for the Web. The clients may be small devices 
but the servers can deal with constraints that make it slightly harder 
to just dump stuff in the document.

> I can accept that many webpages contain footers; what I am uncertain
> about is what use could be made for a footer element if one were added.
>
> Think about it - if you had such an element, what would you do with it?
> What benefit would be gained?

I'd mark up footers using it. The benefit would be that all conforming 
XHTML 2.0 user agent could provide a meaningful presentation separating 
the footer from the end of the main content.

A real world example (http://www.macsanomat.com/nayta.php?id=790): A 
Web columnist does an interview. The last block of the main content 
text from the interviewee. Then, below the main content, there is a 
note about the next issue. The footer is a div with a CSS border-top. 
When the page is viewed in a lightweight user agent that doesn't 
support CSS, the change of the content originator between the 
paragraphs is not obvious.

(http://www.macsanomat.com/nayta.php?id=790)

> Granted, you could style it in some way;
> but you can do that with <div class="footer">. I don't see any other
> tangible benefit.

The benefit would be meaningful presentation in lightweight browsers 
that don't support CSS. (As a secondary point, search engines could 
assign a different relevance value to footer and the main content.)

> > Another thing that I've noticed is that (X)HTML doesn't provide any
> > semantic markup for indicating which part of the page are main
> > content and which parts are navigation.
>
> In the past, maybe; now there is the nl element [4] (navigation list, 
> or
> "menu" in other words). If this is insufficient for your needs in
> some way, I suggest you let the working group know.

nl is insufficient for the purpose I had in mind. nl seems to be 
specifically a declarative replacement for JavaScript pop-up menus.

I meant markup for indicating the navigationness of a part of a 
page--not just nl-style menus.

-- 
Henri Sivonen
hsivonen@iki.fi
http://www.hut.fi/u/hsivonen/

Received on Saturday, 28 September 2002 08:30:30 UTC