Foundation-sites: CSS & JS: Floating Labels!

Created on 13 Jan 2017  ·  16Comments  ·  Source: foundation/foundation-sites

Motivation: http://bradfrost.com/blog/post/float-label-pattern/

Float Label Pros

  • User keeps context–The main advantage of this pattern is that the user keeps the field’s context after they’ve focused and entered a value. This provides for a more accessible, less frustrating experience.
  • Clean and scannable by default–This pattern allows for a clean inline label experience by default, and only becomes a little more cluttered once the user has filled things out.
  • Elegent–It needs to be said: this pattern is sexy. You usually can’t say that about forms. It looks good and the animations are a nice subtle touch.

Past Implementations: Google's Material Design

Demo: https://codepen.io/IamManchanda/pen/oBLexK

Demo Source: Braddy Sammon's codepen ( forked )


Update: Updated codepen as requested by @ncoden
http://codepen.io/IamManchanda/pen/zNBPwP

Source: John wilson's codepen ( forked )

building blocks component request forms

Most helpful comment

You definitely should consider this library: https://github.com/tonystar/float-label-css!

Bulletproof CSS-only implementation of Float Label pattern with automatic fallback for ANY non-supporting browser.

I will be happy to help with integration!

All 16 comments

This is a good idea. However, I do not think we should implement it in the same way as in the CodePen you provided.

We can see on the bradfrost's post that the label is not _visually moved_, but _visually showed_ while a placeholder is hidden. I prefer this animation: it is less distracting and the label do not cross the input border.

Preview of floating labels

I think placeholders should also be used to maintain good accessibility. I would also like a version that is pure CSS. Any ideas if this is possibly by using :focus, :valid and :invalid selectors?

@DaSchTour We have to know if the input is empty (when the placeholder is not shown) or not to show/hide the label. So it requires some Js.

Had some research and here's what i found .... might help us in the developmental phase

@ncoden => http://codepen.io/IamManchanda/pen/zNBPwP
@DaSchTour => https://codepen.io/tonystar/pen/JRLaKw

http://caniuse.com/#feat=css-placeholder-shown

http://caniuse.com/#feat=css-placeholder-shown

Nicolas Even me also not in favour of css only version at this time!
( i knew that already thats its not fully supportive)

Although works with prefix in latest browsers => http://css4.rocks/selectors-level-4/placeholder-pseudo-class.php
But still i dont think we are ready for this !

Your Thoughts @DaSchTour ??

There's a few pure CSS implementations out there, for example:
http://codepen.io/atunnecliffe/pen/gpKzQw

Most rely on input/label pair elements being wrapped in a container element, and for the label element to follow the input element so as to make use of the sibling selector.

Looking at Foundation's documentation, components like Abide, seem to use a:

<label>Name
<input />
</label>

pattern - not sure how this would be affected?

But a definite +1 👍 from me for this pattern.

@paulfelton #AbidePattern
http://jsfiddle.net/RyanWalters/z9ymd852/

{{ If i am understanding you correctly }}

3 questions:

  1. Does it make sense to have a pure css version depending on a rigid structure, with a JS-based fallback for more varied structural options?

  2. Does this make sense as a part of the core framework or an independently installable plugin?

  3. Are there other form patterns that make sense to wrap up with this, perhaps as a set of related form helpers?

1.) I will go with a JS-based fallback for more varied structural options!

2.) Yes it totally makes sense for being the part of the core framework as this is a pattern, a structure and not a plugin and also,

  • User keeps context–The main advantage of this pattern is that the user keeps the field’s context after they’ve focused and entered a value. This provides for a more accessible, less frustrating experience.
  • Clean and scannable by default–This pattern allows for a clean inline label experience by default, and only becomes a little more cluttered once the user has filled things out.
  • Elegent–It needs to be said: this pattern is sexy. You usually can’t say that about forms. It looks good and the animations are a nice subtle touch.

@kball just to point 2. I think foundation unlike other CSS frameworks already is made in a way, that only modules can be used and this is one of the best parts about foundation. So I think, that this could be part of foundation-sites but not activated/included by default.

@IamManchanda I've updated my comment to show the 'abide pattern'.
While pure css would be preferred, and looks possible in the future, if JS is needed to provide cross-browser support, and to not tie to a rigid HTML structure, then that seems reasonable.

One of the advantages of foundation is it's pretty clean - I wouldn't want to change that, so whether it's core/module/building block is probably for others to consider (I'm new here :-)).

The pattern is a strong one but won't be appropriate in every form scenario. It lends itself to shorter forms pretty well, and mobile too, login screens, etc,

You definitely should consider this library: https://github.com/tonystar/float-label-css!

Bulletproof CSS-only implementation of Float Label pattern with automatic fallback for ANY non-supporting browser.

I will be happy to help with integration!

I will be happy to help with integration!

@tonystar - Good deed needs no permission!

https://akrabat.com/the-beginners-guide-to-contributing-to-a-github-project/

Does this make sense as a part of the core framework or an independently installable plugin?
-- Commented by @kball

Just to point 2. I think foundation unlike other CSS frameworks already is made in a way, that only modules can be used and this is one of the best parts about foundation. So I think, that this could be part of foundation-sites but not activated/included by default.
-- Commented by @DaSchTour

One of the advantages of foundation is it's pretty clean - I wouldn't want to change that, so whether it's core/module/building block is probably for others to consider (I'm new here :-)). The pattern is a strong one but won't be appropriate in every form scenario. It lends itself to shorter forms pretty well, and mobile too, login screens, etc,
-- Commented by @paulfelton

Poke @kball - With new building blocks out ... please take a decision on this ?
Shall i forward this to building blocks ??

I think this (and many more form patterns like it) belong as building blocks. :)

Was this page helpful?
0 / 5 - 0 ratings