W3C home > Mailing lists > Public > www-html@w3.org > August 2002

Re: Comments on XHTML 2.0 Working Draft

From: Jonny Axelsson <jax@opera.no>
Date: Tue, 06 Aug 2002 18:33:58 +0200
To: www-html@w3.org
Message-Id: <QLF52B9URPLSOQO1YEADA6ZC062ZXI.3d4ffa76@falcon>

06.08.02 16:03:05, Chris Mannall <chris.mannall@hecubagames.com> wrote:

>8.11 The heading elements
>-------------------------
>
>Is it necessary to have two forms of heading? Bearing in mind that the 
>combination of h and section is recommended over the traditional hX 
>elements, I don't see why both are required. Can the hX elements not be 
>deprecated?

>If it's really necessary to retain the functionality of the hX elements, 
>could we not instead have something like this?:
>
>	<h level="1">Equivalent of h1</h>

From a minimalist's point of view they could, but I don't think we would do 
anyone a service by doing that. 

Firstly, backwards compatibility isn't in itself a bad thing. It is nice if 
the page you made yesterday also works today.

Secondly there are cases where you do want to hardwire heading level, and 
while you could make h1-h6 fully redundant by adding a level attribute to h, 
h1-h6 would still be more convenient.


>8.9 The div element and 8.19 The span element
>-------------------     ---------------------
>
>Reading the descriptions of these elements, I have to wonder why both 
>are necessary. Since the descriptions of both state that "this element 
>imposes no presentational idioms on the content", the only difference 
>between the two is that one is defined as "inline" content and one is 
>defined as "flow" content. One could argue that this distinction is 
>mostly presentational anyway... there's no reason why a single element 
>could not be used for both purposes, for example:

The content model is different. The div element can contain block elements, 
span can't. The distinction between block level elements and inline elements 
are kept, even though they can be presentented otherwise.


>8.16 The quote element and 8.4 The blockquote element
>----------------------     --------------------------
>
>Based on the fact that blockquotes are now allowable inside a p element, 
>is it really necessary to have two elements? It seems to me that once 
>again the only difference between these two is that one is "inline", one 
>is "flow"... which strikes me as a presentational difference that should 
>be left to stylesheets:
>
>	quote { display: block; }
>	p quote { display: inline; }

It is open for discussion whether quote and blockquote contain different 
kind of quotations, they do have different content models.


>18.1 The noscript element
>-------------------------
>
>Is this element necessary? Shouldn't the onus be on document authors and 
>script authors to ensure that documents function appropriately whether 
>scripts are executed or not? The functionality of noscript (only 
>rendering certain content when scripts are unavailable) is easily 
>duplicated by approaching the problem from the other direction:

It is better to specify this in a declarative fashion, this makes the 
relation clearer to non-scripting user agents as well as user 
agents/programming languages that don't support DOM. One goal is also to 
link noscripts to a specific script, probably with nesting, e.g. 

<script type="text/perlscript" src="a.pl">
  <script type="text/pythonscript" src="a.pt">
    <noscript>Neither Perl nor Python supported</noscript>
  </script>
</script>


>18.2 The script element
>-----------------------
>
>Is there any chance that we can start the process of renaming "src" 
>attributes to "href" attributes (or vice versa)? The distinction is both 
>unnecessary and unclear - someone once made the argument to me that src 
>is used when the resource is to be included directly included into the 
>document, and href when the resource is something being pointed to as 
>some form of relation, but examination of HTML and XHTML specs doesn't 
>agree with this argument. If this were the case, then I suppose I could 
>tolerate the difference between the two... without this semantic 
>difference, I can see no reason whatsoever to have two different 
attributes.

Personally I don't think it is worth it. There are a number of linking 
attributes, such as cite, data, href, longdesc, src... I don't see a great 
advantage in renaming those as there are a number of different kind of 
linking types anyway.
 

>It may also be worth highlighting the fact that scripts may need to be 
>wrapped in <![CDATA[ and ]]> declarations if those scripts contain 
>operators conflicting with certain aspects of XML (e.g. <, > operators). 
>The same is true of inline stylesheets.

Good point. Noted.


>Unfortunately, the working draft I have just read doesn't even come 
>close to reaching this objective. Granted, the move to XForms is a step 
>forward in this regard, but "arcane knowledge" is still very much the 
>order of the day since linking, images (via the object element) and 
>image maps are still an intrinsic part of XHTML itself rather than being 
>farmed-out to XLink.

XLink can't support neither object, link or image maps, so that is not a 
real option.


Jonny Axelsson
Documentation,
Opera software
Received on Tuesday, 6 August 2002 12:30:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:52 GMT