- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Tue, 5 Jul 2011 11:15:37 -0400
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: HTML WG <public-html@w3.org>
On Thu, Jun 30, 2011 at 4:44 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > That's because you're presupposing what people are using HTML editors for, I > think. Undoubtedly. I haven't seen any real-world web use-cases other than WYSIWYG editing. >> (which can't be a huge deal if Chrome hasn't seen issues) > > Have they not? When did they change the behavior from the one seen in > Safari 5? I don't know. They'd have to say. > For one thing because in the context of a wysiwyg HTML editor (think > something like an authoring tool, as opposed to a wysiwyg pretty text editor > that happens to use HTML as its data representation but hides it completely) > it makes no sense to run the scripts as the author authors them. I don't get how this would work. Modifying a script element that's already in the DOM will not cause anything to execute no matter what. Adding a script element to the DOM isn't possible using execCommand(), so authors would have to develop their own function to do it, and presumably someone going to the effort of writing such an editor could figure out to avoid script execution by just adding an empty script element to the DOM and only adding contents to it afterward. On the other hand, if you set designMode to on for an iframe and then navigate the iframe so that the user can edit an arbitrary existing page and maybe save it someplace, probably you don't want the scripts to run. After all, if they modify the DOM, you're going to be saving a different page from the one that was loaded, since you'll have the DOM changed but you'll also have the original scripts still in the DOM, and they'll run again when you load the page. Or maybe the user wrote the page in the first place including some scripts (added using non-execCommand() functionality), saved it someplace, loaded it again, and doesn't want the script to run. But does anyone actually do this in practice? An iframe with designMode has a couple of advantages over contenteditable for the common WYSIWYG "write a blog post without knowing HTML" case: 1) It's more robust against browser bugs. Gecko in particular likes to throw exceptions for contenteditable in all sorts of common cases (like <div contenteditable>foo</div>, select "foo" and do execCommand("indent")). I've also seen bugs where browsers will change elements outside of contenteditable ancestors, evidently going up through the DOM without checking if the element they're looking at is still editable. I know my algorithms currently have lots of bugs like this at the moment. 2) It can more easily be styled separately. So while I grant that the narrow use-case I outlined above would be harder to do if script executed when designMode is on, I'm a bit skeptical about whether it's worth it unless people are actually doing things like that. Prohibiting script execution in designMode is confusing and occasionally inconvenient for relatively little benefit. If we do prohibit script execution in designMode, though, we should at least let the script that sets designMode run to execution, if it was set by the page itself. IE9 has the fairly crazy behavior that if a script sets document.designMode = "on", no further statements in the script execute. Firefox 6.0a2 and Opera 11.50 seem like they run that script to completion, but ignore any further scripts. Chrome 14 dev, of course, just runs all script. > In Gecko's case, whole-document designMode is based on code written to > support the former use case (the old suite's HTML editor, in particular). That's all very well, but for speccing purposes I'm only concerned with use-cases on web pages, not use-cases internal to browsers. The latter can be done in a nonstandard way. In my research of real-world contenteditable/designMode usage so far, which I grant was not especially thorough or systematic, the only thing I've found is "write a WYSIWYG blog post" type stuff, and authors use contenteditable and designMode interchangeably for that purpose. Unnecessary differences should be avoided.
Received on Tuesday, 5 July 2011 15:16:33 UTC