W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Stroking algorithm in Canvas 2d

From: Smylers <Smylers@stripey.com>
Date: Fri, 11 Oct 2013 09:32:11 +0100
To: "whatwg@whatwg.org" <whatwg@whatwg.org>
Message-ID: <20131011083211.GA2239@stripey.com>
Rik Cabanier emailed:

> On Thu, Oct 10, 2013 at 2:48 PM, Ian Hickson <ian@hixie.ch> wrote:
> 
> > On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > 
> > > On Thu, Oct 10, 2013 at 1:28 PM, Ian Hickson <ian@hixie.ch> wrote:
> > > 
> > > > On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > > > 
> > > > > > > If you draw a rect with dashes today, the dashing will be
> > > > > > > applied normally. Justin wants to change this behavior so
> > > > > > > we will need something to trigger that. Othewise, existing
> > > > > > > applications that use dashed rectangles will start looking
> > > > > > > different.
> > > > > >
> > > > > > Do we really have enough deployed content using this API that we
> > > > > > are already constrained? What applications are these?
> > > > >
> > > > > Not sure I follow. Are you asking who would use dashed
> > > > > rectangles in canvas?
> > > >
> > > > You mentioned "existing applications". I'm just curious which
> > > > these are?
> > >
> > > Websites using canvas?
> >
> > Do you have URLs I could look at?

Rik, I see you didn't answer that question.

While obviously it's possible that there are websites which are using
dashes in <canvas> and are already depending on the precise behaviour in
browsers that already implement it, the argument ‘we need to keep it
this way for backwards compatibility’ only works if we can see examples
of actual sites where that is the case, and where changing the dashes
would be detrimental to them.

Jasper St. Pierre writes:

> On Thu, Oct 10, 2013 at 6:57 PM, Rik Cabanier <cabanier@gmail.com>
> wrote:
> 
> > On Thu, Oct 10, 2013 at 3:36 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> > > Just so we're clear, I really don't have a strong opinion on this
> > > issue. I just want to make sure we apply the same rigour to
> > > deciding what the model should be as we do to everything else, and
> > > that means not just doing things because they've always been done
> > > that way, but instead either figuring out why they've always been
> > > done that way, or starting from first principles or data and
> > > deriving the right behaviour.
> >
> > I think that's totally reasonable. "That's how we've always done it"
> > often no longer applies.
> 
> Consistency with every other drawing model out there is probably more
> important than you first imagine. Documentation, testing,
> interoperability between browsers, and developer learning are all big
> motivations to keep things the same.

Conversely, I suspect that overall it's less important than you imagine:
the web is continuing to grow at a massive rate, so they are likely to
be far more web developers in the future than there have been developers
so far. In other words, most developers using this API won't have
existing experience of pre-<canvas> systems' dash-drawing APIs — and
that will become more so as time goes on.

It's likely that early adopters of the technology will be those who are
already working in that field using other systems, but I suggest it
would be a mistake to design for the preferences of this small group.

If a new web developer asks “Why isn't there a straightforward way of
doing X?”, I'd rather that the answer isn't “To retain compatibility
with a non-web technology which was invented before you were born.”

Cheers

Smylers
-- 
Stop drug companies hiding negative research results.
Sign the AllTrials petition to get all clinical research results published.
Read more: http://www.alltrials.net/blog/the-alltrials-campaign/
Received on Friday, 11 October 2013 08:32:39 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:11 UTC