James's suggestion: never split a paragraph with a block image. It's not at all obvious what happened, especially if the image is floated right. Instead, we should put the image at the beginning of the paragraph. This would apply when inserting an image, converting an inline image to a block image, and when drag-and-dropping an image.
Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51666
Change 140037 had a related patch set uploaded by Mooeypoo:
Insert images at the start of paragraphs
What is happening to inline images (sometimes used to replace some text which is hard to render, such as letters with stacked diacritics rarely supported in fonts, where the word is instead rendered using an SVG image, or small icons, when they are not inserted by using a custom template?
OK there's a problem with inline images because they cannot be easily dimensionned according to the current font size and positioned according to the line-height and specific baseline of some scripts, and they cannot match other font styles. But they are still needed in some cases because it is not possible to build custom fonts in pages without support of page-level CSS, or scoped CSS (it is impossible with inline CSS in element style attributes that don't have selectors).
Note that it should be possible to rescale an inline SVG image to fit in the 1.6em line-height using CSS "max-height:1.6em" in the <img> HTML element, but MediaWiki still does not support setting any "style=" attribute in [[File:name]] or [[Image:name]].
You can see the effect of client-side image rescaling in the Mobile view of our wikis: it uses "max-width:100% !important" (in addition to other really dirty quirks such as changing the "box-model:" of almost all elements to "border-box" inherited from old "IE quirks mode", rather than the standard "content-box", breaking lots of layouts, even though the mobile view has never been meant to be used with old version of IE; but meant to be used with standard HTML! Someone shoud rework the Mobile view to remove this dirty quirk that breaks lots of layouts as it applies to ALL spans and blocks, forcing many templates to manually set the "content-box:content-box" everywhere and dewikifying lists with ol/ul + li or dl + dt/dd...).
With the support client-side image rescaling (support of "max-height:" style in wiki-images), inline images are safe in the middle of a paragraph (for now they are supported provided that template specify small heights, below 20px).
(In reply to Philippe Verdy from comment #3)
What is happening to inline images (sometimes used to replace some text
which is hard to render, such as letters with stacked diacritics rarely
supported in fonts, where the word is instead rendered using an SVG image,
or small icons, when they are not inserted by using a custom template?
Nothing. This bug is only about block images, as it says.
OK there's a problem with inline images because they cannot be easily
dimensionned according to the current font size and positioned according to
the line-height and specific baseline of some scripts, and they cannot match
other font styles. But they are still needed in some cases because it is not
possible to build custom fonts in pages without support of page-level CSS,
or scoped CSS (it is impossible with inline CSS in element style attributes
that don't have selectors).
Note that it should be possible to rescale an inline SVG image to fit in the
1.6em line-height using CSS "max-height:1.6em" in the <img> HTML element,
but MediaWiki still does not support setting any "style=" attribute in
[[File:name]] or [[Image:name]].You can see the effect of client-side image rescaling in the Mobile view of
our wikis: it uses "max-width:100% !important" (in addition to other really
dirty quirks such as changing the "box-model:" of almost all elements to
"border-box" inherited from old "IE quirks mode", rather than the standard
"content-box", breaking lots of layouts, even though the mobile view has
never been meant to be used with old version of IE; but meant to be used
with standard HTML! Someone shoud rework the Mobile view to remove this
dirty quirk that breaks lots of layouts as it applies to ALL spans and
blocks, forcing many templates to manually set the "content-box:content-box"
everywhere and dewikifying lists with ol/ul + li or dl + dt/dd...).With the support client-side image rescaling (support of "max-height:" style
in wiki-images), inline images are safe in the middle of a paragraph (for
now they are supported provided that template specify small heights, below
20px).
This feels like a MediaWiki bug ("Please let me size text-inline images to automatically be line-height") – do you want to create one?
So the current Tech News needs correction.
The expressions "block image" is ambiguous, at first reading I wondered who was right.
Yes having client-side image resizing with just the addition of support of custom CSS for images would be a bonus.
I know this works because this is already visible and used on the Mobile view even if it works with "max-width:100%" (used with the "box-model" quirk that should have never been used in its specific stylesheet, and which is absolutely not needed)
It also works best with the support of "image sets" (now enabled by default in MediaWiki that can lists several thumbnail sizes, at resolutions 1x, 1.5x and 2x; but it could also add 0.5x and 0.75x for best results, letting browsers select the best interpolations depending on screen resolution and/or zoom mode; and ideally, the image sets for SVG images could also list the native SVG format for the best quality needed for images replacing complex text)
For now the current Tech News for this week (referencing this bug) needs fixing as it is interpreted as meaning all images.
And what you call a "block image" is in MediaWiki an [[image:]] or [[file:]] with "left" or "right" floating-mode attribute, or "center", or "thumb(nail)" (your terminology is strange, because in HTML images are always inline by default, and even MediaWiki keeps them inline by placing the generated <img> element, possibly surrounded by an <a> element, within a block element).
Also, what is happening to image maps in the VisualEditor ? (they are also inline by default, and probably should be resizable by the client)
(In reply to Philippe Verdy from comment #5)
So the current Tech News needs correction.
Our submissions to Tech News are generally re-written to be "simpler" and wrong. This is not (a) a bug and (b) within our control.
The rest of this is not germane for this bug; please take discussion to a venue for proper discussion, like MediaWiki.org or a mailing list.
(In reply to James Forrester from comment #4)
See Bug 66896 (general RFE plus a real bug)
For allowing max-height and general improvement to client-side (and text-friendly) image rescaling which should also be frienfly with the current (broken) Mobile view.
Please discuss Tech News issues by going to Tech News (e.g. Talk page) and not to a VE bug report in Bugzilla. General questions like at the end of comment 5, even if you might consider image maps somehow related to block images in general, should better go to IRC or mailing lists. Thanks.