On Mon, Sep 24, 2012 at 4:32 PM, Ian Hickson wrote:
> On Mon, 24 Sep 2012, Tab Atkins Jr. wrote:
>> Returning to the original subject, we don't *want* optional arguments
>> here.
>
> Well, the canvas API has optional arguments, so there's no way to be
> consistent with canvas with this constraint.
On Sep 24, 2012, at 4:32 PM, Ian Hickson wrote:
> On Mon, 24 Sep 2012, Dirk Schulze wrote:
>>
>> Making the path syntax more complex than it needs to be seems not to be
>> an option for me.
>
> It's definitely an option, assuming this is not a trivial statement,
> because it's no the only ax
On Mon, 24 Sep 2012, Dirk Schulze wrote:
>
> Making the path syntax more complex than it needs to be seems not to be
> an option for me.
It's definitely an option, assuming this is not a trivial statement,
because it's no the only axis along which the syntax can be optimised, and
it is not the
On Mon, Sep 24, 2012 at 3:50 PM, Ian Hickson wrote:
> On Mon, 24 Sep 2012, Tab Atkins Jr. wrote:
>> 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 anyt
On Sep 24, 2012, at 3:50 PM, "Ian Hickson" wrote:
> On Mon, 24 Sep 2012, Tab Atkins Jr. wrote:
>>
>> 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 virtual
On Mon, 24 Sep 2012, Tab Atkins Jr. wrote:
>
> 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.
On Mon, Sep 24, 2012 at 1:14 PM, Ian Hickson 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
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
On Mon, 24 Sep 2012, Jonas Sicking wrote:
>
> I'm not at all convinced that that's true. Sure, it is fewer number of
> functions to document and fewer number of functions for people to learn.
> But that obviously isn't the only metric that we care about since then
> we'd just cram all functiona
On Mon, Sep 24, 2012 at 11:51 AM, Ian Hickson wrote:
> On Sun, 23 Sep 2012, Tab Atkins Jr. wrote:
>> On Sun, Sep 23, 2012 at 3:57 PM, Ian Hickson wrote:
>> > On Fri, 21 Sep 2012, Tab Atkins Jr. wrote:
>> >> So, can we rename the 7-arg arcTo to ellipseTo? That seems to
>> >> support your "always
On Mon, Sep 24, 2012 at 11:51 AM, Ian Hickson wrote:
> On Sun, 23 Sep 2012, Tab Atkins Jr. wrote:
>> On Sun, Sep 23, 2012 at 3:57 PM, Ian Hickson wrote:
>> > On Fri, 21 Sep 2012, Tab Atkins Jr. wrote:
>> >> So, can we rename the 7-arg arcTo to ellipseTo? That seems to
>> >> support your "always
On Sun, 23 Sep 2012, Tab Atkins Jr. wrote:
> On Sun, Sep 23, 2012 at 3:57 PM, Ian Hickson wrote:
> > On Fri, 21 Sep 2012, Tab Atkins Jr. wrote:
> >> So, can we rename the 7-arg arcTo to ellipseTo? That seems to
> >> support your "always [require] all the arguments" recommendation. ^_^
> >
> > Ju
On Mon, Sep 24, 2012 at 1:32 PM, Tab Atkins Jr. wrote:
> On Mon, Sep 24, 2012 at 6:59 AM, Rick Waldron
> wrote:
> > Has there been any discussion about moving newly emerging APIs to a
> single
> > "options object" formal parameter?
>
> This discussion is in the context of the SVG API, which is a
On Mon, Sep 24, 2012 at 6:59 AM, Rick Waldron wrote:
> Has there been any discussion about moving newly emerging APIs to a single
> "options object" formal parameter?
This discussion is in the context of the SVG API, which is an
attribute microsyntax. So, that's not possible for this. ^_^
How
On Sun, Sep 23, 2012 at 11:25 PM, Tab Atkins Jr. wrote:
> On Sun, Sep 23, 2012 at 3:57 PM, Ian Hickson wrote:
> > On Fri, 21 Sep 2012, Tab Atkins Jr. wrote:
> >> So, can we rename the 7-arg arcTo to ellipseTo? That seems to support
> >> your "always [require] all the arguments" recommendation. ^
On Sun, Sep 23, 2012 at 3:57 PM, Ian Hickson wrote:
> On Fri, 21 Sep 2012, Tab Atkins Jr. wrote:
>> So, can we rename the 7-arg arcTo to ellipseTo? That seems to support
>> your "always [require] all the arguments" recommendation. ^_^
>
> Just have one arcTo command, that takes all the arguments.
On Fri, 21 Sep 2012, Tab Atkins Jr. wrote:
>
> So, can we rename the 7-arg arcTo to ellipseTo? That seems to support
> your "always [require] all the arguments" recommendation. ^_^
Just have one arcTo command, that takes all the arguments. Why split it
into two, if you always require all the a
On Thu, Sep 20, 2012 at 4:58 PM, Ian Hickson wrote:
> On Mon, 17 Sep 2012, Tab Atkins Jr. wrote:
>> Heya, we at the SVGWG just resolved today to add equivalents for the
>> CanvasPathMethods interface arc/ellipse/arcTo commands to the
>> element's syntax.
>>
>> Ideally, we'd be able to use the sam
On Mon, 17 Sep 2012, Tab Atkins Jr. wrote:
>
> Heya, we at the SVGWG just resolved today to add equivalents for the
> CanvasPathMethods interface arc/ellipse/arcTo commands to the
> element's syntax.
>
> Ideally, we'd be able to use the same names as Path, for minimal
> confusion - "" producin
Heya, we at the SVGWG just resolved today to add equivalents for the
CanvasPathMethods interface arc/ellipse/arcTo commands to the
element's syntax.
Ideally, we'd be able to use the same names as Path, for minimal
confusion - "" producing a line
from (0,0) to (40,30), then a quarter-arc to (30,40
20 matches
Mail list logo
