[whatwg] Range.createContextualFragment in SVG contexts
I'm trying to re-implement Range.createContextualFragment in Blink following this whatwg spec: http://domparsing.spec.whatwg.org/#extensions-to-the-range-interface There are two issues I'd like to discuss, related to the use of createContextualFragment in SVG contexts. 1) If a Range's context is an svg element, I think the XML parsing algorithm should be selected, so the elements in the resulting DocumentFragment would get the SVG namespace. This way, inserting the fragment in an svg tree would have the intended effect. Examples: https://bug711821.bugzilla.mozilla.org/attachment.cgi?id=582654 (the red circle should be completely covered by a black circle) https://codereview.chromium.org/115693010/diff/70001/LayoutTests/fast/dom/Range/create-contextual-fragment-from-svg-element-range.html 2) If a Range's context is an SVG document, step 2 in the createContextualFragment algorithm will see a null element, and I think it should create an element in the SVG namespace (not the HTML namespace) with the local name svg (not body). Again, this is so that inserting the resulting DocumentFragment in the svg tree would work as intended. I spent a bit of time thinking of how one would get a Range pointing to an SVG document, to see if this issue even applies to HTML5. I eventually found that using svg inside embed creates an SVG document inside the HTML5 document, so I can use createRange on the HTML5 document, and then pass the SVG document to Range.setStart. I can post code if it helps make this clearer. I look forward to your thoughts and comments. Victor
Re: [whatwg] Make the files attribute of the input element writable
On Wed, Dec 5, 2012 at 12:11 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Dec 2012, Victor Costan wrote: There was a thread on this mailing list discussing making it possible to set the file data behind an input type=file element. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 The thread seems to have died down due to insufficient applications for the proposal. Actually the reason this thread hasn't gone anywhere is that there seems to only be implementer interest from Chrome. See: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest Thank you very much for explaining! I can file a bug against Firefox, and argue for it. I think I would have an easier time making an argument if I knew how the API should look like. Can you please give me a hint as to which variant you'd be more likely to agree with? Mutable FileLists vs a way to put together a new FileList + writable files attribute on input type=file? File constructor taking a Blob + name vs having Blobs in a FileList? 1) This would make it possible to write JavaScript libraries that seamlessly scan the current page for input type=file and add integration with Dropbox / Google Drive / Sky Drive etc. I claim that changing the input value is the easiest and most robust method of achieving this without requiring changes to the main application code. Asides from providing an easy path for developers to integrate online storage services into their apps, this change would make it easy to write bookmarklets / browser extensions that add this functionality to any Web application. It seems like this use case would be better handled by having the sites offer an API to the browser, similar to Web Intents, for picking a file. That way you wouldn't need to update each site -- every site would support all the drive systems you use. Yes, but that approach would require deeper application changes. I think that adding a couple of script tags next to an existing input type=file is easier to implement. 2) If I can set the files attribute of an input type=file, I can write unit tests for any code that deals with such an input, such as XHR uploads. Tested code is less likely to break down as it is maintained, so it makes for a better Web. That's an interesting use case, indeed. Thank you! In general, read-only APIs make testing really hard :( 3) Browser extensions / bookmarklets could easily filter files being uploaded. For example, an extension could automatically resize pictures larger than a certain threshold by rendering them to an off-screen canvas. As another example, an extension could detect when huge files are uploaded to a Web mail client or forum, automatically upload them to Dropbox / Google Drive / Sky Drive, and replace them in the input type=file with tiny .url files pointing to the real files. In general, browser extensions don't have to be handled by Web standard APIs, so I'm not sure that's a compelling use case. I think it would be useful to have a drop-in JS library that can perform image resizing on the fly without requiring XHR-based form submission. With these applications in mind, I don't think FileList needs to accept Blobs. Instead, there should be an easy way to build a File out of a Blob and a file name. This capability seems to have been lost when BlobBuilder was deprecated by the Blob constructor. There are places where FileList definitely needs to be readonly, so I don't think it makes sense to make it globally writable. but there could be a MutableFileList or something. That feedback should be sent to the list mentioned at the top of the File API spec. FileList doesn't have to be mutable if there is a FileList constructor that accepts File instances, or if the files attribute of input type=file accepts an array of File instances and converts it into a FileList. I will start a discussion on the public-weba...@w3.org. For reference, they seem to be in favor of a File constructor. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0692.html Thank you very much for your consideration, Victor
[whatwg] Make the files attribute of the input element writable
Dear WHATWG, There was a thread on this mailing list discussing making it possible to set the file data behind an input type=file element. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 The thread seems to have died down due to insufficient applications for the proposal. I would like to urge you to reconsider the proposal, and bring up a few arguments for it. 1) This would make it possible to write JavaScript libraries that seamlessly scan the current page for input type=file and add integration with Dropbox / Google Drive / Sky Drive etc. I claim that changing the input value is the easiest and most robust method of achieving this without requiring changes to the main application code. Asides from providing an easy path for developers to integrate online storage services into their apps, this change would make it easy to write bookmarklets / browser extensions that add this functionality to any Web application. 2) If I can set the files attribute of an input type=file, I can write unit tests for any code that deals with such an input, such as XHR uploads. Tested code is less likely to break down as it is maintained, so it makes for a better Web. 3) Browser extensions / bookmarklets could easily filter files being uploaded. For example, an extension could automatically resize pictures larger than a certain threshold by rendering them to an off-screen canvas. As another example, an extension could detect when huge files are uploaded to a Web mail client or forum, automatically upload them to Dropbox / Google Drive / Sky Drive, and replace them in the input type=file with tiny .url files pointing to the real files. With these applications in mind, I don't think FileList needs to accept Blobs. Instead, there should be an easy way to build a File out of a Blob and a file name. This capability seems to have been lost when BlobBuilder was deprecated by the Blob constructor. I think sticking to files that can be created out of Blobs would allow the reuse of the current default UI for input type=file with few changes. Thank you for your consideration, Victor Victor Costan | vic...@costan.us | www.costan.us | +1 (646) 434-8887 Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science, B.S. '07, M.Eng '08, Ph.D. '14 Sloan School of Management, B.S. '07
