Le Thu, 02 Mar 2006 17:03:43 +0200, Matthew Paul Thomas
<[EMAIL PROTECTED]> 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
