My Operahow to use or survive WebForms2
Thursday, September 21, 2006 2:59:31 PM
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
To be an innovator, make sure your custom attributes match the definition in WF2. For example, the problem with
is that the pattern attribute should be a regular expression.
(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
..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
becomes for example
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..)
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..)
You must be 
João EirasxErath # Friday, September 22, 2006 1:32:28 AM
As a survival policy, Opera could just ignore non numerical min/max attribute values.
Hallvord R. M. Steenhallvors # Friday, September 22, 2006 7:19:48 PM
Robert GræsdalRobbieGee # Wednesday, October 4, 2006 11:47:39 PM
(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.
|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=
[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(
?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \
x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\
[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])
*(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
))*|(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(
?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*
"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".
\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?
[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\
Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x1F
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]
\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()
<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@
,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?
:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\
n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?
:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()
<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\
r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x
1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[
\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^
()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<
>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(
?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r
\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(
?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:
(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\
["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:
(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \
x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:
(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?
[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(
?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x
00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[
([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\]
\x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))
|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(
?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*
\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?
[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x1F]
+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^(
)<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\
n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x
1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\
"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\
n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n
)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x1
F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s
*(?:(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(
?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*
"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[
\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]
))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*
@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r
\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]
(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\
] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]])
)|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".
\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)
*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\
\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\
\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\
r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\
x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\
[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?
:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?
:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x0
0-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?
:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00-\x1F]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \x00
-\x1F]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*))*
)?;\s*)
n00b!!! ;-P
Hallvord R. M. Steenhallvors # Thursday, October 5, 2006 9:26:30 PM
Mark 'Tarquin' Wilton-Jonestarquinwj # Tuesday, November 14, 2006 1:06:54 PM
Word-a-day toilet paper becomes email-address-a-day toilet paper.
FataL # Wednesday, April 9, 2008 4:16:22 PM
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?
FataL # Wednesday, April 9, 2008 4:29:20 PM
Hallvord R. M. Steenhallvors # Thursday, April 10, 2008 5:24:05 PM
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.
FataL # Thursday, April 10, 2008 7:10:29 PM
Originally posted by hallvords:
Hmmm... I would interpret following as willValidate attribute can be set by user via JavaScript:Originally posted by hallvords:
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:
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: So, it is to read only.
Now I think we should disscuss this with WHATWG...
Anonymous # Saturday, July 23, 2011 8:54:48 AM
Anonymous # Saturday, July 23, 2011 11:25:10 AM
Anonymous # Saturday, July 23, 2011 4:29:56 PM
Anonymous # Saturday, July 23, 2011 10:00:11 PM
Hallvord R. M. Steenhallvors # Monday, July 25, 2011 4:33:35 AM
Originally posted by anonymous:
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
Matthew Slymanmatthewslyman # Thursday, July 28, 2011 6:10:34 PM
===
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.html
Set 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?
Hallvord R. M. Steenhallvors # Sunday, July 31, 2011 4:35:41 AM
Originally posted by matthewslyman:
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/
Hallvord R. M. Steenhallvors # Sunday, July 31, 2011 4:39:46 AM
Originally posted by matthewslyman:
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.html
As 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
Matthew Slymanmatthewslyman # Monday, August 1, 2011 11:05:23 AM
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?
Hallvord R. M. Steenhallvors # Tuesday, August 2, 2011 3:37:49 PM
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.)
Hallvord R. M. Steenhallvors # Tuesday, August 2, 2011 6:54:45 PM
Originally posted by hallvors:
(could you report one?)
Matthew Slymanmatthewslyman # Tuesday, August 2, 2011 8:22:05 PM
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.
Hallvord R. M. Steenhallvors # Wednesday, August 3, 2011 1:48:23 PM
Originally posted by matthewslyman:
Did you report one to Opera as well about silently failing when element.validity is set?
Originally posted by matthewslyman:
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
Matthew Slymanmatthewslyman # Wednesday, September 7, 2011 11:00:57 AM
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/1
I 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?
Hallvord R. M. Steenhallvors # Monday, September 12, 2011 8:21:31 PM
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!).Matthew Slymanmatthewslyman # Monday, September 26, 2011 12:35:23 PM
* 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?
Matthew Slymanmatthewslyman # Wednesday, September 28, 2011 2:53:52 PM
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.
Hallvord R. M. Steenhallvors # Monday, October 10, 2011 4:25:49 PM
Originally posted by matthewslyman:
To be honest, I'd rather not go there..
Originally posted by matthewslyman:
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-formatter
It 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.