Organize into Levels?

[justinfagnani]

This is a truly awesome list!

But it might a bit on the long side. I wonder if it would useful to organize it into levels of importance. For instance, loading dependencies and reattachment are way more critical than say restrained colors.

Some of the more important and trickier parts, like supporting content re-projection, or non-obvious enough that they could benefit from being part of a lower level (assuming Level 0 or 1 is the most important).

[JanMiksovsky]

@justinfagnani Thanks for the suggestion. While I agree in general, this is a tricky thing to get right.

• Everyone will have different ideas about what's important.
• History has shown that people are tempted to assign a high priority to issues that affect them directly, and low priority to issues that don't affect them. This is particularly true of accessibility concerns.
• If a developer's goal is to get their component adopted, aesthetic concerns may be just as big barriers to adoption as the correctness of all low-level details. I've seen otherwise interesting components on Bower with such idiosyncratic visual presentations that they couldn't be used on most sites without substantial modification. While it's easy enough to say that adopters should just feel free to style the component they way they want, in practice most people will just look elsewhere for a component they can use without modification. A dev might be better off fixing that presentation before tackling reattachment.

That said, I agree that this list may overwhelm people. I think experience will be the best guide in determining which checklist items are most critical — the ones that are the most important to get right and/or which people most often forget to address. So I think it might be helpful to give this list some time before trying to assign levels of priority. For now, my focus is on getting the list correct, and backing up all recommendations with detail, sample code, and other resources.