On Monday 2008-05-26 16:58 -0700, [EMAIL PROTECTED] wrote: > On Apr 29, 7:51 am, fantasai <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > > > Right. For 'fill', 'mask', 'clip-path' and 'filter', which normally > > > apply to SVG geometry elements, you could just say that each CSS > > > border-box establishes a viewport whose size is the size of the border- > > > box, scaled so that 1 user unit is 1 CSS pixel. That would handle most > > > cases, although you might want something a bit more clever for > > > elements that have broken horizontally or vertically, offsetting the > > > viewport in the progression direction by the amount of progression. > > > > mm, there are various ways you might want to handle that. See > > background-break. > > http://www.w3.org/TR/css3-background/#the-background-break > > Turns out this is not a good way to go for filters. The slice-and-dice > approach will produce terrible results for filters that aren't just > per-pixel transformations, e.g. shadows. background-break:bounding-box > is the only value that makes sense there IMHO, so we should just make > that the only behaviour.
I can see shadows being quite strange for 'continuous', but I don't see how they make a case for 'bounding-box' vs. 'each-box'. (I'd also note that we implement background-break, for inlines only, as -moz-background-inline-policy.) It seems like use of gradients for backgrounds ought to obey background-break, though. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/ _______________________________________________ dev-tech-layout mailing list dev-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
