Wikisource:Wikiproject Once a Week/Layout talk

Examples edit

The Sweeper of Dunluce: the illustration was designed to wrap around the text in a specific manner, thus constraining the text's width, and making it look best if justified. There are also other articles with illustrations that wrap around text.
The Secret That Can't Be Kept: this play needs to be a fixed width so that the right-aligned stage directions don't move too far from the left-aligned dialogue.
The Notting Hill Mystery, Section 7: Fixed width ensures that the diagram is next to the text that it illustrates; more legible if justified.

Sidenotes edit

The Notting Hill Mystery, Section 8 has sidenotes

Exceptions edit

Big caveat: Some pages need the 500px column to be overridden or interrupted! Reasons:

There are some side-by-side text and images that just can’t fit into 500px (though none is more than 600px), e.g.:
- Fair Drinking
- Sonnet (Another rolling year ...)
If we assume that the standard width of a Once a Week page is 500px, what do we do with images that are printed sideways on the page, and thus can be up to 800px wide? For example, London Changes. I’ve so far been setting those to a variable width with the maximum at the full size (750px or whatever), so they can expand outside of the column if the window is wide enough.
A Good Fight - Part 2 contains a score which can't be shrunk any further without making the lyrics ridiculously tiny. It is just under 600px wide.

-- Levana Taylor (talk) 08:23, 6 January 2020 (UTC)[reply]

Thoughts edit

It's very tricky to make sweeping fits-all statements, and I haven't put too much thought into these pages, so forgive me if there are glaring deficiencies:

The Sweeper of Dunluce: lose the width constraint entirely. The image works as well IMO in the top corner, since it's not a drop initial. Something like this. If you really, really want justification, use {{Default layout}} to "recommend" a layout, but don't enforce it on those who don't. By default, users see what you set there as the gadget is a default, but users who don't wish to see it (perhaps because they have their own CSS, or whatever), aren't forced to use it. And if it doesn't suit a reader, they can still change layout. A fixed width is all-or-nothing. E-readers still struggle with the image (I think it doesn't know enough about CSS polygons), but there's not a whole lot you can do here. It's functional, at least.
The Secret That Can't Be Kept: this one probably just needs a max-width on the block centre, not width. Then it should work in all the layouts. The right align doesn't work in my Android ebook app, but it does work on my desktop document reader. Again, it might just not work. For things like poems and plays with "real" line-breaks, I think a max-width'd central column is perfectly fine, and, IMO preferable to ramming it up against the left margin with masses of white space on the right. This is how poems "feel" in print, so it feels natural to me.
The Notting Hill Mystery, Section 7: the diagram here is only next to the text for me in layout 2. In layout 1, the text gets forced under the image, but then it floats right, so you can a kind of dogleg. Probably my font size or something has upset it. Again, I think the best case is not to restrict width for prose that doesn't need it. For the image and text, have a side-by-side div-based layout that collapsed to one-under-the-other in small screens (and in layout 2), CSS flexbox (96% browser support) can do this: as so. This appears to work well in desktop and mobile, and works pretty much exactly as in the original (one under the other) in my ebook reader. Probably older ebook readers without full-scale CSS engines might do it differently, but I imagine they'd fall-back to a similar effect (one under the other), which is probably what you want on any non-desktop screen. The core "magic" here is:

<div style="display:flex; justify-content:center; flex-wrap: wrap;">
<div>
Left "col", or top if wrapping on a small screen
</div>
<div>
Right "col", or bottom if wrapping on a small screen
</div>

~~This would work for Fair Drinking too, I think.~~ Ignore that, I missed that that is a drop initial.

The flex box is very nice, but needs some tweaking. How do I add padding between the columns and make it so that the two items align at the bottom rather than the top? Levana Taylor (talk) 15:32, 22 January 2020 (UTC)[reply]

Add align-items:flex-end to the container for the align-to-bottom and, e.g., padding: 10px; to the relevant items. For this result. Inductiveload—talk/contribs 15:41, 22 January 2020 (UTC)[reply]

A Good Fight - Part 2: this one doesn't need any formatting, I don't think. Lilypond producing fixed width images is a shame, since they could be vectors (SVG), but I don't really know how it all works. it works pretty well in my e-reader, but the fixed image spills out from layout 2 and the mobile page. Not a lot you can do about that, really.
London Changes: that's a challenge. Perhaps {{FI}} would help (it can do percentage-based image sizing), but it has a nasty habit of forcing full-size image loads which are particularly unfriendly to mobile users and e-readers.
Sonnet (Another rolling year ...): this only lines up correctly for me in Layout 2, but other layouts are "OK". I don't have any smart ideas here!

I'm not sure about justification for unconstrained prose, but my instinct is not to force it, and leave it up to the user's CSS to deal with it as needed. Most e-readers justify anyway. If the user is using a narrow layout on their end (e.g. layout 2), they likely have it justified anyway. Tl;dr my feeling is probably do what PSM does and use {{default layout}} (probably with layout 2 or 4) as needed to get a good "default", but set as few "hard" styles (e.g. hard-coded width containers) as possible to maximise the usability in the user's own environment (e.g. Layout 1, e-readers and mobile). Leverage flexbox when useful. Inductiveload—talk/contribs 13:45, 6 January 2020 (UTC)[reply]

Image templates edit

Here is what would be needed for default image templates:

For centered, adjustable-width images, the following parameters are all I’ve been using: width in percent (default 100%); max-width in pixels (never more than 800px, default 500px); top margin (default 25px) and bottom margin (default 20px); alt text. Also, captions: default align=center, font-size=90%.
- However, on second thought, if images wider than 500px (there are only about 30 of them in all) are omitted, then there is no need to specify percent width and max-width separately. 500px=100%, 450px=90%, always. Then the width parameter could be specified in either percent or pixels.
- Exceptions, that wouldn’t use this template, would be for example this (it’s so small that it should be fixed rather than adjustable width), which I would use {{Plain image with caption}} for; and this, where the caption is a complicated block -- I am currently using {{Overfloat image}}, but maybe {{Plain image with caption}} could handle it too.
For left/right floating images, the width would be fixed & never greater than 300px; default margins, top 15px, left/right 15px, bottom 10px. Captions as above, default align=center, font-size=90%.

-- Levana Taylor (talk) 20:40, 21 January 2020 (UTC)[reply]

Some of these cases don't really need any template in my opinion:

[[File:Jonathan Wilde Coffin Plate.png|alt=Mr Jonathan Wilde Died May 24th 1725 In ye 42d year of his age|center|225px]]
{{c|{{smaller|Coffin-plate of the great thief-catcher Jonathan Wilde.}}}}

Coffin-plate of the great thief-catcher Jonathan Wilde.

[[File:Common English grasses (OAW).png|350px|center]]
{{fine block|{{block center|
{{div col|width=15em;|2}}
# Common Sedge.
# Cypérus Sedge.
# Meadow Fox-tail.
# Canary Grass.
# Millet Grass
# Meadow Grass.
# Cock’s-foot Grass.
# Meadow Fescue Grass.
# Quaking Grass.
# Rough Brome Grass.
{{div col end}}
}}}}

This one has extra white space as part of the image, but that could be trimmed. The use of {tl|div col}} means it seamlessly collapses to a single column on small screens.

Common Sedge.
Cypérus Sedge.
Meadow Fox-tail.
Canary Grass.
Millet Grass
Meadow Grass.
Cock’s-foot Grass.
Meadow Fescue Grass.
Quaking Grass.
Rough Brome Grass.

You could still have templates like {{OAW caption}} for unifying the {{c|{{smaller| or {{fine block|{{center block| formatting, so you can adjust the styles from a central location. Inductiveload—talk/contribs 14:04, 22 January 2020 (UTC)[reply]

Ah, you are right. Thanks for pointing out simpler ways! (and I didn’t know about div col) I changed the font sizes to use {{fs90}}. Levana Taylor (talk) 14:30, 22 January 2020 (UTC)[reply]

Centered images edit

(Starting a new section for the specific kind).

I have made a simple template {{large image}} which takes care of scaling an image to 100% if it's bigger than the space allowed. Otherwise, it's the size you specify. Example usage is on the template doc page, and I have made a demo edit at Page:Once a Week, Series 1, Volume II Dec 1859 to June 1860.pdf/444 for you to see it in action. I did not make it a OAW template, as it has no specific OAW logic. Significantly, it will only load the image at the size you tell it to, which, for that page, was a 2500kB -> 139kB reduction. Inductiveload—talk/contribs 15:05, 22 January 2020 (UTC)[reply]

Nice -- that works for the 500px to 800px images. How would you handle specifying top and bottom margins?

Also, what about smaller ones? I would like to keep them proportional to the text column, at least for those larger than 300px: that way if an article has two illustrations, one 400px wide and one 500px, when you narrow the column they both shrink but stay the same size relative to each other. I want to be able to say that they are respectively 80% and 100% of the text column, in other words. Levana Taylor (talk) 15:15, 22 January 2020 (UTC)[reply]

Re margins: could you give an example? It would be possible to feed CSS right into {{large image}} with a parameter, but it might be better to have a special margins param than raw CSS input (or have both), depending on how it's used.

I like to have top & bottom margins of 20px in most cases (that doesn’t look ridiculously large on e-reader does it? it’s good to have the less-cramped space in desktop). In some cases, I want an even larger margin -- for instance, when an illustration is between two stanzas of a poem, the margin-spaces should be at least as large as the spaces between the stanzas: 25 or 30px looks good on desktop. So, having a default margin of 20 and being able to override it would be nice. Levana Taylor (talk) 16:12, 22 January 2020 (UTC)[reply]

For smaller ones, that's might to be quite tricky, as the CSS used cannot be parametrised: phab:T200632. Again, have you got an example in mind? Flex-box layout might work too, but depends on what the use-case is. Inductiveload—talk/contribs 15:23, 22 January 2020 (UTC)[reply]

Compare the two illustrations in The Science of Matrimony (Part 3). Notice that the figures in both pictures are the same size, it’s just a composition with more or fewer figures. So they really are intended to be kept proportional to each other. Mind you, I probably am being ridiculously fussy, given how few people will notice this. But, darn it, I started working on OAW for the pictures, so I care about them! Levana Taylor (talk) 15:48, 22 January 2020 (UTC)[reply]

Ah, I see, I was thinking size-by-side images. This is no so hard: I added a max-width parameter to the template. See this page for a demo. When the page is very wide (>800px), it will by 800/500px as specified. When the page is smaller than that, the images will scale at a ratio of 8:5, because the smaller image has a max-width of 5/8 (62.5%).

I also added a style parameter so you can throw in any other styling, including margins and so on. Handy shorthand, BTW,: margin: 20px 0; sets top and bottom to 20px, right and left to 0. Inductiveload—talk/contribs 16:10, 22 January 2020 (UTC)[reply]

Super!! thanks so much. I’m off to start fixing things, and will bug you again when I run into something fancy. Levana Taylor (talk) 16:23, 22 January 2020 (UTC)[reply]

You're very welcome! Good luck! Inductiveload—talk/contribs 16:26, 22 January 2020 (UTC)[reply]