[whatwg] Embedding images within editable content
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.
Re: [whatwg] Thoughts on HTML 5
2008/12/21 Garrett Smith dhtmlkitc...@gmail.com Styling is done in css. Dynamic styling is currently done with the style property of HTMLElement. This is currently implemented in DOM2HTML and HTML5, but I once read they're going to write a separate CSS-Object Model, whose spec is not ready yet, but it is mentioned in the CSS current work. I don't have time to go into the all the problems with CSSOM here. Shortcomings of the CSSOM 'views' module were discussed on www-style. 'VIews' is not the only CSSOM module that has problems. Most of CSS is already implemented (like HTML, they're just standarizing what browser already do) you don't need collection either: just use appropriate DOMNodeLists, while for DOMStringMap you may use binding specific features (all Object are hash maps in ECMAScript3): it works this way even in HTML5 Where are you getting this information? What information? a) DOMNodeList are collection of ordered Nodes -- see DOM3Core for definition - if you want only Element Nodes see the Element Traversal specification by the WebApps WG b) ECMAScript Object are implemented as associative arrays (hash map / binary tree) -- see Mozilla Developer Center: it is only about Firefox, but I think all browser behave like this since they must reference arbitrary properties that are not known at compile time (if they compile) c) DOMStringMap is defined to be like ECMAScript Object -- look at its IDL: it has no members, no properties, no methods but scripts use certain features only on their own browsing context, so that may be moved from that to global scope, removing the whole window object from scope (for current javascript you can write window.window.window.window.window... and get the same as nothing) The closest definition to 'nothing' would be the value undefined. I do not know of a browser where - window.window.window === undefined is true by default. I get window. a) undefined != undefined is true in ECMAScript b) i didn't mean undefined, i mean literally nothing, eg this script window.window.window.window.window.window.window.alert(hello, world); is exactly the same as alert(hello, world); The closes thing we got to an example of invalid html is TJ post about jquery validation plugin. If you click throuh, there is an demo using a minlength custom attribute. The attribute may have the effect the author wanted it to have in a set of browses he is concerned about. That effect and the set of browsers could be more clearly demonstrated in an example that shows only that, as well as edge cases where results may vary. I don't see your point... If you can't define clearly what can be reasonably expected of a piece of (invalid) code, then nothing can be reasonably expected of it. It's not a good to write code that can't have an expected outcome. HTML5 is here to define what browser must and must not do with de-facto standards (called DOM Level 0, but also features that once were browser-specific like embed) Instead what I'm asking is only for the developer point of view. Giovanni
[whatwg] 8.2.4.4 Close tag open state
The condition here is relly long. Is there any way we can make it shorter? Cheers, Edward
Re: [whatwg] Embedding images within editable content
On Mon, Dec 22, 2008 at 2:53 AM, Shital Shah syte...@yahoo.com 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. 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. ~TJ
Re: [whatwg] Embedding images within editable content
Tab Atkins Jr. wrote: On Mon, Dec 22, 2008 at 2:53 AM, Shital Shah syte...@yahoo.com wrote: I'm wondering if there are any ideas being discussed to add an ability so users can embed images in editable areas. [snip] 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. 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.
Re: [whatwg] Embedding images within editable content
On Mon, Dec 22, 2008 at 1:33 PM, Martin Atkins m...@degeneration.co.uk wrote: 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. You can't create a file input with the filename pre-filled for obvious security reasons, but you *can* still do some clever stuff here. In order to add a picture you'll probably need them to go through a file dialog anyway to select the picture, and you can make this *actually* be the file dialog of a hidden file input. You can then move this input around in the DOM without clearing its value, and submit it transparently. It's a bit hacky, but hey, web security is Serious Business. ~TJ
Re: [whatwg] Embedding images within editable content
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 Dec 22, 2008, at 2:33 PM, Martin Atkins wrote: Tab Atkins Jr. wrote: On Mon, Dec 22, 2008 at 2:53 AM, Shital Shah syte...@yahoo.com wrote: I'm wondering if there are any ideas being discussed to add an ability so users can embed images in editable areas. [snip] 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. 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.
Re: [whatwg] 8.2.4.4 Close tag open state
On Dec 22, 2008, at 19:31, Edward Z. Yang wrote: The condition here is relly long. Is there any way we can make it shorter? Not really, but it's possible to flatten out the lookahead by adding states so that the condition in each state becomes simpler. (In fact, it's possible to remove lookahead from the tokenizer altogether by adding more states.) See Tokenizer.java in the Validator.nu HTML Parser. SVN URL: http://svn.versiondude.net/whattf/htmlparser/trunk/ -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Embedding images within editable content
Observe the following: http://granite.sru.edu/~ddailey/svg/clipembed.html In IE 4 - 7 (with the Adobe SVG plugin enabled), the end user can select an image from her own hard drive using a file upload. In IE 4, I had a similar thing (sans SVG) that worked also in Netscape. It doesn't work in the other (more standards compliant?) browsers though, and folks have cited the obvious security reasons. I had complained a year or two ago here that the spec no longer seemed to enable this. I recall someone becoming quite indignant that an author would even WANT to allow users to have access to images. The reason for the security concern as well as the indignation eluded me, and the security seems not to be SO terrible, I thought, if old Netscape and comparatively new IE7 still allowed me to do it. The ability of the browser to be able to support user-selected image content (without making a roundtrip to the server which to me seems like a bigger security risk than having local images displayed and manipulated ) seems to be at the core essence of what I would define as web hypertext applications. Hixie, responded to this thread a year or so ago, with supportive remarks (that I confess I didn't totally understand) saying that it looked as though there would be a way to do this through some mechanism that I gathered was outside the scope of WHATWG or HTML5. 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. Overall, while I respect the need for security, I think functionality is the primary objective and that security should be designed around functionality rather than the reverse. Let's make that a design principle! cheers David - Original Message - From: Tab Atkins Jr. jackalm...@gmail.com To: Martin Atkins m...@degeneration.co.uk Cc: wha...@whatwg.org Sent: Monday, December 22, 2008 2:39 PM Subject: Re: [whatwg] Embedding images within editable content On Mon, Dec 22, 2008 at 1:33 PM, Martin Atkins m...@degeneration.co.uk wrote: 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. You can't create a file input with the filename pre-filled for obvious security reasons, but you *can* still do some clever stuff here. In order to add a picture you'll probably need them to go through a file dialog anyway to select the picture, and you can make this *actually* be the file dialog of a hidden file input. You can then move this input around in the DOM without clearing its value, and submit it transparently. It's a bit hacky, but hey, web security is Serious Business. ~TJ
Re: [whatwg] Embedding images within editable content
Tab Atkins Jr. wrote: On Mon, Dec 22, 2008 at 1:33 PM, Martin Atkins m...@degeneration.co.uk wrote: 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. You can't create a file input with the filename pre-filled for obvious security reasons, but you *can* still do some clever stuff here. In order to add a picture you'll probably need them to go through a file dialog anyway to select the picture, and you can make this *actually* be the file dialog of a hidden file input. You can then move this input around in the DOM without clearing its value, and submit it transparently. It's a bit hacky, but hey, web security is Serious Business. This is indeed the solution I employed in a webapp I developed some time ago. The main irritation with it was that I needed to submit the image to the server before it could be displayed in the WYSIWYG view, which required considerable hoop-jumping to put the image in a transient location that would eventually be cleaned up if the user didn't actually end up using the image on the page, or didn't save the page at all. It also didn't work in the copy-paste case, though admittedly in that situation we usually just ended up linking to off-site images rather than file: URLs, since the copy-pasting was from other websites. In an ideal world, the content and all embedded media would be submitted together in the ultimate form submission. One approach would be to use multipart/form-data and have the browser act as if the images were in file upload form widgets, and another approach suggested by another poster was to include the image using a data: URL. In both cases I would still want to do some server-side work after submission to extract the images and store them separately, but at least the user experience matches the expectation that the image is part of the document. Of course, neither of these approaches have particularly great fallback behavior. The data: URL approach looks the most promising, but apps that are not written with that in mind will presumably end up serving the content with data: URLs and confusing downlevel browsers. At least it'll do something sensible in modern browsers, though, while still making the images available for extraction server-side if desired.
Re: [whatwg] 8.2.4.37: EOF handling
On Mon, Dec 22, 2008 at 9:33 PM, Edward Z. Yang edwardzy...@thewritingpot.com wrote: Hello all, I think EOF should be handled explicitly in the states after we Consume the U+0023 NUMBER SIGN, since the spec as it stands right now implies that there will always be another character after the number sign. Or am I being a little redundant? EOF is always treated as if it were a character, e.g. lots of places say Consume the next input character: ... EOF - ... Reconsume the EOF character in the data state. If you have # at the end of a file, the next character is the EOF character, which is not 'x' or 'X' and so it is anything else. So it seems consistent and unambiguous to me. -- Philip Taylor exc...@gmail.com
[whatwg] 8.2.4.37: EOF handling
Hello all, I think EOF should be handled explicitly in the states after we Consume the U+0023 NUMBER SIGN, since the spec as it stands right now implies that there will always be another character after the number sign. Or am I being a little redundant? Cheers, Edward
Re: [whatwg] 8.2.4.37: EOF handling
Philip Taylor wrote: EOF is always treated as if it were a character, e.g. lots of places say Consume the next input character: ... EOF - ... Reconsume the EOF character in the data state. That seems fair, although most implementations won't have an actual end of file character; they'll be checking their string index to see if they've gone out of bounds. But the spec is internally consistent (I'm just used to seeing an EOF special case on almost every state). Thanks, Edward
[whatwg] 8.2.5.10 - Adding textarea
For the steps under 'A start tag whose tag name is textarea' in 8.2.5.10 (in body insertion mode), step 3 seems wrong to me, since step 1 already includes an append operation. As specified now, it will cause two textarea elements to be added (assuming new element refers to the textarea). Cheers, kats
[whatwg] Consuming ampersands
Hello all, When I'm consuming a character reference, when does the ampersand get consumed? This doesn't seem to be obvious from the documentation, which talks of consuming character references and number hash signs, but never the ampersand. Cheers, Edward
Re: [whatwg] Consuming ampersands
On Tue, Dec 23, 2008 at 1:08 AM, Edward Z. Yang edwardzy...@thewritingpot.com wrote: Hello all, When I'm consuming a character reference, when does the ampersand get consumed? This doesn't seem to be obvious from the documentation, which talks of consuming character references and number hash signs, but never the ampersand. They're consumed in the state that comes before the character reference state, e.g.: 8.2.4.1 Data state Consume the next input character: - U+0026 AMPERSAND () ... switch to the character reference data state. -- Philip Taylor exc...@gmail.com
[whatwg] Minor typo in 8.2.4.37
in the range 0x to 0x0008, U+000B, U+000E to 0x001F, 0x007F to 0x009F, 0xD800 to 0xDFFF , 0xFDD0 to 0xFDDFin the range 0x to 0x0008, U+000B, U+000E to 0x001F, 0x007F to 0x009F, 0xD800 to 0xDFFF , 0xFDD0 to 0xFDDFin the range 0x to 0x0008, U+000B, U+000E to 0x001F, 0x007F to 0x009F, 0xD800 to 0xDFFF , 0xFDD0 to 0xFDDF U+000B is not a range. Cheers, Edward
[whatwg] Code defined for one document called after that document is no longer the one being displayed
On Thu, 15 May 2008, Jonas Sicking wrote:
Generally saying that scripts won't run once you've navigated away from
a page is wrong. For example I think that if you mutate the DOM of
document that has been navigated away from mutation-event handlers will
still fire. And UserDataHandlers will likely fire as described by spec.
The HTML5 spec now defines that once you navigate away, the scripts are
frozen, meaning that scripts defined by the page itself won't fire.
Scripts from other pages still will, though.
Not to mention that there can still be script executing for a page when the
page is navigated away from. For example:
var value = hello nurse;
onload = function() {
alert(i'm still the active page);
document.write(new page);
alert(I'm script running in the context of a page that has been +
navigated away from. See, |value| is still there: + value);
}
Right, per spec, that should work fine. (The complications are if this
code then calls some script in another document -- then if that code calls
back into this code, an exception will be raised. At least, per spec. I
tried doing what IE does, but IE's behavior is wacky, the two asserts in
this example both are true:
document.open();
document.write(scriptfunction b(w) { assert(w === window); w.w = window;
}\/script);
window.b(window);
assert(window !== window.w);
...which makes no sense to me.
[ inner windows and outer windows ]
[...] Some of this stuff is there for web compat. Such as the fact that
this results in the code executing after the document.write above still
is able to access global variables that were defined before the call.
I.e. the |value| in the second alert still works.
Per spec, document.open() doesn't replace the Window object... In fact,
right now even the global variables aren't ever nuked by document.open()
per spec. It's not really clear to me when that should happen... The
behavior of the browsers today is not interoperable at anything but a
superficial level, and the low-level behaviors are all kinda weird (e.g.
IE's behavior as described above). Of note, Safari doesn't seem to blow
away the global variables:
http://www.hixie.ch/tests/adhoc/dom/level0/document/open/008.html
http://www.hixie.ch/tests/adhoc/dom/level0/document/open/009.html
Mozilla seems to handle 'var x' differently from 'window.x', though per
the JS spec I can't find any justification for this (they should be the
same except for the former having DontDelete set).
On Tue, 5 Aug 2008, Ian Hickson wrote:
I would like some input from browser vendors.
Right now, if you navigate an iframe to a document, and take a
reference to a method defined in that document, and then navigate that
iframe to another document, and then call the method, browsers differ in
what they do.
There are several behaviours:
- In one browser, the Window object changes with each navigation,
and the global object is that object, and the method runs fine.
- In one browser, the method call fails, saying that methods can't be
called while the document that defined them isn't the active document
of the browsing context whose global object is the method's.
- In one browser, the Window object acts as a kind of view on the global
object, which changes with each navigation, leading the method to see
the original global object in its scope chain, but the new one if it
uses the 'window' object. (In this environment, 'this' at the top scope
returns the 'window' object, not the global object.)
- In one browser, the global object and the Window are the same, but the
global object is totally wiped out with each navigation, preventing the
method from accessing its global object's data. (In this browser, the
results are slightly different when navigating top-level windows
instead of frames.)
These results were derived from:
http://damowmow.com/playground/demos/global-object/004.html
I propose to adopt the second behaviour above. It seems by far the
simplest behaviour to define and implement. Are there any objections to
this? Given the lack of interoperability here, it seems like we aren't
really constrained to pick something due to compatibility.
The change would be that if a method is invoked when the script
execution context that the method was running in has a Document object
that is not the active Document object of its browsing context, then
that method immediately throws an exception. Access to variables
obtained from such script execution contexts would be unaffected.
I've now done this.
On Tue, 5 Aug 2008, Aaron Boodman wrote:
By 'method' do you mean any function object, defined anywhere in that
window? For example, does document.getElementById count? Does the foo in
var myglobal = {foo:function(){...}}; ? What about getters?
I mean any code entry-point defined by a script. So lambdas yes, getters
and
