A few bugs with version v0.97.0

[gempain]

Hi,

Probably the most amazing css/js framework I have seen so far, so I thought you would appreciate some feedback about several issues I have found.

Setup

Materialize v0.97.0
Safari 8.0.6

Issues

1. When a date picker is applied to an input field inside a <div class="input-field"></div>, the placeholder should move up (respectively down) when the picker opens (respectively closes).
   

2. IMHO, even though it is not part of the range slider components of Google Material Design, Materialize should provide a double range slider.

   

3. Input error is misplaced when input has no value, most likely because of the placeholder . It only displays correctly when the placeholder slides up.

   Default

   

   Workaround

   placeholder=""
   

   Result

   

4. Long error messages will span over several lines and break the design.

   Default

   

   Workaround

   provided by @marci2020

   label[data-error]:after {
     white-space: nowrap;
   }
   

   Result

   

5. IMHO, when several inputs are stacked, inputs below are too close to the error message.

   Default:

   

   Workaround

   provided by @marci2020

   Adding "col" class to every element with "input-field" class and putting it into an element with class "row" (like done on Materialize form examples).

   <div class="row">
   <div class="input-field col s12">
       <input disabled value="I am not editable" id="disabled" type="text" class="validate">
       <label for="disabled">Disabled</label>
   </div>
   </div>
   

   Result

   `

6. Error messages (from data-error) are not displayed on inputs with the datepicker class.

   

7. Close a date picker, switch browser tab, come back to the previous tab and the picker reopens. Bug has been reported on Safari (8.0.6) and Chrome (43.0.2357.134).

Looking forward to reading you.

Cheers, and keep the amazing work !

[najmsheikh]

Oh my God I thought I was doing something wrong with the error label spanning over multiple lines. Thanks for not just reporting the bugs but also providing solutions to them!

[clementgpro]

Here is a hack to fix the third issue.
$('input:not([placeholder])').attr('placeholder','');

Waiting for those errors to be solved!

[gempain]

@najubhai You are very welcome :)

@Clemzd That will work nicely and it is probably a cleaner way to do it ! However, I try not to use JS when an HTML solution exists :)

Yep, can't wait for those issues to be fixed, especially that of the errors not displayed on date picker input fields.

[clementgpro]

@gempain Native HTML solutions are always the best! Except when the HTML code is already written =)

[gempain]

@Clemzd what do you mean ?

Except when the HTML code is already written =)

[clementgpro]

@gempain I was saying this hack is better than alterate the HTML code. I think that placeholder="" is not a good practise.

And oh my bad, this solution does not work anyway
This one works instead.

.input-field label {
    font-size: 0.8rem;
    -webkit-transform: translateY(-140%);
    -moz-transform: translateY(-140%);
    -ms-transform: translateY(-140%);
    -o-transform: translateY(-140%);
    transform: translateY(-140%);
}

[gempain]

@Clemzd I agree with you, using placeholder="" is not the cleanest solution, but memory wise more efficient than using JS :) But anyways, the last solution you provided is better, but after testing it I notice that it changes the input behavior: the slide-up effect on focus does not work anymore. The fix should be a bit more complex.

Assuming input is empty, you need to differentiate two states:

1. no focus:
   A. label follows default Materialize behavior
   B. data-error translated by 14% (as your solution suggests)
2. focus:
   A. label follows default Materialize behavior
   B. data-error falls back to default Materialize style

The solution should only modify 1.B.

[clementgpro]

Yes, you're 100% correct. I don't really need this effect that's why this fix is enough for me for now. I am using this framework at work for a project so I don't have lot of time to spend on fixing bugs.
I am waiting for better solutions to come! =)

[gempain]

Same thing here :) I don't have much time to work on fixing these bugs ^^ I hope they'll find a solution soon :)

[ghost]

For me width 100% does not fix the issue with the error messages mentioned in point 4.
What worked is white-space: nowrap.

label[data-error]:after {
white-space: nowrap;
}

[derixithy]

This fixes the input error for me somewhat, the only problem is it still displays an effect when giving the input focus.

.input-field input.invalid + label {
  width:100%
}
.input-field input.invalid:not(:focus) + label:after {
  font-size: 0.8rem;
  position: absolute;
  top: 40px;
}

[gempain]

@marcl2020 have you tried adding !important to the fix ? Not sure why it isn't working for you :/ Thanks for providing a fix :) I will try it at work today and update my initial post in case it works for me as well :) Which browser are you trying this on (so I can reproduce) ?

@derixithy I'll git it a try if I get some time at work today :) I might just try to find the right fix :)

Anyone has an idea on the date picker errors not showing ? That's the strangest one to me :/

[ghost]

@gempain no haven't tried adding it, going to check later if it works.

[gempain]

@marci2020 Your solution works for me ! I also noticed a bug cause by my solution: it breaks the width of input[type=search]. The corresponding label has a padding, therefore its outer width is 100% + padding, which exceeds the width of the div, creating an x scroll... So I'll change my solution to yours in my original post. Thanks for providing it !

[ghost]

@gempain point 5 can be solved by adding "col" class to every element with "input-field"
class and putting it into an element with class "row".

[gempain]

@marci2020 That works gracefully ! I'll update the list. However, I am not a fan of such solutions as I believe that it adds unnecessary tags to the page, that becomes unreadable, although I agree that your solution follows the philosophy of the Materialize framework :)

Actually, in my current pages, .input-fields elements all have the colclass, but not all of them are inside a row. This is intentional, though I know it is not "semantically" correct.

[ghost]

Error mentioned in point 7 also happens with Chrome

[gempain]

@marci2020 what is your Chrome version ? (so I can update correctly).

[ghost]

@gempain it's 43.0.2357.134

[gempain]

@marci2020 Thanks, updated :)

[ghost]

For point 6 check:
https://jsfiddle.net/1eek79qz/7/

The error message will get into place once a value is selected.

[gempain]

Not on Safari apparently :/

[iktakahiro]

My-Workaround:

.input-field label[data-error].active:after
  font-size: 0.8rem
  -webkit-transform: none
  -moz-transform: none
  -ms-transform: none
  -o-transform: none
  transform: none

.input-field label[data-error]:after
  font-size: 0.8rem
  white-space: nowrap
  -webkit-transform: translateY(-120%)
  -moz-transform: translateY(-120%)
  -ms-transform: translateY(-120%)
  -o-transform: translateY(-120%)
  transform: translateY(-120%)

form
  .row
    .col.s12
      margin-bottom: 15px

It seems that this issue is difficult.

[maxverro]

IMO, all these work around solutions are fine and do actually work. Although I would suggest a different approach. I use this framework within different .NET MVC application. Having a required Attribute is a common thing. Therefore, when returning a view, as mentioned before, if the input has no focus the data-error is misplaced. So here is what I suggest, we could use an extra markup to serve as the container for the validation error message. Basically, adding a span below the input to hold the text is a clean plain html solution and will most likely be more compatible with other web framework (ie MVC uses unobstructive JavaScript which normally display the error in a span below the field. The span will automatically fill 100% of the width and should use display:block.

People who download the source could easily modify the class name applied to the span to match their need (ie: Again, for a MVC user, the class name could be changed for the one used with unobstuctive JavaScript to match existing or custom JavaScript selectors.

Pseudo element are great in general. Although, I am not a great fan of the approach used to display validation errors.

[enmanuelr]

Some of these CSS workarounds work great, but generally apply to inputs. When using textareas, because they dynamically grow, I'm still getting an overall between the error message and the text area content.

[vlado]

For point 3 you can use $('input.invalid:not([placeholder])').attr('placeholder', '');. It will probably require Materialize.updateTextFields(); also.

[ben-sykes]

6 and 7 are still issues. Has there been any response from the creators?

Edit: Workaround for 7 (working in Chrome 52.0.2743.116).

For some reason (haven't dug that deep), but it still thinks the datepicker input is the active element on the page, so when the window regains focus, it displays the datepicker. (This can be proven out by interacting with anything else on the page, then switching tabs the same way as originally described by OP). Not sure if this is the most efficient way to handle this, but it works.

Just add the following to the onClose() option:

$('.datepicker').pickadate({
    onClose: function () {
        $(document.activeElement).blur();
    }
});

[ctytgat]

Is there any workaround/fix for issue6? (data-error with datepicker).
Still an issue with version 0.98.0 ...

[reynaldi2802]

issue number 6 just been fix recently by @Dogfalo

[wittsparks]

I'm still seeing issue #3 - I'm using 0.99.0 from CDN:
https://cdnjs.cloudflare.com/ajax/libs/materialize/0.99.0/css/materialize.min.css

I take it not all of these issues have been corrected?

[Dogfalo]

In v1-dev, we've overhauled the label system so that is the error messages do no move inadvertently with the primary label.

[ctytgat]

@Dogfalo Do you know in which release this overhaul will be included?

[tomscholz]

1.0.0

[jtlthe2]

I put the following workaround in my CSS to wrap the text when I specified and when it needed to in my Angular 2 app.

label[data-error], label[data-success] {
    width: 100%;
    white-space: pre-wrap;
}

It allowed me to fill my data-error property with the following

[attr.data-error]="'Line 1 of the message.\nLine 2 of the message. I am going to make this really really really really really really really really really really really really really really really really really really really really really really really long, so it wraps.\nLine 3 of the message.\n'"

which then displayed the error how I wanted (image attached).