[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make a drawing with Emacs

From: tomas
Subject: Re: make a drawing with Emacs
Date: Fri, 4 Sep 2020 10:43:23 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Sep 03, 2020 at 09:50:38PM +0200, Tomas Hlavaty wrote:
> On Thu 03 Sep 2020 at 21:43, Lars Magne Ingebrigtsen <> wrote:
> > Tomas Hlavaty <> writes:
> >
> >> svg--arguments is called in 9 places.  Should it be possible to identify
> >> all relevant keys for each use-case or is that not reasonable for svg?
> >
> > It's not reasonable.  Different SVG renderers accept different
> > parameters, etc.
> interesting
> why does it depend on the renderer and not on svg spec?  sounds strange.
> do you have an example?

Go through the W3C specs [1] with a critical eye and you'll see lots
of those little things. After all, W3C is a consortium with very big
players in it (it wouldn't work if it weren't) -- and each of them
follows their own interest. Thus, W3C recommendations resemble a bit
those international treaties where each party has some leeway of
interpretation [2].

And then implementors do what they want anyway; users will come to
us whining that "chrome does this-and-this", we'll tell them "chrome
is wrong", they'll call us "arrogant twits" ;-)

> i can imagine a case where svg is inside html and maybe it could have
> arbitrary attributes, e.g. data-myattr1

In theory, that's what namespaces are for. In practice, though...

Nevertheless, independently of how you embed the thing syntactically
(SVG even allows extending the DTD!) users will throw chairs at you
whenever it looks differently than in Chrome/Firefox/Internet Exploder
Version 0.95 or something. Be sure to duck quickly :-)


[2] Similar structures lead to similar "laws". To me, this is an
   obvious extension of Conway's Law [3]: laws/tech specs are just
   some weird kind of software, after all.

 - t

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]