On Apr 29, 4:25 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > (Apologies for butting in.)
You're quite welcome :-). > On Apr 25, 6:05 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: > > > I wasn't sure whether to blog about this but I thought I might as well > > start a little conversation here first... > > > People are proposing all sorts of extensions to CSS for fancy > > presentational effects --- gradients, canvas backgrounds, masks, and > > so on. I think this is unwieldy and duplication of effort. > > Do you mean unwieldy to authors or unwieldy to implementors? > > For reference: I just checked and the patch to add CSS masking added > 191 lines of code to WebKit, excluding the ChangeLog entry. To compare > to another somewhat duplicative piece of functionality, we have over > 8000 lines of code specific to SVG text support (that's excluding > generic text layout and font code). So I don't think it is that big a > deal for implementors. If I'd designed SVG I'd have tried to make it share more with HTML and CSS. But that's water under the bridge, it's hard to fix now. The cost is not just the cost of the implementation, but also the work required to spec out the features, the extra testing required, the extra syntax that authors and tools must know. > > Instead I'd just like the SVG CSS properties 'filter', 'mask', 'clip-path', > > and > > 'fill' to Just Work on non-SVG content --- making the full power of > > SVG paint servers and effects available to HTML content. And I'd like > > a way to specify any element as an 'image' source for CSS 'background' > > and other properties ... could be as simple as url(#element). > > These would be neat features and I think Opera does this already. Glad you think so. > In general, I don't think the "SVG already does this" argument holds > much water. SVG does text, hyperlinking and inline inclusion of bitmap > images, features that were already in HTML, and this is not > unreasonable. These things are basic, and just as applicable to vector > graphics on the Web as to hypertext. > > So, even with the ability to use SVG styling with HTML, I think a > native CSS way to do it is still desirable. Gradients and masks are, > much like shadows and rounded corners, pretty basic effects that are > well supported by underlying graphics libraries. It shouldn't be > mandatory to reference them from a separate SVG document (with its own > SVG DOM and presumably render tree) to use them in CSS. > > While SVG is great as a markup language for scalable vector graphics, > I don't think it works so well as a styling language for other markup > languages. It was never designed for that. True, it was not designed for that, more's the pity. I want to see how apt it is for that purpose, and what might need to be done to make it more suitable. Duplication isn't my only concern here. I'm concerned that as we strive for increasingly complex effects, CSS syntax struggles to cope. It's hard to work with complex property values; we have no standard object model to script them with. Authors end up banging strings together which is tedious, fragile and slow. Even your CSS transitions and animations proposals have no way to modify their components. Being able to use XML fragments and the DOM seems like a win. You say that gradients and masks are pretty basic effects. Even if that's true (I'm not convinced about masks, at least), it won't end there. Authors will ask for small enhancements, and the path of least resistance will be to add each one in turn as a new CSS property or value. For my taste, CSS already tends too far towards a grab-bag of complex features instead of a small set of composable primitives. Rob _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
