HTML selectedcontent element

[zcorpan]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: HTML selectedcontent element
• Specification or proposal URL (if available): Define the <selectedcontent> element whatwg/html#10633
• Explainer URL (if available):
• Proposal author(s) (@-mention GitHub accounts): @josepharhar
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @hsivonen
• WebKit standards-position:

Other information

Previously, I had looked only at changes to select parsing and had missed whatwg/html#10633 , which appears to be treated as part of the whole package. I'm worried about breaking the so far implied invariant that there is one DOM element node per non-erroneous (possibly implied) start tag. Even template, which changed the basic expectations of how markup corresponds to DOM constructs allows parsing conforming markup to a DOM tree and re-reserializing to round trip. selectedcontent causing one option start tag to result in two option element nodes breaks at least serialization round-trippability of conforming markup. I don't at this time have more concrete reasoning about what practical badness this can cause exactly, but this kind of departure from the (implied) invariants worries me, so I don't want to say "positive" about this particular aspect.

Originally posted by @hsivonen in #1086 (comment)

[mfreed7]

Previously, I had looked only at changes to select parsing and had missed whatwg/html#10633 , which appears to be treated as part of the whole package. I'm worried about breaking the so far implied invariant that there is one DOM element node per non-erroneous (possibly implied) start tag.

I believe that invariant is still true here. The <selectedcontent> element is serialized correctly, as are its contents, and will completely round-trip. Now there is also a UA behavior in these cases (behavior that happens to be at parsing time, but also happens when the user changes selected options) that clones subsequent content back into the <selectedcontent>. In addition, that’s exactly equivalent to what you can do today with script. I.e. I don’t see that as different from this snippet:

<div id=foo>Some content</div>
<script>
  foo.innerText = "something else";
</script>

That will “round trip”, but #foo will now be “something else”. The new thing here is just that <selectedcontent> can have its content replaced. That’s new behavior for HTML elements, but the round tripping behavior seems like a natural fallout.

Even template, which changed the basic expectations of how markup corresponds to DOM constructs allows parsing conforming markup to a DOM tree and re-reserializing to round trip. selectedcontent causing one option start tag to result in two option element nodes breaks at least serialization round-trippability of conforming markup. I don't at this time have more concrete reasoning about what practical badness this can cause exactly, but this kind of departure from the (implied) invariants worries me, so I don't want to say "positive" about this particular aspect.

I’m not sure what you mean here, about one option tag resulting in two option element nodes… can you please clarify?