On Apr 29, 7:51 am, fantasai <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > On Apr 28, 11:58 am, fantasai <[EMAIL PROTECTED]> wrote: > >> I don't know what "fill" would mean for a non-SVG element, but it sounds > >> like a pretty reasonable approach in general. You just have to define for > >> each property what exactly it means when applied to a CSS box. > > > 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. Rob _______________________________________________ dev-tech-layout mailing list dev-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
