W3C home > Mailing lists > Public > www-svg@w3.org > July 2008

Re: Applying SVG properties to non-SVG content

From: James Elmore <James.Elmore@cox.net>
Date: Wed, 16 Jul 2008 12:09:10 -0700
Message-Id: <4DBCD53A-517A-47EB-BA52-D288E018119E@cox.net>
Cc: www-svg <www-svg@w3.org>, "www-style@w3.org" <www-style@w3.org>
To: Bert Bos <bert@w3.org>

On Jul 16, 2008, at 5:12 AM, Bert Bos wrote:

> On Saturday 12 July 2008 01:08, Doug Schepers wrote:
>> Bert Bos wrote (on 7/11/08 2:58 PM):
>>> A different problem is how to set the priorities. Compared to all
>>> the other work being done in SVG and CSS, how high a priority is
>>> this and how many resources are available for it? Should it be done
>>> in the next two years (at the cost of what other work?), can it
>>> wait a year or two, should it not be done anytime soon, or not be
>>> done at all...
>> Personally, I see this as a high priority.  I think it should be
>> started in a timeframe that allows Mozilla, Opera, and Safari to
>> include this in upcoming product releases.
> I disagree. For me this is low priority.
> SVG exists. People can already make a fancy filter or gradient.  
> Whether
> it is easier to do in CSS than in SVG and if indeed it is so much
> easier that it justifies making CSS more difficult to use and
> implement, is a discussion that we can maybe have one day, but  
> there is
> no hurry.
> There are other things that are not possible yet and for which CSS is
> much more clearly the right place: hyphenation, columns, page numbers,
> leaders, vertical text, non-rectangular wrap-around, downloadable
> fonts, fixed line spacing, drop caps, baseline alignments, etc. If
> after all that we still think that CSS isn't big enough, we can  
> discuss
> copying some features from SVG to CSS.

I have a slightly different take on this discussion. For me, this is  
not about what SVG can do or what HTML can do; it is about what CSS  

CSS is about styling -- which includes all the things Doug listed  
above, certainly. It also includes things like clipping and providing  
background images and colors. It should also include transforms and  
repeats and masking and -- yes -- gradients. These all have to do  
with the STYLE of a document.

The first chapter of almost every book on X/HTML will inform the  
reader that the language is about content. Similarly, a book about  
SVG will probably claim that it is about graphics. So why is CSS not  
about STYLE? Whether a styling feature already exists in HTML or not  
should be irrelevant in the discussion of whether that feature  
belongs in CSS. If a good styling idea already exists in SVG, I say  
-- take it into CSS and support it as our own. There will already be  
examples of the styling abilities if we take styles from sources  
other than HTML -- use them.

If CSS only exists to style on-line (or recently, printed) HTML  
documents, it is -- and always will be -- a bastard step-child of  
HTML. If we expand CSS so it can add style to SVG documents, it will  
also be a lesser cousin to SVG. To make CSS stand on its own, we need  
to consider style in general, not just style for HTML or for SVG. Too  
often in this (CSS) group's discussions I have seen words to the  
effect that "we don't need that styling feature because ... (pick  
one: it can be done already in HTML; it can't be done in HTML anyway;  
it can be done with SVG; it can only be of interest to SVG users)."

I think of CSS as a STYLING language and want to consider styles of  
all sorts. So what if some of the styles are irrelevant to on-line  
displays? So what if pixel-level controls are unneeded within a  
browser? So what if SVG already allows users to do something which is  
clearly a STYLING issue.

Previously, I suggested adding styling features which differed from  
"what we have always done" and several people basically told me "we  
don't need that styling feature because ... (see above)". Is CSS for  
styling? Or is it just for styling HTML? Are there no good styling  
ideas beyond HTML's borders? And, as the CSS printing group is  
undoubtedly finding out, there are times and places where pixel-level  
controls are useful and times when they are only a source of trouble.  
Why are new ideas in the CSS group measured against what HTML does?  
Why not consider styling in general? If the purpose of CSS is  
styling, then some of the styles will not apply in some  
circumstances. (E.g., pixel-level controls on screens; font controls  
on block elements; gradients behind opaque images; etc.) But they  
will possibly be useful in other cases.

Gentlemen and Ladies -- do not limit CSS by keeping it tied to a 1995  
model of the internet. Let us have freedom to style things undreamt  
in the last century.

Sorry, I was carried away.

There will always be things which do not apply in some cases.  
Consider that CSS may, in the future, style SVG and that some of  
those styles can add to features not possible in HTML. Maybe some of  
the SVG programmers can make the implementation of those features in  
CSS possible. Do not limit yourselves because you are not interested  
in the feature. Maybe more volunteers will step forward if a feature  
they want is considered. Yes, these projects always take time and  
move slowly. But to say that the priorities will not allow even  
considering these styles for several years will make CSS even less  
relevant than saying that "CSS only works for HTML and, if someone  
wants an SVG feature, they should learn to program SVG."

My apologies, again for the rant. Committees tend to bother me  
unreasonably. Please consider the positive points -- if you find any  
-- and discount the rant, if you can.

> Bert
> -- 
>   Bert Bos                                ( W 3 C ) http://www.w3.org/
>   http://www.w3.org/people/bos                               W3C/ERCIM
>   bert@w3.org                             2004 Rt des Lucioles / BP 93
>   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Wednesday, 16 July 2008 19:09:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:19 UTC