layout.html should not be bundled with the polymer.html import. #942
Comments
|
|
@mitranim unfortunately, it's not as simple as that. As I state above, if any element I use imports |
|
The problem is actually even worse. Polymer requires that you load it via rel=import, It seems Polymer devs think that forcing XHR is okay. I find this rather grotesque. Edit. Nevermind, I was being incredibly stupid: forgot to change |
|
@philipwalton layout.html is causing conflicts with the google-analytics components. If you use the |
|
Ping. Polymer team, as @rchedrese-va points out, @rchedrese-va, the only way I can think of to deal with this problem right now is to manually override the styles imposed by html /deep/ google-analytics[segment] {
display: flex;
position: static;
margin: 0;
padding: 0;
background-color: transparent;
-webkit-box-shadow: none;
box-shadow: none;
border-radius: 0;
}You'll also have to make sure to update that code if either |
|
Closing this issue due to age and the release of version 1 of Polymer - please feel free to re-open if this is incorrect. |
While I fully support the goal of making it easier for developers who use Polymer to do layout in a simple, sane way, I think the way it's currently being done contradicts pretty much all the best-practices Web Components are trying to promote.
When you include the
polymer.htmlimport, you get a global stylesheet containing global attribute rules that all use the/deep/and universal selectors. In other words, they match every single element inside<html>, even elements inside a shadow boundary.This means that the following attributes are essentially "claimed" by Polymer:
flex,block,hidden,relative,fit, andsegment. If anyone else uses them, there may be unintended consequences (which, again, is exactly what Web Components are supposed to help avoid). There are also several other attributes, which, if used in conjunction with the wrong attribute, will have the same problem:horizontal,vertical,inline,auto,none, etc.These are all pretty common words, so there's an extremely high probability that other developers will use them without realizing they come with style baggage. In fact, that's how I discovered
layout.htmlin the first place. I was trying to debug a conflict.The very first sentence on the Polymer website reads:
Encapsulation
Web Components are supposed to be pro-modular and anti-globals. The main selling point of Shadow DOM is style encapsulation, and yet Polymer, out of the box, breaks that with no way to opt out.
Interoperability
One thing that makes Web Components superior to all existing UI solutions is the promise of interoperability. The point is you can import a custom element, and, regardless of whether it was made with X-Tags or Polymer or with just JavaScript, it's supposed to work and not conflict with the existing elements on the page.
However, if I'm building a site with X-Tag and I import an element made with Polymer, I'm going to get
layout.htmland it's going to potentially conflict with every other element I use.Even if I try to avoid this problem by just including
polymer.js(instead ofpolymer.html), I will still run into this issue if I include anyone else's element that importspolymer.htmlanywhere in the dependency graph.How it should be done
There is no reason
layout.htmlneeds to be bundled with Polymer. It's just a stylesheet, and like every other stylesheet, it can and should be included at the developer's discretion.Another option is to make it a standalone layout element that other elements can compose or extend from to get this styling. At least this way there won't be surprises.
The text was updated successfully, but these errors were encountered: