yes

is a pain but doing without it was extremely complex and wouldn't even work with advanced use cases (like radio/checkbox lists, …)

Personally I like this approach. It seems more semantically correct & clear, as opposed to mixing labels, inputs from different parts of the form.

And <fieldset> sounds like it's meant exactly for this use case. Same for using <legend>, according to mozilla docs it is meant to be used as the caption for <fieldset>s.

is float: right that's why it must be put before the fields (side note: I think it's also good for screen readers/disabled users…)

Do you think some developers might have issues w/ this? It seems easy to screw up.

do you think it would be better to remove the custom class

and replace it with alerts (since it's what is used behind the scenes):

If form-help is just a shortcut for alert alert-info then I don't see an issue w/ keeping it. I think most forms won't necessarily need to display success/errors, and if the styling is the same as alerts (so no extra work needs to be done to display an alert in the same place/way), then it's easy/convenient for both use cases.

Regarding styling <select>, I believe Morpheus uses a library for styling checkboxes, perhaps something similar exists for <select>s? If it is to be done, probably better to do in another PR, though.

looks otherwise good to me

Here is a quick feedback: looking the screenshot above (https://cloud.githubusercontent.com/assets/720328/7744667/99e2e468-ffa5-11e4-811f-c4962540a27e.png) from a usability point of view, there is not enough contrast for the inline help. Solution: either we make the Inline text Grey color darker (or alternatively: Make the background grey lighter). More contrast will make inline help easy to read.

@mattab I agree but this is the alert style, we can change it separately (because I think it would be good to apply that change for alerts too, not just form help)

@diosmosis I will try using fieldset and legend then!

Regarding "float: right" and "It seems easy to screw up" that's true, but we can immediately see that the help is positioned below the field in that case. I'll give another try at placing the help after the input in the HTML and see how that turns out.

Regarding styling , I believe Morpheus uses a library for styling checkboxes, perhaps something similar exists for s? If it is to be done, probably better to do in another PR, though.

Agreed this PR will already be quite extensive.

I have tried using fieldset and legend tags and it was a complete fail from an accessibility point of view. See this answer: http://stackoverflow.com/a/7042529/245552

Some screen readers assume that field sets will only be used that way and are optimized for that use case, causing the screen reader to announce the legend on every single input in the list

I haven't reproduced that particular behavior (I guess all screen readers are different) but I tried 2 screen readers and the fieldset behaves as a group encapsulating its content, it becomes hard to tab or navigate inside them (i.e. it adds a lot of steps to be able to fill the form). Additionally replacing labels with legends makes them non-clickable because not associated to the inputs anymore. Additionally with the screen reader legend≠label so inputs would have no description anymore…

All in all I think fieldsets are not a good option. Even for radios and checkboxes I found the user experience worse when using a screen reader (but maybe that's because I'm not used to it). I suggest to keep using <div class="form-group"> and labels.

Regarding help blocks I tried to put it after the fields (inputs, radios, …) in the HTML layout but it requires some complicated Less/CSS and it messes up a lot of things (because we have to make the inputs float:left, which is a mess when there are several radios/checkboxes with labels). I don't think it's worth it, keeping it simple and logical is good (a float element should always be put before the item on which we want to align). And if by mistake we put the help after the input it's quite easy to understand what's wrong (visually it's explicit). Also the good thing with the current solution is that when using a screen reader the help is read before reaching the input, which is much better.

Ok, I withdraw my comments about <fieldset>/<label> and the float:right.

@mnapoli Is this ready to merge? If so, can you remove the WIP label? I can look again and merge if it looks good. I'll also create a follow up issue for the notification contrast.

Not 100% finished, I want to move all the forms to the new design. I also need to review all the UI tests to make sure there is no regression. I'll ping you when it's done ;)

Looking forward to the new forms applied consistently 👍

   I haven't styled the <select> tags like in the mockups because on some browsers (e.g. Chrome) it's not possible: we would have to use hacks and recreate a select using HTML/CSS

Is there another solution to style tags in Chrome or do you think it looks acceptable not to style them?

Oh I think we should try as much as we can (because else it doesn't look good at all), even maybe use fake selects (if it doesn't mess up too much the tests). But I think it's even possible on Chrome with CSS only, it's just that it requires a more work because when you disable the default appearance you loose everything (e.g. the arrow) so you have to recreate the style from scratch. Anyway I need to research more into that, but in the meantime I think it shouldn't block that (which blocks the user/site manager).

I've given a try to styling selects and it worked (for Chrome, Safari and Firefox, need to test on IE):

The end result shouldn't be too complex CSS so I'll add it to this pull request.

Edit: for IE the custom style doesn't apply.

@mattab thanks I have fixed those UI regressions (one was appearing only on Firefox). What's left is check every UI screenshot diff (lots of them because of small changes everywhere) + test using different browsers

Ok great 👍 merging (it will make it into the next beta)

I didn't check the screenshot diffs neither with different browsers did you? There were a lot of changed screenshots and I was stuck yesterday by the UI tests failing because of the segmentation faults

they were broken, I thought about it but then wanted us to move forward with design changes. Hopefully we can solve the UI tests issue. (not sure if it is #8034 or a new one)

yes they were broken, but this PR has been merged without being tested (at least by me) that's what I'm saying (was still WIP). I'm going to test on master then