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. > I think that makes a lot of sense, but you'd have to define what happens > if I reference e.g. an SVG <rect> element for my background-image. What > are the intrinsic dimensions here? What happens if I reference an SVG font > element? Or a <text> element? A gradient? A filter? Some of these make > sense and some of them don't. Whether they're defined to do something useful > or defined to be ignored, they all need to be defined explicitly one way > or another. 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. Rob _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
