See also: IRC log
RRSAgent: this meeting spans midnight
RRSAgent: make logs public
<masayuki> Hello.
masayuki: welcome!
Gary and I worked a little this past week on some of the bugs, and got down to 7 last night :-)
<scribe> scribe: travis
<scribe> scribenick: travis
First bug we'd like to talk about is: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25485
This bug concerns the overlap between DOM L3 and DOM4's definition of the eventing system (model)
<garykac> If we remove the stuff covered in DOM4, then we remove Sections 3 and 4 (and a lot of glossary items)
<garykac> Before doing that, we'd need to check with them and run a check to make sure that we don't have anything that should be added to their spec.
I'm not married to any of the content in those old sections; it might be best for the web community to only have a single source of info for the 'official' definition of how the event model works.
<garykac> We (D3E) would probably keep all the deprecated stuff in the appendices (unfortunately).
Gary and I reviewed the DOM4 spec briefly and it looks fairly complete, though we want to double-check.
<garykac> travis: agreed
<garykac> We should compose an email and send it to the list
<garykac> Should we try to compose a draft here?
I think the essense of the draft will be what we think are the duplicated parts, and a proposal of how the spec would look without them?
<garykac> We should also call attention to the spec dependency graph: HTML5 -> D3E -> DOM4 (since we would now depend on DOM4)
Yes, it seems a little odd conceptually, but might be OK given everyone's understanding of how this stuff happened historically.
If we don't eliminate the redundancy, then we need to be certain that our spec and DOM4 are semantically equivalent.
(We use prose descriptions, DOM4 uses algorithms--a little hard to rationalize the difference, but it can be done.)
<garykac> https://docs.google.com/document/d/1VqwfHyNDtoOoDzZZ7xZlrcxtcy8ZORV1pUoRjRbwJro/edit
<garykac> OK. The doc looks like a first draft
<garykac> We should sleep on it and review tomorrow-ish and then send it out to the MLs.
<garykac> masayuki: Did you see the update to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23908
<garykac> We'd like to have a more accurate description than "default keyboard layout" since we're not sure that it defaults to US.
<masayuki_> garykac: Yeah, but I don't know the answer of the last question, though.
<masayuki_> On Mac, "current ASCII capable keyboard layout" is the last selected ASCII capable keyboard layout.
<garykac> "last selected" - ick
Very interesting.
<garykac> I doubt that's something that is consistent cross-platform
<masayuki_> On Windows, we can just ignore Kana-Lock state for Japanese. I'm not sure about Korean and Chinese.
scribe: and when there is no previously selected ASCII capable keyboard layout, then there needs to be a fallback, right?
<masayuki_> Travis: I guess that the first ASCII capable keyboard layout in the keyboard layout list is used.
<garykac> I wonder what it would do if the "last seleced" keyboard layout didn't support the key being pressed (eg: last keyboard = US; key pressed = UK backslash)
<garykac> (or the 'ro' key on a Japanese keyboard)
<garykac> (ろ)
<masayuki_> Good point. However, US keyboard layout on Mac is a special keyboard layout. It changes input character by physical keyboard type!
<masayuki_> E.g., "Quote" key inputs : with JIS keyboard but ' with ANSI keyboard, :-(
<masayuki_> Like that, "IntlRo" key inputs \.
Gary and I are inclined to leave the current text there (it was our best effort given what we know) and are welcome to improve the text as new information comes available.
<masayuki_> Anyway, if D3E spec defines keydown and keyup shouldn't be fired during composition, this issue may be WONTFIX.
It does matter during Ctrl/Meta key combinations though.
<garykac> These key combinations will occur outside of composition sessions
Despite this, I'd still like to resolve the bug "fixed" for now.
<garykac> I think that it's as Fixed as we're likely to get it in the near future.
<garykac> If it is an issue, we can revisit in UI Events
<masayuki_> We don't need to worry about Meta key. On Mac, during pressing Meta key causes ASCII capable keyboard's character is passed by NSEvent.
<masayuki_> I.e., browsers should just honor the OS's event.
<garykac> I'm hoping that in all these cases, the browser can simply return what the OS provides.
Yep, that would be great.
<garykac> I don't want them to create goofy mapping tables to fix this problem.
(We just wanted to try and write that into the spec, but it baffled us a bit...)
<masayuki_> Pressing Ctrl key causes a control character code (< 0x20) on all OSes.
Ctrl+[some character] uses the ASCII capable layout though--that's what we were comparing to Meta.
<masayuki_> Travis: yes. I think that browsers should use same character as native application's shortcut key handling.
Agree.
<garykac> sgtm
We are out of time
<garykac> same time/place next week
Yep. Hopefully with only 1 or 2 bugs left!
Thanks all!
<masayuki_> Even with Kana is locked on Windows, Ctrl + ASCII character shortcut work fine on Windows.
<masayuki_> Thanks!
RRSAgent: please generate the mintues
RRSAgent: please make the minutes
RRSAgent: make logs public
RRSAgent: make the minutes
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: travis Inferring ScribeNick: Travis Found ScribeNick: travis Default Present: [Microsoft], +1.425.936.aaaa, garykac Present: [Microsoft] +1.425.936.aaaa garykac Travis WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 14 May 2014 Guessing minutes URL: http://www.w3.org/2014/05/14-webapps-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]