Re: [whatwg] input type=hidden and validation
1. This was intented for the future html spec. I'm sure I'm not the only one questioning this issue. 2. Others didn't have any trouble understanding me. 3. This list is open to everyone, I shot out a question and I got many replies, so thank you all. Reporting a problem you are not sure you have is a good reason to be shot :-) Besides, general questions are better served at news:comp.infosystems.www.authoring.html; this list is for your ideas regarding the future of HTML. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oldřich Vetešník Sent: Wednesday, October 22, 2008 5:52 PM To: Tab Atkins Jr. Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] input type=hidden and validation Dne Wed, 22 Oct 2008 17:40:55 +0200 Tab Atkins Jr. [EMAIL PROTECTED] napsal/-a: I can't really remember at the very moment, but I remember having some trouble with it with in my php script. I will try to look into it again and let you know where the problem was.
Re: [whatwg] introduction, plus some form input ideas
The DOM work was fake, but if you insist, here you have some fake SAX work:
Sub PrintOption(value, selected, text)
Const tagName = OPTION
Dim attrs(3)
Attrs(0) = value
Attrs(1) = value
If value = selected Then Attrs(2) = selected
Response.Write OpenTag(tagName, attrs)
Response.Write EmitText(text)
Response.Write CloseTag(tagName)
End Sub
Of course, the right way is to use callbacks for potential attributes and
content; I have not done that for simplicity of exposition. And in this
particular case you gain nothing by not using DOM because the fragment you
construct is very small anyway.
Chris
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
timeless
Sent: Thursday, October 23, 2008 7:22 AM
To: [EMAIL PROTECTED]; whatwg@lists.whatwg.org
Subject: Re: [whatwg] introduction, plus some form input ideas
You're doing dom work, the code jonas wrote reminds me of perl which
typically doesn't generate a dom and then serialize it to send out
over the wire. Among other things serializing often requires the
entire document which means you can't build and incrementally send the
document over the wire. For documents i build, this would typically
kill my server or simply cause the connection to be reset because
processing takes too long.
On 10/22/08, Kristof Zelechovski [EMAIL PROTECTED] wrote:
I do not find the other code significantly simpler than the present one.
I would rather say:
Sub printOption(value, selected, text)
Dim Opt
Set Opt = Option. Create(value, text)
Opt. selected = (value = selected)
Response.Write Opt.outerHTML
End Sub
For each rec in recset
printOption rec.value, selectedValue, rec. text
Next
Problem solved.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonas Sicking
Sent: Wednesday, October 22, 2008 6:19 PM
To: Ian Hickson
Cc: whatwg@lists.whatwg.org; Ric Hardacre
Subject: Re: [whatwg] introduction, plus some form input ideas
Ian Hickson wrote:
2. select tag:
selectedindex=[num]
implicitly set the selected index, instead of having to parse all the
option
tags and insert a selected string, much easier to bind to server side
data,
an invalid value (such as -1 or greater than the number of option tags)
would
mean none are selected. this would obviously not apply to
multiple-selects
You can do this from script at the moment (setting the .selectedIndex
attribute). I haven't added it to the markup side yet. It doesn't seem to
add much other than convenience (you can already do this with
selected=,
as you noted). Adding features has a high cost, even for simple features
like this, and I'm not sure we can really justify the cost here.
I actually think that something like this could be of high value to
authors.
I've found myself many many times writing serverside code like this:
selected_value = get_default_selected();
list_of_records = get_records_from_db();
print(select name='hi');
foreach (record in list_of_records) {
print(option );
if (record.value == selected_value) {
print(selected );
}
print(value=' + record.value + ' + record.text +
/option);
}
while this works it is quite a pain. It would be much better if you
could stick selected value in one place and then just dump all values.
Such as:
list_of_records = get_records_from_db();
print(select name='hi' value=' + get_default_selected() + ');
foreach (record in list_of_records) {
print(option value=' + record.value + ' + record.text +
/option);
}
So I think it works quite well as a convenience feature.
We would have to define things like does the value content attribute
change value when a new option is selected, or does it just act as a
default value. In firefox different controls behave differently in this
regard, I haven't yet checked what the html5 spec does.
/ Jonas
--
Sent from Gmail for mobile | mobile.google.com
Re: [whatwg] WF2: required attribute clarification requested
On Wed, 6 Sep 2006, Alex Vincent wrote: For disabled or readonly controls, the (required) attribute has no effect. What does this mean? The missingValue bit of validityState is either on or off. Do I need to change the required bit if we're disabled? Or should I leave it alone? I have clarified this in the merged version of WF2 in HTML5. Please let me know if the current spec is clearer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] The :in-range and :out-of-range pseudo classes
On Mon, 2 Oct 2006, Arve Bersvendsen wrote: 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. This is now academic, since min and max no longer apply to type=file. (We'll probably introduce a 'multiple' attribute for this case.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] fixing the authentication problem
Google Chrome has SNI because it uses WinHTTP for HTTPS connections and WinHTTP supports SNI. Adam On Wed, Oct 22, 2008 at 5:33 AM, timeless [EMAIL PROTECTED] wrote: On Tue, Oct 21, 2008 at 10:14 PM, Aaron Swartz [EMAIL PROTECTED] wrote: You're thinking of SNI: http://en.wikipedia.org/wiki/Server_Name_Indication which doesn't work in IE6, IE6, or Safari, making it less than useful for anything serious. anything proposed today to be added would appear *after* SNI which is already implemented in: * Mozilla Firefox 2.0 * Opera 8.0 * Internet Explorer 7 * Google Chrome I'm not certain where SNI was added by Google for Chrome, but most likely it could be integrated into WebKit for Safari for a future version.
Re: [whatwg] [WF2] select required
On Mon, 2 Oct 2006, Simon Pieters wrote: 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.) On Wed, 4 Oct 2006, Robert wrote: 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. This use case is definitely something we want to consider, but I don't think it's about required=. It's about an option in the select being a non-option (as it were). select by definition can't have nothing selected. That's what it means. The issue about a placeholder value is listed as an open issue in the spec, and will probably be addressed at some future point. I hope this addresses your comments satisfactorily. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Detecting Web Forms for future proof scripts?
On Mon, 2 Oct 2006, Ric Hardacre wrote:
[scriplets] 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?
For datalist, you could just check the class name of a datalist
element, or check to see if the input element has a list DOM
attribute, as in if ('list' in inputElement).
Cheers,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] select required
Many times I've set SELECT.selectedIndex to -1 to have the effect of an invalid starter value; I think this is a case where the REQUIRED attribute would make sense. If a SELECT has a REQUIRED attribute, and SELECT.selectedIndex == -1, then the control would be considered invalid. It would also seem to be beneficial to have some non-scripting means of setting SELECT.selectedIndex to -1. Perhaps an UNSELECTED boolean attribute, as in select unselected Weston On Thu, Oct 23, 2008 at 5:31 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 2 Oct 2006, Simon Pieters wrote: 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.) On Wed, 4 Oct 2006, Robert wrote: 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. This use case is definitely something we want to consider, but I don't think it's about required=. It's about an option in the select being a non-option (as it were). select by definition can't have nothing selected. That's what it means. The issue about a placeholder value is listed as an open issue in the spec, and will probably be addressed at some future point. I hope this addresses your comments satisfactorily. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag : loop for ever
On Oct 14, 2008, at 5:40 PM, Ian Hickson wrote: There is no way to say loop forever right now primarily because doing so would mean complicating the syntax of the playcount attribute to be not just a number. You can work around it with script (just add onended=currentTime=0 to the video element). This would lead to perceptible glitches in looped audio, compared to being able to represent the looping to the media framework. To be honest I'm not really convinced we need the looping feature at all. It seems like we should drop this from the current version. What benefit does it bring? Is looping really that common? If we got rid of it we could find better ways of picking the start time. For example: I think looped audio would be a common thing for games to want to do, and they wouldn't want it to glitch when it loops. Regards, Maciej
Re: [whatwg] video tag : loop for ever
On Oct 15, 2008, at 8:03 PM, Eric Carlson wrote: On Oct 15, 2008, at 3:52 PM, Chris Double wrote: On Thu, Oct 16, 2008 at 10:14 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: That's not the question. The question is whether the looping attributes are needed at all. It seems that there's some desire for simple looping, e.g. background sounds. That does not require the five attributes the specification currently provides though. Rather, it requires one simple boolean attribute. I agree. I think the simple boolean attribute seems clearer and more useful. Which attributes exactly are being considered for removal? I'm assuming these ones: playCount loopStart loopEnd currentLoop start and end would remain, yes? After thinking about this, I'm not sure that limiting playback to a section of a media file will be used very often. A developer can easily script the same functionality as long as they don't use the default controller, so it seems to me that attributes for this aren't warranted. I think they are useful if you want to: a) Loop a fragment (might be useful for audio for the same reason people chop up a single large image to use multiple background images) b) Use the default controls and get the right behavior. This is pretty important, I don't think we should require writing a full custom set of media controls just to be able to play a fragment without getting clearly bogus UI. For these reasons I think start and end should remain at least in the IDL interface. I agree loopStart and loopEnd are overkill. Regards, Maciej
Re: [whatwg] [WebForms2] custom form validation notifications
On Wed, 4 Oct 2006, Joao Eiras 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.
You can call setCustomValidity() to set a specific string.
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;
If scripting is disabled, why would you not want the user notified? That
would be pretty bad UI. :-)
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 already exists:
http://www.w3.org/TR/css3-ui/#pseudo-validity
Regarding custom messages for pattern= (the case where making a good
message is hard), the spec suggests using title= for the message.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag : loop for ever
On Fri, Oct 24, 2008 at 1:48 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 15, 2008, at 8:03 PM, Eric Carlson wrote: On Oct 15, 2008, at 3:52 PM, Chris Double wrote: On Thu, Oct 16, 2008 at 10:14 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: That's not the question. The question is whether the looping attributes are needed at all. It seems that there's some desire for simple looping, e.g. background sounds. That does not require the five attributes the specification currently provides though. Rather, it requires one simple boolean attribute. I agree. I think the simple boolean attribute seems clearer and more useful. Which attributes exactly are being considered for removal? I'm assuming these ones: playCount loopStart loopEnd currentLoop start and end would remain, yes? After thinking about this, I'm not sure that limiting playback to a section of a media file will be used very often. A developer can easily script the same functionality as long as they don't use the default controller, so it seems to me that attributes for this aren't warranted. I think they are useful if you want to: a) Loop a fragment (might be useful for audio for the same reason people chop up a single large image to use multiple background images) Does having a boolean loop attribute (also included in the DOM) satisfy your needs? b) Use the default controls and get the right behavior. This is pretty important, I don't think we should require writing a full custom set of media controls just to be able to play a fragment without getting clearly bogus UI. I think controlling a video or audio player requires a decent javascript API. Mabye we are still lacking in that respect. But I don't think start and end should be a feature of html elements, because if they are mainly used for dynamic stuff, they are not well expressed as attributes. Regards, Silvia.
Re: [whatwg] [WF2] select required
On Oct 23, 2008, at 5:31 AM, Ian Hickson wrote: This use case is definitely something we want to consider, but I don't think it's about required=. It's about an option in the select being a non-option (as it were). select by definition can't have nothing selected. That's what it means. The issue about a placeholder value is listed as an open issue in the spec, and will probably be addressed at some future point. This is an interesting point I hadn't considered. It's *very* common to use the first option in a select as a non-choice such as Choose one..., setting the value to something unique (often but it could be something else if is a valid choice) so it can be treated as a non-selection. This serves *precisely* the same purpose as the placeholder attribute on text input fields, which I had assumed wouldn't be valid for select. I suggest that the placeholder attribute should indeed apply to select, and the behavior should be similar to the current practice of using the first option. In particular, the placeholder should appear both on the collapsed menu, and at the top of the open menu, although it should not be selectable. But the question is, when the menu is collapsed, when should the placeholder be displayed instead of one of the options? Any time the value is ? Only until the user selects something? Somebody smarter than me, please figure this out. :-) -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] [WF2] select required
On Thu, Oct 23, 2008 at 12:45 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Oct 23, 2008, at 5:31 AM, Ian Hickson wrote: This use case is definitely something we want to consider, but I don't think it's about required=. It's about an option in the select being a non-option (as it were). select by definition can't have nothing selected. That's what it means. The issue about a placeholder value is listed as an open issue in the spec, and will probably be addressed at some future point. This is an interesting point I hadn't considered. It's *very* common to use the first option in a select as a non-choice such as Choose one..., setting the value to something unique (often but it could be something else if is a valid choice) so it can be treated as a non-selection. This serves *precisely* the same purpose as the placeholder attribute on text input fields, which I had assumed wouldn't be valid for select. I suggest that the placeholder attribute should indeed apply to select, and the behavior should be similar to the current practice of using the first option. In particular, the placeholder should appear both on the collapsed menu, and at the top of the open menu, although it should not be selectable. But the question is, when the menu is collapsed, when should the placeholder be displayed instead of one of the options? Any time the value is ? Only until the user selects something? Somebody smarter than me, please figure this out. :-) Very nice; I like the idea of expanding the proposed placeholder/hint attribute, and this does indeed seem perfect for it. Ultimately the display of the hint is, and should be, up to the UA, so that non-full-featured devices can display things in a maximally helpful way to the user. Within the context of a standard browser on an ordinary computer, though, the correct display seems relatively clear. When the select is collapsed, the hint should show until the user selects something. After the user selects something, the hint will never again display in the collapsed state. I'm not sure if it's necessary for the hint to display in the expanded state. If it is, though, then it should always be the first item in the list, and it should be nonselectable, similar to how column groups display currently. ~TJ
Re: [whatwg] [WebForms2] custom form validation notifications
This are just my thoughts, however I feel they are worth sharing: On Thu, Oct 23, 2008 at 4:40 PM, Ian Hickson [EMAIL PROTECTED] wrote: You can call setCustomValidity() to set a specific string. Joao explicitly asked for a way to achieve this **without scripting enabled**. I think it's quite obvious why setCustomValidity() doesn't solve that need. Would having some sort of custom-error-message attribute hurt that much? (Of course, the name is just an example, and I wouldn't really suggest it). It would simply ignored by current UAs, and not really hard to implement (actually, it'd be trivial compared to implementing reg.exp. parsing). 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; If scripting is disabled, why would you not want the user notified? That would be pretty bad UI. :-) That'd be really useful if validation can be delegated to server-side scripting when no client-side scripting is available. Anyway, I don't think such an attribute is needed: a page can be authored with a catch-all validation rule for the field, and then the Javascript could update that rule upon the page's loading: if scripts are dissabled, the rule wouldn't be updated and would stay as the catch-all. OTOH, I think Joao's idea was more like to relying on visual hints (ie: marking the field as red) on cases where an error message popup would be redundant and annoying. I think that could be more elegantly handled with an empty attribute value for an hipothetical custom-error-message attribute (which is not the same as an absent attribute).
Re: [whatwg] [WebForms2] custom form validation notifications
Am Donnerstag, den 23.10.2008, 23:02 +0100 schrieb Eduard Pascual: Would having some sort of custom-error-message attribute hurt that much? (Of course, the name is just an example, and I wouldn't really suggest it). It would simply ignored by current UAs, and not really hard to implement (actually, it'd be trivial compared to implementing reg.exp. parsing). We already have @title and as section 2.6 of WF2 says: Authors should include a description of the pattern in the title attribute. User agents may use the contents of this attribute when informing the user that the pattern is not matched, or at any other suitable time, such as in a tooltip or read out by assistive technology when the control gains focus. That pretty much sweeps the issue, does it ? OTOH, I think Joao's idea was more like to relying on visual hints (ie: marking the field as red) on cases where an error message popup would be redundant and annoying. I think that could be more elegantly handled with an empty attribute value for an hipothetical custom-error-message attribute (which is not the same as an absent attribute). What's the problem with having :valid and :invalid CSS pseudo-classes ? Greetings -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] [WF2] select required
On Oct 23, 2008, at 12:19 PM, Tab Atkins Jr. wrote: Ultimately the display of the hint is, and should be, up to the UA, so that non-full-featured devices can display things in a maximally helpful way to the user. Within the context of a standard browser on an ordinary computer, though, the correct display seems relatively clear. When the select is collapsed, the hint should show until the user selects something. After the user selects something, the hint will never again display in the collapsed state. I'm not sure if it's necessary for the hint to display in the expanded state. If it is, though, then it should always be the first item in the list, and it should be nonselectable, similar to how column groups display currently. 1) If the user clicks to open the menu, then clicks away or presses Esc without making a selection, does that count as a selection for purposes of making the placeholder not appear again? 2) If the user never selects something, they'll never see anything but the placeholder. That means they won't see the text associated with whatever option is selected by default. In many cases, the default option will be some sort of blank* value to indicate that the user has not made a selection; the current practice serves both purposes at the same time (having a blank value to indicate no selection, and setting the text of that option to a placeholder/ hint). A placeholder option would replace one of these purposes, but not both; authors would still need to have a default option that indicates non-selection. * By blank, I mean something unique that the script that will process the form knows means a non-selection. I normally use option value= for this purpose, but it could be any value the author devises. In other cases, there must always be something selected; a non- selection shouldn't be possible. An example might be the country field on an address form, which defaults to the most likely choice (e.g. United States for sites that expect most of their audience to be American). The user shouldn't be permitted to select a non- value. How should the placeholder text be displayed? It seems clear to me that it should NOT appear on the collapsed menu at all, but should appear at the top of the expanded menu. There are other cases where having a blank option is appropriate, but the default may be something else. The user can explicitly change the selection to a blank option. How should the placeholder behave in each of these cases? I realize these are display issues rather than semantic issues, but I think it's appropriate to discuss them. -- Andy Lyttle [EMAIL PROTECTED]
