Re: [whatwg] Arbitrary HTML in option-elements
On Tue, 30 Nov 2004, Matthew Raymond wrote: Olav Junker Kjær wrote: It would be a useful feature if arbitrary HTML was allowed in option elements. E.g. items in a dropdown could have different icons. Yeah, personally, I think we should look at adding the |icon| attribute to the option element. We can't allow arbitrary markup in option in text/html for legacy reasons. The icon idea seems reasonable for menus of actions, but we're doing with with menu now; for drop down lists, most lists in most operating system UIs don't seem to have an icon so I'm not convinced we really want to expose that yet. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] select with tabular data
On Fri, 17 Dec 2004, Anne van Kesteren wrote: I don't really follow what you are proposing here. Could you give more details? Think of a SELECT element which has a table formatted dropdown list. This enables you to do thinks like: Name Tel A. van Kesteren 000434 I. Hickson 213432 I believe I proposed something similar before based on a proposal from 1996 in www-html[1]. [1]http://lists.w3.org/Archives/Public/www-html/1996Aug/0446.html On Sat, 18 Dec 2004, Matthew Raymond wrote: Matthew Thomas had a similar idea: http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-December/002600.html It has a few problems, though. In legacy browsers the column headers aren't visible and the content of other fields isn't visible. Here's an improved version that works better with legacy user agents: | label for=result1Results of Query 1/labelbr | shead for=result1 | sh sort=ascNumber shName shDepartmentbr | /shead | select table id=result1 name=results1 size=4 | option value=234sd234 sdAdams, John sdHuman Resources | option value=33sd33 sdFranklin, Ben sdFinance | option value=199sd199 sdHarrison, W. H. sdMarketing | option value=1022sd1022 sdLincoln, Abe sdIS | option value=599sd599 sdWashington, Marsha sdIS | /select This is what it would look like in XHTML: | label for=result1Results of Query 1/labelbr | shead for=result1 | sh sort=ascNumber/sh shName/sh shDepartment/shbr | /shead | select table id=result1 name=results1 size=4 | option value=234 | sd234/sd sdAdams, John/sd sdHuman Resources/sd | /option | option value=33 | sd33/sd sdFranklin, Ben/sd sdFinance/sd | /option | option value=199 selected | sd199/sd sdHarrison, W. H./sd sdMarketing/sd | /option | option value=1022 | sd1022/sd sdLincoln, Abe/sd sdIS/sd | /option | option value=599 | sd599/sd sdWashington, Marsha/sd sdIS/sd | /option | /select For a number of existing user agents, the above markup could be styled with CSS to give it the appearance of a listview control. In this manner, we can support true listview-style controls for HTML5 user agents and simulated ones for legacy user agents using the same markup. (Note that I wanted to create a system that just reused the table elements that webmasters are already accustom to using, but making such a system work in Internet Explorer is problematic.) We have datagrid now for this use case. For select-like behavior we don't have a good solution, but it's unclear that this is a particularly common problem -- most drop downs and select boxes i see in my day to day interaction with my OS aren't tabular. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] 9.2. Focus
On Mon, 2 May 2005, Anne van Kesteren wrote: I would like the specification to say more explicitly which value of the TABINDEX attribute is the default value. Is the spec clear enough now? As TABINDEX is likely to affect if elements will match :enabled and :disabled that should be stated as well. Not sure I follow this. Also, what is the difference between '-1' and '-1' as values for the TABINDEX attribute? It might make sense to say something along the lines of any negative value is treated the same. That's what the spec says now. It is unclear from the specification what it means when one element has '1' and another has '4'. I might have missed it but I don't see which is supposed to be more important. I think this is clear now, right? I was also wondering about inheritance. In what sense? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] fixing the authentication problem
This is similar to the SSH model; the first time you connect, you're expected to manually check by some means that you're connecting to the right server. On subsequent connections, you won't be bothered unless the key changes. I'll concede that in most cases no-one actually verifies the key in the first connection case, but at least this requires an attacker to intercept your *first* connection from a particular client, rather than just any connection. I may not verify the key manually, but if my first connection to a particular server is made over a local network that I trust to be secure, then I can trust the key my SSH client has saved. This is not at all an uncommon situation: I set up a new server, I plug my laptop into the local LAN, I log in to make sure everything works. Later, when I'm sitting in a restaurant waiting for lunch and my laptop is connected to an untrusted public wifi network, I know the key my SSH client saved is legitimate. This wouldn't be common with HTTP. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Context help in Web Forms
On Sun, 12 Jun 2005, Charles McCathieNevile wrote: One of the difficulties is that many content providers don't want to clutter their page with help links Actually, given the way many sites actually do have help links, or ? icons, or the like, I don't see content providers being reluctant to do this, as you say. You are right that many sites *do* have help links present in the page. Some even try to have them on a per question basis. There is in fact an accessibility cost in this for some users (the huge difficulty with getting accessibility right is that it is a very heterogenous, and at times *apparently* conflicting set of user requirements). There are others who don't. The implementation of the contexthelp attribute was driven by the US Treasury, whose audience must measure in millions or tens of millions (I don't know how many US taxpayers read information online around April each year, when they have to file their returns, but I would guess it is a very large number indeed). They were unwilling to add all the visible links. There are many others who believe that all those extra links are clutter. I think you and I agree that in fact having them explicit and clearly discoverable is valuable. That doesn't change the fact that there are many designers who do look for a way to hide the help, while making it accessible to screen reader users, or similar. They tend to use CSS tricks at the moment, some of which defeat their goals quite neatly, others of which complicate sites endlessly, and some of which seem to work. I don't understand how inline text is inaccessible. Could you elaborate? An example would be useful. Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF3] The altinput Element
On Sun, 28 Aug 2005, Matthew Raymond wrote: The altinput element is intended to be a possible alternative to my earlier dataentry element. [...] I studied these proposals in depth. To summarise for people who weren't there 3 years ago or who have forgotten, the context is providing elements to better provide fallback markup for things like input type=date, so that during the transition from no support to wide-spread support people can write both sets of markup. The proposals are quite well designed. However, my concern is that we shouldn't add features that will last for a long time but only be useful for a short time. The transition period during which people will want to support both is short relative to the lifetime of the feature. I fully agree that we should design features that have fallback characteristics (obviously), but I am reluctant to create features purely for fallback. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] fixing the authentication problem
Level of trust affects your decisions about whether you post, what information you post, and whether you feel you have to encrypt it yourself. Chris -Original Message- From: WeBMartians [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 22, 2008 2:29 AM To: 'Eduard Pascual'; 'Kristof Zelechovski'; 'Andy Lyttle'; whatwg@lists.whatwg.org Subject: RE: [whatwg] fixing the authentication problem Somewhere, is there a definition of trust in this context? I say that in all seriousness; it's not a facetious remark. I feel that it might be useful.
Re: [whatwg] introduction, plus some form input ideas
On Mon, 30 Jan 2006, Ric Hardacre wrote: hello, i'm an asp developer in the uk and have a couple of suggestions... no doubt selfishly to make my life easier one day :-) these could probably do with their own threads if they're deemed worthy of discussion but let's just throw them out there: 1. form tag: send=all , (default, send all fields to server in get/post) send=changed , only send hidden fields and fields that have been changed by the user the idea being that if i'm running a datagrid then there's no point sending a ton of data back and forth if the user only edits a couple of cells. but the hidden form data will still be needed in any case so i can still connect the data sent to the user who sent it! I've noted this as a feature for a future version. I haven't added it to HTML5 yet because I don't want to get too far ahead of the browsers (they tend to not implement things when the spec is too far ahead of them). 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. 3. input tags: validate=[regex] implicitly set a regular expression to which the inputted data must conform, so a value of regex=([0-9]*)\.[0-9][0-9] would (assuming my top-of-the-head regexp isn't totally fubar) only allow the user to enter a number in currency format (any number of digits, a full stop and two digits). though how to enforce it is another question, leave it up to the agent? simply not respond if any other key was pressed? would it need a hint to fill out default formatting too, appending the .00 if it is left off, etc. This is now in HTML5, usng the pattern= atribute. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] fixing the authentication problem
Internet Explorer will continue to display warnings about unencrypted submissions until you explicitly instruct it not to. I find this feature useful per se, it works as Do you really want to submit this information? Sometimes I do not, e.g. when I press something accidentally, and it allows me to back off. This is the default setting. Unencrypted connections are safer because they do not give a false impression of security. The browser says that the submission is unsafe unless the user is heedless enough to disable the warning. The warning can be disabled for backwards compatibility, so that the browser can behave like when there was no secure HTTP at all. On the other hand, there are no legacy considerations regarding invalid certificates. In the case of a self-signed certificate, the data as encrypted can be read only by the receiving server; but nothing prohibits the server from abusing your data, including forwarding the information unencrypted. This is a false sense of security. Evil.org poses as blog.com means that it presents a site identical to blog.com, which may also be in the domain of blog.com. I did not try to address the original suggestion. I only wanted to justify the assumption that compromised encryption is more dangerous than no encryption (think of Aenigma). Chris -Original Message- From: Eduard Pascual [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 22, 2008 1:40 AM To: Kristof Zelechovski; Andy Lyttle; whatwg@lists.whatwg.org Subject: Re: [whatwg] fixing the authentication problem On Tue, Oct 21, 2008 at 4:35 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Sending any data, including, log-in data, through an unencrypted connection is greeted by a warning dialogue box in Internet Explorer. Only the first time. IIRC, the don't display this again checkbox is checked by default. A similar precaution is taken when the server certificate is not trusted. Not similar at all: for unencrypted connections, you have the don't bother me again option, in the form of an obvious checkbox; while with self-signed certificates you are warned continuously; with the only option to install the certificate on your system to trust it (which is a non-trivial task; out of the reach for most average users; still annoying even for web professionals; and, to top it up, you need to do it on a site-by-site basis). It doesn't make any sense for UAs to treat unencrypted connections as safer than (some) encrypted ones: that's simply wrong. The risk of using an invalid certificate is bigger than not using any because your level of trust is bigger while you are equally unprotected. That's, simply put, not true. The level of trust doesn't actually depend (for average users) on the certificate at all, but on what the browser says about it. The level of protection, instead, is independent from the user, and it's not the same for each case: On an unencrypted connection, everyone could read the data being sent. This is no protection at all. On a connection encrypted with a self-signed certificate, the user can rest assured that the data is only readable by the server, regardless of who is actually behind that server. There is some protection here, even if it's not the most possible. On an encrypted connection with a CA-signed cert, the user has the protection from encryption (only the server will be able to read the data), plus the guarantee that the CA has taken care to verify that the entity in charge of that server is who it claims to be. It is not enough to make sure that your credentials do not unintentionally leave example.com. Consider the following scenario: 1. You want to update your blog at blog.com 2. Evil.org poses as blog.com by phishing or DNS poisoning. 3. You log in to evil.org using your credentials of blog.com. 4. The bad guys at evil.org use your credentials to post an entry at blog.com that you are going to deploy a dirty bomb in NYC. 5. You travel to the USA and you end up in Guantanamo. Nice, eh? Although I'm not sure what do you mean by Evil.org poses as blog.com, I see no point in Aaron's original suggestion that would deal with such a case. In summary, besides UAs' paranoia, I can't see any case where the suggested feature would provide anything self-signed certificates don't already provide. And since it involves using public-key encryption, I don't see any reason why UAs would treat the encryption keys differently from current SSL certificates.
Re: [whatwg] Context help in Web Forms
A LINK element cannot have a LABEL ancestor so Ian's answer seems to answer a different request. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 22, 2008 9:43 AM To: Charles McCathieNevile Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Context help in Web Forms On Sun, 12 Jun 2005, Charles McCathieNevile wrote: Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
On Wed, 22 Oct 2008, Kristof Zelechovski wrote: rel=help is now defined to apply to the link element's parent and its children. A LINK element cannot have a LABEL ancestor so Ian's answer seems to answer a different request. By link element I meant whatever element was creating the link (in this case, a or area). Sorry about the confusion. The spec is clear about this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] minlength attribute
On Mon, 27 Feb 2006, laos wrote: minlength attribute. This attribute applies to texthttp://whatwg.org/specs/web-forms/current-work/#text, password http://whatwg.org/specs/web-forms/current-work/#password, urlhttp://whatwg.org/specs/web-forms/current-work/#url, and email http://whatwg.org/specs/web-forms/current-work/#email input types, and textarea elements. For text input controls it specifies the minimum length of the input, in terms of numbers of code points On Tue, 28 Feb 2006, Matthew Raymond wrote: Well, this wouldn't be useful at the actual time of input, because you may delete enough of the contents to go below the minimum length prior to putting in new input. Clearly this would have to apply for validation, and I believe that the |pattern| attribute would already cover this, as you can specify the number of character required in |pattern|. Or am I misunderstanding how |pattern| works? On Wed, 1 Mar 2006, laos wrote: I think that this would be useful for forms in which a username or password is asked, and is required that they contain at least six or eight characters and I also consider that would be useful so that the user agents show error messages. The pattern attribute could solve this (with exception of the error message), but also this attribute would solve many cases that the specification solves of other way (I think that most of the things they could be solved with this attribute). Thanks for your feedback. I agree that this could be a useful feature in certain cases. It's not clear to me though that these cases are that common. Could you elaborate on the use cases for this? Is it just usernames and passwords, effectively? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Callback driven initialization of canvas
On Tue, Oct 21, 2008 at 10:04 PM, timeless [EMAIL PROTECTED] wrote: Technically in gecko today CAPS should be able to squish canvas methods per domain (not tested, but ask mao about offering a feature in noscript for it). The goal would not be to completely forbid canvas but to block it by default while allowing the user to activate it when he wants to. -- Fabien Meghazi Website: http://www.amigrave.com Email: [EMAIL PROTECTED] IM: [EMAIL PROTECTED]
Re: [whatwg] fixing the authentication problem
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] [html5] 9.2. Focus
On Wed, 22 Oct 2008 09:15:32 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 2 May 2005, Anne van Kesteren wrote: As TABINDEX is likely to affect if elements will match :enabled and :disabled that should be stated as well. Not sure I follow this. I'm not sure either anymore :-) I was also wondering about inheritance. In what sense? I think this was about the case where both a parent and a child element of that parent element have the tabindex attribute set and how the UI and tab order should work. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Callback driven initialization of canvas
On Wed, Oct 22, 2008 at 2:07 PM, Fabien Meghazi [EMAIL PROTECTED] wrote: The goal would not be to completely forbid canvas but to block it by default while allowing the user to activate it when he wants to. This is a nice feature to have, but the problem is, would it work in reality? It works for Flash, since it most of the flash scripting is loaded together with the applet. However, Canvas elements will probably interface much more with the rest of the page than Flash applets. I believe many applications would need large amounts of additional code to handle graceful degrading *and* late loading of such elements, even with callbacks. Would many web authors use this feature? Then again, maybe the onLoad event would be a good place for such a callback?
Re: [whatwg] Is fieldset interactive?
On Mon, 3 Apr 2006, Henri Sivonen wrote: On Apr 3, 2006, at 09:47, Ian Hickson wrote: On Sat, 1 Apr 2006, Henri Sivonen wrote: Should fieldset count as an interactive element for the purpose of nesting rules? No, since as you say: A fieldset in a context where interactive elements are forbidden is not allowed to contain any form controls anyway. ...it would be pretty stupid to disallow fieldset's main use case... Oops. Good point. :-) Should fieldset itself only be allowed in contexts where interactive elements are allowed (both so that it does not itself forbid interactive descendants)? We could, but that seems like excessive complexity. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Boolean attributes on datagrid
On Mon, 17 Apr 2006, Henri Sivonen wrote: The multiple attribute, if present, must be either empty or have the literal value multiple. Similarly, the disabled attribute, if present, must be either empty or have the literal value disabled. (The actual values do not have any effect on how these attributes are processed, only the presence or absence of the attributes is important.) Allowing the empty string does not conform to the general policy on non-minimized boolean attributes. I think it would be a good idea to state the conformance requirements and the processing model for boolean attributes once near the beginning of the spec. It would also be good to provide a way for identifying boolean attributes. This is done now in HTML5. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Which form inputs are interactive?
On Fri, 24 Mar 2006, Henri Sivonen wrote: The spec says: Certain elements in HTML can be activated, for instance a elements, button elements, or input elements when their type attribute is set to radio. When is an input element non-interactive? type='hidden' seems non-interactive. The rest are all interactive, right? That sentence has been rewritten to remove mention of specific cases here. To answer your question, things stop being interactive in a number of cases, e.g. disabled controls, display:none, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Callback driven initialization of canvas
Fabien Meghazi wrote:
Will it be possible for the browsers to allow an extension such as
canvas block ?
My understanding is that it won't be possible (please correct me if
I'm wrong, I'm not an expert) as the initialization of a canvas
context is done as follow :
var canvas = document.getElementById('tutorial');
if (canvas.getContext){
var ctx = canvas.getContext('2d');
// drawing code here
} else {
// canvas-unsupported code here
}
But if the initialization of the canvas tag was callback driven, then
I guess it would be possible to do a canvas block.
var canvas = document.getElementById('tutorial');
if (canvas.getContext){
canvas.getContext('2d', function(ctx) {
// drawing code here
});
} else {
// canvas-unsupported code here
}
With this scheme, I guess it would be possible to hook the getContext
function and do whathever with the callback function (eg: call it when
user click the canvas element like flash block)
Callback driven features are definitely important for features where you
want to engage the user before enabling the feature. For example the
geolocation specs uses this pattern, as does the FileDialog interface in
the fileupload draft.
However I'm less convinced that this applies to canvas. You could
accomplish the same thing by turning off rendering for all canvases for
a page until the user has opted in. This allows asynchronous opt-in from
the user, without requiring a callback driven API for the developer.
/ Jonas
Re: [whatwg] Context help in Web Forms
On Wed, 22 Oct 2008, Jonas Sicking wrote: Ian Hickson wrote: Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. Would it make sense to say that if link rel=help appears in the head, that it appears to the whole page? It's said that for some time now. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
Ian Hickson wrote: Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. Would it make sense to say that if link rel=help appears in the head, that it appears to the whole page? / Jonas
Re: [whatwg] [html5] HTMLMapElement.images
On Sun, 2 Jul 2006, Shadow2531 wrote: On 7/1/06, dolphinling [EMAIL PROTECTED] wrote: Can you even have an image map on an input type=image ? Yes This is no longer allowed in the spec, actually. Is that a problem? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] input type=hidden and validation
Hello, I'd like to throw a question out here, please don't shoot me if it's been already answered, I'm a full-time coder and don't have an internet at home so I can't make any deep researches in your archives. Q: Is it possible that hidden inputs don't have to be in a semantic tag? That is it passes the validation test without showing this error up: line 20 column 32 - Error: document type does not allow element input here; missing one of p, h1, h2, h3, h4, h5, h6, div, pre, address, fieldset, ins, del start-tag It's because hidden inputs aren't meant to be shown to the front-end user so it doesn't mean if it's not covered in a semantic tag. Sometimes it's O.K., you have a form with a few fieldsets so you can put it in one, but sometimes it's rather stupid having to do divinput type=hidden name=somename value=somevalue //div just to silence the validator. Thank you, Ollie
Re: [whatwg] [wf2] Leap seconds, dates in the past
On Fri, 18 Aug 2006, Gervase Markham wrote:
Henri Sivonen wrote:
Could you elaborate on the use cases? Are there a lot of use cases on
the Web now that force site author to hack awkward JavaScript widgets
themselves? Can't they continue using those hacks for uses cases that
are not mainstream like airline reservations?
Could we perhaps make the functions which do date calculation and
differencing pluggable? That is to say, we expose them on the DOM of the
widget, so you can do:
function gervsSubtractDates()
{
...
}
myWidget.subtractDates = gervsSubtractDates()
That way, you could have a calendar widget that defaulted to Gregorian
but could be hacked by specialist web pages to display other sorts of
calendar.
Note I haven't thought this through very well - it may be rubbish :-)
On Fri, 18 Aug 2006, Henri Sivonen wrote:
Sounds like architecture astronautics to me.
I expect a widget designed for choosing Gregorian dates to be unsuited
for arbitrary calendars.
On Fri, 18 Aug 2006, Gervase Markham wrote:
It's a fair cop, guv.
That is, you are probably right :-)
I agree with Henri - I'm not sure this solves the problem really. I'm also
not sure the problem is one we should worry about solving yet. We need
more experience with calendars first.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=hidden and validation
On Wed, Oct 22, 2008 at 10:41 AM, Oldřich Vetešník [EMAIL PROTECTED]wrote: Hello, I'd like to throw a question out here, please don't shoot me if it's been already answered, I'm a full-time coder and don't have an internet at home so I can't make any deep researches in your archives. Q: Is it possible that hidden inputs don't have to be in a semantic tag? That is it passes the validation test without showing this error up: line 20 column 32 - Error: document type does not allow element input here; missing one of p, h1, h2, h3, h4, h5, h6, div, pre, address, fieldset, ins, del start-tag It's because hidden inputs aren't meant to be shown to the front-end user so it doesn't mean if it's not covered in a semantic tag. Sometimes it's O.K., you have a form with a few fieldsets so you can put it in one, but sometimes it's rather stupid having to do divinput type=hidden name=somename value=somevalue //div just to silence the validator. Thank you, Ollie Big question here is, why is this necessary? You only use hidden inputs in a form. If you have a form, you'll have other inputs (at least a input type=submit or button type=submit), which *do* have to obey those semantic limits, and thus will be wrapped in an appropriate tag. Why can't you just stuff your hidden inputs in there along with them? The exact location of a hidden input is of absolutely no consequence in any way (except for it being in the appropriate form, of course), so you should always have an appropriate place for them. ~TJ
Re: [whatwg] input type=hidden and validation
Dne Wed, 22 Oct 2008 17:40:55 +0200 Tab Atkins Jr. [EMAIL PROTECTED] napsal/-a: On Wed, Oct 22, 2008 at 10:41 AM, Oldřich Vetešník [EMAIL PROTECTED]wrote: Hello, I'd like to throw a question out here, please don't shoot me if it's been already answered, I'm a full-time coder and don't have an internet at home so I can't make any deep researches in your archives. Q: Is it possible that hidden inputs don't have to be in a semantic tag? That is it passes the validation test without showing this error up: line 20 column 32 - Error: document type does not allow element input here; missing one of p, h1, h2, h3, h4, h5, h6, div, pre, address, fieldset, ins, del start-tag It's because hidden inputs aren't meant to be shown to the front-end user so it doesn't mean if it's not covered in a semantic tag. Sometimes it's O.K., you have a form with a few fieldsets so you can put it in one, but sometimes it's rather stupid having to do divinput type=hidden name=somename value=somevalue //div just to silence the validator. Thank you, Ollie Big question here is, why is this necessary? You only use hidden inputs in a form. If you have a form, you'll have other inputs (at least a input type=submit or button type=submit), which *do* have to obey those semantic limits, and thus will be wrapped in an appropriate tag. Why can't you just stuff your hidden inputs in there along with them? The exact location of a hidden input is of absolutely no consequence in any way (except for it being in the appropriate form, of course), so you should always have an appropriate place for them. ~TJ 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] input type=hidden and validation
On Wed, 22 Oct 2008 17:41:37 +0200, Oldřich Vetešník [EMAIL PROTECTED] wrote: I'd like to throw a question out here, please don't shoot me if it's been already answered, I'm a full-time coder and don't have an internet at home so I can't make any deep researches in your archives. Q: Is it possible that hidden inputs don't have to be in a semantic tag? That is it passes the validation test without showing this error up: line 20 column 32 - Error: document type does not allow element input here; missing one of p, h1, h2, h3, h4, h5, h6, div, pre, address, fieldset, ins, del start-tag It's because hidden inputs aren't meant to be shown to the front-end user so it doesn't mean if it's not covered in a semantic tag. Sometimes it's O.K., you have a form with a few fieldsets so you can put it in one, but sometimes it's rather stupid having to do divinput type=hidden name=somename value=somevalue //div just to silence the validator. You can test this with http://validator.nu/ which already validates HTML5. You can basically insert input type=hidden (and other input types) virtually anywhere except directly inside table, ol and elements with similar special models. Does that help? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] input type=hidden and validation
On Wed, 22 Oct 2008, Oldřich Vetešník wrote: Q: Is it possible that hidden inputs don't have to be in a semantic tag? That is it passes the validation test without showing this error up: line 20 column 32 - Error: document type does not allow element input here; missing one of p, h1, h2, h3, h4, h5, h6, div, pre, address, fieldset, ins, del start-tag I believe in HTML5 that we've allowed input in most places, which should satisfy your needs. Let us know if it does not. :-) Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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
Re: [whatwg] introduction, plus some form input ideas
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
Re: [whatwg] input type=hidden and validation
I suggested the same thing a week ago: http://www.nabble.com/input-type%3Dhidden-outside-phrasing-content-td275 4.html#a2754 with replies here: http://www.nabble.com/Re:-input-type%3Dhidden-outside-phrasing-content-td200 00847.html#a20023298 The short answer is that for some elements (eg FORM) this is already solved in HTML5, but for other elements (eg TABLE) it is not, and the responses were not too positive about changing that. Best regards Mike Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oldrich Vetešník Sent: den 22 oktober 2008 17:42 To: [EMAIL PROTECTED] Subject: [whatwg] input type=hidden and validation Hello, I'd like to throw a question out here, please don't shoot me if it's been already answered, I'm a full-time coder and don't have an internet at home so I can't make any deep researches in your archives. Q: Is it possible that hidden inputs don't have to be in a semantic tag? That is it passes the validation test without showing this error up: line 20 column 32 - Error: document type does not allow element input here; missing one of p, h1, h2, h3, h4, h5, h6, div, pre, address, fieldset, ins, del start-tag It's because hidden inputs aren't meant to be shown to the front-end user so it doesn't mean if it's not covered in a semantic tag. Sometimes it's O.K., you have a form with a few fieldsets so you can put it in one, but sometimes it's rather stupid having to do divinput type=hidden name=somename value=somevalue //div just to silence the validator. Thank you, Ollie
Re: [whatwg] input type=hidden and validation
Ian Hickson wrote: I believe in HTML5 that we've allowed input in most places, which should satisfy your needs. Let us know if it does not. :-) We discussed this last week http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016655.html and HTML5 is certainly a step forward in this respect. Still, HTML5 doesn't allow input everywhere in the document. For visible input fields this is of course a good thing, but for hidden input it would be good to have more flexibility. My use-case is a server-side solution that is to automatically add hidden postable state to just about any HTML fragment (the form is taken care of on an outer level). To make this in a valid way today presents quite a few challenges like traversing table models or adding extra td:s just for state. I don't have any universal solution, but possibilities include: - allowing hidden input:s to actually live anywhere (this is probably hard to do dtd/validation-wise) - inventing some hidden postable state that is orthogonal to the element structure and thus can be added to any element (maybe an extended version of the data attributes?) - keeping the whole thing invalid but still define in HTML5 how the migration of ill-placed input:s should work (I did a little research on the last point here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016718.html ) Do you have comments or any other ideas? Best regards Mike Wilson
Re: [whatwg] input type=hidden and validation
On Wed, 22 Oct 2008, Mike Wilson wrote: - allowing hidden input:s to actually live anywhere (this is probably hard to do dtd/validation-wise) It's easy to specify, the problem is that it makes it easy for authors to get in trouble if they change the type attribute on the fly (e.g. in an editor or from script). It's also not clear why this is necessary -- putting it in the first cell of a row, or the next li in an ol, seems trivial. - inventing some hidden postable state that is orthogonal to the element structure and thus can be added to any element (maybe an extended version of the data attributes?) That seems like a lot of complexity for what is already possible. - keeping the whole thing invalid but still define in HTML5 how the migration of ill-placed input:s should work That is theoretically already defined. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=hidden and validation
On 22/10/2008 19:58, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 22 Oct 2008, Mike Wilson wrote: - allowing hidden input:s to actually live anywhere (this is probably hard to do dtd/validation-wise) It's easy to specify, the problem is that it makes it easy for authors to get in trouble if they change the type attribute on the fly (e.g. in an editor or from script). From an implementation perspective this makes life a lot harder as well since the allowable positions for input now depend on an attribute rather than just the tag name. WYSIWYG editors would also find it difficult to indicate the presence of the hidden field in odd locations like between table and tr even ignoring the fact that they'd have to move it if the author changed the type. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Caching offline Web applications
I haven't reviewed the new draft yet just a preliminary comment for now. * intercept namespaces [new] This form of namespace is not in the spec at present. This is a proposal to add it. It is a heavily used feature of the Gears LocalServer. The basic idea is to intercept requests into this namespace and satisfy them with a cached 'namespace-handler' without consulting the server. 2) Hijacking parameterized requests and returning a local resource without incurring any network traffic. This isn't supported; the network is always consulted. But if the network request fails, then a fallback resource is used, though it cannot be generated on the fly. Why? I had assumed this was a simple omission in the original draft. Can you explain the rationale behind not having this feature? What am i missing?
Re: [whatwg] input type=hidden and validation
Ian Hickson wrote: On Wed, 22 Oct 2008, Mike Wilson wrote: - allowing hidden input:s to actually live anywhere (this is probably hard to do dtd/validation-wise) It's easy to specify, the problem is that it makes it easy for authors to get in trouble if they change the type attribute on the fly (e.g. in an editor or from script). Certainly. None of this is easy. It's also not clear why this is necessary -- putting it in the first cell of a row, or the next li in an ol, seems trivial. Assuming you are in control of the whole page's markup at once then I agree. But when you are not and, it may be far from trivial. (I mentioned an example of this in the link I included earlier http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016718.html ) - keeping the whole thing invalid but still define in HTML5 how the migration of ill-placed input:s should work That is theoretically already defined. Interesting. Is it the foster-parenting of tables you are referring to, or is there anything more specific for input:s? Best regards Mike Wilson
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
