W3C home > Mailing lists > Public > www-svg@w3.org > September 2010

Should the base svg element support CSS or trigger events?

From: Kevin Ar18 <kevinar18@hotmail.com>
Date: Thu, 2 Sep 2010 20:13:03 -0400
Message-ID: <SNT110-W53A3A4632F0EE5E61E253FAA8D0@phx.gbl>
To: <public-fx@w3.org>
CC: <www-svg@w3.org>

Well, I said I wanted to write up a summary about this ongoing discussion.  So here it is.  I had to use an attachment as it is several files: start with index.html
If there is a good place I can upload the files in non-zip form, let me know.
 
Note: hope it was ok to cc www-svg@w3.org ... although the discussion has been on public-fx@w3.org lately.
 
Here is a copy of the index page:
 

This document should: 

Help bring people up to speed on the topic (who have not been following it since the beginning). 
Summarize some of the key points on the issue. 
Key Points

Quick SummaryCurrently there are two key issues that need clarification/solving in the spec. Both issues involve the base/topmost svg element when inserted into an html page (specifically, the svg tag; and not object, embed, or image). 
Events
Question: Should the base svg element block access to content underneath and should it trigger events? 
Clarification: It is highly desirable that the answer be no in both cases, but the issue needs clarification and/or confirmation. 
CSS Styling
Question: Can CSS styles apply to the base svg element (inserted in html)? 
Clarification: Resolving this issue raises all kinds of tricky problems for Events and other aspects.

Details about EventsTo help explain things, I have included the following examples/testcases: 

Visual Examples 
^ These "Visual Examples" provide an easy to understand "visual" explanation. 
These next examples are working demonstrations of Visual Examples 2 and 3. 
These 2 "tests" provide an informal way to demonstrate the desired behavior ... and can be used to check how well a browser works. 

Test 2 
Test 3 
Automated Pass/Fail Browser Tests 
^ This is a test suite that will provide you with a pass/fail for various features ... and can be used to check how different browsers react. 
* The test also "prints out" the results in the textbox at the bottom, which can be used to study how the browser reacted to each test. 
Manual Browser Tests 
^ This is another pass/fail test covering features that cannot be automated. They must be checked manually by a human. 
Resolving the Spec

Several Options:The current plan is to clarify these issues in the SVG spec (and/or other specs). There are several possible solutions (and there are probably others that others might think of). 

Strictly enforce current SVG specs: Declare that the svg element (when inserted into html) has the following properties: (1) it cannot block content underneath (2) it cannot be the target of pointer events (3) it cannot be styled using CSS. 
Pros: 

This seems to be the current interpretation of the SVG specs and how SVG should integrate with HTML 
It requires the least # of changes to the specs (it may only require a clarifying note). 
Cons: 

It ignores some of the realities of the CSS box model. Objects, like the svg element, when included in html content need the ability to be positioned using CSS (thus need to support CSS). 
It seems natural to allow the box/container for the svg element to be styled with CSS properties like border. Many people, myself included, have done this to a base svg element before; and most browsers support styling the base svg-in-html tag with CSS. 
Most, or all, browsers would have to change their implementation to remove CSS style support ... or just leave their implementation non-standard. 
Strictly enforce the current SVG specs just like #1, with one difference: Add many of the CSS styles to the SVG spec. These include adding styles like border, margin, padding, background-color, background-image, into the SVG spec for all SVG elements. 
This option has been suggested by Doug Schepers on his blog. Pros: 

It would keep all issues totally within the SVG spec. 
It treats all SVG the same. In the word of Doug on his blog: "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." 
Cons: 

Not all CSS properties are a good fit in SVG. 
It may be overkill to try and add the styles for all of SVG, when the real problem is only the topmost svg element in a CSS styled XML or HTML document. 
Address the SVG-in-HTML or SVG-in-XML+CSS as a special situation where the "outside" of the SVG element follows the CSS box model and the content area of the box follows the SVG spec -- kind of like surrounding the svg element with an anonymous CSS box. 
I outlined some of the details on this option here: http://lists.w3.org/Archives/Public/public-fx//2010JulSep/0066.html 
As of right now, this "suggestion" is a little incomplete. I would really like to do some research on CSS styles first and maybe post about this "suggestion" at a later time. 
Problems with events that need to be resolved:
More info about CSS styles.
Background Details
If you have not been following this discussion, the following background info may be helpful. 
The Core Issue:The core issue is simple. There needs to be a way to layer SVG elements over html content so that it does not block access to html items underneath. Consult the following documents: 

Rationale - Why this is an importation issue. 
Example(s) 
Ultimate Goal regarding this issue. 
Problem - the spec? the browsers? or both? 
What does the spec say on this issue?

Useful background info 
Clarification of the spec 
Problems, Conflicts, and Items that are unclear  		 	   		  


Received on Friday, 3 September 2010 00:13:39 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:46 GMT