On Oct 3, 2013, at 6:35 PM, Brian Matthews (brmatthe) wrote:
> First is the status bar display for anchors while hovering over them. As > expected, it's the blob URL. While this is completely correct and exactly > what I'd expect, I'm not sure how useful it is. For an anchor with a "normal" > URL, the user is told something about where the resource is (the domain name > and path, "http://example.com/order";), and what it is (the last element of > the path, "invoice.pdf"). With a blob URL, they're told where it is (at least > for those who know what a blob URL is, or accept that "blob:..." is something > magic they don't need to know about :-) ), but nothing about what it is. This is an implementation issue that goes beyond the spec. (as others have remarked, this kind of thing falls under the purview of UI/UX, which web specifications rarely touch on meaningfully), but I think it is probably a useful informative comment that I'll add as part of "LC Commentary" changes. I think you should file bugs on all browser projects that you'd like to see this kind of thing implemented in. It's a useful feature for end-users. > Second, and related, is what happens when someone saves an image or target of > a link. In both cases with "normal" URLs, there's a name component and the > user agent can use that as the name of the resulting file, or suggest it if > doing a Save As.... With blob URLs, there is no name, so the user agent has > to make up a name. So with Firefox one gets fun names like index.gif (when > saving an <img>), or bf_UK+0O.gif and y+f+wR9a.pdf (when saving the target of > an anchor), and Chrome uses the opaqueString part of the URL, resulting in > names like 49c122d8-0958-4dfd-ac9c-0a6245c5f91f..gif. None of those exactly > brim with semantic content. OK, I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23450 I'm not fully convinced by other commentors on this listserv that we should use Content-Disposition as how to do this. I think "how" Save As is implemented is a detail left to browsers, but I think the part of using file name is useful during Save As. > Also, 8.5.6 step 1 in the spec starts "Fire a progress event called error. > Set the error attribute;". Doesn't firing an event call the event handlers > immediately? If so, this seems to be saying to call the error handler > *before* setting the error attribute, which seems backwards. Yes, I agree! https://www.w3.org/Bugs/Public/show_bug.cgi?id=23451 Thanks for your thoughtful LC commentary. -- A*
