W3C home > Mailing lists > Public > www-style@w3.org > September 2013

RE: [[css-shapes]] feedback

From: David Dailey <ddailey@zoominternet.net>
Date: Mon, 9 Sep 2013 20:32:55 -0400
To: "'Tab Atkins Jr.'" <jackalmage@gmail.com>
Cc: "'www-style list'" <www-style@w3.org>
Message-ID: <002101ceadbd$4b4f3770$e1eda650$@net>

What I meant by the regular <rect> syntax was

<rect x=[real number or percentage of screen] y=[ real number or percentage of screen] width=[length or percentage of screen] height=[length or percentage of screen] ... attribute-value list > -- I am assuming the spec talks about real numbers rather than imaginaries or quaternions or something else weird.

And yes, sure, why not just allow people to reference a real SVG object complete with fill and stroke and all the rest instead of inventing a thing called rectangle? In the case of inner flow, having text inherit the background of a drawn svg object complete with gradient and filters makes sense to me.

Maybe I'm missing some aspect of what the syntax in this draft is referencing though.


-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Monday, September 09, 2013 8:13 PM
To: David Dailey
Cc: www-style list
Subject: Re: [[css-shapes]] feedback

On Mon, Sep 9, 2013 at 5:03 PM, David Dailey <ddailey@zoominternet.net> wrote:
> a)      Just allow the SVG versions of these various basic shapes? That is,
> instead of, for example,
> rectangle([<length>|<percentage>][, [<length>|<percentage>]] why not 
> allow  the regular SVG syntax for a <rect>?

What is "the regular SVG syntax for a <rect>"?  The XML?  The attributes?  Something else?

> b)      Arbitrary <path> elements to flow shape are harder what with all the
> microsyntax of paths, but since all browsers support SVG anyhow (and 
> in particular, they all seem to know how to render paths) why not 
> define text flow for arbitrary paths? What I found a bit tricky in my 
> implementation was following the left and right sides of paths, but 
> compared to the issue of concavities (which you seem to be handling 
> with the even-odd fill rule – that can get a bit odd at times I’m 
> sure) that seems relatively simple in comparison.

Yes, given that we have polygan(), I'm not sure why we wouldn't support path() as well.  It's just a polygon() with curved paths, basically - all the other difficulties of path() are already present and handled in polygon().

Received on Tuesday, 10 September 2013 00:33:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:34 UTC