> The most important comment I have is that there is too much emphasis
> on rendering. In the draft RFC, description of a feature is often
> accompanied by some discussion of how it might be rendered. For a
> particularly strong example, see the roles for the P tag. Now either
> these hints are part of the specification or they are not. If they
> are not, then they should go into an appendix.
HTML+ includes rendering hints and when they are recognised by browsers, they
should be treated in a predictable/consistent way. It makes sense to describe
these, in the minimal fashion needed for such consistency, at the point in
which the relevant attribute is introduced.
Perhaps the suggestions are too vague or too strong - please let me know.
> As a further point re rendering hints, consider, please, that some of
> the Internet community is blind. Do you want to include hints to
> writers of audio browsers also?
That sounds an interesting area to experiment with! It looks (sic) like
further work is needed before we can come up with hints to writers of audio
browsers. This seems to me more suitable for a later informational RFC.
> why a citation better conveyed by <em role="cite"> than <cite>
There are many potential logical emphasis tags like "cite". The EM mechanism
is intended to prevent an explosion of tag types. The combination of logical
and physical emphasis into a single element means that browsers can deal
sensibly with emphasis even when it doesn't recognise the logical category
involved. It gives us open ended logical categories with rendering hints.
> Are the roles (which are English words) also to be used in documents
> not written in English?
Yes, just like you have to use the same tag names. WYSIWYG editors would
hide this from people though.
> the "footnote" and "margin" roles of em are not roles, that is they
> don't describe semantics, they are rendering hints. Again, I won't
> argue whether or how much HTML+ should support rendering but can we
> at least agree to call hints hints and roles roles? There is some
> underlying semantics here, namely that the foot note is a comment
> on the immediately preceding text; and that both are a kind of
> digression. But the decision to place at bottom of page or in the
> margin is purely rendering.
I agree that this is bending the scheme somewhat. Perhaps one could make
them rendering attributes as in <em footnote> .... </em>?
> I suggest that roles be spelled out, not abbreviated as in e.g.
> "dfn" for "definition" or "kbd" for "typein".
> the optional rendering hints for typeface (hv and tr) are mis named.
> If the meaning is supposed to be "sans serif font" or "serif font"
> then why not instead have face=sans-serif and face=serif. Or
> serif=yes/no?
Maybe. I chose these names for brevity and compatibility with HTML.
What do other people feel about this?
> <hr> is rendering.
Thats right. Browsers could ignore it if they want.
> when specifying size of a text field for input, which font is used for
> the character units of the width and height?
The font to be used in the field itself. For variable pitch fonts it makes
sense to use the width of the largest character. Alternatively, browsers
should allow the field to scroll sideways, as is common on many GUIs.
> for role=byline - what's the scope of this? the whole document, the next
> section?
The spec says "information about the author of the document".
> Re tabs in PRE - if someone specifies tabs with the tab tag, does this
> replace the built-in tab stops at every eight characters?
If there are more tabs on a given line than tab stops, then the extra tabs
can be treated with the default every 8 character tab stops. This is the way
it works with Microsoft Word. I haven't tried other packages.
> In many places the document tells us that an id field can be used. It
> would be nice to have a full list of all possible places. Should we
> assume that an id is only permitted where the doc explicitly says it
> may go?
The DTD is the authority on this matter.
> The FIGD tag "allows you to give a textual description which can be
> shown when the figure itself can't be". But may/should a browser show
> the material in a FIGD tag when it CAN show the figure?
A reasonable idea is to show this text while waiting to retrieve the figure
data itself.
> Re: ISMAP. Shouldn't the encoding also specify *which* mouse button
> was pressed?
No, some systems only have one mouse button. I guess suggesting the left
button when there are two or more might be worthwhile.
> You should delete the sentence that says ISMAP is slow. That's not
> part of the spec, is it?
Thank you. Its a hangover from an earlier draft - well past its read-by date!
> Re: Tables: Why not spell it as <table> instead of <tbl>
I did in earlier versions, but TBL seemed more in line with the other tags.
> The first "guideline" says: "There is no need to declare empty cells
> at the end of a row". But this is certainly not a guideline, e.g. it
> is not something that a browser is free to ignore. A browser which
> does so is, I think, in error.
The row separator unambiguously defines where one row ends and the next
begins. This suggestion will make browsers more robust. I will move it
to a better place.
> Can a table have more than one <tt>? Must all <tt> be before all <th>?
The DTD makes it clear that only one is permitted, and that it must be
directly following <tbl>.
> It seems that the designer of this feature must have intended some
> semantics which the example hints at but the spec does not mention.
> Note that the first two lines of the table have only three entries
> (line 1 has two entries, the first spanning two columns), yet they
> begin in column 2, not column 1.
The spec is perhaps too concise. In the first row,
<th rowspan=2><th colspan=2>average<th>other
The first cell is empty and merged with the next row (rowspan=2). The
next cell spans 2 columns (colspan=2).
In the second row: <th>height<th>width<th>category
The first cell is implicit and carried over from the first row, by the
rowspan=2 attribute. This is explained in the footnote. I hope you can
see that each row provides definitions for all four columns. Note you
can mix TH and TD on the same row, e.g. when the first column contains
headers (TH = header cell, TD = data cell).
The complications arising from merged cells should be hidden by WYSIWYG
editors, but the general format is really quite simple (you should have
a look at other table formats!).
> the <tb> tag is pure rendering.
Yes, but worth having I think.
> Re: Link attributes. Which if any of these attributes are mandatory?
For the A tag, only HREF, For the LINK tag ROLE is also needed to make sense.
> Re: Change Bars. It would be very nice to have a way to express the
> date/time the change was made. It would also be nice to have a way to
> express the identity of the person who made the change.
Good idea!
> Re: the Miscellaneous tags. the description here makes it seem that
> these are mandatory. I think what you mean is that if they appear at
> all they can only appear at the start, not that they "must appear"
Thanks for spotting this!
> It would be nice if the RFC had a table of contents and an index, as it
> is likely to eventually become the reference manual for HTML+
> It would be nice if there were section and subsection numbers
> throughout.
OK I will try and create a table of contents and an index as you suggest.
I am not a fan, though, of section numbering.
I have been getting a number of other requests, and will need to revise the
spec fairly soon anyway, before it gets proposed formally as an Internet
Draft.
Many thanks for your comments,
Dave Raggett