Re: Should script execution be allowed in designMode documents?

On 7/5/11 11:15 AM, Aryeh Gregor wrote:
>> 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()

Not all scripts come from <script>. What about on* attributes, say?

In any case, my post was just a description of why Gecko has the 
behavior it does, since you couldn't imagine why anyone would ever want 
that behavior.  Just helping the imagination along.  ;)

> But does anyone actually do this in practice?

No idea.

> An iframe with designMode has a couple of advantages over
> contenteditable for the common WYSIWYG "write a blog post without
> knowing HTML" case:

Sure.  Again, I'm not arguing about existence of use cases for 
"designMode as pretty text editor" use cases here; just pointing out 
that there are use cases along the "HTML editor" lines you seem to not 
have considered.

>> 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

I didn't say we're not willing to change the behavior, just said _why_ 
it is the way it is right now.  Please stop the straw-man arguments.

-Boris

Received on Tuesday, 5 July 2011 15:28:39 UTC