Comments on: On the styling of forms

By: Chris Lienert

Chris Lienert — Mon, 18 Feb 2013 08:24:46 +0000

Styling form fields has always been a mine field and the new HTML5 fields and CSS selectors haven’t exactly improved the situation.

I use a “safe” subset of HTML5 fields with minimal styling albeit hooked into my custom JS validation library which does the dirty work.

It’s no surprise third party script libraries are used for such things given the inherent complexities involved. The wild and wandering variety of form stylings seem evidence enough that what’s in place isn’t working very well.

By: Richard Sexton

Richard Sexton — Fri, 01 Feb 2013 04:53:47 +0000

http://rs79.vrx.net/interests/computers/sw/if/shadow-dom/

By: Barney

Barney — Thu, 31 Jan 2013 16:15:04 +0000

I couldn’t submit this form when I entered ‘barneycarroll.com’ as my ‘Website’. The feedback was: ‘Please enter a URL’.

Peter Winnberg hits the crucial nail on the head which is that validation is far too simplistically defined and implemented. While WebForms were an awesome idea at the time, we’re now accustomed to JS to do this work. As you say, it’s `novalidate` or no usability depending on the capricious whims of eager browser devs ATM.

Extensible Shadow DOM is the way forward for widgets, ultimately. We love the idea of universal accessibility but we don’t want to be at the mercy of `::-webkit-scrollbar-top-left-curve-when-overflowed`.

Paul Irish hints [1] a bit at this kind of thing: in many ways the community at large has implemented its own standards that are just far too sophisticated compared to the wishy-washy, obsolete-before-release attempts at advanced native forms UX proposed in HTML5.

[1] https://github.com/h5bp/lazyweb-requests/issues/92

By: Patrick H. Lauke

Patrick H. Lauke — Thu, 31 Jan 2013 08:15:48 +0000

I love the implications in David Goss’ comment. All the fancy “built-in, not bolt-on” functionality of baked-in form validation, audio/video element, etc were intended to be the default, and then feature-detect and fall back on JS solutions…but now it seems that in many cases, the opposite is happening: use your more customisable JS thing first, and fall back on the natively supported (but limited) elements instead. Brave new world…

By: David Goss

David Goss — Thu, 24 Jan 2013 12:54:32 +0000

With the exception of buttons, I don’t try to do very much styling to form elements. IMO they should still resemble the operating system controls fairly closely so that users are immediately familiar with them and don’t how to stop and figure out how to use them.

The problem with wanting to style things like input[type=range] and input[type=date] is that you can’t be sure what kind of control will be rendered – I think the spec contains suggestions about this, rather than instructions.

If you decide, for instance, that you want some input that would require an input[type=range] but you want to do a fancy custom control with JS for it, you can still use the input[type=range] as an accessible default, then use JS to hide it on page load and update it whenever your custom control is updated.

The nice thing about having the new input types and attributes is that they double up as hooks for your JavaScript fallback – the required and pattern attributes in particular are great for this.

By: Constantine

Constantine — Wed, 23 Jan 2013 21:58:51 +0000

@Charlie my point is “styling of forms ? whatever, forms are obsolete”.
If you need something simple and accessible (and developed fast) – you can still use all the classic stuff: HTML 4 Forms + CSS up to lvl3, but if you want to get anything more advanced – you will need to go with JS. If your user don’t have JS – they are useless. Either they are penny-less trafic-eaters who never buy anything, or they are crappy old bots (fyi: Google and Bing bots can parse JS, at ES5 level).

___
Why i compare css to assembler ?
Because the are no variables, no scoping, no functions,
because in order to position a block – you need to position couple of other blocks so they move the target one,
because nobody uses css without some compiler/preprocessor in any big project for years already,
because working with sprites is royal mess,
because css is unfriendly both to designer (who would like visual tools) and to programmers (who want a real language),
because nobody wants to write css nowadays.

Yet, it’s simple, and good enough for its job. As all the pretty sites we see are made with ugly css.