[whatwg] [editing] Additional miscellaneous commands

2011/8/16 Aryeh Gregor <ayg at aryeh.name>

> 2011/8/16 Alfonso Mart?nez de Lizarrondo <amla70 at gmail.com>:
> > Hi
> >
> > The drafted specs defines most of the common features of contentEditable,
> > but there are other commands that have been left out
> >
> > enableInlineTableEditing
> > enableObjectResizing
> > AutoUrlDetect
> > RespectVisibilityInDesign
> > ...
>
> I have some of these noted in the "Comments" drop-down at the bottom here:
>
> http://aryeh.name/spec/editing/editing.html#issues
>

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.


> I've looked at MSDN documentation and compiled a list of supported
> commands, but I seem to be missing some.  Do you know of a more
> comprehensive list?  Also, it would help a lot if you (or anyone else)
> could point out which specific commands sound especially useful.
>
>
As I said, there are a bunch of commands for IE, but many of them aren't
really related to editing (like SaveAs), few people knows how to use them,
or just don't work (some lists of commands refer to the MSHTML component
that seemed more focused on developing FrontPage).

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

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

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.

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.


> IE used to had a bunch of poorly documented commands, but the important
> part
> > for me is that those extra commands might enable some behaviors that are
> too
> > hard to emulate by javascript, and if they can be added to the spec, then
> > hopefully they will be available in the future for all the users.
>
> I agree with this general point, but it's really best to have specific
> examples to work with.  It's almost surely not worth it to
> reverse-engineer all the IE commands here.  For instance,
> RespectVisibilityInDesign is something we can do without -- visibility
> should always be respected, so that what the user sees is what they
> get when they save.  If authors want to let users edit particular
> invisible things, they can make them visible using a stylesheet rule.
>

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.


>
> > One basic example is resizing. Currently Webkit browsers doesn't allow
> the
> > user to resize a picture, table,.. that it's placed in the contents. Some
> > people might not want that behavior at all, others might prefer to enable
> it
> > only for tables but not images, and I think that instead of putting that
> > burden on the javascript editor, it should be the browser the one that
> takes
> > care of that with a basic command to turn it on/off and then firing the
> > needed events when something like a resize starts or ends like IE does.
>
> Might the CSS resize property be the best way to do this?
>
> http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resize
>
> Then authors could do img { resize: both } or similar.  This is much
> more flexible than a global on-off switch, because you could allow the
> user to resize some things but not others.  For instance, a forum that
> allows users to insert custom images and also smilies might want them
> to be able to resize the custom images but not the smilies, and it
> could do that with an appropriate CSS selector.  I'd have to update
> the spec to say that if the user resizes editable things, the browser
> needs to actually change the DOM to add height/width attributes or
> properties.
>
> I filed a bug on this:
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=13795>.  Please feel
> free to file bugs for any other specific features you'd like me to
> look into.  Note that right now I'm mostly focused on fixing up and
> stabilizing core functionality, so I might not get around to adding
> new features for a while.
>

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.

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.

Regards

Received on Tuesday, 16 August 2011 10:26:14 UTC