W3C home > Mailing lists > Public > www-style@w3.org > January 2011

[css3-background] Implementation tips concerning algorithm for computing sizes of background images lacking intrinsic dimensions?

From: Jeff Walden <jwalden@MIT.EDU>
Date: Wed, 12 Jan 2011 13:18:58 -0600
Message-ID: <4D2DFEA2.8010602@mit.edu>
To: www-style@w3.org
I've been working in my spare time to add support to Gecko for properly-sized dimensionless vector background images.  (Currently if a vector image lacks a dimension we assign it the corresponding background positioning area dimension, ignoring intrinsic ratios, possibly mis-scaling in the lack, and so on.)  I've started by writing more tests than you want to know covering, in theory, all aspects of the computation.  Some of the tests are doubtless incorrect, for thinkos, typos, misunderstandings, etc.  Now I'm implementing the algorithm, then I'll see what the tests say, fix the broken ones, fix the algorithm, and be done.  (And possibly give feedback here too, if needed, and post the tests when debugged.)

The current, incomplete Gecko algorithm is about forty lines, structured in this manner.  First, it handles contain/cover.  Then it handles the cases where both dimensions, then either one, then neither dimension, is auto.  In both cases it computes scaling factors to apply to the image dimensions.  It's complex but fairly readable: just mind the maxes and mins.

http://hg.mozilla.org/mozilla-central/file/7a3469118cf3/layout/base/nsCSSRendering.cpp#l2570

The "easiest" approach to add vector support would multiply the algorithm length by 4 (dimensions or not), then 2 (ratio), and splat that huge switch in each place with modifications.  (Or discriminate on contain/cover/etc. first, or on dimension info, or whatever -- embrace the combinatorial explosion.)  I started this approach, and it is a nightmarish amount of code, "trustworthy" only with a proportionate number of tests.   It seems implausible that this is the best approach.

Given the tests I have, I (reviewer's another matter) could probably (very, very grudgingly) live with the 8x algorithm size if that's what it takes to implement it correctly without excessively degrading readability.  But has anyone found a better way?  If anyone can post an outline of their stepwise background size algorithm that accounts for vector images, I'd be eternally grateful.

Jeff
Received on Wednesday, 12 January 2011 19:20:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:36 GMT