[whatwg] some issues

Hi all,

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.

==========

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.

==========

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.

==========

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."

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."

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. Which leads to ...

==========

4.) Where are the DTD's / Schemas?

HTML and XHTML are *tightly specified* by SGML / XML boundaries.
Where are yours? This is a major issue considering that you are
contemplating introducing new tags and attributes. Not only
that, but you are contemplating taking liberties with previous
definitions and allowing arrangement of tags and attributes
which are proscribed by the W3C DTDs.
For example:

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.

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?
Again: it's a legitimate line of enquiry to try and extend the
specs IMO, but not to completely rearrange them to your suiting.

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.

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? This enterprise is going to require
enormous amounts of hackery just to get it to work anyway;
setting up a new mimetype in the browser to keep everything
well-boundarised is the least of your problems. Moreover, the
W3C DTDs fall under their software license, not their
documentation license: you're allowed to mess with them to
create your own markup - you're just not allowed to call it
HTML/XHTML (which this clearly isn't ...).

Alternatively; a possibly superior method: 
Submit *all* these proposals as HTML 4.1 or 5. That's what they
purport to be anyway. As it is, your timescale is based on
piecemeal development of the three proposed specifications, and
yet each relies on the others to a certain extent. No standards
body is going to ratify the individual segments which, in
isolation from the others, represent something of an incomplete
spec. 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.

My point here is that you aren't helping yourselves with the
current approach.

==========

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.

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.

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..." or, even better, "Documents using ...". Also: 'new' is
extraneous here. It's a *new* specification - the contents are
*new* by definition.

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?
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.

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

==========

I'm aware that the above sounds like a prime example of general
cynicism and malaise, but there is a purpose behind it. 

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.

At the moment, this working group has all the hallmarks of a
brand new rocket: Modern, based on pragmatism, derived from
existing technology, but unfortunately oriented towards a
mountainside. rather than towards space ...

regards,

C Williams


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com

Received on Monday, 5 July 2004 03:57:34 UTC