« Paper can be faster than gadgets: a printable 2014 wall calendar for more efficient scheduling discussions | Main | Delegate brain-melting date math and localization to general-purpose calendar web components »

June 16, 2014


Freemen Muaddib


About the now-deprecated "applyAuthorStyles" to polymer elements, I see a big problem in the design of the polymer platform itself.
As anybody who tried to use polymer elements in the real world, the styling is where developers find more troubles when integrating polymer elements (see for example this excellent article by Chris Strom, author of the book "Patterns in Polymer": http://japhr.blogspot.it/2014/06/a-tag-named-apply-author-styles.html ).
There’s an inherent and unresolved tension in creating styleable general-purpose components. Of course Polymer is too young as a platform, and it may not shows yet. This problem will become evident when a component evolves and acquires more styling.
Suppose you give your component a light gray background so that its “out of the box” appearance looks reasonable. An author overrides that background to be red so that it fits in with their red visual theme. Later, you decide that your component requires a border somewhere to clearly delineate its contents from the outer page. Unfortunately, the aforementioned author wasn’t prepared to override this new border. When they pick up a new version of your component, they’ll end up with a red background but a gray border. That may not be what they want. If this happens too often, the author may come to feel that the use of a general-purpose component is not worth the trouble. The best resolution to this tension is still an open question. For the time being, your best bet is to give your general-purpose component an extremely basic visual appearance. But with time authors would end thinking that is quickier and safer to write all the elements by themself in plain html with their own stylesheet, and this could spell the end of Polymer Elements adoption.

Yury Zholobov

What about navigation by touch swiping with the component reacting as expected by user - tracking touch and dynamically scrolling the content with prev/next content becoming partially visible?

Jan Miksovsky

Yury: Yes, these components definitely need to support touch. That's still a work in progress.

The comments to this entry are closed.