Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Textfield label overlaps if input has placeholder #243

Closed
Garbee opened this issue Apr 24, 2015 · 28 comments
Closed

Textfield label overlaps if input has placeholder #243

Garbee opened this issue Apr 24, 2015 · 28 comments

Comments

@Garbee
Copy link
Collaborator

Garbee commented Apr 24, 2015

The textfield (at least with a single-line) doesn't look right at all if you give the input a placeholder.

For example:

<div class="mdl-textfield mdl-js-textfield">
            <input class="mdl-textfield__input" type="email" id="email" name="email" placeholder="you@example.com" required>
            <label class="mdl-textfield__label" for="email">Email:</label>
        </div>

This provides a display where the placeholder overlaps the label making both unreadable. Placeholders are pretty common when you are expecting a specific format within a text area to show a user how to enter something. While pattern matching and such do work, placeholders are effective in portraying what is requested ahead of time.

Anything we can do here considering the spec on Text Fields makes no mention of placeholders?

@addyosmani
Copy link
Contributor

We can ask UX for their opinion here. Would it be possible to include a screenshot along with this question so I can help them visualise what we're talking about?

@Garbee
Copy link
Collaborator Author

Garbee commented Apr 25, 2015

Oh whoops, yea I forgot the screenshot thanks for asking!

The input is for email in the upper left corner.

selection_016

@Garbee
Copy link
Collaborator Author

Garbee commented May 6, 2015

So in the meeting the MD guy (Sorry, didn't catch his name) mentioned something about hiding the placeholder until active to get around the label mash-up. That is entirely possible since we can target the placeholder and have it display none right off, then as the input becomes active during the label transition set the display again so it will show. Finally on user input the browser will auto-hide the placeholder.

This solution is doable, but seems kinda-sorta hacky and then makes the placeholder not quite as useful as it otherwise would be.

@surma
Copy link
Contributor

surma commented May 6, 2015

I disagree. It feels very natural/material-y to me to have the placeholder fade in as the label slides up. Would you mind doing a quick'n'dirty version to see what it looks/feels like?

@Garbee
Copy link
Collaborator Author

Garbee commented May 6, 2015

Yea, I'll do a mockup.

However, I feel the placeholder's should be view-able for as much time as possible before input. Especially for odd form entries where people may be referencing the placeholder to find needed information. Having them display on active state only before input is counter to that key reason for placeholders existence.

@surma
Copy link
Contributor

surma commented May 6, 2015

Thank you, @Garbee!

I do see your point, but I somehow feel like our label is taking over part of the placeholder’s purpose due to the way it is positioned on the text field itself. In any case, Zach’s proposal is better than what we have right now and he just came up with that on the spot. That’s why I’d like to give it a go.

@Garbee
Copy link
Collaborator Author

Garbee commented May 6, 2015

Yea, well worth seeing at least. If anything it is a good start until the Material Design team goes back over inputs and hopefully addresses the issue in some way.

@Garbee
Copy link
Collaborator Author

Garbee commented May 7, 2015

Oh, and I'll be working on the demo of this placeholder trick in the morning. Just got pulled into digging through a lot of crbug issues for this evening. 😦

@sgomes
Copy link
Contributor

sgomes commented Jun 24, 2015

@surma A fix for this has been merged, right?

@surma
Copy link
Contributor

surma commented Jun 24, 2015

Yes

@surma surma closed this as completed Jun 24, 2015
@Mikdadali
Copy link

same issue for me

@Mikdadali
Copy link

2016-01-28_182032

@sgomes
Copy link
Contributor

sgomes commented Jan 28, 2016

@RootCrashed This specific bug has already been fixed, so if you're seeing this in the latest version (1.0.6), please try to reproduce it in a codepen so that we can analyse it, and open a new bug if needed. Thanks!

@StefanoSega
Copy link

Still reproducible in v.1.1.1 with e.g. this code:

<div class="mdl-textfield mdl-js-textfield search-textfield">
<input class="mdl-textfield__input" id="txtSearch" type="text">
<label class="mdl-textfield__label" for="txtSearch">Search for ...</label>
</div>

@surma
Copy link
Contributor

surma commented Mar 2, 2016

Confirmed: https://codepen.io/surma/pen/JXdEqe

@surma surma reopened this Mar 2, 2016
@sgomes
Copy link
Contributor

sgomes commented Mar 4, 2016

I can definitely see the issue with your codepen, @surma, but I don't understand what the use-case is for defining both a label and a placeholder on the input? What would be the expected behaviour?

@macx
Copy link

macx commented Mar 4, 2016

@sgomes I have the same in a actual project. For the floating labels I'm using the title (e.g. "Date of Publishing") and for the Placeholder I'm using an example date to show users the right formatting.

@Mikdadali
Copy link

i am using label inplace of placeholder

On 4 March 2016 at 19:28, David Maciejewski notifications@github.com
wrote:

@sgomes https://github.com/sgomes I have the same in a actual project.
For the floating labels I'm using the title (e.g. "Date of Publishing") and
for the Placeholder I'm using an example date to show users the right
formatting.


Reply to this email directly or view it on GitHub
#243 (comment)
.

Regards,
MikdadAli Momin
FrontEndDeveloper

Sent from my Moto X play

@sgomes
Copy link
Contributor

sgomes commented Mar 4, 2016

Ah, that makes sense, thanks @macx! How were you expecting this to be displayed when you first tried it out? Were you expecting the label to be at the top?

@macx
Copy link

macx commented Mar 4, 2016

@sgomes I would expect the label at the top (at the floating labels). Because it's the same behavior as the users input text (filled in textfield).

@sgomes
Copy link
Contributor

sgomes commented Mar 4, 2016

Yup, that sounds reasonable. Let me take a stab at this and see if it's doable.

@sgomes
Copy link
Contributor

sgomes commented Mar 4, 2016

@macx I think the best we can do is:

  • If you're using a floating label, automatically move it to the top if there's a placeholder. This matches what happens when the user types something.
  • If you're not using a floating label, hide it. This also matches what happens when the user types something.

How does that sound?

@macx
Copy link

macx commented Mar 4, 2016

@sgomes Sounds perfect!

sgomes added a commit that referenced this issue Mar 4, 2016
Make labels interact better with placeholders in textfields. Fixes #243.
@Mikdadali
Copy link

yes

On 4 March 2016 at 20:52, David Maciejewski notifications@github.com
wrote:

@sgomes https://github.com/sgomes Sounds perfect!


Reply to this email directly or view it on GitHub
#243 (comment)
.

Regards,
MikdadAli Momin
FrontEndDeveloper

Sent from my Moto X play

@sgomes
Copy link
Contributor

sgomes commented Mar 7, 2016

This is now fixed and released in 1.1.2.

@sgomes sgomes closed this as completed Mar 7, 2016
@JavaGalaxy
Copy link

Hi I am also facing the same issue.
I am using MDB Free 4.2.0. and 1.1.2 version of material design lite.

@Danbardo
Copy link

This was still a problem for me using 1.3.0.

To fix it I just deleted the labels .mdl-textfield__label on document ready. Seeing as it was only a problem on the login page, it wasn't a big deal.

@nhducseuit
Copy link

Using 1.3.0 for now.
My guess is this problem was caused by Chrome as this SO question points out
https://stackoverflow.com/questions/35049555/chrome-autofill-autocomplete-no-value-for-password

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants