Feedback #10
Description
I've re-read the list for the tenth time, it's very useful
A problem I have, though, is that the list doesn't differentiate between UI and functional components
Otherwise, I have some feedback about the rules that are already present in the list:
Relative Paths — Are all paths relative to required resources (images, etc.) relative to the component source?
A web component should appear self sufficient as far as the user is concerned. If resources are required, they should be packaged with the component. The distribution and packaging standards should be a matter of their own
Local Effects — Does the component limit its effects to itself (or a designated target element)?
This rule is not very clear. Does an overlay affect over elements?
Child Independence — Can you use the component with a wide range of child element types?
This too is unclear. What's considered a wide range? The <span> tag only accepts a very limited set of child elements. Putting a <div> as a child of a <span> will somehow work but it's supposed to be invalid. If the HTML does not always allow child Independence, it shouldn't be considered standard for web components too.
Back-End Independence — Can the component retrieve its content from a variety of a back-end services?
This rule will be practically impossible to enforce in some cases. Take the <google-map> Polymer element for example. While, in theory, it could support other services, it just wouldn't make sense to bundle them all under the same component
Responsive — Does the component scale well to standard mobile, tablet, and desktop screen sizes?
This one is really tricky. While it is very important on visually large components like a text editor, it doesn't necessarily make sense on more atomic ones like buttons. The HTML is not responsive per spec, responsiveness is "only" a UX standard. Then, a more atomic element shouldn't deal with that
Progress Feedback — For long operations, does the component provide appropriate feedback?
Long operations should only be allowed whenever the network is used (think API calls or lazy loading external resources). If an UI element does need computations in order to work, it should be coupled with an external, functional, element.
e.g. a Fibonacci calculator should be composed of two elements <fib-view> and <fib-calc>. Each one should have its own set of events and the user should be in control of whether or not to show a loader and what this loader would look like. Then again, this concern may already be solved by letting the user customize the calculator loader styling
I may have misunderstood the intent of some of the rules, don't hesitate to correct me if I'm wrong.