RE: Should the base svg tag receive events?

Doug, WG,

>From thread "How does the svg element handle CSS border and background-color?" moved to FX Task Force list. Posted 8/21/2010. 

> This touches on the question, asked in a related thread, on whether the 
> <svg> element, by default, should be a proximal event target for pointer 
> events.  My answer on that is a pretty firm "no"; if you want to have it 
> as an event target, give it a background, or change the 'pointer-events' 
> value.

I suppose the related thread is "Should the base svg tag receive events?". In that thread several arguments have been exposed. As I understand it, two distinct and correlated points emerged: 
  1) registration of pointer events on the outermost <svg>, or other <svg> or <g>.
  2) the eligibility of the above elements to assume the status of event.target, otherwise expressed in the DOM specification as event's target.

The inconsistency of the svg specification on the subject, as well as some inappropriate language and wording, have been pointed out with multiple arguments, the least of which not being the contradicting interference with other specifications, the DOM in particular.

Questions and requests for confirmation on some sensitive points have not been acknowledged. By not acknowledging, that doesn't make the *crushing* evidence of some of the arguments less crushing.

In a post of 8/16/2010 that remains unanswered, I wrote:

> This being the state of the facts and because of the argument at point 3, 
> I would recommend that the whole section be purely and simply removed. It 
> has absolutely no reason for being. If there is a valid reason for it to 
> exist that I don't know of, I would like to know it as I, as well as 
> others, might be missing something important.
>
> If such reason is exposed here and now, and if it fails to gather the 
> general consent of authors and implementers, or if no valid reason is 
> exposed, then the spec must conform to the common practices and the 
> observed browsers' behavior by recognizing them as standards (my recent 
> post http://tech.groups.yahoo.com/group/svg-developers/message/63966 [1] 
> comes very handy here). Otherwise the implementations must be arbitrarily 
> forced to comply, with all the consequences that that implies.

To this day I haven't seen any such reason exposed. 

That post followed a request for clarification. Must I understand that if clarifications and argumentations do not go in the sense of what the WG would like to hear then they are simply ignored or discarded?

In all response I read through another bias that:

> My answer on that is a pretty firm "no"; if you want to have it as an 
> event target, give it a background, or change the 'pointer-events' value.

I read there that the arguments are not contested but it's like that anyway. What should we make of this? How do you think we can interpret your firm "no"? Would you accept this as a valid answer?

Domenico


[1]
"Then there is also another important consideration: what is to be considered as standard? Traditionally a standard was defined scholarly upon observation of methods commonly used in a trade or discipline, to make official a widespread construction or creation technique, at least the one that prevails on others. Or, following the dictionaries: "something considered by an authority or by general consent as a basis of comparison, an approved model"..."




----- Original Message ----- 
From: "Doug Schepers" <schepers@w3.org>
To: "Jeff Schiller" <codedread@gmail.com>
Cc: "Tony Schreiner" <tonyschr@microsoft.com>; "Kevin Ar18" 
<kevinar18@hotmail.com>; "Chris Lilley" <chris@w3.org>; <public-fx@w3.org>
Sent: Saturday, August 21, 2010 11:39 PM
Subject: Re: How does the svg element handle CSS border and 
background-color?


> Hi, folks-
>
> (Moving this to the FX Task Force list, with a BCC to the SVG list; this 
> is a coordination issue, and should be handled there.  If you are 
> interested in such topics, please do subscribe to the low-traffic 
> public-fx list.)
>
> I've also posted this, in slightly expanded form, on my blog, in the hopes 
> of getting comments from a different part of the community that doesn't 
> subscribe to these email lists:
>  http://schepers.cc/css-in-svg
>
> Jeff Schiller wrote (on 8/21/10 3:16 PM):
>> On Thu, Aug 19, 2010 at 3:08 PM, Tony Schreiner <tonyschr@microsoft.com
>> <mailto:tonyschr@microsoft.com>> wrote:
>>
>>> The list of CSS properties Jeff referenced are the ones that apply
>>> to the SVG content itself, but I would argue that when the outermost
>>> SVG element is embedded in HTML it must behave on equal footing with
>>> similar HTML elements. Going even further, when embedded in HTML the
>>> outermost SVG element should also support being directly styled a
>>> block or inline block, positioned as absolute, relative, or fixed,
>>> and so on. None of these styles are in that list, and none of these
>>> make sense for the SVG content itself, but they do make sense on the
>>> root SVG container element in HTML.
>>
>> I actually have no strong opinion one way or another here.  It's just
>> been my understanding that SVG elements can't be styled with border
>> properties (for instance).  It seemed a logical conclusion to draw since
>> there is no box model concept in SVG.  I didn't think about the CSS
>> ramifications of the fact that an <svg> inline in a HTML context does
>> create a page-aligned box.
>>
>> My main concern in this matter is the following:  Will it be more
>> confusing to new authors to say 'SVG elements cannot be styled with a
>> CSS border' or 'SVG elements cannot be styled with a CSS border except
>> for the outermost <svg> element inline in a HTML context' ?
>>
>> If the specs are updated for the latter and it's clear to authors in
>> practice and we don't get fifty emails to www-svg saying "Why can't I
>> have a CSS border around my <circle>?" then I'm fine either way.  I'll
>> probably still wrap my <svg>s in a <div> though ;)
>
> I think it's pretty clear that the intent of the SVG 1.1 spec was that 
> those box-model CSS properties must not apply to any SVG elements.  In 
> addition to what the spec states on the subject, my conversations with 
> participants from the SVG WG at the time are unambiguous in that respect.
>
> The question is, is that the behavior we want?  How hard or easy is it to 
> change that in modern SVG+HTML+CSS implementations?  What is most useful 
> and intuitive for content authors?
>
> In my opinion, we could specify that some aspects of the box model apply 
> without screwing with SVG's coordinate-based placement system too much. 
> Here are my initial thoughts on some specific properties:
>
> ==Borders==
> A borders is different than a stroke.  An SVG element, including any 
> graphical (<rect>, <circle>, <path, etc.) or container element (<svg>, 
> <g>) can have both a stroke (which conforms to the geometry) and a border 
> (which conforms to the element's bounding box).  A common use case is 
> setting the graphics apart from other content, or doing mouseover 
> highlights of an SVG element; for example, when I mouse over or focus a 
> circle, it would be much nicer, and just as semantic, to simply have a CSS 
> property draw a rectangle around that element as a highlight than for me 
> to generate a rectangle based on the bbox and insert that into the DOM, 
> keep a pointer to it, then remove it when I mouse out.
>
> Paint servers and similar resources (gradients, filters, etc.) would not 
> have any border.  Note: <defs> is a non-rendering element, akin to <head>, 
> so no border would be visible for that either, but if the content of a 
> <defs> is <use>d, any border properties would apply in the same manner as 
> for other properties.
>
> The border would not have any effect on the layout or rendering; it would 
> be strictly visual.
>
>
> ==Margin==
> No effect on SVG content, but may affect HTML content around that SVG 
> content.  So, an <svg> element with 'margin: 20px;' has a 20px gap around 
> the SVG content, just as if it were <img style="margin: 20px;"/>
>
> Alternately, maybe margin only has an effect for <svg> elements; that 
> might be simpler to specify, implement, and understand for content 
> authors.
>
>
> ==Padding==
>
> Again, this has no effect on SVG content, but it does affect how the 
> border is drawn.  This would be a nice way to compensate for thick stroke 
> widths.
>
>
> ==Background==
> A background is different than a fill.  Background is much the same as 
> border; it is a rectangle (modulo the border-radius effects) around the 
> shape, based on its geometric bounding box, taking into account padding.
>
> By default, there is no background color, including for the <svg> element.
>
> SVG Tiny defines a 'viewport-fill' and 'viewport-fill-opacity'.  I think 
> those should be deprecated in favor of 'background' properties; I have no 
> opinion on which should have precedence... maybe they should be seen as 
> aliases of 'background', if that makes it simpler.
>
> A background raises the question of pointer events, which is also relevant 
> to border.
>
> ==Pointer Events==
> Should pointer events on the border or background fire on the element 
> itself?  I think that the default should be "no", just to be safe and 
> consistent with older SVG content, but I could easily be persuaded to 
> reverse that.  Either way, there should be a new property or set of 
> properties that can modify this, in a manner consistent with how CSS is 
> defining 'pointer-events'.
>
> This touches on the question, asked in a related thread, on whether the 
> <svg> element, by default, should be a proximal event target for pointer 
> events.  My answer on that is a pretty firm "no"; if you want to have it 
> as an event target, give it a background, or change the 'pointer-events' 
> value.
>
> ==Questions==
> A few high level questions:
>
> Is this a change from SVG 1.1 and SVG Tiny 1.2?  Yes.
>
> Is this backwards compatible?  Kind of.  It introduces new behavior that 
> is not consistent with past behavior, but doesn't explicitly change very 
> much.
>
> Does this break existing content?  Very doubtful.
>
> Is this intuitive for content authors?  My intuition says yes.
>
> Does this match existing implementations?  Some, at least.
>
> Does this provide value for content authors? Yes.
>
> Does this make it harder to implement?  I don't know; I suspect it makes 
> it easier for at least some implementations.
>
> Does this improve interoperability?  Yes.
>
>
> ==Conclusion==
> I propose we change SVG 2 to explicitly define this behavior.  Hixie seems 
> to imply that this is not for HTML to define, and I tend to agree with 
> that, though maybe some informative mention in the HTML5 or CSS specs for 
> how SVG treats margins and padding might be appropriate.
>
> I don't think this should be any different in standalone SVG files than in 
> SVG files referenced or inlined in HTML.  That would be very unintuitive, 
> in my opinion.
>
> If this is not controversial, I would be happy to put any or all of this 
> in the SVG Integration spec, which is one of the foundations of SVG 2 [1]. 
> If someone disagrees with this, we'll have to talk about it before I start 
> editing the spec.  In either case, it would need to be fleshed out some... 
> I'm probably glossing over some possible stumbling blocks in the box 
> model, which I'd appreciate feedback on.
>
> [1] http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>