Add "why upgrades" document to proposals section

[domenic]

This hopes to explain why upgrades are important.

[annevk]

This doesn't address the drawbacks about not being able to do parser extensions (e.g. set in the constructor how the parser should behave for this element, get end tag notifications).

[annevk]

And also how this basically does not match what any user agent does at the moment and therefore puts us down a particular path for any new features related to constructing elements that might be less than ideal.

[domenic]

@annevk I think parser special-cased elements are additive to upgradeable elements---you can have both. Not in the same element, sure. But I think authors are much more interested in progressively enhanced non-specially-parsed elements than they are in only-usable-after-loading-definitions specially-parsed elements. For the minority who do want the latter, we can definitely add that functionality, if they are willing to give up progressive enhancement.

This does match how user agents work at the moment, if you conceptualize the built-in element definitions being already loaded before parsing happens. I'm not sure what you mean by how it could constrain new features, though.

[dglazkov]

This is starting to get off-topic for this particular discussion, but would love to get a better handle on parser extensibility. Should this even be a design goal? It seems that most element-specific parser strategies are things that we would like to avoid in the future. The requests that I've seen are all "make my element behave like a <template> element", which seems like it should just be solved by sub-classing. It might be good to just say "parser is done" and avoid complicating things.

[domenic]

@dglazkov that is a great discussion to have though. I've forked the thread to #113 for that specifically.