W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: missing principle

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 27 Apr 2007 02:59:35 -0700
Message-Id: <EA67A1B9-0DFF-4EA8-8765-30E378FB35B4@apple.com>
Cc: "public-html@w3.org" <public-html@w3.org>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>

On Apr 27, 2007, at 2:33 AM, Daniel Glazman wrote:

> Maciej Stachowiak wrote:
>> Apple has many non-browser uses of HTML, including a mail client.  
>> So I agree with the sentiment and I'd be glad to add such a thing.  
>> Do you have a suggested phrasing?
> I'll work on it.
>> Personally, though, I'd like to hear what new presentational  
>> elements are needed. Do you have a proposed list?
> No, I don't need new elements. I just wanted to say the existing  
> minimal
> set, deprecated or not in the HTML4 dtd, is good to keep.
> b, i, u. pre is ugly but so simple and widely used it shouldn't be
> touched. sup and sub.

You'll be glad to bear that b, i, pre, sup and sub are in there in  
the HTML4 draft, mostly with semi-semantic fig leafs for their meaning.

u is not there. I guess the HTML5-official way of representing it  
would be <font style="text-decoration: underline">, which is a bit  
wordy, and in the mail context could be problematic for  
interoperation with non-CSS mail readers. On the other hand,  
underline is used much less often than bold or italic, has little  
proper use in typeset text, and is disrecommended in html content for  
anything but a hyperlink, since it may confuse users. So I would not  
miss u as much as b and i.

> I'm not far from thinking the align attribute is a good thing.

Not there - do you have a use case?

> semanticless elements div and span are immensely important.

span and div are also there.

> On another hand, big and small are bad, because handling nested
> big or small elements is painful in an editor.

big is dropped, but small is added, representing the semantic of  
"small print (part of a document often describing legal restrictions,  
such as copyrights or other disadvantages), or other side comments",  
which seem useful.

>> Personally, I think <font> restricted to use by WYSYWIG editors  
>> (note, <font> doesn't have to be just a font setting, it is for  
>> any purely presentational application of additional style) is  
>> probably sufficient for most needs, but I could be missing something.
> font is cool but font is really painful and harmful. Setting font  
> sizes
> through font seems to me a danger for interoperability.

It's mainly intended as a presentational element to hang a style  
attribute on, as an escape hatch for WYSIWYG editors.

Received on Friday, 27 April 2007 09:59:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:19 UTC