Re: Cougar comments

On Fri, 9 May 1997, Brian Kelly wrote:

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

LINK defines a relationship between an HTML document and another
resource, the type of which is not restricted to HTML. I appreciate
your reservations, but note that WD-style is the result of lengthy
discussions constrained by the need for backwards compatibility with
existing deployed practise.

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

CSS allows you to specify selectors which only apply in the context
of a particular ancestor element, have a look at the CSS1 spec for
details.

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

The name was chosen by the group working on I18N and has been
generally accepted for a long time (in Web terms).

> (c) versus DIV - if one uses SPAN within P and DIV outside P to do
> the same thing then we are in real doo-doo!! 

Can you please provide an example of the problems that occur.

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

I will discuss this with my colleagues to gauge their reactions
to this proposal.

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

Other people have argued the same way. This is not something the
HTML working group has clearly settled at this time.

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

Note that the spec defines Cougar as using Unicode as the base
character set. The symbol entities are defined in terms of the
corresponding Unicode values. This still leaves browsers free to
use the Adobe Symbol font if they chose, but the browser is then
responsible for selecting the appropriate glyphs based upon the
entity names or Unicode values.

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

The precise names for the entities is still under discussion and
we are working to ensure they are harmonized with proposals by
other groups including the W3C Math working group.

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

I think your assumption is too strong. In any case W3C is
priviledged to have the help of world leading experts in this area.
We will do our best to make this part of Cougar clearer.

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

It is likely that this will be supported via the style sheet as the
HTML working group would prefer to avoid new presentation markup. 
We are planning on providing a strict version of the Cougar DTD for
those people who wish to avoid any presentation tags or attributes. 

Thanks for your comments,

-- Dave Raggett <dsr@w3.org> tel: +1 (617) 258 5741 fax: +1 (617) 258 5999
   World Wide Web Consortium, 545 Technology Square, Cambridge, MA 02139
   url = http://www.w3.org/People/Raggett

Received on Friday, 9 May 1997 15:32:17 UTC