This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13429 - Section 7.5 contenteditable and designMode must make navigation consistent platform conventions
Summary: Section 7.5 contenteditable and designMode must make navigation consistent pl...
Status: CLOSED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Rich Schwerdtfeger
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf
Depends on:
Blocks:
 
Reported: 2011-07-28 19:59 UTC by Rich Schwerdtfeger
Modified: 2013-01-09 14:48 UTC (History)
13 users (show)

See Also:


Attachments

Description Rich Schwerdtfeger 2011-07-28 19:59:04 UTC
Section 7.5 The section must mandate and specify that navigation be consistent with platform conventions. This must be applicable to contenteditable and designmode. For example, browsers running on Windows must follow that platform's conventions for navigation. A Mac has different platform navigation conventions from Windows. So, the Windows and Mac implementation would not need to match. 

Specifically, On Windows, a serious problem we see between different browsers is how each one implements navigation and default editing (e.g. delete, backspace etc.) differently. This has resulted in CKEditor (an open source web editor) implementing special keyboard handling and strange DOM manipulations in order to try and get the experience the same (or close to) between browsers. Here's a common example: in IE, if the caret is at the end of a link and the user hits a backspace, IE deletes the link but leaves the caret in the same position with the text of the link unchanged. In FF, the backspace will delete the last character in the link, preserving the link element.

This problem impacts people with disabilities, mainstream keyboard users, developers that use editing hosts in the web applications.
Comment 1 Aryeh Gregor 2011-07-28 21:02:34 UTC
This is all defined in detail in the HTML editing spec.  The "additional requirements" section specifies the behavior for Enter, Shift-Enter (or platform equivalent), Backspace, Delete, and typing text:

http://aryeh.name/spec/editing/editing.html#additional-requirements

The detailed requirements for backspace are here:

http://aryeh.name/spec/editing/editing.html#the-delete-command

Previously, they followed all non-IE browsers in that backspacing after a link doesn't unlink it.  On consideration, though, the IE behavior is more useful, and also matches Word 2007, so I changed the spec to match it:

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

Thanks for the feedback.  My current understanding is this will stay a separate spec and not be incorporated into HTML5, per bug 13423 and bug 13425, but I'll wait for Hixie to confirm that before I resolve this.
Comment 2 Aryeh Gregor 2011-07-28 22:16:00 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: no spec change
Rationale: I just spoke with Hixie, and I think it's clear that we aren't going to merge this detailed editing stuff into the HTML spec within the W3C's HTML5 timeframe, if ever.  It will remain in a separate spec for the time being.  Thus as a bug filed against HTML5, it's WONTFIX, but the substance of your suggestions is already covered in the editing spec, and I'd appreciate any specific feedback you had about it.
Comment 3 Michael[tm] Smith 2011-08-04 05:16:27 UTC
mass-move component to LC1
Comment 4 Rich Schwerdtfeger 2011-08-09 20:03:12 UTC
I thought this was the editing spec. Where is the "editing spec.?" Is this in web apps? Got a link?
Comment 5 Benjamin Hawkes-Lewis 2011-08-09 20:30:41 UTC
(In reply to comment #4)
> I thought this was the editing spec.

The intention is to replace the Editing APIs section of W3C HTML5 wholesale with a new, separate spec.

> Where is the "editing spec.?" Is this in web apps? Got a link?

Currently it's being edited by Aryeh at his own site:

http://aryeh.name/spec/editing/editing.html

This is the spec Aryeh's links point to in comment #2.

Vendor feedback on the draft can be read over on the WHATWG list (perhaps most easily accessed via the Mail Archive):

http://www.mail-archive.com/whatwg@lists.whatwg.org/msg27615.html

It's worth reading the whole thread.

Michael Smith has created a component in the W3C bugtracker under the webapps:

Here's the link to file a bug:

http://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG&component=HTML+Editing+APIs
Comment 6 Rich Schwerdtfeger 2011-08-09 20:45:05 UTC
Thank you Benjamin. You understand that nobody in W3C really would know to look at a private document by Areyeh. 

Is there a defect written on the editing section stating that it will be moved to this separate document? This is a rather big change that should also be logged as a defect against HTML LC1.

When does Areyeh plan to submit it to web apps soon? I would prefer that it were in W3C space for review.

Separating this out into a separate document is a good idea. I applaud Areyeh for doing it.
Comment 7 Aryeh Gregor 2011-08-10 01:29:06 UTC
Bug 13423 and bug 13425 request that the relevant sections be removed from HTML5.  My spec isn't being worked on at the W3C and I don't currently intend to submit it to any W3C working group, but you can file bugs on it in W3C's Bugzilla under WebApps WG -> HTML Editing APIs.
Comment 8 Rich Schwerdtfeger 2011-08-10 16:44:59 UTC
Areyeh, since you don't intent to submit your document to the W3C and I see no plans for a W3C document designed to address consistent keyboard behavior why should we agree to not have any text on this in the HTML 5 spec.?  

This is a very big gap given that the defect was written against a W3C specification. In other words, I see no W3C road map for what we need other than the HTML 5 spec.
Comment 9 Aryeh Gregor 2011-08-10 17:07:21 UTC
The specification I'm working on is in the public domain.  If you or anyone else would like to submit it to the W3C, or write a delta spec at the W3C, or whatever, you can feel free.  However, my understanding after speaking with Hixie is that he is not personally interested in maintaining a specification at the W3C for functionality that is already adequately specified outside the W3C, whether or not the outside specification is published at any formal standards body.

If you object to the closure of this bug, you can escalate it to an issue, as outlined in comment 2.  In that case you would have to find someone else to write the specification text you want for the W3C, given that Hixie and I are not interested (although you can copy my text if you want, since it's public domain).

Alternatively, if you would like to reopen this bug and try to get a response from Hixie instead of me, I won't object, since I could be perceived as biased.  However, then you wouldn't be able to escalate until he got around to responding, which might take a while.

I hope that clears things up.
Comment 10 Rich Schwerdtfeger 2011-08-10 17:48:50 UTC
Areyeh, this clears things up for me ... including a clearer perspective on Google's web strategy moving forward. thank you.
Comment 11 Aryeh Gregor 2011-08-10 19:23:05 UTC
No one at Google has given me any instructions on what to do other than "write an execCommand() spec".  My decisions on how to write it and where to host it have been entirely my own, and I'd make the same ones if I were employed by Mozilla or anyone else -- assuming my employer left it up to me as Google did.  I explained my rationale at some length here: https://plus.google.com/u/0/105458233028934590147/posts/h7nsT7wuNmX  But this is off-topic for Bugzilla.
Comment 12 Rich Schwerdtfeger 2011-08-11 15:36:52 UTC
Aryeh, I cannot consider an arbitrary specification outside the W3C process for legal reasons. I see this spec. also has a Google copyright.

I see Google has allowed you to use their name in the copyright of the editing API specification.
Comment 13 Aryeh Gregor 2011-08-11 19:15:55 UTC
(In reply to comment #12)
> Aryeh, I cannot consider an arbitrary specification outside the W3C process for
> legal reasons.

I regret to hear that.  You are, again, free to submit the spec to the W3C yourself or find someone else who is willing to.  It would be much less work than trying to write your own spec of comparable quality.

> I see this spec. also has a Google copyright.
> 
> I see Google has allowed you to use their name in the copyright of the editing
> API specification.

I was instructed that Google holds the copyright to any work I do for them, and Hixie also advised me at some point to release the work into the public domain (CC0).  I was not specifically requested or permitted to use Google's name in any particular fashion.  I've removed the copyright notice to avoid confusion.  Regardless, I wrote the spec myself and no one at Google has anything to do with it except for funding it, so please don't try to read any motives on Google's part into my actions.
Comment 14 Rich Schwerdtfeger 2011-08-11 19:43:29 UTC
That is an improvement, however the solution cannot be a non-W3C specification. 

My argument is not with breaking out detailed editing into a separate document nor with the contents of your specification which I have not reviewed.

If such a specification were to address this in another W3C rec-tracked specification, tied to HTML, I believe the HTML accessibility task force would accept that as being resolved for the HTML specification and focus a review on the other document. Unfortunately, no such W3C specification exists.

Consequently, and regrettably, I have to change the status to reopened.
Comment 15 Shelley Powers 2011-08-11 19:56:48 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > Aryeh, I cannot consider an arbitrary specification outside the W3C process for
> > legal reasons.
> 
> I regret to hear that.  You are, again, free to submit the spec to the W3C
> yourself or find someone else who is willing to.  It would be much less work
> than trying to write your own spec of comparable quality.
> 
> > I see this spec. also has a Google copyright.
> > 
> > I see Google has allowed you to use their name in the copyright of the editing
> > API specification.
> 
> I was instructed that Google holds the copyright to any work I do for them, and
> Hixie also advised me at some point to release the work into the public domain
> (CC0).  I was not specifically requested or permitted to use Google's name in
> any particular fashion.  I've removed the copyright notice to avoid confusion. 
> Regardless, I wrote the spec myself and no one at Google has anything to do
> with it except for funding it, so please don't try to read any motives on
> Google's part into my actions.

You just said that Google holds the copyright on the work you do. Does it also hold patent rights? Most companies reserve patent rights for any employee work. I assume Google is no different. 

I would assume that someone at Google, especially in the Google legal department would be interested in what's happening here. Point of fact, I strongly recommend that you and Ian may want to have a chat with Google's legal department.

And Google also entered into a legal relationship with the W3C when it joined with the W3C and agreed to participate in developing specifications. Your actions contradict this agreement.
Comment 16 Aryeh Gregor 2011-08-11 20:18:25 UTC
I am not going to continue to use this bug to discuss my editing specification.  Anyone who wants to discuss it with me can e-mail me personally and optionally CC www-archive, or e-mail whatwg if it's a technical issue.  I am definitely not qualified to comment on legal issues, and I recommend that anyone who has a legal question or complaint should consult a qualified lawyer.
Comment 17 Shelley Powers 2011-08-11 20:32:33 UTC
(In reply to comment #16)
> I am not going to continue to use this bug to discuss my editing specification.
>  Anyone who wants to discuss it with me can e-mail me personally and optionally
> CC www-archive, or e-mail whatwg if it's a technical issue.  I am definitely
> not qualified to comment on legal issues, and I recommend that anyone who has a
> legal question or complaint should consult a qualified lawyer.

Google entered into an agreement when it joined the W3C. I assume it applies to you if you're employed by Google. 

http://www.w3.org/2005/03/Member-Agreement

True, you can take a copy of the work and do what you want--though I would assume that people who commit to a team would continue that team rather than participate one day, yank work the next, and so on--but if I read this agreement correctly, you can't _remove_ this work from the W3C. Once this work was done as part of the Consortium efforts, it became jointly owned by the group members and the Consortium.

I'm not a lawyer, but I do know teamwork when I see it. And when I don't.
Comment 18 Sam Ruby 2011-08-14 23:54:44 UTC
This bug is in an inconsistent state: REOPENED and TrackerRequest.  As it was reopened prior to an issue being raised, I'm removing TrackerRequest for the moment.  When this bug is re-RESOLVED, the option to add TrackerRequest will again be available.
Comment 19 Ian 'Hixie' Hickson 2011-12-02 00:53:14 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: no new technical information since comment 2. Aryeh's spec is now in a CG at W3C so the non-technical issues seem resolved as well.
Comment 20 Michael Cooper 2013-01-09 14:48:24 UTC
Issue in this bug has been taken up by the HTML Editing APIs community group http://www.w3.org/community/editing/.