Fighting against an easier way to do something because you think it makes the existing way look unusable and unnatural in comparison is like trying to become taller by chopping off other people’s heads.
There is no easier way to do the thing srcdoc is designed to do. You’re trying to get an easier way to do something quite different, but your suggestion if adopted will make it much easier to misuse srcdoc for its primary designed use-case and thus lose all the security benefits, particularly for the non-expert devs that srcdoc was explicitly designed to help.
What you want isn’t any easier for the cases srcdoc was designed for.
And btw, is escaping really that much harder?
Yes. Can you provide a full account of all the markup patterns that will be recognized as being a closing tag? No looking at the HTML spec’s parser section, that’s cheating - the point is that closing tags are definitely non-trivial to recognize, as they’re far wider than just a single search-and-replace can find. (If you do cheat, this is not a correct answer - those are the authoring requirements for valid HTML. What’s actually recognized as an end-tag is much wider.)
Or require the contents to be wrapped in a for extra inertness.
If you can trick the sanitizer into letting your
</iframe> thru (thus escaping the sandbox and yielding a full-blown XSS), you can trick it into letting your
Authoring environments have not been designed for shoving HTML inside attributes.
srcdoc wasn’t designed for authoring environments. It was designed to allow embedding presumed-hostile text into a webpage, with an absolute minimum amount of escaping needed to be absolutely safe. Anything you’re doing beyond that is exceeding what it was meant for, and diluting the security strength of the feature to accommodate non-core use-cases is not a good idea.
What I’m saying is that your request should be for something to directly support whatever stuff you want, not modifying srcdoc to become what you want. The latter is not going to happen because it defeats the entire point. The former, if I read between the lines of your request for an actual use-case, sounds like it’s just shadow DOM + some usability improvements for literal-HTML authoring, which is a reasonable v2 feature request.