chromium-status: add status field help text

static/js/main/main.js

+// Copyright (c) 2013 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+/*
+ * Code for the main user-visible status page.
+ */
+
+window.onload = function() {
+  document.add_new_message.message.focus();
+  help_init();
+}
+
+/*
+ * Functions for managing the help text.
+ */
+
+function help_init() {
+  // Set up the help text logic.
+  // We do not mark these vars as local so we can use them later on.

[cmp, 2013/11/10 16:31:06]

That is an unnecessary optimization.  We should mark them as local here and
everywhere else, and just get their elementById later in each function call.

[vapier, 2013/11/10 20:49:05]

Done.

+  message = document.getElementsByName('message')[0];
+  message.onmouseover = help_show;
+  message.onmousemove = help_show;
+  message.onmouseout = help_hide;
+  message.onkeypress = auto_submit;
+
+  help = document.getElementById('help');
+  help.onmouseover = help_show;
+  help.onmouseout = help_hide;

[cmp, 2013/11/10 16:31:06]

Consistency: if we call help_show onmousemove for message, is there a reason not
to call it on help, too?  I think it may be best to call it on help.  WDYT?

[vapier, 2013/11/10 20:49:05]

i set it on message because the message text box can get resized, and so the
positioning needs updating.  there isn't really such an issue inside of the help
text ... the cursor is inside of it, so the help text isn't going anywhere.

i could add the event, but the only effect it'd have is to be constantly running
javascript that doesn't do anything useful.

+}
+
+function help_show() {
+  help.style.left = message.offsetLeft + 'px';
+  help.style.top = message.offsetTop + message.offsetHeight + 'px';
+  help.style.display = 'inline-block';

[cmp, 2013/11/10 16:31:06]

http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-...

Here this should be: help.hidden = false;

[vapier, 2013/11/10 20:49:05]

you can't use .hidden and .style.display at the same time.  in a previous
version, i was experimenting with different elements for the help text, and i
needed .display to be 'inline-block'.  so once you've set that, the .hidden
attribute is completely ignored.

so you can't have a css element doing:
  style: inline-block;
and then have the javascript toggle the .hidden.  the element stays displayed
the whole time.

that said, the latest revision using a <div> seems to render correctly w/out
inline-block, so i can switch to .hidden.

+}
+
+function help_hide() {
+  help.style.display = 'none';

[cmp, 2013/11/10 16:31:06]

http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-...

Here this should be: help.hidden = true;

+}
+
+/*
+ * Misc functions.
+ */
+
+// Used by the status field.
+function auto_submit(e) {

[cmp, 2013/11/10 16:31:06]

I think it's better to stick to the current behavior here of relying on 'tab' +
'enter' to trigger submitting the form, so no auto_submit() hook needed.  We're
not losing anything by not catching an enter keypress in this status input box,
and it would be surprising to people who expect the textarea to act like a
textarea.  (In a textarea, enter keypress does not auto-submit forms by default
in user agents.)

[vapier, 2013/11/10 20:49:05]

the current behavior allows you to simply hit enter to submit because it's an
<input> element.  by changing it to a <textarea>, i've broken that behavior, and
i restore it by this javascript.

since newlines aren't allowed in the message, it doesn't seem like a big deal.

+  if (!e.shiftKey && e.keyCode == 13) {
+    // Catch the enter key in the textarea.  Allow shift+enter to work
+    // so people editing a lot of text can play around with things.
+    var form = document.getElementsByName('add_new_message')[0]
+    form.submit();
+    return false;
+  }
+  return true;
+}