(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>