Question thread #91

[pauamma]

It's time for another question thread!

The rules:

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)
- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

Comments

[roadrunnertwice]

Just to clarify -- the div needs to have an inline style defined, or can an unadorned div suffice?

Yeah, it needs an inline style. Well, more precisely, it just needs a style attribute. An empty style="" attribute works fine.

That exemption isn't really meant for "normal content" images like a photo or a comics page; it's meant for stuff inside some kind of decorative markup like a character sheet or a nav thingy, where the sizes of things need to line up just so. For casual images, the HOPE has always been that you just post it and it's fine (plus or minus a little bit of click-to-zoom). But we're kind of still getting there.

What's tricky is the amount of (kinds of stuff) x (ways in which stuff gets posted) x (ways in which stuff gets displayed). Like,

• Pixel dimensions match intended display size at 1x (SMBC; QC) vs. px decoupled from display size so it looks good at high-DPI (your comics).
• Integral image meant to be viewed in toto (any non-pano photo, whether landscape or portrait) vs. "navigable canvas" image meant to be viewed in parts, through a movable viewport (comics with vertical panel flow and no splash pages).
• Mobile vs. desktop.
• Bare img tag vs. image in a link (typically pointed at the full size image).
• Handcrafted post intended for DW vs. markup in a feed that came from who knows where.
• Height/width attributes carefully chosen for the purpose at hand vs. height/width attributes auto-filled by an image host's "click for embed HTML" copypasta.
• 1000 journal styles worth of reading pages.

So for a portrait of a person, you definitely want to keep the image inside the viewport by default, which means constraining the height. But that plays hell with a 4-comi style strip, so you need click-to-zoom. But click-to-zoom only fixes strips that aren't inside links (the QC feed); the SMBC feed still looks kinda hosed. But you don't want to break link-clicking, so you need some other way to control zooming, maybe a little hover control or something? But making that work on EVERY JOURNAL STYLE starts getting kind of prohibitive, and besides, the link goes to a full size version of that image anyway, so I haven't gotten that one solved yet. And then we've got your issue, where the pixel dimensions aren't related to the intended display size.

Well, I'm rambling. Anyway, I figured out how to limit the "zoomed" state to the provided height/width attributes, but haven't figured out how to skip displaying the "zoomable" cursor in that case for images that are already the size they'd "zoom" to. Maybe that's not a huge problem; I'll mull it over a bit more.

[potofsoup]

mmmm yeah it's a pretty tough nut to crack. I used to do img tags with pixel widths in the 500-700 range, depending on how much I want the vertical to show on the page, but recently switched to % widths to avoid it being atrocious to mobile users (more of an issue on AO3 than here). I also used to have web-sized images rather than the larger images, but given the range of screen resolutions nowadays, combined with my laziness and the increased speed of the internet, it's just easier to go with full resolution.

It makes sense that you'd want photos or portraiture to fit vertically on the screen, so I just may be the odd person out in wanting to post comics, etc. And I've gotten in the habit of clicking through to SMBC nowadays to read a long strip, so it's not terribly inconvenient, especially since now I know the div trick!

Then again, maybe if either height or width is specified as a percentage on the image, the person might be wanting it a specific way? It was definitely a bit weird to me when my img tag refused to behave in the way I'd intended, and I didn't know why or how I could get around it. (though that might be a documentation issue). But I totally see your point re: random images being brought in that have unhelpful width/height attributes, combined with the wide range of widths for the post container (probably ranging from 300-1000px). Awkwardness regardless, tbh. Tumblr does it awkwardly, too -- inline images below an arbitrary pixel threshold gets displayed as-is (I think 320px wide), and over that gets forced into 100% wide, so if I wanted a 400px img to stay 400 px, I'd have to add 100px of whitespace, or add a "do not resize this" class to the image.

Anyways, thank you so much for the info about the div/table tags, and for doing all this to make it work better! I shall use the tags judiciously!

[roadrunnertwice]

Hmm, now that you got me thinking about it again, I've thought of a few more improvements:

• Just bail out of squishing for any image that includes inline CSS in its style="..." attribute! That's an extremely clear way for people to say "I'm handling it myself."
• Add a new "semi-squished" state with a max width but no max height, and use it on images whose height is more than twice their width. Anything like that is almost definitely not a portrait; probably 70% chance it's a tall comic or meme.

That would still squish your comics more than you want, but if we used your width attribute to make click-to-zoom max out at "legible" instead of "stupid," maybe that wouldn't be that bad? Plus you could always just use inline CSS to do whatever specific thing you want.