X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/5d21dc313c1d478c8d71e4fe0a22104123059358..669a5f5ecc0d50daf96d8dc2af219c94c8625fb4:/doc/plugins/contrib/album/discussion.mdwn?ds=sidebyside diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn index e504c49a0..23ff9017d 100644 --- a/doc/plugins/contrib/album/discussion.mdwn +++ b/doc/plugins/contrib/album/discussion.mdwn @@ -833,3 +833,57 @@ to `doc/style.css` should be enough? --[[smcv]] >>> And right you are, unsure how I missed that. My album branch is now rebased >>> on your album5 branch (with the two now useless commits removed). >>> --[[cbaines]] + +cbaines, would you mind publishing an album with more realistic pixel-sizes +of images using your modified CSS? It's difficult to get an idea of how it +will degrade under conditions like "image size > browser window" with +images as small as the ones you used. You might find + +(`git clone git://git.pseudorandom.co.uk/git/smcv/ikiwiki-demos/ikialbum.git`), +or the same techniques, useful: it contains images with a realistic pixel +count, but very very lossy JPEG compression, to keep the size in bytes low. + +> I have now created a large (images) example, you can find all the examples +> here [1]. I have also built all the examples with the album5 branch, you can +> find the results here [2]. +> +> 1: +> 2: + +It's much, much easier to review changes if you use separate commits for +cosmetic changes like "separate index CSS from viewer CSS" and "more +consistent indentation", and functional changes like turning the prev/next +links from absolutely-positioned to floating. I'd be happy to apply +the cosmetic changes if they were in commits that were literally only +cosmetic changes, with no functional effect. + +> I have now rewritten the CSS changes to get a smaller diff. The only big +> functional change is from the previous patch is the max-width stuff to cope +> better with large images. + +For the functional bits: I think I'd have used floating boxes instead of the +absolutely-positioned boxes that are currently used if they provided the effect +I wanted. I can't remember exactly why I didn't do that now, but +it might have been because if the browser window shrinks below the image width, +floats have weird behaviour (they push the actual image out of the way), or because +I wanted the entire left/right margin of the image to be clickable to have +a large click-target for scrolling through the album. + +If there's something specific that you think is wrong with the CSS in my +branch, could you please explain it, and perhaps we can come up with something +that matches both our requirements? + +--smcv + +> I don't think that something specific is wrong with CSS in the album5 branch, +> but it does not display large [3], or small [4] images very well. It might be +> possible to resolve the image size issues without changing from absolute +> positioning, but I felt (for no particular reason) that I would do it using +> floats. +> +> The clickable region on the margin seems the most likely reason to me to go +> with absolute positioning, as an initial look at doing this with floats +> suggests that it is non-trivial. +> +> 3: +> 4: