[whatwg] some issues

[Ian Hickson]

On Mon, 5 Jul 2004, [iso-8859-1] C Williams wrote:
>
> Browsing the specification, some random thoughts occured to me. I've
> outlined them below. They're pretty ephemeral, and very much based on
> 'first impressions'. Some are concerned with a more immediate 'PR'
> angle, but no doubt I'll have more to say when I've understoof the
> ramifications of the work in more detail.

Thanks for your feedback!


> 1.) The Slashdot quote mentioned as representative of demand in
> [1.Introduction] asks for a feature deliberately stated as not being
> considered in [1.5. Missing features] (grid / spreadsheet editing). This
> kind of inconsistency does not help present a coherent argument.

Removed the quote.


> 2.) You really should change the stylesheet and 'Working Draft' image.
> Attempting to look identical to the W3C specifications:
>
> i.) Makes the effort appear lacking in formal design ideas / skills of
> its own.
>
> ii.) Casts the effort as either cynically manipulative (hoping to
> deceive people into thinking that it's a genuine W3C spec) OR
> desperately aspirational (little boy dressing in father's clothes).
> Don't be afraid to look like the outfit that you are. If the W3C (or any
> other standards body) ever adopted the spec as a standard, reformatting
> it to their look-and-feel is a trivial issue for a later time.
>
> iii.) Gives the appearance of laziness.
>
> iv.) Possibly puts you on dubious legal ground.

The stylesheet isn't actually the W3C stylesheet, there are a number of
differences. The only real similarities are the font and colour of the
headers, and the colour and placement of the background image.

I changed the colours and made the headers slightly different.

I don't want to make too many changes because frankly, the W3C stylesheet
is very good for specs.


> 3.)"This specification clarifies and extends the semantics put
> forth in [HTML4] for form controls and form submission."
> [1.1. Relationship to HTML]
> "some of the features added in this module only apply to XHTML
> documents"
> [1.2. Relationship to XHTML]
>
> Can you actually say this, in the legal sense?
>
> The W3C Document License
> [http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231]
> under which the specifications are released, states:
> "No right to create modifications or derivatives of W3C
> documents is granted pursuant to this license."

This isn't a modification or derivative of the document, it's a
modification and derivative of the semantics set out in that document.


> The W3C Intellectual Rights Notice and Legal Disclaimers
> [http://www.w3.org/Consortium/Legal/2002/ipr-notice-20021231]
> states:
> "No material may be modified, edited or *taken out of context*
> such that its use creates a false or misleading statement or
> impression as to the positions, statements or actions of W3C."

Again, the material is untouched, only the semantics are affected.


> Sure, there's grey area there, but I'm not *certain*, legally, that
> you're allowed to even purport to extend their specs* in any way. Note
> that I'm talking about the language used, not the idea.

Frankly if this really was illegal, then we'd have much bigger problems on
our hands than WHATWG is attempting to address.


> 4.) Where are the DTD's / Schemas?
>
> HTML and XHTML are *tightly specified* by SGML / XML boundaries.
> Where are yours?

Nowhere, yet. Personally I think DTDs and Schemas are a waste of time. For
one, they catch only a tiny fraction of authoring errors (there is no way
to express most of the conformance criteria in HTML and Web Forms 2 with
DTDs and Schemas).

What I do think is useful is syntax checking. In XML, that's free (you get
XML well-formedness checking in all compliant XML parsers). In HTML, we
could do with a DTD that did basic syntax checking.

However, I believe fantasai has volunteered to write some DTDs for Web
Forms 2.0 at some point anyway.


> i.) [1.6. Conformance requirements]
> "Documents that use the new features described in this
> specification using XHTML or other XML languages over HTTP must
> be served using an XML MIME type such as application/xml or
> application/xhtml+xml and must not be served as text/html.
> [RFC3023] Documents served in this way *may contain a DOCTYPE if
> desired, but this is not required*."
>
> Please see both [http://www.w3.org/TR/xhtml1/#strict] and
> [http://www.w3.org/TR/xhtml11/conformance.html#strict],
> specifically note [4] in both cases:
> "*There must be a DOCTYPE declaration in the document* prior to
> the root element. The public identifier included in the DOCTYPE
> declaration must reference ... "
> *Extending* a specification is one thing; rearranging it for no
> apparent reason is something else.

XHTML's requirement makes no sense. Why would an XML document need a
DOCTYPE? The DOCTYPE is required in SGML to say what the content should be
handled as, but in XML the DTD is useless, and namespaces fulfill that
role instead.

This is by far not the only requirement that makes no sense in XHTML1.


> ii.) [2. Extensions to form control elements]
> "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 is not allowed by any of the W3C specs. Moreover, what's the point,
> if the element has to be empty? Considering the allowance of a control's
> attribute to specify the parent form (a good idea IMO), surely forward
> declarations at the beginning of the body element are adequate (bearing
> in mind that you're allowing empty form elements and they should take up
> no space), and previous-specification-legal?

This is to aid transititon to XForms, which puts metadata about the form
into the head of the document.


> This brings us round to the mime-type / namespace pollution issue. Is it
> really right for you to allow documents of this extended type to be
> served as text/html, application/xml or application/xhtml+xml? They're
> clearly NOT.

For text/html, whether it is technically good or not is largely
irrelevant. This work will only be useful to authors if they can use
text/html. So, for better or worse, we're stuck with that.

For the XML MIME types, RFC3023 basically says they are all equivalent, so
it doesn't make much difference either way.


> Why not specify your own DTDs/Schemas - as Jim Ley has suggested - ones
> which borrow everything from the previous W3C specifcations, and adjust
> them to your new ideas, serving them as another mime-type?

It wouldn't make any difference. The important thing is the namespace. If
a UA comes across an element in the XHTML namespace, it doesn't matter
what MIME type it was sent as, or even if it was sent as one at all. That
element will have its semantics.


> Alternatively; a possibly superior method:
> Submit *all* these proposals as HTML 4.1 or 5.

Yeah, on the long run this will almost certainly be what happens. (The FPI
proposed in the spec hints towards this already.)


> Get them *all* ready, and submit them *all* as an extension to HTML,
> dropping the XML component. This avoids the mime-type and namespace
> pollution issues completely.

In practice UAs handle nodes in XML's XHTML namespace identically to nodes
in text/html documents, so they can't really be split.


> 5.) Extraneous waffle (I'm aware of the irony ... ) and Bad
> Specificationese(TM).
>
> The spec contains numerous sections which do not belong there. Sections
> such as [1.5. Missing features] and others have no business in a
> specification. Specifications are supposed to be predominantly
> normative. Implementors of UAs and client programmers don't want to know
> every thought which occurred in the production of the specification.
> They only want to know what's *there*: Just the facts. I understand the
> desire to explain the reasoning through which certain design decisions
> have been made, not least to head off repeated questions on the mailing
> list. However; this should be confined to a document entitled
> 'Rationale' or 'Justification' which is linked to from the spec and
> provides annotated clarification.

I disagree; it is quite common for specifications to have entire chapters
introducing rationale, and I think it goes a long way towards making the
specification more approachable.


> Some the grammar and punctuation in the document is dubious to say the
> least. I notice fantasai put a lot of work in, and his/her edits are
> undoubtedly improvements, but not all have been implemented. It's not
> that anything's terrible, per se; but it comes across as informal and
> slightly ill-deserving of attention. This is a self-defeating trope: It
> encourages that the ideas contained be dismissed.

If you have specific cases you think are wrong, let me know. In general
the "readable" prose (as opposed to the "specalese" prose) is a direct
response to requests I've had to make specs more readable. Several people
have commented that this makes it easier for them to understand what the
spec says, so I'm not convinced that it causes people to dismiss the spec.

In particular, the CSS spec (which is quite colloquial in places) is often
favourably compared to the XML spec (which is so technical as to be
unreadable for most people).


> Some examples (there are lots more of them):
>
> i.)
> [1.6. Conformance requirements]
> "Documents that use the new features described..."
>
> This is just bad english. It should be "Documents *which*
> use..."

I was taught the opposite, actually:

   "The apple that fell from the tree was rotten."
   "The apple, which fell from the tree, was rotten."


> or, even better, "Documents using ...".

That sounds wrong to me.


> Also: 'new' is extraneous here. It's a *new* specification - the
> contents are *new* by definition.

No, some of the features described in WF2 are clarifications of stuff in
HTML4, and do not use any new syntax and so don't need new DTDs.


> ii.)
> [2.16. Handling unexpected elements and values]
> "Note: It should be noted that while nesting a form inside a
> select control may look cool, it is extremely poor UI and must
> not be encouraged."
>
> Firstly; what is "look cool" doing in a general-purpose, global
> specification?

It's there so that the entire sentence can be immediately quoted to
someone in terms they understand, but with the weight of being a normative
quote. Numerous times I've had conversations like this:

   A: Hey look at this! Isn't it cool!
   B: Yes, very good, but as the spec says:
      "Conformant documents SHOULD NOT contain elements with the
      local name "option" and the XHTML namespace whose descendent
      subtree includes elements with the local name "form" and the XHTML
      namespace."
   A: Say what?

Now compare:

   A: Hey look at this! Isn't it cool!
   B: Yes, very good, but as the spec says:
      "Note: It should be noted that while nesting a form inside a
      select control may look cool, it is extremely poor UI and must
      not be encouraged."
   A: Oh ok.


> Secondly; if you expand the sentence it becomes: "it is extremely poor
> user interface and must not be encouraged". I think you see the problem.

The phrase "poor UI" is well-established in the industry.


> iii.)
> [3. The repetition model for repeating form controls]
> "Creating such a library is left as an exercise to the reader."
>
> Firstly; this has absolutely no business being there.

Why not?


> Secondly; it's terribly phrased. If, for some reason, you felt it
> absolutely had to stay in, "... as an exercise *for* the reader" would
> be better.

Oops.



> Many of the ideas contained in the specification are useful, practical,
> good ideas, but they'll never see the light of day unless you get
> everything right. I'm aware that the working document announced that you
> wished to begin shipping product before Christmas but I feel that, in
> order to be taken seriously, this just is not feasible. Leaking these
> specs and UAs as and when they are ready, in small segments, does nobody
> any good.

I highly doubt that colloquial wording will have any effect on the
popularity of the spec. Readability is, IMHO, very important.


Thanks again for your feedback!

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'