W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: Text Selection

From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
Date: Thu, 11 Nov 2004 07:53:55 -0800
To: "Robert O'Callahan" <robert@ocallahan.org>, www-svg@w3.org
Message-id: <6.1.1.1.2.20041111072944.059beb20@mailsj-v1.corp.adobe.com>

Robert,
I have some good news.

At 07:19 AM 11/11/2004, Robert O'Callahan wrote:

>Jon Ferraiolo wrote:
>
>>The SVG WG expected no interoperability between user agents that take 
>>advantage of <svg:foreignObject>. Anything within an <svg:foreignObject> 
>>has user-agent-specific behavior.
>That's disturbing, because I expect HTML-in-SVG will be a major use case 
>on the Web. Currently <foreignObject> doesn't work properly under SVG 
>transformations in Mozilla, but we plan to eventually fix that and have it 
>actually participate in the SVG rendering pipeline (no temporary 
>fixed-resolution bitmap). I hope this can be standardized soon.

The W3C has just started a Compound Document working group (CDWG) which is 
chartered to address this very question, along with others. Language 
integration (another way to say compound documents) is the sole subject of 
this working group. We just had our first working group meeting (3 days).

The CDWG schedule calls for focusing initially (for <n> months) on 
integration via reference for mobile platforms, such as a mobile profile of 
XHTML referencing a mobile profile of SVG via the <html:object> tag. This 
is Compound Document by Reference. It was our first meeting and we are 
still figuring out the scope and schedule of the Compound Document by 
Reference (CDR). The mood so far is to get something simple out quickly.

There are actually a number of interoperability issues with the simple case 
of XHTML referencing SVG which we hope to nail. For example, there is no 
spec that says whether two SVGs should have synchronized timelines, or 
whether clicking on an hyperlink within a referenced SVG should invoke the 
hyperlink. Most of these things seem obvious, but they are not written up 
unambiguously in any W3C spec yet. Because they are obvious, we hope we can 
move quickly on specs and create corresponding test suites so that user 
agents can verify that they are implementing these (hopefully obvious) 
integration rules.

Once we have the Compound Document by Reference case far enough along, 
current thinking is that we would start to tackle the Compound Document by 
Inline/Inclusion case. There is a good chance that work on the inclusion 
case will start in earnest in the first half of 2005 (i.e., somewhere in 
the range of January to June), but we are early in the process, so the best 
I can do is offer some level of hope that work will begin *relatively* soon.


>>Denis points out one very difficult problem: native controls. If the 
>>Adobe SVG Viewer hosted the IE MSHTML control (which definitely counts as 
>>a DIFFERENT user agent) to render the embedded HTML, and the content was 
>>rotated or scaled, what would happen? It is not possible to transform 
>>native controls; they only know how to work when both upright and on top 
>>of everything else.
>CSS implementors have already grappled with the problems of native 
>controls. Basic features such as handling the case where a translucent PNG 
>is positioned on top of a form element raise a lot of issues. If you want 
>to do CSS3 'opacity' and printing, then you have to have at least the 
>ability to capture form control rendering to a buffer, and with that you 
>can do almost anything. So I don't see this as a problem for browsers.

But what happens if a user clicks on the rasterized form element? Suppose 
it was an input field. What if the user clicks on the rasterized form field 
to set a type-in point, and then starts typing? How can you determine 
between which characters the user clicked? By intercepting the mouse clicks 
and performing inverse transformations to map back into the coordinate 
space for the (offscreen) native control, and then sending Windows events 
to the native controls, and then rerasterizing after each key event? It is 
hard to believe such an approach could be robust, stable, and performant 
across Windows, Mac, Linux, and who knows what other operating environments 
which Mozilla is used on.

Jon


>Rob
>
>--
>Robert O'Callahan <robert@ocallahan.org>
>"In the beginning was the Word, and the Word was with God, and the Word
>was God. ... The Word became flesh and made his dwelling among us. We
>have seen his glory, the glory of the One and Only, who came from the
>Father, full of grace and truth." 1 John 1:1,14
>
Received on Thursday, 11 November 2004 15:55:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC