[whatwg] 2.20.2 The command element - icon attribute

[ROBO Design]

Le Thu, 02 Mar 2006 17:03:43 +0200, Matthew Paul Thomas  
<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
>
> 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 wasn't subscribing to those opinions. I was just saying some people  
complain. In my personal opinion WHATWG is on a very good path with WA 1.0  
and WF 2.0 because they both represent the strong needs of todays rapidly  
evolving web applications (such as, but not limited to: sliders, progress  
bars, TCP/IP connections, server-side DOM events, canvas, standardized XML  
HTTP request, etc).

Yet, regarding the icon attribute, I do believe it's not needed. <div>,  
<span>, <i>, <b> and all the tags that "made it" into WA 1.0 are  
repurposed. Also, I agree a spec shouldn't be too semantical, there must  
be some balance.

Icon attribute is not a legacy attribute, it's not something Ian *must*  
have into the spec. He can leave it out, or make a section in the WA 1.0  
which presents the CSS 3 "Web Applications" module. There he could go and  
add all the things required for styling progress bars, menus, commands,  
etc.

>> (I've read some "WHATWG bashing" in some blog posts).
>
> That's not a useful comment. What did they say?

I wouldn't like this thread to become a "fight" over this, nor over  
something else. Next :).

>
>> Defining icons and other presentational endeavours must definitely be  
>> left to CSS WG.
>
> Why?

Or... do as I said above: CSS 3 module. Therefore Ian wouldn't have to  
wait for CSS WG.

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

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.

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

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.

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

Leave open doors for ugly hacks or not?

It's also not only about web designers. We all know the majority of  
clients have very annoying and naive requirements. High on the list is ...  
design requirements. Then ... the designer will be forced to do some hacks  
(or not ... ).

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

Ignoring the attempts, IMHO, would be very good. This ain't gonna work,  
anyway.

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

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

I'd have to disagree somehow over this. The difference is not purely  
presentational. Yes, the difference is *also* presentational, but it's  
also a "metaphorical" difference. I won't go into details (it's beyond the  
purpose of the thread).

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

True. I myself don't like scrollbar colors being changed just because the  
designer of the site wanted so. It's annoying.

You either: agree, embrace or disagree with diversity.

My simple point of the entire thread is just: don't add the icon  
attribute. Leave this to a CSS spec by CSS WG, or ... add new CSS  
properties in the WA 1.0 spec.

CSS 3 UI (which is already a CR) contains the content:icon and icon:url()  
properties:
http://www.w3.org/TR/css3-ui/#element


-- 
http://www.robodesign.ro
ROBO Design - We bring you the future