- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 7 Jan 2005 14:47:30 +0000 (UTC)
Thanks again for your detailed and substantial comments.
On Sat, 1 Jan 2005, Matthew Thomas wrote:
> >
> > ...
> > Previous versions:
> > http://www.whatwg.org/specs/web-forms/2004-12-10-call-for-comments/
> > (diffs)
>
> 1. <http://www.whatwg.org/specs/web-forms/current-work/diff-2004-12-10-
> call-for-comments> is an empty document.
Yeah, that will happen every now and then. The script to generate the
diffs takes about one minute per diff and occasionally the server kills
the script before it has a chance to finish (if it hits the CPU quota).
Sometimes I don't notice the diff is broken and so it stays that way for a
few days until I next regenerate the spec and diffs.
(If anyone has a better way of doing HTML diffs, let me know. I've tried
pretty much everything I can find.)
> > 1. Introduction
> > ...
> > Authors have long requested enhancements to HTML4 to support some of their
> > more common needs. Such comments in mailing lists and other forums were
> > examined, and from these sources a set of requirements and design goals were
> > derived:
>
> 2. The misleading Slashdot post of yore lingers as HTML comments in the
> spec for no apparent reason. And now that it is no longer in the
> visible text, the final sentence refers to "such comments" not
> previously introduced.
> * "such comments" --> "such requests"
The unapparent reason is that I generally comment out instead of deleting,
and delete later. Such as now. Fixed.
> > * Dynamic addition of more fields (repeating structures) on the
> > client side without scripting.
>
> 3. Grating redundancy.
> * "addition of more" --> "addition of"
Fixed.
> > * Few dependencies: this specification should stand alone and not
> > require support for other technologies such as XPath, XMLSchema, or
> > XML Events, as these are not implemented in typical Web browsers
> > and requiring them would significantly delay the time required to
> > deploy browsers supporting this specification.
>
> 4. You can delay an event, but you can't delay a time.
> * "delay the time required to deploy" --> "delay the release of"
Fixed.
> > Relationship to HTML
> > Relationship to XHTML
> > Relationship to XForms
> > Relationship to XForms Basic
>
> 5. "relationship", "relationship0", relationship1", and
> "relationship2" are poor IDs for these headings. If a Web Forms
> 2.1, 2.2, etc reorders, adds to, or removes some of these sections,
> either the numbers will become out of order, or links to the other
> sections from elsewhere on the Web will break.
Yes. Those IDs are all automatically generated by the script that
generates the table of contents.
I've changed the IDs for those four headers but there will still be many
similar problems with other autogenerated IDs in the spec.
> > 1.7. Conformance requirements
> > ...
> > Diagrams, examples, notes, and sections marked as non-normative are
> > non-normative. All other content in this specification is normative.
>
> 6. This could easily be misinterpreted distributively (diagrams marked
> as non-normative + examples marked as non-normative + notes marked
> as non-normative + sections marked as non-normative).
> * "As well as those sections marked as non-normative, all
> diagrams, examples, and notes in this specification are
> non-normative. Everything else in the specification is
> normative."
I'm dubious about "All other content" -> "Everything else" but ok, fixed.
> > 1.8. Terminology
> > ...
> > The term *form control* refers to input, output, select, textarea and button
> > elements. It does not include form, label, datalist or fieldset elements.
>
> 7. <option> probably should be included in one of these lists.
Ok.
> > 2.3. Changes to existing controls
> > ...
> > Specifically, the form, legend, select, and optgroup elements may now be
> > empty.
>
> 8. * "However, with the exception of the form element, authors should
> avoid allowing any of these elements to be both empty and
> visible for any noticable period, as it is likely to confuse
> users."
Fair point.
> > Also, as controls no longer need to be contained within their form
> > element to be associated with it, authors may prefer to declare their
> > forms in advance, at the top of their documents. The form element is
> > therefore allowed in the head element of XHTML documents, although
> > only when the form element is empty. (This does not apply to HTML.)
> >
> > Similarly, form elements in XHTML may now be nested (this does not
> > apply to HTML).
>
> 9. Why don't these apply to HTML? The explanation of the former is
> buried waaaay down in a parenthesis in section 2.18. There doesn't
> seem to be an explanation of the latter at all. It would be nice if
> these were explained more promptly.
The reason for both is the same -- it would mean changing how HTML content
is parsed in ways that could affect existing content. I don't see how to
concisely explain this in a useful manner before 2.18. Do you have any
suggestions?
> > The children of a form element must be block-level elements, unless one of
> > the ancestors of the form element is a td, th, li, dd, or block-level
> > element other than div, in which case either block-level or inline-level
> > content is allowed (but not both).
>
> 10. Why the exception of <div>?
The idea here is to allow certain cases that were disallowed in HTML4,
despite being semantically adequate. The <div> element, however, doesn't
add any semantics, and so doesn't make the case semantically adequate.
> > Authors are recommended to always have one radio button selected.
> > Having no radio buttons selected, or more than one in a group
> > selected, is considered very poor UI.
>
> 11. Why mention "or more than one in a group selected"? UAs don't even
> allow that (at least, not in standard HTML), so there's no point
> raising the possibility.
As far as I can tell, this isn't true.
> In any case, these sentences belong at the
> end of the previous paragraph.
Ok, both paragraphs merged into one.
> > The first submit button in a form is the form's default button.
> > ...
> > If there is no default button, then the implicit submission mechanism must
> > submit the form as if there was an enabled default button.
>
> 12. It would be more of a logical counterpart to the first sentence to
> say "If there is no submit button".
Agreed.
> 13. To submit a GET form "as if there was an enabled default button",
> the UA needs to include the value of the button in the submission
> URI. But how is the UA to know the value of a button that doesn't
> exist?
The same way as if there was a button but it had no name (i.e. your
premise is wrong, the UA doesn't need to include that name/value pair,
since it might not have one).
Added ", unnamed," to the sentence.
> > 2.5. Extensions to existing attributes
> > ...
> > UAs must now support the accesskey attribute on select elements.
>
> 14. First, this renders the Web Applications 1.0 draft text "Support for
> the accesskey attribute is optional" substantially irrelevant -- the
> only way of implementing both Web Forms 2.0 and Web Applications 1.0
> would be to support the accesskey attribute, making it not optional.
Point taken. Changed to:
<p id="access-key-select">UAs may now support the
<code>accesskey</code> attribute on <code>select</code> elements
(and must at a minimum support the relevant DOM attribute).</p>
> Second, this removes the ability of a UA implementor to implement
> type-ahead find as a more reliable (since some authors will specify
> accesskeys and some won't) and quicker (especially if the number of
> items in the menu is large) way of selecting an item with the
> keyboard.
I don't understand how.
> And third, this inhibits UAs from following platform
> interface conventions; for example, while some Mac OS programs use
> accesskeys for buttons, checkboxes, and radiobuttons, doing so for
> menus is very non-standard behavior (I think I have only seen one
> program ever do so).
Presumably the new wording solves this.
> > The accesskey attribute on label elements must act the same way as
> > they would have if specified on the associated element directly.
>
> 15. * "they would have" --> "it would"
Fixed.
> > disabled
> >
> > The disabled attribute applies to all form controls except the
> > output element, as well as the fieldset element.
>
> 16. This could be interpreted as meaning that the disabled atribute
> applies to <fieldset>, *or* that the disabled attribute does not
> apply to <fieldset>.
> * "as well as" --> "and also to"
Fixed.
> > maxlength
> > ...
> > Authors are encouraged to only use maxlength on uri and email
> > fields if the server side processor actually has a limit on the
> > size of data fields it can usefully process.
>
> 17. "Only use maxlength" implies "use maxlength and no other
> attributes", which is not what you mean.
> * "only use maxlength on uri and email fields if" -->
> "use maxlength on uri and email fields only if"
Fixed.
> > The ERROR_TOO_LONG code is used when this attribute is specified on
> > a text, password, uri, email or textarea control and the control
> > has more than the specified number of characters, or when it is
> > specifies on a file control and at least one of the selected files
> > is longer than the specified number of bytes.
>
> 18. * "specifies" --> "specified"
Fixed.
> > readonly
> > ...
> > Specifically, it does not apply to radio buttons, check boxes, file
> > upload fields, range controls, select elements, or any of the
> > button types; the interface concept of "readonly" values does not
> > apply to button-like interfaces.
>
> 19. "Checkbox"/"checkboxes" and "check box"/"check boxes" are used
> seemingly at random throughout the spec (sometimes both in the same
> sentence). Pick one spelling and stick to it. (I don't remember
> seeing "check box" previously, but maybe I hang out with the wrong
> people.)
Changed to "checkbox" throughout. "Check box" makes sense -- it's a box
that you check! :-P
> > 2.6. The pattern attribute
> > ...
> > For example, the following snippet:
> > <label> Part number:
> > <input pattern="[0-9][A-Z]{3}" name="part"
> > title="The expected format is: a digit followed by three
> > uppercase letters."/>
> > </label>
> >
> > ...could cause the UA to display an alert such as:
> >
> > The expected format is: a digit followed by three uppercase
> > letters.
>
> 20. I dread the thought of any author reading the spec (or reading a
> tutorial written by someone who has read the spec, etc) and thinking
> that "The expected format is:" should be standard text for their
> title=s!
> * "The expected format is:" --> "A part number is"
Fixed.
> 21. It should be clarified that UAs may still show the title= in
> non-error situations (for example, as a tooltip when hovering over
> the control), so a title= should not be worded as if an error has
> necessarily occurred.
Added:
<p>UAs may still show the <code>title</code> in non-error situations
(for example, as a tooltip when hovering over the control), so
authors should be careful not to word <code>title</code>s as if an
error has necessarily occurred.</p>
> > 2.8. The form attribute
> > ...
> > The form attribute gives a space-separated list of IDs of form elements that
> > the form control is to be associated with, and overrides the relationship
> > between the form control and any ancestor form element.
> >
> > Any of the IDs in the space separated list that do not identify an element
> > in the document, or that identify an element that is not an HTML form
> > element, must be ignored.
>
> 22. Pick "space-separated" or "space separated", and stick to it. (I
> find the former less ambiguous.)
Changed one occurance of "space separated" to not be space-separated.
> > 2.8. The form attribute
> > ...
> > In other words, form controls must be associated with the forms given in
> > their form attribute, or, if they don't have one, must be associated with
> > the nearest ancestor form element or the forms given in the form attribute
> > of the nearest fieldset element with a form, whichever is the nearest. If
> > none of those apply, the form control is not associated with any form.
>
> 23. * "element with a form" --> "element with a form attribute"
Fixed.
> 24. I had a go at making this paragraph less brain-frazzling.
> * "In other words, a form control belongs to the form or forms
> given by its form attribute. If it doesn't have a form
> attribute, it belongs to its nearest ancestor form element, or
> to the form or forms given by the form attribute of its nearest
> ancestor fieldset, whichever is the nearer ancestor. If the
> control doesn't have such an ancestor either, it belongs to no
> form at all."
I'm not sure it's much better. Left it as is for now.
> > If a form is specified multiple times in the form attribute, all occurances
> > but the first are ignored.
>
> 25. * "occurances" --> "occurrences"
Three fixed.
> > 2.10. The autofocus attribute
> > ...
> > When a form control is inserted into a document, the UA must check to see
> > if it has this attribute set. If it does, and if the control is not
> > disabled, then the UA should focus the control, as if the control's focus()
> > method was invoked.
>
> 26. What if the control is of a type that is not normally focusable on
> the user's platform? For example, in OS X with "Full Keyboard
> Access" turned off (as it is by default), only text fields (aka
> <input type="text/password/date/time/etc"> and <textarea>) and
> listboxes (aka <select multiple>) should be focused.
> * "If it does, and if the control is not disabled," -->
> "If it does, the control is not disabled, and it is of a type
> normally focusable in the user's operating environment,"
> * Perhaps further: "UAs with a viewport should also scroll the
> document enough to make the control visible, even if it is not
> of a type normally focusable."
Ok.
> > (When multiple elements are simultaneously inserted into the document,
> > they must all perform this, in document order.)
> > This implies that during document load, the last form control with
> > this attribute set is the one that will have focus once the document
> > is loaded. ... Authors should only mark one (non-disabled) control per
> > document with the autofocus attribute.
>
> 27. All the sentences about multiple autofocused controls should be
> together in their own paragraph.
> * "Authors should avoid setting the autofocus attribute on
> multiple elements in a document. If multiple non-disabled
> elements with the autofocus attribute set *are* inserted into a
> document, the UA should focus them sequentially in document
> order. This means that during document load, for example, the
> last form control with the attribute set will end up with
> focus."
> * If accepting suggestion 26 above, "last form control" --> "last
> focusable form control".
I didn't take your text literally but did move the three things you
mentioned into one reworded paragraph.
> > The value of the attribute, if set, should be autofocus.
>
> 28. "autofocus" here is linked to the attribute definition, which is
> wrong, because you are referring here to the value rather than to
> the attribute itself.
Over-enthusiastic cross-referencing by the postprocessor I mentioned.
Fixed.
> > 2.13. The output element
> > ...
> > Note the em element in the markup. It emphasises a part of the number.
>
> 29. Why is this notable? It doesn't seem at all relevant.
Clarified.
> > 2.14. Extensions to the textarea element
> >
> > The rows and cols attributes of the textarea element are no longer
> > required attributes. When unspecified, CSS-compliant browsers should
> > lay the element out as specified by CSS, and non-CSS UAs may use
> > UA-specific defaults, such as, for visual UAs, using the width of the
> > display device and a height suitable for the device.
>
> 30. As I said previously
> (<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-
> July/001005.html> item 41), this appears to
> recommend that UAs default textareas to being too wide to view
> without scrolling (especially if there is something horizontally
> adjacent to the textarea). If there is a way to remove this
> implication without suggesting CSS support, please do so.
I tried to change it a bit. I don't know if it's much better:
<p>The <code>rows</code> and <code>cols</code> attributes of the
<code>textarea</code> element are no longer required attributes.
When unspecified, CSS-compliant browsers should lay the element out
as specified by CSS, and non-CSS UAs may use UA-specific defaults,
such as, for visual UAs, using the available width on the page and a
height suitable for the device.</p>
> > hard
> > The text is submitted with explicit line breaks, and in addition,
> > line breaks added to wrap the text at the width given by the cols
> > attribute.
>
> 31. * Either "line breaks added" --> "line breaks are added", or
> "and in addition, line breaks" --> "and also with line breaks"
Fixed.
> > 2.15. Extensions to file upload controls
> > ...
> > There is currently no way to specify an unlimited number of files may be
> > uploaded. Authors are encouraged to consider what the practical limit
> > actually is for their server-side script. For example, if the server uses an
> > unsigned 16 bit integer to track file uploads, a suitable max value would
> > be 65536.
>
> 32. Ehhhh. Why not just allow the value "any", as is done for step=?
Because it would only make sense for file uploads and I didn't want the
added complexity just for this one edge case. (Let's face it, there'll
always be a maximum here.)
> > This is similar to straight-forward Web logging, or diary writing, but
> > instead of submitting textual entries, one submits sound bites.
>
> 33. "Web logging"? Some old-fashioned newspapers refer to them as "Web
> logs", but they're much more commonly "Weblogs". (See also
> <http://en.wikipedia.org/w/index.php?title=Talk%3AWeblog&diff=1399541&oldid=1283187>.)
They're most commonly referred to as "blogs". "Weblog" seems weird to me.
> > For textarea elements containing tags in HTML
> > The tags should be parsed as character data, but entities and
> > comments should be recognised and handled correctly. (This doesn't
> > apply to XHTML.)
>
> 34. Why not?
Because we can't change XML parsing rules.
> > For option elements containing nodes other than text nodes
> > ...
> > How such markup should be rendered is undefined. Two possibilities
> > are sensible: rendering the content normally, just as it would have
> > been outside the form control; and rendering the initial value
> > only, with the rest of the content not displayed (unless forced to
> > appear through some CSS).
>
> 35. What does "initial value" mean? Does it mean "content preceding the
> first non-text node"?
It means the value in the defaultValue DOM attribute. The term is
originally from HTML4. Sentence above clarified a little.
> > While nesting a form inside a select control may look cool, it is
> > extremely poor UI and must not be encouraged.
>
> 36. Offering a demo of it and saying it "may look cool" is perhaps not
> the worst *possible* way of not encouraging it, but it's close. Post
> it in your Weblog or something if you must, but it doesn't really
> belong in a spec.
Bo-rrriiiing. I commented out that paragraph for now.
> > 3.1. Introduction for authors
> > ...
> > In order to distinguish this row from a normal row, however, something
> > needs to be added to the template to mark it as being a template. This is
> > done using a repeat attribute:
> > <tr id="order" repeat="template" >
> > <td><input type="text" name="row[order].product" value=""></td>
> > <td><input type="text" name="row[order].quantity" value="1"></td>
> > </tr>
> >
> > To prevent an attribute from being processed in this way,
>
> 37. This note should be immediately after the description of the process
> (i.e. before "In order to..."), otherwise "this way" is confusing.
Ok.
> 38. * "an attribute" --> "a name or id attribute"
No, it really is any attribute.
> > put a non-breaking zero-width space character () at the
> > start of the attribute.
>
> 39. * "attribute" --> "attribute value"
Ok.
> > The second way is by including an add button inside the template, so
> > that when the template is replicated, the button is replicated into
> > the resulting block. When such a button is pressed, the template is
> > replicated, and inserted immediately before the block in which the
> > button is found. For example, if there were add buttons in the rows of
> > the example above, and someone pressed the button in the second row, a
> > row would be inserted between the first row and the second row.
>
> 40. If the template is inserted before the block in which the button
> is found, then the button itself (like the rest of its block) will
> (in left-to-right text) move downward and/or rightward. This usually
> won't matter mousewise, because a newly-created add button usually
> will appear exactly where the just-clicked one was; but it will
> still look odd in those environments where buttons are focusable --
> because focus will appear to have jumped, as a result of a click, to
> something that is nevertheless not under the cursor. If adding
> several blocks consecutively, there may be more annoying effects for
> accessibility aids, since the mouse is repeatedly encountering
> newly-created buttons with identical text, rather than continuously
> hovering over the same button.
>
> Therefore, it would be better for the template to be inserted after
> the block instead.
Then you have no way of inserting something at the top.
> > 3.2.2. Repetition blocks
> > ...
> > Repetition blocks that don't have an associated template are termed orphan
> > repetition blocks. They can take part in the deletion and movement aspects
> > of the repetition model, but not addition..
>
> 41. * "termed" --> "" (or why not "nouned"?)
-> "called".
> * "addition.." --> "in addition."
Fixed, along with some strange markup errors there. I wonder if I
accidentally deleted something at some point here. I sure hope not.
> 42. I propose that "move"
> <http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-
> August/001634.html> be introduced now, instead of "move-up" and
> "move-down".
I'm sorry, but "move" is simply WAY too complicated. A real implementation
would want to do cool things like sliding elements in and out of the way
as you drag the other element above it, would need to support both
keyboard- and mouse- driven interaction, would need to implement all kinds
of funky things in the rendering engine (e.g. how to handle a drag when
the elements in question are in a 0.5 opacity block rotated 47 degrees and
passed through three SVG filters), and so forth.
I agree it's a good idea. I disagree that it is simple. The move-up and
move-down buttons are extremely easy to implement in comparison, and I
feel much more confident that UAs will be able to implement them
correctly. Before something of the complexity of 'move' is implemented, we
need to be sure that the entire repetition model is worth further time
investment -- at the moment, while I believe it is indeed fulfilling a
market need, it is definitely a debated point.
> > When these new types are used with input buttons, the value attribute
> > shall, if present, provide the button caption (although this may be
> > further overridden by the stylesheet).
>
> 43. * "However, a user agent may ignore this attribute so as to render
> buttons consistent with those performing equivalent functions in
> the user's operating environment. For this reason, if nesting
> repetition blocks, authors should position such buttons
> carefully to make clear which block a button applies to."
>
> That way, add and remove buttons can have their familiar rounded (+)
> and (-) appearances on Mac OS X (probably using value+title combined
> as a tooltip), while still having text captions on platforms where
> add and remove buttons are less common.
Ok.
> > 3.4. The repeat-min and repeat-max attributes
> > ...
> > These two attributes have no effect on the repetition model when present on
> > elements that do not have a repeat attribute with the value set to template.
>
> 44. "template" here is linked to the attribute definition, which is
> wrong, because you are referring not to that attribute but to a
> value of a different attribute.
Fixed.
> > 3.7.1. Repeated rows
> >
> > The following example shows how to use repetition templates to dynamically
> > add more rows to a form in a table.
>
> 45. Grating redundancy.
> * "add more" --> "add"
Ok.
> > 5. Form submission
> > ...
> > 1. Step one: Dispatch the submit event.
>
> 46. * "event." --> "event"
Fixed. Incidentally, the markup in this section suggests to me that Web
Apps is going to need to do something to HTML to handle this better. And
suggestions?
> > 5.2. Handling characters outside the submission character set
> > ...
> > ____________________________________________________
> > || Warning |||||||||||||||||||||||||||||||||||||||||||
> > | |
> > | This form cannot handle some of the characters you |
> > | have entered (including "?" and "?"). |
>
> 47. * '"?"). |' --> '"?"). |'
Heh. Fixed.
> > 5.3. application/x-www-form-urlencoded
> > ...
> > 3. The values of file upload controls are the names (excluding path
> > information) of the files selected by the user, *not* their
> > contents.
>
> 48. In section 2.15, an accept= attribute is introduced for <input
> type="file">, especially (but not solely) for "small devices that do
> not have file systems and for which the only way of handling file
> upload is to generate the content on the fly". What should such
> devices use as a name for such a non-existent file?
Clarified.
> > 4. Control names and values are escaped. Space characters are replaced
> > by "+" (U+002B), and then non-alphanumeric characters are encoded
> > in the submission character encoding and each resulting byte is
> > replaced by "%HH", a percent sign (U+0025) and two uppercase
> > hexadecimal digits representing the value of the byte.
>
> 49. Should this be written the other way around? This way round, space
> characters and "+" characters will end up as the same "%HH" entity.
I did s/then/other/.
> > 7.7. Validation APIs
> > ...
> > * The control does not have a repetition templates as an ancestor.
>
> 50. * "templates" --> "template"
Fixed.
> > 7.9. Additions specific to the HTMLInputElement interface
> > ...
> > Two new methods, stepUp() and stepDown(), enable authors to write code that
> > increases and decreases (respectively) the value of the control in integral
> > increments of the given step value. The argument specifies the number of
> > steps by which to increase or decrease the value. If the control's value is
> > invalid or empty, then the methods shall raise an INVALID_STATE_ERR
> > exception. If a particular invocation of the method would invalidate the
> > value (for example, if stepUp(1) is called when the control's value is less
> > than step from max), then the method shall raise an INVALID_MODIFICATION_ERR
> > exception. If the argument passed is zero, then the method shall raise an
> > INDEX_SIZE_ERR exception.
>
> 51. What if step="any"?
Fixed.
> > A. XHTML module definition
> > ...
> > Warning. XML documents using the new repetition model with the index
> > substitution feature on ID attributes cannot validate, as the "[" and "]"
> > characters are not valid in IDs in XML.
>
> 52. This warning is a non-verbatim repetition of the note at the end of
> section 3. Is this intentional, should they have the same text, or
> should one of them be removed?
It's intentional.
> > C. Deprecated features
> > ...
> > Documents must not use deprecated features. User agents should support
> > deprecated features.
>
> 53. In the HTML world, something that authors *must* not use, and which
> UAs might not implement, is not "deprecated"; it is "obsolete".
> <http://www.w3.org/TR/REC-html40/conform.html#deprecated>
Having read the definitions of "deprecated" and "obsolete" to which you
refer, and having looked at the W3C guidelines for specification editors,
I feel that "deprecated" is correct here.
> > D. Requirements for declaring interoperability
>
> 54. The sections listed in this section should be hyperlinked.
Yeah, that would be nice.
> > [CSJSR]
> > Client-Side JavaScript Reference (1.3). Netscape Communications
> > Corporation, May 1999. The Client-Side JavaScript Reference (1.3)
> > is available at
> > http://devedge.netscape.com/library/manuals/2000/javascript/1.3/
> > reference/index.html
>
> 55. <http://devedge.netscape.com/library/manuals/2000/javascript/1.3/
> reference/index.html> has been unavailable throughout the period I was
> reviewing this spec. Perhaps
> <http://web.archive.org/web/20040202050531/http://devedge.netscape.com/
> library/manuals/2000/javascript/1.3/reference/> would be a better reference.
devedge goes up and down. I'm following that situation and will update the
link as appropriate at some future point.
> 56. The raw URIs in the JavaScript 1.3 reference, the RFC references,
> and the XBL reference should all be hyperlinked.
The links already point to them. It would be silly to have the same link
twice, and would just look busy.
Thanks,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 7 January 2005 06:47:30 UTC