Material-design-lite: Textfield label overlaps if input has placeholder

[Garbee]

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="[email protected]" 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]

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]

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

The input is for email in the upper left corner.

[Garbee]

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]

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]

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]

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]

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]

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. :frowning:

[sgomes]

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

[surma]

Yes

[Mikdadali]

same issue for me

[Mikdadali]

[sgomes]

@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]

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]

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

[sgomes]

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]

@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]

i am using label inplace of placeholder

On 4 March 2016 at 19:28, David Maciejewski [email protected]
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
https://github.com/google/material-design-lite/issues/243#issuecomment-192293063
.

_Regards,_
_MikdadAli Momin_
_FrontEndDeveloper_

_Sent from my Moto X play_

[sgomes]

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]

@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]

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

[sgomes]

@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]

@sgomes Sounds perfect!

[Mikdadali]

yes

On 4 March 2016 at 20:52, David Maciejewski [email protected]
wrote:

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

—
Reply to this email directly or view it on GitHub
https://github.com/google/material-design-lite/issues/243#issuecomment-192319295
.

_Regards,_
_MikdadAli Momin_
_FrontEndDeveloper_

_Sent from my Moto X play_

[sgomes]

This is now fixed and released in 1.1.2.

[JavaGalaxy]

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]

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]

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