[whatwg] [OT] OpenWebIndia
We are trying to collect Indian Developer who would like participate on HTML5/openweb discussion and start community workshop in India for advocacy for html5-related technologies. Thanks http://mail.openwebindia.org/mailman/listinfo/openwebindia_openwebindia.org -- ┌─┐ │Narendra Sisodiya │http://narendrasisodiya.com └─┘
Re: [whatwg] Race condition in media load algorithm
On Mon, 2 Aug 2010, Chris Pearce wrote: There's a race condition in the media load algorithm. When the resource selection algorithm begins, it sets a task to complete the rest of the resource selection algorithm asynchronously. Not quite. It awaits a stable state and then runs a synchronous section, which means that it will run the subsequent steps as soon as the current task has finished, before anything else that is queued. Thus: In the asynchronous task, we set the delaying-the-load-event flag to true at step 4. But between the resource selection algorithm setting the task to asynchronously continue the algorithm, and the task actually running, the load event could fire ...the load event couldn't fire, because the load event is queued as a task, which will execute at the earliest _after_ the synchronous section has run (unless the task was queued before the task in which the resource selection algorithm was invoked started, of course). I don't think there's anything defined that delays the load event which can finish without a task executing. (And even if there was, moving this particular step around wouldn't change things other than theoretically making the race condition window a bit smaller.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Content-Disposition property for a tags
Dennis wrote: I have an idea which would be very cool for HTML5. Having a Content-Disposition property on a tags which does the same as the HTTP Header. For example changing the file name of the file to be downloaded or rather have a image file download rather than it being shown in the browser directly. Hang on... isn't the mechanism for this already available via the type attribute? For example: a href=/path/to/image.jpg type=image/jpegFull size image/a A browser could offer a preference setting, for example: Always download the following types of files, rather than opening in the browser: * images[x] * movies[ ] ...etc. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Content-Disposition property for a tags
I'm really not too sure what pre-existing problem this actually solves. Given that a server sets the correct mime-types for a given resource, we know what type it is already. Setting the Content-disposition on the client side creates an annoying user experience. If I want to open a link in a new tab, window or download, I'll do it like I have done for the last ten years—via a keyboard modifier or a contextual menu. On Mon, Aug 2, 2010 at 8:31 PM, Jeremy Keith jer...@adactio.com wrote: Dennis wrote: I have an idea which would be very cool for HTML5. Having a Content-Disposition property on a tags which does the same as the HTTP Header. For example changing the file name of the file to be downloaded or rather have a image file download rather than it being shown in the browser directly. Hang on... isn't the mechanism for this already available via the type attribute? For example: a href=/path/to/image.jpg type=image/jpegFull size image/a A browser could offer a preference setting, for example: Always download the following types of files, rather than opening in the browser: * images[x] * movies[ ] ...etc. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Please consider dropping the sandbox attribute from the iframe element
On Aug 1, 2010, at 6:59 PM, Tantek Çelik wrote: Summary: The new 'sandbox' feature on iframe should be considered for removal. It needs a security review, it will be a lot of work to implement properly, and may not actually solve the problem it is intending to solve. More details here: http://wiki.whatwg.org/wiki/Iframe_Sandbox I encourage fellow web authors and browser implementers to add their opinions/comments to that wiki page. As other have mentioned, iframe sandbox has been implemented in WebKit for some time. Additional points of information: 1) It's shipping in current versions of Safari and Chrome. 2) Security experts have reviewed it. @sandbox itself seems pretty solid, although there are possibly issues with related features such as text/html-sandboxed and @seamless. 3) Content has been built using it. 4) While it's unclear if iframe sandbox will work well for comments or other such cases of seamless untrusted content, it seems clearly useful for use cases like gadgets and ads. While more security review is always welcome, it seems like the basic idea is solid, and it's demonstrably implementable. The initial patch implementing it for WebKit can be seen here: http://trac.webkit.org/changeset/51577. This patch was 100k, but more than half of it is tests and the ChangeLog entry. Regards, Maciej
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On 07/30/2010 06:43 AM, Oliver Hunt wrote: all array functions defined in ES5 are generic in that they work over any array-like object. They're guaranteed to work over any array-like native JavaScript object. They're *not* guaranteed to work on host objects like the various node lists. FWIW in practice `Array.prototype.*.call(htmlcollection)` does work on the modern desktop browsers except for IE. It would be possible to specify that the native-JS object guarantee should also extend to node lists. This would allow fast browser implementations of the array-like methods to be used without having to copy to a new Array. However this would still leave the method of calling them a little ugly. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/
Re: [whatwg] Race condition in media load algorithm
On 8/2/10 5:17 AM, Ian Hickson wrote: There's a race condition in the media load algorithm. When the resource selection algorithm begins, it sets a task to complete the rest of the resource selection algorithm asynchronously. Not quite. It awaits a stable state and then runs a synchronous section, which means that it will run the subsequent steps as soon as the current task has finished, before anything else that is queued. So the model is that there are asynchronous tasks but there are also things that run after the current asynchronous task finishes? How are we defining current asynchronous task and finish? How does this setup handle cases when the current asynchronous task spins the event loop, if at all? -Boris
Re: [whatwg] Content-Disposition property for a tags
Jeremy Keith jer...@adactio.com wrote: Dennis wrote: ... Hang on... isn't the mechanism for this already available via the type attribute? For example: a href=/path/to/image.jpg type=image/jpegFull size image/a That wouldn't help in this case... A browser could offer a preference setting, for example: Always download the following types of files, rather than opening in the browser: * images[x] * movies[ ] ...etc. Yes, but that wouldn't help since I want to force downloads regardless of the browser settings. Maybe it would do if the type was set to application/octet-stream, since those, by default, always get downloaded.
Re: [whatwg] Content-Disposition property for a tags
Ben Schwarz ben.schw...@gmail.com wrote: I'm really not too sure what pre-existing problem this actually solves. Given that a server sets the correct mime-types for a given resource, we know what type it is already. Yes, since we don't want to set MIME-Types. I want to be able to set what a file actually is. Is it a file which is supposed to be shown in the browser? Or is it an attachment (refering to the content-disposition setting) Setting the Content-disposition on the client side creates an annoying user experience. I don't think so. What would you rather have? download (Please right click and save target as) or download If I want to open a link in a new tab, window or download, I'll do it like I have done for the last ten years—via a keyboard modifier or a contextual menu. No problem with what you want to have, but can't webmasters ALREADY set the content-disposition? I just want to copy this functionality over to the client to prevent that you always have to use a scripting language server-side. On Mon, Aug 2, 2010 at 8:31 PM, Jeremy Keith jer...@adactio.com wrote: ...
Re: [whatwg] Content-Disposition property for a tags
Dennis wrote: Yes, but that wouldn't help since I want to force downloads regardless of the browser settings. Ah, I see. In that case, I fundamentally disagree with what you are asking for. Final control should be in the hands of the user, not the author. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Content-Disposition property for a tags
On Mon, 2010-08-02 at 18:09 +0200, Dennis Joachimsthaler wrote: Ben Schwarz ben.schw...@gmail.com wrote: I'm really not too sure what pre-existing problem this actually solves. Given that a server sets the correct mime-types for a given resource, we know what type it is already. Yes, since we don't want to set MIME-Types. I want to be able to set what a file actually is. Is it a file which is supposed to be shown in the browser? Or is it an attachment (refering to the content-disposition setting) Setting the Content-disposition on the client side creates an annoying user experience. I don't think so. What would you rather have? download (Please right click and save target as) or download Which can easily be done with sever-side code. It's still annoying for the end user when things like this happen though. For example, who do you know that hasn't turned off whatever PDF browser plugin has been installed along with their Acrobat Reader? Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Content-Disposition property for a tags
On Mon, Aug 2, 2010 at 9:21 AM, Michael Kozakewich mkozakew...@icosidodecahedron.com wrote: Dennis wrote: Yes, but that wouldn't help since I want to force downloads regardless of the browser settings. Maybe it would do if the type was set to application/octet-stream, since those, by default, always get downloaded. People don't often like it when they're forced to do something. If they want to download it, they can select Save Link As... from their browser. If they actually want to view it full-screen, they don't want to be forced to download it. I see where you're coming from, but we try not to force users to do things. For the same reason, @target was removed from links. @target was not removed from links. HTML4 Strict removed it, but HTML5 rightly added it back because it has useful functionality. ~TJ
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On Aug 2, 2010, at 7:36 AM, And Clover wrote: On 07/30/2010 06:43 AM, Oliver Hunt wrote: all array functions defined in ES5 are generic in that they work over any array-like object. They're guaranteed to work over any array-like native JavaScript object. They're *not* guaranteed to work on host objects like the various node lists. Uhhh, I have no idea what you're talking about -- there are no type checks in any of the array prototype functions, they all operate in terms of property access alone, all the methods we're talking about basically start out like this: 1. Let O be the result of calling ToObject passing the this value as the argument. 2. Let lenValue be the result of calling the [[Get]] internal method of O with the argument length. 3. Let len be ToUint32(lenValue). 4. If IsCallable(callbackfn) is false, throw a TypeError exception. 5. If thisArg was supplied, let T be thisArg; else let T be undefined. 6. Let k be 0. 7. Repeat, while k len Eg. array-like in the context of ES5 should be interpreted as has a property named 'length', the array methods will work on any type. FWIW in practice `Array.prototype.*.call(htmlcollection)` does work on the modern desktop browsers except for IE. It would be possible to specify that the native-JS object guarantee should also extend to node lists. This would allow fast browser implementations of the array-like methods to be used without having to copy to a new Array. However this would still leave the method of calling them a little ugly. As above there is no question of it being possible -- the spec behaviour makes no exceptions for host vs. native object types. If IE has a bug, then IE has a bug, that doesn't change the spec. --Oliver
Re: [whatwg] Content-Disposition property for a tags
On 2 Aug 2010, at 17:21, Michael Kozakewich wrote: Dennis wrote: Yes, but that wouldn't help since I want to force downloads regardless of the browser settings. Maybe it would do if the type was set to application/octet-stream, since those, by default, always get downloaded. People don't often like it when they're forced to do something. If they want to download it, they can select Save Link As... from their browser. If they actually want to view it full-screen, they don't want to be forced to download it. I see where you're coming from, but we try not to force users to do things. For the same reason, @target was removed from links. I agree that it's not good to force users in general. However, this attribute can be implemented only as a hint for browsers to display Open/Save dialog. Users wouldn't be forced to download the file, it would just be easier for them to download. OTOH users may be annoyed when their browser isn't saving some types of documents by default (and whether certain type of file should be viewed inline or saved might depend on context, e.g., I may want to read PDF booklets in the browser, but would prefer to save PDF receipts and tickets). If Content-Disposition was attribute on a, then webmasters could easily offer right option (or both) where it makes sense. Downloads can be forced already with Content-Disposition: attachment. It's just harder to do, and unfortunately that doesn't stop webmasters from trying. Popular PHP snippets for forcing download are among the most disgusting cargo-cult code I've ever seen — they're collection of self-contradictory and nonsensical HTTP headers, break caching and resuming, and often have security vulnerabilities. It would be great if we could obsolete those scripts. -- regards, Kornel
Re: [whatwg] Content-Disposition property for a tags
2010/8/2 Kornel Lesiński kor...@geekhood.net: Downloads can be forced already with Content-Disposition: attachment. It's just harder to do, and unfortunately that doesn't stop webmasters from trying. Popular PHP snippets for forcing download are among the most disgusting cargo-cult code I've ever seen — they're collection of self-contradictory and nonsensical HTTP headers, break caching and resuming, and often have security vulnerabilities. It would be great if we could obsolete those scripts. Indeed; I've used those code samples, and since the entire area is basically voodoo to me, I still have no idea which headers I sent did anything and which are useless or even harmful cruft. In general, even well-educated authors have no clue what they're doing here. ~TJ
Re: [whatwg] Content-Disposition property for a tags
Kornel Lesiński kor...@geekhood.net wrote: On 2 Aug 2010, at 17:21, Michael Kozakewich wrote: I agree that it's not good to force users in general. However, this attribute can be implemented only as a hint for browsers to display Open/Save dialog. Users wouldn't be forced to download the file, it would just be easier for them to download. OTOH users may be annoyed when their browser isn't saving some types of documents by default (and whether certain type of file should be viewed inline or saved might depend on context, e.g., I may want to read PDF booklets in the browser, but would prefer to save PDF receipts and tickets). If Content-Disposition was attribute on a, then webmasters could easily offer right option (or both) where it makes sense. Downloads can be forced already with Content-Disposition: attachment. It's just harder to do, and unfortunately that doesn't stop webmasters from trying. Popular PHP snippets for forcing download are among the most disgusting cargo-cult code I've ever seen — they're collection of self-contradictory and nonsensical HTTP headers, break caching and resuming, and often have security vulnerabilities. It would be great if we could obsolete those scripts. Thank you, this is exactly what I was trying to say. To force was maybe the wrong word.
Re: [whatwg] Content-Disposition property for a tags
Am 02.08.2010 18:21 schrieb Michael Kozakewich: Dennis wrote: Yes, but that wouldn't help since I want to force downloads regardless of the browser settings. Maybe it would do if the type was set to application/octet-stream, since those, by default, always get downloaded. People don't often like it when they're forced to do something. If they want to download it, they can select Save Link As... from their browser. If they actually want to view it full-screen, they don't want to be forced to download it. I see where you're coming from, but we try not to force users to do things. For the same reason, @target was removed from links. But it has made it back into HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-a-element I assume the reason is that some de-facto standards have established that users have got used to. One of them seems to be that clicking on an external link in a corporate web site usually opens a new window or tab, whatever they set in their browser prefs. Some users (like me) might forget to hold the ctrl key because most corporate websites use target=_blank anyway on all external links, and get annoyed if the original page disappears and they have to go back their session history. Another de-facto expectation could be, that on a download page with several links, they behave consistently, starting a download: h1Press downloads/h1 ul lia href=portrait.jpgPortrait image (JPG)/a/li lia href=band-photo.tifMy band (TIFF)/a/li lia href=cv.pdfCurriculum vitae (PDF)/a/li lia href=discography.xlsDiscography (Excel File)/a/li /ul Every link is likely to invoke an other default action, which does not seem consistent to me in this context - even if the downloading journalist as an experienced user might be able to anticipate the action based on the file type information in the brackets. Dennis' and Roger's proposal would definitely be helpful here.
Re: [whatwg] Content-Disposition property for a tags
On Mon, Aug 2, 2010 at 12:21 PM, Michael Kozakewich mkozakew...@icosidodecahedron.com wrote: People don't often like it when they're forced to do something. If they want to download it, they can select Save Link As... from their browser. If the author can predict that the user probably wants to do this (like because they just clicked on a button that says Save), they should be able to trigger it directly. This isn't to say that the user must be *forced* to do it -- if authors use this annoyingly, browsers will compete on providing UI to avoid the annoyance. As with anything UI-related in specs, it would just serve as a hint or guideline, not an iron-clad command that all browsers must obey to the letter. I see where you're coming from, but we try not to force users to do things. Let's say you have an image editor, written using canvas and whatnot. You want to have similar UI to native image editors, and that includes a Save button (probably adorned with a little picture of a 3.5 floppy, which is amusing when you think about it). Clicking the Save button should pop up a dialog like in a native app, asking you where to save it. Currently this can be done, but you have to send a request to the server and get a Content-Disposition: attachment response. Probably you have to do it in a hidden iframe so it doesn't navigate the whole page, etc. The request is for some feature to do this without the rigamarole. If you don't agree that this use-case is worth adding the feature for, do you think that: 1) The status quo is fine: you should have to send a request to the server to implement a Save button. Offline image-editing apps don't matter. Probably not a popular attitude here. 2) You (the app author) shouldn't even be able to do that. You should have to say Right-click and choose 'Save As'. Except that of course this is less convenient for the user, it takes up more space in the UI, the option might not be named the same thing in all browsers, apps might want to make right-click do something else so that context menus don't work, there are plenty of platforms (like phones) where right click doesn't even make sense, and in general the web platform makes no UI guarantees at all. So then we get multipage guides explaining how to do it in a handful of popular browsers, with images and step-by-step instructions like http://www.wikihow.com/Clear-Your-Browser's-Cache, and unpopular browser users get to figure it out themselves. 3) Something else? All in all, this seems like a very straightforward, useful thing to ask for. Yes, users can do it through browser UI, but that doesn't permit authors to present it in a consistent way, draw the user's attention to it, put it where the user will expect it in context, etc. It's very similar to print(): of course the user can just hit Ctrl-P, but some people are used to clicking Print buttons and will be puzzled and unhappy if they don't find one. Not everyone will try to think of alternative ways to perform a task when their initial expectation fails. That's the point where a lot of people give up, or call their techy friends or relatives for help. Many people use computers by rote, and don't know what to do when the usual incantation fails. Even for those of us who know better, it's can be more convenient if the application has more control, so they we don't *have* to manually click through menus when the app can do it for us.
Re: [whatwg] Content-Disposition property for a tags
On 8/2/10 1:15 PM, Aryeh Gregor wrote: If you don't agree that this use-case is worth adding the feature for, do you think that: 3) Something else? For the use case your describe, it might just make more sense for browsers to support Content-Disposition on data: URIs directly somehow... Maybe. -Boris
Re: [whatwg] Please consider simplifying authoring guidance for the img alt attribute
Am 01.08.2010 11:43 schrieb Tantek Çelik: http://wiki.whatwg.org/wiki/Img_Alt I encourage fellow web authors to add opinions/comments. My personal opinion on the alt attribute is that: - it should only be used if the image is crucial for understanding the content, or for navigation (such as headline or link images or charts) - it's absence should default to what is alt= in HTML4 - search engines should generally ignore text in the alt attribute, but evaluate the title attribute instead Rationale: 4.8.1.1.12 says: A corollary to this is that the alt attribute's value should never contain text that could be considered the image's caption, title, or legend. It is supposed to contain replacement text that could be used by users instead of the image; it is not meant to supplement the image. The title attribute can be used for supplemental information. The most common use cases of @alt are (at least as far as I know from my authoring practise): - Insert the text contained in a headline or link image - Insert an empty string to make the page validate - Insert a short description of the image, preferably containing some keywords for search engines; sometimes the search engine aspect is weighted even higher than the contents of the image here Only the first one of these use cases matches the gideline given in 4.8.1.1.12. The second one is not harmful, exept some minimal bandwidth impact. But the third one is actually counterproductive with regard to accessibility. An image which conveys information, if it is not a text replacement (such as a headline or link image), a corporate logo, or some kind of chart, is usually almost impossible to describe in a way that can't be considered the image's caption, title, or legend. Usually, the information conveyed by the image is either duplicated in the text that the image is associated to (or in it's caption or legend), or at all useless for anybody that does not see the image. Either way, the presence of an alt text does not provide useful information, but possibly confuses - specially if it is written with regard to search engines. I am confident that declaring the alt attribute as optional would not only simplify the spec and validation, but also have no significant effect regarding accessibility, as poor authoring cannot really be prevented by structural means. And I am also confident that if search engines ignored the alt attribute, and authors were encouraged to only insert alt text if helps to understand the content, this would have a positive effect on accessibility, as authors would be discouraged to put unnecessary information in the alt attribute for seo purposes, or duplicate the legend or caption (what I used to do before I read 4.8.1.1.12, because HTML4 seemed to require exactly this).
Re: [whatwg] Proposal for Web Storage expiration
If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present. Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible. I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Scott Hess [mailto:sh...@google.com] Sent: Friday, July 30, 2010 5:05 PM To: Nicholas Zakas Cc: Jeremy Orlow; Alexandre Morgaut; whatwg@lists.whatwg.org; Jonas Sicking Subject: Re: [whatwg] Proposal for Web Storage expiration On Fri, Jul 30, 2010 at 11:51 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: And I totally agree, this is not a strong security feature, and that's not the intent. The intent is just to give an extra measure of control of the lifetime of the data to bring Web Storage closer to being a replacement for a wider range of functionality that currently uses cookies. I don't think this really follows. Cookies were invented quite awhile ago, and may not be a good model for development. A reasonably small dataset allows the client to expire cookies aggressively. With large local storage, doing per-item expiration is not a good idea - you do not want your UA groveling through a gig of data you are not otherwise using to expire a couple dozen items. Per-database expiration might make sense, because the expiration information could be stored in a central location as a hint to the UA (if the site isn't going to use the data after two weeks, might as well delete it). Sites could segment their expiration needs by using multiple data stores. That said, idle storage is eventually going to be reclaimed anyhow, so you could just ignore the problem. Current storage proposals are much richer than cookies, so the developer could just store dates alongside their other data and make the decisions directly, no need for the system to help. Since the JavaScript accessing the data is executing right next to the data, you don't have the latency issues client/server communication introduces. So long as expiration is a SHOULD, its not clear to me that this idiom is powerful enough to deserve footprint in the spec. -scott
Re: [whatwg] Please consider simplifying authoring guidance for the img alt attribute
On Mon, 2010-08-02 at 17:19 +0200, Markus Ernst wrote: - search engines should generally ignore text in the alt attribute, but evaluate the title attribute instead Rationale: 4.8.1.1.12 says: A corollary to this is that the alt attribute's value should never contain text that could be considered the image's caption, title, or legend. It is supposed to contain replacement text that could be used by users instead of the image; it is not meant to supplement the image. The title attribute can be used for supplemental information. What you said doesn't make sense. The alt text is to be used instead of the image, and the title is for supplemental content. Therefore, search engines should use alt text, as that is what they are attempting to convey in the lost (in the sense that search engines don't process images like they do text) image. If they used the title, one can only imagine the trouble. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Race condition in media load algorithm
On Mon, 2 Aug 2010, Boris Zbarsky wrote: So the model is that there are asynchronous tasks but there are also things that run after the current asynchronous task finishes? It's a little more detailed than that, but yes, that describes the event loop model. How are we defining current asynchronous task and finish? In terms of the event loop algorithm: http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2 How does this setup handle cases when the current asynchronous task spins the event loop, if at all? The spinning of the event loop is also defined in terms of the event loop in a manner that strictly defines this: http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#spin-the-event-loop -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On 8/2/10, Oliver Hunt oli...@apple.com wrote: On Aug 2, 2010, at 7:36 AM, And Clover wrote: On 07/30/2010 06:43 AM, Oliver Hunt wrote: all array functions defined in ES5 are generic in that they work over any array-like object. They're guaranteed to work over any array-like native JavaScript object. They're *not* guaranteed to work on host objects like the various node lists. Uhhh, I have no idea what you're talking about -- there are no type checks in any of the array prototype functions, they all operate in terms of property access alone, all the methods we're talking about basically start out like this: [..] And they continue like this: Whether the [something] function can be applied successfully to a host object is implementation-dependent. Where [something] is replaced by slice in this case. Eg. array-like in the context of ES5 should be interpreted as has a property named 'length', the array methods will work on any type. That is not true. ECMAScript has what is called host object. A host is any ecmascript object that is not defined by the specification; it is not a user-defined object (because that explicitly defined to be a native object). A host object may or may not be implemented as a native ECMAScript object. That leaves two types of host objects: 1) native 2) non-native More on that: https://mail.mozilla.org/pipermail/es-discuss/2010-July/thread.html#11501 Nothing says that any of the various dom collection objects must be native object. The W3C does not define an interface collection; The term itself comes from Microsoft IE 4, which predates the w3c DOM; hence the quotes around the term collection. FWIW in practice `Array.prototype.*.call(htmlcollection)` does work on the modern desktop browsers except for IE. It would be possible to specify that the native-JS object guarantee should also extend to node lists. This would allow fast browser implementations of the array-like methods to be used without having to copy to a new Array. However this would still leave the method of calling them a little ugly. As above there is no question of it being possible -- the spec behaviour makes no exceptions for host vs. native object types. If IE has a bug, then IE has a bug, that doesn't change the spec. IE does not have a bug. IE does not implement its host objects as native ES objects. I proposed to change that by defining an interface that would require that, as well as putting a definition of [[Get]] property access on such objects in one place; not scattered through various interfaces as they currently are and will continue to be otherwise, with the proliferation of new indexed collection type interfaces. Garrett
Re: [whatwg] Race condition in media load algorithm
On 8/2/10 3:11 PM, Ian Hickson wrote: How are we defining current asynchronous task and finish? In terms of the event loop algorithm: http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2 Ah, I see. Is the note there about synchronous sections having no side-effects something that is true by default due to the way synchronous sections are used in the specification? How does this setup handle cases when the current asynchronous task spins the event loop, if at all? The spinning of the event loop is also defined in terms of the event loop in a manner that strictly defines this: http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#spin-the-event-loop I'm not sure I follow the steps here, actually. Just to make sure I do understand Say I have a task T in the event queue. Task T begins some algorithm that has a synchronous section, then spins the event loop. If I understand the steps in #processing-model-2 correctly, the synchronous sections would run after task T completes, not while task T is spinning the event loop? Or does stop the currently running task in #spin-the-event-loop imply a jump to step 2 of the algorithm under #processing-model2? (Note: I still have a problem with the way pause is defined here, but I've raised that before, I believe.) -Boris
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On Aug 2, 2010, at 12:57 PM, Garrett Smith wrote:
I also linked to the old catchalls proposal earlier in the thread.
That is because the host objects mentioned here have a specialized
catchall behavior that isn't yet defined by any specification, so
when the code has property access with an integer index, as: anObj[2]
- then it's supposed to be the same as a call to the `item` method.
That mostly works, but isn't specified isn't completely and isn't
completely interoperable due to variance in undefined vs null.
I noticed that rather than define catchall, HTML5 copied the old DOM text:
| In the ECMAScript DOM binding, objects implementing the
| HTMLFormControlsCollection interface must support being
| dereferenced using the square bracket notation, such that dereferencing
| with an integer index is equivalent to invoking the item() method with that
| index, and such that dereferencing with a string index is equivalent to
| invoking the namedItem() method with that index.
The problem with that is that property access doesn't do any
typechecking, and so
obj[2]
- is equivalent to:-
obj[2]
Can it be argued as to what integer index means? And what is a string
index?
It does seem a little weird as EcmaScript does not distinguish between string
and non-string property names, the special handling of numeric indices inside
the [[GetOwnProperty]]/[[PutOwnProperty]] methods of those types that have
special handling, in those types the special numeric index path is hit if the
property name is an Array index, which is defined as (pseudo code)
bool isArrayIndex(String property)
{
unsigned index = ToUint32(property);
return ToString(index) == property index = 0 index 0x;
}
Garrett
--Oliver
Re: [whatwg] Proposal for Web Storage expiration
On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present. If we add this to IndexedDB then there are certainly multiple storage areas. You can have any number of objectStores inside any number of databases. Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible. I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way. If we add expiration to IndexedDB on an objectStore level, then the page author doesn't need to do anything beyond setting an expiration date, right? / Jonas
Re: [whatwg] Race condition in media load algorithm
On Mon, 2 Aug 2010, Boris Zbarsky wrote: On 8/2/10 3:11 PM, Ian Hickson wrote: How are we defining current asynchronous task and finish? In terms of the event loop algorithm: http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2 Ah, I see. Is the note there about synchronous sections having no side-effects something that is true by default due to the way synchronous sections are used in the specification? Yeah. It's intended to help keep the ways to implement this somewhat open. How does this setup handle cases when the current asynchronous task spins the event loop, if at all? The spinning of the event loop is also defined in terms of the event loop in a manner that strictly defines this: http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#spin-the-event-loop I'm not sure I follow the steps here, actually. Just to make sure I do understand Say I have a task T in the event queue. Task T begins some algorithm that has a synchronous section, then spins the event loop. If I understand the steps in #processing-model-2 correctly, the synchronous sections would run after task T completes, not while task T is spinning the event loop? The synchronous section would run as soon as the task span the event loop. Spinning the event loop is defined essentially as being equivalent to breaking the original task in two, one that does everything up to spinning the event loop, and one that does everything after spinning the event loop. You are effectively waiting for some condition to become true and then queueing a task to run the continuation of the algorithm. It's just more convenient to write the algorithms as one long set of steps rather than having split them up into multiple algorithms that invoke each other and pass state around. Or does stop the currently running task in #spin-the-event-loop imply a jump to step 2 of the algorithm under #processing-model2? Yes. (Note: I still have a problem with the way pause is defined here, but I've raised that before, I believe.) I think we all have a problem with pause, but I don't know what we can do about it. I don't have any pending feedback from you on this topic, as far as I can tell. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On Fri, Jul 30, 2010 at 2:46 PM, Alex Russell slightly...@google.com wrote:
On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson i...@hixie.ch wrote:
The e-mails quoted below consist of the salient points of this thread:
On Fri, 23 Apr 2010, David Bruant wrote:
Make that HTMLCollection (and all HTML*Collection, as a consequence of
inheritence of HTMLCollection) inherit from the ECMAScript Array
prototype. This way, it will make available all Array extra methods
(forEach, map, filter...) added in ECMAScript5 (and next versions which
should go in the same direction).
As far as I know, adding this won't break any existing code. The
semantics of a Collection and the way it is used is very close from
ECMAScript Arrays. I don't think that the notion of live object and
ECMAScript Array are incompatible either. Once again, I am talking about
ECMAScript binding. I have no intention to touch the HTMLCollection
interface or other languages bindings.
On Sun, 25 Apr 2010, J Z wrote:
If HTMLCollection was inheriting from Array, and methods like `forEach`,
`map`, etc. were to operate on a live object, there would definitely be
undesired consequences. We can see this in, say, Firefox (which allows to
set [[Prototype]] of `HTMLCollection` to `Array.prototype`):
HTMLCollection.prototype.__proto__ = Array.prototype;
document.getElementsByTagName('div').forEach(function(el) {
el.parentNode.removeChild(el); // doesn't work as expected
});
// turning live collection into static array fixes this
Array.slice(document.getElementsByTagName('div')).forEach(function(el) {
el.parentNode.removeChild(el);
});
On Sat, 24 Apr 2010, David Bruant wrote:
I think I can take your point as a pro more than a con, because in
ES5, right before the definition of each array extra method, a paragraph
like the following can be found :
The range of elements processed by forEach is set before the first call
to callbackfn. Elements which are appended to the array after the call
to forEach begins will not be visited by callbackfn. If existing
elements of the array are changed, their value as passed to callback
will be the value at the time forEach visits them; elements that are
deleted after the call to forEach begins and before being visited are
not visited.
This point is confirmed by every algorithm where the length is saved
once for all before the loop and not got from the .length property each
time.
On Mon, 26 Apr 2010, Erik Arvidsson wrote:
On Sun, Apr 25, 2010 at 01:07, David Bruant wrote:
Le 25/04/2010 00:39, J Z a écrit :
I have thought a lot about weirdnesses that people could think about
like trying to assign a value to the HTMLCollection (divs[14] =
myOtherDiv), but once again, it wouldn't be more allowed than it
currently is (I have no idea of what happens today, but if an error
is thrown in a for-loop, it should throw an error as well in a call
within a forEach).
How would destructive methods like `push` or `sort` behave? Would
`document.body.childNodes.push(document.createTextNode('foo'))` append
text node to a body element? Or would it be a noop?
That is actually a very good point. It think that the behavior should
be exactly the same as an equivalent without array methods. (this
point of my proposal would need to be made completly explicit for each
method)
One way to solve this could be to split Array into two interfaces. One
to be used with immutable array like objects and one to use to mutate
objects. Then we could apply the immutable array like interface to
NodeList and its related interfaces. The benefit of doing that is that
NodeList.prototype.push would be undefined instead of failing when
called.
On Mon, 26 Apr 2010, David Flanagan wrote:
Rather that trying to make DOM collections feel like arrays, how about
just giving them a toArray() method? This makes it clear that a
collection is not an array, but clearly defines a way to obtain an
array. Clever implementors might even be able to optimize common
uses-cases using some kind of copy-on-write strategy so that toArray()
doesn't involve memory allocation and copying.
Of course, trying to teach programmers when they ought to call toArray()
and when it is not necessary is another matter. Perhaps calling the
method snapshot() and focusing on the live vs. static distinction
instead of the fake array vs. true array distinction would invite less
misuse.
Or we can just leave the DOM as it is and get used to calling the
equivalent of Prototype's $A() function.
Before changing something this substantial, I'd like to have implementor
feedback regarding what the best way to address this is:
- somehow make HTMLCollections and NodeLists inherit from Array?
- define a bunch of feature on HTMLCollections and NodeLists so that
they're like arrays?
I don't think this makes sense given the immutability
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On 08/02/2010 09:57 PM, Garrett Smith wrote:
Can it be argued as to what integer index means? And what is a string index?
Good catch, that's pretty ambiguous language. Browsers implement this as
if integer index were equal to the term array index defined section
15.4 of ECMA262 (that is an unsigned 32-bit integer other than
(132)-1, expressed in simplest-possible decimal form), and string
index meaning any other index.
The paragraph should be updated to explicitly reference this; probably
the language about square brackets should be dropped too, as it seems to
represent a misunderstanding of exactly how the ECMAScript
square-bracket and dot operators actually work.
Whether a property name is an array index or not is an unrelated issue
to the matter of how the property value is retrieved. OK, you can't use
the direct dot syntax on an array index purely as a grammatical manner,
but . and [] aren't the only way to access properties. (eg.
document.links.hasOwnProperty('0').)
--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/
Re: [whatwg] [canvas] getContext multiple contexts
On Thu, 29 Apr 2010, Vladimir Vukicevic wrote: A while ago questions came up in the WebGL WG about using a canvas with multiple rendering contexts, and synchronization issues that arise there. Here's our suggested change to getContext. This seems overly complex. I've gone for a somewhat simpler approach, which basically makes canvas fail getContext() if you call it with a context that isn't compatible with the last one that was used, as defined by a registry of contexts types. Currently, only '2d' and '3d' are defined in this registry, and they are not defined as compatible. It essentially allows for multiple contexts but adds no synchronization primitives other than the requirement that rendering must be visible to all contexts (that is, that they're rendered to the same destination space). Having 3D and 2D contexts rendering to the same space -- especially given getImageData() and the like -- seems like an interoperability nightmare. This also adds the 'attributes' parameter which can customize the context that's created, as defined by the context itself. WebGL has its own context attributes object, and I'd suggest that the 2D context gain at least an attribute to specify whether the context should be opaque or not; but that's a separate suggestion from the below text. I haven't added this. Could you elaborate on why this is needed? What happens if the method is invoked agains with different parameters? It seems far preferable to have this on the API rather than as part of the getContext() method. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Race condition in media load algorithm
On 2/08/2010 9:17 p.m., Ian Hickson wrote: On Mon, 2 Aug 2010, Chris Pearce wrote: There's a race condition in the media load algorithm. When the resource selection algorithm begins, it sets a task to complete the rest of the resource selection algorithm asynchronously. Not quite. It awaits a stable state and then runs a synchronous section, which means that it will run the subsequent steps as soon as the current task has finished, before anything else that is queued. Ah, I see. My understanding of the processing model was incomplete, thanks for clarifying! All the best, Chris Pearce.
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On 8/2/10, And Clover and...@doxdesk.com wrote:
On 08/02/2010 09:57 PM, Garrett Smith wrote:
Can it be argued as to what integer index means? And what is a string
index?
Good catch, that's pretty ambiguous language. Browsers implement this as
if integer index were equal to the term array index defined section
15.4 of ECMA262 (that is an unsigned 32-bit integer other than
(132)-1, expressed in simplest-possible decimal form), and string
index meaning any other index.
Not exactly.
An array's `length` is 1 greater than the largest index in the array;
represented as uint internally. The largest possible array index is
2^32 - 2. ES5 specification says this a bit differently:
| A property name P (in the form of a String value) is
| an array index if and only if ToString(ToUint32(P)) is
| equal to P and ToUint32(P) is not equal to 232-1
That could cover integer index, but the remaining undefined is
string index, which seems a paradoxical name, even for Java
programmers.
Suppose string index could be any other index. Or it could be any
index matching production for NAME.
But then, does that mean property access on an HTMLCollection can
never return undefined? Seems so; must be either `null` or an object.
If the a collection is spec'd to use specialized [[Get]] access, then
it may need to use catchalls. Again, browsers do use these in some
cases and they aren't specified.
The paragraph should be updated to explicitly reference this; probably
the language about square brackets should be dropped too, as it seems to
represent a misunderstanding of exactly how the ECMAScript
square-bracket and dot operators actually work.
Whether a property name is an array index or not is an unrelated issue
Depends. If a specialized [[Get]] implemented as a catchall, then the
browsers do some checking.
A specialized [[Get]] may be interfering with array generics working
with IE host object collections. It may have been that it was too
complicated and that the developers decided that it was easier to fail
fast by throwing JScript object expected'.
Again, on that error, if `ho` is a host object, then the behavior in
IE = 8 for `[].slice.call( ho )` is JScript object expected. IE
operation sees that the context -- the `this`value -- is not a JScript
object and then aborts prematurely, without trying. It could be that
the attempt to slice the object could actually succeed, as: -
0 in ho length in ho
- is true.
to the matter of how the property value is retrieved. OK, you can't use
the direct dot syntax on an array index purely as a grammatical manner,
but . and [] aren't the only way to access properties. (eg.
document.links.hasOwnProperty('0').)
That shows that `hasOwnProperty` is present on the object and that
calling it returns true where there.
For compatibility with IE, a layer of indirection may be used:
({}).hasOwnProperty.call(document.links, 0);
- and resulting true in IE.
However, that hasOwnProperty check does not always true for
collections. As seen in the previous example I posted, for property P,
[[HasProperty]] resulted false when there is a property P. Once again,
this time with hasOwnProperty, I see a result in Firefox 3.6: [false,
object]
javascript: var result =
[
({}).hasOwnProperty.call(document.forms[0], 0),
typeof document.forms[0][0]
];
alert( result )
HTML5 also codifies a common form memory leak as past names map.
Both of those oddities were explained more here:
http://www.jibbering.com/faq/names/
However, AFAIK, HTML5 does not specify the catchall behavior for the
approach for specialized property access seen there.
Does a collection have element properties? (and by element, I do
not mean Element, but indexed/keyed item that represents an object in
the collection.
If it does, then that's a lot easier. Spec'd specialized behavior for
property accessors can be removed; as that behavior is already defined
by ECMA-262. The only change could be to allow for integer index
access to return `undefined`, as it currently does in most browsers.
If any collection does not have element properties, then it is
necessary to define integer index and string access, at least for
that collection.
Most collections appear to have element properties and so I can't see
any reason for not specifying that. I recall raising discussion of
property access on collections over a year ago, before writing the
article I've linked above.
Garrett
Re: [whatwg] Proposal for Web Storage expiration
Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. To be clear, I think there should be expiration for all forms of client-side data storage, and adding it to one doesn't seem like a reason to not add it to all. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas Sicking Sent: Monday, August 02, 2010 2:10 PM To: Nicholas Zakas Cc: Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org; Jeremy Orlow Subject: Re: [whatwg] Proposal for Web Storage expiration On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present. If we add this to IndexedDB then there are certainly multiple storage areas. You can have any number of objectStores inside any number of databases. Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible. I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way. If we add expiration to IndexedDB on an objectStore level, then the page author doesn't need to do anything beyond setting an expiration date, right? / Jonas
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On 8/2/10, Garrett Smith dhtmlkitc...@gmail.com wrote:
On 8/2/10, And Clover and...@doxdesk.com wrote:
On 08/02/2010 09:57 PM, Garrett Smith wrote:
[...]
({}).hasOwnProperty.call(document.links, 0);
- and resulting true in IE.
However, that hasOwnProperty check does not always true for
...does not always result `true for...
collections. As seen in the previous example I posted, for property P,
[[HasProperty]] resulted false when there is a property P. Once again,
this time with hasOwnProperty, I see a result in Firefox 3.6: [false,
object]
That was not clear, I meant that [[HasProperty]] resulted false and
[[Get]], via property accessors. resulted in the element being
retrieved.
Garrett
Re: [whatwg] The real issue with HTML5's sectioning model
On Fri, 30 Apr 2010, Eduard Pascual wrote:
Basically, most of the issues with headings boil down to a single fact:
the sectioning model is (probably needlessly) over-bloated. [...]
And now, in HTML5, not only have h1-6 been kept, but a plethora of new
elements: section, nav, aside, article, hgroup, header,
footer; and it even messes with address. The justifications for
h1-6 (backwards compatibility, better transition, etc) are quite
sound; but the 7 new elements more than double the mess.
Another way to look at it is that the new elements simplify the markup
authors have to use. Most of the new elements correspond to very commonly
used class names.
Actually, if we try to implement the outlining algorithm in the form
of selectors that match each level of headings we have: On the case that
the h1-only approach, selecting each level of heading requires a list
of something raised to the n-th power selectors, where n is the heading
level minus one.
Not necessarily. We can fix Selectors to make this much shorter, in a way
equivalent to what the spec says, for example using a pseudo-class like
Mozilla's :-moz-any().
On the case of a mixed approach, it is *absolutely* impossible to get
the headings properly matched with current selector technology.
Indeed. We can always improve that technology if that's a problem, though.
In practice it's not clear what the needs are here. I don't see most
authors needing to select both section/h1 and h2/h3 etc with the
styles interacting. Do you have any concrete use cases in mind where this
is a problem?
My suggestion is to clean things a bit: consolidate the sectioning model
into a single element+attribute pair, like this:
section stays as is.
nav becomes section kind=nav
aside becomes section kind=aside
article becomes section kind=article
address becomes section kind=address (and the former is defined
in the compatibility section as equivalent to the later, because it is
the only element of the sectioning model that already exists in
previous versions of HTML).
I'm not sure about what should be done with header, footer, and
hgroup, but I hope this is a good place to discuss it ;-)
I don't understand what problem this solves. All its seems to do is make
the language more verbose.
This yields several advantages:
1) The styling issue improves drastically: any pre-HTML5 will
understand this (IE would require a bit of javascript anyway) out of
the box:
h1 { styling for top-level }
section h1 { styling for second-level }
section section h1 { styling for third-level }
and so on, for as many levels as you need.
If you want to target older UAs, you can just use h2-h6 with
section, instead of relying on the automatic sizing of h1.
2) All of a sudden, something like section kind=aside navh1See
also/h1 some indirectly related links here.../section becomes
possible, plus easy to style, and works happily with the outlining
algorithm.
Isn't that a negative, rather than a positive?
3) Future needs will become easier to solve on future versions of the
specification, and with significantly smaller costs: for example, let's
assume a new sectioning element such as attachment becomes a
widespread need (it would already make sense on sites like web-mail
services, discussion boards, bug-trackers, and some others...). So a new
crouton on the soup, which would be treated quite like a generic div
by pre-HTML6 (or 7, or whatever) browsers. Now, with the
section+attribute approach, we'd get something like section
kind=attachment: that'd would still work with the outlining algoryth
(it could be treated as generic section), it's styling will work
smoothly, etc.
Given how often we add new sectioning elements, I don't think that's
something to worry about optimising for. At least not in favour of a
simple language.
On Sat, 1 May 2010, Eduard Pascual wrote:
It's not a matter of saving a few characters here and there.
Well, that was more or less the reasoning behind having these elements in
the first place, so it is a _bit_ about that. :-)
The very purpose of section and its friends is to implement explicit
sectioning on HTML, so there is no need to rely on error-prone,
painful-to-maintain implicit h1-6-based sectioning. However, the spec
recommends still using h1-6 anyway, to ensure backwards compatibility.
The compatibility goal itself is a quite good thing but, on this case,
it not only destroys the primary purpose of the feature, but makes
things even worse: having to state the same thing (the sectioning of the
document) twice (with the sectioning elements and with the numbered
headings) doubles the chance to introduce errors, and doubles the effort
required to maintain the content.
Yeah, but it's only an issue during the transition period.
In summary: the section+attribute approach solves all the issues the
current model solves
Not all of them; the main problem was
Re: [whatwg] :checked should match selected option elements
On Fri, 30 Apr 2010, L. David Baron wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-checked defines what elements match the :checked pseudo-class. However, I think it's missing an important case: selected option elements within a select. http://www.w3.org/TR/css3-selectors/#checked says: # For example, the :checked pseudo-class initially applies to such # elements that have the HTML4 selected and checked attributes as # described in Section 17.2.1 of HTML4, but of course the user can # toggle off such elements in which case the :checked # pseudo-class would no longer apply. which clearly shows that it's the intent of css3-selectors that the pseudo-class apply in this case. From looking at VCS history, Gecko has implemented :checked on option elements since Gecko 1.8 == Firefox 1.5. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should :default apply to checkboxes, radios, and options?
On Fri, 30 Apr 2010, L. David Baron wrote: For a long time, Gecko has implemented the behavior that the :default pseudo-class matches checkboxes, radios, and options that are selected by default (i.e., anything that matches :checked by default). I think supporting it for option elements is explicitly stated in the spec where :default was introduced: # One example is the default submit button among a set of buttons. # Another example is the default option from a popup menu. # Multiple elements in a select-many group could have multiple # :default elements, like a selection of pizza toppings for # example. -- http://www.w3.org/TR/css3-ui/#pseudo-default and I think supporting it for radios and checkboxes logically follows from that. However, the HTML5 spec says that :default should not apply in these cases: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-default I don't feel particularly strongly about this one, but it seems like the original intent of :default was to match both things that are the default button and things that are selected by default. Was this difference with existing implementation behavior intentional? No, that particular definition just didn't come to mind. On Fri, 30 Apr 2010, Jonas Sicking wrote: Out of curiosity, what is the use case for :default? On Fri, 30 Apr 2010, L. David Baron wrote: For buttons, it's common to present the button that's the default action for a dialog (the one that submits if you hit enter in a textfield, for example), with a thicker border. (For example, in dialog boxes in Windows.) For radios/checkboxes, one might want to present the labels corresponding to the current state in a different font (perhaps bold?) or color so that if a user switches away from the defaults they can switch back without having to remember what they changed. (I believe I've seen UI that does this, although I can't think where.) Since nobody seemed to object to this, and we already have an implementation, I've added it to the spec. I don't feel strongly about this either. Note that the definition of :default isn't quite the same as what is :checked by default. For example, the first option here matches :default, even though the second is the one that matches :checked by default, and indeed the first can never match :checked while disabled: select option disabled selectedA optionB /select I did this for compat with Firefox. We could change it but it would make the rules somewhat more convoluted. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Web Storage expiration
On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. I suspect it will be much easier to add to IndexedDB than to localStorage/sessionStorage. I don't expect the latter to go away, though generally it seems like people are disliking localStorage enough that it's hard to get any changes made to it. / Jonas
Re: [whatwg] definition of :link and :visited should allow flexibility
On Fri, 30 Apr 2010, L. David Baron wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-link says: # All a elements that have an href attribute, all area elements # that have an href attribute, and all link elements that have an # href attribute, must match one of :link and :visited. A number of user agents have recently implemented changes to handling of :link and :visited that can't be described strictly in terms of an element matching a selector. These are described in more detail in http://dbaron.org/mozilla/visited-privacy . css3-selectors has an exception that allows this: # UAs may therefore treat all links as unvisited links, or # implement other measures to preserve the user's privacy while # rendering visited and unvisited links differently. --http://www.w3.org/TR/css3-selectors/#the-link-pseudo-classes-link-and-visited HTML5 should have a similar exception that allows user agents to be more flexible than requiring that all of the elements listed match exactly one of :link and :visited. I've added a paragraph saying that another spec might introduce additional requirements here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] suggestion for HTML5 spec
On Sat, 1 May 2010, rya...@mail.com wrote: My suggestion for the HTML5 spec is that the video tag should have a feature that can enable GPU acceleration on a user's graphics card, so it will take some stress off the CPU. Do you like my suggestion? Why would a user ever want anyone to disable their GPU acceleration? On Sun, 2 May 2010, Simon Fraser wrote: The only reason I can think of why this should be exposed to web authors is if a browser is unable to use GPU accelerated for video without side effects (like always rendering on top of the rest of the content). Such an option would be similar to the wmode param on plugins, which is a huge mess, and should be avoided at all costs. One of the benefits of video being a real HTML element is that it respects CSS properties like any other element. Indeed, it seems like we'd just want this to be automatic. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] RFC: input type=username
This thread primarily discussed ways to allow users to log in and out of sites, possibly through improvements to the forms model. This is an area that seems to be under a lot of active research, so it's probably premature to change the HTML spec at this point. I haven't introduced any new form types. Some comments on a few of the specific points raised: On Tue, 4 May 2010, Eitan Adler wrote: Use cases: 1) A screen reader that sees a form with a type=username and a password field. The screen reader could just ask Log in to this site? [y/n]?. No further context would be needed. My browsers already do this on many of my sites; why can't an AT? 2) UAs can more easily discover login forms and offer things such as Firefox's Account Manager [1] or a remember me feature There are a variety of ways this can be done today (e.g. the name=, id=, or class= attributes; declarative descriptions as used by [1]; a link rel pointing to a form control; microformats; etc); a new input field type doesn't seem necessary to do this. 3) Currently autofill for usernames looks for something like id=username or name=username. However on certain websites this fails. Furthermore some websites offer a find other members feature where you could type in a username. I've often seen these fields filled in automatically with my name. Why would sites where this doesn't work today use a new feature to do this? Surely they can do this now already, so why aren't they doing it? [1] http://www.mozilla.com/en-US/firefox/accountmanager/ On Tue, 4 May 2010, Steve Dennis wrote: On 4/05/2010, at 9:07 AM, timeless wrote: Why would a site which doesn't cooperate with today's autofill features choose to cooperate with your proposal? Because id=username isn't a standard as such. Having it specified in a spec is likely to help people adopt it more quickly. RFC3106 has specified this since 2001, and has been implemented for a long time: https://tools.ietf.org/html/rfc3106 It didn't seem to do much to make adoption happen more quickly. Why would this new idea make things go faster? Saying why bother? about all the broken sites on the web totally defeats the purpose of what everyone here's trying to achieve. Sure, but we can't help these sites without their cooperation. How do we get them to cooperate? We've tried standards (RFC3106), we've tried making the user experience better (password fillers). What else can we try? Another input doesn't seem to address this. On Tue, 4 May 2010, Dirk Pranke wrote: I think this idea is halfway to what I'd want to see. Namely, we should add an input type=login field that triggers a powerbox/dialog (much like the input type=file dialog) that can collect whatever sort of credentials are needed (username / password, two-factor auth, FB connect credentials, OpenID/OAuth credentials, etc.). I agree that it should probably build on top of the Account Manager spec. I think the whole login process needs to be taken as out of page as possible. Unfortunately, the auto-login mechanism in Mozilla's prototype is probably too out of page, and so there should be a way to trigger the login from an in-page element (hence the above). I strongly urge people to experiment in this area. This is the kind of thing that should precede standardisation. On Thu, 6 May 2010, Markus Ernst wrote: Maybe it is a problem to have several functionalities mixed up in the type attribute, such as control display, autofill and validation functionalities. OTOH there are validation hints both in the type and pattern attributes. Maybe keywords could be added as possible values of the pattern attribute, in order to provide standard validation types such as e-mail, numeric, or maybe also date and datetime. input type=text pattern=email input type=username pattern=email This only seems to be a problem if we overload type= for two different axes (the type of data, in this case an e-mail address, and the intent of the data, in this case a username). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Questions about meter element
On Wed, 5 May 2010, yael.aha...@nokia.com wrote: I have a couple of questions regarding the meter element. 1. I could not find the meter element in the tables in http://dev.w3.org/html5/spec/Overview.html#annotations-for-assistive-technology-products-aria. What is the ARIA role for the meter element? I don't think ARIA currently has one that is appropriate. 2. From UA requirements for showing the gauge: When representing a meter element to the user, the UA should indicate the relative position of the actual value to the minimum and maximum values, and the relationship between the actual value and the three regions of the gauge. Considering that the default size of this element is 5em width and 1em height, how should the 3 regions be represented by the UA? The simplest way is probably a flat bar with the regions coloured (e.g. green for the optimal region, red for the regions on the other end, yellow for the remaining region if any) and with a black notch showing where the value lies. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] suggestion for HTML5 spec
On Mon, Aug 2, 2010 at 5:53 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 1 May 2010, rya...@mail.com wrote: My suggestion for the HTML5 spec is that the video tag should have a feature that can enable GPU acceleration on a user's graphics card, so it will take some stress off the CPU. Do you like my suggestion? Why would a user ever want anyone to disable their GPU acceleration? I believe I've heard people say that they might sometimes want this for power management, i.e. performing the same computation on the GPU might take more power than performing it more slowly on the CPU. I imagine this would depend on the specific configuration and computations involved, though. -- Dirk
Re: [whatwg] Input URL State and Files object
On Wed, 5 May 2010, Charles Pritchard wrote: On 5/5/2010 12:42 PM, Ian Hickson wrote: On Wed, 5 May 2010, Charles Pritchard wrote: Awhile ago, it appears, the files object was removed from input type=url files doesn't really make much sense for type=url... Do you mean type=file? Sorry, it didn't make much sense: I meant a FileList object which FileReader would use. I still don't really see what you want here. Is there currently a method for allowing cross-domain access to an image based on user input? XMLHttpRequest is the intended way to do this. XMLHttpRequest relies upon CORS headers from the server Yes. We would have to rely on CORS whatever the solution was to be. Should a user intentional drag an image or URL object, or otherwise select one from their browser UI, the interaction is quite similar to the input type=file object. Only, with a remote resource. Is this a common occurance? I'm sorry to have approached this so poorly; what I'm looking for is a solution to the following use case: A person is assembling a digital scrap-book, using a web application, of pictures they've found related to their love of kittens. Those that they've downloaded to their computer, they simply drag and drop into the application -- (File API, FileReader, ondrop). Those that they find on the internet, they drag their bookmark onto the application, drag the image onto the application, or simply, copy and paste the URL into an input type=url box. Oh, you mean the ability for the user to give the page access to remote resources that themselves aren't opting in to giving the page access. Why wouldn't input type=file be usable for this? You should be able to drag any file to that, just like you can type in a URL in Windows in an open file dialog box. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] suggestion for HTML5 spec
On Mon, Aug 2, 2010 at 6:43 PM, Dirk Pranke dpra...@chromium.org wrote: On Mon, Aug 2, 2010 at 5:53 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 1 May 2010, rya...@mail.com wrote: My suggestion for the HTML5 spec is that the video tag should have a feature that can enable GPU acceleration on a user's graphics card, so it will take some stress off the CPU. Do you like my suggestion? Why would a user ever want anyone to disable their GPU acceleration? I believe I've heard people say that they might sometimes want this for power management, i.e. performing the same computation on the GPU might take more power than performing it more slowly on the CPU. I imagine this would depend on the specific configuration and computations involved, though. That's a decision for either a user or a user agent, not an author. It should not be toggleable from HTML. - James -- Dirk
Re: [whatwg] RFC: input type=username
On Mon, Aug 2, 2010 at 6:12 PM, Ian Hickson i...@hixie.ch wrote: This thread primarily discussed ways to allow users to log in and out of sites, possibly through improvements to the forms model. This is an area that seems to be under a lot of active research, so it's probably premature to change the HTML spec at this point. I haven't introduced any new form types. Some comments on a few of the specific points raised: On Tue, 4 May 2010, Eitan Adler wrote: Use cases: 1) A screen reader that sees a form with a type=username and a password field. The screen reader could just ask Log in to this site? [y/n]?. No further context would be needed. My browsers already do this on many of my sites; why can't an AT? 2) UAs can more easily discover login forms and offer things such as Firefox's Account Manager [1] or a remember me feature There are a variety of ways this can be done today (e.g. the name=, id=, or class= attributes; declarative descriptions as used by [1]; a link rel pointing to a form control; microformats; etc); a new input field type doesn't seem necessary to do this. 3) Currently autofill for usernames looks for something like id=username or name=username. However on certain websites this fails. Furthermore some websites offer a find other members feature where you could type in a username. I've often seen these fields filled in automatically with my name. Why would sites where this doesn't work today use a new feature to do this? Surely they can do this now already, so why aren't they doing it? I suspect that this is usually a result of ignorance. I don't think many content authors are aware of how form-fillers work. [1] http://www.mozilla.com/en-US/firefox/accountmanager/ On Tue, 4 May 2010, Steve Dennis wrote: On 4/05/2010, at 9:07 AM, timeless wrote: Why would a site which doesn't cooperate with today's autofill features choose to cooperate with your proposal? Because id=username isn't a standard as such. Having it specified in a spec is likely to help people adopt it more quickly. RFC3106 has specified this since 2001, and has been implemented for a long time: https://tools.ietf.org/html/rfc3106 It didn't seem to do much to make adoption happen more quickly. Why would this new idea make things go faster? I'm not sure what you mean by has been implemented for a long time. I am not aware of any ecommerce site of any significant size implementing this standard. Having been responsible for one such site from roughly 2002-2008, I had never heard of this spec, nor have several people that I would expect to have heard of it if it had ever achieved any traction at all. This makes me suspect that this is not a great example to hold up. I think it is pretty well known that simply getting a document published and declaring it a standard is not sufficient to ensuring adoption, but not having a document published is certainly a deterrent to adoption. Saying why bother? about all the broken sites on the web totally defeats the purpose of what everyone here's trying to achieve. Sure, but we can't help these sites without their cooperation. How do we get them to cooperate? We've tried standards (RFC3106), we've tried making the user experience better (password fillers). What else can we try? Another input doesn't seem to address this. In the absence of any recommended convention that people are actually aware of, sites will continue to make life difficult for password managers and form-fillers. Encouraging people to follow a convention would be a good thing, even if we have a large legacy problem that would have to be addressed through other things. Suggesting that people follow 3106 instead of creating a new input type (which is I think what you're doing) is certainly one possible solution here. On Tue, 4 May 2010, Dirk Pranke wrote: I think this idea is halfway to what I'd want to see. Namely, we should add an input type=login field that triggers a powerbox/dialog (much like the input type=file dialog) that can collect whatever sort of credentials are needed (username / password, two-factor auth, FB connect credentials, OpenID/OAuth credentials, etc.). I agree that it should probably build on top of the Account Manager spec. I think the whole login process needs to be taken as out of page as possible. Unfortunately, the auto-login mechanism in Mozilla's prototype is probably too out of page, and so there should be a way to trigger the login from an in-page element (hence the above). I strongly urge people to experiment in this area. This is the kind of thing that should precede standardisation. Agreed; I think there is a lot of value in having a conversation about how we might improve login flows on this list, but it is too early to think that we can standardize on one particular implementation. Perhaps the WHATWG needs an experimental track in addition to a standards track? -- Dirk
Re: [whatwg] suggestion for HTML5 spec
On Mon, 2 Aug 2010, Dirk Pranke wrote: Why would a user ever want anyone to disable their GPU acceleration? I believe I've heard people say that they might sometimes want this for power management, i.e. performing the same computation on the GPU might take more power than performing it more slowly on the CPU. I imagine this would depend on the specific configuration and computations involved, though. This seems like a matter for the user, not the Web page, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] suggestion for HTML5 spec
On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 2 Aug 2010, Dirk Pranke wrote: Why would a user ever want anyone to disable their GPU acceleration? I believe I've heard people say that they might sometimes want this for power management, i.e. performing the same computation on the GPU might take more power than performing it more slowly on the CPU. I imagine this would depend on the specific configuration and computations involved, though. This seems like a matter for the user, not the Web page, though. Ah, I knew you were going to say this. I agree, but I can also imagine that the way the user selects this is by choosing one of two different resources from a page, just like we do today for videos of different bandwidths. -- Dirk
Re: [whatwg] Expanding the cite element
On Wed, 5 May 2010, Simpson, Grant Leyton wrote: Is there any value in adding an href or uri or similar attribute to the cite element to indicate a location for a work (or information about the work) or, in the case of a URI, an indicator that can be used as a reference programmatically? I don't know; is there? What would the use case be? q has a cite attribute, so it seems to me that if we have a place to link to further information in q it makes sense to do so in cite. To be honest, q cite hasn't been very successful. One could argue it is a failed experiment. :-) If it wasn't more or less harmless, I'd probably be arguing to remove it. If it were a URI (and therefore not necessarily retrievable), it would help in cases where the same work gets referenced in slightly different ways: pAs Ashley Crandall Amos says in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means of Determining the Dates of Old English Literary Texts/cite ... Amos also mentions in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means/cite/p Works tend to have as many different URIs to reference them as titles, sometimes more. :-) On Thu, 6 May 2010, Edward O'Connor wrote: cite uri has a much worse fallback story than simply embedding a link in cite. pAs Ashley Crandall Amos says in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means of Determining the Dates of Old English Literary Texts/cite ... Amos also mentions in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means/cite/p Consider how the above would work in legacy browsers, and then consider how this would work in them: pAs Ashley Crandall Amos says in citea href=http://example.com/books/crandall/linguisticmeans;Linguistic Means of Determining the Dates of Old English Literary Texts/a/cite ... Amos also mentions in citea href=http://example.com/books/crandall/linguisticmeans;Linguistic Means/a/cite/p Using a does seem like it would solve this neatly without additional effort. On Thu, 6 May 2010, Schalk Neethling wrote: I guess this is the 'Paving the cowpaths' situation. Is there a 'standard' where most developers do as in the sample by Ted? That's a good question; have people found this useful enough to work around the lack of an attribute here? If not, maybe there's no problem to solve in the first place. On Fri, 7 May 2010, Simpson, Grant Leyton wrote: 1. Referencing something in the href attributed of an a tag implies that the URI will resolve to a URL, that is, that it will be accessible on the web at that address. Not every URI is a URL, though. That's what I was trying to do with a uri attribute for the cite tag is to identify the resource, not necessarily link to it. Any link could be resolved; for example the browser could have a handler for isbn: links that looks up the book on Amazon or Google Books. 2. We would have to formally define what a within cite means, otherwise we would leave the pairing up for interpretation. Until we know that this is a problem people really want solving, that's probably ok. 3. Are there instances where tags that can be used separately take on a different meaning in relation to one another? I know what li means in relation to ol and ul, but then again, I can't really use li outside of either of those two. a wouldn't take on a different meaning, it would just add additional information to the page. On Sat, 8 May 2010, Benjamin Hawkes-Lewis wrote: I'm not opposed to adding @cite to cite but note that when you are identifying a resource rather than linking to a resource, you could use microdata or RDFa. For example: http://dev.w3.org/html5/md/#global-identifiers-for-items http://rdfa.info/wiki/Rdfa-microdata-markup-comparison#Book_markup_with_ISBN_and_description Indeed, that may be a better solution in general. 2. We would have to formally define what a within cite means, otherwise we would leave the pairing up for interpretation. You stated that you want to indicate a location for a work (or information about the work). A hyperlink indicates the location of an item or information about an item, and a href creates a hyperlink. What could be the other interpretations of citea href=...Work title/a/cite or a href=...citeWork title/cite/a other than that the hyperlink locates the work or information about the work? Indeed. 3. Are there instances where tags that can be used separately take on a different meaning in relation to one another? I know what li means in relation to ol and ul, but then again, I can't really use li outside of either of those two. I think the combination of cite and a to indicate a work title and the location of the work or information about the work does not involve changing the meaning of either cite or a. This is the markup
Re: [whatwg] suggestion for HTML5 spec
On Mon, Aug 2, 2010 at 7:09 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 2 Aug 2010, Dirk Pranke wrote: On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 2 Aug 2010, Dirk Pranke wrote: Why would a user ever want anyone to disable their GPU acceleration? I believe I've heard people say that they might sometimes want this for power management, i.e. performing the same computation on the GPU might take more power than performing it more slowly on the CPU. I imagine this would depend on the specific configuration and computations involved, though. This seems like a matter for the user, not the Web page, though. Ah, I knew you were going to say this. I agree, but I can also imagine that the way the user selects this is by choosing one of two different resources from a page, just like we do today for videos of different bandwidths. It seems better to have a way for the user agent to automaically negotiate the right bandwidth usage based on user preference, too. Any setting like this that we offer authors _will_ be misused, possibly as often as used correctly. Unless there's a really compelling reason to have it, it seems better to let the user be in control. If users can choose between two links on a page labelled high FPS - will destroy your battery and low FPS, they are in control, in a way that is easily understood by the user and allows them to make the choice at the point in time that it matters. Compare this with changing the streaming settings on QT Player or Windows Media Player, or even toggling the use the video card button on your laptop (and hoping that the content is smart enough to degrade gracefully instead of choking). We've seen this exact same argument play out over the last fifteen years in video on the web. The technology for detecting and adjusting bandwidth dynamically has been around forever (actually implemented, even), and yet for every one multi-bitrate stream available on the web, I imagine there are very many more that are single-bitrate. A big part of the reason for this is because doing it this way is (in my opinion) a better user experience. That said, I do also agree that it opens up the possibility for abuse or incorrect usage (just like it's possible to send a HD stream down a modem line). And, I'm not actually advocating a solution here one way or another, just attempting to answer your question. -- Dirk
Re: [whatwg] Race condition in media load algorithm
On 8/2/10 5:20 PM, Ian Hickson wrote: Or does stop the currently running task in #spin-the-event-loop imply a jump to step 2 of the algorithm under #processing-model2? Yes. OK, that might be worth clarifying. (Note: I still have a problem with the way pause is defined here, but I've raised that before, I believe.) I think we all have a problem with pause, but I don't know what we can do about it. I don't have any pending feedback from you on this topic, as far as I can tell. Odd. I definitely sent something about it (in particular that it doesn't seem very easily implementable in terms of network event behavior, if the pause is waiting on a network event and other network events need to not be delivered in the meantime). -Boris
Re: [whatwg] Content-Disposition property for a tags
Perhaps to avoid the legacy baggage it could be a simple attribute eg. a href=blah download This would prevent duplicating 'type', and bringing in all the knowledge people seem to not have about how 'content-disposition' works in headers. or even an extension of target? eg. a href=blah target=_save Then it would be clear that it's only a hint, like the other target values. -- James (I accidentally sent this to the wrong address before sorry for the dupe) On 3 August 2010 03:37, Boris Zbarsky bzbar...@mit.edu wrote: On 8/2/10 1:15 PM, Aryeh Gregor wrote: If you don't agree that this use-case is worth adding the feature for, do you think that: 3) Something else? For the use case your describe, it might just make more sense for browsers to support Content-Disposition on data: URIs directly somehow... Maybe. -Boris
Re: [whatwg] Input URL State and Files object
On 8/2/2010 6:54 PM, Ian Hickson wrote: On Wed, 5 May 2010, Charles Pritchard wrote: Sorry, it didn't make much sense: I meant a FileList object which FileReader would use. I still don't really see what you want here. Is there currently a method for allowing cross-domain access to an image based on user input? XMLHttpRequest is the intended way to do this. XMLHttpRequest relies upon CORS headers from the server Yes. We would have to rely on CORS whatever the solution was to be. I'm sorry to have approached this so poorly; what I'm looking for is a solution to the following use case: A person is assembling a digital scrap-book, using a web application, of pictures they've found related to their love of kittens. Those that they've downloaded to their computer, they simply drag and drop into the application -- (File API, FileReader, ondrop). Those that they find on the internet, they drag their bookmark onto the application, drag the image onto the application, or simply, copy and paste the URL into an input type=url box. Oh, you mean the ability for the user to give the page access to remote resources that themselves aren't opting in to giving the page access. Why wouldn'tinput type=file be usable for this? You should be able to drag any file to that, just like you can type in a URL in Windows in an open file dialog box. input type=file would be usable. Were this implemented: When a user through selection, click+drag or manual entry of a URL should the browser still submit an Origin request header? It seems that CORS doesn't come into effect here -- but at the same time, it'd be handy for logging purposes and added security. When a cross-site resource is fetched via CORS, the agent submits an Origin header. A secure site (such as a bank), may always return a Forbidden response if the Origin header is set; blocking any kind of cross-site sharing, even sharing attempted by a user (through an input type=file field).
