Re: Text Selection

Jon Ferraiolo wrote:

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

Great.

>> 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?

Basically, yes. Note that even the case of a regular element (say an 
image) positioned over a native widget form element requires you to do 
all that, except for the SVG transformations, which are not a big deal. 
(Okay I guess in theory if your native toolkit supports transparent 
widgets you could put the image in its own native widget layer on top of 
the form element, but there are other problems there.)

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

True, and that's why we don't use native controls. Safari carefully 
wrangles the Mac native widget set. Dunno about Opera. Even IE doesn't 
use native controls for most of its widgets! (Well, last time I checked 
was IE 5.5; you can use Spy++ to check IE6 for yourself.)

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 16:42:13 UTC