Merge selectnodetitle into core

(Merging "node system" and "node.module" components for 8.x; disregard.)

Rerolled the patch for this issue.

Re-post of reroll. Previous not patching?

Looks like there is a problem with UTF16 in that patch:

$ cat select-node-title-1446470-6.txt
��diff --git a/core/modules/node/node.js b/core/modules/node/node.js

Checking with file linux tool:

$ file select-node-title-1446470-6.txt
select-node-title-1446470-6.txt: unified diff output, Little-endian UTF-16 Unicode text, with CRLF, CR line terminators
$ file 1446470_2-select-node-title.txt
1446470_2-select-node-title.txt: unified diff output, ASCII text

Latest patch was done with Windows, I don't know what could be wrong in the environment.

Uploaded patch in ANSI encoding.

Format is ok now (look at the filesize and compare with the other patches and the initial one), but it does not apply.

New patch with updated git settings:

git config --global core.autocrlf true
git config --global core.safecrlf true

Patch from linux environment.

I tried this manually and it didn't work. The title input ID in D8 is no longer #edit-title, but rather, #edit-title-0-value. Hard-coding that seems messy. I wonder if the approach instead should be to simply provide focus on the first form input element? That would be more generic, should somebody remove the title field, or re-order the form.

I think that's a good idea. In this patch, the first, enabled, visible input is focused.

I tested this by enabling the search block in the header. The solution in #16 sets focus on the search input instead of the first element in the node form. I think adding the class node-form to the selector will resolve this issue.

I've also added a beta phase evaluation to the summary.

Oh yeah! I was using only the Seven theme for Admin so I did not think to make it specific to .node-form since that was the only form on the page. Updated in this patch.

Patch in #18 works as expected. This is a very practical usability improvement, thanks for working on this!

I don't see any review from @Bojhan, @yoroy, etc. i.e. someone from the usability team. I personally think this makes a lot of sense, but as far as I know, this would be the first time we would be doing something like this in core so I think it makes sense to get a proper sign-off. If there are no reservations I can see this being useful on other pages as well.

Also I don't see any discussions relating to accessibility. For keyboard only users, this is certainly an improvement, but I can't really judge how this will affect blind users. Should there be some announcement (Drupal.announce()) to where the current focus is or does that happen automatically? I think - again, as this will be setting a precedent - we need some accessibility expert's review here.

No usability concerns. Its mainly an accessibility question I think.

1. On a slow connection it is theoretically possible a user starts typing in a field, the js file is loaded and the focus unexpectedly jumps to the title field.
2. Why make this specific for node and not any entity? (node, taxonomy, user, etc.)
3. Could the same feature be implemented with html5 <input autofocus />? This would also resolve #1. For an example, see http://www.w3schools.com/tags/att_input_autofocus.asp

Yes, that sounds preferable IMO.

http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/
This article suggests also adding an aria-describedby for accessibility purposes, which seems sensible to me, but I've never used a screen reader, so it would still need verification from someone on the accessibility team that this is something that people using screen readers can work with.

Hey look what I found :-)

Oops

Synopsis of the related issue:

Long story short, from a screen reader user point of view let's close this issue as won't fix...

Closing this as "Won't fix" in line with the arguing in the related issue.