[whatwg] Image.src and file://

[Ian Hickson]

On Wed, 25 Mar 2009, ddailey wrote:
> 
> If we make a puzzle of 2n-squared minus 1 (e.g. a puzzle of 15) in which 
> web site visitors can slide tiles around through a grid, we might wish 
> to detect, through script, when the puzzle has been "solved." This means 
> interrogating the value of Image.src as resolved by the browser. In IE, 
> Chrome and FF I noted today (something different than it was a year or 
> so ago) that for content served from the local drive space (in Windows 
> anyhow), document.images[x].src resolves to file:///C:/ [path].  In 
> Opera, it still resolves to "file://localpath:/" . Hence, script to 
> determine if the puzzle has been solved has to resort to a wee bit of 
> mischief to untangle the issue. Over the past nine years or so, I've 
> seen at least a half dozen different strategies employed by various 
> browsers to deal with the issue, ranging from the sensible to the 
> bizarre, varying as a function of where the file is found (in local 
> drive space, networked files, or even files served from the web). Where 
> might we expect things to settle down ultimately?

I think the basic answer is that if you're using file://, that you're not 
on the Web, and so interoperability isn't a priority. However, if there 
could be a good file:// spec written, that could solve the problem.


> P.S. I gather from what you've written here, that indeed the spec will 
> simplify access to local drive space through input type=file eventually, 
> hence allowing client-side image manipulation for web applications? Will 
> this solution propagate outward into SVG as well, where it will also be 
> quite useful, or only if the SVG is inlined in HTML?

The feature of <input type=file> would work in SVG if the HTML is inlined 
into the SVG.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'