![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Entry tags:
Question thread #91
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.
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.
no subject
It'd definitely be nice if the "zoomed" state respects my width definitions! Or if the shrink wasn't trying to fit to screen height. There's definitely webcomics out there that have a reasonable max width but no max height considerations because nowadays people just scroll. (Instagram is changing that behavior again, but not fully). For example, SMBC (see example from smbc feed here: https://smbc-comics-feed.dreamwidth.org/1103365.html ). At least it's better than tumblr, which basically resizes things to fit to 1024 height, and therefore makes tall webcomics too low-res to actually read...
no subject
Yeah, it needs an inline style. Well, more precisely, it just needs a
styleattribute. An emptystyle=""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,
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.
no subject
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!
no subject
Hmm, now that you got me thinking about it again, I've thought of a few more improvements:
style="..."attribute! That's an extremely clear way for people to say "I'm handling it myself."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.
no subject
Hi! Pardon the necro-post, but since I told you about the more awkward workarounds for image squishing, I wanted to let you know that there are now easier ways to deal with this!
style="(some css)"attribute on an image tag, we don’t squish it at all. So you can use that to set an exact size calculated however you want.Those are all things we discussed later in the thread, but now they’re live on the site. I hope they make things nicer!
no subject
Ah, thank you so much for resurrecting this post! I noticed the image changes on the smbc comics since the code push and rejoiced! And the other things make perfect sense re: image sizing. Thank you so much for making my dreams come true <333