- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 24 Sep 2012 15:18:08 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: WHATWG List <whatwg@whatwg.org>
On Mon, Sep 24, 2012 at 1:14 PM, Ian Hickson <ian@hixie.ch> wrote: > On Mon, 24 Sep 2012, Tab Atkins Jr. wrote: >> > >> > Omitting two numbers, one of which is zero, is easily no more a win >> > than the cost of having two different nearly-identical commands. Just >> > consider C/c and S/s; is it really worth it? >> >> Yes, it is. ^_^ The authoring convenience of not having to repeat >> things, or not having to read past useless things, is fairly >> significant. > > Do we have any data on this? If this really is a concern, it may suggest > that maybe the whole path syntax should be rethought. As it stands it > already has quite a lot of repetition. For example, look at the amount of > repetition in the examples for A/a in the SVG spec. Yes, the A/a commands (ArcBetween) are elliptical-only, which is problematic. As part of our revamping of paths, particular the arc syntaxes, I'll be proposing a circular ArcBetween as well. That eliminates the repetition. >> > What's wrong with A/a? It seems to be equivalent to arcTo(). Is it >> > arc() that you want to add? I'm very confused. >> >> Oh, no, they're *completely* different. arcTo() is *great*, because >> it's convenient and solves a useful problem (rounding a corner) without >> you having to do much math. For A, you have to determine the start/end >> points on the circle yourself, usually involving trig. The only >> similarity between the two commands is that they both draw an arc as >> part of their operation. > > I don't really follow. > > The main use case for arcTo() is rounded corners. With A/a, these are > trivial. Consider a 300x150 rectangle with 10px radius corners, top left > corner at 0,0. There's no trig necessary, you just give the points on each > side, with the radius as offset: > > d="M10,0 H290 A10,10 0 0 1 300,10 > V140 A10,10 0 0 1 290,150 > H10 A10,10 0 0 1 0,140 > V10 A10,10 0 0 1 10,0 > Z" > > (The Z isn't really necessary.) > > If anything, I'd say this is better than what you have to do with > arcTo(), since with that one you have to give both the corner coordinate > and the destination coordinate, rather than just the latter. > > Could you elaborate on what exactly it is that is being done here? If > there were some examples showing the problems that would really help. You are looking at the simplest possible use-case for A/a, nearly the only case that can be done without trig, where you're starting and stopping the arc at a quarter-turn. Try virtually anything more complex, like rotating the square 45deg. Using arcTo it's still trivial - you just need to know enough trig to figure out that the corners are now at (0, 1.414), etc., and the command takes care of the rest for you. With A/a, you need to do a bit more to translate the points of the diamond into the start/end of the arc. Don't even get me started on trying to do a 5-pointed star with rounded corners. In general, if you can do a sharp corner, you can do a rounded corner with arcTo. You need no additional information. arcBetween almost always needs significantly more information. ~TJ
Received on Monday, 24 September 2012 22:23:09 UTC