W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

RE: SVG12: non-visual foreign markup

From: Jon Ferraiolo <jonf@adobe.com>
Date: Sun, 1 Jan 2006 15:01:24 -0800
Message-ID: <6ECA24BE410D994496A2AE995367C5C84F8473@namail3.corp.adobe.com>
To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
Cc: <www-svg@w3.org>

Hi Bjoern,
Sorry, I did not fully understand the thrust of your comments.

The primary usage of foreignObject for the years ahead is likely to be visual because the primary reason for using a graphics language is visual rendering. Therefore, it makes sense to optimize the consistency of foreignObject with SVG's other visual rendering facilities. It is for this reason that the SVG spec says that a width or height of zero on foreignObject disables rendering. This matches the rules for other rectangular graphics features in the SVG language. Even if you don't buy this consistency argument and still believe that this rules is wrong, then a second reason is that rules on foreignObject width/height are carryovers from SVG 1.0 and 1.1 and we thus have a backwards compatibility issue. Just one example: Adobe has implemented support in HTML content inside of a foreignObject within two different SVG implementations we have developed in-house.

The primary type of non-visual markup for the years ahead is likely to be audio, for which SVG has an 'audio' element. Perhaps other "rendering" media such as tactile, aromatic rendering, or perhaps other aural rendering facilities will become popular, but for the moment visual and audio are the two main techniques for rendering web content. Therefore, for non-visual foreign markup, I would expect that non-visual and non-audio content represents unusual situation that does not warrant special language facilities. Content developers can simply set the width and height on foreignObject to any positive value, such as "1", and the contents will get null visual rendering (i.e., transparent black, which is equivalent to no rendering).

Would you be satisfied if the specification included an informative note of some sort explaining that non-visual foreign markup still requires a positive width/height in order to be rendered (visual or non-visual), but that if there is no visual rendering for the foreign markup, the positive width/height values will have no impact on the visual presentation of the content?

Jon Ferraiolo
Member SVG Working Group
Adobe Systems, Inc.

-----Original Message-----
From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] 
Sent: Tuesday, December 27, 2005 1:10 PM
To: Jon Ferraiolo
Cc: www-svg@w3.org
Subject: Re: SVG12: non-visual foreign markup

* Jon Ferraiolo wrote:
>In terms of changing the draft, we do not believe any changes are necessary 
>relative to the topics in this email. (Although other comments from you are 
>indeed resulting in changes.)

The issue I raised is that it is unclear how to include non-visual
foreign markup in SVG documents, in particular as the foreignObject
element seems to assume visual rendering. I think the draft either
needs to clearly define how to do that or explain why it does not;
so if there isn't a dedicated section in the draft that I missed
and you failed to point out, this is not satisfactory to me.

>Regarding audio, I am sure you are well-aware that SVG-t 1.2 has an 'audio' 
>element. We strongly encourage content developers to specify audio via the 
>'audio' element, which has the various attributes needed to control audio 
>and synchronize it with the other time-based element and which will work 
>interoperably so long as UAs support the given codec such as MP3, instead 
>of specifying audio via 'foreignObject', which does not have the multimedia 
>attributes that are often needed.

The <audio> element cannot be used to refer to non-visual foreign
markup, it can only be used to refer to complete external non-SVG
resources that are audible.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Sunday, 1 January 2006 23:01:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:06 UTC