[XHTML2] Comments on WD 5

(Replies have been directed to www-html only.)
This post is a combination of editorial comments and suggestions for 
changes that could be made in XHTML2.  I have not repeated the 
suggestions I have made concerning firming up the way XHTML2 handles 
establishing the connection between meta-data and its profile, as those 
appear to be in the process of being addressed.  Other comments that I 
have made that appear to have been unaddressed so far, I have repeated 
where I feel that those comments were not purely of a stylistic nature.

1) Section 5.5 Attribute Types
I mentioned this in a comment on the fourth working draft (PR#6440) but 
no resolution has been offered so I'm rementioning it.  The first and 
second tables are inconsistent in that one refers to Attribute Types 
and the other to Data Types.  I recommend that the section refer to 
attribute types uniformly.

2) Section 5.5 Attribute Types
As far as I can tell the NAME attribute type is unused in XHTML2.  In 
HTML4/XHTML1 the NAME attribute type was used only for the name 
attribute of the meta element and that has been changed to NMTOKEN in 
XHTML2.  I recommend that the NAME attribute type be removed from the 
working draft.

3) Section 5.5 Attribute Types
As far as I can tell the Charsets attribute type is unused.  Indeed, I 
can't even imagine a circumstance in which one would want to indicate 
multiple charsets in XML.  I recommend that the Charsets attribute type 
be removed from the working draft.

4) Section 5.5 Attribute Types
This is a revision to a comment I made on the fourth working draft 
(PR#6442).  The Length attribute type is unused by any attribute in 
XHTML2.  It is used however by the Coordinates attribute type.  I 
recommend that the Length attribute type not have a separate listing, 
but that its description should be moved to the description of the 
Coordinates attribute type.

5) Section 5.5 Attribute Types
The URIList attribute type is new to XHTML2.  In HTML4/XHTML1, the
uri-list attribute type is what XHTML2 calls URIs.  Since the comma can 
be a valid URI character, I recommend that all usage of URIList in the 
working draft be changed to URIs and that the URIList attribute type be 
removed from the working draft. (See also comment 19 below.)

6) Section 6.5 Hypertext Attribute Collection
The sentence "The value of this attribute is a space-separated list of 
link types." used in the description of the rel and rev attributes is 
redundant since this is mentioned in the description of the LinkTypes 
attribute types.  It may be worth removing these sentences.

7) Section 6.7 Image Map Attribute Collection
Could the image map shapes be more closely aligned with the Basic 
Shapes Module from SVG?  To completely do so, three changes that can be 
separately implemented would be required.
7a) Ellipses
Add "ellipse" to the list of values for the shape attribute.  Ellipse 
would expect four coordinates to be provided:
 center-x, center-y, radius-x, radius-y.
7b) Rounded Rectangles
Add rounded rectangles to the possible shapes.  This would mean that 
when the shape attribute is "rect", That four, five, or six coordinates 
could be provided.  When four are provided, no rounding occurs.  When 
five are provided, the fifth coordinate is used as the rounding radius 
for the corners.  When six are provided, the fifth coordinate is used 
as the horizontal rounding radius (radius-x) and the sixth is used as 
the vertical rounding radius (radius-y).
7c) Change Rectangles from LTRB to LTWH
This change gives no new ability but only serves to align the way 
rectangles are specified in XHTML with the way they are specified in 
SVG.  Whether this change should be made it boils down to whether it is 
considered more important to have consistency with SVG or with previous 
versions of (X)HTML.  It definitely should be made only if the other 
two changes are also made, since without the other changes, there is no 
reason to make this change to impose consistency with SVG, as the lack 
of all the basic filled shaped that SVG provides means that there could 
be no consistency.
If the change is made made, then the first four coordinates provided 
for a rectangle would be changed from:
  left-x top-y right-x bottom-y
to:
  left-x top-y width-x height-y

8) Section 6.9 Style Attribute Collection
The issue is raised in the fifth working draft of a desire of providing 
a generic method af specifying the attributes that contain style 
information.  Two possible solutions come to mind.
8a) Add an xml-styleattr PI
Add a new PI: xml-styleattr.  This would have the pseudo-attributes 
alternate, media, title and type with the same syntax as the xml-
stylesheet PI.  There would also be an "attr" attribute that would be a 
CDATA #REQUIRED pseudo-attribute."attr" would take a space separated 
list.  The XHTML2 DTD could include <?xml-styleattr type="text/css" 
attr="html:style"?>
8b) Replace xml-stylesheet PI with xml-style PI
This would be similar to xml-stylesheet but would allow for three ways 
of specifying the location of style information instead of just one.  
It would have the pseudo-attributes alternate, media, title and type 
with the same syntax as the xml-stylesheet PI.  The href attribute from 
xml-stylesheet and the attr attribute from the xml-styleattr proposal 
above would also be present, but changed from #REQUIRED to #IMPLIED.  
In addition, a space separated list of element names that provide style 
information for a document could be provided as a CDATA #IMPLIED pseudo-
attribute named "elem".  The XHTML2 DTD could include <?xml-style 
type="text/css" attr="html:style" elem="html:style"?>

9) Section 7.4 The body element
Other than tradition, is there a reason to not allow Inline or PCDATA 
as acceptable content for the body element?  This would simplify the 
Minimal Content Model of body to (PCDATA|Flow)*

10) Section 8 The Block Text Module
A proliferation of blockXXX elements is occurring.  (We now have 
blockquote and blockcode, and discussion on www-html has mentioned the 
strong possibility of blocksamp being added.)  Might I suggest that 
instead we have but a single element: block.  The block element would 
indicate that a user agent should have a default method, such as 
indenting in a visual agent, to indicate that the contents are a 
coherent group (as opposed to section or div, which have no such 
recommendation.)  The exact method of indicating this would be up to 
the user agent and of course could be altered by styling information.  
The white space preservation properties of the blockcode element should 
be made part of the code element.

11) Section 8.8 The pre element
Is this element really needed?  If the  white space preservation 
property was attached to code, kbd, and other appropriate computing 
elements , then one major use of pre would be taken care of.  The other 
major use presented as an example, poetry, seems to be adequately taken 
care of by the l element.  Is there any other remaining semantic use of 
white space that couldn't be handled by xml:space in the remaining rare 
cases?

12) Section 8.9 The section element
The word "explicitely" should be "explicitly" with no second e.

13) Section 9.The Inline Text Module
Why not make white space preservation part of the standard values for 
the code and kbd elements?  Since an author might or might not wish to 
have sample output be white-space preserving, that property should be 
handled by the xml:space attribute or the pre element if it is retained 
in that case in that case.

14) Section 9.11 The strong element
There must  be some way of indicating the intensity of emphasis.  
Nested em's are insufficient as for example, it is impossible  to tell 
in CSS to know if even em > em::first-child > is a a single application 
of strong emphasis or a phrase which begins with something emphasized 
in a a section of emphasis that then later ends the internal emphasis, 
reverting to ordinary emphasis.  Even using three or more em's to 
indicate strong emphasis is insufficient.  While it allows an author to 
know when he means strong emphasis as opposed to emphasis within 
emphasis, leaves others clueless unless they rely upon the presentation 
(i.e.  bold text) to indicate when text is strongly emphasized.  Either 
strong needs to be retained or em needs one or more attributes added to 
it to indicate the degree and/or type of emphasis.

15) Section 11.1 Definition lists
There needs to be an element that can group together (dt+, dd+) 
groupings.  A div of dl's is the best improvisation that can be done 
right now to achieve the desired presentation effect, but that is wrong 
for XHTML2 since that implies semantically a group of different 
definition lists.  I propose that a <di> element (definition item) be 
added to the content model of of <dl>.  I.e., make definition lists 
have the following DTD fragment:
<!ELEMENT dl (dd | di | dt)+>
<!ELEMENT di (dt+, dd+)>
<!ELEMENT dt (#PCDATA | %Inline;)*>
<!ELEMENT dd (#PCDATA | %Flow;)*>

16) Section 12.1.2 Links and external style sheets
Given that there exist two other ways XHTML2 could specify an external 
stylesheet:
 <?xml-stylesheet type="text/css" href="style.css"?>
 <style type="text/css" src="style.css" />
is there any need to keep the <link> mechanism for accessing external 
style sheets?  Eliminating it from XHTML2 would allow the media 
attribute to be removed from the link element.

17) Section 13.1 The meta element
I noticed that the http-equiv attribute is being dropped.  PICS appears 
to depend upon this attribute.  Is there some other method of 
specifying PICS meta-data, or is PICS support being dropped in XHTML2?

18) Section 13.1 The meta element
According to (PR #6217) a decision was made on 15 January 2003 to 
restore the scheme attribute to the meta element.  This change has not 
yet been made in the working draft. 

19) Section 14.1 The object element
There is a change introduced in the archive attribute in XHTML2.  In 
HTML4/XHTML1, the uri-list attribute type used by the archive attribute 
was what XHTML2 calls URIs, not URIList.  Since the comma can be a 
valid URI character, I recommend that the attribute type of the archive 
attribute be changed to URIs. (See also comment 5 above.)

20) Section 14.1 The object element
The object element and the Embedding Attribute Collection both provide 
a means of embedding other data into an XHTML document.  The Embedding 
Attribute Collection deals with simple embedding, whilst the Object 
Module deals with more complex embedding.  However, the use of the type 
attribute in the object element to indicate the ContentType of the URI 
of the data attribute conflicts with the use of the type attribute to 
indicate the ContentType of the src attribute of the Embedded Attribute 
Collection.  I see two ways of solving the problem.
20a)
Since the object element and the Embedding Attribute Collection both 
deal with embedding, drop the data attribute and use the src attribute 
from the Embedding Attribute Collection to indicate the location of the 
object's data.
20b)
Since the object element and the Embedding Attribute Collection deal 
with different types of embedding, keep the data attribute and use a 
different attribute such as datatype to indicate the ContentType of the 
URI of the data attribute.

21) Section 14.2 The param element
Doesn't the param element still need the type attribute (or an 
equivalent, if XHTML reserves type to indicate only the ContentType of 
the src attribute) to indicate the ContentType of the URI given by 
value when valuetype="ref"?

22) Section 19.1 The caption element
As has already been noted in the fifth working draft, since caption now 
applies to object as well as table it needs to be placed in a module of 
its own.  Might not caption however, be profitably extended to other 
block elements?  For 
example:
<blockquote>
<caption>The Gettysburg Address</caption>
<l>A. Lincoln</l>
<l>87 Years Ave.</l>
<l>Gettysburg, PA</l>
</blockquote>
or:
<div src="/images/lastsupp.jpg">
<caption>The Last Supper by Leonardo di Caprio</caption>
</div>

Received on Wednesday, 21 May 2003 11:11:34 UTC