[whatwg] Embedding images within editable content

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'