Re: Styling composite elements

Whilst I agree absolutely with your sentiment and hierarchy, I disagree with this use case.

CSS and <select> have existed for longer than Android or iOS. We should not encourage bad user experiences, but we should not preclude the ability to create great ones, or stand in the way of the inventiveness and creativity that many in our industry possess.

Using security as an example, where restrictions are imposed to stop the authors from doing bad things (which isn't about incompetency, but about malice) there is usually a workaround for those with altruistic intent.

We offer no alternative here, so authors invent their own. If we had the ability to style these, it would not "duplicating the terribleness of the existing workarounds" - it would be much better. At the very least, the controls would be exposed properly, and semantically, and browsers (and us) would have the opportunity to display them in another way. I don't disagree that it could be untested, but I fail to see how this could be worse than the status quo.

We would not remove eval() from JS to stop authors writing bad code; it would result in an incomplete language that would stop people who know the right uses of it from using it in that manner.

We now allow anchors to surround block level elements in HTML, and multiple H1s - and abuse of these are rife. But we shouldn't remove these capabilities, because they should exist for HTML to be complete and consistent.

I still think this is a failure of CSS. Can we not come up with solutions, rather than just assuming that if authors can give a <select> a blue border and an image for the arrow some people will have a bad experience? What if I want the text to wrap to two lines for example? Or if this is a requirement from the business and my objections fall on deaf ears? I am given no option but to implement the worst option possible, because no alternative exists.

AK

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

> On Wed, Feb 20, 2013 at 2:50 PM, Antony Kennedy <antony@silversquid.com> wrote:
>> So, we are assuming that lots of authors are idiots and will make crappy
>> websites, and so we should restrict everyone else?
> 
> No, we are assuming (correctly, given a long and consistent history)
> that most authors don't test their pages on multiple devices (or even
> multiple browsers on the same device).
> 
> Please don't try and cast this as an insult.  It's just a truth of
> human behavior, verified through lots of experience.  If we ignore
> this, we'll design bad things.
> 
> This does mean that sometimes we don't allow authors to do certain
> types of things.  This is similar to security issues - because a tiny
> number of authors are malicious, we sometimes have to restrict anyone
> from doing useful things that can be abused.  Because security is very
> hard and most authors get any non-trivial security wrong, we sometimes
> have to restrict things *even if* a method to secure it exists.
> 
> Users are more important than authors.  Protecting their experience is
> more important than giving authors new tools.  Simple fact of life -
> there are lots more users than there are authors.
> 
> (For explanation, the "hierarchy of constituencies" that we generally
> abide by is: technical purity < spec authors < implementors < authors
> < users.  A large benefit to one group can override a small downside
> to a higher group, but generally higher groups trump lower groups.  We
> violate this hierarchy sometimes, but as a rule we stick to it.)
> 
>> 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/
> 
> Yes, I'm quite aware of the workarounds that exist today - I was a
> professional webdev before I moved to full-time standards.  They are
> indeed terrible.  That doesn't make our job any easier, though - just
> duplicating the terribleness of the existing workarounds doesn't bring
> much benefit.
> 
> ~TJ

Received on Wednesday, 20 February 2013 23:22:54 UTC