[whatwg] [editing] Additional miscellaneous commands

Thu Aug 18 14:05:07 PDT 2011

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

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

Yes, now it's clearer what's the meaning of the button.
Now if someone had some bright idea to enable finding in the hidden text
that would be perfect, but the view source workaround is good enough for the
moment.

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

Showing all whitespace would be the most complete solution, but if the rest
of browsers could behave like Opera and handle this, that would be enough
for most of the people:

br:before {content: "\B6";}

That's just CSS and I'm not sure if it should be present in this spec, but
on the other side it's clear that besides the .execCommand a good Editing
spec should state or hint about other features that the browsers must
implement to behave properly (like showing the caret so the user knows where
he's typing,  enable the user to select parts of the content,...). These
might look trivial, but iOS5 seems to be the first mobile browser that will
behave good enough so that both CKEditor and TinyMCE will enable the support
for it (check the comments in
http://code.google.com/p/android/issues/detail?id=8253 about the Android
browser)
A browser that provides a perfect implementation of all the execCommands but
doesn't allow the user to type or select is worthless for editing.