Re: [whatwg] additional key attribute in form field
On Fri, 6 Jul 2007, Alexander wrote: i wonder why there's still no a special 'key' attribute for every form field implemented. Basically the answer is because it can already be done with name. On Fri, 6 Jul 2007, Alexander wrote: Of course, it's how I usually do this :) But I would not be against some common specified approach - especially taking into consideration some restriction on 'name' symbolset (there are much less restrictions on 'value' symbolset) We've expanded name= in HTML5 to allow basically any value. On Fri, 6 Jul 2007, Alexey Feldgendler wrote: Changing the form submission formats (that currently only allow for name/value pairs) is out of scope for WHATWG. That's not the case (indeed we had an XML format for a while), but I don't think it's necessary in this case anyway. On Sat, 7 Jul 2007, Krzysztof Żelechowski wrote: 1. Your code is old-fashioned: the identifier should be used instead of the name. It's not old-fashioned, these techniques are all valid techniques. Let's avoid putting down each other's conventions. 2. The identifier should be unique throughout the document so your code will be ill-formed. He was making up his own markup proposal, so there's no way to know if this is true or not. It appears you are making assumptions about his proposal here that are not warranted. If I understand your intention correctly, you want to submit an entire table instead of just one record a time; HTML forms clearly were not designed with that application in mind. I think you would be better off by performing an internal query on the client side---where you can refer to the form fields by numeric index rather than by identifier---and reformatting it to JSON before submission. If this is impossible, you could make a round trip to the server for each record. My experience shows that it is often the case with current implementations. That seems overly complicated; I would recommend using a key exactly as the original poster attempted, but simply using the name field and separating the key from the field name with a punctuation character. On Sat, 7 Jul 2007, carmen wrote: old-fashioned or not, the reality is most popular web frameworks are using regex hacks on the name field to squish more information in there. input name=user[35][name] value=Emmanuel it might be worth considering how they could use normal form fields without Javascript, and not require Regex in multiple places along the line. obviously another workaroudn besides regex is custom serialization and nonstandard attribute names of the input element - my preference using RDFa style predicates to describe what the field actually contains... Different people have different needs. I wouldn't characterise the use of a convention for naming input controls as a hack. Also, this shouldn't require JavaScript, it can be purely server-side logic. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Tue, 28 Oct 2008 16:01:33 -0400, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 30 Jan 2007, Shadow2531 wrote: http://www.whatwg.org/specs/web-forms/current-work/#for-mailto http://www.whatwg.org/specs/web-forms/current-work/#x-www-form-urlencoded (#4) In mailto URIs, %20 represents a space. form action=mailto:; input name=subject value=1 2 input type=submit /form If you submit that form, mailto:?subject=1+2; will be passed to the mail client instead of mailto:?subject=1%202;. This results in 1+2 in the subject field instead of 1 2. Are UAs allowed to use %20 instead so things come out right, or must mail clients decode + to a space? Thunderbird, M2, and Outlook express don't decode +s. RFC2368 is referenced, but it and application/x-www-form-urlencoded that the mailto: form methods are referenced under conflict with each other on whether a space should be encoded to %20 or +. Fixed in the HTML5 spec. Thanks. Awesome! Thanks. Question though. What about the method=POST case where the query string is kept? For example: form action=mailto:?subject=1+2; method=POST input type=text name=body value=1+2 input type=text name=other value=1 2 input type=submit /form When submitting that, I expect to see: mailto:?subject=1%2B2body=body%3D1%252B2%26other%3D1%25202 submitted to the mail client. The current POST section seems to say that this would be submitted instead: mailto:?subject=1+2body=body%3D1%252B2%26other%3D1+2 In other words, I think spaces in values should be emitted as %20 for POST too and in the case there's a query string present in the action attribute for POST, any + in the hvalues of the query string should be normalized to %2B (to be consistent with a + inside a form control's value that gets converted to %2B) Also, for POST only, if there isn't a subject hvalue specified in the action attribute, Firefox will append subject=Form%20Post%20from%20Firefox so that Form Post from Firefox ends up in the mail client's subject field. Do you think Form Post from UA should be specified? -- Michael
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Wed, 29 Oct 2008, Michael A. Puls II wrote: Question though. What about the method=POST case where the query string is kept? For example: form action=mailto:?subject=1+2; method=POST input type=text name=body value=1+2 input type=text name=other value=1 2 input type=submit /form When submitting that, I expect to see: mailto:?subject=1%2B2body=body%3D1%252B2%26other%3D1%25202 submitted to the mail client. The current POST section seems to say that this would be submitted instead: mailto:?subject=1+2body=body%3D1%252B2%26other%3D1+2 In other words, I think spaces in values should be emitted as %20 for POST too and in the case there's a query string present in the action attribute for POST, any + in the hvalues of the query string should be normalized to %2B (to be consistent with a + inside a form control's value that gets converted to %2B) The idea is that the same thing as would be posted to an HTTP server is what is sent using the e-mail body, so I think we'd want the exact same + behavior as normally. Also, for POST only, if there isn't a subject hvalue specified in the action attribute, Firefox will append subject=Form%20Post%20from%20Firefox so that Form Post from Firefox ends up in the mail client's subject field. Do you think Form Post from UA should be specified? I don't think that's really necessary; UAs are free to implement e-mails however they like really. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On Sun, 15 Jul 2007, Alex Vincent wrote: I've held off on commenting about the new types suggested for input so far, but I should mention this: Web Forms 2 as it currently stands has twenty-four different types of input elements. Ten from HTML 4, fourteen new ones in this spec. Please, please, don't overload it any more than is absolutely necessary. We're down to 20 total, 10 from HTML4 and 10 new ones, 6 of which are date-related, 2 of which are numeric, and 2 of which are text-based. We'll probably add type=color soon, and maybe type=emails or some such some time after that. In general though I agree that we should keep things to a minimum, just as with all parts of the Web platform. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Web Forms 2.0] 2.3. Extensions to the select element - comment proposal
On Mon, 27 Aug 2007, Garrett Smith wrote: Currently there is a problem in at least Firefox, and I can't remember about IE. If no OPTION has selected attribute, then Firefox will select the first option in the list. If the first option is selected, it's selected attribute will be true and the defaultSelected will be false. This is because defaultSelected is required to return the value of the HTML selected attribute. The negative result this has is that it causes the form to appear dirty. To work around this, manually mark the first element as selected. I think it isn't a bug that it marks the form as dirty (as it were); the data that the server sent is that nothing was selected, yet the client would submit a value. This is a difference and it is right to act as if it is a difference, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] successful form controls
On Thu, 13 Sep 2007, Garrett Smith wrote: I found a few mistakes in the spec. === 5.1. Successful form controls The controls that are successful are those that are included in the submission (in the form data set) when their form is submitted. All form controls are successful except: Controls with no associated form. Controls that are inside repetition templates (those that are in their forms' templateElements list). Controls that are inside datalist elements. Controls with no name, except if they are image controls. Disabled controls. Checkboxes that are not checked. Radio buttons that are not checked. Submit buttons (including image buttons) that did not initiate the current submission process. Buttons of type button, reset, add, remove, move-up, or move-down. Output controls. File upload controls with no value selected, or with only values that point to non-existent files. Controls do not have to have a value to be successful. === missing: * Readonly controls (just like how it works in HTML 4) These do submit, it is not a mistake that they are not listed. * controls within a fieldset that is disabled Those controls are disabled, so that is covered already. * controls whose associated FORM (either FIELDSET or FORM element) is either disabled or readonly. We currently have no way to disable or mark as readonly an entire form. The WF2 spec does include the attribute disabled for a fieldset, but does not say that disabling a fieldset has *any* effect whatsoever. This, to me, seems to be an oversight. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebSocket support in HTML5
Hi Philipp, After all, more or less the only situation you'd want to use UDP Wrong. But then personally, I'd use UDP for server-generated events, and something other than a context-devoid, connection-less, session-hijackable, bollocks protocol as my middleware backbone; I am clearly 180 degrees in the minority :-) That out of the way, I think the structure in content approach is preferable because in the end it makes the whole feature easier to use and accessible to a much broader range of web authors. Because a WS stream has standardized metadata and delimiters, you can easily build a generic framework that processes those parts for you. Fine, you want structure in content then you stick it on *afterwards*. Please don't impose your particular views on what everyone else's data stream should look like! Some might like chunking, record-type indicators, or data-length sentinels, or something completely different; it's up to them! Anyway, I believe Shannon has come up with a very workable ws.read(bytes) and ws.write(bytes) alternative.Spookily, just like a Socket - amazing. Well done. Note that it was a conscious design decision to make WS incompatible with existing protocols, because the risk for misuse is too great. Excellent, so WebSockets have been deliberately ham-strung by design? Now that explains a lot :-( Even if I was less paranoid I'd still smell a vested interest rat here Yes, you can have all the sockets you want as long as you are forced through our HTTP servers to do it. Cheers Richard Maher - Original Message - From: Philipp Serafin [EMAIL PROTECTED] To: Kristof Zelechovski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, September 29, 2008 7:18 PM Subject: Re: [whatwg] WebSocket support in HTML5 On Sat, Sep 27, 2008 at 12:58 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: If you are in control of the server, you can simulate datagram sockets with one-shot controlled sockets I do not agree with Richard at all, but I have to play devil's advocate here because I think such a simulation would be pretty useless. After all, more or less the only situation you'd want to use UDP outside a LAN is when TCP doesn't fit your needs, e.g. because the flow control does more harm than good to your use-case or because your peers have not enough processing power for a full TCP implementation. Simulating UDP via TCP would pretty much combine the disadvantages of both protocols. Also, you already need a full roudtrip to initiate a TCP connection, a second one to perform the WS handshake and a third one to close the connection. Data not taken into account. You can hardly repeat that for every datagram you want to send. That out of the way, I think the structure in content approach is preferable because in the end it makes the whole feature easier to use and accessible to a much broader range of web authors. Because a WS stream has standardized metadata and delimiters, you can easily build a generic framework that processes those parts for you. This is especially important if you DON'T have full control over the server, which I believe is the case for the majority of smaller sites that use a shared hosting solution. Those hosters usually don't give their clients access to the underlying processes at all. All the clients can do is upload static files and script files that get executed in a restricted environment. It's really hard to integrate pure, persistent connections into such a setup. With WS, a hoster could for example have a demon listen to all incoming WS connections and call the client's scripts whenever a data frame has been received. In short, it's much easier for them to manage persistent connections if there is a standardized structure. And if it's easier for them, hopefully the support for this feature will grow. As for the restriction of unicode data, of course we could just use an octet counting mechanism like HTTP does instead of a fixed delimiter. This would allow arbitrary data inside the WS frames. On the other hand, this might make it easier to spoof existing protocols. Would the benefits of this outweigh the risks? Note that it was a conscious design decision to make WS incompatible with existing protocols, because the risk for misuse is too great. If you need your web app to inerac with a specific service, it should be easy to write a generic proxy that does the handshake, strips out the frame marks and transforms the data. Also, it's not like the other technologies would vanish all of a sudden. If you have sufficient control over your server, you can STILL use Java or Flash sockets. Regards, Philipp Serafin
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Hi Maciej, Does OS X (or the iPhone for that matter) support Java 6 yet? And were all these security bug reports you keep seeing to do with Java in general, or the Apple version in particular? Would Strict Same Origin policy not be useful as an optional (perhaps default) configuration? Cheers Richard Maher - Original Message - From: Maciej Stachowiak [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org; Michal Zalewski [EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 12:22 PM Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web On Sep 26, 2008, at 2:19 PM, Elliotte Rusty Harold wrote: Michal Zalewski wrote: I kinda assumed this suggestion was tongue-in-cheek, but if not - banning cross-domain IFRAMEs to fix one flaw, without providing viable methods for sandboxing untrusted same-origin content, would leave web developers with no tools to deal with quite a few classes of major security issues. It's tongue-in-cheek that I don't expect it to be adopted or seriously considered (this year). It's not tongue-in-cheek in that I very much wish it were adopted. That is, I think it's in the realm of the desirable, not the possible. I am curious what issues you see with same origin content. They certainly exist, but I tend to feel those are orthogonal to the issues at hand, and subject for a separate discussion. I do think we have an existence proof that security in this realm is possible. That's Java. Modulo some outright bugs in VMs (since repaired) the default Java applet security model has worked and worked well since 1.0 beta 1. (1.0 alpha 1 wasn't quite strict enough.) I have seen no security design flaws exposed in Java applets in over ten years. That's why I suspect duplicating Java's security policy in HTML is a safe way forward. I'm skeptical that anything less will suffice. Java's security policy is also looser in some ways. For example, it allows the applet to connect to any port on the origin server. This has at times caused Java applets to be subject to vulnerabilities that did not affect plain HTML+JS+CSS (more recently than in the past 10 years). The general Web same-origin policy considers the port as well as the host to be part of the origin. More generally, I am on Apple's internal incoming security bug list, and I see Java applet security bugs all the time, so I think whatever the strength of the model may be, it does not lead to Java applets being secure in practice. And finally, the key question for whether strict same-origin can work it not one of security but of functionality and usability. The trend in recent years has been for browsers to punch more controlled holes in the same-origin policy to fulfill the frequent desire of Web application developers to communicate with other servers from the client side. This is desirable so that AJAX apps (where most of the logic and functionality is client-side) can make use of third-party Web services APIs, in the same way that native apps can, without having to round-trip through their own server. I do not see this trend reversing any time soon. In conclusion I think limiting the Web to 100% strict same-origin would not be desirable even in an ideal world where compatibility issues are not a concern. I don't expect this to happen, however, because many large players are exploiting existing security design flaws in the web to do things they shouldn't be allowed to do in the first place, especially tracking users. Any scheme that limits the ability of advertisers and others to track users will be strenuously resisted. For the record, neither Apple nor the WebKit project have any strong commercial interest in the ability of advertisers or others to track users. Regards, Maciej
Re: [whatwg] WebSocket websocket-origin
Hear! Hear! - Original Message - From: Shannon [EMAIL PROTECTED] To: Anne van Kesteren [EMAIL PROTECTED] Cc: WHATWG [EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 12:59 PM Subject: Re: [whatwg] WebSocket websocket-origin Anne van Kesteren wrote: What is the reason for doing literal comparison on the websocket-origin and websocket-location HTTP headers? Access Control for Cross-Site Requests is currently following this design for access-control-allow-origin but sicking is complaining about so maybe it should be URL-without-path comparison instead. (E.g., then http://example.org and http://example.org:80 would be equivalent.) I think the temptation to standardise features like access control defeats the point of websockets. Since things like access control and sessions can be readily implemented via CGI interfaces it seems implied that the whole point of websockets is to provide lightweight services. If the service actually needs something like this then the author can perform the check post-handshake using any method they feel like. I don't really feel strongly one way or the other about this particular header but I'm concerned about the slippery-slope of complicating the HTTP handshake to the point where you might as well be using CGI. Maybe the standard should simply recommend sending the header but make no requirement about how it is parsed. That way the service itself can decide whether the check is even necessary and if so whether it should be strict or loose or regex-based without the client automatically hanging up the connection. Shannon
Re: [whatwg] Simplified WebSockets
Hi Shannon, In the absence of Socket Policy Files, this is a good fallback position; the shorter the handshake, the better. Cheers Richard Maher - Original Message - From: Shannon [EMAIL PROTECTED] To: WHAT working group whatwg@lists.whatwg.org Sent: Tuesday, September 30, 2008 4:04 PM Subject: [whatwg] Simplified WebSockets It occurred to me the other day when musing on WebSockets that the handshake is more complicated than required to achieve its purpose and still allows potential exploits. I'm going to assume for now the purpose of the handshake is to: * Prevent unsafe communication with a non-websocket service. * Provide just enough HTTP compatibility to allow proxying and virtual hosting. I think the case has been successfully put that DDOS or command injection are possible using IMG tags or existing javascript methods - however the counter-argument has been made that the presence of legacy issues is not an argument for creating new ones. So with that in mind we should implement WebSockets as robustly as we can. Since we don't at first know what the service is we really need to assume that: * Long strings or certain characters may crash the service. * The service may not be line orientated. * The service may use binary data for communications, rather than text. * Characters outside the ASCII printable range may have special meaning (ie, 'bell' or control characters). * No string is safe, since the service may use string commands and non-whitespace separators. For the sake of argument we'll assume the existence of a service that accepts commands as follows (we'll also assume the service ignores bad commands and continues processing): AUTHENTICATE(user,password);GRANT(user,ALL);DELETE(/some/record);LOGOUT; To feed this command set to the service via WebSockets we use: var ws = new WebSocket(http://server:1024/?;AUTHENTICATE(user,password);GRANT(user,ALL); DELETE(/some/record);LOGOUT;) I have already verified that none of these characters require escaping in URLs. The current proposal is fairly strict about allowed URIs but in my opinion it is not strict enough. We really need to verify we are talking to a WebSocket service before we start sending anything under the control of a malicious author. Now given the huge variety of non-HTTP sub-systems we'll be talking to I don't think a full URL or path is actually a useful part of the handshake. What does path mean to a mail server for instance? Here is my proposal: C = client S = service # First we talk to our proxy, if configured. We know we're talking to a proxy because it's set on the client. C CONNECT server.example.com:1024 HTTP/1.1 C Host: server.example.com:1024 C Proxy-Connection: Keep-Alive C Upgrade: WebSocket/1.0 # Without a proxy we send C HEAD server.example.com:1024 HTTP/1.1 C Host: server.example.com:1024 C Connection: Keep-Alive C Upgrade: WebSocket/1.0 # If all goes well the service will respond with: S HTTP/1.1 200 OK S Upgrade: WebSocket/1.0 or S Some other HTTP response (but no Upgrade header) or S Other non-HTTP response or No response. # If we get a 200 response with Upgrade: WebSocket we *know* we have a WebSocket. Any other response and the client can throw a 'Connection failed' or 'Timeout' exception. The client and server can now exchange any authentication tokens, access conditions, cookies, etc according to service requirements. eg: ws.Send( 'referrer=' + window.location + '\r\n' ); ws.Send( 'channel=' + 'customers' + '\r\n' ); ws.Send( CookiesToServerSyntax() ); The key advantages of this method are: * Simplicity (less handshaking, less parsing, fewer requirements) * Security (No page author control over initial handshake beyond the server name or IP. Removes the risk of command injection via URI.) * Compatibility (HTTP compatible. Proxy and Virtual Hosting compatible. Allows a CGI script to emulate a WebSocket) I'm not saying the current proposal doesn't provide some of these things, just that I believe this proposal does it better. Shannon
Re: [whatwg] WebSocket and proxies
Hi Shannon, Bummer :-( Please don't give up! Sorry if this is a really stupid question (my knowledge of proxy-servers is minimal) but what issues are involved here that have not been solved with a product such as Orbited? http://www.orbited.org/ Look, I've never used it but, if I understand it correctly, it sits behind the proxy-server and traps the Socket traffic and forwards it onto the designated run-o'-the-mill TCP/IP server. Could a similar mechanism(s) not work here? Is it that we're dealing with runtime discovery of public proxy-servers outside any firewalls? Something else? Cheers Richard Maher PS. Much prefer the websocket.read(bytes) and websocket.write(bytes) well done! Please don't forget websocket.peek(bytes). - Original Message - From: Shannon [EMAIL PROTECTED] To: WHAT working group whatwg@lists.whatwg.org Sent: Tuesday, October 14, 2008 7:22 AM Subject: [whatwg] WebSocket and proxies In the process of testing my WebSocket proposal I discovered the CONNECT method has a major restriction. Most proxies disable CONNECT to anything but port 443. The following is from Squid and the Blowfish: -- It is very important that you stop CONNECT type requests to non-SSL ports. The CONNECT method allows data transfer in any direction at any time, regardless of the transport protocol used. As a consequence, a malicious user could telnet(1) to a (very) badly configured proxy, enter something like: ... snip example ... and end up connected to the remote server, as if the connection was originated by the proxy. --- I verified that Squid and all public proxies I tried disable CONNECT by default to non-SSL ports. It's unlikely many internet hosts will have 443 available for WebSockets if they also run a webserver. It could be done with virtual IPs or dedicated hosts but this imposes complex requirements and costs over alternatives like CGI. The availability and capabilities of the OPTIONS and GET protocols also varied from proxy to proxy. The IETF draft related to TLS (http://tools.ietf.org/html/draft-ietf-tls-http-upgrade-05) has this to say: --- 3.2 Mandatory Upgrade If an unsecured response would be unacceptable, a client MUST send an OPTIONS request first to complete the switch to TLS/1.0 (if possible). OPTIONS * HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade --- So according to this draft spec OPTIONS is the only way to do a *mandatory* upgrade of our connection. Once again this failed in testing --- = OPTIONS * HTTP/1.1 = Proxy-Connection: keep-alive = Connection: Upgrade = Upgrade: WebSocket/1.0 = Host: warriorhut.org:8000 = = HTTP/1.0 400 Bad Request = Server: squid/3.0.STABLE8 Other proxies gave different errors or simply returned nothing. The problem may be related to the Upgrade and Connection headers rather than OPTIONS, since I had similar issues using Connection: Upgrade with GET. I had the most success using GET without a Connection: Upgrade header. It seems that the proxy thinks the header is directed at it so it does not pass it on to the remote host. In many cases it will abort the connection. Using the Upgrade: header without Connection allows the Upgrade header through to the actual websocket service. It seems to me that whatever we try in many cases the connection will be silently dropped by the proxy and the reasons will be unclear due to the lack of error handling. There seems to be a wide variation in proxy behaviour for uncommon operations. I suppose proxy developers could fix these issues but whether a significant rollout could be achieved before HTML5 is released is questionable. Given that an asynchronous connection cannot be cached the only reasons remaining for going through a proxy are anonymity and firewall traversal. Automatically bypassing the users proxy configuration to solve the issues above has the potential to break both of these. It would be a significant breach of trust for a UA to bypass the users proxy and some networks only allow connections via a proxy (for security and monitoring). It seems that we're stuck between a rock and hard place here. In light of this I reiterate my earlier suggestion that the time could be better spent providing guidelines for communication via an asynchronous CGI interface. This would allow reuse of existing port 80 and 443 web services which would resolve the cross-domain issues (the CGI can relay the actual service via a backend connection) and most of the proxy issues above (since proxy GET and CONNECT are more reliable on these ports). Shannon
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Wed, 29 Oct 2008 03:42:17 -0400, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2008, Michael A. Puls II wrote: Question though. What about the method=POST case where the query string is kept? For example: form action=mailto:?subject=1+2; method=POST input type=text name=body value=1+2 input type=text name=other value=1 2 input type=submit /form When submitting that, I expect to see: mailto:?subject=1%2B2body=body%3D1%252B2%26other%3D1%25202 submitted to the mail client. The current POST section seems to say that this would be submitted instead: mailto:?subject=1+2body=body%3D1%252B2%26other%3D1+2 In other words, I think spaces in values should be emitted as %20 for POST too and in the case there's a query string present in the action attribute for POST, any + in the hvalues of the query string should be normalized to %2B (to be consistent with a + inside a form control's value that gets converted to %2B) The idea is that the same thing as would be posted to an HTTP server is what is sent using the e-mail body, so I think we'd want the exact same + behavior as normally. O.K., but in the case of the + that's in the mailto URI in the action attribute, the author means a '+' and not a space (they're allowed to be left in raw form in a mailto URI). If it gets sent to a server, the + will be treated as a space, which is not what is intended. The workaround is of course for the author to make sure to encode that + as %2B (or never use anything but action=mailto:; even for POST). But, for good measure, it seems like the UA should fix that if the + will ever end up in an HTTP URI. Of course right now, browsers only pass the data as a mailto URI to an email program, so the + from the query string will be a + and come out fine in the compose window. As for spaces in form control values coming out as + (for POST) in a programs's body field, that's not as big of a deal as there's no use-case to *see* any of the data *like that* anyway. But it does seem incorrect to encode mailto spaces as + though. However, if for POST, if everything after 'mailto:' in the action attribute was dropped (like get) and all you ever had was mailto:?body=encoded_stuff that was POSTed, then the spec could say that the value you might see in the body field represents *HTTP* url encoded data. Or, the spec could say that if the protocol in the action attribute is mailto:, +s in the action attribute have to be encoded as %2B and spaces in the action attribute have to be encoded as %20. Then, the validator can catch that and the spec can say (for POST), that the body hvalue that gets generated from the form represents *HTTP* form data. Then, it'll be clear why +s in the value are represented as + instead of %20. Or, if it's O.K. for a UA's URI normalizer/resolver to take action=mailto:?subject=1+2 3 and normalize that to action=mailto:?subject=1%2B2%203; for use with the form's .action getter, I guess that might solve it to. Of course, there's no use for POST and action=mailto:; right now, so I guess we have time to fix things later if they become a problem. Thanks On a side, if you look at the 'if (form.method == post)' condition in http://shadow2531.com/opera/userjs/BeforeMailtoURL.js, you'll see how I handle this. (The form dataset generation is not as complete as it should be though, but doing that seems complicated. Wish browsers had a form.generateDataset() function) -- Michael
[whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
Ian Hickson schrieb: On Tue, 28 Oct 2008, Markus Ernst wrote: [...] I consider a total re-thinking of select, input type=checkbox and input type=radio elements as highly desirable, though I see that this might cause more serious backwards compatiblity problems than for example removing the font tag. One possible solution could be using the select tag with a type attribute: label for=genderGender:/label select id=gender name=gender type=boxgroup option value= /option option value=mMale/option option value=fFemale/option /select I don't understand what problem you are trying to solve here. Changing a group of radio buttons resp. checkboxes into a select element, or vice-versa, needs a non-trivial amount of work. This applies to both HTML coding and DOM access. Consider a form with some quite big radio button groups, and now you have do add some more options. After you are done, your boss says: Ok, great work... but this looks too ugly now, just change it into those dropdown kind of things. Also, if you want to achieve the same via DOM access requires quite some coding amount, you have to build a totally different tree of elements, instead of one line: document.getElementById(gender).type = dropdown; On Tue, 28 Oct 2008, Tab Atkins Jr. wrote: I haven't given it serious thought, but as far as I can tell his proposed solution (piling all four display types onto the select tag) would work wonderfully as a semantic consolidation/simplification, and be nicely backwards-compatible. There are still good reasons to support keeping the input types of radio and checkboxes, of course (frex, wrapping a form around a list, and putting an input within each li), but this proposal would simplify the most common case. I don't see what problem this solves. What's wrong with what we have now? We have similar things treated in different ways. To illustrate this, have a look unordered and ordered lists, which are similar, too. Consider ul and ol would have the same kind of different syntaxes; say, the ul element would work like we know it, but to make an ordered list we would have to write something like: p type=orderedlist listposition value=list position 1 listposition value=list position 2 /p Now simply changing an ordered into an unordered list would cause an annoying amount of re-writing, such as changing a radio button group into a select element does.
[whatwg] Offline Cache iframe inheritance
The spec says when an iframe (a child browsing context) doesn't refer a manifest in the html tag it has to inherit cache from its parent's document. 1. This should be restricted to the same origin because when an offline application loads in an iframe a site (an advertisement or what ever site) that site has full access to window.applicationCache object and can inject to the cache any kind of resource from any origin without user notification. This resource is then carried among cache versions until explicitly overwritten or deleted from the cache. 2. When a completely different site from a different origin, in this case not malicious, is loaded in an iframe from inside of an offline application, the site would probably be completely broken - the resources on the page could not be load because of the associated cache of probably unrelated offline application. 3. Master documents are associated with the cache after the cache update finished. I percept this step as a way to make the offline application document be in a consistent state after cache update finished w/o need to refresh the top document, right? But, iframes that should inherit cache from its parents are not associated (there were no cache at moment of load/cache selection algorithm and there is not visible in the spec to do the association later). Workaround is to add reference to the manifest to all iframe'd documents, but in that case there is no need to have a special handling for such child contexts in case they don't refer a manifest. All these points lead me to opinion to remove the cache inheritance for child contexts feature. The manifest reference will not involve any new updates because they are atomically cumulated and let different sites fall off the offline app context. Also we don't have any cross-site security risks, even just potential. Potentially, to preserve inheritance and save some work to web developers, we may introduce explicit attribute to iframe by defining the manifest to use or just say to let the context inherit the cache from the parent. -hb-
Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
On Wed, Oct 29, 2008 at 9:49 AM, Markus Ernst [EMAIL PROTECTED] wrote: Consider a form with some quite big radio button groups, and now you have do add some more options. After you are done, your boss says: Ok, great work... but this looks too ugly now, just change it into those dropdown kind of things. Honestly, this seems like a presentational issue to me. Isn't CSS3's Basic UI module (http://www.w3.org/TR/css3-ui/) enough to handle that? Correct me if I'm wrong, but it seems that the properties there would allow you to present a radiobutton group as a dropdown menu, and vice-versa. To illustrate this, have a look unordered and ordered lists, which are similar, too. Consider ul and ol would have the same kind of different syntaxes; say, the ul element would work like we know it, but to make an ordered list we would have to write something like: p type=orderedlist listposition value=list position 1 listposition value=list position 2 /p Now simply changing an ordered into an unordered list would cause an annoying amount of re-writing, such as changing a radio button group into a select element does. Even in that case, CSS3 (and I think even CSS2) would perfectly allow you to render an originally unordered list as an ordered one (with different choices of numbering style), and vice-versa, without changing anything on the markup. In summary, if you only need to change the presentation, then it's a CSS issue (and CSS seems to deal well enough with it); and if you are really changing the semantics and inherent structure of the document, then the need to non-trivially adjust the markup is unavoidable: after all, the semantics and structure is what the markup is actually defining. Just my thoughts.
[whatwg] Early feedback on header association algorithm
1. On this part: If there is a header cell in the table http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#concept-table whose corresponding |th http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-th-element| element has an ID that is equal to the value of id, then assign the first such header cell in tree order to the data cell. I don't want to implement a special local table only getElementByIdInTable. I'd rather have this reworded to something like If there is an element in the document with a corresponding ID (via getElementById) equal to the value of /id/, and it is a header cell in the current table, then assign it to the data cell. 2. The larger part of algorithm is upside down for our needs. I see a use case for providing what headers are associated with a cell, but not the other way around. Typically an AT will want to know what labels or headers to present to a user when a user navigates to a cell. Therefore, I wish the entire algorithm was flipped and tells us what headers are a match for a given cell. 3. The one piece of information we do need when we are on a given th is whether to expose it with ROLE_ROWHEADER or ROLE_COLUMNHEADER in our GetRole() implementation. If scope isn't row, rowgroup, col or colgroup then we'll need to base that on the position in the table. It seems fairly obvious if the th is in an edge (but not corner) position, but other cases are less obvious. I haven't gone through the algorithm in fine detail yet, mostly because of comment #2. We'd have to turn the algorithm inside out in order to evaluate it. - Aaronj
Re: [whatwg] video tag : loop for ever
Silvia Pfeiffer wrote: On Sat, Oct 25, 2008 at 6:18 PM, Jonas Sicking [EMAIL PROTECTED] wrote: 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. It sounds to me like there are 3 proposals: 1. Have 'start' and 'end' as content attributes. This means that they are accessible though getAttribute/setAttribute and video start=... end=... in the markup). They are also available as DOM attributes, i.e. myVideo.start = ... myVideo.end = ... 2. Allow a fragment identifier to be specified in the src that specifies a part of the file to be played. Expose DOM attributes to control the start and the end, i.e. myVideo.start = ..., myVideo.end = ... Setting these attributes would change the value of the fragment identifier in the src attribute and thus which part is being played 3. Allow a fragment identifier to be specified in the src that specifies a part of the file to be played. Don't expose myVideo.start or myVideo.end DOM attributes. Instead address the use case of having multiple sound effects in a single downloaded file in some other way (for example using zip files, playlists, or simply letting people set the fragment identifier manually using the src attribute) There is also the somewhat orthogonal issue of if the default UI should only display the selected range (be it if the selection happens through content start/end attributes or a fragment identifier). I would personally be fine with all three proposals. The risk with proposals 1 and 2 that I see is that a implementation might be expected to download the whole file even if just part of it is specified to be played so that transitions can happen rapidly. Just to clarify: the specification of a media fragment in a URI is supposed to enable receiving of just the specified fragment, not only the full resource. The media fragments Working Group is creating a specificaton that will enable that. I actually think that your options 2 and 3 are orthogonal. 2 is about playing (and looping over) a media fragment, while 3 is about creating a playlist of multiple media resources (potentially also having a fragment specifier). Sorry, I think I was being unclear. Maciej (and I think others) have suggested that it would be useful if it was possible to allow audio to be used such that a single file can be downloaded that contains multiple sound effects, and then use javascript to play different sound effects contained in that file at various times. For example someone creating a shoot-em-up game might create a file that contains the sound for shoot weapon, enemy exploding, player dying, and player finishes level. It can then when appropriate use javascript to play any one of these sound effects. I have heard three proposed solutions for this use case: 1. Have start=.. and end=.. content attributes. This means that they are accessible though getAttribute/setAttribute and audio start=... end=... in the markup). They are also available as DOM attributes, i.e. myAudio.start = ... myAudio.end = ... So to play a specific sound effect script would do: myAudio.start = enemyExplodingStart; myAudio.end = enemyExplodingEnd; myAudio.play(); 2. Allow a fragment identifier to be specified in the src that specifies a part of the file to be played. Expose DOM attributes to control the start and the end, i.e. myAudio.start = ..., myAudio.end = ... Setting these attributes would change the value of the fragment identifier in the src attribute and thus which part is being played. To play a specific sound effect script would do: myAudio.start = enemyExplodingStart; myAudio.end = enemyExplodingEnd; myAudio.play(); 3. Not add specific support to audio for now. Instead rely on specifications such as xspf playlists or jar protocols. It would still be possible for a page to do: myAudio.src = audioURL + #start= + enemyExplodingStart + ;end= + enemyExplodingEnd;
Re: [whatwg] video tag : loop for ever
Am Mittwoch, den 29.10.2008, 11:16 -0700 schrieb Jonas Sicking: Maciej (and I think others) have suggested that it would be useful if it was possible to allow audio to be used such that a single file can be downloaded that contains multiple sound effects, and then use javascript to play different sound effects contained in that file at various times. For example someone creating a shoot-em-up game might create a file that contains the sound for shoot weapon, enemy exploding, player dying, and player finishes level. It can then when appropriate use javascript to play any one of these sound effects. Remind me again what is wrong with multiple audio elements ? Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] video tag : loop for ever
On Wed, Oct 29, 2008 at 6:16 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Maciej (and I think others) have suggested that it would be useful if it was possible to allow audio to be used such that a single file can be downloaded that contains multiple sound effects, and then use javascript to play different sound effects contained in that file at various times. For example someone creating a shoot-em-up game might create a file that contains the sound for shoot weapon, enemy exploding, player dying, and player finishes level. It can then when appropriate use javascript to play any one of these sound effects. Wouldn't multiple audio elements be better here? They'd point to the actual same file, but different fragments. That would even make the script less bloated (just selecting each element, instead of explicitly getting the appropriate fragment from the master file each time you need it). This brings the additional advantage that, in the event the server does support file fragments, only the actually required fragments will be downloaded. And, if the server doesn't support fragments, then there is still no reason why the UA would download the same whole file more than once for a single page (maybe there is a need to ensure the UA isn't that silly for such cases, however). Furthermore, the idea of having multiple sound effects in a single file is just a matter of packaging, probably mere convenience, and multiple audio elements would better reflect the actual semantics: these are separate sound effects actually.
Re: [whatwg] Early feedback on header association algorithm
The problem of table header identifiers is a reflection a general problem of locality in markup: you cannot use templates without renaming the identifiers, which is the easy part, and replacing the internal references to the identifiers, which is the hard part. If you find this remark silly because a solution is well-known, please forgive my illiterate comment above; in that case, that solution should be applied. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Leventhal Sent: Wednesday, October 29, 2008 6:43 PM To: WHATWG List Subject: [whatwg] Early feedback on header association algorithm 1. On this part: If there is a header cell in the table http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.ht ml#concept-table whose corresponding |th http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.ht ml#the-th-element| element has an ID that is equal to the value of id, then assign the first such header cell in tree order to the data cell. I don't want to implement a special local table only getElementByIdInTable. I'd rather have this reworded to something like If there is an element in the document with a corresponding ID (via getElementById) equal to the value of /id/, and it is a header cell in the current table, then assign it to the data cell. 2. The larger part of algorithm is upside down for our needs. I see a use case for providing what headers are associated with a cell, but not the other way around. Typically an AT will want to know what labels or headers to present to a user when a user navigates to a cell. Therefore, I wish the entire algorithm was flipped and tells us what headers are a match for a given cell. 3. The one piece of information we do need when we are on a given th is whether to expose it with ROLE_ROWHEADER or ROLE_COLUMNHEADER in our GetRole() implementation. If scope isn't row, rowgroup, col or colgroup then we'll need to base that on the position in the table. It seems fairly obvious if the th is in an edge (but not corner) position, but other cases are less obvious. I haven't gone through the algorithm in fine detail yet, mostly because of comment #2. We'd have to turn the algorithm inside out in order to evaluate it. - Aaronj
[whatwg] Implement XMLHttpRequest interface subset on HTMLDocument
I realized that the HTTP response headers exposed in the HTMLDocument
interface http://www.w3.org/html/wg/html5/#htmldocument are limited:
referrer, cookie, lastModified, charset, characterSet.
It would be very useful if a script could get *all* of the response headers,
the raw entity body, and the HTTP status: basically it would be great if the
HTMLDocument interface implemented a subset of of the XMLHttpRequest spec,
namely the parts which have to do with the response (e.g.
getAllResponseHeaders(), getResponseHeader(), status, and others which
appear below). The HTMLDocument interface already has a readyState property
which XMLHttpRequest also has, but the HTMLDocument interface lacks XHR's
onreadystatechange attribute.
If this subset were implemented on HTMLDocument, then scripts would be able
to determine if the page if a 404 or get any other arbitrary information
that is passed in the response header.
Here's a proposed extension to the HTMLDocument interface with some comments
to explain the semantics:
interface HTMLDocument {
...
//another way to get DOMContentLoaded event; the readyState would start
out as LOADING
attribute EventListener onreadystatechange;
// state
const unsigned short UNSENT = 0;
const unsigned short OPENED = 1;
const unsigned short HEADERS_RECEIVED = 2;
const unsigned short LOADING = 3;
const unsigned short DONE = 4;
readonly attribute unsigned short readyState; //already in HTML 5
// request
void abort(); //complements window.stop(): stops the contained document
instead of the associated resources
// response
DOMString getAllResponseHeaders();
DOMString getResponseHeader(in DOMString header);
readonly attribute DOMString responseText; //the non-parsed content of the
document
readonly attribute Document responseXML;
readonly attribute unsigned short status;
readonly attribute DOMString statusText;
}
Re: [whatwg] Implement XMLHttpRequest interface subset on HTMLDocument
What should the property HTMLDocument.responseXML represent?
Chris
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter
Sent: Wednesday, October 29, 2008 8:06 PM
To: [EMAIL PROTECTED]
Cc: Ian Hickson; Anne van Kesteren
Subject: [whatwg] Implement XMLHttpRequest interface subset on HTMLDocument
I realized that the HTTP response headers exposed in the HTMLDocument
interface http://www.w3.org/html/wg/html5/#htmldocument are limited:
referrer, cookie, lastModified, charset, characterSet.
It would be very useful if a script could get *all* of the response headers,
the raw entity body, and the HTTP status: basically it would be great if the
HTMLDocument interface implemented a subset of of the XMLHttpRequest spec,
namely the parts which have to do with the response (e.g.
getAllResponseHeaders(), getResponseHeader(), status, and others which
appear below). The HTMLDocument interface already has a readyState property
which XMLHttpRequest also has, but the HTMLDocument interface lacks XHR's
onreadystatechange attribute.
If this subset were implemented on HTMLDocument, then scripts would be able
to determine if the page if a 404 or get any other arbitrary information
that is passed in the response header.
Here's a proposed extension to the HTMLDocument interface with some comments
to explain the semantics:
interface HTMLDocument {
...
//another way to get DOMContentLoaded event; the readyState would start
out as LOADING
attribute EventListener onreadystatechange;
// state
const unsigned short UNSENT = 0;
const unsigned short OPENED = 1;
const unsigned short HEADERS_RECEIVED = 2;
const unsigned short LOADING = 3;
const unsigned short DONE = 4;
readonly attribute unsigned short readyState; //already in HTML 5
// request
void abort(); //complements window.stop(): stops the contained document
instead of the associated resources
// response
DOMString getAllResponseHeaders();
DOMString getResponseHeader(in DOMString header);
readonly attribute DOMString responseText; //the non-parsed content of the
document
readonly attribute Document responseXML;
readonly attribute unsigned short status;
readonly attribute DOMString statusText;
}
Re: [whatwg] Implement XMLHttpRequest interface subset on HTMLDocument
If the interface were implemented as-is, document.responseXML would just be
a reference back to the document object.
So if the document is XML, then document === document.responseXML
On Wed, Oct 29, 2008 at 12:14 PM, Kristof Zelechovski [EMAIL PROTECTED]
wrote:
What should the property HTMLDocument.responseXML represent?
Chris
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Weston Ruter
*Sent:* Wednesday, October 29, 2008 8:06 PM
*To:* [EMAIL PROTECTED]
*Cc:* Ian Hickson; Anne van Kesteren
*Subject:* [whatwg] Implement XMLHttpRequest interface subset on
HTMLDocument
I realized that the HTTP response headers exposed in the HTMLDocument
interface http://www.w3.org/html/wg/html5/#htmldocument are limited:
referrer, cookie, lastModified, charset, characterSet.
It would be very useful if a script could get *all* of the response
headers, the raw entity body, and the HTTP status: basically it would be
great if the HTMLDocument interface implemented a subset of of the
XMLHttpRequest spec, namely the parts which have to do with the response
(e.g. getAllResponseHeaders(), getResponseHeader(), status, and others which
appear below). The HTMLDocument interface already has a readyState property
which XMLHttpRequest also has, but the HTMLDocument interface lacks XHR's
onreadystatechange attribute.
If this subset were implemented on HTMLDocument, then scripts would be able
to determine if the page if a 404 or get any other arbitrary information
that is passed in the response header.
Here's a proposed extension to the HTMLDocument interface with some
comments to explain the semantics:
interface HTMLDocument {
...
//another way to get DOMContentLoaded event; the readyState would start
out as LOADING
attribute EventListener onreadystatechange;
// state
const unsigned short UNSENT = 0;
const unsigned short OPENED = 1;
const unsigned short HEADERS_RECEIVED = 2;
const unsigned short LOADING = 3;
const unsigned short DONE = 4;
readonly attribute unsigned short readyState; //already in HTML 5
// request
void abort(); //complements window.stop(): stops the contained document
instead of the associated resources
// response
DOMString getAllResponseHeaders();
DOMString getResponseHeader(in DOMString header);
readonly attribute DOMString responseText; //the non-parsed content of
the document
readonly attribute Document responseXML;
readonly attribute unsigned short status;
readonly attribute DOMString statusText;
}
Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
The meaning of HTMLDocument.responseXML looks a bit strange and
unexpected: a property of an object bound to the object itself by
definition. I would suggest leaving that one out.
Chris
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter
Sent: Wednesday, October 29, 2008 8:19 PM
To: Kristof Zelechovski
Cc: [EMAIL PROTECTED]; Ian Hickson; Anne van Kesteren
Subject: Re: [whatwg] Implement XMLHttpRequest interface subset
onHTMLDocument
If the interface were implemented as-is, document.responseXML would just be
a reference back to the document object.
So if the document is XML, then document === document.responseXML
On Wed, Oct 29, 2008 at 12:14 PM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
What should the property HTMLDocument.responseXML represent?
Chris
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter
Sent: Wednesday, October 29, 2008 8:06 PM
To: [EMAIL PROTECTED]
Cc: Ian Hickson; Anne van Kesteren
Subject: [whatwg] Implement XMLHttpRequest interface subset on HTMLDocument
I realized that the HTTP response headers exposed in the HTMLDocument
http://www.w3.org/html/wg/html5/#htmldocument interface are limited:
referrer, cookie, lastModified, charset, characterSet.
It would be very useful if a script could get *all* of the response headers,
the raw entity body, and the HTTP status: basically it would be great if the
HTMLDocument interface implemented a subset of of the XMLHttpRequest spec,
namely the parts which have to do with the response (e.g.
getAllResponseHeaders(), getResponseHeader(), status, and others which
appear below). The HTMLDocument interface already has a readyState property
which XMLHttpRequest also has, but the HTMLDocument interface lacks XHR's
onreadystatechange attribute.
If this subset were implemented on HTMLDocument, then scripts would be able
to determine if the page if a 404 or get any other arbitrary information
that is passed in the response header.
Here's a proposed extension to the HTMLDocument interface with some comments
to explain the semantics:
interface HTMLDocument {
...
//another way to get DOMContentLoaded event; the readyState would start
out as LOADING
attribute EventListener onreadystatechange;
// state
const unsigned short UNSENT = 0;
const unsigned short OPENED = 1;
const unsigned short HEADERS_RECEIVED = 2;
const unsigned short LOADING = 3;
const unsigned short DONE = 4;
readonly attribute unsigned short readyState; //already in HTML 5
// request
void abort(); //complements window.stop(): stops the contained document
instead of the associated resources
// response
DOMString getAllResponseHeaders();
DOMString getResponseHeader(in DOMString header);
readonly attribute DOMString responseText; //the non-parsed content of the
document
readonly attribute Document responseXML;
readonly attribute unsigned short status;
readonly attribute DOMString statusText;
}
Re: [whatwg] video tag : loop for ever
On Wed, Oct 29, 2008 at 11:35 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Multiple AUDIO elements require one request per element unless they refer to the same stream or they use the data URL scheme, or the whole page is packaged as multipart/mixed, which would indeed be nice for such sets of small resources if only user agents supported it. This is a great use case for the jar: protocol. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
Providing the original document tree before transformation in HTMLDocument.responseXML makes sense. In that case, the Document returned should be immutable, just as a DOMString is; I am not sure how to declare it in IDL. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter Sent: Wednesday, October 29, 2008 8:35 PM To: Kristof Zelechovski Cc: [EMAIL PROTECTED]; Ian Hickson; Anne van Kesteren Subject: Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument This is not completely strange or unexpected construct, since window == window.self. Furthermore, having a HTMLDocument.responseXML would be useful in the case that an XSLT stylesheet outputs HTML, plain text, or something else; in such a case, it would be very useful to get the original responseXML. Note that I don't envision this responseXML being any sort of shadow DOM; I mean, if XSLT did transform the XML data, making a change to responseXML would not cause the XSLT engine to re-parse the updated responseXML. Maybe this would be useful, but it seems overly complicated. On Wed, Oct 29, 2008 at 12:26 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: The meaning of HTMLDocument.responseXML looks a bit strange and unexpected: a property of an object bound to the object itself by definition. I would suggest leaving that one out. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter Sent: Wednesday, October 29, 2008 8:19 PM To: Kristof Zelechovski Cc: [EMAIL PROTECTED]; Ian Hickson; Anne van Kesteren Subject: Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument If the interface were implemented as-is, document.responseXML would just be a reference back to the document object. So if the document is XML, then document === document.responseXML On Wed, Oct 29, 2008 at 12:14 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: What should the property HTMLDocument.responseXML represent? Chris
Re: [whatwg] video tag : loop for ever
There are multiple ways to encapsulate heterogeneous data in documents: application resources (the res URL scheme), file archives (jar, zip, shar, tar, whatever). Of those possibilities, MIME is most Web-friendly IMHO, although the downside is that the transmitted resource grows. This should not be a problem for small resources and using it for big resources does not gain you anything, so you just get it as a separate file. And, as has been previously discussed, jar is not a protocol, it is a content type. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan Sent: Wednesday, October 29, 2008 8:36 PM To: Kristof Zelechovski Cc: whatwg; Nils Dagsson Moskopp Subject: Re: [whatwg] video tag : loop for ever On Wed, Oct 29, 2008 at 11:35 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Multiple AUDIO elements require one request per element unless they refer to the same stream or they use the data URL scheme, or the whole page is packaged as multipart/mixed, which would indeed be nice for such sets of small resources if only user agents supported it. This is a great use case for the jar: protocol.
Re: [whatwg] Proposal: Allow block content inside label element
Of course, a Windows check box label corresponds to nothing in HTML! I have extrapolated Windows GUI where a check box has a TITLE. This Windows TITLE property has no counterpart in HTML. Sorry for the confusion. I should have added Please answer yes or no because I would like to have a definitive statement of your advice to Microsoft Internet Explorer. Do you think the Internet Explorer should abandon support for LABEL behavior as defined in HTML 4? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 29, 2008 6:06 AM To: Křištof Želechovski Cc: 'WHAT-WG' Subject: Re: [whatwg] Proposal: Allow block content inside label element On Wed, 29 Oct 2008, Křištof Želechovski wrote: The text that Windows places near check boxes and radio buttons corresponds to INPUT[value], not to LABEL. No, the value= attribute is the internal value for submission purposes and is not UI text. Internet Explorer redirects focus from labels to obey HTML 4; according to HTML 5, it should stop. Should it really? And what should happen with labels on HTML 4 pages? The user experience will be inconsistent. The whole point is to make the user experience within a single OS be consistent.
Re: [whatwg] Proposal: Allow block content inside label element
On Wed, 29 Oct 2008, Křištof Želechovski wrote: Of course, a Windows check box label corresponds to nothing in HTML! This is incorrect. A Windows checkbox label corresponds to the contents of a label element associated with an input type=checkbox element. Do you think the Internet Explorer should abandon support for LABEL behavior as defined in HTML 4? Insofar as I think they should do whatever the platform does, I believe that they should abandon a strict reading of HTML4, yes. However, at the end of the day, this is up to them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Allow block content inside label element
We have a different opinion on what corresponds means. A label in HTML is detached, both logically and graphically, while a TITLE in Windows GUI is attached. You can translate from Windows GUI to HTML - but this direction is not interesting; you cannot translate from HTML to Windows GUI, at least not in all cases, without reorganizing content. So you cannot implement support for HTML label in terms of Windows TITLE. Chris -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 9:20 PM To: Křištof Želechovski Cc: 'WHAT-WG' Subject: RE: [whatwg] Proposal: Allow block content inside label element On Wed, 29 Oct 2008, Křištof Želechovski wrote: Of course, a Windows check box label corresponds to nothing in HTML! This is incorrect. A Windows checkbox label corresponds to the contents of a label element associated with an input type=checkbox element.
Re: [whatwg] Proposal: Allow block content inside label element
On Wed, 29 Oct 2008, Křištof Želechovski wrote: We have a different opinion on what corresponds means. A label in HTML is detached, both logically and graphically, while a TITLE in Windows GUI is attached. You can translate from Windows GUI to HTML - but this direction is not interesting; you cannot translate from HTML to Windows GUI, at least not in all cases, without reorganizing content. So you cannot implement support for HTML label in terms of Windows TITLE. Sure, nobody said there was a 1:1 mapping from HTML to Win32. We're just talking about UI concepts, the actual implementation details at the API level are completely irrelevant to the discussion. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Early feedback on header association algorithm
I shall try to explain the general problem in more detail. Suppose you have a template that inserts a table T into the Web page, and some elements in the table have identifiers. It is not a safe operation because the identifiers can conflict with element identifiers on the containing page, or element identifiers within code snippets submitted to the template as arguments. In order to preserve uniqueness of identifiers, you can either rename them or use GUIDs. The first operation is tricky if the identifiers are referred to by other attributes and scripts; the other is unintuitive and seems like an overshoot (because what you need are page-unique identfiers, not globally unique identifiers). If I had a solution to this problem, I would be happy to submit it. I was hoping for someone smarter than me to stand up and say Oh, this is easy. I also think this problem is not restricted to HTML, all markup languages are affected. My generic solution would be to add a global attribute named local-id and add a method HTMLElement.getChildById(arg) to return the nearest (in terms of the least depth) child of the element with the local-id equal to arg, or the element itself. (This is the reverse of syntactic scoping). Elements that have properties containing referring to other identifiers could locate the referenced elements by local identifiers from the perspective of a well-defined ancestor (FORM for LABEL, TABLE for TD, etc.) But I am far from being sure that it is the right thing to require and that it would solve a significant class of problems in a satisfactory way. Bonus example: P id=PA local-id=a .../P TABLE ID=T THEAD TR TH id=TA local-id=a ... TBODY TR TD some-property-that-refers-to-an-id=a /TABLE Now T.getChildById(a) === TA. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 29, 2008 8:16 PM To: Kristof Zelechovski Cc: 'WHATWG List' Subject: Re: [whatwg] Early feedback on header association algorithm On Wed, 29 Oct 2008, Kristof Zelechovski wrote: The problem of table header identifiers is a reflection a general problem of locality in markup: you cannot use templates without renaming the identifiers, which is the easy part, and replacing the internal references to the identifiers, which is the hard part. If you find this remark silly because a solution is well-known, please forgive my illiterate comment above; in that case, that solution should be applied. Could I ask you to phrase your feedback in terms of changes you would like to see to the spec, ideally with examples? People have told me (and I concurr) that they have trouble following your feedback. (It is especially hard since you don't quote context.)
Re: [whatwg] Early feedback on header association algorithm
On Wed, 29 Oct 2008, Kristof Zelechovski wrote: I shall try to explain the general problem in more detail. Suppose you have a template that inserts a table T into the Web page, and some elements in the table have identifiers. It is not a safe operation because the identifiers can conflict with element identifiers on the containing page, or element identifiers within code snippets submitted to the template as arguments. In order to preserve uniqueness of identifiers, you can either rename them or use GUIDs. Just prefix them with the name of the template. In general, this feedback seems unrelated to the header association algorithm. Could I ask you to send feedback like this in new threads instead of replying to tangentially related e-mails? 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 Thu, Oct 30, 2008 at 7:38 AM, Eduard Pascual [EMAIL PROTECTED] wrote: Wouldn't multiple audio elements be better here? I can see use cases where multiple audio elements might not be as useful as one containing multiple samples. I might have a single audio file containing 500 'parts of speech' which I form together to make my browser speak lojban, or create some sound effect. I don't want 500 audio elements. Each instantiation of an audio element requires that audio element to parse the metadata. I can't call play on that audio element until 'metadataloaded' occurs so I have to wait for the event and structure my code around that and the subsequent delay. I'm not sure that type of use case is very likely though. In my JavaScript 8080 emulator I took the approach of multiple audio elements for the sounds and it works quite well. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video tag : loop for ever
Am Donnerstag, den 30.10.2008, 13:19 +1300 schrieb Chris Double: I'm not sure that type of use case is very likely though. In my JavaScript 8080 emulator Wait, what ?
Re: [whatwg] video tag : loop for ever
On Thu, Oct 30, 2008 at 1:46 PM, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: I'm not sure that type of use case is very likely though. In my JavaScript 8080 emulator Wait, what ? http://www.bluishcoder.co.nz/js8080 Needs a fast modern browser with recent canvas support. Webkit and Firefox nightly builds work. 'Enable Sound' loads multiple audio elements with the sound files and uses 'play' when the sound should play. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video tag : loop for ever
Eduard Pascual wrote: On Wed, Oct 29, 2008 at 6:16 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Maciej (and I think others) have suggested that it would be useful if it was possible to allow audio to be used such that a single file can be downloaded that contains multiple sound effects, and then use javascript to play different sound effects contained in that file at various times. For example someone creating a shoot-em-up game might create a file that contains the sound for shoot weapon, enemy exploding, player dying, and player finishes level. It can then when appropriate use javascript to play any one of these sound effects. Wouldn't multiple audio elements be better here? They'd point to the actual same file, but different fragments. That would even make the script less bloated (just selecting each element, instead of explicitly getting the appropriate fragment from the master file each time you need it). This brings the additional advantage that, in the event the server does support file fragments, only the actually required fragments will be downloaded. The whole idea was to make a single HTTP request to the server. Doesn't seem like your proposal accomplishes that. As I said, I'm fine with not satisfying this use case (of allowing multiple sound effects downloaded in a single request). But that was the use case that was cited. / Jonas
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On Oct 29, 2008, at 6:40 PM, Kristof Zelechovski wrote: Declare INPUT[type=mailing-list] instead of INPUT[type=emails], please. Type=emails is ugly and confusing (as it seems to expect messages). ... emails is indeed ugly, but mailing-list would be even worse. A mailing list usually has a single address. -- Matthew Paul Thomas http://mpt.net.nz/ ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)---
Re: [whatwg] video tag : loop for ever
On Thu, Oct 30, 2008 at 11:52 AM, Jonas Sicking [EMAIL PROTECTED] wrote: Eduard Pascual wrote: On Wed, Oct 29, 2008 at 6:16 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Maciej (and I think others) have suggested that it would be useful if it was possible to allow audio to be used such that a single file can be downloaded that contains multiple sound effects, and then use javascript to play different sound effects contained in that file at various times. For example someone creating a shoot-em-up game might create a file that contains the sound for shoot weapon, enemy exploding, player dying, and player finishes level. It can then when appropriate use javascript to play any one of these sound effects. Wouldn't multiple audio elements be better here? They'd point to the actual same file, but different fragments. That would even make the script less bloated (just selecting each element, instead of explicitly getting the appropriate fragment from the master file each time you need it). This brings the additional advantage that, in the event the server does support file fragments, only the actually required fragments will be downloaded. The whole idea was to make a single HTTP request to the server. Doesn't seem like your proposal accomplishes that. As I said, I'm fine with not satisfying this use case (of allowing multiple sound effects downloaded in a single request). But that was the use case that was cited. No, that's not a use case - that's a proposed solution for the use case of having multiple small audio files required for playback of one larger audio presentation. If another solution can satisfy this need with appropriate qos, then I don't think we need to worry further. Regards, Silvia.
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On Thu, Oct 30, 2008 at 1:16 AM, Matthew Paul Thomas [EMAIL PROTECTED] wrote: On Oct 29, 2008, at 6:40 PM, Kristof Zelechovski wrote: Declare INPUT[type=mailing-list] instead of INPUT[type=emails], please. Type=emails is ugly and confusing (as it seems to expect messages). ... emails is indeed ugly, but mailing-list would be even worse. A mailing list usually has a single address. What about multi-email, email-list or email-addresses? The last one is the one I most like, and the most explicit, with the only (minor) drawback that it's the longest. Anyway, that's just a suggestion. BTW, the same argument could be made on type=email, since someone could easily think it expects an entire message.
Re: [whatwg] video tag : loop for ever
On Thu, Oct 30, 2008 at 12:52 AM, Jonas Sicking [EMAIL PROTECTED] wrote: The whole idea was to make a single HTTP request to the server. Doesn't seem like your proposal accomplishes that. Indeed, it doesn't. It doesn't seem that the recent messages mentioned that need neither. Anyway, for the case of multiple queries to the same object (ie: identical URI at least until the # part), I think there should be some way to ensure that a single request for that object is made, at least optionally; but I think this would stray out-of-topic under this discussion's subject.
Re: [whatwg] Web Forms: change event
Ian Hickson wrote: On Wed, 6 Jun 2007, Sander wrote: The specs say that for select ...the change event shall be fired when the selection is completed Does this mean that, when using a keyboard for navigation, the change event is fired when the user hits 'enter' or when she navigates from one option to another? I assume it's the former, but I just to be sure as selectboxes with change event handlers are often (ab)used for navigation purposes. So, can anyone confirm my assumption? Thanks. The HTML 4 specification[1] says: | The onchange event occurs when a control loses the input focus and its | value has been modified since gaining focus. A test case[2] I found does expects that onchange fires when the select has been changed and while it still has focus. | Procedure | 1. Using the keyboard or an assistive technology that emulates the | keyboard, move focus to the select control. | 2. Using the keyboard or an assistive technology that emulates the | keyboard, select a value from the menu to trigger the onChange event. [example] | Expected results | | 1. A star colored according to the select option value appears when | the onchange event is triggered. Firing onchange before the select loses focus does not follow the HTML specification but is more useful and is what browsers mostly do. Often, a select is used to trigger another action, such as showing more fields in a form. The user chooses an option and, based on the selection, a section of the form is shown. If the change event does not fire when the item is chosen, the callback will not be called and the user will not see the event until he changes focus by tabbing or clicking away. Instead, the chagne event should (ideally) fire when a different option has been selected. Depends on the platform. Yep. Select-multiple adds one more variant. I've used different wording in HTML5, let me know if it's confusing still (it probably is), and what it should say instead. Link or text? It would be useful to have x-browser way to get a select change event. The change does not bubble in all browsers. Depending on the implementation, a change event may or may not fire on: * alphanumeric key press (selects an element) * up/down arrow key press (selects an element) * select via enter after arrow key press It is generally desirable to have a select fire the event when the value has changed, even if it still has focus. Garrett [1]http://www.w3.org/WAI/UA/TS/html401/cp0102/0102-ONCHANGE-SELECT.html [2]http://www.w3.org/TR/html401/interact/scripts.html#adef-onchange -- comp.lang.javascript FAQ URL: http://jibbering.com/faq/
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On 10/30/08, Eduard Pascual [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2008 at 1:16 AM, Matthew Paul Thomas [EMAIL PROTECTED] wrote: On Oct 29, 2008, at 6:40 PM, Kristof Zelechovski wrote: Declare INPUT[type=mailing-list] instead of INPUT[type=emails], please. Type=emails is ugly and confusing (as it seems to expect messages). ... emails is indeed ugly, but mailing-list would be even worse. A mailing list usually has a single address. What about multi-email, email-list or email-addresses? The last one is the one I most like, and the most explicit, with the only (minor) drawback that it's the longest. Anyway, that's just a suggestion. BTW, the same argument could be made on type=email, since someone could easily think it expects an entire message. INPUT[type=email][multiple=1] c.f. SELECT[multiple=1]
Re: [whatwg] video tag : loop for ever
On Oct 29, 2008, at 18:34, Silvia Pfeiffer [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2008 at 11:52 AM, Jonas Sicking [EMAIL PROTECTED] wrote: Eduard Pascual wrote: On Wed, Oct 29, 2008 at 6:16 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Maciej (and I think others) have suggested that it would be useful if it was possible to allow audio to be used such that a single file can be downloaded that contains multiple sound effects, and then use javascript to play different sound effects contained in that file at various times. For example someone creating a shoot-em-up game might create a file that contains the sound for shoot weapon, enemy exploding, player dying, and player finishes level. It can then when appropriate use javascript to play any one of these sound effects. Wouldn't multiple audio elements be better here? They'd point to the actual same file, but different fragments. That would even make the script less bloated (just selecting each element, instead of explicitly getting the appropriate fragment from the master file each time you need it). This brings the additional advantage that, in the event the server does support file fragments, only the actually required fragments will be downloaded. The whole idea was to make a single HTTP request to the server. Doesn't seem like your proposal accomplishes that. As I said, I'm fine with not satisfying this use case (of allowing multiple sound effects downloaded in a single request). But that was the use case that was cited. No, that's not a use case - that's a proposed solution for the use case of having multiple small audio files required for playback of one larger audio presentation. If another solution can satisfy this need with appropriate qos, then I don't think we need to worry further. That's exactly what proposal 3 was. / Jonas
