Update best practices language around attributes/properties

src/documents/articles/web-components-best-practices.html.md

@@ -18,7 +18,7 @@ Keep in mind that we fully expect best practices to evolve over time and so this
 1. **Namespacing**: [Custom elements](http://www.w3.org/TR/custom-elements/) should have a dash in their name (e.g `<x-tabs>`, `<my-tabs>`). The text before the dash is effectively a namespace. You want to keep it short but also unique. Try not to overlap on someone else's prefix if possible. Only use a prefix shorter than three characters if you already have lots of developer interest in your set of components.
 2. **Mimic built-in elements as closely as possible**: Your component should feel just like any other natively implemented element to developers. If in the future you're formally speccing your element's API, will you feel embarrassed by how different it feels?
 3. **Failing silently is golden**: Components should act like native DOM elements, so avoid creating elements that throw JS errors from ordinary DOM interactions, for example: you can place a `<div>` inside a `<ul>`, and while it may not behave or render normally, it shouldn't throw errors either.
-4. **Attributes for data in** Use attributes to pass configuration in. Use boolean attributes for boolean values. Ex: `<my-element selected>` instead of `<my-element selected="true">`.
+4. **Attributes/Properties for data in** The state of an element should always be determinable by its properties and it should not matter the order in which the properties are set. Every exposed attribute should have a corresponding property and updating an attribute should reflect that change to the property. Updating a property should reflect back to an attribute only when it benefits styling, or perhaps accessibility (e.g. if you expose an API where setting a role property would reflect to an ARIA role attribute). If the property sets the corresponding attribute, and you’re using the `attributeChangedCallback` to reflect attributes changes to properties, you’ll want to add a guard to prevent an infinite loop.
 5. **Events for data out**: Use custom events to pass information out of components unless the information to pass is large or changes extremely often.
 6. **Include Dependencies**: Include all dependencies your component needs. Don't worry if that means including redundant `<link rel="import" ...>`; as long as you set appropriate cache headers, these will only be fetched and loaded once. Using [HTTP 2.0](http://en.wikipedia.org/wiki/HTTP_2.0) can reduce the cost of having multiple files, or you can concatenate and minify them into a single file when you deploy your app.
 7. **Document your component**: Document your component so that others know how to use it. Components have many aspects that count as part of their API, including things that you might not think of as part of the API.