On 24 Aug 2005 at 0:17, Ian Hickson wrote:
Could we extend contentEditable in a way that would let the UA offer a
non-scripting UI for saving the edited page? For example using the
form attribute from WF2?
What's wrong with File Save ?
I meant Save as in submit to the server (thought
Ian Hickson wrote:
Why does Web Forms 2 not deal with the textInput event from DOM
Level 3 Events?
http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-textInput
Is there something about DOM 3 Events' description that is ambiguous
in terms of WF2?
It looks equivalent to the 'input'
Dimitri Glazkov wrote:
I was thinking more along of the lines of this:
div contentEditable id=mainPageContent ... /div
form
input name=mainPageContentEdit type=html src=#mainPageContent /
/form
Perhaps we should allow the 'form' attribute from Web Forms 2 on all
elements that have the
Lachlan Hunt wrote:
And, as I demonstrated in an earlier e-mail with the widgEditor I linked
to, it's not hard for an author to provide a script that converts the
textarea to a WYSIWYG editor using the contentEditable DOM interface.
It's not much different from the scripts that are being
Anne van Kesteren wrote:
Dimitri Glazkov wrote:
I was thinking more along of the lines of this:
div contentEditable id=mainPageContent ... /div
form
input name=mainPageContentEdit type=html src=#mainPageContent /
/form
Perhaps we should allow the 'form' attribute from Web Forms 2 on all
Matthew Raymond wrote:
No, because you'd still be missing the |name| of the control. The
|id| is not the same thing as a control name. Also not that you loose
stuff like disable, readonly, and a host of new WF2 stuff as well...
I'm aware that the 'name' and 'id' attribute are not equivalent.
Lachlan Hunt wrote:
Anne van Kesteren wrote:
From a semantic point of view contentEditable is much better than a textarea
hack.
contentEditiable is not semantic, it's behavioural and belongs in the
DOM interface only, not the markup.
Yeah, I think you may have a point. It may make
On Wed, 24 Aug 2005, Lachlan Hunt wrote:
Anne van Kesteren wrote:
From a semantic point of view contentEditable is much better than a textarea
hack.
contentEditiable is not semantic, it's behavioural and belongs in the DOM
interface only, not the markup.
How is it not semantic? It's not
On Wed, 24 Aug 2005, Matthew Raymond wrote:
Yeah, I think you may have a point. It may make more sense to enable
editing of DOM Ranges through scripting rather than putting it in
markup.
Uh, that would be unbelievably hard to implement.
After all, if we're going to be dynamically
Ian Hickson wrote:
Perhaps we should allow the 'form' attribute from Web Forms 2 on
all elements that have the 'contenteditable' attribute set.
What would the processing model be?
It might be useful to have this, but I think it does not cover all
cases. As you need scripting for editing
On Wed, 24 Aug 2005, Hallvord Reiar Michaelsen Steen wrote:
On 24 Aug 2005 at 0:17, Ian Hickson wrote:
Could we extend contentEditable in a way that would let the UA offer a
non-scripting UI for saving the edited page? For example using the
form attribute from WF2?
What's wrong
Ian Hickson wrote:
It's similar, yes. Where's the ambiguity?
UAs might question which of the two should be dispatched first but other
than that there is a duplication of events. UAs have to support both of
them eventually. (Unless textInput is changed to input when DOM 3 Events
moves to
On Wed, 24 Aug 2005, Anne van Kesteren wrote:
Ian Hickson wrote:
It's similar, yes. Where's the ambiguity?
UAs might question which of the two should be dispatched first but other
than that there is a duplication of events. UAs have to support both of
them eventually. (Unless textInput
On Tue, 23 Aug 2005, Dimitri Glazkov wrote:
On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote:
Yes, but note that the UA is not required to perform any validating or
anything. In practice I doubt we'll ever see useful implementations
(whereas we already have useful, and used, implementations
On 8/24/05, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 23 Aug 2005, Dimitri Glazkov wrote:
Ian, I think the opposite is true, actually. Most of the browser-based
HTML editors that I saw operate by augmenting functionality of a
textarea element, and the accept attribute would work make
The header and footer elements don't allow any sectioning elements,
which includes blockquote. However, headers and footers sometimes
include a short (but not inline) epigraph. How would you mark that
up?
~fantasai
16 matches
Mail list logo
