Re: [whatwg] [WebForms2] custom form validation notifications without scripting
Na , Brad Fults <[EMAIL PROTECTED]> escreveu: On 10/3/06, Joao Eiras <[EMAIL PROTECTED]> wrote: Although WebForm2 provides automatic validation of form content from the UA side, the specification has a few gaps related to customizablility of notifications, by web authors, without scripting enabled. If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like "You must set a value!" (for required) or "foo is not in the format this page requires" (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. Is the use of the title attribute inappropriate for this case? I believe title is used for a berief description, not for error messages, besides a control may not validate for more than one reason.
Re: [whatwg] [WebForms2] custom form validation notifications without scripting
On 10/3/06, Joao Eiras <[EMAIL PROTECTED]> wrote: Although WebForm2 provides automatic validation of form content from the UA side, the specification has a few gaps related to customizablility of notifications, by web authors, without scripting enabled. If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like "You must set a value!" (for required) or "foo is not in the format this page requires" (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. Is the use of the title attribute inappropriate for this case? -- Brad Fults
[whatwg] [WebForms2] custom form validation notifications without scripting
Although WebForm2 provides automatic validation of form content from the
UA side, the specification has a few gaps related to customizablility of
notifications, by web authors, without scripting enabled.
If the user fills a form in an improper way the UA should alert him of the
problems. Opera in the early days of its initial web forms support showed
an alert box stating that the information was invalid, now it flashes the
input field, and presents a message overlapped in the webpage.
However it presents a very generic error message like "You must set a
value!" (for required) or "foo is not in the format this page requires"
(for pattern).
The author may want, in the case of an error, to present its custom error
message to the end user.
This could be achieved by declaring new custom attribute for the several
controls, which could hold the message. The UA could then either pop up
that message to the user or embed it in the page (like Opera does
currently).
The attribute could be named like requirederr, patternerr, or use some
other sort of naming convention to easily associate the constraining
property with the message attribute.
If the UA has scripting disabled, trying to prevent the default action for
an invalid event won't work. Too overcome this problem, there could be a
new attribute which could be called 'notifyoninvalid="true|false"' with a
default value of true, for each control, or for the entire form. If the
value is false, then the UA wouldn't notify the user in case of
invalidity. This could then be delegated to some CSS using :invalid;
Now, to ease the authors work, there could be another css pseudo-classes,
to compliment :invalid, which is :valid
*:valid{border:thin solid green;}
This way it's more easy to provide custom notifications, instead of
default ones, with no scripting.
Goodbye.
Re: [whatwg] [WF2]
On Wed, 04 Oct 2006 02:32:27 +0200, Simon Pieters <[EMAIL PROTECTED]> wrote: Then don't mark the select as being required. Or do you mean that there are cases where the user has to change the value to ""? What would that be? One case could be that an old web application is configured serverside to interpret an empty value as "none of the above". For the author, it would be risky to change this as opposed to just slapping on some added functionality for modern browsers on the client side. So should there be a declarative way to express this? I say yes, but I think "pattern" is a better candidate than "required", or as Joao Eiras suggested, marking certain options as "invalid" - or all of the above. - Robert Græsdal
Re: [whatwg] [WF2]
Hi, From: Robert <[EMAIL PROTECTED]> On Mon, 02 Oct 2006 16:35:32 +0200, Simon Pieters <[EMAIL PROTECTED]> wrote: Submitting an empty value may be wanted, Then don't mark the select as being required. Or do you mean that there are cases where the user has to change the value to ""? What would that be? and since a select by definition is a list of predefined valid values, it would make little sense to prevent the user from selecting some of them. In practice they are prevented today (with script). The most common way to do this (from what I've seen) is to use "" as value for the first option, and then check the value with script (either client side or server side, although on the client side you could check for selectedIndex instead). However, I agree with the use case of the invalid starter value so users must consciously select a value they wanted instead of the default one. So should there be a declarative way to express this? Regards, Simon Pieters
Re: [whatwg] [WF2]
Well, the option element could be extended with a new attribute 'invalid'
which hold prevent that option to be selected.
Robert <[EMAIL PROTECTED]> escreveu:
On Mon, 02 Oct 2006 16:35:32 +0200, Simon Pieters <[EMAIL PROTECTED]>
wrote:
I've seen a case where a is used and the user is required to
change its value, as in:
Select one:
Foo
Bar
Now this can be done with radio buttons instead, but why can't the
above be supported? That is, make required apply to s and if
the value is empty then required is not satisfied. (Same for multiple>.)
Submitting an empty value may be wanted, and since a select by
definition is a list of predefined valid values, it would make little
sense to prevent the user from selecting some of them. However, I agree
with the use case of the invalid starter value so users must consciously
select a value they wanted instead of the default one.
The following script will do exactly what you wanted, although Opera
doesn't seem to use the custom error message for some reason. I'm not
sure if that's my fault or Opera's due to my lack of experience with
WF2, but it does prevent form submissions just fine as long as there are
invalid selects.
The script works in Opera 9.02.
http://www.w3.org/1999/xhtml';},4,null);
var elem=null;
while(elem = res.iterateNext()){
if(!elem)break;
checkSelect({'target':elem}); // do initial check
elem.addEventListener('change',checkSelect,false);
}
]]>
--
Robert Græsdal
Re: [whatwg] [WF2]
On Mon, 02 Oct 2006 16:35:32 +0200, Simon Pieters <[EMAIL PROTECTED]>
wrote:
I've seen a case where a is used and the user is required to
change its value, as in:
Select one:
Foo
Bar
Now this can be done with radio buttons instead, but why can't the above
be supported? That is, make required apply to s and if the value
is empty then required is not satisfied. (Same for .)
Submitting an empty value may be wanted, and since a select by definition
is a list of predefined valid values, it would make little sense to
prevent the user from selecting some of them. However, I agree with the
use case of the invalid starter value so users must consciously select a
value they wanted instead of the default one.
The following script will do exactly what you wanted, although Opera
doesn't seem to use the custom error message for some reason. I'm not sure
if that's my fault or Opera's due to my lack of experience with WF2, but
it does prevent form submissions just fine as long as there are invalid
selects.
The script works in Opera 9.02.
http://www.w3.org/1999/xhtml';},4,null);
var elem=null;
while(elem = res.iterateNext()){
if(!elem)break;
checkSelect({'target':elem}); // do initial check
elem.addEventListener('change',checkSelect,false);
}
]]>
--
Robert Græsdal
[whatwg] innerHTML and QNames
Hi, On getting .innerHTML the spec says that the tag name is used to serialize tags. However, Opera and Firefox use the local name. Also, it isn't certain that element names and attribute names will be all lower-case. http://simon.html5.org/test/html/dom/the-document/dynamic/in-html/demo.htm However, it seems IE does return the QName for elements and attributes...: http://simon.html5.org/test/html/dom/the-document/dynamic/in-html/ie-demo.htm I'd rather the spec followed Opera and Firefox here though (i.e., use the local name). Regards, Simon Pieters
