Re: [SVGMobile12] Resolution of issue SVGT12-487 not satisfactory

Chris Lilley wrote:
>> Further, the issue we discovered in the process of said explanation --
>> an incompatibility between the behavior of "_self" in the proposed SVG
>> Mobile 1.2 specification and the de-facto behavior of "_self" in
>> <object> and <iframe> in existing HTML UAs -- is still unresolved.
> 
> Not really - its agreed that the target in the SVG Tiny 1.2 draft, the
> SVG 1.1 and SVG 1.0 Recs is different to de-facto HTML UA behaviour for
> the HTML target attribute.

Why, though?

> As an example, the HTML one seems totally focussed on frames

Not de-facto.

> although the HTML WG agrees that target has
> non-frame uses. The HTML one omits some values entirely.

You mean like "_replace"?  Given that that behavior is given by "_self" anyway 
(in HTML), it seems like it's not really needed...

>> As I had understood, the plan was to work on resolving said
>> incompatibility,
> 
> The specification says that the target attribute meanings are from
> WebCGM, which is a W3C Recommendation.

Perhaps this is my objection then.  The meanings in WebCGM are inconsistent with 
the #1 de-facto use of targeting on the Web.  I don't see a good reason for this 
inconsistency past the fact that no one actually working on any HTML UAs was 
involved in WebCGM and that WebCGM decided to add another value for the "target" 
attribute instead of expanding the meaning of the existing attributes to include 
more than just frames (which is the default behavior of HTML UAs, and what the 
HTML specification would by now say in errata if the HTML WG ever published any 
errata).

> The SVG spec makes no claim that the target attribute has the same
> meanings as HTML.

This is my objection, frankly.  I don't see why there should be two different 
target attributes that the W3C specifies that have two totally different 
meanings.  If the only problem is that the HTML WG is completely unresponsive in 
changing circumstances (which is what WebCGM seems to be working around with 
"_replace"), then the solution, in my opinion is to ignore the HTML WG and 
follow the de-facto HTML "standard" -- what all the HTML UAs do.

> It does claim that its the same as WebCGM.

Why?  That is, why is compatibility with WebCGM more important than 
compatibility with the #1 most common use of targeted loads on the web?

> Okay, we have noted that you are unsatisfied.

Thank you.

> What would make you satisfied? Are you asking us to change the behaviour
> so that it is no longer the same as WebCGM but instead is the same as what
> you describe as de-facto behavior of HTML implementations do?

Yes.

> How would that help?

It would, imo, make it more likely that this portion of SVG is actually 
implemented per spec in HTML UAs.

> It just moves the incompatibility from one place to another

True; the question is where it does the most harm.  Specifically:

1)  Are there SVG UAs that are also HTML UAs?
2)  Are there SVG UAs that are also WebCGM UAs?
3)  Are there WebCGM UAs that are also HTML UAs?

I suspect the answer for #3 is "no".  For #1 and #2, I again suspect that the 
answer is "yes" to both, otherwise you wouldn't care about compat with WebCGM, 
right?  ;)  At which point the question becomes which set of UAs would suffer 
more from this incompatibility and which set of UAs the SVG Working Group cares 
about more, in terms of getting this part of the spec right.

> and makes the spec incompatible with several W3C Recs

I would be interested in the list of these Recs and in how those interact with SVG.

> rather than with some de-facto but underspecified behaviour.

I believe I wrote up a pretty clear specification of the behavior at some point 
in this thread...  If the problem is that it doesn't have an official W3C stamp 
yet, I fully expect that to be remedied by the WebApps Working Group.

> Besides, this does not introduce an incompatibility. It just means that
> the SVG target is not the same as the HTML target. The SVG 'a' is not
> identical to the HTML 'a' either (its broadly similar, but the HTML one
> forbids nesting, for example).

Sure.  But at this point you're assuming things about implementations (for 
example, that the targeting algorithm is implemented by the link node).  I 
suppose that could be done, in general...

> You have not explained why de-facto behaviour of some implementations of
> one specification should have primacy over well specified, implemented
> behaviour that is already in several Recs for two languages which are
> compatible with one another.

It's all a matter of whom you expect to support SVG, frankly.  Keep in mind that 
my position is definitely from the point of view of "some implementations of one 
specification" here.  ;)  As things stand, all I can say is that it's not very 
likely that Gecko would ever implement this part of the SVG specification 
correctly, due to the need to do centralized targeting (to handle HTML links, 
window.open, and so forth in a consistent fashion).  Hence me raising the issue.

> We have, reluctantly, marked your disagreement

Again, thank you.

-Boris

Received on Thursday, 3 August 2006 00:47:45 UTC