[whatwg] 2.20.2 The command element - icon attribute

Matthew Paul Thomas mpt at myrealbox.com
Fri Mar 3 06:30:29 PST 2006


On Mar 3, 2006, at 7:11 AM, ROBO Design wrote:
> ...
> <mpt at myrealbox.com> a écrit:
>>
>> 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
>> ...
> I wasn't subscribing to those opinions. I was just saying some people 
> complain.

Then why mention them at all? That seems like dog-whistling.

> ...
> I was having a quite interesting talk with a guy. I could've called 
> him naive - he's not an expert in web development at all.
>
> He strongly disproves of not being able to style scrollbars, buttons 
> and more.
>
> People will always want to do so. Native rendering won't suffice. Some 
> designers hate seeing native buttons, inputs, selects and whatever.

And they can continue to implement and/or style controls, and pay the 
cost of having less usable sites, just as they do now; with the browser 
vendors saving the Web authors from themselves, to the extent the 
people using the browsers desire, just as they do now.

> If the specifications won't give them the proper ways to style them, 
> we'll see quite many annoying hacks of the future.

I think the sum (annoyance ✕ popularity) of those hacks will be less 
than the sum (annoyance ✕ popularity) of fully stylable menus would be. 
You think the reverse. I think that's the real disagreement here, and 
we can't prove it one way or the other.

> Developers are making the switch to CSS layouts, departing away from 
> table layouts. Now is the time for CSS to evolve and give them all the 
> power they want.

Non sequitur fallacy. Actually, two of them. First, that more people 
are using CSS does not necessarily mean CSS should "evolve and give 
them all the power they want". (Such a process would probably lead to 
something as unwieldy as XHTML 2.) Second, even if CSS should "evolve 
and give [developers] all the power they want", that would not 
necessarily mean that <command icon= should be part of CSS.

Do you have any specific reason for wanting <command icon= to be part 
of CSS? I'm not thoroughly opposed to the idea, it just seems very 
inconvenient. Most icons will be used for only one menu item, so the 
"you don't have to repeat yourself" argument for using CSS doesn't 
apply. In that respect it's quite similar to <object src=.

> I wouldn't personally like seeing a new menu for each web app, but 
> that's the way it goes.

Slippery slope fallacy. Currently, Web authors who want menus in HTML 
either (a) misuse <select> with script, or (b) implement their own with 
positioned elements and script. Introducing a third option, (c) use 
<command> and related elements, won't increase the proportion of Web 
developers using (b)! It certainly won't result in "each Web app" using 
(b).

> Leave open doors for ugly hacks or not?

False dilemma fallacy. There is no "or not": HTML 5 doesn't, and can't, 
prevent Web authors from continuing to use the ugly hacks they're 
already using (except to cry "non-conformant!" and let slip the dogs of 
validation). What it can, and does, do is offer better alternatives to 
those hacks.

> ...
> I almost can hear a web developer "ugh .... that's ugly!!!" (seeing 
> the menus natively rendered).

And he or she has to put up with such vomitous native controls in every 
menu and every dialog of Dreamweaver, too! The poor thing.

> ...
>> 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. <...>
>
> True. I myself don't like scrollbar colors being changed just because 
> the designer of the site wanted so. It's annoying.

So the anecdote of the naïve guy above was more dog-whistling?

> You either: agree, embrace or disagree with diversity.
> ...

I suspect that's another false dilemma, but to be honest I'm not even 
sure what you're saying. :-)

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/



More information about the whatwg mailing list