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
OK. I'll forward my comment about background-break to www-style. > > For background(#id), you would only be able to usefully reference > > elements that actually render something. So referencing gradients, > > fonts and filters would do nothing. For SVG geometry elements you'd > > establish a viewport the same way as above. > > I don't think SVG elements have a 'border-box' exactly.. How would you > determine whether the SVG element has an intrinsic size or only an > intrinsic ratio? OK, let's render the SVG element in a viewport established by the background clip area. > Referencing filters and gradients directly for a background might be > useful. The size of the box they apply to would be the same as for an > image with no intrinsic size or ratio. Not for filters. For gradients, maybe. That would be a separate feature. Rob _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
