Re: Should the base svg tag receive events?

Hi Doug,


----- Original Message ----- 
From: "Doug Schepers" <schepers@w3.org>
To: "Domenico Strazzullo" <nst@dotuscomus.com>
Cc: "Kevin Ar18" <kevinar18@hotmail.com>; <www-svg@w3.org>
Sent: Wednesday, August 25, 2010 7:43 PM
Subject: Re: Should the base svg tag receive events?


> Hi, Nico-
>
> Domenico Strazzullo wrote (on 8/25/10 6:36 AM):
>>
>> The original post is always available in the archives.
>>
>>> Why the svg element should NEVER "dispatch" an event due to user
>>> interaction:
>>
>> You cite parts of the svg spec as sustaining evidence. The validity 
>> itself
>> of the spec in regard to pointer events is in cause. The spec cannot be
>> used as evidence for argumentation.
>
> Actually, it can and should.  There are many details in any technical 
> specification where we pick an arbitrary behavior, which implementers 
> should follow for the sake of interoperability.

Ouch! It can not. Perhaps I should expand it to dissipate any 
misunderstandings:

The parts of the SVG 1.1 specification that you are bringing forward as 
supporting evidence, cannot be retained as such because their own validity 
is in cause, meaning, under accusation of non-conformity. Their legitimacy, 
or, inversely, the fact that the accusation is well founded, can only result 
from analysis carried out by those who are examining, while relying on their 
expertise, their common sense and their own judgment. Those examiners will 
not consider the SVG 1.1 specification as the Bible or Coran and will not be 
satisfied by evidence like "the Bible says this so that's it and that's 
that." If the examiners went by that, how could they then use their own 
discernment?

Is it clearer now? Perhaps this short story can also help:

A guy robs a bank but says that he's not an outlaw. Then the judge says "You 
are an outlaw. You will be punished". And then the guy's lawyer says "My 
client is not an outlaw because he says he's not one." So then the judge 
gets up, ready to go, and says "Oh, OK then, no problem. Bye bye."

Nobody can witness in his own favor.

>
> An example that springs to mind: what is the starting point of a rectangle 
> or circle?  This matters because a stroke-dasharray will look different on 
> different viewers otherwise, which is not usually what the content author 
> wants.

'stroke-dashoffset' is normally there for that. Only, all you get in the 
spec is this:
"specifies the distance into the dash pattern to start the dash."
No wonder the agents don't render the same.

>
> Some issues are less arbitrary, and there are good reasons for any of 
> several specific behaviors; in that case, we simply have to pick one, 
> based on the best evidence, and require implementations to exhibit that 
> behavior.
>
> When there are conflicts between specifications, that does cause a 
> problem; however, don't assume that the first specification got it right. 
> For example, HTML5 deliberately contradicts several other (non-HTML) 
> specifications, because the implications of the behavior they describe is 
> suboptimal in the HTML context, and the group and editor of HTML5 made the 
> conscious choice to change the behavior.  In the best cases, this results 
> in a fix to the original spec, through consensus... specs are never 
> perfect, and they can change over time.

It depends on the definition of time. In general you cannot change the rules 
during the game. Like for the constitutions in every democratic nation, new 
laws are constantly added but if a proposal is found to contradict or offend 
an existing law, that one first needs to be abrogated and that may take 
decades because the chambers consider the implications, their utmost 
priority being to not destabilize the order. Radical regimes instead don't 
normally take those precautions.

>
> The SVG spec has changed in the past based on implementation realities; 
> this may be an instance where it changes again.  We don't know yet.
>
>
>> Essentially you say "The spec is right because it says so",
>
> In most cases, I think that this argument is perfectly reasonable.  The 
> spec says what it does because it was the end point of a line of reasoning 
> that the working group responsible for the spec had consensus on.

I'm sorry, this remains to be proven.

>
>
>> where we are contesting the very legitimacy of what it  says,
>> as well as the self-attribution of the prerogative of overriding
>> other specifications.
>
> As the editor for the DOM3 Events specification, I feel pretty confident 
> that the SVG 1.1 spec is not contradicting or overriding that spec on this 
> issue.  I don't agree with Boris' assessment that SVG 1.1 is 
> self-contradictory here; I think that there is an interpretation of the 
> spec that is perfectly consistent with itself and with other specs.

SVG 1.1 <-> DOM2, not DOM3. I can easily believe that you feel pretty 
confident about it as the editor for the DOM3 Events specification.

>
> All that said, we may change the spec anyway, to match some 
> implementations.  Or we (where we includes the implementers) may ask the 
> implementations to change.  That's where we stand with the issue.  We'll 
> decide it at the next SVG WG F2F in a week or two.

If I had to retain one lesson from all this and draw one conclusion, I would 
say this:
To rush the new spec(s) out is not right. It first needs to be audited by 
two, or better, three *independent* entities, whose expertise in the 
technical, as well as literary domain must be thoroughly verified before the 
assignments. The process shouldn't take less than six months and six extra 
months at least could be allowed for letting it cook and testing. This is 
normally the professional way of doing it, given the availability of 
resources. In their absence then the process should take even longer.

Also, the fish is becoming too big for the bowl, there cannot be anymore 
only one entity in control. Another independent entity should be created, 
probably a consortium or association of implementers. The fact that they are 
competitors must not be an obstacle. They should have their own meetings and 
one spokesperson. There should be a mutual control between those entities. 
The implementers, as association, could very well be one of the auditors of 
the specs.

Regards,
Domenico Strazzullo

>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>

Received on Thursday, 26 August 2010 14:39:05 UTC