how to use or survive WebForms2

EDIT: New and improved version of this blog post here:
http://dev.opera.com/articles/view/making-legacy-pages-work-with-web-forms/

Forms need validation. User-friendly, helpful, client-side validation. Plenty of validation examples exist, using JavaScript of various flavours.

The WebForms2 attempts to extend HTML4's form features and one of the objectives is to add support for common validation scenarios.


Being an early implementor of WebForms2 we've seen a few cases where WebForms2 attributes conflict with existing custom attributes (or runs into simple markup mistakes). Generally there are two cases of problems, either the built-in validation unexpectedly prevents form submits, or unexpected new properties confuse JavaScripts that look for custom ones.

Here are some suggestions for webmasters on how to handle problems:

Case: Opera's validation kicks in and prevents your form from submitting

Here you can be a fireman or an innovator – or both. To be a Fireman and just stamp out the problem, you can add a tiny touch of JavaScript to handle invalid events and sort out the issues. For example, to make Squidoo's login work, the fireman approach might be

document.addEventListener( 'invalid' , 
/* when an invalid event occurs, the user is trying to submit a form with invalid fields */
function(e){ 
  var input=e.target;
  if(input.validity.patternMismatch){ /* value crashed with pattern attribute */
     e.target.removeAttribute('pattern');
  }
  e.preventDefault(); /* do not show validation error */
  if(validate(e.target.form)) e.target.form.submit(); /* make sure form submits (Opera bug workaround) */

}, false );

To be an innovator, make sure your custom attributes match the definition in WF2. For example, the problem with

<input required="true" pattern="email" type="text" value="" tabindex="1"
 name="email_address" id="email_address"  />

is that the pattern attribute should be a regular expression.

<input required="true" pattern=".*@.*..*" type="text" value="" tabindex="1"
 name="email_address" id="email_address"  />

(I know that's simplistic, I just don't want to divert into the endless debate about finding the perfect regexp for E-mail addresses..)

Now, the validation script needs to be updated to take that into account of course. First of all, it can "learn" not to validate forms in WF2-browsers since that is handled by the browser. For example on Squidoo, they have a function called validate that receives a form as its argument. They could write

function validate(form){
  if(form.checkValidity){ return; } // browser has built-in validation

..then rewrite the part that checks the "pattern" attribute for the other browsers to read the regexp directly from the pattern.

JS being confused by new built-in properties

FreeParking's domain lookup is broken in Opera 9. The reason is that the script finds input.min and input.max attributes, both are empty but since they are not null the script thinks the domain name is supposed to be a number.

The only real fix for that is to audit your custom attributes and make sure they do not conflict with WebForms2. The fireman could of course also check if a WF2-browser is used, meaning

if (e.numeric || (e.min != null) || (e.max != null))

becomes for example

if ( e.willValidate==null && (  e.numeric || (e.min != null) || (e.max != null) ) )

since if willValidate is defined the UA would handle min and max with its built-in validation. (Of course they could also just remove the null comparison since the empty strings will evaluate to false anyway – but they may want to be able to set an empty min or max attribute to trigger number validation..)

Advertisements

27 thoughts on “how to use or survive WebForms2

  1. he reason is that the script finds input.min and input.max attributes, both are empty but since they are not null the script thinks the domain name is supposed to be a number.

    As a survival policy, Opera could just ignore non numerical min/max attribute values.

  2. The problem is that WF2 defines those DOM properties, so now they exist on all HTMLInputElement objects even if there is nothing in the markup.

  3. Pfft, amateur… everyone knows the regexp for matching email addresses by rfc 822 is (?:(?:rn)?[ t])*(?:(?:(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*|(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)*<(?:(?:rn)?[ t])*(?:@(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*(?:,@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*)*:(?:(?:rn)?[ t])*)?(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*>(?:(?:rn)?[ t])*)|(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)*:(?:(?:rn)?[ t])*(?:(?:(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*|(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)*<(?:(?:rn)?[ t])*(?:@(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*(?:,@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*)*:(?:(?:rn)?[ t])*)?(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*>(?:(?:rn)?[ t])*)(?:,s*(?:(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*|(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)*<(?:(?:rn)?[ t])*(?:@(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*(?:,@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*)*:(?:(?:rn)?[ t])*)?(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] x00-x1F]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*>(?:(?:rn)?[ t])*))*)?;s*)n00b!!! ;-P

  4. Think it would be easier to just write down every possible email address, and check against that list :PWord-a-day toilet paper becomes email-address-a-day toilet paper.

  5. I just stuck with Opera when implementing custom validation. Opera doesn't get attention to willValidate attribute set to false — it wants validate fields anyway. :(For other browsers I use WebForms 2 library and it works as expected. I just don't know how to fix it in Opera. See my test page.BTW, is it known bug or I should report it?

  6. FataL: I don't see WF2 saying anything about setting the willValidate attribute! As it is specified I think it's a sort of read only attribute informing your script or the UA that this element will be included in validation.That also implies there is no way in WF2 to say from a script that "this element should not be considered for validation (even though it has validation attributes like required)". To avoid validation of elements you actually have to remove the validation attribute, for example input.removeAttribute('required').I think you should bring this issue up with WHATWG or the HTML WG. The spec should be clarified.

  7. Originally posted by hallvords:

    I don't see WF2 saying anything about setting the willValidate attribute!

    Hmmm… I would interpret following as willValidate attribute can be set by user via JavaScript:

    each element in this list whose willValidate DOM attribute is true is checked for validity

    Originally posted by hallvords:

    That also implies there is no way in WF2 to say from a script that "this element should not be considered for validation (even though it has validation attributes like required)". To avoid validation of elements you actually have to remove the validation attribute, for example input.removeAttribute('required').

    In this case I will lost validation of element "forever". I used willValidate set to false to temporary remove validation of some form field.Also you may want to remove validation from not required field (allow enter text to number field, etc.)…Originally posted by hallvords:

    I think you should bring this issue up with WHATWG or the HTML WG. The spec should be clarified.

    Shure. I will try to ask Hixie…Update: I posted a question to WHATWG forum. Lets wait for the answer.Update 2: Hmmmm… I see this the specs:

    readonly – attribute – boolean – willValidate;

    So, it is to read only. :(Now I think we should disscuss this with WHATWG…

  8. Matthew Slyman writes:Weird behaviour with more than one fieldset in a form…I'm having difficulty getting Web Forms 2 working on Opera. When I use Google's javascript library, fieldsets are missing (whether or not I set the "required" attribute on fields inside it), and when I don't use Google's js webforms2 library (excluding that reference from the HTML source), relying on Opera, I get some strange behaviour that I would expect for non-compliant browsers (pressing the add/remove record buttons submits the entire form via POST rather than simply modifying the user-interface).http://www.aaabit.com/products/calculation/bin-packing/The only way I can find to make this page work is to switch off Javascript in Opera, and rely on the fall-back methods I've designed for non-compliant browsers with Javascript switched off…Can you help explain the difficulties I'm experiencing, and any possible remediations?

  9. Matthew Slyman writes:I now have a simplified version of the same page. No required fields. No alternative methods of making repetition work…If you use Google's javascript, the second fieldset isn't displayed at all. If you don't use Google's javascript, the add/remove record buttons submit the form to the server and make a new page request, and also, don't actually do anything with the fieldset repetition.I thought Opera was an early implementer of this? I'd love to support Opera but cannot see how I can do it at the moment… I'm cutting my page down to the bare minimum, and I still can't see how to make it compatible with a broad range of browsers, even if I restrict my customers to only using "compliant" browsers, or switching on Javascript…

  10. Matthew Slyman writes:I found out the cause of the problem, and it appears to be either:* Google's javascript being platform-specific (very unlikely)* Opera mishandling Web Forms 2.0 repetition model (almost certain)http://www.aaabit.com/products/calculation/bin-packing/test.htmlI made the test even simpler, and used as a basis for my testing, one of Google's own test pages:http://webforms2.googlecode.com/svn/trunk/testsuite/006.htmlIt appears that there is exactly one feature whose inclusion can make Opera work "correctly", and whose exclusion causes Opera's repetition model not to work at all. That feature is this attribute:repeat-start="0"For Opera to work, it appears (based on my tests with the simple HTML file above) that this attribute must also have a particular value: zero.Doing this has a side-effect that my page starts with zero repetitions of the repeating block.Omitting Google's Javascript causes Opera not to be able to handle the repetition model at all, according to my tests. There was no combination of tags/ attributes/ values that I could find, in hours of testing, that would make Opera work without Google's Javascript.Can you fix this please? Both in terms of the native handling of the repetition model, and the hiccups that appear with the Javascript, when omitting "repeat-start=0"?

  11. Matthew Slyman writes:Latest version of webforms2-p.js is available here:https://github.com/westonruter/webforms2I have tried the latest version, and this isn't helping. I've looked at webforms2_src.js – I can't understand much in the short time I've had, but from what I can understand, I believe that some platform-specific quirks in Opera's javascript implementation might be preventing repeated fields from being initialised correctly by this javascript system.How do you suggest for me to go forward with this, if I want to support Opera?

  12. Originally posted by anonymous:

    don't actually do anything with the fieldset repetition.I thought Opera was an early implementer of this?

    The repetition model that was in earlier drafts of HTML5 has been removed from the current HTML5 forms spec text, and although Opera was indeed an early implementor we have consequently dropped support for this legacy WF2 feature.The problem you're seeing is caused by the script trying to set validation properties that cause exception on setting (see error console). I'm not sure why this doesn't cause trouble in other browsers with WebForms support. If Opera throws more than others that's a bug and should be reported..Since you're not a My O member and thus don't get notifications about new posts I hope you see this 🙂

  13. I'm back. Your latest post raises more questions:===1. Repetition was the best bit of Web Forms 2.0 – whose idea was it to remove this from the spec.? As you can see from my original demo URL, this feature is actually REQUIRED for some purposes to be done in a user-friendly way…2. Has this actually be fully removed from all future specifications, or just postponed for introduction into the official HTML spec., over the near-term, to make life easier for browser implementors now? If this feature isn't going to be implemented any more, then what I am supposed to use in its place, for applications that require this functionality? Why am I no longer allowed to use the markup that was almost about to become the official standard?3. OK so Opera throws errors instead of implementing stuff that never made it into the official spec. (I had no idea until a few hours ago that repetition had been removed from the spec.) Why throw errors that prevent my fallback Javascript from working (when my JS is a popular and well-established cross-platform library)? Why not just remove the functionality and raise soft WARNINGS in the error console (in the background please without interrupting my application) if you really must? I think this is the key point.4. OK so if Opera really must throw errors instead of allowing my Javascript to work, then why does this happen inconsistently (so that now I've changed just one character in my source "test.html", all of a sudden the page works in Opera?http://www.aaabit.com/products/calculation/bin-packing/test.htmlSet repeat-start="0" and as if by magic, it works again. This will look like an error to most developers.===By the way your article on debugging Javascript problems is slightly confusing, at least for people using British English… There is no "Tools" menu. I had to go into Opera/Settings/Preferences/Content/JavascriptOptions, and then set the error console to appear on errors…http://dev.opera.com/articles/view/how-to-debug-javascript-problems-with-op/I think my initial customer does business in Belarus and Ukraine (amongst other places), so I'm telling them they will want Opera support. I'd be delighted to have some help with this. What can you do?

  14. Originally posted by matthewslyman:

    By the way your article on debugging Javascript problems is slightly confusing

    Just a quick comment on this – before I find time to dive into the other questions: this article is very old, from a time where debug capabilities were much more limited (across all browsers, actually, not just Opera). For newer stuff see for example http://www.alistapart.com/articles/advanced-debugging-with-javascript/ or other stuff on http://dev.opera.com/

  15. Originally posted by matthewslyman:

    Repetition was the best bit of Web Forms 2.0 – whose idea was it to remove this from the spec.? [X]2. Has this actually be fully removed from all future specifications, or just postponed for introduction into the official HTML spec?

    The WebForms2 spec was merged into the HTML5 forms section, I don't know entirely why the repetition model was dropped. Here is the current version:http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.htmlAs for the future plans, you'll have to ask on the WhatWG list.. Perhaps if you argue the case, some refined version will return at some point in the future 🙂

  16. Hallvord,Thanks for your helpful answers to my points 1 and 2.Are you able to help me with points 3 and 4, that relate specifically to Opera's peculiar treatment of my test page?

  17. It seems setting formElement.validity causes an exception in Opera but is silently ignored by other browsers. This probably warrants a bug report.One fix that makes it work fine in Opera, is to add a small check inside the updateValidityState method:

    updateValidityState:function(a){ if( typeof a.validity !='undefined' )return;

    and fixing

    hasBadImplementation:navigator.userAgent.indexOf("WebKit")

    to be a proper boolean value rather than -1 in most browsers:

    hasBadImplementation:navigator.userAgent.indexOf("WebKit")!=-1

    (I don't think this library has been tested much as-is, that bug is somewhat bad as all the if($wf2.hasBadImplementation) checks will evaluate to true when hasBadImplementation is -1.)

  18. I just did. The fellows who created that script are called Weston Ruter and Zoltan Dulac (the latter did the most recent update). I contacted Zoltan by email too, but have not yet received a response.I'm still getting errors in the Opera Javascript error console, even after completing your fix and another listed on the github.com site.Pending this Javascript being fixed, or Opera, or both; I've applied my work-around for Opera: detect Opera browser and set "repeat-start" to zero for every repeating element. As long as my end-users have their error console switched off, this should yield acceptable results. It's a real kludge though, and not very user-friendly to have none of the repeating elements showing when the page is first loaded.

  19. Originally posted by matthewslyman:

    I just did.

    Did you report one to Opera as well about silently failing when element.validity is set?Originally posted by matthewslyman:

    I'm still getting errors in the Opera Javascript error console

    Well, fix "dhaocument" to "document" in http://www.aaabit.com/js/webforms2-p.js and double-check what comparison operator I used after the indexOf("WebKit") call in the suggested fix above 😉

  20. I completed these updates and I'm still getting errors in the Opera Javascript console. Appears to have a problem with this: a.validity.customError=!!a.validationMessage;I'm a little out of my depth here with this Javascript (especially with the way it's formatted in this packed file, all on one line). Another commenter is now saying they're abandoned hope for this library:https://github.com/westonruter/webforms2/issues/1I think this response is a bit extreme. I just found the "_src.js" file… I still have hopes that the thing can be fixed (it's mostly doing what I require, just with a few glitches).I just updated the page, so that Opera gets the same treatment as other browsers (no work-around). a.validity.customError=!!a.validationMessage;This is still the source of the problem. All the problems seem to be focused here at the moment. Can you help me with this?What would you do if you were in my position? If you can help me mop up the last few issues, that would be fantastic. Otherwise, what would be your advice?

  21. My advice would be to add this just inside the initNonRepetitionFunctionality function:

    if('checkValidity' in document.createElement('form') && !$wf2.hasBadImplementation) return;

    What that basically means is: if the browser supports WF2-ish validation (has a checkValidity method on FORM elements), don't bother trying to add WF2-like methods and properties.(I've left the check for hasBadImplementation intact, but most likely this will also cause problems with Safari and Chrome at some point, since it's just a browser sniffing check and really says nothing about whether the implementation is bad or has been fixed. If you want to try leaving out that, you can add just

    if('checkValidity' in document.createElement('form')) return;

    and test your validation in WebKit-based browsers. If validation seems to work OK, I really recommend doing this!).

  22. Hallvord, this is amazing – my test page is now working with every major browser except Internet Explorer (there are no big surprises there). Now working with:* Firefox* Chrome* Safari* Opera (thanks to you for this and for forward compatibility fixes)All working now in Javascript, without relying upon the much slower fall-back HTML only system.This WebForms2.js library is supposed to contain code specially designed to enable it to work with MS Internet Explorer. My customer will be very unhappy with me if this tool doesn't work smoothly on MSIE. (No pressure on you of course, you've gone way beyond what I might have expected here, and I can only be grateful for what you've done.) I have a feeling though that the library was originally developed in the days of MSIE6, and that MSIE v. 7/8/9 might have tripped up whatever code is supposed to patch the quirks of MSIE 6.Really I ought to ask this as two questions:1* Can you spot any obvious problems with the MSIE browser sniffing in my code, that might muck things up with MSIE7+? Is there a simple way to fix it?2* Your skills in debugging Javascript are obviously far better than mine (did you use any techniques I might not have thought of, like unpacking that Javascript?). In general, one of the most significant ways excellent programmers differ from the rest is in debugging skills. I've been formally trained in programming at technical college, university etc., and I don't remember any serious attempt to teach debugging as a skill in its own right. What are you doing – just following function calls down with your Javascript-trained-eye, until you see a problem?Or can you give any inside tips on debugging tools and techniques? Could you write a tutorial or two on your blog? Or perhaps write a book on the subject with other industry experts?

  23. Update: Re: Your 31 July posts.I've submitted communications to whatwg via forums and emails to lists. The idea of reinstating the repetition model in some form is being considered.I'm planning to read through the Javascript debugging article(s) you recommended, and study them in detail.

  24. Originally posted by matthewslyman:

    Can you spot any obvious problems with the MSIE browser sniffing in my code

    To be honest, I'd rather not go there.. :p I do note though that the test page you uploaded expects to find http://www.aaabit.com/js/webforms2-msie.js if you load it in IE, and this file is 404. Might help ;)Originally posted by matthewslyman:

    (did you use any techniques I might not have thought of, like unpacking that Javascript?)

    Definitely – beautifying the code is the very first step. There are several tools available to do this automatically (I sometimes use http://tools.arantius.com/tabifier for HTML) but having found obscure bugs in several of them the only one I really trust is my own:https://github.com/hallvors/javascript-formatterIt takes a simplistic approach, no fancy options or code aestetics really – just makes things readable. And I've used that script (either the PHP or the JS port) many times per day for several years on the web's most dense JS, so it's pretty stable by now ;)I'll try to write some more about debugging, either here or on dev.opera.com. It is an important topic indeed. Somebody on Twitter linked to this Slashdot comment which is worth reading.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s