Re: Applying SVG properties to non-SVG content

James, Bert and Doug,

my take is a fourth way, one not as yet subscribed to by any W3WG

creating at least one version of each spec that provides for an easy- 
to-use AT for the average joe.
no not one mediated by a gynormous hyped corporation, just an average  
joe.

rather than a catchall for any developers' fantasy.
iirc html as originally developed was reasonably successful in this  
respect, even though the tool aspect is outstanding a decade later....

well tx


Jonathan Chetwynd

j.chetwynd@btinternet.com
http://www.openicon.org/

+44 (0) 20 7978 1764


On 16 Jul 2008, at 20:09, James Elmore wrote:

>
>
> 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  
> SHOULD do.
>
> 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.
>
> <rant>
> 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.
> </rant>
>
> 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
>>
>
> </James>
>