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

Hello www-svg,

 Boris Zbarsky <bzbarsky@mit.edu> wrote:
 
> Issue SVGT12-487 was that the description of the difference between
> _self and _replace in the specification is unclear. This issue has not
> been resolved - the language in the specification is still unclear.

Sorry it still seems unclear.

> Some of the text from Chris's explanation to me in e-mail should
> really find its way into the spec.

Glad that explanation helped. Agreed, we will review that email and add
text to clarify the existing behaviour as appropriate.

> 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. As an example, the HTML one seems totally
focussed on frames, although the HTML WG agrees that target has
non-frame uses. The HTML one omits some values entirely.

> 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. SVG WG has checked with WebCGM WG
that the meanings are consistent between the two specifications. We
also asked WebCGM to check actual implementations; they did so and confirmed
that the definitions in the spec are the same as what actual running
code does. Thus, there is no incompatibility between what the spec says
and what actually happens.

The SVG spec makes no claim that the target attribute has the same
meanings as HTML. It does claim that its the same as WebCGM.

>  but the resolution only talks about a 
> plan to "put examples into the CDR test suite".

As explained, they can't really go in an SVG test suite because they need
a surrounding context to show the different behaviours.

>   This is not an acceptable resolution to me.

Okay, we have noted that you are unsatisfied.

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? How would
that help? It just moves the incompatibility from one place to another,
and makes the spec incompatible with several W3C Recs rather than with some
de-facto but underspecified behaviour.

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).

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.

> Please either reopen issue SVGT12-487, or flag me as disagreeing with this 
> resolution, since it does not actually solve the problem at hand.

We have, reluctantly, marked your disagreement, since the SVG spec is in
fact compatible with the specification that it claims to be compatible
with.

> Also. please create a separate issue for the abovementioned
> incompatibility issue?

Please see the discussion above.


-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Thursday, 3 August 2006 00:20:02 UTC