[whatwg] [WF2] The :in-range and :out-of-range pseudo classes
In chapter 8.2 of the WF2 draft, URL:http://whatwg.org/specs/web-forms/current-work/#relation additional CSS pseudo-classes are specified. Are file upload controls left out of the definition of :in-range and :out-of-range on purpose, or is it an oversight in the specification? :in-range Matches numeric, date-related, or time-related form control elements which have a min or max attribute set and whose validity objects have none of the typeMismatch, rangeUnderflow, and rangeOverflow flags set. :out-of-range Matches numeric, date-related, or time-related form control elements which have a min or max attribute set and whose validity objects have one or both of the rangeUnderflow and rangeOverflow flags set. -- Arve Bersvendsen, Opera Software ASA, http://www.opera.com/
Re: [whatwg] WF2 clarification request: File upload controls
Alex Vincent wrote: In the past, user agents have allowed file upload controls to reference files not local to the computer in question. For validity purposes, I wonder if this should still be allowed under Web Forms 2.0. I don't think you could forbid it; this is a feature that people use, and it would be a restriction that they wouldn't understand. Why can't I upload this file from my personal documents directory on the company file server? Allowing remote values in the file upload control could be a performance hit via networking, since we'd have to verify the file exists before saying valueMissing is false... Another option would be to say that for file upload controls, this value/event is a) asynchronous and b) optional for user agents. (Optional also meaning they could fire it for some paths and not others.) In this case, behaviour would revert to the WF 1.0 behaviour. Gerv
Re: [whatwg] Opera canvas bug?
Thank you for the bug reports. I have some comments on the second test case. The cause of this is that Opera applies the transform in the fill command (which is how I read the current spec, but it is not very clear). When the fill is called the scale is already reset, so the rect is drawn untransformed. I would like some clarification in the spec on when the transformation is supposed to be applied. regards, Tim On Sat, 30 Sep 2006 16:29:52 +0200, Benjamin Joffe [EMAIL PROTECTED] wrote: I have set up a few pages to demonstrate bugs with Opera's canvas implementation. You can see it here: http://abrahamjoffe.com.au/ben/opera_canvas_bugs/index.htm , I am sure that the first 3 are genuine Opera bugs but the 4th one might not be because I do not think that the WhatWG spec is specific enough with nested clipping paths, none-the-less I feel that the way Firefox handles the script is more correct than how Opera does. Would you agree? Regards, Benjamin
[whatwg] [WF2] select required
Hi, The required= attribute doesn't apply to selects in the current draft of WF2. As an author I'd expect it to apply to select. I've seen a case where a select is used and the user is required to change its value, as in: select name=test required option value=Select one: optionFoo optionBar /select Now this can be done with radio buttons instead, but why can't the above be supported? That is, make required apply to selects and if the value is empty then required is not satisfied. (Same for select multiple.) (I realise that radio buttons and checkboxes satisfy required even if the value is empty.) Regards, Simon Pieters
[whatwg] Detecting Web Forms for future proof scripts?
I'm attempting to write Javascript scriptlets to emulate some of the Web Forms 2.0 spec in HTML 4 documents. Firstly, they obviously need to degrade for non-scripting UAs, which is easy enough. Secondly they need to check that they're running on a compatible scripting engine, just checking for the existence of document.getElementById is the simple way (If there are better ways then I'm always open to learning). But I'm presented with an issue, suppose for example I wanted to emulate the datalist element for a text box. I can use the DOM and some on-the fly CSS to build a Javascript emulated datalist, but how would one go about ensuring that if/when it encounters a browser that can handle the datalist that it does not execute? This is probably quite an open question and yes I'm aware of the embedding-a-select-inside-the-datalist solution to this particular example, but the general question remains: How to script WF2 functionality for current browsers in a way that both degrades AND yields to the UA when it can handle the functionality natively? Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Detecting Web Forms for future proof scripts?
Ric, Hopefully, you aren't duplicating work that has already been done here: https://sourceforge.net/projects/wf2/ Granted, this is only for IE, but nearly half of your work is already done then. Cheers, Shawn On 10/2/06, Ric Hardacre [EMAIL PROTECTED] wrote: I'm attempting to write Javascript scriptlets to emulate some of the Web Forms 2.0 spec in HTML 4 documents. Firstly, they obviously need to degrade for non-scripting UAs, which is easy enough. Secondly they need to check that they're running on a compatible scripting engine, just checking for the existence of document.getElementById is the simple way (If there are better ways then I'm always open to learning). But I'm presented with an issue, suppose for example I wanted to emulate the datalist element for a text box. I can use the DOM and some on-the fly CSS to build a Javascript emulated datalist, but how would one go about ensuring that if/when it encounters a browser that can handle the datalist that it does not execute? This is probably quite an open question and yes I'm aware of the embedding-a-select-inside-the-datalist solution to this particular example, but the general question remains: How to script WF2 functionality for current browsers in a way that both degrades AND yields to the UA when it can handle the functionality natively? Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Detecting Web Forms for future proof scripts?
This project appears to be dead for over a year now. It seems to have at least intention to support Gecko, but I couldn't get it to work properly in Firefox. Just because the project appears to be dead doesn't mean you should just disregard all the work that has been done with it before. It's original aim is only for IE (as stated in the description). However, it has a large amount of work already done - why reinvent the wheel? Cheers, Shawn
Re: [whatwg] Detecting Web Forms for future proof scripts?
On Mon, 02 Oct 2006 17:00:02 +0100, Shawn Wilsher [EMAIL PROTECTED]
wrote:
Hopefully, you aren't duplicating work that has already been done here:
https://sourceforge.net/projects/wf2/
Granted, this is only for IE, but nearly half of your work is already
done then.
This project appears to be dead for over a year now. It seems to have at
least intention to support Gecko, but I couldn't get it to work properly
in Firefox.
I've ran into similar problem as the original poster. For inputs, buttons
and repetition there's an easy solution:
input.setAttribute('type','uri');
if (input.type != 'uri') alert('no native WF2!');
but it's a stretch to assume that support of certain input type means
support for all of WF2, so I'm curious how can one detect support for
other functionality.
--
pozdrawiam, Kornel Lesiński
Re: [whatwg] Detecting Web Forms for future proof scripts?
On Mon, 02 Oct 2006 17:37:28 +0100, Shawn Wilsher [EMAIL PROTECTED] wrote: This project appears to be dead for over a year now. It seems to have at least intention to support Gecko, but I couldn't get it to work properly in Firefox. Just because the project appears to be dead doesn't mean you should just disregard all the work that has been done with it before. It's original aim is only for IE (as stated in the description). However, it has a large amount of work already done - why reinvent the wheel? If I need just a feature or two, it's easier for me to write and maintain my own bit of code rather than rip it out of an unfinished, unstable code that I'm not familiar with. I'd love to use that script once it's production-ready. -- regards, Kornel Lesiński
Re: [whatwg] Detecting Web Forms for future proof scripts?
Kornel Lesinski wrote: On Mon, 02 Oct 2006 17:37:28 +0100, Shawn Wilsher [EMAIL PROTECTED] wrote: This project appears to be dead for over a year now. It seems to have at least intention to support Gecko, but I couldn't get it to work properly in Firefox. Just because the project appears to be dead doesn't mean you should just disregard all the work that has been done with it before. It's original aim is only for IE (as stated in the description). However, it has a large amount of work already done - why reinvent the wheel? If I need just a feature or two, it's easier for me to write and maintain my own bit of code rather than rip it out of an unfinished, unstable code that I'm not familiar with. I'd love to use that script once it's production-ready. The project isn't dead. We stopped developing it as Mozilla had not started on WF2. That has now changed [1] and we will soon restart development. There is no intention to support Gecko, it is an IE only implementation. Although it is not production ready, it is pretty close. By all means download and play with it. Let me know if you find any bugs! -dean [1] https://bugzilla.mozilla.org/show_bug.cgi?id=344614
Re: [whatwg] Detecting Web Forms for future proof scripts?
[Sorry Ric, re-sending to include the list] On 02/10/06, Ric Hardacre [EMAIL PROTECTED] wrote: suppose for example I wanted to emulate the datalist element for a text box. I can use the DOM and some on-the fly CSS to build a Javascript emulated datalist, but how would one go about ensuring that if/when it encounters a browser that can handle the datalist that it does not execute? What about this attempt? http://www.hallvord.com/opera/demo/wf2-datalist.htm -- Hallvord R. M. Steen
