If v-html is deprecated, would .innerHTML and .textContent still work when used in html? does html case insensitive not apply as in .innerHTML would become .innerhtml?

.inner-html - it's mentioned in the rfc

So .inner-html will be compiler specific? otherwise how it will know if it should be innerHtml or innerHTML?

@donnysim AFAIK, there are only 2 NOT read-only props that not strictly follow the camel-case rules. innerHTML and outerHTML.

@troy351 I know, that's just a question on implementation 🤷

@donnysim I think just add additional check for these two props as an exception

I'm favorable to the shorthand. It remembers me lit-html.

I'm neutral to v-html and v-text deprecation.

I like the deprecation of v-text and v-html to simplify the API. As an alternative to a shorthand though, I wonder if it might be better to use the same behavior as Svelte, assigning to a DOM property if one exists and falling back to an attribute otherwise. Then we'd achieve as brief a syntax as this shorthand while further simplifying the API to deprecate the .prop modifier, instead of adding to the API with difficult-to-google syntax.

I can't immediately think of any edge cases and couldn't find any open issues for Svelte reporting any. Is this potentially feasible?

@chrisvfritz I think that's worth trying, I'm mostly concerned with potential behavior differences from how Vue handles it now. Would need some testing in real world use cases.

@yyx990803 Perhaps as an interim step, detected DOM properties could not only have the DOM property set, but also get added as an attribute, as happens now. That way, if someone is relying on the attribute existing (e.g. using a ref and calling getAttribute), it will still exist. I agree though that either way, we'd need some real-world testing to ensure this doesn't create edge cases we can't currently foresee.

Closing since this is technically no longer needed in Vue 3 - if a property with the same name exists on the target DOM node, it will automatically be bound as a prop.