| 08:35 | <zcorpan> | test |
| 11:49 | <zcorpan> | SimonSapin: i'll assign you the responsibility for this offsetParent gecko bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=15430#c11 :-) |
| 12:27 | <jgraham> | krijnh: krijn: Can you rejoin #testing on the W3C server, please? |
| 13:21 | <zcorpan> | does someone care about https://www.w3.org/Bugs/Public/show_bug.cgi?id=23173 ? |
| 13:27 | <SimonSapin> | zcorpan: ? |
| 13:30 | <annevk> | zcorpan: ID lookup within a subtree should work |
| 13:30 | <annevk> | zcorpan: browsers could always resort to the selector slow path |
| 13:30 | <annevk> | "slow" |
| 13:31 | <zcorpan> | annevk: yeah |
| 13:32 | <zcorpan> | SimonSapin: i found a gecko bug in that comment. i care enough to bring it to your attention, but i don't care enough to file the bug myself. :-P |
| 13:33 | <zcorpan> | SimonSapin: (i just picked you at random) |
| 13:59 | SimonSapin | sighs |
| 14:32 | <darobin> | TabAtkins: have you considered using specref for bikeshed? |
| 15:38 | <rniwa> | slightlyoff: yt? |
| 15:39 | <rniwa> | arv: ? |
| 16:16 | <jgraham> | zcorpan: Do you know the requirements for pywebsockets in web-platform-tests offhand? Which port(s) should it run on? |
| 16:16 | <jgraham> | If it has to be the same as the HTTP server, I guess I have a slight problem to solve |
| 16:36 | <jgraham> | So, it looks like hopefully not |
| 16:36 | <jgraham> | Although |
| 16:36 | <jgraham> | I suspect those are the Jetty ones |
| 16:36 | <jgraham> | :} |
| 16:36 | <jgraham> | | |
| 16:37 | <jgraham> | Oh, that was return, not backspace |
| 16:38 | <jgraham> | These jetty tests are going to have to die |
| 16:38 | <jgraham> | Art won't like me :( |
| 16:59 | <TabAtkins> | darobin: I'm planning to add in specref support, yeah. It's kinda tricky, since specref links are untyped. |
| 17:05 | <zcorpan> | jgraham: the port is configurable in a single .js file iirc |
| 17:05 | <zcorpan> | at least for the opera tests |
| 17:15 | <TabAtkins> | zcorpan, hsivonen: That CSS wiki page is outdated. The CSSWG adopted better policies in line with Blink and Firefox's current behavior. |
| 17:46 | <dglazkov> | good morning, Whatwg! |
| 17:52 | <marcosc_> | dglazkov: can Web components interact with the browser's preloader? |
| 17:53 | <marcosc_> | dglazkov: for instance, we want to make a <x-picture> thing that wraps img tags. But we want the images to load like they were inlined in the markup. |
| 18:07 | <joelcox> | Hey everyone. |
| 18:09 | <joelcox> | I'm new at this, so I'm trying to follow http://wiki.whatwg.org/wiki/What_you_can_do as close as possible and wrote up a user-centric description of a problem, namely allowing browsers to bind to multimedia buttons. |
| 18:09 | <joelcox> | I wrote it up in a Gist. Any feedback is much appreciated. - https://gist.github.com/joelcox/6641424 |
| 18:16 | <arv> | rniwa: Do you still have a question for me? |
| 18:24 | <rniwa_> | arv: yeah |
| 18:24 | <rniwa_> | arv: have you looked into IndieUI spec? |
| 18:24 | <rniwa_> | arv: https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html |
| 18:25 | <rniwa_> | arv: it defines a whole bunch of things to expose JS-defined UI behaviors |
| 18:25 | <arv> | rniwa_: nope... looking now |
| 18:31 | <rniwa_> | arv: it looks very similar to command stuff in html5 and editing commands |
| 18:31 | <arv> | rniwa_: yeah, that was my first thought too |
| 18:31 | <arv> | rniwa_: The only thing that this brings to the table afaict is the predefined list of commands/actions |
| 18:32 | <arv> | rniwa_: it is trivial to polyfill which is a good thing |
| 18:39 | <arv> | rniwa_: The list of actions is a bit thin |
| 18:40 | <rniwa_> | arv: yeah |
| 18:40 | <arv> | rniwa_: Just looking at random UI toolkit will give you a large list of common actions |
| 18:41 | <arv> | rniwa_: (no place to file bugs but here is one such random list: http://msdn.microsoft.com/en-us/library/System.Windows.Input.ApplicationCommands_properties.aspx) |
| 18:48 | <Domenic_> | joelcox: this is a good thing to work on, +1. I think there is already some work in DOM3 events to make those keys exposed with standard key codes though |
| 18:49 | <Domenic_> | joelcox: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent?redirectlocale=en-US&redirectslug=DOM%2FKeyboardEvent#Key_names_and_Char_values search for MEDIA_ |
| 18:51 | <joelcox> | Good to hear Domenic_. I'll add that to the document :) |
| 18:51 | <annevk> | joelcox: I recommend asking on www-dom⊙wo |
| 18:51 | <annevk> | joelcox: work on UI Events is mostly there |
| 18:52 | <rniwa_> | arv: i wonder if we should be discussing it in WebApps instead |
| 18:52 | <zewt> | dom3 events key stuff is a mystery to me |
| 18:52 | <rniwa_> | arv: it seems like a bunch of stuff in here can get annevk's help |
| 18:52 | <rniwa_> | arv: like all the enums :/ |
| 18:53 | <rniwa_> | annevk: ^ |
| 18:53 | <zewt> | like, talking about a ton of totally device-specific buttons |
| 18:53 | <annevk> | rniwa_: the IndieUI stuff? |
| 18:53 | <rniwa_> | annevk: yeah |
| 18:54 | <Domenic_> | aren't enums supposed to be lowercase these days? |
| 18:54 | <Domenic_> | no idea what you do for multi-word values though (camelCase?) |
| 18:55 | <rniwa_> | Domenic_: there shouldn't be any enums. |
| 18:57 | <arv> | Domenic_, rniwa_: The question regarding multi word is still valid |
| 18:57 | <annevk> | String enumerations are fine, but yeah, convention is lowercase. |
| 18:58 | <Domenic_> | (it's *non*-string enums that are evil...) |
| 18:58 | <annevk> | With String.prototype.normalize() as notable exception... |
| 18:58 | <Domenic_> | meh, I thought Norbert's argument for that was reasonable |
| 18:58 | <Domenic_> | they're like standard acronyms from other documents or similar, not words |
| 18:59 | <joelcox> | annevk: Thanks for the suggestion, will look into the proper procedures to do that. |
| 18:59 | <annevk> | We use "arraybuffer" in XMLHttpRequest |
| 18:59 | <zewt> | (err, acronyms are words) |
| 19:00 | <annevk> | joelcox: see http://lists.w3.org/Archives/Public/www-dom/ for instructions of subscribing |
| 19:00 | <annevk> | joelcox: there's no procedures for posting other than sending email |
| 19:00 | <joelcox> | annevk: Ah ok, thanks. |
| 19:16 | <rniwa_> | arv, annevk: so palettefocus/toolbarfocus requests for example are trying to solve the problem of |
| 19:16 | <rniwa_> | creating a document editor |
| 19:16 | <rniwa_> | where we don't currently have a way of focusing on a toolbar/palette button without clearing focus/selection on the main document view |
| 19:16 | <rniwa_> | there are a whole bunch of other things this spec tries to address |
| 19:17 | <rniwa_> | sicking: hi sicking! |
| 19:17 | <annevk> | rniwa_: it seems kinda premature to solve those things without fixing the architecture layer |
| 19:17 | <rniwa_> | annevk: yeah |
| 19:17 | <rniwa_> | annevk: I think we need to fix the architecture |
| 19:18 | <annevk> | rniwa_: but then I said that too when they added ARAI rather than getting to a place where <input> et al were fixed and it seems ARIA happened and the latter is still not done... |
| 19:18 | <annevk> | rniwa_: the hard problems are left unsolved and paved over by hacks or some such |
| 19:18 | <rniwa> | annevk: web component model might be replacing ARAI to some extent but yeah. |
| 19:18 | <zewt> | bandaiding problems seems to have a way of ensuring real fixes never happen |
| 19:19 | <rniwa> | annevk: we should fix the problem now before we add this accessibility feature to the Web |
| 19:19 | <annevk> | I wish I had more bandwidth |
| 19:19 | <rniwa> | annevk: haha, you need to recruit! |
| 19:59 | <dglazkov> | marcosc_: we probably should get on the same page terminology-wise :) What's a browser preloader? And what do you mean by "inlined in the markup"? |
| 20:12 | <marcosc_> | dglazkov: sorry, back... |
| 20:13 | <dglazkov> | marcosc_: np. There's also a twitter convo |
| 20:13 | <marcosc_> | dglazkov: I'll take a look |
| 20:13 | <dglazkov> | marcosc_: it's all very confusing. |
| 20:14 | <marcosc_> | dglazkov: I'll try to find some code examples... it's pretty simple once you see it |
| 20:15 | <marcosc_> | dglazkov: take a look at this markup pattern: https://github.com/scottjehl/picturefill#markup-pattern-and-explanation |
| 20:15 | <marcosc_> | we basically want to replicate that as a web component |
| 20:16 | <marcosc_> | the problem with the markup pattern is that images are not loaded until _after_ DOMContentLoaded |
| 20:17 | <marcosc_> | What we want to do is make a <x-picture> element, that would ideally work the same as <img> (the browser loads images as it finds them in markup ) |
| 20:19 | <dglazkov> | marcosc_: you can do slightly better with custom elements. Basically, you're tied to the createdCallback timing, which will be at the microtask checkpoint. The createdCallback is what will create a shadow tree for <x-picture> |
| 20:20 | <marcosc_> | dglazkov: ok, I'll investigate that |
| 20:21 | marcosc_ | runs off to have dinner |
| 21:04 | <zcorpan> | i wonder if people would have a different opinion on critic if it didn't have "opera" in the name |
| 21:11 | <zcorpan> | hmm. i enabled review.dropAnyReview but the button doesn't show |
| 21:13 | <joelcox> | Domenic_: Just send an email to www-dom like you and anne suggested, thanks again. |
| 21:35 | <zcorpan> | jgraham: ping https://critic.hoppipolla.co.uk/r/9 |
| 21:38 | <zcorpan> | web-platform-tests has a sad number of open PRs, and some can't be automatically merged anymore |
| 21:42 | <zewt> | nothing discourages me from contributing to something more than sending a patch and nothing happening, heh |
| 21:54 | <zcorpan> | yeah :-( |
| 22:27 | <zcorpan> | marcosc: you can use <img is="x-picture"> or some such i think |
| 22:27 | <marcosc> | zcorpan: thanks for the tip |
| 22:28 | <marcosc> | still a Web Components noob |
| 22:36 | <zcorpan> | marcosc: so by 'preloader' i thought you meant the speculative scanner. but i guess you don't want the browser to fetch anything, you want to run some JS "asap" when the element is parsed, right? |
| 22:45 | zcorpan | wonders if the web legacy has already poisoned <picture> such that a native impl would break the web |
| 22:45 | <zcorpan> | e.g. http://www.vogue.es/ |
| 22:47 | <zcorpan> | heh, http://24ways.org/ escaping angle brackets is hard, let's go shopping |
| 22:48 | <marcosc> | :) |
| 22:48 | <marcosc> | heh |
| 22:48 | <marcosc> | our <picture>-perfect response |
| 22:49 | <marcosc> | zcorpan: you looking at the latest webdevdata? |
| 22:49 | <marcosc> | I don't think it's too late... we've been telling people not to use it |
| 22:49 | <marcosc> | Anyway, wish I could stay and chat, but I gotta pack :( |
| 22:50 | <zcorpan> | webdevdata yeah |
| 22:50 | <marcosc> | zcorpan: if you can, can you paste in some of the searches you are doing as examples into the GH repo for that |
| 22:50 | <marcosc> | there is an open bug |
| 22:51 | <marcosc> | we are collecting examples to create better docs |
| 22:51 | <marcosc> | for how to grep the data |
| 22:51 | <marcosc> | etc |
| 22:51 | <marcosc> | grepping is actauly hard... even if you go shoppin |
| 22:53 | <zcorpan> | hf365.com uses <picture><img ...></picture>. cato.org showed up but doesn't seem to use <picture> anymore |
| 22:53 | <zcorpan> | i just did grep -rIE "<picture(\s|>)" . |
| 22:55 | <zcorpan> | so now i just found one site that would break, that seems OK |
| 23:00 | <zcorpan> | well, depending on how it gets defined... not showing fallback if no <source> matches would break hf365.com |
| 23:43 | <dreamdust> | Is there a way to find out the history of a given tag in the html spec? For example, *who* is the person who decided that <header> should be added to the spec. |
| 23:44 | <dreamdust> | I assume I have to grep archives of the mailing list? |
| 23:48 | <TabAtkins> | Asking here often works. For example, <header> was added by Hixie, along with the other sectioning elements, due to research on common class names using the Google corpus. |
| 23:51 | <dreamdust> | Is there any criteria for why a tag is added, or is it pretty much "we talk about it and decide to add tags." Seems like adding tags based on common class names is… arbitrary to put it nicely. |
| 23:55 | <TabAtkins> | The research was for common landmark class names. If a large percentage of the internet uses <div class="header">, that suggests that a <header> element would be useful for cleaning up that code. |
| 23:56 | <Philip`> | TabAtkins: It was added because of that, but then it was renamed to <hgroup>, so that doesn't explan the current <header>, as far as I'm awae |
| 23:56 | <Philip`> | *aware |
| 23:56 | <TabAtkins> | Philip`: Hm? Iirc, <header> has always been <header>. |
| 23:57 | <Philip`> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-April/019538.html - "I've renamed the old <header> to <hgroup>." |
| 23:57 | <Philip`> | coincident with http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2009/002212.html - "Introduce a new <header> element." |
| 23:57 | <TabAtkins> | Huh, all right. |
| 23:59 | <Philip`> | dreamdust: What method would be less arbitrary than doing research into current practices and extending the language to more naturally express those practices? |