On Mar 3, 2006, at 7:11 AM, ROBO Design wrote:
...
<[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
...
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/
