Web API TPAC 07 Face to face

Introductions [these have been merged together, although different people were present at different times - CMN]

SD: Sunava Dutta, Ajax champion for IE. DOM3, HTML 4/5 is Travis.

CMN: Chaals McCathieNevile, Opera chief standards officer and chair of the group

DS:Doug Schepers, team contact, work for W3C and am also staff contact for CDF and SVG

AE: Andrew Emmons, from OpenText, we make an SVG player. On SVG/CDF

JW: Jonathon Watt, work for Joost, member of SVG, have been working on Mozilla SVG for some time

ED: Erik Dahlström, lead opera's SVG team, in SVG WG

PL: Peter Linss from HP, new CSS rep. Previously from Netscape, co-inventor of Gecko.

AB: Art Barstow, Nokia, Chair of Web app formats group.

LH: Lachlan Hunt, Opera, editor of Selectors API

AvK: Anne van Kesteren, XHR editor, Opera

MC: Marcos Caceres, Widget spec eitor in WAF, Queensland University of Technology

MS: Michael Smith, W3C, Staff contact for HTML-WG

MJS: Maciej Stachowiak, Safari team (Apple)

FT: Anthony Grasso, Canon - SVG WG.

AP: Addison Phillips, chair of i18n core, Yahoo

OH: Oliver Hunt, keyboard guy, safari

RI: Richard Ishida, i18n activity lead, W3C

FS: Feliz Sasaki, WS Policy group, W3C

Thursday November 8

SVG group: DOM 3 events and other questions from them?

AndrewE: DOM 3 Events is a gating factor holding us back

DS: What in particular?

AE: We need it to be in CR. That's KeyEvents, right? We will align to the WebAPI Mousewheel events proposal.

DS: That has general consensus. But keyboard events are tricky.

CMN: If you need all of DOM 3 key events to happen, you will have to wait. The rest of D3E, including the basic key events already in the draft, can be published quickly, but the rest is difficult and Doug has now got the ball on it (after several people failed to achieve anything)

DS: To get keyboard stuff right is complicated, and needs to bring together a bunch of different groups. We have some commitment from various groups, and we need to draw together the stuff and make a spec that works (because the current stuff doesn't really :( ).
... expecting that this will take half a year to get some kind of reasonable spec.

AE: That would be terrible for us.
... it matters to have some stuff, but we don't need it to be all-encompassing.

DS: I suggest making an informative reference from SVG.

AE: I think it would take an effort from the implementors to decide on a common key structure. If it is ust informative then we still may decide to do it some of the way.

DS: If everyone implementing is at the table we can move this forward. I don't think we will have an interop problem, we will have a "holy grail" of keyboard events.

CMN: The current plan of record for WebAPI is to publish without fixing up key events, and then publish those later. So what works better for SVG?

AE: The current key events stuff more or less works for mobile.

DS: No, it doesn't.

AE: There are softkeys, right?

DS: No, but they can be added fairly easily. these are not really the problem. Going with the keyboard stuff that has been around for ages is hard because it works differently in different browsers (charcode/keycode are inconsistent)

CMN: So you can have the inconsistent stuff now, or wait, or we can drop the key stuff completely like DOM 2 did and you would ahve to reference DOM 2 key stuff plus an informative reference to DOM3KE

AE: I am fine with dropping all the key stuff. What we need is some list of key identifiers.

ED: Sounds OK to me.

DS: There would still be the keyup/down stuff. And there would be in DOM3KE some new stuff informatively. Sunava, would MS actually implement the key event stuff and DOM 3?

SD: What's the timeline?

DS: For the key stuff, we are talking about 2008 or 2009.

SD: Will ask Travis to help drive the design of D3KE. I can't make an implementation commitment at this stage.

JW: Would rather it be split out and done properly than have another key event disaster...

DS: Last one of those was "let's split it out".... The first one was that it wasn't, it was just not implemented

SD: Do we have implementations already?

AE: Yes. If we informatively implement this spec and it changes massively what happens?

SD: That is one of the spots we have to consider.

DS: Relatively small amount of current content, AFAIK only SVG user agents currently implement D3E

AE: There are also OMA, 3GPP, JSR-287 referencing this. Not sure if they are referencing key section.

RESOLUTION: (proposed) We will split out Key Events and want to move the rest of the spec forward as fast as possible.

DS: Coordinating with Bjoern, I will try to chase this and make it happen.

CMN: Any other issues for SVG?

AE: We will align with the proposal from D3E (but have some editorial suggestions)

Specs and authors and prioritisation

summary of Spec status and editors at http://www.w3.org/2006/webapi/

Element Traversal

http://www.w3.org/TR/ElementTraversal/

DS: it's largely the same as specified in SVG, but also includes the childElementCount attribute. I've incorporated all the feedback, and I think it's ready for LC

CMN: When was the last substantive issue raised?

DS: Well before the last draft. Current TR draft incorporates all changes.

ACTION-234: Chaals call for consensus on Element Traversal Last Call [recorded in http://www.w3.org/2007/11/08-webapi-minutes.html#action01]

AE: SVG still specifies Element Traversal. If you get it to keep up we can change to referencing it. We also have some tests.

ED: Heycam was wokring on some, I made at least one, ...

Progress Events:

http://www.w3.org/TR/progress-events/

CMN: There is one outstanding substantive issue which I propsed to resolve in line with HeyCam's comments. It seems that is uncontroversial so I should be ab le to make a new spec after this week, with all the stars in line that would mean last call this year.
... Sun have been nagging for this

AE: SVG has a progress event. not sure how far off it is from your spec.

ACTION-235: Chaals check SVG progress event and see if it is different. [recorded in http://www.w3.org/2007/11/08-webapi-minutes.html#action02]

Selectors API

CMN: Lachy is working, should be close to last call

<Lachy> AFAIK, all issues have been resolved with it and haven't received any comments since the last WD was published

CMN:Lachy, you think that Selectors can go to last call?

<Lachy> yes

<scribe> ACTION-237: Chaals to call for consensus on Selectors going to last call [recorded in http://www.w3.org/2007/11/08-webapi-minutes.html#action04]

Network Communication

CMN: At risk, for lack of editing resources :(

DS: SVG took that stuff out of SVG spec, wants to make it a seperate spec

AE: Has been implemented and deployed.

DS: Strategy is to move forward with it seperately.

AE: SVG doesn't have an editor for their version either. Hoping to get one from Ikivo...

Window:

DS: Hixie eager to get that out of HTML spec, but needs active editor because there are dependencies.

DOM 3 Events

CMN: No apparent active editor.

DS: Have been working offline on this.

ACTION-236: Doug to chase up or otherwise obtain a spec for a Keyless D3E, and a seperate Key events spec. [recorded in http://www.w3.org/2007/11/08-webapi-minutes.html#action03]

DS: Problem for Key events is getting buy in from implementors (and that it is messy)
... plan is to bring together the people who have now promised to come together, and whoever else needs to be there, and make a spec (see above discussion in previous topic)

XHR

CMN: 2 specs (version one, version two), and on the agenda for tomorrow because AvK will be available then
The rest of the summary at http://www.w3.org/2006/webapi/ is still accurate now.

<jwatt> ScribeNick jwatt

Charter Discussion is Member Only. But yes, we intend to recharter.

Media object

DS: Media object was a spec that grew out of a need to access the native width and height of raster images in SVG. I looked at the problem and realized this could be a way of getting all types of metadata on various media. I made a generic API for accessing media properties. this exposes some of the most common as explicit properties

<ed> it's in the next to latest 1.2 full draft right?

DS: and adds an API to access the raw metadata format. it's metadata format independent

PL: HP sees that as a requirement

DS: I'd like to ask for first public WD so we can shop this around

ACTION-239: chaals to call for FPWD consensus on MediaObject [recorded in http://www.w3.org/2007/11/08-webapi-minutes.html#action08]

CMN: does anyone have any comments beyond shifting to WD

ED: I think it should mention SVG in width and height. might be a percentage. mention intrinsic size

DS: yeah

ED: says "natural width in pixels", doesn't say it's the intrinsic width

DS: I did some research, and there was a lot of confusion whether something was "intrinsic" or "natural". these are terms for raster images, something to do with pixel values or resolution or something

CMN: my limited understanding is that they mean the same thing

ED: duration doesn't mention SVG

DS: I do want to note that all of these properties are available on all objects. may return null if it doesn't make sense, e.g. audio might not have height. distinction between the referencing object and the intrinsic data. so object embedding audio might have height. regardless of whether the details are correct, there's general agreement that the methodology is good, so I'd like to move forward

ED: about buffering of multimedia, is that something you'd like to have in this spec, or is it covered by another

AE: media access gives you something

ED: it's not good enough? HTML5 has addressed some of this stuff

PL: for accessing the raw metadata, I'd suggest an array rather than a string since there may be multiple sources of metadata

ED: data about which timeranges are buffered, like an array...this is covered in HTML5

PL: I'd like to see some sort of query API, give it a string, get back a result to avoid having to parse the raw metadata

DS: get and set value. intermediate form, for extensibility. all reasonable

PL: guess there's a lot of outstanding issues regarding what it means to write to it

DS: may not be appropriate for all user agents

PL: not sure if it's appropriate in the spec, raises questions e.g. if you don't have write access to it

DS: one use case is if a user in a browser adds some metadata, they may be able to save that local copy to their HD with the new metadata, even if that data doesn't get sent back to the server

Planning for tomorrow

CMN: We will ask Jean Yves to call in at 11am (yay! sleep in or go to another group) for JSR/Progress and Element Traversal/whatever 2pm Anne will be here for XHR

<scribe> ACTION-240: Sunava try to get responses to email about XHR onto the public list - due tomorrow [recorded in http://www.w3.org/2007/11/08-webapi-minutes.html#action09]

MEETING ADJOURNED

Friday November 9

JSR-280 proposals

JYB: Goes through slides. JSR 280... We have some dependencies as listed. We are final release so we have made choices already.... 2 specs that raise issues, DOM 3 Core and Progress Events... DOM 3 - our developers cannot agree with Bjoern's answer. The rest are Progress event. For DOM 3- ISSUE-115 and ISSUE-116 - spec missing an amendment. And a new issue needs to be clarified. For progress, ISSUE-117 stalled event was suggested. We would suggest not to.

CMN: Agreed already. I am happy not to change the names of the attributes that are disputed, which means that for Progress all your proposals will be accepted.... for DOM 3 Core as far as I know there is no other group, and no apparent progress on the spec here. If you volunteer editing resources that would help us move forward.

XHR 1

http://www.w3.org/TR/2007/WD-XMLHttpRequest-20071026/

<sunava> as I discussed with Charles yesterday, IE will reply after today's discussions, since we'll have a better idea of the WG's plans here (this is the first time I'm meeting in person -:) )

AvK: Goes from WD to WD - people implement features and send feedback, and is more or less CR-ready I think. the implementation experience is leading to changes

SD: We have been providing feedback, two batches last year and we liked the spec then. The spec has evolved, and I sent a recent email with our objections to the current draft. We didn't mean to say it was too detailed, our concern is that XHR has been around for a long time, IEs implementation is what the bulk of people are using and we want version 1 to be in line with that. We are happy for it to evolve, in a versioned release. It's time

MJS: Who will document IE's behaviour?

SD: It is our responsibility to do that and I have now committed to that.

AvK: I have invested a lot of time in reverse-engineering. The only significant difference I know of is that the new spec has constants and is based on DOM events for the handling of onReadyStateChange and to align with DOM.

<Lachy> IE can implement a switch by differentiating between: new XMLHttpRequest(); and new ActiveXObject("XMLHTTP);

AvK: the new spec references the Window spec that is used to define what IE does to resolve URIs. IE uses ??? to resolve URI bases in iframes etc

SD: The spec depends on Window?

AvK: We could move the reference to HTML5

SD: HTML5 is not stable - is that a good reference for XHR which is an object of its own? I would not embed the references into the spec everywhere.

AvK: You need to define the behaviour

MJS: Referencing HTTP seems better than copying it into the spec.

SD: XML Parsing is not the only thing XHR does. Most people use it for text, so you could make it there at the bottom. is it a SHOULD or MUST?

MJS: It says if you support XML you MUST support XML parsing according to XML. If you don't support it, you can be a conforming non-XML implementation.

DS: Want to avoid pointless arguments.

DS: if IE doesn't support the constants yet, but changes to do so, it doesn't break existing content since they can use the non-constant references. There are things that you can change that don't break anything.

SD: Right. moving it forward would be nice in a versioned object.

CMN: My job is to look for consensus ... if somebody is proposing a change that doesn't break any existing content and doesn't cause pain to those people out there on the Web, [I don't think that an objection about something like that is going to carry]

<anne> http://tc.labs.opera.com/apis/XMLHttpRequest/ has the tests

TT: Are we targetting XML 1.0, 1.1 or both?

AvK: !.0 primarily

TT: That has a limited charset which is a problem.

MS: What does 1.1 do?

TT: 1.1 is open ended so you can use Unicode as it develops in future. So you can transmit characters you need to transmit.

AvK: Content will already work.

TT: No.

(discussion of whether 1.0 is limiting or not)

MJS: Don't think mandating XML 1.1 is appropriate...

AvK: XML Core group is talking about rescinding 1.1 and fixing 1.0

<anne> http://www.w3.org/TR/2006/REC-xml-20060816/#charsets

<mjs> my understanding is that this is the normative requirement: "Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 which is referenced here: http://www.w3.org/TR/REC-xml/#ISO10646 which says: (See http://www.iso.ch for the latest version.)

<scribe> ACTION-241: Chaals to chase i18n and XML to clarify whether XML 1.0 allows for extending legal characters [recorded in http://www.w3.org/2007/11/09-webapi-minutes.html#action02]

<anne> I also note that the main use case of XML 1.1 seems to be localization, not internationalization

SD: Who is going to maintain references etc

<anne> (with respect to tag names, etc.)

DS: The process requires certain things for us to progress, including assuring the stability of referenced documents. Window - is it dramatically changing or a stable part of HTML 5 spec?

MJS: Not changing in HTML 5. Probably best approach now is to copy/paste the relevant HTML 5 version and publish. Would not be a difficult exercise, Just A Matter Of Work.

DS: Is Microsoft most interested in getting XHR to recommendation?

SD: Indeed, modulo the need to address IE compatibility.

AvK: Depends on HTML5 for other reasons.

MJS: To progress XHR we need to factor out the bits of HTML 5 and get them along, or abstract the dependencies

SD: Sounds like we should be removing dependencies?

MJS: Those that are problematic. So dependencies are OK but we may need to work around ones that are holding us up.

SD: Think the spec should avoid dependencies and stand alone as much as possible.

MC: Yahoo's widget engine implements XHR. It is interlinked, but from an engineering perspective it should be contained.

TT: To the extent that you can, eliminating dependencies helps move along.

AvK: Without proposal for actual spec changes, this is nice philosophy but not that useful

MJS: So we should look at the actual dependencies and see if we can remove them 1 by 1.

DS: What dependencies are there?

[looking at the text to find out what the dependencies mean. Hixie and Anne, the two people who claimed to have really know everything, failed to agree on how to handle the dependency on Window so this discussion was terminated. Some comments are recorded below]

[[ meta argument about how much you have to have read to be allowed to use a spec, and whether that works in the real world ]]

MJS: [RFC2617] HTTP Authentication: Basic and Digest Access Authentication is probably not a useful spec since it describes cookie handling that is not the same as implementation of it - will send comment.

IH: You could remove the Window reference to informative

DS: How stable is Window in HTML 5

IH: There is little useful material to pull out...

TT: Should upgrade to handle latest language tags

AvK: This is just for the language headers - although maybe that should be upgraded.

<scribe> ACTION-242: Sunava provide technical comments from team - due in 3 weeks [recorded in http://www.w3.org/2007/11/09-webapi-minutes.html#action03]

XHR2

http://dev.w3.org/2006/webapi/XMLHttpRequest-2/

[short presentation from Anne - I will look for slides reference again later]

AvK: XHR2 has some extended functionality, but mostly is about integration with a spec from WAF that opens some holes for Cross site access.
... Cross site has GET (supposedcly safe, e.g. for image) and non-GET (not allowed generally)
... For GET you have a tag that says what requests are OK... solves the simple cases (XBL, XSLT, ...)
... for scary stuff like DELETE requests, you make an authorisation request, and then do what you do with GET to the response you get.
... authorisation uses a header Method-check added to GET requests.
... the authorisation can be cached, like common HTTP stuff
... The access control spec is not up to date, and XHR2 is not even FPWD yet

DS: How do you set up the context to use the access control with XHR2 request?

AvK: The user agent establishes it when it gets a request that wants to be cross-site.

SD: With X-domain we are changing the ancient laws of same-site-origin and we need to make sure the moon doesn't stop, and what teh security principles are. Do people have thoughts on what the security principles are?

MJS: Resource access across domains requires permission from both ends, should preferably be data not code.

MC: How does that relate to script?

MJS: The script element violates this. There are implications that are important but that has been done already. But it needs to be clearly pointed out that allowing transmisison of code is very very dangerous.

MC: So eradicating script element is a goal?

MJS: Don't think it is used for x-site communication

MC: Of course it is.

SD: Don't think it will ever get replaced - there are companies that make money swallowing your data who might not change their business model taht much.

AvK: Thisis opening new things not constraining existing things.

MJS: If you have open REST API you can write a desktop application or let a server talk to it, but a client-based app cannot now and there is no reason not to develop a good emchanism for that.

SD: We should not open a new attack surface by doing cross-domain e.g. making sure that you don't send a bare DELETE request that non-hardened servers would execute. There are some potential concerns identified by Mozilla and we should check those. Flash has something scary that we think is horribly insecure.

MJS: So from the flash example the lesson should be that the access control mechanism should be based on in-band communication.

AvK: The XHR Author cannot set stuff like u/name and password, and the like

SD: Microsoft has some experience in cross site stuff, and we will send some comments on things. We have a proposal - can we make that available?

CMN: Of course

SD: Similar, but there is an anonymous request, there is a handshake. Seperate cache to avoid cross-cache pollution

IH: You can already do that with iframe.

MJS: What about cached authentication?

SD: Our goal was to not increase, and in some cases decrease, attack surface. it is like a tightened version of what you have.

MJS: Would be interested in seeing teh security analysis that jsutifies the locking down

SD: Of course - we will send that with the basic spec. in current proposal you can only GET/POST. Looks here like we can expand that with the double request structure.

IH: We need cookies in the first request.

SD: What about a distributed attack?

IH: These are set by the settings that the user already has for that site - cannot set new ones.

<scribe> ACTION-243: Sunava to send security analysis and Microsoft proposal for cross site access. [recorded in http://www.w3.org/2007/11/09-webapi-minutes.html#action04]

SD: Like Doug Crockford's JSON proposal, modified. Should we change the name for v2?

DS: It was an idea

[bike shed discussion with a proposal from Microsoft for something like a proposal from Anne...]

IH: We need wildcarding in google...

AvK: You could live without it

IH: Yes, in principle...

key events and i18n

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

Hixie, Anne leave, i18n folks arrive

<Hixie> chaals: my opinion is that we must define the legacy charCode and... whatever the other one is called, as well as keyIdentifier, and that the first two must be defined as close to legacy implementations as possible

DS: The latest to accept the poisoned chalice of editing the keyboard events spec. The major problem is there is nothing about keycode/charcode in the spec. IME stuff, text input is non-existent/inadequate currently. The real problem is lack of implementation when these were specified

OH: Safari supports keyidentifier stuff. Problem is lack of keycode/charcode, and problems with keypress being essential to the web but b0rken

DS: ANother issue is order of events. Think OH and I have a reasonable approach for ordering events...

OH: Also working on improving cmpatibility with keycode/charcode

DS: Approach moving forward is to get input from right people. This is an issue we are trying to deal with as an ongoing taskforce including OMA, HTML browsers, SVG browsers, i18n, WAI, ...

RI: Who implemented key identifier?

OH: Safari/Webkit has most of this, but problems with stuff like windows key, cut/copy identifiers

AE: Bitflash has it, has mobile-specific keys like soft1/soft2, ...

DS: Ikivo too. The list of identifiers is non-exhaustive. There are some for mobile that are not there. Not all keys are on all players - how to deal when you don't have the key - remap it somehow or expect authors to do the right thing.

MJS: Remapping what the handler is bound to is not really feasible.

AP: So things like windows key won't ever trigger.

DS: We could specify that you can ignore them...

MJS: Major question. Are there keys that could be considered either same or different - e.g. should phone * be different to 101-key *? Would prefer that be no...

DS: There is a second attribute for location - mobile keypad, number pad, main keyboard etc. So you can decide how to treat them, and default to treating the same. Advise authors to specify keys such as soft1 AND f1 ...

RI: It is difficult to understand how this works - assume everyone understands as much as I do. For a serbian keyboard and key identifiers, if I hit q on US-101 I get an identifier associated with "Q". If I switch to french, I get "A" from the same key

OH: Yep...

<aphillip_> ? vs q vs. a

RI: If I change to Serbian, I will get "љ" or something, to find out which of those you are representing you need to look at the keyboard mapping - check the keypress and then look at what keys are available in the mapping

OH: The OS has to tell you what the character comes out, not the JS interpreter or browser.

RI: so when you interrogate the OS, how does it respond when you search for a key?

OH: Only know win/mac - the OS passes the key to the input manager that determines what the key is. This allows for complex things, when you get multiple-key input methods. On Windows the application tells windows when to convert the scan code for the key into an actual character. That should work on any platform. Problem is where you have multi-key input method stuff.

RI: Currently, it seems that OS gives a key code. How in KeyIdentifier do you get the information to say "please give me a serbian character"

MJS: Think that is not how OS X works.

OH: The keycode is a scan code for the keyboard. The user says I am on us-101 or fr-101 and the keycode is the same but the OS converts that to the actual key used

DS: Also, I map my caps lock to delete, so that is what is given.

TT: Might help to think of the keyboard as a grid...

MJS: You get phyiscal ID, logical ID, and the character that is supposed to mean (into the browser from the OS)

RI: KeyCodes give "q" and KeyIdentifier gives the actual character

DS: Keyidentifier is an abstaction layer

RI: So if you have an american keyboard you get "Q"?

OH: Depending on whether shift is held, you can get "Q" or "q"

RI: My understanding was the KeyIdentifier represents actual keys

AP: You get "shift" down, "Q", "shift" up with a modifier saying shift is held attached to the "Q"

RI: Without shift, I get "Q" as a keyidentifier and textinput of "q" if I just press the key alone

AE: That's what we do

OH: Yes, so do we.

RI: So if I change to serbian and press q I get an identifier for "(lower case serbian version)", not the upper case one that you get from US
... changes are much more dramatic on numbers in a non-ascii (e.g. french - how do you know what the 1/! key gives?

DS: Would suggest we unite this and say you get lower case

AP: The spec says upper case

RI: In arabic, where you get different letters on the key but there is no case? what is the key you get for د/ء?

TT: What about exposing the physical keys so you can describe the keys you get

RI: In bloglines S advances. On phone you can generate an S but with different scancode. With keyid you can run bloglines on a phone...

TT: There is something dependent on physical layout, and something that abstracts to character naming. Using naming conventions causes problems

AP: This is modeled on JS and Java

RI: Why does this cause problems?

TT: You don't know what you are generating...

AP: There are several levels of problem types. There is a health warning on key event saying look at text event not key event. So how can we provide something that maps to keyboards? With Java, some keyboards produce what you expect, some just keep sending english keycodes, but odd text event. So what do we want to tell people?

DS: Would it be a problem to change the mappings for keyidentifier?

OH:We return the unmodified name of the key - Q in US, different cases in Serbian depending on whether shift is held down. Could be an OS issue of depending on the modifier

TT: What would you do for the 2 euro keys?

OH: Would return the € id

TT: For both keys?

OH: Yes. We can add an identifier to say left or right €. You are adding info that applications cannot often, and should not, try to identify

TT: But if you want to play a game...

<Lachy_> what about on, say, the norwegian keybaord I have in front of me: Pressing E/Shift+E gives e/E (as usual), but AltGr+E types €. Should the keyidentifer return the same in all 3 cases?

OH: You can customise keyboard. It is not sane or safe to say you can rely on the layout of keyboards.

RI: We have a hybrid approach... coming back, the problem is where there are two characters for a key what do you choose? I hear Oliver saying there is one choice (in english), and that is the keyID, but that doesn't happen in serbian, nor in Arabic where there are different letters on the same key, e.g. د ء (they are different) depending on whether you shift. How do you ask for one or the other using keyID

OH: We return different things. My interpretation was to give a character in keyID, not looking at keycode/charcode because they are dependent on hardware and OS/software

CMN: For games, actual layout is important

OH: Games generally (and should) let you define the key controls - e.g. a chorded key setup.

DS: Games provide their own abstraction layer as a way of dealing with this - mostly to do with legacy keyboards. Are mobile keypads standard?

AE: Keypads are very standard where we have content - even if it is a virtual keypad you have the same.

OH: I think it is wrong for us to always send upper case character for unicode. Changing that may not be a compatibility problem since webkit/khtml are the only engines doing that.

AE: Isn't that from the spec?

DS: It says that, and gives a non-exhaustive list. I would say that sequence should be made informative

AP: and fixed if you want a different result

<shepazu> http://www.w3.org/TR/DOM-Level-3-Events/keyset.html#KeySet-Set

DS: There is a sequence in an appendix. I think mentioning capitals is difficult for implementors

RI: THink it mentions lower case ones, so that is odd when we look at what we have

OH: There are layouts that shift depending on modifier - e.g. dvorak/QWERTY

AP: Dead key sequences generate key events, but no characters

RI: But you wouldn't look for ñ

CMN: Why not since it is native on spanish

RI: It would be dangerous to rely on that being sensible to create

DS: Some of this relies on authors making sane choices

AP: What key code do you generate for a dead key?

DS: What do you think of tying keycode/charcode to key identifiers?

OH: It is very hard to make a sensible choice... keycode seems to match scan code, not something the user expects.

DS: Right

OH: I've been manually forcing special keycodes to match ctrl-alt etc - there are enough sites that assume it that you have to do so.

TT: There is an ISO spec for the 101-layout. There is a logic that everyone follows. In the hardware you get a code that follows that, and from it people are deriving stuff. If we move to a naming convention that follows the standard or something like that, we will number all the different kinds of keys and map them along to a text event. if someone varies from that it becomes clear that things change. This is how a universal remote works - it maps buttons to particular signals using this info

DS: The keyboards are different

TT: The ISO standards are pre-windows key

OH: Problem is that not everyone uses 101-keyboards.

TT: Right - so if you add a key you add an entry into the table of keys that exist.

DS: That should be at the OS

TT: Then you are tied to the OS

MJS: Browsers are based on teh OS - no device tie

TT: Then you can't match the controls :(

OH: But you can't anyway.

RI: With a DVORAK, don't press the top left to get "q"

TT: Then the character code comes out as "q" and the identifier is different

RI: There are some things you can identify, and there are some things that move around. So instead of tracking scan codes, we are tracking a nominal value for keys (not true text input, but something hybrid).

TT: This is just a naming convention

AE: So key identifiers would be numbers? That would make content creation really difficult. Content creators wont deal with u+0032 ...

MJS: You get to keycode/charcode. If there is something lower than keycode, there is no way to find out if that was odd. charcode gives the character, textinput gives you the actual text generated by your IME. What does keyID solve, or should we work on the existing ones?

RI: KeyID is for problems that arise with international keyboards.

OH: KeyID tells you about the composition event without having to rely on people looking for a specific sequence of events.

MJS: What it does for representing u0032 is worse than the charcode solution

AE: So maybe it makes sense only to deal with f1 key, etc.

RI: If you are serbian you have to figure out the latin version of the key for some serbian letter

MJS: My understanding is that charcode gives you the actual character that comes out.

RI: So you end up with a combination of keycode/charcode

DS: Which happens now

MJS: Is there a benefit?

hixie returns

OH: We could stop giving charcodes for "delete key" . KHTML gives "A" not u+0032

AP: Spec is unclear what you should get, there are few implementations, so it is hard to determine if it is an improvement or not. Keyevent is hard to program with, because you can fool it by changing your layout. Text events are very accurate...

<tex> ISO 9995 is the keyboard std.

MJS: They are not fed by the keyboard driver but by the input method

<tex> ISO/IEC 9995 (less formally "ISO 9995") is an ISO standard defining layouts of computer keyboards. It defines a keyboard as having three groups of key assignments:

<tex> Group 1 is the basic layer with a base and shift (lower and upper case)

<tex> Group 2 is the national layer with a base and shift. There is a locking shift to access this.

<tex> Group 3 allows for supplemental characters to be entered. This is a single plane and uses a non-locking shift.

<tex> Some keyboards in use are defined outside of this standard.

<tex> The ISO/IEC 9995 standard dates to 1994 and has undergone several updates over the years. It currently consists of the following parts:

<tex> ISO 9995-1:2006 General Principles Governing Keyboard Layouts

<tex> ISO 9995-2:2002 Alphanumeric Section

AP: keyboards produce erratic results as you change between them and that is challenging because tehre are a lot of models.

MJS: I think you want physica ID, logical ID, actual text generated. the existing methods do that except for some command keys. So we could plug that small hole instead of inveinting a new layer for everything

RI: As I understand that, keyID does that - keycode for function keys, charcode-type info for keys that change. But copes better with changing keyboards

MJS: Mixing sounds like a bad choice

RI: I thought so, but now I don't

MJS: Everyone has worked this way and I think it is brave to think we can invent a new one

RI: Problem is that it works fine in english, but falls down in international markets

TT: Some markets provide a service for downloading or changing keyboards. If you are generating events that would be confusing - give the physical event and give the system a chance to munge it.

OH: Think we should remove requirement to be a unicode description, and allow you to say "A".

RI: But problems would come from pgDn

AP: You wuld still have named keys, sothe question is what the name is - " " or u+0020?

MJS: Two issues. What do you call different keys, and Is mixing a la keyID the right approach to making it easier to deal with? I am not sure a priori whether keyID gives the text or the physical key?

AP: you get the problem that textinput is not implemented

IH: But ditto for keyID

AE: In SVG having key names was useful for svg:accesskey so you could use a string name

MJS: Having string names seems good. Do we need to idenitfy a third list of names since we already have to support two (plus textInput)?

DS: So you think we should identify the list of named keys?

MJS: Suggesting have keyCode/Charcode, and get string names for keys that aren't a character. Then figure out what to do - charcode is "delete", or there is a prperty that says "magic key", etc...

tex leaves

RI: To decide if that is a good approach we should ask the people who invented them and ask why they did it

<r12a> http://people.w3.org/rishida/utils/keyevents/

RI: when you are in non-latin keyboards there are things that do not return anything (well, 0)

MJS: So those things need a more useful identifier, may be impossible at OS to get a useful identifier.

RI: tended to be things like [ that is å in norwegian

<aphillip_> http://lists.w3.org/Archives/Member/member-i18n-core/2007Aug/0004.html

[discussion of what keys return which codes zhen you swap keyboqrds]

MJS: If you switch keyboards, it tries to generate the same events for the same keys.

RI: Only does that for latin keyboards

IH: Not surprising since there is no particular label for serbian etc.

DS: None of this solves physical location

MJS: Don't think that can be done. think the critical thing is human-comprehensible names for command/modifier keys.

DS: So the list there is a good start?

AP: There is a good start, but things that don't belong

MJS: Think we should reverse-engineer what keycode/charcode do already, and then figure out what is missing and how to add it.

<jwatt> you need to know the function of the key. knowing the actual physical location is not necessarily possible and should not be relevant.

RI: That means rewriting the whole appendix

DS: That is essentially what we figured we probably have to do.

AE: The issue is that we are close to exiting and sounds like that could lead to changes in content.

DS: We could publish as is, say "this sucks but now we will deal with it"

MJS: I would prefer to delete than pulish rubbish. Would like us to plan to spec key events because it is significant and important.

FS: Clarification - main goal is to work with input methods?

[no, we haven't got that far yet]

DS: That is part of the goal.

CMN: We need to remain basically compatible, and then look at how much we can fix. I would rather get good implementation of what we have than start another round of trying to fix something unimplemented... where possible

AE: There are also things like JSR-287. referring to the existing specs.

AP: We need to scope. If the right thing to do is a total rewrite, we could break off. If that is not what we need to do, we can proceed to give a schedule.

<Lachy_> indeed. splitting the keyboard stuff out makes a lot of sense right now

CMN: Think that we can still split, and would prefer to do that since the rest of it seems a lot more mature and reliable, and we can make it go forward maybe faster (as various groups have been crying out for)

AP: I am worried about splitting it out and going to square one again.

RI: There is a plan to develop stuff in the spec.

<r12a> ie. the keycode and charcode stuff

FS: Which mentions the possibility of splitting that out.

<fsasaki> "(This part of the specification is likely to be moved to a separate specification on keyboard events.)" from http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset

CMN: So should we start with KeyCode/Charcode, or a different design?

AE: There are people relying on KeyID - e.g. in mobile world. So changing that will cause further problems.

OH: The bugs I have seen are not about looking for a particular physical location, just making false assumptions about the how the layout says where get a character.

DS: There are people wanting to get WASZ keys because of their layout on the keyboard.

[discussion of the best way to deal with this...]