- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 3 Sep 2009 23:20:29 +0000 (UTC)
On Mon, 22 Dec 2008, Shital Shah wrote: > > I'm wondering if there are any ideas being discussed to add an ability > so users can embed images in editable areas. > > Many modern web applications including blogs and wikis allow users to > visually edit content with rich formatting. However present limitation > with all browsers is lack of ability to insert images and other media > when editing this content. This limitation to insert images visually and > naturally within editable content holds back several novice and even > expert users to create rich content in web effortlessly. Please comment > if any ideas being considered to solve this problem within HTML5 or > future specifications roadmap. On Mon, 22 Dec 2008, Tab Atkins Jr. wrote: > > I'm confused about what you're asking. All decent WYSIWYG editors *do* > allow users to insert images, and often other media. You can see the > image right in the display next to all the text while you're editting > it. On Mon, 22 Dec 2008, Douglas Mayle wrote: > > I replied to the originator of this thread, but forgot to include the > list. Shital was talking about rich paste and the ability to embed > images. As of IE8, all of the major browsers support data URI's for > images, but none of them will generate that on paste... > > I work on Xinha(WYSIWYG editor), and I know that it's possible to > generate this with Gears, or maybe also with Canvas, but I don't see how > we could do anything in HTML5... On Mon, 22 Dec 2008, Martin Atkins wrote: > > I don't know what the original poster was asking about, but one issue > I've encountered in this area is that users want to embed images from > their own local drives rather than having to separately upload them to > the server first. > > Unfortunately, the in-browser editors often make it look like this is > going to work; users manage to get embedded images with file:// URLs > that seem to work for that user but obviously will not work for any > other user. > > However, I'm not sure what the solution is here. If contentEditable was > a "real" form widget you could imagine it supporting a > multipart/form-data upload of all of its contained images, or something. > However, as long as client-side code is manually shifting the data to > and from real widgets it's not clear how to do this since you can't just > create a file-upload control with the filename pre-populated and submit > it transparently. This is now handled by drag-and-drop and <input type=file> supporting local File access. On Mon, 22 Dec 2008, ddailey wrote: > > While we're on the subject, I would really like to be able to read pixel > values from local images by plugging them into (as through a input > type=file) a <canvas>. Having access to pixel values, allows certain > filter effects to be defined in JavaScript rather than relying on the > preexisting filters build into canvas and SVG. Not only that but > analysis of image data (as in scientific image processing) would be > enabled. This is possible now. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 3 September 2009 16:20:29 UTC