Re: ISSUE-141 (IME examples): IME examples [DOM3 Events]

[timeless]

On Wed, Oct 6, 2010 at 9:22 AM, Web Applications Working Group Issue
Tracker  wrote:
>
> ISSUE-141 (IME examples): IME examples [DOM3 Events]
>
> http://www.w3.org/2008/webapps/track/issues/141
>
> Raised by: Doug Schepers
> On product: DOM3 Events
>
> Hallvord R. M. Steen 
> :
> [[
> In the text about Input Method Editors [1], the examples do
>
>> keydown: 's' (U+0073, Latin Small Letter S key)
>> compositionstart: ''
>> keyup: 's' (U+0073, Latin Small Letter S key)
>> keydown: 'i' (U+0069, Latin Small Letter I key)
>> keyup: 'i' (U+0069, Latin Small Letter I key)
>> keydown: 'Convert'
>
> Now, I'm not a developer - merely a "black box" QA tester - but is it
> possible to implement this in a cross-platform way? AFAIK, on Windows,
> Windows mobile and perhaps other platforms all the implementation will get
> in a keydown event is a VK_PROCESS virtual key code. How is the
> implementation then supposed to map that to an 's', an 'i' and so on?
>
> What sensible implementations currently do is to fire keydown with keyCode
> set to 220 (VK_PROCESS) and keyup with the actual key's virtual key code -
> if the platform makes it available in keyup events, otherwise 229.
>
> (Sorry about the number of separate E-mails today. I've tried to read the
> spec carefully earlier, but it's funny how you overlook things and they
> suddenly jump at you..)
>
> [1] 
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keys-IME
> ]]

I think I had similar concerns when looking at what the IME for Maemo5
or its successor could provide (it tends to take lots of shortcuts).

I think in general it is not safe to expect IMEs to be particularly
forthcoming in their contribution of events.

Also, the Maemo 5 IME can do things like complete "ti" as "timeless",
from my perspective this is really an IME effect, it's equivalent to
me ing "timeless" or "meless" over/after "ti" (however you want
to think about it), it isn't equivalent to me typing "t" "i" "m" "e"
"l" "e" "s" "s", as I didn't do that. One reason to consider this is
when you look at how PuTTY for s60 or the Maemo IME work w/ SSH
sessions over dialup. If each character is pressed, each would be sent
as its own *expensive* packet over a slow and expensive dialup link
(where the user is paying per padded encrypted packet), plus the round
trip response packets. In mobile devices each packet and each
computation to process each useless intermediate step is expensive, so
avoiding them is appreciated.

Re: ISSUE-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 Events]

[timeless]

On Wed, Oct 6, 2010 at 9:16 AM, Web Applications Working Group Issue
Tracker  wrote:
>
> ISSUE-137 (IME-keypress): Should keypress events fire when using an IME? 
> [DOM3 Events]
>
> http://www.w3.org/2008/webapps/track/issues/137
>
> Raised by: Doug Schepers
> On product: DOM3 Events
>
> Hallvord R. M. Steen 
> :
> [[
> current spec text says about the keypress event:
>
>> This event type shall be generated after the keyboard mapping
>> but before the processing of an input method editor, normally
>> associated with the dispatching of a compositionstart, compositionupdate,
>> or compositionend event.
>
> I think this is wrong, if an IME is actively processing the input no
> keypress event should fire.
> ]]

There was some discussion at work about how a search engine (e.g.
Google [this was before it had the really live search, but after they
added the drop down stuff]) might want to handle incomplete IME bits.
I'm not sure if we have useful notes on this subject, nor do I
remember what my opinion was at the time (it would have been about a
month before my vacation which lasted a month).

I think my general tendency was to ask not to provide keypress but to
provide the event in some IME specific event instead. It's ok for an
IME aware HTML application to listen for such events, but it isn't OK
to confuse a naive web application (and let's face it, most are). I
might have also argued that it would be ok to provide keydown/keyup
notifications and only suppress keypress, but I really don't recall.

Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting

[timeless]

Thanks to Art, I'll be there. Most likely I'll be available as a scribe.

I'm still digging through my backlog (one month's vacation takes time
to recover). I should be done w/ my webapps backlog sometime tonight
minus comments on actual documents (and that leaves one more mailing
list w/ 400 threads to read).

notes to self:
Currently I need to look at D3E, DOM-Core, Widgets: TWI + P&C.

I'll also try to read a few charters before TPAC, e.g. Web-Notifications.

Re: [widgets] Best practice / recommendation for widget id scheme?

[timeless]

On Sat, Oct 2, 2010 at 6:53 PM, Marcos Caceres  wrote:
> Alway use a http uri.  Should we make an Authoring note in P&C about this?

https should be ok too :)

Re: A URL API

[timeless]

On Mon, Sep 20, 2010 at 9:27 AM, Adam Barth  wrote:
> On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe  
> wrote:
>>> 1) There are now two methods for getting at the URL parameters.  The
>>
>> and none for setting them?
>
> That's correct.  Looking at various libraries, there seems to be much
> more interested in paring out query parameters than for constructing
> them.  One popular JavaScript library did have an API that took a
> dictionary and built a query string out of it.  I imagine most folks
> just use the HTML Form element.

MXR (hg.mozilla.org/webtools/mxr/) has an api for constructing urls
(mostly parameters really). It tends to do redirects/rewrites which
send most but not all of a set of parameters to another location.
Another thing it sometimes tries to do is drop empty bits () from the url. another thing it of course does is
strip out '../' or similar variations.

Note that MXR happens to mostly do its work server side, but there are
bits which would do equivalent work client side, the server/client
side bit is an implementation detail and I'd expect that people not
caring about JS-off browsers would put much more of the code into the
client and use javascript to do these manipulations.

I'm sorry that I don't have time to read the current document. I'll
try to do that once I finish reading my backlog.

Re: [widgets] Draft minutes from 23 September 2010 voice conf

[timeless]

On Thu, Sep 23, 2010 at 5:06 PM, Arthur Barstow  wrote:
>   Regrets

Minor note, I had told people in August that I would be on vacation
for September, thus I should have been listed in Regrets for this
meeting (and the previous one).

Re: XHR2 proposal: support for informational responses

[timeless]

On Fri, Sep 10, 2010 at 6:07 PM, Julian Reschke  wrote:
> it might be cool (and not too complicated) to (optionally) expose 1xx
> responses to the caller (see
> ).

There's one application I know of (not browser based) which regularly
reports "Error 100 Continue ..." as a dialog.

> This could be done through an opt-in, such as specifying a callback function
> to be called asynchronously when the messages come in (returning status line
> and headers).

As long as it's opt in per specific code, to avoid the disaster that
I've seen in existing apps which don't properly handle this, it should
be fine.

xhr.addEventListener("http100",  function callback(status_number,
status_string, response_headers, response_body){})

Note that I'm not in favor of someone adding support for "http1xx", I
expect callbacks to be surprised when they get a specific number that
is not the one they were designed for (just as my app above wasn't
expecting 100).

Re: ISSUE-122 (add mousewheel): Consider adding 'mousewheel' again [DOM3 Events]

[timeless]

On Fri, Sep 10, 2010 at 2:09 PM, Web Applications Working Group Issue
Tracker  wrote:
> 'mousewheel' was later dropped based on feedback from implementers (Mozilla, 
> Microsoft), who expressed a reluctance to implement 'mousewheel', and a lack 
> of useful interoperability and concern that any change to improve interop 
> would likely break a number of sites.
>
> However, the group may wish to consider adding it again, see:
> * http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0103.html

I'm generally concerned about events which don't work well in other media.

One of the challenges we faced while developing the n900 was dealing
with web sites which expected a fully functional two button mouse (the
n900 is a touch screen with no buttons). We've had designs at time
which provide for showing a mouse on part of the screen and enabling a
user to tap on the left/right buttons etc., this is painful,
expensive, awkward, and I don't have any studies showing users manage
to make this work. Having to deal w/ the scroll wheel case makes this
worse. Otoh, it /might/ be ok to specify "onzoom" and "onscroll", most
devices have /some/ support for these operations (in the n900 we have
hardware volume keys which are sometimes used for zooming, and the
user can user their finger or stylus to trigger a scroll operation).
The same general behaviors could exist in e.g. the iPod
Touch/iPhone/iPad -- none of which have a scroll wheel.

Sorry for the lateness of my reply, I was on vacation last month and
now have 100+ conversations in this group to catch up on (this
includes not being able to respond to messages between "LC
Announcement" and "LC Deadline").