Re: Styling composite elements

So, we are assuming that lots of authors are idiots and will make crappy websites, and so we should restrict everyone else?

The Internet is already full of crappy websites. When using screen readers - 90% of websites are awful. If we just did away with CSS and went back to Times New Roman, black text and blue underlined links, that problem would go away.

To me, this is a ridiculous argument. It's like saying people can't use paint because they might make a mess. Or they can't have a pen in case they write something people can't read.

We should be providing the right tools, for everyone. Everything is abusable, and everything requires skill. We should encourage good behaviour by simple implementation, easy to read documentation and education, not act like user experience police, or belittling those authors for whom the documentation is too complicated.

My comment stands. Where CSS fails to provide authors the ability to style elements on a page, it has failed as a technology. The argument seems to be that browser vendors know best and we should not give authors the tools they need to satisfy their own requirements, which would be a very restrictive world. If we do not let authors do this, they fake the controls, with exactly the result you are describing - but worse!

If the problem were really terrible, a semantically implemented <select> allows for user stylesheets that override it. A faked control, does not.

Right now, and for years, people have been asking how to make their <select> pretty, on-brand and consistent:

http://stackoverflow.com/questions/11342146/how-to-make-beatiful-select-lists
http://stackoverflow.com/questions/11208302/select-box-with-just-the-css-styling-similar-to-jquery-ui-button
http://stackoverflow.com/questions/1895476/how-to-style-a-select-dropdown-with-css-only-without-javascript
http://doctype.com/style-select
http://stackoverflow.com/questions/4656580/how-do-i-style-a-select-box-with-gradients

And right now, people are downloading and implementing things like:

http://www.bulgaria-web-developers.com/projects/javascript/selectbox/
http://jamielottering.github.com/DropKick/
http://harvesthq.github.com/chosen/
http://www.queness.com/post/204/25-jquery-plugins-that-enhance-and-beautify-html-form-elements
http://wellstyled.com/en/javascript-styleselect-jquery-plugin/

…These are not exposed to AT properly, do not have proper label/field associations, do not have appropriate keyboard controls, or other problems…

By not providing a standardised supported method to achieve this, we are already realising what you are trying to avoid.

AK

On 20 Feb 2013, at 22:20, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Feb 20, 2013 at 1:56 PM, Antony Kennedy <antony@silversquid.com> wrote:
>> Of course, I've seen that.
>> 
>> So, where nothing was done, the <select> experience would be exactly as it is now.
>> 
>> With media queries, as an author I could then choose the experience I want my users to have. I could leave it as is, or make it as terrible or as wonderful as I choose.
> 
> What will actually happen is that a lot of people will use the new
> stuff, only test on their desktop machine, and then people using
> phones will just have a crappy experience.
> 
> We have to weigh author pro/cons against user pro/cons when designing
> new features, and something that is almost certain to result in a
> crappy experience for a decent fraction of users is generally
> undesirable.
> 
> ~TJ
> 

Received on Wednesday, 20 February 2013 22:50:41 UTC