Implementing this would be a little problematic for VE too, as we use a XML builder to generate the wikitext for updating the rendering. We'd probably have to switch to sending over the Parsoid HTML and having the API round-trip it to update the rendering.

A few questions come to mind:

• Does the dirtying affect the semantics of the tag extension? Or is it just a noisy dirty diff?
• If the latter, and if only a handful of extensions are affected, we could make a case for tag extensions to be xml-compliant and then use a bot to fix up.
• If semantics are affected and/or a lot of extensions use these kind of properties, it will take more work.

I suspect not many extensions use this, and even fewer would have a flag attribute that could also be a value attribute. That said, <syntaxhighlight> claimed in documentation that using 'line' without a value was equivalent to the default value, line="FACNY_LIES", although this was all lies and the php only cared about the presence of the attribute (see https://www.mediawiki.org/w/index.php?title=Extension%3ASyntaxHighlight_GeSHi&type=revision&diff=1673241&oldid=1659681 ).

Without doing a full audit of extensions I couldn't say for sure if there are any other instances.

I think a dirty diff of attr to attr="" will annoy users though, so if we do go down the XML route, we should have a default value for booleans, e.g. ="1"

The problem with requiring a value is that ="" looks messy in the source and="1" may confuse users into thinking that ="0" will disable the feature, while many extensions are coded to just check for attribute existence.

I think HTML5 says that an empty attribute is actually itself, not the empty string? (Let me check...)

https://stackoverflow.com/questions/21796217/are-attributes-without-value-allowed-in-html4

Alas, "empty attribute syntax" is one of the things which changed between XML, HTML4, SGML, and HTML5. And wikitext extension tags are not any of those, really, so of course we don't have to match them exactly. But it would be nice to move to the HTML5 semantics, just to reduce surprise.

Parsoid should probably just serialize empty attribute values using the empty attribute syntax, since that's almost always what's wanted. That would take care of most of the dirty diff issue. Of course, we could/should tweak the PHP side API to use the HTML5 semantics (that is, treat empty attribute syntax and the empty string value as identical, as far as extension code can tell).

Please provide me with an update? Are you working on it?

@cscott Are you still working on this bug and VisualEditor changes of <references responsive> to <references responsive =""> ?