Allow inline imagemaps
Closed, DeclinedPublic
Actions

Assigned To

Authored By

	Arlolra
	Aug 30 2021, 11:54 PM

Description

From https://www.mediawiki.org/wiki/Extension:ImageMap#Syntax_description

The first logical line specifies the image to be displayed. This must be in the same format as an ordinary MediaWiki image link (see Images help), except without the enclosing [[ and ]] markup.

However, the legacy parser implementation will always wrap the map and img in a div, preventing it from being considered phrasing content and paragraph wrapped.

Parsoid's implementation and the legacy parser's output when !$enableLegacyMediaDOM do not, keeping the same structure as it would normally render the file, with the addition of the map element,
https://github.com/wikimedia/parsoid/commit/f554b152e404183da1467e3314743c1afb5c3834
https://github.com/wikimedia/mediawiki-extensions-ImageMap/commit/66cc306cbe98770add276f28bb497495810d57d7

Unfortunately, this resulted in T271566 where inline syntax is used and the margin from the added paragraph is leaving some of the background visible. This particular case can probably be fixed by using the |none option, but it begs the question of how widespread the effects of such a change may be.

From https://www.mediawiki.org/wiki/Help:Images#Rendering_a_single_image

Controls the horizontal alignment (and inline/block or floating styles) of the image within a text (no default value).

Details

Subject	Repo	Branch	Lines +/-
Bump wikimedia/parsoid to 0.14.0-a18	mediawiki/vendor	master	+1 K -1 K
Force block imagemaps	mediawiki/services/parsoid	master	+50 -16
Force block imagemaps when !$enableLegacyMediaDOM	mediawiki/extensions/ImageMap	master	+22 -10

Customize query in gerrit

Related Objects

Mentioned In: T294467: Error: Call to a member function insertBefore() on null in ImageMap class
Mentioned Here: T214601: Gallery media is erroneously using sub-typeof if format is supplied
rEIMA348ac261cec2: Fixed bug 14052: tidy inserting <p> tags randomly. Put the <map> inside one of…
T271566: Issue with pie graphs on some articles

Event Timeline

Arlolra created this task.Aug 30 2021, 11:54 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 30 2021, 11:54 PM

This particular case can probably be fixed by using the |none option,

Less fun things,
https://en.wikipedia.org/wiki/Module_talk:Chart#Right_align,_caption
https://en.wikipedia.org/wiki/Template:Pie_chart?veaction=editsource

However, the legacy parser implementation will always wrap the map and img in a div, preventing it from being considered phrasing content and paragraph wrapped.

To be clear about this, the div is on the same line as the image and map, so doBlockLevels doesn't wrap it.

https://en.wikipedia.org/wiki/Module:Chart is replicated across many wikis and any fixes would presumably need to be copied there.

Having spent some time trying ot understand the issue, I think we should disallow inline imagemaps. Unlike images where there are reasons for using inline images (icons, trendlines, etc.), imagemaps are meant to be maps with clickable segments and I see no realistic usecase where an inline image would have clickable segments (I suppose we could concoct one, but let someone actually request it before we open this can of worms).

My inclination is to edit the Extension page on mediawiki and explicitly document (to clarify) that any image markup that would otherwise be treated as an inline image in wikitext would be forcibly typecast to be a block image by adding the appropriate image option automatically. That would be ideal resolution rather than work through unnecessary complexity trying to allow them and figure out the impact, lint for edge cases, fix markup, etc.

See commit 348ac261cec277b7883b27f12a6c098158f7b2c9 in the ImageMap repo. Unless I am misreading that, this has been a block since 2008. So, I cannot imagine any user of imagemap is expecting them to be rendered inline. That indicates we should fix the documentation and add the image type-coercion code to force inline syntax to block syntax.

Noting that there are some trappings to forcing |none described in T214601