Add demo_page.html to cr_elements/v0_8

Add demo_page.html to cr_elements/v0_8

This CL should facilitate conversion of cr- elements and help debugging
them in isolation.

To view elements in demo_elements.html, navigate to:
chrome://resources/cr_elements/v0_8/demo_page.html

BUG=485381
Committed: https://crrev.com/8d81ad5028eb4d90348d7c576c28754555d06a76
Cr-Commit-Position: refs/heads/master@{#330297}

[stevenjb, 2015-05-15 02:07:33]

stevenjb@chromium.org changed reviewers:
+ jlklein@chromium.org, michaelpg@chromium.org

[stevenjb, 2015-05-15 02:07:34]

How about this as a compromise / alternative to
https://codereview.chromium.org/1138153002/.

The demo page will be less discoverable, but will still allow us to quickly test
new elements without needing to modify the .grd file, run gyp_chromium, and
remember to remove the demo file from the .grd before commit.

Note: The {{}} properties are still not behaving correctly and I don't know why.

[michaelpg, 2015-05-15 02:45:29]

looks like the cr-elements need "notify: true" in their properties, otherwise
they don't fire change events so there's nothing to bind to. but, AFAICT this
code should work when cr-elements are fixed so LGTM.

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
File ui/webui/resources/cr_elements/v0_8/demo_element.js (right):

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
ui/webui/resources/cr_elements/v0_8/demo_element.js:32:
console.log('checkboxCheckedChanged=' + this.checkboxChecked);
for observer methods set in the properties block, the new value is passed in as
the first argument. it's probably correct-er to just use that instead of getting
the property from |this|, since they should be equal.

[stevenjb, 2015-05-15 03:01:42]

So, I have the same problems with paper-elements and data binding as I am with
cr-elements, so something somewhere has changed that breaks the way
cr-demo-element is doing data binding from .5 to .8.

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
File ui/webui/resources/cr_elements/v0_8/demo_element.js (right):

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
ui/webui/resources/cr_elements/v0_8/demo_element.js:32:
console.log('checkboxCheckedChanged=' + this.checkboxChecked);
On 2015/05/15 02:45:29, michaelpg wrote:
> for observer methods set in the properties block, the new value is passed in
as
> the first argument. it's probably correct-er to just use that instead of
getting
> the property from |this|, since they should be equal.

Given that they should be equal, why would that be more correct-er? This way I
think it is clear that this.foo is set to the new property value. (This is more
relevant in places where the changed method is more complicated, e.g.
cr_network_icon.js).

[michaelpg, 2015-05-15 03:50:32]

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
File ui/webui/resources/cr_elements/v0_8/demo_element.js (right):

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
ui/webui/resources/cr_elements/v0_8/demo_element.js:32:
console.log('checkboxCheckedChanged=' + this.checkboxChecked);
On 2015/05/15 03:01:41, stevenjb wrote:
> On 2015/05/15 02:45:29, michaelpg wrote:
> > for observer methods set in the properties block, the new value is passed in
> as
> > the first argument. it's probably correct-er to just use that instead of
> getting
> > the property from |this|, since they should be equal.
> 
> Given that they should be equal, why would that be more correct-er? This way I
> think it is clear that this.foo is set to the new property value. (This is
more
> relevant in places where the changed method is more complicated, e.g.
> cr_network_icon.js).

TL;DR: I meant this to be optional.

I guess it's just my opinion that if the argument is explicitly given we should
use it. It's also going to be faster than looking up a property in |this| which
itself is a getter function that gets another property (~38% slower on my
machine - http://jsperf.com/function-arguments-vs-this-accessor)

I don't think there are many cases in Settings where that's going to matter
though, and it certainly doesn't matter here.

Your way saves us from having to document parameters which is nice.

[michaelpg, 2015-05-15 04:29:13]

paper-toggle-button suffers from the same bug. Try using paper-checkbox, make
sure you have version 0.8.4 (rebase to ToT or run reproduce.sh if not).

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
File ui/webui/resources/cr_elements/v0_8/demo_element.html (right):

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
ui/webui/resources/cr_elements/v0_8/demo_element.html:34:
<span>Input.value={{inputValue}}</span>
This isn't supported, {{bindingAnnotations}} need to be the only content of an
element (it basically binds to element.textContent). Wrap it in another span for
example.

Sorry I didn't catch this before.

[stevenjb, 2015-05-15 06:47:00]

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
File ui/webui/resources/cr_elements/v0_8/demo_element.html (right):

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
ui/webui/resources/cr_elements/v0_8/demo_element.html:34:
<span>Input.value={{inputValue}}</span>
On 2015/05/15 04:29:13, michaelpg wrote:
> This isn't supported, {{bindingAnnotations}} need to be the only content of an
> element (it basically binds to element.textContent). Wrap it in another span
for
> example.
> 
> Sorry I didn't catch this before.

Aha. It worked on .5, but I wouldn't be surprised if that was actually a bug.

[michaelpg, 2015-05-15 07:14:22]

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
File ui/webui/resources/cr_elements/v0_8/demo_element.html (right):

https://codereview.chromium.org/1124073007/diff/1/ui/webui/resources/cr_eleme...
ui/webui/resources/cr_elements/v0_8/demo_element.html:34:
<span>Input.value={{inputValue}}</span>
On 2015/05/15 06:47:00, stevenjb wrote:
> On 2015/05/15 04:29:13, michaelpg wrote:
> > This isn't supported, {{bindingAnnotations}} need to be the only content of
an
> > element (it basically binds to element.textContent). Wrap it in another span
> for
> > example.
> > 
> > Sorry I didn't catch this before.
> 
> Aha. It worked on .5, but I wouldn't be surprised if that was actually a bug.

No, it WAI in 0.5 but is no longer supported in 0.8 (or 0.9) for performance
reasons. So anywhere we had a line like 34 we have to wrap the annotation in a
tag like <span>.

[Jeremy Klein, 2015-05-15 18:55:54]

lgtm

I'm cool with this and I appreciate your effort finding a compromise here.
Thanks!

[stevenjb, 2015-05-17 00:26:11]

The CQ bit was checked by stevenjb@chromium.org

[stevenjb, 2015-05-17 00:26:11]

The patchset sent to the CQ was uploaded after l-g-t-m from
michaelpg@chromium.org
Link to the patchset: https://codereview.chromium.org/1124073007/#ps20001
(title: "Fix span")

[commit-bot: I haz the power, 2015-05-17 00:26:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1124073007/20001

[commit-bot: I haz the power, 2015-05-17 02:18:00]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-05-18 11:32:22]

Patchset 2 (id:??) landed as
https://crrev.com/8d81ad5028eb4d90348d7c576c28754555d06a76
Cr-Commit-Position: refs/heads/master@{#330297}