Skip to content
This repository has been archived by the owner on May 29, 2019. It is now read-only.

2.0 preview minimal docs #1804

Merged
merged 26 commits into from
Oct 31, 2016
Merged

2.0 preview minimal docs #1804

merged 26 commits into from
Oct 31, 2016

Conversation

arthurevans
Copy link

No description provided.


<a href="https://github.com/Polymer/polymer-build/blog/master/README.md" target="_blank">See the polymer-build README for instructions</a>.
Copy link
Member

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>
```

Copy link
Member

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?

Copy link
Author

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.

@googlebot
Copy link

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.

@arthurevans
Copy link
Author

@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).

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@arthurevans arthurevans merged commit 0d7acda into master Oct 31, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants