Re: [whatwg] Video with MIME type application/octet-stream
On 13.09.2010 23:51, Aryeh Gregor wrote: ... And for heavens sake, do not specify any sniffing as official. Instead, explicitly specify all sniffing as UA specific and possibly suggest that UAs should inform the user that content is broken and the current rendering is best effort if any sniffing is required. This is totally incompatible with the compelling interoperability and security benefits of all browsers using the exact same sniffing algorithm. ... Again, there's more than browsers. And even for video in browsers, the actual component playing the video may not be part of the browser at all. So there's *much* more that would need to implement the exact same sniffing. Has anybody talked to the people responsible for VLC, Windows Media Player, and Quicktime? Best regards, Julian
Re: [whatwg] Timed tracks: feedback compendium
On Tue, Sep 14, 2010 at 6:11 PM, Philip Jägenstedt phil...@opera.comwrote: On Mon, 13 Sep 2010 15:50:09 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Mon, Sep 13, 2010 at 5:55 PM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 11 Sep 2010 01:27:48 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Fri, Sep 10, 2010 at 11:00 PM, Philip Jägenstedt phil...@opera.com wrote: On Thu, 09 Sep 2010 15:08:43 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, Sep 8, 2010 at 9:19 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 23 Jul 2010, Philip Jägenstedt wrote: If we must have both kind=subtitles and kind=captions, then I'd suggest making the default subtitles, as that is without a doubt the most common kind of timed text. Making captions the default only means that most timed text will be mislabeled as being appropriate for the HoH when it is not. Ok, I've changed the default. However, I'm not fighting this battle if it comes up again, and will just change it back if people don't defend having this as the default. (And then change it back again if the browsers pick subtitles in their implementations after all, of course.) Note that captions aren't just for users that are hard-of-hearing. Most of the time when I use timed tracks, I want captions, because the reason I have them enabled is that I have the sound muted. Hmm, you both have good points. Maybe we should choose something as the default that is not visible on screen, such as descriptions? That would avoid the issue and make it explicit for people who provide captions or subtitles that they have to make a choice. If we want people to make an explicit choice, we should make kind a required attribute and make browsers ignore tracks without it. (I think subtitles is a good default though.) I think you misunderstood - my explanation probably wasn't very good. I'm looking at it from the authoring POV. What I meant was: if I author a text track that is supposed to be visible on screen as the video plays back and if we choose either @kind=subtitle or @kind=caption as the default, then I don't have to really think through about what I authored as it will be displayed on screen. This invites people to not distinguish between whether they authored subtitles or captions, which is a bad thing, because a deaf user may then get tracks with the wrong label and expectations. If, however, we choose as a default something that is not visible on screen, e.g. @kind=description or @kind=metadata, then the author who wants their text track to be visible on screen has to give it a label, i.e. make an explicit choice between @kind=subtitle and @kind=caption. I believe this will lead to more correctly labeled content. I am therefore strongly against default labeling with either subtitle or caption. We could make @kind a required attribute instead as you are saying. OK, I think we mostly agree. Any default will sometimes be wrong, so to not have to choose between subtitles and captions, I'd still really prefer if specific HoH-tags like sound can be shown or hidden depending on user preference. I think that would lead to more content actually being written for HoH users, as it doesn't requiring maintaining 2 different files. Ah, you are talking about some kind of CSS marker for the audio events that are marked up in a caption file and that could just simple be display: none if they are viewed as a subtitle. Interesting idea... not sure that matches with the current spec though. The spec already has sound, what's missing is making the default styling of it depend on user preference and making this the recommended way of delivering HoH content. many new files will not play in the software created for the old spec. As long as we don't add a header, the files will play in most existing software. Apart from parsers that assume that SRT is plain text (and thus would be unsuitable for much existing SRT content), what kind of breakage have you found with WebSRT-specific syntax in existing software? I think we need to add a header - and possibly other things in the future. Will we forever have the SRT restrictions hold back the introduction of new features into WebSRT? Yes, if we extend SRT we can't break compatibility. However, it seems that all the extensibility needed already exists, as arbitrary tag names are handled by the parser. Your analysis of what format for headers we can introduce without breaking old SRT files speaks against that. Whatever extensions we introduce beyond what we currently have will break compatibility with some and increasingly more old SRT parsing software. Not to speak of format compatibility, which is already a non-given. You're right, adding a header breaks SRT compat. Allowing anything as part of the syntax is a bit dangerous though, as most
Re: [whatwg] Timed tracks: feedback compendium
On Tue, 14 Sep 2010 10:11:16 +0200, Philip Jägenstedt phil...@opera.com wrote: The point of a header is that browsers can identify WebSRT files and not keep parsing through a 100GB movie file, I don't think we should break SRT compat for this. I don't think this is a problem at all. We already have this situation elsewhere, e.g. what if you do link rel=stylesheet href=movie.webm? If it really turns out to be a problem you could just apply the hardware limitations clause and abort parsing if you haven't found any cues after parsing X bytes or whatever. In any case, the spec currently requires text/srt (or other supported subtitle format MIME type) for track, so a movie file would be rejected based on the MIME type per spec (see step 4 in #sourcing-out-of-band-timed-tracks). -- Simon Pieters Opera Software
Re: [whatwg] Timed tracks: feedback compendium
On Tue, 14 Sep 2010 10:33:42 +0200, Philip Jägenstedt phil...@opera.com wrote: I don't know, do we need comments anywhere? Putting them between cues might work, but is that useful? Apart from text/plain I cannot think of a web text format that does not have comments. Validators should probably recommend against them for the next couple of years though, as only browsers would support that feature in the immediate future. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Timed tracks: feedback compendium
On Tue, 14 Sep 2010 10:30:03 +0200, Simon Pieters sim...@opera.com wrote: On Tue, 14 Sep 2010 10:11:16 +0200, Philip Jägenstedt phil...@opera.com wrote: The point of a header is that browsers can identify WebSRT files and not keep parsing through a 100GB movie file, I don't think we should break SRT compat for this. I don't think this is a problem at all. We already have this situation elsewhere, e.g. what if you do link rel=stylesheet href=movie.webm? If it really turns out to be a problem you could just apply the hardware limitations clause and abort parsing if you haven't found any cues after parsing X bytes or whatever. In any case, the spec currently requires text/srt (or other supported subtitle format MIME type) for track, so a movie file would be rejected based on the MIME type per spec (see step 4 in #sourcing-out-of-band-timed-tracks). Well, I was hoping to sidestep the issue of MIME types and file extensions by always ignoring them. Last I checked Apache doesn't have a default mapping for .srt, so everyone using track would have to add it themselves. About metadata, I noticed that there's a voice called credit... -- Philip Jägenstedt Core Developer Opera Software
[whatwg] Media Accessibility Checklist, please review and comment (relates to timed tracks discussion)
The following document has recently been made available for review: http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Checklist It is the product of quite a lot of discussion and work, by a number of people, toward the goal of identifying specific needs of users with disabilities for alternative access to web-based media. It would be worthwhile to have wide review of that document to make sure it actually accomplishes that goal. So if you can make time to review it, comments and questions on it are welcome anywhere; for example, as a reply to this message, or as entries on the related Talk page here: http://www.w3.org/WAI/PF/HTML/wiki/Talk:Media_Accessibility_Checklist Thanks, --Mike -- Michael(tm) Smith http://people.w3.org/mike
[whatwg] Web Storage, Editor's Draft 20 August 2010 - Request for enhancement
I tried out local storage, used it to save the contents of a content-editable passage. It worked great in Firefox, Chrome, Safari, and MSIE. Only one problem: Every time I switched browsers, I had to start over with the original unedited passage. So I have two requests. 1. I would like the browser vendors to all use the same implementation of localStorage, as this will greatly facilitate browser-independent viewing experiences. As it stands, I have no idea how to maintain continuity if a user viewing my page in one browser switches to another browser. None. 2. Kindly extend the specification so that other applications can make constructive use of localStorage. Specifically, (a) establish a convention for associating keys with particular files (e.g., by prepending the file's path name to the key), and (b) allowing other applications to treat the file and its associated local storage as a single entity. Doing this would allow a user to e-mail the current state of a file to a friend, so that both will have the same view of the file. This ability to share "current" views of a file is useful for maintaining HTML's role as a communications vehicle. Jim Williams
Re: [whatwg] Suggested enhancement for initialization of mouse events
On Tue, 2010-09-14 at 07:51 -0400, Jim Williams wrote: Currently, there appears to be no way of sensing the location of the mouse cursor without waiting for user-initiated events. The problem is that there is no way to fill in the real current values for many of the parameters when executing the following, without copying needed information from a user-initiated mouse event such as mousemove, for example: event.initMouseEvent(type, canBubble, cancelable, view, detail, screenX, screenY, clientX, clientY, ctrlKey, altKey, shiftKey, metaKey, button, relatedTarget); This problem is one of the things that made implementation of the mousepoint event difficult [cf. http://pagenotes.com/mousepoint/mousepointEvent.htm]. Suggested Enhancement One way of addressing this problem is to allow omitted arguments that are correctly filled in by the implementation. That is to say, allow event.initMouseEvent(type, canBubble, cancelable, view, relatedTarget), where the omitted arguments reflect the mouse's current state, e.g., screenX is the mouse's current screenX coordinate. Another possibility is to enhance initEvent so that, in the case of mouse events, initEventfills in correct values for those parameters that would otherwise be set by initMouseEvent. In order for this approach to be fully effective, it would be necessary to allow an optional fourth argument for the relatedTargetparameter, in other words, allow any user defined event to supply a related target, if appropriate: event.initEvent(type, bubbles, cancelable, relatedTarget); In the case of a mouse event, this would be equivalent to event.initMouseEvent(type, canBubble, cancelable, view, detail, screenX, screenY, clientX, clientY, ctrlKey, altKey, shiftKey, metaKey, button, relatedTarget); where the additional arguments have their actual current values. On the one hand, I realize it's a bit late in the game for this sort of suggestion, but on the other, this note does point out a weakness of the event interface that could easily be removed. Jim Williams I'm not entirely sure that this is possible. As far as I know (and I could be very wrong) the events start with the OS and work their way down the system to eventually reach the Javascript through a user agent, so if the mouse has moved off of the user agent (browser) then it may not be possible to access the current coordinates. The browser would only be aware of the coordinates that it was last passed by the OS, i.e. only those in it's own window space. A browser could offer up the last known coordinates, but if the cursor is beyond the region of a browser window for example, then the browser would be passing across the wrong values. This might not matter for most cases, but then again, I can't foresee much use for having the coordinates of a cursor that triggered no event. The only time a user agent might be aware of the correct coordinates and no event would be triggered would be where the cursor was over part of the user agent that wasn't the web page, like the menubar, etc. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Media Accessibility Checklist, please review and comment (relates to timed tracks discussion)
Michael(tm) Smith m...@w3.org, 2010-09-14 19:26 +0900: So if you can make time to review it, comments and questions on it are welcome anywhere; for example, as a reply to this message, or as entries on the related Talk page here: http://www.w3.org/WAI/PF/HTML/wiki/Talk:Media_Accessibility_Checklist It was brought to my attention that the above page is editable only by certain people in the W3C user DB. So, I have made a copy of the associated page, with its own Talk page: http://www.w3.org/html/wiki/Talk:MediaAccessibilityChecklist You will need to set up a W3C user account in order to authenticate to edit that -- but anybody is welcome to open such an account. That said, as I mentioned before, comments here are welcome also. --Mike -- Michael(tm) Smith http://people.w3.org/mike
Re: [whatwg] Suggested enhancement for initialization of mouse events
On 9/14/2010 5:00 AM, Ashley Sheridan wrote: I'm not entirely sure that this is possible. As far as I know (and I could be very wrong) the events start with the OS and work their way down the system to eventually reach the Javascript through a user agent, so if the mouse has moved off of the user agent (browser) then it may not be possible to access the current coordinates. The browser would only be aware of the coordinates that it was last passed by the OS, i.e. only those in it's own window space. A browser could offer up the last known coordinates, but if the cursor is beyond the region of a browser window for example, then the browser would be passing across the wrong values. This might not matter for most cases, but then again, I can't foresee much use for having the coordinates of a cursor that triggered no event. The only time a user agent might be aware of the correct coordinates and no event would be triggered would be where the cursor was over part of the user agent that wasn't the web page, like the menubar, etc. Even if the browser could tell you the mouse coordinates of a cursor that wasn't over the content/frame in question, doing so would be a serious security problem. The only way this would make sense is for the omitted arguments to reflect the last mouse event you received... but that's more ugly than simply remembering them from that last event yourself. Matthew Kaufman
Re: [whatwg] Suggested enhancement for initialization of mouse events
Interesting points. Possibly, my proposed cure is worse than the original problem. Jim Williams Matthew Kaufman wrote: On 9/14/2010 5:00 AM, Ashley Sheridan wrote: I'm not entirely sure that this is possible. As far as I know (and I could be very wrong) the events start with the OS and work their way down the system to eventually reach the _javascript_ through a user agent, so if the mouse has moved off of the user agent (browser) then it may not be possible to access the current coordinates. The browser would only be aware of the coordinates that it was last passed by the OS, i.e. only those in it's own window space. A browser could offer up the last known coordinates, but if the cursor is beyond the region of a browser window for example, then the browser would be passing across the wrong values. This might not matter for most cases, but then again, I can't foresee much use for having the coordinates of a cursor that triggered no event. The only time a user agent might be aware of the correct coordinates and no event would be triggered would be where the cursor was over part of the user agent that wasn't the web page, like the menubar, etc. Even if the browser could tell you the mouse coordinates of a cursor that wasn't over the content/frame in question, doing so would be a serious security problem. The only way this would make sense is for the omitted arguments to reflect the last mouse event you received... but that's more ugly than simply remembering them from that last event yourself. Matthew Kaufman
Re: [whatwg] Web Storage, Editor's Draft 20 August 2010 - Request for enhancement
On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams jgwilli...@mindspring.com wrote: I tried out local storage, used it to save the contents of a content-editable passage. It worked great in Firefox, Chrome, Safari, and MSIE. Only one problem: Every time I switched browsers, I had to start over with the original unedited passage. So I have two requests. 1. I would like the browser vendors to all use the same implementation of localStorage, as this will greatly facilitate browser-independent viewing experiences. As it stands, I have no idea how to maintain continuity if a user viewing my page in one browser switches to another browser. None. Like cookies, all browser data will be dependent on the browser. There's very little chance of this ever changing. Users rarely switch browsers, in any case. We web developers are a rare exception. 2. Kindly extend the specification so that other applications can make constructive use of localStorage. Specifically, (a) establish a convention for associating keys with particular files (e.g., by prepending the file's path name to the key), and (b) allowing other applications to treat the file and its associated local storage as a single entity. Doing this would allow a user to e-mail the current state of a file to a friend, so that both will have the same view of the file. This ability to share current views of a file is useful for maintaining HTML's role as a communications vehicle. The FileSystem API is designed for this use-case, so you can build a file in javascript and ask the user to save it to their harddrive. ~TJ
Re: [whatwg] Web Storage, Editor's Draft 20 August 2010 - Request for enhancement
On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams jgwilli...@mindspring.com wrote: I tried out local storage, used it to save the contents of a content-editable passage. It worked great in Firefox, Chrome, Safari, and MSIE. Only one problem: Every time I switched browsers, I had to start over with the original unedited passage. So I have two requests. 1. I would like the browser vendors to all use the same implementation of localStorage, as this will greatly facilitate browser-independent viewing experiences. As it stands, I have no idea how to maintain continuity if a user viewing my page in one browser switches to another browser. None. If you need persistent cross-browser state, on a page that you control, why not just store it server-side? Then it also works from multiple computers, which even your proposed modifications to localStorage won't get you. 2. Kindly extend the specification so that other applications can make constructive use of localStorage. Specifically, (a) establish a convention for associating keys with particular files (e.g., by prepending the file's path name to the key), and (b) allowing other applications to treat the file and its associated local storage as a single entity. Doing this would allow a user to e-mail the current state of a file to a friend, so that both will have the same view of the file. This ability to share current views of a file is useful for maintaining HTML's role as a communications vehicle. Jim Williams
Re: [whatwg] Video with MIME type application/octet-stream
On 2010-09-13 15:55, Nils Dagsson Moskopp wrote: Mikko Rantalainenmikko.rantalai...@peda.net schrieb am Mon, 13 Sep 2010 16:03:27 +0300: […] Basically, this sounds like all the issues of BOM for all binary files. And why do we need this? Because web servers are not behaving correctly and are sending incorrect Content-Type headers? What makes you believe that BINID will not be incorrectly used? (If you really believe that you can force content authors to provide correct BINIDs, why you cannot force content authors to provide correct Content-Types? Hopefully the goal is not to sniff if BINIDs seems okay and ignore clearly incorrect ones in the future...) This. BINID may be a well-intended idea, but would be an essentially useless additional layer of abstraction that provides no more safeguards against misuse than the Content-Type header. The latter also required no changes to current binary file handling — which for BINID would need to be universally updated in every conceivable device that could ever get a BINID file. Yeah! That is the one shorterm drawback, while the longterm benefit is that file extensions and content type would be redundant (as the files themselves would inform what they are, in a standard way). Oh well! I can always dream that some form of binary id will come about in the next decade or so I guess...*laughs* -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
Re: [whatwg] Video with MIME type application/octet-stream
On 2010-09-14 08:37, Julian Reschke wrote: On 13.09.2010 23:51, Aryeh Gregor wrote: ... And for heavens sake, do not specify any sniffing as official. Instead, explicitly specify all sniffing as UA specific and possibly suggest that UAs should inform the user that content is broken and the current rendering is best effort if any sniffing is required. This is totally incompatible with the compelling interoperability and security benefits of all browsers using the exact same sniffing algorithm. ... Again, there's more than browsers. And even for video in browsers, the actual component playing the video may not be part of the browser at all. So there's *much* more that would need to implement the exact same sniffing. Has anybody talked to the people responsible for VLC, Windows Media Player, and Quicktime? Best regards, Julian Good question, I can only speak for my self as a developer but I imagine that anything that allows a media player to stop sniffing sooner in a file is very welcome indeed as that saves resources (memory, disk access, faster initialization of the codec and user related interface feedback, etc.) Legacy files will always be an issue obviously, but there is no reason to let future files remain just as difficult, eventually legacy files will vanish or be transcoded or have their beginning patched to take advantage of it. (in the case of my proposal one could easily add it by hand using a hex editor, so it's certainly not difficult to support in that regard.) -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
Re: [whatwg] ArrayBuffer and ByteArray questions
Yes, we only need to add it to BlobBuilder so that it can be applied to both FileReader, XHR.send and any other place that take the blob. On Wed, Sep 8, 2010 at 10:57 AM, Eric Uhrhane er...@google.com wrote: On Tue, Sep 7, 2010 at 4:09 PM, Jian Li jia...@chromium.org wrote: Hi, Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html ), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? It seems like an obvious addition for BlobBuilder or XHR.send, but do we need it in both, or is one sufficient? Thanks, Jian
Re: [whatwg] ArrayBuffer and ByteArray questions
On Tue, 14 Sep 2010 21:13:46 +0200, Jian Li jia...@chromium.org wrote: Yes, we only need to add it to BlobBuilder so that it can be applied to both FileReader, XHR.send and any other place that take the blob. send() takes everything straight as well. BlobBuilder should not be a prerequisite to transmit bytes, in my opinion. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Web Storage, Editor's Draft 20 August 2010 - Request for enhancement
I see localStorage and sessionStorage as a chance to fix things that weren't so good with cookies. So I'd be interested to know what factors actively promote the failure to come up with a common browser-independent interface for localStorage. Do browser builders actually have something to gain by resisting interoperability here? I'd also be interested to see some actual data on how often people switch browsers. Much of my own browser-switching experiences have to do, not with web development, but with online courseware that was designed to run on a particular browser - and then I follow links on whatever browser I'm on at the moment, so that the same sites often turn up on both browsers. I also know nontechnical people who just like downloading and playing with stuff, including browsers. Also, yes, one could use the file system API in place of cookies or other local storage, but that tends to interrupt the user's flow of thought, so I'd prefer to avoid such heavy-handedness without having a good reason. Tab Atkins Jr. wrote: On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams jgwilli...@mindspring.com wrote: I tried out local storage, used it to save the contents of a content-editable passage. It worked great in Firefox, Chrome, Safari, and MSIE. Only one problem: Every time I switched browsers, I had to start over with the original unedited passage. So I have two requests. 1. I would like the browser vendors to all use the same implementation of localStorage, as this will greatly facilitate browser-independent viewing experiences. As it stands, I have no idea how to maintain continuity if a user viewing my page in one browser switches to another browser. None. Like cookies, all browser data will be dependent on the browser. There's very little chance of this ever changing. Users rarely switch browsers, in any case. We web developers are a rare exception. 2. Kindly extend the specification so that other applications can make constructive use of localStorage. Specifically, (a) establish a convention for associating keys with particular files (e.g., by prepending the file's path name to the key), and (b) allowing other applications to treat the file and its associated local storage as a single entity. Doing this would allow a user to e-mail the current state of a file to a friend, so that both will have the same view of the file. This ability to share "current" views of a file is useful for maintaining HTML's role as a communications vehicle. The FileSystem API is designed for this use-case, so you can build a file in _javascript_ and ask the user to save it to their harddrive. ~TJ
Re: [whatwg] Web Storage, Editor's Draft 20 August 2010 - Request for enhancement
The application I'm mainly thinking of is courseware, and it indeed does need to obtain server-side copies of students' work. But, academia being what it is, these systems tend to get overused and bog down and crash, inflicting furor and anguish on students and professors alike. An ability for the courseware to run partly offline on student computers improves reliability. But I want students concentrating on their math, not offline/online storage sharing strategies. Security is another consideration. Building experimental user-server exchange mechanisms isn't tolerated in my work environment, as you might imagine. So if I can use localStorage to simulate server-side storage and build a proof-of-concept prototype that's entirely on the user's computer [i.e., mine], I have more opportunity to demo what I'm doing. Following these ideas a little further, there's good reason to retain the user-side mechanisms in a production version, and just have the server check and sign user successes. As the server-side checks succeed, the user can migrate his results to other students or a professor, possibly via e-mail. That's why I'd like to have localStorage implemented in an e-mail compatible fashion. Hopefully, the localStorage implementation would also be compatible with dropboxes. But you're right about maintaining state across multiple computers. It would be nice to have a background mechanism for migrating student work from one student computer to another. Eric Uhrhane wrote: On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams jgwilli...@mindspring.com wrote: I tried out local storage, used it to save the contents of a content-editable passage. It worked great in Firefox, Chrome, Safari, and MSIE. Only one problem: Every time I switched browsers, I had to start over with the original unedited passage. So I have two requests. 1. I would like the browser vendors to all use the same implementation of localStorage, as this will greatly facilitate browser-independent viewing experiences. As it stands, I have no idea how to maintain continuity if a user viewing my page in one browser switches to another browser. None. If you need persistent cross-browser state, on a page that you control, why not just store it server-side? Then it also works from multiple computers, which even your proposed modifications to localStorage won't get you. 2. Kindly extend the specification so that other applications can make constructive use of localStorage. Specifically, (a) establish a convention for associating keys with particular files (e.g., by prepending the file's path name to the key), and (b) allowing other applications to treat the file and its associated local storage as a single entity. Doing this would allow a user to e-mail the current state of a file to a friend, so that both will have the same view of the file. This ability to share "current" views of a file is useful for maintaining HTML's role as a communications vehicle. Jim Williams
Re: [whatwg] Web Storage, Editor's Draft 20 August 2010 - Request for enhancement
On Tue, Sep 14, 2010 at 4:30 PM, Jim Williams jgwilli...@mindspring.com wrote: I see localStorage and sessionStorage as a chance to fix things that weren't so good with cookies. So I'd be interested to know what factors actively promote the failure to come up with a common browser-independent interface for localStorage. Do browser builders actually have something to gain by resisting interoperability here? I think you're coming at it from a quite different point of view than browser builders usually have. When we implement e.g. our localStorage database, having it use the same file format as Opera is the furthest thing from our mind. Even if we wanted to share data with them, how would we make sure that we didn't both write the file at the same time? How would we know when to update our in-memory state from disk? What if you had multiple Firefox profiles that each used a different set of cookies--which profile should sync with Opera? These are huge problems and lots of work, and for very little payoff. I'd also be interested to see some actual data on how often people switch browsers. Much of my own browser-switching experiences have to do, not with web development, but with online courseware that was designed to run on a particular browser - and then I follow links on whatever browser I'm on at the moment, so that the same sites often turn up on both browsers. I also know nontechnical people who just like downloading and playing with stuff, including browsers. Also, yes, one could use the file system API in place of cookies or other local storage, but that tends to interrupt the user's flow of thought, so I'd prefer to avoid such heavy-handedness without having a good reason. Tab Atkins Jr. wrote: On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams jgwilli...@mindspring.com wrote: I tried out local storage, used it to save the contents of a content-editable passage. It worked great in Firefox, Chrome, Safari, and MSIE. Only one problem: Every time I switched browsers, I had to start over with the original unedited passage. So I have two requests. 1. I would like the browser vendors to all use the same implementation of localStorage, as this will greatly facilitate browser-independent viewing experiences. As it stands, I have no idea how to maintain continuity if a user viewing my page in one browser switches to another browser. None. Like cookies, all browser data will be dependent on the browser. There's very little chance of this ever changing. Users rarely switch browsers, in any case. We web developers are a rare exception. 2. Kindly extend the specification so that other applications can make constructive use of localStorage. Specifically, (a) establish a convention for associating keys with particular files (e.g., by prepending the file's path name to the key), and (b) allowing other applications to treat the file and its associated local storage as a single entity. Doing this would allow a user to e-mail the current state of a file to a friend, so that both will have the same view of the file. This ability to share current views of a file is useful for maintaining HTML's role as a communications vehicle. The FileSystem API is designed for this use-case, so you can build a file in javascript and ask the user to save it to their harddrive. ~TJ
