webshims validityMessages trumped by those of browsers with only partial validation support about webshim HOT 16 CLOSED

Thanks, I do see two errror here, but not what you mentioned. I will fix those and explain, how this works. I wanted to solve this. It would be great, if you would look, how we can improve documentation.

from webshim.

Ok, before I start to fix the issues here some short informations, how it should work:

1. the customMessage approach (has a minor error see workaround below):
   $.webshims.setOptions('forms', {customMessages: true});
   $.webshims.activeLang('zh');
   $.webshims.polyfill('forms');
   $(document).bind('firstinvalid', function(e){
   $.webshims.validityAlert.showFor( e.target, $(e.target).attr('customValidationMessage'));
   return false;
   });
2. the overrideMessages approach:
   $.webshims.setOptions('forms', {overrideMessages: true});
   $.webshims.activeLang('zh');
   $.webshims.polyfill('forms');

Due to the fact, that I have moved activeLang from polyfiller.js to dom-extend.js, both approaches will throw an error. The second approach currently only works initially, what is not nice.

Here is how you would do it, with webshims lib 1.5.2:
$.webshims.setOptions('forms', {customMessages: true});
$.webshims.ready('dom-extend', function(){
$.webshims.activeLang('zh');
});
$.webshims.polyfill('forms');
$(document).bind('firstinvalid', function(e){
$.webshims.validityAlert.showFor( e.target, $(e.target).attr('customValidationMessage') );
return false;
});

To make the validityMessages bullet proof, you should write something like this:
$.webshims.validityMessages.zh = $.extend(true, {}, $.webshims.validityMessages[''], {
valueMissing: '请填写此字段。'
,typeMismatch: {
email: '请输入一个电子邮件地址。'
}
});

Additionally, I see some other problems in your code, regarding to $('body').fadeIn(); Am I right, that you are doing this, to remove FOUCs?

from webshim.

Ok, I have fixed the issues and pushed them to the master-branch.

from webshim.

Hey Alex, sorry for the late reply, and thanks so much for the tips! I've upgraded to webshims 1.6.0RC3 and incorporated your suggestions commit. Things are looking much better now all around, except for one small thing I noticed: In Firefox 4, the form is validated before anything is input, so basically it starts out with the email input outlined in red (example). I can dig into this when I get a chance but feel free to close this ticket in the meantime.

Thanks again!

Josh

from webshim.

P.S. As far as I know the $('body').fadeIn() is in there just for style's sake, and not to avoid any FOUC (I didn't put it there originally). If you get a chance, I'd love to know what the other problems were you saw in the code. I can probably get rid of that $('body').fadeIn() too.

from webshim.

About the red outline: This is absolutly ok and well stupid. This is a feature of CSS3 UI module and doesn't have to do with webshims lib. You can simply remove this with box-shadow: none. Note that you should also set the border, the background-color and the color. Here is how you could do it:
/* remove native invalid styles */
:invalid {
box-shadow: none;
border: 1px solid #000;
background: #fff;
color: #000;
}

FF4 adds some nice extra selector, which do the job better this is called: :-moz-ui-invalid. Webshims also adds some extra class, which behave similiar to -moz-ui-invalid (.form-ui-invalid).

So your style could look, like this:
/* remove native invalid styles */
:invalid {
box-shadow: none;
border: 1px solid #000;
background: #fff;
color: #000;
}

    //add invalid style for FF4
    :-moz-ui-invalid {
        //invalid style
    }

    //add invalid style for all browsers
    :-moz-ui-invalid {
        //invalid style
    }

from webshim.

About the $('body').fadeIn()-Thing:

You do move your JS at the bottom. Moving JS at the bottom doesn't make loading the whole page faster. Putting JS at the bottom means: Load JS as slow as possible, to reduce the time, where the user doesn't see the page loading (white page). The problem is, that this also causes FOUCs. In your case you hide the whole page and make it visible with JS, which means, the white page loading isn't decreased, it will be increased. This means: You should, put your JS at the top!

Another thing here is:

1. Don't rely on JS
2. Don't hide with display: none (because, this can create some strange issues, if you are using JS)

My CSS-Code for this (The .js-Class comes with Modernizr):

    .js body {
        visibility: hidden;
    }

My suggested JS Code:

    $(function(){
        $('body')
            .css({opacity: 0, visibility: 'visible'})
            .fadeTo(400, 1)
        ;
    });

One question: I have written, that a developer should prefer 'customMessages' over 'overrideMessages', why did you use overrideMessage? (As you see I'm not really happy with this.)

from webshim.

re red outline in firefox, if you save the following in test.html:

<form>
<input type="email" required placeholder="email" /><input type="submit" value="+" />
</form>

and open it in firefox, it doesn't get the red outline until you actually enter something in the text input. So something additional in my page must be triggering Firefox's validation before the user enters input. This may or may not be webshims. But the fix for the wrong behavior on my page is not CSS.

Thanks for pointing out those nice invalid selectors though, good to know!

from webshim.

re fadeIn thing: thanks for the advice about how to do that the right way! I moved all the script to the top like you suggested and decided to just ditch the fadeIn effect, but if I have to add it back I'll do it like you said. As for the script at the bottom, I was just following a recommendation I think the Firefox YSlow plugin made to me years ago, and hadn't tested the differences out. Thanks for the explanation, and I'll certainly report back if I find anything else interesting.

from webshim.

re customMessages vs overrideMessages, I chose the latter because it required writing less code. ;) When a library provides two ways of doing the same thing, I usually assume the one where I have to write less code is the preferred way, since presumably it means changing less stuff from its default behavior. If this isn't the case here, would it be possible to make it so you can use customMessages without having to write custom event handlers and binding them to various validation events?

I know the docs page says customMessages is less obtrusive, but it doesn't explain why, or if it does I wasn't able to follow it.

Thanks!

from webshim.

Uh oh, just tested my page out in Chrome 7 and webshims is not rendering the validity messages. Can you take a peek at http://1.bravenewsoftware.appspot.com in Chrome 7 and see if you can reproduce?

Many thanks,
Josh

from webshim.

Hi,

I'm not sure, but if you see the following behavior:

• try to submit
• submit is aborted
• first invalid field is focused
• no error UI

This is a known bug in old webkit (includes also Safari 5.0.1, but not Safari 5.0.2 and not Safari 4.x).

I decided some time, that I don't fix this bug anymore (you can only do this with browser sniffing + is test intensive), because of the non-existent marketshare of those webkit versions.

Why are you testing those browsers, is supporting chrome 7 needed???

from webshim.

Ok, I have fixed this on my local machine, but needs some extra tests. Only to make my statement above clear. It was a small issue on a browser with very small marketshare and I take x-browser testing very seriously.

This was the list of browsers, which I did actively test:

• FF final/latest (4.0)
• FF -1 (3.6)
• FF fixed @ 3.0 (no localStorage in Mozilla test)
• IE6
• IE7
• IE8
• IE9
• Safari - 1 (4.x)
• Safari final/latest (5.0.4)
• Safari for latest iOS (4.3.1)
• Safari nightly
• Chrome dev (currently 11)
• Chrome final (10)
• Chrome fixed @ 10 (has almost everything right, but one small issue, which has to be browser sniffed)
• Opera final (11.01)
• Opera -1 (10.54)

and now I got a new browser to test with each release:

• Safari fixed to 5.0.1

Although, I'm working with a testsuite, this huge list makes it really hard to push a new release.

from webshim.

Hey Alex, sorry for the noise! I had no idea about all that. I only tried Chrome 7 because it was the only old version of Chrome I had lying around on my computer and I figured I'd give it a whirl. It sounds like it makes no sense though to support it. You give lots of good reasons not to fix this, so please don't bother on my account! Sorry if I caused you any trouble!

from webshim.

I have fixed, only because I saw, that someone is trying, so this bothers me. I only wanted to make clear, that I already do a lot of x-browser testing and due to the fact, that HTML5 features are really differntly supported, it's really hard, to make it really really good. Now it is fixed (the testsuite already showed, that this fails) and now I have setup my vm using another Webkit version.

from webshim.

Well, thanks for fixing, and again, definitely don't spend precious time on this kind of thing if it goes against your better instincts. I just noticed it says very clearly on the demo page that Chrome 9.0+ is supported, so a bug submitted for Chrome 7 can very fairly be closed as invalid!

In other news, I haven't yet had a chance to put any more time into looking into the validation being triggered too early in Firefox 4 or the customMessages vs overrideMessages. Probably any extra time I get to put into webshims in the future will go toward helping with translations and looking at using Modernizr 2's ability to just test for the features you need. Ideally some day there'd just be a webshims API hosted on a CDN which you could use to only request script that tests for and polyfills just the features you need. That would be awesome!

from webshim.