On Mar 2, 2006, at 9:21 AM, ROBO Design wrote:
...
I'd highly recommend not to define the icon attribute, or any other
attribute with possible relation to presentation. This fuels
accusations that what this specification defines is not "as semantical
as" the XHTML 2 specification
If that's true -- and it's hard to tell, because the XHTML 2 draft is
so wordy -- then HTML 5 is probably on the right track. (Even then, as
I described in January, a few parts of the Web Apps draft are almost
certainly too semantic for most HTML authors to follow.
<http://64.233.179.104/search?q=cache:hPXm-qGuZjEJ:
listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-January/
005431.html>)
(I've read some "WHATWG bashing" in some blog posts).
That's not a useful comment. What did they say?
Defining icons and other presentational endeavours must definitely be
left to CSS WG.
Why?
Lets take the icon. Designers would immediately want to define the
positioning of the icon: top, right, bottom, left - in pixels,
percents, etc - similar to background position.
And UA vendors would be free to ignore such attempts on platforms for
which such customized positioning would not make sense. Which is, all
of them.
Then they'll "hack" into the DOM to change the icon on hover, and do
some more.
That would be unfortunate, and it would be nice if UA vendors ignored
attempts to do that too, though not as important.
All this stuff must be defined by the CSS WG.
Why?
The WA 1.0 "loosely" defines the icon attribute. That's not an
attribute of a semantical value, it's for a pure presentational
purpose.
The difference between <select> and <input type="radio"> ... <input
type="radio"> is purely presentational. The difference between <select
multiple> and <input type="checkbox"> ... <input type="checkbox"> is
purely presentational. The difference between <input type="text"> and
<input type="password"> is purely presentational. That doesn't mean
they shouldn't all exist.
If Ian Hickson really wants to define the icon attribute in the spec,
then he should go further and offer complete customization over the
way the icon is rendered.
Why? Native menu implementations don't.
Or should the icon render as normal icons render in the default chrome
of the user agent (most likely of the OS)?
Naturally.
If that's the case, designers won't be happy either (neither myself,
being a designer too). We always like to do different designs.
...
Then do what native application developers do in the same situation,
when they want to be gratuitously inconsistent with the rest of the
platform: implement your own menu controls. That will be more difficult
than using <command>, of course, which is good because it means authors
will be more likely to use <command> instead.
--
Matthew Paul Thomas
http://mpt.net.nz/
