chromium-status: add status field help text

chromium-status: add status field help text

The way the status field gets parsed for keywords is a bit of esoteric
knowledge -- you slowly figure it out over time based on seeing what
other people are doing.

Let's fix that by adding tooltip text that is shown whenever you mouse
over the status input field.  Here we explain in clear detail how the
parsing happens.

BUG=chromium:314501
TEST=ran an appengine instance and checked the status behavior
TEST=`./tests/main_test.py` passes

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=239247

[vapier, 2013-11-04 22:44:25]

you can see an example of how this looks here:
http://www/~vapier/chromium-status-example.png

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

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js
File static/js/main/main.js (right):

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js#newcode20
static/js/main/main.js:20: // We do not mark these vars as local so we can use
them later on.
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.

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js#newcode29
static/js/main/main.js:29: help.onmouseout = help_hide;
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?

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js#newcode35
static/js/main/main.js:35: help.style.display = 'inline-block';
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-...

Here this should be: help.hidden = false;

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js#newcode39
static/js/main/main.js:39: help.style.display = 'none';
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-...

Here this should be: help.hidden = true;

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js#newcode47
static/js/main/main.js:47: function auto_submit(e) {
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.)

https://codereview.chromium.org/58593002/diff/1/templates/main.html
File templates/main.html (right):

https://codereview.chromium.org/58593002/diff/1/templates/main.html#newcode18
templates/main.html:18: &nbsp;(4) Otherwise, the tree is <span
class="open">open</span> for business
The rest of this file is well-indented, let's keep this indented, too.  +4
indent on lines 9-18, and rebalance for <80 chars per line.

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

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js
File static/js/main/main.js (right):

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js#newcode20
static/js/main/main.js:20: // We do not mark these vars as local so we can use
them later on.
Done.

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js#newcode29
static/js/main/main.js:29: help.onmouseout = help_hide;
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.

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js#newcode35
static/js/main/main.js:35: help.style.display = 'inline-block';
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.

https://codereview.chromium.org/58593002/diff/1/static/js/main/main.js#newcode47
static/js/main/main.js:47: function auto_submit(e) {
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.

https://codereview.chromium.org/58593002/diff/1/templates/main.html
File templates/main.html (right):

https://codereview.chromium.org/58593002/diff/1/templates/main.html#newcode18
templates/main.html:18: &nbsp;(4) Otherwise, the tree is <span
class="open">open</span> for business
done (although the rest of the file doesn't follow the 80 col rule)

[vapier, 2013-11-10 21:18:19]

the new patchset should address all the feedback sans the open issue wrt the
enter key

[vapier, 2013-12-05 20:43:03]

i've split off the <input> change into a sep CL.  it was the only piece cmp had
concerns with, so the rest of the code should hopefully be an easy lgtm now ;).

[szager1, 2013-12-05 20:47:48]

lgtm with nit.

https://codereview.chromium.org/58593002/diff/70001/templates/main.html
File templates/main.html (right):

https://codereview.chromium.org/58593002/diff/70001/templates/main.html#newco...
templates/main.html:10: The message is scanned for partial matches (in the order
listed)<br>
"partial matches" sounds weird.  How about "keywords"?

[vapier, 2013-12-05 21:02:45]

https://codereview.chromium.org/58593002/diff/70001/templates/main.html
File templates/main.html (right):

https://codereview.chromium.org/58593002/diff/70001/templates/main.html#newco...
templates/main.html:10: The message is scanned for partial matches (in the order
listed)<br>
"keywords" to me indicates word boundaries, and that's not what the code does.

e.g. if "maint" appears anywhere in the string whilst the tree is closed, then
the tree is in maintenance mode.  so if you say something like "Tree is closed
(skia is broken; maintainer is looking into it -> crbug.com/1234)", the status
will be "maintenance" and not "closed".

e.g. if the status is "Tree is open (the problem has been disclosed)", the
status will be "closed".

[szager1, 2013-12-05 22:04:34]

On 2013/12/05 21:02:45, vapier wrote:
> https://codereview.chromium.org/58593002/diff/70001/templates/main.html
> File templates/main.html (right):
> 
>
https://codereview.chromium.org/58593002/diff/70001/templates/main.html#newco...
> templates/main.html:10: The message is scanned for partial matches (in the
order
> listed)<br>
> "keywords" to me indicates word boundaries, and that's not what the code does.
> 
> e.g. if "maint" appears anywhere in the string whilst the tree is closed, then
> the tree is in maintenance mode.  so if you say something like "Tree is closed
> (skia is broken; maintainer is looking into it -> crbug.com/1234)", the status
> will be "maintenance" and not "closed".
> 
> e.g. if the status is "Tree is open (the problem has been disclosed)", the
> status will be "closed".

"partial matches" still sounds obscure to me, but I don't want to bikeshed on
it.

[vapier, 2013-12-05 23:00:32]

i'm happy to change the wording to something better, but i don't think
"keywords" is better than "partial matches".  as a programmer, i thought
"partial match" would be a concept that other programmers would recognize, but
perhaps it's not as common as i think it is.

when i search for "keywords", all the results seem to match my concept --
they're whole words.

how about "partial strings" or "substrings" ?

[commit-bot: I haz the power, 2013-12-06 18:58:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vapier@chromium.org/58593002/150001

[commit-bot: I haz the power, 2013-12-06 18:59:05]

Change committed as 239247