On 8/31/05, Jasper Bryant-Greene [EMAIL PROTECTED] wrote:
Aside: Now that I looked at the source of the literature list, I noticed
that some titles of works were marked up as em. my hypothesis is that
after an upgrade Dreamweaver has started using em when pressing
command-i. Sigh. See
Aankhen wrote:
On 8/31/05, Jasper Bryant-Greene [EMAIL PROTECTED] wrote:
Aside: Now that I looked at the source of the literature list, I noticed
that some titles of works were marked up as em. my hypothesis is that
after an upgrade Dreamweaver has started using em when pressing
command-i.
[sorry Jasper, accidentally sent it to your account alone]
On 8/31/05, Jasper Bryant-Greene [EMAIL PROTECTED] wrote:
Did you actually read the mpt.net.nz article that my article refers to?
Yes. Quite a few times. I also read the portion of the previous
message that you quoted that talks about
On 8/30/05, Matthew Raymond [EMAIL PROTECTED] wrote:
You're talking about defining behavior for a semantic element. You're
essentially dictating parts of the implementation of |contenteditable|
to user agent vendors.
Not at all, I'm saying the current implementation in IE is appropriate
for
Jim Ley wrote:
On 8/30/05, Matthew Raymond [EMAIL PROTECTED] wrote:
Oh, I think I get it. You don't necessarily want there to be toolbars
and the like,
No, I want contentEditable left as is, because not all the use cases
and delivered products of contentEditable are applicable to full
On Aug 28, 2005, at 11:02, Lachlan Hunt wrote:
Although some editors do also provide some semantic options, they're
usually limited in their abilities. Some have some semantic block
level elements like headings, paragraphs, lists and maybe blockquote.
However, few have semantic elements like
Henri Sivonen wrote:
Could the user interface difficulties with this semantic inline elements
stem at least partly from problems with the semantic inline elements
themselves?
Consider cite for example. What's it really good for? Why should an
author bother to use cite instead of i? Once you
Matthew Raymond wrote:
Ian Hickson wrote:
On Fri, 26 Aug 2005, Matthew Raymond wrote:
So, effectively, what you're saying about textarea accept=text/html
is the following:
1) The HTML in a textarea is unstyled (at least unstyled by the parent
document) unless styles or stylesheets are
[ Re-arranging reply to start with the fundamental scripting
dependency topic. If you insist that I'm beating some dead animal
now I promise to shut up :) ]
On 24 Aug 2005 at 12:16, Ian Hickson wrote:
contentEditable needs scripting anyway, to offer things like insert em
element here, etc.
Ian Hickson wrote:
On Wed, 24 Aug 2005, Lachlan Hunt wrote:
contentEditiable is not semantic, it's behavioural and belongs in the DOM
interface only, not the markup.
How is it not semantic?
How is it semantic?
It's not behavioural...
It's behavioual because it specifies how content
On 8/29/05, Hallvord Reiar Michaelsen Steen [EMAIL PROTECTED] wrote:
On 24 Aug 2005 at 12:16, Ian Hickson wrote:
contentEditable needs scripting anyway, to offer things like insert em
element here, etc.
Why must contentEditable depend on scripting? What if we make sure
the wording of
Note: The quoted text has been rearranged for clarity.
Ian Hickson wrote:
The answers to your questions are [...]
On Wed, 24 Aug 2005, Matthew Raymond wrote:
For example, are the HTML contents loaded into the DOM?
[...]only as text nodes[...]
Are they treated like a separate document in
Matthew Raymond wrote:
The simple fact of the matter is that, with the version of HTML5 you
currently propose, there is no way to submit HTML in the DOM without
scripting.
Considering you need scripting for applications anyway, that is no
problem. Note that the WHATWG is not about inventing
On Fri, 26 Aug 2005, Matthew Raymond wrote:
So, effectively, what you're saying about textarea accept=text/html
is the following:
1) The HTML in a textarea is unstyled (at least unstyled by the parent
document) unless styles or stylesheets are specified within the
textarea contents.
On Wed, 24 Aug 2005, Matthew Raymond wrote:
Well, we already have textarea accept. It's up to you guys to
convince UA makers to implement it. :-)
I think there are still issues to address with regards to textarea
accept. For example, are the HTML contents loaded into the DOM? Are
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
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
I've been following this thread for a little while. I too think that
the contentEditable is not done quite right.
My biggest problem with it (and this was pointed out before) is that
it is a half-way effort: there is markup that enables the editing, but
there is no markup that provides any
On Fri, 5 Aug 2005, dolphinling wrote:
Perhaps I've missed something, but while I've seen lots on what
contentEditable does and how it works and how various other things are
associated with it, I've never actually seen anything explaining *why*
it exists. So... what's it good for?
Rich
On Mon, 15 Aug 2005, Lachlan Hunt wrote:
How is [contentEditable] any different from a text area form control
with a specified accept type of text/html, which would allow a UA to
load any external editor (eg. XStandard) or degrade to a regular text
area?
contentEditable is implemented.
On Tue, 23 Aug 2005, Hallvord Reiar Michaelsen Steen 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 ?
--
Ian Hickson
On Tue, 23 Aug 2005, Dimitri Glazkov wrote:
I was surprised to learn that WF2 spec does not support rich textarea. I
still can't figure out why.
Time. It's on the list for WA1/WF3 (although currently contentEditable is
the way I intend to address the need).
Again, IMHO, the
On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 23 Aug 2005, Hallvord Reiar Michaelsen Steen 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
On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote:
Actually, originally, HTML was supposed to be user editable always. Much
like in Amaya. So contentEditable is more of a compromise between the
original intent of the Web and the don't let them modify it! attitude
that has grown since.
I
On Tue, 23 Aug 2005, Dimitri Glazkov wrote:
As you know, there is already a scheme for communicating server's
expectations on input -- forms.
I can't see how contentEditable fits in this scheme.
It doesn't. If you want contentEditable to be submitted, you need to use
a line of script.
On Tue, 23 Aug 2005, Dimitri Glazkov wrote:
On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 23 Aug 2005, Hallvord Reiar Michaelsen Steen 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
Ian Hickson wrote:
On Mon, 15 Aug 2005, Lachlan Hunt wrote:
How is [contentEditable] any different from a text area form control
with a specified accept type of text/html, which would allow a UA to
load any external editor (eg. XStandard) or degrade to a regular text
area?
contentEditable
Lachlan Hunt wrote:
I'm not disputing the fact that there is an unfortunate demand for
embedded WYSIWYG editing in web based CMSs, it is the conceputally
broken implementation I'm against.
I don't consider this demand unfortunate. I consider it an essential
part of the vision for the web. The
Olav Junker Kjær wrote:
Lachlan Hunt wrote:
I'm not disputing the fact that there is an unfortunate demand for
embedded WYSIWYG editing in web based CMSs, it is the conceputally
broken implementation I'm against.
I don't consider this demand unfortunate. I consider it an essential
part of
Olav Junker Kjær wrote:
Lachlan Hunt wrote:
How is that any different from a text area form control with a
specified accept type of text/html, which would allow a UA to load any
external editor (eg. XStandard) or degrade to a regular text area?
The point of contentEditable is that some areas
Anne van Kesteren wrote:
Quoting dolphinling [EMAIL PROTECTED]:
Perhaps I've missed something, but while I've seen lots on what
contentEditable does and how it works and how various other things are
associated with it, I've never actually seen anything explaining *why*
it exists. So... what's
Quoting Lachlan Hunt [EMAIL PROTECTED]:
Could you be more specific? It basically enables WYSIWYG editing for
web pages.
(With the freedom that you can restrict certain elements from being
edited, et
cetera.)
How is that any different from a text area form control with a
specified accept
Lachlan Hunt wrote:
How is that any different from a text area form control with a specified
accept type of text/html, which would allow a UA to load any external
editor (eg. XStandard) or degrade to a regular text area?
The point of contentEditable is that some areas of a page can be made
41 matches
Mail list logo
