01390: Make images at line starts HTML5 friendly
Issues:
With a HTML5 doc declaration in the skin template (<!DOCTYPE html>) inline images are vertically aligned at baseline, which is fine if an image is used in a text line, or not stacked on top of another image.
But if it is stacked on top of another image, browsers add a small bottom margin (ca 4px), which cannot be eliminated via css rules, and adds space between vertically stacked images and also between an image and its caption text, making captions appear too low.
And if a text line starts with an image, i.e. image followed by text etc., the baseline vertical alignment is not applied, as PmWiki puts the image into its own block div, and it is not part of a paragraph.
These alignment issues can be observed and tested on page Test.2016Skin, which has the 2016 skin enabled, which carries the HTML5 doctype.
Possible Remedies:
Add css rule to prevent extra bottom margins for images at beginning of a line, with or without captions:
div.img img:only-of-type { vertical-align: bottom; }
Modify the Markup rule for images at the beginning of lines, so such images will be wrapped in their own div block, including caption span element, only if they are followed by the pipe character and caption text, otherwise wrap the image and following text in a <p> tag, so baseline vertical alignment will be applied (which already is the case if a line starts with text and contains an image later). A possible modified rule could be this:
Markup_e('^img', 'block', "/^((?>(\\s+|%%|%[A-Za-z][-,=:#\\w\\s'\".]*%)*)$KeepToken(\\d+L)$KeepToken)(\\s*\\|\\s?)?(.*)$/", "(strpos(\$GLOBALS['KPV'][\$m[3]],'<img')===false) ? \$m[0] : ((\$m[4]) ? '<:block,1><div class=\"img\">'.\$m[1].'<br/><span class=\"caption\">'.\$m[5].'</span></div>' : ((\$m[5]) ? '<p>'.\$m[1].\$m[5].'</p>' : '<:block,1><div class=\"img\">'.\$m[1].'</div>' )) ");
Such changes do not impact skins with no HTML5 doctype, like the current default skin, as far as I can tell.
HansB July 30, 2016, at 03:55 AM
I'm uncomfortable changing the current HTML output: we don't know how people are using it and we may break their wikis on upgrade. However, we could add CSS classes to the division block: <div class='img imgonly'>
when there is a single picture,<div class='img imgcaption'>
when there is a picture with a caption,<div class='img'>
when there is text after the picture but no caption (like now).
This will make sure that nothing changes for existing wikis, but HTML5 skins could use div.imgonly
and div.imgcaption
for styling the vertical alignment. Will this be acceptable? --Petko August 07, 2016, at 01:07 AM
I see you added rules for the 2016 skin, and it works on page Test.2016Skin, so you must have changed the ^img markup for the page too, I guess. I understand your reluctance to add <p> tags for the case of an image followed by text. Still, it looks odd to have what is semantically a paragraph, beginning with an image, without paragraph tags, and wrapped in a div with class 'img'. But then nobody complained about this before, and we were happy having wrappers with classes for captions! So, yes, I can accept your solution, with those reservations. HansB August 07, 2016, at 02:51 AM
Sorry you find this classname odd (I believe you requested the feature and approved the name). Should we have chosen "starts-with-img" it might have been less odd. If people request a change we can make it a variable. --Petko August 07, 2016, at 05:33 AM
PS: My suggested css rule
div.img img:only-of-type { vertical-align: bottom; }
is removing additional bottom margin affecting image captions for current and previous PmWiki versions, so at least half the problems are addressed by that (the caption vertical alignment was my original first concern), whereas your suggested rules do not do that and require the change to the ^img markup. So an upgrade to latest PmWiki (i.e. the next version with the new markup) will need to be recommended if we go for your solution. HansB August 07, 2016, at 03:14 AM
What you request (setting/changing vertical alignment) never worked with HTML5 skins, unless the skins did it. So objectively it is not a problem. People either never stacked pictures, or never noticed the space (or lack of it), or they don't care, or they fixed it if they cared, or they prefer it this way (I do, actually I prefer to have spacing around pictures, see my styles for Mini or Thumblist, which, BTW, are also affected by ^img
, and a Mini:
line semantically can be in a div.img
). There is no need to fix things that aren't broken. Per the PmWiki Philosophy, we don't want to change the HTML or CSS in a way that might modify existing wikis, using existing skins and recipes, or people's custom skins and recipes. But we do want to allow you to change them if you like, and to document and support a recipe if you believe anyone else needs this. Adding simply new classes should achieve both these goals. ... As always, if the community, with arguments and a number of votes requires this to change, we can change it. :-) --Petko August 07, 2016, at 05:33 AM
Petko, please forgive me if I do not understand precisely what you are saying! I do not wish to split hairs about semantics. All I noticed was that changing the doctype to HTML5 is introducing additional bottom margins to images, which changed the vertical alignment of captions and of images on top of each other, compared to non HTML5 doctype skins, and that it was impossible to fix this via CSS alone. Hence my request to change the core markup, so the alignment issues can be corrected via CSS. If you think it is best avoiding changes to the HTML, then please go ahead with your proposal, so we can introduce HTML5 skins without these vertical alignment issues. This has nothing to do with the question if spacing around images may be preferable (I agree with you preferring images with space around them), but that we can control these added bottom margins. So I do hope the core ^img markup can be changed to allow for this. And I am not set on any particular way for that, I just wanted to communicate my thoughts looking at these issues. Thanks. -- HansB August 07, 2016, at 08:26 AM
Added for 2.2.90 (per my comment stamped "August 07, 2016, at 01:07 AM"). Sorry if it was unclear -- we were talking about the same thing, and we both were on the same side. :-) --Petko August 07, 2016, at 10:30 AM