-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Conversation
Revise based on feedback from Arthur
Merge changes from master
Hack in 2.0 preview tab.
|
||
<a href="https://github.com/Polymer/polymer-build/blog/master/README.md" target="_blank">See the polymer-build README for instructions</a>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a typo. I think you meant to link to https://github.com/Polymer/polymer-build/blob/master/README.md.
Side: I worry that we're losing a lot of insight into what happens behind the scenes when using this module with the new text. If there's time I might mention that it's useful for bundling files, extracting inline resources (CSS/JS), generating Service Workers and so on.
<a>...</a> | ||
</my-anchor> | ||
``` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading this correctly, we're encouraging use of falling back to the LightDOM for anything that needs to support progressive enhancement while moving away from the idea of type-extensions becoming a thing you can rely on. Is that right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the answer to #2 is "yes" (we're backing off from pushing type-extension elements in the short term). I don't think it has anything to do with progressive enhancement.
I guess the text here could be a little more nuanced. For something like <dom-bind>
, the whole point is taking a user-supplied template... Hence, taking a template supplied in light DOM makes sense.
A custom input could just as well use an input element in shadow DOM (which is what <paper-input>
used to do, and probably still does). However, there are a lot of attributes you can tweak on an input element... So rather than trying to proxy all of those through to your custom element API, it's easier to let the user set them directly, which the old iron-input
did by virtue of being a type-extension element, and the new iron-input
does by taking an <input>
in light DOM.
This commit replaces the "content" tag in the part "Afer" under the section "DOM Template" of the upgrade guide by a "slot" tag. Closes #1807
remove #
…nt-by-slot Replace oversight tag content
We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm. |
fix hex color code
@katejeffreys Can you test this branch locally to make sure it's working? I'd like to merge this into master (it should be the same as what we have on the site right now). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
No description provided.