Re: CSS Charter

Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote:

> fantasai wrote:

>
>> David Hyatt wrote:
>>> Here is a list from Apple regarding what we would like to see  
>>> within the scope of the charter.
>>
>> What resources is Apple willing to allocate towards getting these  
>> proposed specs and test suites done?
>
> Let me play the devil's advocate intentionnally here.
> That list does ring a bell, does ring a lot of bells in fact.
>
> Transformations, transitions, animations, filters..
>
> has Apple heard of SVG ?

Perhaps this was meant to be a rhetorical question. But in fact we  
have very advanced SVG support, including integration with HTML and  
CSS. So yes we have heard of SVG, have studied it closely, and have  
thought about the implications for the web platform as a whole.

> 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.


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.

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

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.


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