issue when implementing a button showing a menu

[Hoa V. Dinh]

Hi all,

1. Behavior issue

I tried to implement a button showing a menu in a very simple way and in a polymerized version.

https://github.com/dinhviethoa/polymer-dvh-ui

in non-polymer/ folder, open index.html (I opened it using a local web server), a square “Menu", should show:

When you click on the square, a menu will show and a dark background will also show.

When you click on the dark background, the menu and the dark background will disappear.

I tried to implement the same using polymer.

https://github.com/dinhviethoa/polymer-dvh-ui/blob/master/polymer/dvh-menu-button/dvh-menu-button.html

The polymer version is in polymer/ folder.

Run the following:

$ bower install

Then open index.html through a local web server.

When you click on on the button “Menu”, the menu only will show. The dark background will not show despite I’m doing the exact same thing.

Moreover, when I toggle the Web Inspector, the dark background will suddenly appear.

Can someone help me understand how to get it to work?

Is it an issue in Chrome?

2. Debugging

2.1. inspecting DOM

It feels to me that it was generally more difficult to debug a combinaison of Polymer elements that I wrote compared to just styling my items in the DOM.

Here’s what the DOM of the non-polymer version shown:

 

The DOM of the polymer version, when I enabled shadow DOM in devtools, I had the following:

There’s much more information and makes it difficult to find the items you want to inspect.

I think linearizing polymer elements should help: merging #shadow-root and the content of the node.

It will prevent me to try to dig in these two hierarchy independently.

2.2. inspecting CSS style

It’s also more difficult to know which CSS stylesheet is responsible for the given look of your element.

For example, when I’m focusing on dvh-menu-item in DevTools:

I know that the "font-size: 10px” CSS property value applied because of "::content dvh-menu-item user agent stylesheet” but it’s misleading because it’s not because the "user agent stylesheet” and there’s no indication of which CSS file (or HTML file) is responsible for this value.

Of course, we have here a very simple example. Sometimes, the hierarchy can be even more tricky to inspect.

Is there some experienced polymer user/developer who has some recommendation about how to workaround those debugging issues?

I’m running on Google Chrome 34.0.1788.0 (Official Build 245082) dev.

Thanks.

-- 

Hoa V. Dinh

[Scott Miles]

> 1. Behavior issue

This is a CSS calculation problem due to a Blink bug. Whenever toggling dev-tools fixes a display issue, you probably have found a Blink bug.

In particular, dvh-menu-button style selected by "#overlay.opened ~ #background" is not applied correctly due to a Blink bug (being investigated). As a workaround, I added code to dvh-menu-button.js which toggles .opened on #background as well as #overlay (exploiting the bug to fix itself).

Note: in the code from GitHub, the dvh-menu-button.html declaration has `noscript` attribute, so the script portion of the control (in dvh-menu-button.js) was being ignored. I removed the noscript attribute for my testing.

> 2.1. inspecting DOM

> It feels to me that it was generally more difficult to debug a combination of Polymer elements that I wrote compared to just styling my items in the DOM.

This is a natural reaction, because we have introduced scoping into your mental model. DOM used to be one giant pile of global nodes, but ShadowDOM allows encapsulating entire subtrees into a scope. At trivial scales, the introduction of scoping can look like boilerplate, as you see. But the scoped architecture can handle drastic growth in complexity.

It's true that when you compare the raw composed trees, the scoped version is clearly more heavyweight. But the point of the scoping is to avoid you ever having to study the full composed tree. We let the DOM sort that out at render time. For design and debugging, the goal is to study only individual sub-trees. 

> Here’s what the DOM of the non-polymer version shown:

 

I would suggest a more apples-to-apples comparison would be:

Even for this small example, the Polymer version is cleaner and free from implementation details. 

It's true that you will need to look into deeper layers, but the idea is to drill down one shadow-root at a time. In other words, scoping enables each shadow-root to be an abstraction that can be tested for inputs and outputs as a black box. 

IOW, start debugging the relationships between the dvh-* elements without opening any shadow-roots. Only after determining, e.g., you need to study something about dvh-menu itself would you crack open it's internals via the shadow-root inspector.

It's true that dev tools spams the inspector with "shadow root" entries (when Show Shadow DOM is enabled), I think we can improve this at dev tools level.

Also, as it happens, your most used element is trivial (dvh-menu-item), so the sense of custom element overhead is amplified (it's almost all overhead). If the goal is to allow dvh-menu-item to take on lots of extra complexity, this is a good design: by encapsulating an element, we can hide arbitrary complexity into it's scope. 

OTOH, for compactness, one can completely remove the registration of dvh-menu-item. We can still use that tag name, just in it's natural state as a plain HTMLElement.

You can also simplify things by using data-binding for events and state. In my version, see that the event-handlers are wired up declaratively, which helps decouple the behavior from UI. Also, the 'opened' state is now managed in the API by a boolean property. The UI itself decides what 'opened' means for presentation.

Here is a version with these simplifications for your review: http://jsbin.com/ixIpIMa/3/edit

After these changes, it seems to me the Polymer version compares favorably to the raw DOM version.

> 2.2. inspecting CSS style

Seems to me you have found a bug or two in dev tools, I don't think this reflects a problem with custom elements per se.

As for complexity, the answer is the same as above: the good part about Shadow DOM is the scoping. For CSS, this means most rules are constrained to exactly one shadow root (aka tree scope). Just like when inspecting DOM, you can study subtrees in isolation, which dramatically reduces the complexity barrier.

HTH! Thanks so much for the detailed feedback.

Scott

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/0FBD868DA0FE452F93C4BB0991BAAFF6%40google.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Hoa V. Dinh]

1. Behavior issue 

In particular, dvh-menu-button style selected by "#overlay.opened ~ #background" is not applied correctly due to a Blink bug (being investigated).

Is there a crbug related to it that I can follow?

2.1 and 2.2. inspecting DOM and CSS

In the real world, I’ll be debugging my app - written with Polymer elements, then usually need to show the shadow DOM.

Then, I’ll still face the huge DOM to inspect with two different paths: #shadow-root and the regular DOM.

I usually need to inspect the DOM to try some CSS styling and understand why a given CSS style is happening.

And the “scoping” doesn’t help here.

Keeping the shadow DOM hidden in the web inspector only happens when I’m not writing any polymer elements and using only existing ones.

It’s clearly not my use case.

I still think we need some improvement in DevTools.

-- 

Hoa V. Dinh

[Scott Miles]

On Thu, Jan 23, 2014 at 3:01 PM, Hoa V. Dinh <d...@chromium.org> wrote:

1. Behavior issue 

In particular, dvh-menu-button style selected by "#overlay.opened ~ #background" is not applied correctly due to a Blink bug (being investigated).

Is there a crbug related to it that I can follow?

https://code.google.com/p/chromium/issues/detail?id=337573

 

2.1 and 2.2. inspecting DOM and CSS

In the real world, I’ll be debugging my app - written with Polymer elements, then usually need to show the shadow DOM.

Then, I’ll still face the huge DOM to inspect with two different paths: #shadow-root and the regular DOM.

There is a bit of a miscommunication here. Yes, you certainly need to debug your app, and you will need to show Shadow DOM to do that. However, if you open every shadow dom of every element as shown in your screenshot, then you are doing it wrong. 

 

I usually need to inspect the DOM to try some CSS styling and understand why a given CSS style is happening.

And the “scoping” doesn’t help here.

The scoping will utterly help you if you let it. E.g, a shadow-root represents an isolated world of DOM, data, and CSS. This allows you to divide-and-conquer complicated scenarios via encapsulation.

Wrt styling, because of scoped CSS, in most cases a shadow-root can is only affected by it's own CSS. You have no cognitive load from the potentially massive amount of styling in other scopes, you can simply ignore it.

 

I still think we need some improvement in DevTools.

Certainly, I don't disagree with that. I do however want to distinguish DevTools features/bugs from problems with Polymer architecture itself. 

Scott

[Elliott Sprehn]

On Thu, Jan 23, 2014 at 3:58 PM, Scott Miles <sjm...@google.com> wrote:

On Thu, Jan 23, 2014 at 3:01 PM, Hoa V. Dinh <d...@chromium.org> wrote:

1. Behavior issue 

In particular, dvh-menu-button style selected by "#overlay.opened ~ #background" is not applied correctly due to a Blink bug (being investigated).

Is there a crbug related to it that I can follow?

https://code.google.com/p/chromium/issues/detail?id=337573

I might also suggest you not use the ~ combinator in CSS. It's very very slow since it causes huge style invalidations.

- E

[Scott Miles]

For the record, there is a working version for reference here: http://jsbin.com/ixIpIMa/3/edit

On Wed, Jan 22, 2014 at 6:26 PM, Sergey Shevchenko <serg...@google.com> wrote:

You have the `noscript` attribute on your `<dvh-menu-button>` yet your element has a scripting part to it, which you're including from outside the element's definition. This is not how things are normally done in Polymer. Could you move the `<script>` tag inside the element, remove the `noscript` attribute, and retry?

I'll leave the rest to others to comment on.

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/c49765de-c9e4-4592-8fe4-29fd7cfe5980%40googlegroups.com.