[whatwg] [editing] Additional miscellaneous commands

[Aryeh Gregor]

Thanks again for your feedback.

2011/8/16 Alfonso Martínez de Lizarrondo <amla70 at gmail.com>:
> Ups, sorry, I thought that the Comments buttons would open a feedback form
> but anyway I haven't read all the spec and I just used Ctrl+F to check for
> some of those commands and I didn't find anything.

Ah, I can see how that would be confusing.  I renamed "Comments" to
"View comments":

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=60e4f1e6

Is that clearer?  You probably won't find it with Ctrl-F, because it's
hidden by default, but Ctrl-F on the HTML source should work.

> From the list that I've mentioned previously:
> Inline table editing is available only in Mozilla, it's nice in order to add
> or remove rows.

Bug filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13806.  I
expect this would be pretty complicated relative to the benefit, so I
don't think I'll get to it soon, but it's definitely a feature for a
future version.

> Autodetection of URLs is a feature of IE and since IE9 it's possible to
> disable it. Many people expect that when they type an URL it gets converted
> automatically into a link.

Bug filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13807.  I
might get to this relatively soon, since it's a fairly visible feature
that users are likely to expect.

> Of course there are other people that don't want
> it. I've written previously in other sites that the best way to handle it
> would be to get an event with the new created link, that way the editor
> could alter some properties (like setting a @rel or @target) if needed.

This is a general issue with commands.  I've seen authors forced to
work around this with insertImage too: they insert an image with a URL
like "##insertedimage##", then do something like
document.querySelector("##insertedimage##") to find it, then set the
URL to the one they actually want and set classes and things.  It
might indeed make sense to have special events for various kinds of
autocreated or command-created elements.

> The Respect visibility features is aimed at being able to have something
> with display:none and the user can edit it, if it's hidden then the editor
> has to provide some other way so that the user can edit that content that
> might be displayed later with javascript.

That's one CSS rule, no?

> At the very least, providing a list of all the known commands of all the
> browsers can help to use those little hidden secrets. And of course a big
> warning on those that shouldn't be used anymore like it's done with the
> useCss. In those cases it might be enough to provide a list of commands that
> aren't really useful and so the implementors can move to try to remove them
> as you suggested.

I might add a list at some point of commands that are deliberately not
specified, for which implementers should drop support.

> There are many things that are possible with javascript and stylesheets, but
> I think that the goal was to make things simpler.
> For example your algorithm is implemented in Javascript and AFAIK, both
> CKEditor and TinyMCE don't use .execCommand to apply styling while editing,
> they also use their own javascript routines. So applying the same statement
> there's no need that the browsers change their implementation because it can
> be done with javascript.

Absolutely, the goal is to make things simpler for authors.  However,
if something is already very simple to do with CSS and JavaScript, we
don't need to add an extra way to do it.  All the commands that are
currently specified are *incredibly* difficult to do well -- I've
spent hundreds of hours over the course of months specifying them, and
there are still major deficiencies in a lot of them.  But if you can
make display: none things display with one CSS rule, so that's not
something we need an extra way to control.

> Yes, that sounds fine; we just have to be sure that everyone agrees that
> such CSS property also applies while editing a document (and maybe say that
> by default it should be enabled for both images and tables in editable
> elements)
> Also, maybe the behavior of the browser should be slightly different while
> editing. I think that the resize property might have been thought for
> textareas so the user can adjust the size (and ignore designers that don't
> use the pages that they create) and so they aren't really worried about the
> exact size, but while editing a content it's nice to see the resized
> dimensions like done in Firefox. And of course, resizing a picture by the
> corner should respect the width/height ratio, not like IE does.

Thanks, I updated the bug with this further info.

> Related to CSS, one feature that people request and that from my POV should
> be done with CSS is the ability to see the "formating blocks", that's easy
> to do with most of the elements by using a little background image in the
> stylesheet and some border, but Opera used to be the only one able to format
> <br>, and that's what people are requesting, to see a glyph where a line
> ends like they can do in MS-Word. But I'm not sure that this relates to the
> Editing APIs doc.

It sounds like more of a CSS thing.  It would only really be useful
for editable content, but there's no reason it should be restricted to
that.  I could imagine a property like display-whitespace or such.
Bug filed, although this is definitely a long-term feature given the
complexity relative to benefit:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13808