| 04:03 | <mortrca> | I would like to see an api developed that would allow for pages to capture events for non-standard keyboard buttons such as the play/pause/next/previous and other media control buttons that many keyboards have. |
| 04:04 | <mortrca> | Is there a reliable way for me to determine if this suggestion has been made in the past? |
| 05:25 | <kochi> | MikeSmith: yt? |
| 05:31 | <MikeSmith> | kochi: here |
| 05:34 | <kochi> | Hi Mike! |
| 05:34 | <kochi> | I read the F2F minutes of IME API part, and there was a discussion about its accessibility issue. |
| 05:36 | <kochi> | I understand there are strong oppositions for implementing an editor in <canvas> |
| 05:36 | <MikeSmith> | kochi: yep |
| 05:37 | <kochi> | but I think we shouldn't prevent those who want to do so from implementing, by restricting API |
| 05:37 | <kochi> | probably presenting such an example in the API doc isn't a good thing. |
| 05:39 | <MikeSmith> | kochi: yeah, I think part of it is just, that canvas example is quite prominent |
| 05:39 | <MikeSmith> | the spec would still be fine without that example |
| 05:40 | <MikeSmith> | so it might just be a matter of dropping that example |
| 05:40 | <MikeSmith> | you could still keep the hooks in the API |
| 05:40 | <kochi> | Ok, I feel that the example made readers have impression that "implementing editor in <canvas>" is the primary goal to achieve by the IME API |
| 05:40 | <MikeSmith> | right |
| 05:41 | <kochi> | Ok, I'll consider dropping it. Maybe coming up another good example would be better. |
| 05:41 | <kochi> | Also I got a very detailed (even updated) API doc from Microsoft |
| 05:42 | <kochi> | which was very awesome |
| 05:42 | <kochi> | but I have a fundamental question: can we mix CSS feature in the IME API spec? |
| 05:43 | <kochi> | their proposal included CSS properties like 'ime-mode'. |
| 05:43 | <kochi> | I think it makes sense to have all IME related features in one spec rather than distributed in HTML, DOM and CSS |
| 05:48 | <kochi> | It makes sense if the spec is used as a reference, it would be convenient to have all related information in one place, but if another authoritative CSS spec is updated, there may be discrepancy and doubles the updating effort for one thing. |
| 08:47 | <Hixie> | cabanier: i'd be fine with making fonts support CORS if browsers want to implement that. the canvas spec is blind to that, it just uses the font's origin. |
| 09:48 | <annevk> | http://www.w3.org/2001/tag/doc/mime-respect |
| 09:52 | <Ms2ger> | 2001? |
| 10:05 | <annevk> | I wonder if the TAG was responsible for the idea that there's no meaning inherit to the URL. Might be about time to obsolete that... |
| 13:15 | <annevk> | http://lists.w3.org/Archives/Public/www-style/2013Apr/0641.html seems like overkill for what mostly comes down to string equality operations... Am I missing something? |
| 13:15 | <annevk> | TabAtkins_: ^^ |
| 13:16 | <zewt> | D: |
| 13:17 | <zewt> | he started with two RFCs, that's always a recipe for massive overcomplexity |
| 13:17 | <Redface> | hi :) |
| 13:19 | <zewt> | annevk: better to be able to compare arbitrary attributes, have a really simple comparison, then if the comparison doesn't match your site, use the sort key approach and add another attribute just for the comparison |
| 13:20 | <annevk> | zewt: not sure what you mean |
| 13:21 | <zewt> | though at that point i guess you may as well just use a class and skip the whole thing |
| 13:21 | <zewt> | <a href="http://weird.url"; data-foo="http://simplified.url">; |
| 15:09 | <GPHemsley> | Hixie: Should I let you sort out any proposed change to the meta name list/ |
| 15:09 | <GPHemsley> | ? |
| 15:18 | <annevk> | GPHemsley: what do you mean? |
| 15:38 | <annevk> | TabAtkins_: Keven's argument is that JavaScript's modules follow the same semantics as CSS' @import by default but can be overridden |
| 15:38 | <annevk> | Kevin* |
| 15:38 | <TabAtkins_> | I understand his argument, but it's still wrong. Also, CSS's @import is not a great model to be emulated. |
| 15:39 | <TabAtkins_> | He's attaching way too importance to the concept of a central naming authoring. (This seems to be a common failure mode among people who like namespaces - they fetishize non-collision, even when it's perfectly reasonable to allow and manage collisions). |
| 15:40 | <annevk> | TabAtkins_: the default loader resolving against the document's URL combined with appending ".js" to the end seems silly though |
| 15:40 | <annevk> | TabAtkins_: @import semantics as default seems saner |
| 15:41 | <TabAtkins_> | Where relative links are resolved against the stylesheet's url? |
| 15:41 | <GPHemsley> | annevk: Most of the requests for wiki accounts nowadays are for people wanting to add entries to the Meta Extensions list |
| 15:43 | <annevk> | TabAtkins_: ah yeah, in JavaScript you might use the script's url I suppose, given it's a syntactic construct you can do that |
| 15:43 | <annevk> | GPHemsley: ah okay, that seems fine |
| 15:43 | <GPHemsley> | annevk: which? |
| 15:44 | <annevk> | GPHemsley: people adding entries to the list |
| 15:44 | <TabAtkins_> | Problematic, though - it means that when you move code from a <script> block to a separate stylesheet, you need to change the url. Also, CSS's relative-link-resolution semantics are convenient *sometimes*, when getting resources which are situated near the stylesheet, but very frustrating when trying to link together resources in disparate locations. |
| 15:44 | <TabAtkins_> | (I want to add a doc() or doc-url() function that's identical to url(), but resolves against the document's base url instead.) |
| 15:47 | <annevk> | don't do base, but just the doc's URL |
| 15:47 | <annevk> | well, actually... |
| 15:47 | <TabAtkins_> | Riht, sorry, slip of fingers. |
| 15:47 | <SimonSapin> | annevk: is that not the same? |
| 15:47 | <annevk> | SimonSapin: no |
| 15:48 | <SimonSapin> | maybe with <base>? |
| 15:48 | <annevk> | TabAtkins_: it still seems better than append ".js" and then fetch it... |
| 15:48 | <TabAtkins_> | annevk: Doesn't seem too bad to me. ^_^ |
| 15:49 | <annevk> | any other place that takes something that looks like a URL does not do that, but it's okay if JavaScript has it for modules? |
| 15:50 | <annevk> | o_O |
| 15:50 | <TabAtkins_> | It makes the module syntax look a lot like other language's module syntax, which is nice! |
| 15:58 | <TabAtkins_> | annevk: Regarding the url matching, I think David Sheets should be ignored. Yes, URL matching is technically a pattern matching operation, but the patterns are non-trivial to author yourself, and we can offer much better. |
| 15:58 | <TabAtkins_> | Also, as he says himself, it's not able to express the :local-link() semantics. ^_^ |
| 16:00 | <TabAtkins_> | I agree that it does offer a more powerful model in total, but I don't think it's worth it for giving up the simplicity of common cases. |
| 16:05 | <annevk> | It's a mismatch with the architecture we have today. |
| 16:05 | <dglazkov> | good morning, Whatwg! |
| 16:08 | <MikeSmith> | good morning, Web Components |
| 16:08 | <MikeSmith> | WebKit doesn't like you any more |
| 16:09 | <MikeSmith> | but we still do |
| 16:09 | <Ms2ger> | We do? |
| 16:10 | <nimbu> | ahahahahhaha |
| 16:10 | <nimbu> | Ms2ger is hilarious |
| 16:10 | <Ms2ger> | I am? |
| 16:14 | <nimbu> | VERY FUNNY! |
| 17:04 | <til> | dglazkov: can you please register appsforartists on the wiki for me |
| 17:05 | <til> | i'd like to add a link to the webgl settings object that getContext('2d') is mirroring |
| 17:05 | <til> | http://www.khronos.org/registry/webgl/specs/latest/#5.2 |
| 17:07 | <cabanier> | hixie: so this line should be taken out then: "using a font that has an http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin that is not the http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#same-origin as that of the http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document object ….then the method must throw a http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastruc |
| 17:10 | <til> | (CanvasOpage) |
| 17:10 | <til> | Opaque |
| 17:15 | <dglazkov> | til: could you be asking the wrong guy? I have no idea what you're asking for :) |
| 17:16 | <til> | you're listed here |
| 17:16 | <til> | http://wiki.whatwg.org/wiki/Special:ListUsers%26group%3Dautoconfirmed |
| 17:16 | <til> | there's a big banner for non-logged-in users that says if you want to make an edit, run it by one of these guys |
| 17:17 | <til> | you were listed there. weird. |
| 17:17 | <dglazkov> | til: I guess I am no longer important :) |
| 17:18 | <til> | you're always important |
| 17:18 | <til> | Hixie: can you please make me an account at appsforartists on the wiki |
| 17:19 | <til> | i want to link the CanvasOpaque proposal to the WebGL settings object it's implementing |
| 17:20 | <MikeSmith> | til: I can set it up, I think |
| 17:21 | <til> | hooray MikeSmith |
| 17:21 | <til> | :) |
| 18:57 | <gsnedders> | Anyone here with the parser swapped in? |
| 19:09 | <gsnedders> | (If anyone does, can you help check whether <button><p><button> goes into an infinite loop per spec?) |
| 19:12 | <jsbell> | is boris zbarsky around? I can't recall his IRC nick. bzed perhaps? |
| 19:13 | <jsbell> | hrm, seems to be bz, so guess not |
| 19:14 | <gsnedders> | I don't think he's ever in here. |
| 19:21 | <MikeSmith> | jsbell: try #developers on irc.mozilla.org |
| 19:21 | <MikeSmith> | nick is just "bz" |
| 19:23 | <jsbell> | I'll just email, not urgent. :) |
| 19:23 | <jsbell> | thanks tho! |
| 19:24 | <gsnedders> | I am fairly certain html5lib is hitting another infinite loop per spec. |
| 19:24 | <gsnedders> | This is… nice. |
| 19:32 | <gsnedders> | Oh, no, it's just a bug in html5lib. |
| 19:34 | <jgraham_> | Seems more likely |
| 19:34 | <jgraham> | wilhelm: Is this power adapter yours? |
| 19:44 | <gsnedders> | jgraham: Do you want to set up critic for html5lib-tests? |
| 20:09 | <jgraham> | gsnedders: Sure, can do |
| 20:10 | <jgraham> | Although the thought of making the API calls is making me feel tired now. In the morning I think |
| 20:24 | <jgraham> | gsnedders: You can have some review for the patch instead |
| 20:24 | <jgraham> | I didn't merge, in case you want to |
| 20:25 | <Hixie> | cabanier: why? |
| 20:25 | <Hixie> | cabanier: if we take that out it'd be a security hole... |
| 21:51 | <cabanier> | Hixie: why is it a security hole? |
| 22:05 | <TabAtkins_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2237 |
| 22:05 | <TabAtkins_> | Whoops, wrong channel. |