Cougar comments

I have been asked to foward the following comments on the Cougar draft to
this list by a colleague who is not on this list.

-------------------------------------------------------------------

I have read all the Cougar texts and i have the following comments:

1.  Use of LINK for style information:

The semantics of LINK have always been intended to provide additional 
information about hypertext links. There is no need to overload with 
style link information. The STYLE element can easily be extended with 
another attribute (type CONREF) to provide the name of a style 
source-file. This would be much cleaner.

2.  SPAN

(a) I see the value of SPAN, but I would expect that the formatting 
effects of SPAN in H1 to be different to SPAN in LI (say). Hence the 
style information should be able to be provided as attributes to the 
SPAN element, or the element name in the STYLE tag needs to allow 
fully qualified generic identifiers (eg: H1/SPAN ... or LI/SPAN ... )

(b) Also the name seems to infer 'spanning' of elements which clearly 
(if SGML integrity is to be maintained) is not true.

(c) versus DIV - if one uses SPAN within P and DIV outside P to do the 
samwe thing then we are in real doo-doo!! Hence to whole of 
'within-element' style control needs more thought.

3.  SCRIPT

SRC attribute should be type CONREF if it replaces the content of the 
element.

4.  IFRAME

I prefer use of EMBED/OBJECT with additional attributes - there is 
insufficient difference between the semantics of IFRAME and OBJECT to 
warrant a seperate element. Maybe, the desire to be able to amend 
margin sizes etc., should be fundamental to html., hence be able to be 
included in HEAD elements, and apply to all pages not just those 
embedded in other pages.

5.  Additional entities

(a) Don't use Symbol to get Greek! (I am having to do that at the 
moment with a site I am developing because I cannot guarentee that the 
reader will have a greek font installed, but it will lead to trouble, 
I am sure). ISO 10646 implementation is clearly the long-term answer, 
but in the meantime, fast switching between 8859 parts would be 
appreciated (rather than using huge collections of entities)

(b) Entity names must not clash with ISO TR 9573 names (parts 12-16), 
or convertion between HTML and other applications of SGML will be made 
very difficult.

6. Internationalization (i18n)

Inclusion of soft-hyphen - this will be very useful, but it opens the 
door to the general inclusion of language-dependent hyphenation rules. 
For example: I assume that a word that includes ­ can ONLY be 
hyphenated at ­, in which case a word that starts or ends with 
­ cannot be hyphenated at all. And, so it will go on!! The WD on 
i18n needs to cover language-depenedent hyphenation issues.

And finally, I repeat my plea for NOCRLF and BLANK attributes to HR 
for the reasons I have given you previously.

Feel free to distribute these comments wider (or to ask me for more 
explanation prior to distribution). Comments that have wider support 
may be listened to!!

--------------------------------------------------------------------

Brian Kelly

------------------------------------------------------
Brian Kelly, UK Web Focus
UKOLN, University of Bath, BATH, England, BA2 7AY
Email:  B.Kelly@ukoln.ac.uk     URL:    http://www.ukoln.ac.uk/
Phone:  01225 323943            FAX:   01225 826838

Received on Friday, 9 May 1997 06:55:59 UTC