SVG editing using designMode/contenteditable sounds like an interesting and extremely complicated investment area for the browser. I don't think we want to support using SVG elements for editing scenarios at the moment.

Let’s focus on making editing HTML elements better for now.

I think the API is fine the way it is hanging off of HTMLElement.

Thanks for the input.

I'm still studying feasibility for this, and let's keep this open
until we find good reasons to or not to do so for SVG element.

Currently SVG element can be focus-able with tabindex and can get
key events, so the same could be done for composition events.

If we allow just receiving DOM compositionevents on any SVG element
which have focus (just like keydown events), it would be more consistent
between HTMLElement and SVGElement.

As Travis commented in #1, allowing contenteditable on SVG element
should be a hard thing, but just allowing it to handle composition event
and allow Javascript code to draw the composition wouldn't add much
complexity to SVG code.

I'll investigate this further for this but this can be dropped from the
first version of IME API, as the need for this should not be so big.

As the method was changed to a property (getInputContext() -> .inputMethodContext), changed the subject accordingly.

Somebody will revisit this once this is required for a useful purpose.