[WICD] comments

Hello CDF WG,

Here are some comments on the three WICD drafts of Dec 19:


* WICD Core
  http://www.w3.org/TR/2005/WD-WICD-20051219


1) 2 Root Document Format

I think WICD should allow HTML as root document.

It seems it would be very useful and no extra effort to support HTML as 
root document in addition to XHTML1. HTML has the same semantics as 
XHTML1, is better supported on the Web and is (in my opinion) easier to 
write.


2) 3 Scalable Child Elements

I think the most common presentation of "scalable child elements" is not 
to fit the screen, but to be shown inline in an HTML (or in this case: 
WICD) document. Even if they are shown on their own, a typical computer 
will show them in a window, not full-screen.


3) 3.2.1 Scalable Foreground Child Elements

XHTML also has an IMG element. Is it expected that IMG elements work the 
same as OBJECT elements (apart from parameter attributes, obviously)? 
Or is that undefined?


4) 3.2.1.1 Still-image Rendering

What is the default value for the "render" parameter?


5) 3.2.2 Scalable Background Image

The text says that the order of the values becomes significant when the 
'background' shorthand property is used. That's not true. (The order of 
the position values may be significant, but that is already the case in 
the 'background-position' property.)


6) Ditto

The background area of an element doesn't have to be a rectangle. An 
inline element or an element at a page break may consist of several 
boxes. CSS3 will have properties to control how a background is split 
or repeated over such boxes, but until those are ready, the behavior is 
undefined.

WICD should probably also say that those cases are undefined.


7) Ditto

CSS3 will have properties to allow background images to scale to the 
size of an element (or to any other size). Which is, I believe, 
compatible with the idea in this draft that the intrinsic size of a 
"scalable background image" without an explicit size is magically the 
same as the size of the element. (Apart from issue 6 above, of course.)

But it seems that the definition of the intrinsic size belongs in CSS, 
not in WICD, because that's also where the size of scalable 
*foreground* images is defined.


8) 4 Other Child Element Formats

"Any audio or video format supported by the device": Do you mean UA 
instead of device? My device is capable of many formats, but I would 
have to install the right software first...


9) 7.2 Font Naming

"There are typically less fonts available": less -> fewer


10) 8.1 Content Encoding

Must WICD UAs support gzipped content even if the protocol isn't HTTP? 
On a typical local file system, e.g., it is not possible to indicate 
the type of a compressed file. The file has one type ("gzipped data"), 
unlike in HTTP, where it has both a type ("text/html") and an encoding 
("gzip").


11) 9 Synchronization support

Why does WICD deal with synchronization? Isn't that what SMIL is for?


12) 9.2 Timeline initialization

a) Changing the document on the fly in order to animate its display 
seems rather a strange thing to do. It is not unlike the self-modifying 
programs that were popular before structured programming. What is the 
document after you change it? Will it be different if you save it at 
different points in time? Will it still match its digital signature?

For the intended effect, it is also inefficient in execution time and 
illogical for the programmer.

I think what the programmer is looking for is simply a pair of 
functions/methods called start() and stop().

b) But, in fact, I think that WICD documents should not contain programs 
at all (except as transclusions). The D stands for Document, doesn't 
it? One of the biggest advantages of a document over a program is that 
the knowledge it contains is declarative and explicit. (Important for 
the Semantic Web!). Also, documents are poor user interfaces.

So, I think changing the "timeline" parameter should have no effect and 
the definition of programs should be left to the WAF and WebAPI WGs 
instead.



* WICD Full
  http://www.w3.org/TR/2005/WD-WICDFull-20051219/


1) For me, a much more useful format would have:
   - HTML
   - MathML
   - Java
in addition to the formats mentioned, and would not have
   - ECMAScript.

HTML and Java are, in fact, already widely available. MathML not yet, 
but efforts are underway and some extra push would be very useful, in 
view of its importance for the Semantic Web.


2) 3.1 Identification

A type like "text/xhtml+xml; profile=WICD" would be easier to 
understand, easier to remember, shorter, would not look like a URL and 
would not need quote marks. A parameter like that would also be 
case-insensitive, like the rest of the MIME type.

Please, don't use URLs unless as machine-readable addresses of data. 
Using them for other purposes makes their meaning fuzzy and thus more 
difficult to process automatically.

Also, WICD is a text/* type, not application/*. The most useful fallback 
for a UA is to show it, not to save it to disk. That's why it has a 
charset parameter.

(RFC 2045 indeed says that compound documents should have a top-level 
type of application, but WICD isn't a compound document in the sense of 
RFC 2045, because the non-text content is transcluded, not part of the 
same file.)



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Saturday, 28 January 2006 21:31:52 UTC