SVG Properties in CSS (was: Re: CSS Charter)

On Mar 25, 2008, at 11:28 PM, Maciej Stachowiak wrote:
>
> Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote:
>>
>> I would personally really like to understand why CSS should  
>> reinvent the
>> wheel here instead of reusing something that is now widely accepted,
>> widely implemented. And mobile devices are not too weak to handle
>> SVG, a Canon DSLR camera has all its menus and UI in SVG...
>
>
> There's three basic reasons to specify advanced presentational  
> features in CSS, even when similar features are already present in  
> SVG.
>
> But first, let me add that we do not consider this to be a question  
> of competition. We have an implementation of SVG, we think many of  
> the features are great, and we'd like to give them broader  
> applicability on the web. For some of our proposals in the area of  
> advanced presentation, we've tried very hard to be consistent with  
> what SVG does. In other cases we have proposed semantics that are  
> more appropriate in the CSS context. In general, the SVG WG itself  
> envisions that SVG should interoperate with CSS. Many SVG  
> presentational features map directly to CSS properties when  
> appropriate CSS properties are available.

Slightly of-topic, but still interesting (to me) -- why not add the  
missing SVG properties to CSS?

For example: CSS already supports properties to style lines for  
borders and for rules. Add the remaining properties to CSS so it can  
control all the styles of lines available in SVG. If (X)HTML does not  
allow those properties for borders, they can still be used for SVG,  
and possibly for other stylings/languages. Add: stroke, stroke- 
dasharray, stroke-dashoffset, stroke-linecap, stroke-linejoin, stroke- 
miterlimit, stroke-opacity, stroke-width. These properties allow  
control of line styles in much greater precision than border, border- 
color, border-width, and border-style.

Since these attributes are already present in SVG, adding them to CSS  
would improve the SVG-CSS connection. Once they are allowed in CSS,  
some enterprising programmer will add them to parts of HTML. (OR to  
MathML, or ...) Several browsers/UAs already have SVG support;  
incorporating existing features in CSS on these applications would  
not be a terrible burden. (And, for those browsers which do not  
support SVG, this would be further incentive to support the WWW  
standards.)

Several discussions have taken place on this list recently about  
filtering, transforming, clipping, gradients, etc., all of which are  
partially or completely defined in SVG. But without CSS properties,  
these ideas must be controlled solely by SVG attributes. This limits  
the use of CSS in SVG, as well as limiting what CSS can do in other  
circumstances.

As a starting point, take one set of SVG attributes which could be  
used in (X)HTML (such as the stroke* properties listed above) and  
consider adding them to CSS), EVEN IF THEY ARE NOT ALLOWED IN  HTML.  
I think the possibilities opened would stimulate much thought about  
WHY they are not allowed in HTML and HOW they could be very useful in  
HTML.

Other places to begin include properties for gradients, filtering,  
color properties (including profiles and rendering), and fills. Since  
even cell phones support many SVG features, it is unreasonable to  
claim that this proposal would make rendering too slow for HTML.

>
>
> In any case, let's get back to the reasons why SVG, cool as it is,  
> is not enough, in our opinion:
>
> 1) Separation of semantics/markup and presentation.  SVG is,  
> essentially, a presentational markup language. Other languages,  
> like HTML, are designed to work with a separate presentation layer  
> via a stylesheet, in CSS or otherwise. Many SVG features are  
> interesting in the context of Web hypertext documents and Web  
> applications. It should be possible to get these features while  
> maintaining separation of semantics and presentation, without  
> having to use presentational markup. For true vector graphics  
> presentational markup is reasonable, but for Web documents or  
> applications with graphical effects, there are important concerns  
> like machine processing and accessibility where the separation of  
> concerns is important. Furthermore, HTML+CSS has built-in features  
> for advanced flow text layout, and native look & feel form  
> controls. While it is in theory possible to combine such features  
> with advanced graphical effects by mixing SVG and HTML elements,  
> this can be needlessly complex, and behavior in browsers that do  
> not support the relevant features can be hard to predict.

Agreed. SVG requires that it CAN be displayed without CSS, but it  
SHOULD ALSO work with CSS. For some display objects, SVG would still  
be required, since they are too complicated to produce in the HTML  
model. (The SVG model converts everything to pixels, this has  
benefits for presenting graphical objects.) But since HTML already  
has some control over color, lines, images, text, etc., why not allow  
CSS to extend these controls in an SVG fashion over things which HTML  
already allows? And, this would allow extension of the SVG abilities  
(for HTML objects which might support them) into HTML. (Consider: SVG  
allows using text outlines as clipping borders; several people have  
asked for this ability in HTML.)

The CSS model allows browsers to ignore properties which they do not  
support/understand, and designers should provide fall-backs. For  
example, if CSS is extended to support gradients, and some UAs allow  
gradients for background colors, this would be a wonderful design  
feature. And, for those browsers which do not support gradients,  
designers could specify one of the gradient colors as the background.

>
> 2) Syntax matters.  Web content authors are used to writing in [X] 
> HTML and CSS. Being able to add effects like filters and animations  
> in a way that fits naturally with this model would be a strong  
> advantage, compared to having to escape to a wholly different  
> markup language. Furthermore, mixing HTML and SVG can be  
> challenging. To apply any SVG-based graphical effect that isn't  
> exposed at all through CSS

It feels right to control animations with CSS. I haven't been able to  
imagine a syntax which is CSS compatible for this feature, yet, but I  
am still looking. Since I am speaking only about presentational  
features, it should be possible to specify these abilities in CSS.

Since the last time I looked (several years ago), support for  
combining SVG and HTML has greatly improved. It is still a separate  
language, and using SVG to display things which are (partially)  
supported in HTML, and which are purely presentational, seems wrong.  
Equally, it seems wrong to me that some people in this discussion  
group reply 'make an image file' or 'put it in PDF' when asked about  
presentations not currently supported by HTML. (Yes, I know that  
pixel-level control over some things is unreasonable on web pages. I  
also know that gradients can be used everywhere a plain color is used  
in SVG and wonder why that feature is not in HTML or at least in CSS.)

>
> 3) Well-defined graceful fallback.  CSS has a pretty clear model  
> for what happens with unknown properties - they can be specified  
> but are ignored. But injecting presentational SVG markup is tricky  
> - different browsers have divergent approaches to namespaced  
> elements in HTML content, and it can be unclear what will happen  
> with the rendering when an unknown element is injected.

The last time I tried, I was able to use a separate SVG file and an  
HTML <object>. If the UA does not support SVG, it should allow a jpg  
or other image file to replace it. Still, if I am trying to control  
PRESENTATION, not content, it should be possible in CSS, without  
requiring a separate file and/or a separate language within the HTML  
file.

>
>
> Let's look at a specific example, transforms. The CSS WG has  
> already done work in this area, so hopefully it is less  
> controversial. Currently "transform" is an attribute on SVG  
> elements that does not map to a CSS property. However, there is no  
> deep logical reason why it should be allowed to apply an affine  
> transform to a bezier path, but not to a paragraph or table.  
> Clearly, adding a "transform" presentational attribute to all HTML  
> elements would be inappropriate. Sticking with the official SVG  
> path, you'd have to do something like this to rotate a table, in  
> XML syntax:
>
> ...
> <div style="width: 600px; height: 600px"> <!-- have to specify  
> fixed size here -->
>    <svg xmlns="http://www.w3c.org/2000/svg">
>         <foreignObject width="600" height="600" transform="rotate 
> (90)"> <!-- and here -->
>             <table xmlns="http://www.w3c.org/1999/html"  
> style="width: 600px; height: 600px"> <!-- and here, I do not  
> believe 100% works in this context -->
>                 ...
>             </table>
>         </foreignObject>
>     <svg>
> </div>
>
> That's a whole lot of boilerplate - three extra elements, plus a  
> bunch of attributes. The extra elements, in addition to crufting up  
> the markup, are an extra runtime cost in speed and memory. In  
> addition, such xmlns declerations can't be portably used in text/ 
> html markup, so either content must be served conditionally with  
> different MIME types, or the markup has to be actually inserted at  
> runtime with script.
>
> That's a long way to go for a simple rotation effect. We believe a  
> CSS property that can be applied to the table via a stylesheet is  
> simpler and better. This will lead to the rotation effect being  
> ignored in browsers that don't do CSS transforms. In addition, a  
> transform property makes sense for SVG too. There is no deep reason  
> transform must only be an attribute and not a property in SVG -  
> much like other SVG presentational attributes it could map directly  
> to the CSS property. In fact we specifically chose syntax that is  
> aligned with SVG's transform attribute in this case.
>
> I hope this example makes our intentions clear. We are not just  
> trying to duplicate SVG features in a thoughtless way. We are  
> trying to extend some of the more generally applicable innovations  
> from SVG alone to the web platform as a whole, making them easier  
> and more efficient to apply them to CSS and HTML.
>
>
> I will also add that, even though Apple has shipped an experimental  
> implementation under -webkit-prefixed properties, we do not want  
> this implementation to lock in our preliminary design choices. This  
> implementation is a proof of concept that these ideas can work well  
> in the context of CSS, are practically implementable, and can be  
> practical for authors.
>
>
> I hope this information is helpful to the Working Group.
>
>
> In any case, I am a little concerns that as chair you seem to have  
> somewhat negative feelings about this feature going into the  
> charter discussion. It is of course your duty to be skeptical of  
> charter proposals, and feature proposals generally, but I hope you  
> will consider Apple's proposals with an open mind.
>
>
> Regards,
> Maciej
>
>
>
Many features common in SVG have been requested in HTML. Transform is  
one of them. Gradients, filters, clipping, and so on are also  
requested on a fairly regular basis. This proposal would extend  
support for SVG within CSS. It would also allow the addition of some  
of these features (which fit within the HTML layout model, or which  
can be adjusted by declaring how the blocks would move/resize/reshape  
when applied to the block content) to HTML. Once they are part of CSS  
syntax, it would be much easier to expand their usage to HTML  
presentation.

Once SVG presentation is more completely included in CSS, we can  
consider other layout/presentation abilities. Where are the CSS  
styles for music? Can CSS be used in design languages for electronics  
parts? I'm sure others in this group can provide dozens of possibles.  
Of course, not all features of SVG can be used in HTML, but why limit  
ourselves to just the HTML attributes when there are many other good  
models available?

</James>