04:15 | <annevk> | rafaelw: I updated the bug, fwiw |
04:18 | <annevk> | http://kenneth.io/blog/2013/07/15/the-messy-state-of-web-notifications-in-chrome-safari-blink-webkit/ seems fucked |
06:09 | <matjas> | is http://bugzilla.validator.nu/ timing out for anyone else? |
06:15 | <MikeSmith> | matjas: yeah |
06:17 | <MikeSmith> | hsivonen_ has an ongoing issue with load on that server |
06:18 | <MikeSmith> | lately it's made that bugzilla almost unusable most of the time |
06:41 | <ondras> | annevk: sorry for being afk; it was already night in my time zone. my true name is Ondřej Žára, but your version is of course allright as well :) |
07:42 | <matjas> | MikeSmith: https://bitbucket.org/validator/validator/pull-request/4/use-a-monospaced-font-for-some-form-fields/diff btw (not sure if you’re getting notifications for PRs) |
09:00 | <MikeSmith> | matjas: thanks yeah I did see that |
11:13 | <EGreg> | hey guys |
11:13 | <EGreg> | is there a way to dynamically add scripts to an HTML document at runtime, and have them download in parallel yet execute in order? |
11:14 | <EGreg> | async? defer? |
11:14 | <EGreg> | async+defer? |
11:14 | <EGreg> | I am looking to support IE8+ |
11:21 | <EGreg> | http://www.html5rocks.com/en/tutorials/speed/script-loading/ ! |
11:54 | <matjas> | TIL IE permits `;` in hostnames, e.g. http://example.com;.coredump.cx/ |
12:07 | <MikeSmith> | matjas: I wonder if the URL spec handles those as expected |
12:34 | <galant> | what is browsers support for zoom property, does browsers support it? |
12:41 | <SimonSapin> | galant: it’s non standard, IE only |
12:41 | <galant> | no webkit supports it |
12:41 | <galant> | too |
12:42 | <galant> | I want to make startrek like effect when their ship goes into warp ^^ |
12:42 | <SimonSapin> | have you tried CSS transforms? |
12:49 | <galant> | MAN this SCALE ISA COOL ^^ |
12:49 | <galant> | isa/is |
15:23 | <dglazkov> | good morning, Whatwg! |
15:42 | <Jasper> | I remember an older draft of "Web Notifications" supporting full HTML content in the body of a notification. Has this been removed? |
15:42 | <Jasper> | I just checked the latest draft and it doesn't say how to render a notification. |
15:43 | <Jasper> | ( http://notifications.spec.whatwg.org/ ) |
16:29 | <Ms2ger> | Jasper, yeah, it was removed because native notifications don't support that |
16:34 | <Jasper> | Ms2ger, OK, cool. I was hoping it would be removed, since I could imagine web notifications used as a browser-approved, unblockable popup ability. |
16:43 | <MikeSmith> | Jasper: web notifications are opt-in |
16:43 | <MikeSmith> | per-origin |
16:43 | <MikeSmith> | users have to explicitly grant perms |
16:44 | <Jasper> | I thought Safari didn't implement that right now... |
16:44 | <MikeSmith> | dunno |
16:44 | <MikeSmith> | but if so they're not conforming to the spec |
16:56 | <Ms2ger> | http://kenneth.io/blog/2013/07/15/the-messy-state-of-web-notifications-in-chrome-safari-blink-webkit/ |
17:10 | <Hixie> | anyone know if gecko has any plans to update its <menu> implementation to match the spec? (the spec was changed at some point to more closely match firefox, but there were some things that didn't quite match firefox for sanity reasons) |
17:12 | <annevk> | ondras: will be fixed soonish |
17:12 | <annevk> | Hixie: haven't heard anything with regards to that |
17:12 | <Ms2ger> | Me neither |
17:12 | <Ms2ger> | Who did that? janv? |
17:12 | <Hixie> | and sicking, i believe, yeah |
17:13 | <Ms2ger> | I can file a bug |
17:14 | <Hixie> | that would be good, thanks |
17:14 | <Hixie> | cc me? |
17:14 | <Hixie> | ian⊙hc |
17:14 | <Ms2ger> | Boo, :hixie doesn't work |
17:15 | <Hixie> | 'hixie does |
17:15 | <Hixie> | or, you know, just "hixie" |
17:15 | <Hixie> | i don't understand this colon convention |
17:15 | <Hixie> | it's like, let's take a perfectly good system that works by substring match, and require it to match by precise match. |
17:15 | <Ms2ger> | Interestingly, there's a ian⊙hc <xixaxnxhx⊙xxt> |
17:15 | <Hixie> | o_O |
17:16 | <Hixie> | wtf |
17:16 | <Hixie> | who would do that |
17:16 | <Ms2ger> | No idea |
17:16 | <Hixie> | file another bug :-P |
17:16 | <Hixie> | to have that removed :-P |
17:17 | <Hixie> | anyway the reason i ask about the menu thing |
17:17 | <Hixie> | was that i was curious about author experience with merging menus vs replacing menus |
17:17 | <Hixie> | trying to work out if i should add this "nodefault" attribute that people asked for |
17:18 | <Hixie> | maybe called "replace-system-menu" or something else better than the vague "nodefault" |
17:18 | <Ms2ger> | Dunno if I'd want to allow that, as a user |
17:19 | <Hixie> | well jan and sicking were arguing that authors won't use it if we don't provide it, either as an option, or, failing that, as the only behaviour. |
17:19 | <Hixie> | (personally i'm with you) |
17:19 | <Hixie> | either way, though, i don't want to add features like that before we have more implementation experience with what the spec actually says |
17:19 | <Hixie> | in particular since MikeSmith was arguing we should rename <menu type=popup> to something pithier |
17:20 | <Hixie> | (though we haven't been able to find something good yet) |
17:32 | <Domenic_> | I think if authors (by which I mean our UX designers) are going to use merged menus, then the merged menus needs to be really unintrusive, i.e. a single menu item. |
17:34 | <Domenic_> | i would even consider making that a requirement? because if someone does Firefox-style merger with browser junk all over the place, <menu> will get no traction. |
17:46 | <Hixie> | Domenic_: that's the argument i've heard, yeah. i don't understand why authors hate users so much. :-) |
17:57 | <annevk> | Hixie: of course, you can say that, but by not giving authors what they want, you're making the situation for users worse ;) |
17:58 | <annevk> | Witness e.g. form controls |
17:59 | <Hixie> | that's the argument people use for drm, too |
17:59 | <Hixie> | "my not letting authors screw users over, you're hurting the users!" |
17:59 | <Hixie> | or, you know, authors could just not screw the users over |
18:01 | <annevk> | DRM seems different. There's no way to do DRM without browsers providing hooks (either plugin or DRM-focused plugin hooks). Form controls however can be created by some HTML/CSS/JavaScript that's utterly inaccessible. |
18:22 | <Hixie> | annevk: you can do drm without browsers providing hook, you just don't do it on the web |
18:22 | <Hixie> | the point is you shouldn't do it at all |
18:22 | <Hixie> | i think form controls is different than menu |
18:23 | <Hixie> | for form controls, we just didn't _have_ form controls |
18:23 | <annevk> | I don't think so. Developers can innovate much faster than browsers with UI. |
18:23 | <Hixie> | it wasn't that they weren't as pretty or whatever. at least, not for most custom controls. groups like google are a special case. |
18:23 | <annevk> | No Google is not. Styling form controls has been a top feature request for over a decade. |
18:24 | <Hixie> | ok |
18:24 | <Hixie> | i don't really know what we're arguing at this point |
18:24 | <Hixie> | i'm not disagreeing with you |
18:25 | <annevk> | I guess what I'm saying is that developers need full control over what happens when you right click, including playing a movie in the popup. |
18:25 | <Hixie> | o_O |
18:25 | <Hixie> | when i tried providing something that was extensible to do that, gecko didn't implement it |
18:26 | <Hixie> | instead y'all did <menuitem> |
18:26 | <Hixie> | and i had to scale the spec back to do that instead |
18:26 | <annevk> | Sounds like my position might be different from sicking :) |
18:26 | <annevk> | Sorry for the added confusion. |
18:27 | <Hixie> | what you're describing is not a context menu, which is what i was talking about -- it's a popup, which is something i tried to spec years ago in xbl2 |
18:27 | <Hixie> | but since nobody implemented that... |
18:27 | <Hixie> | oh actually it wasn't in xbl2, it was in web-controls |
18:28 | <Hixie> | http://www.whatwg.org/specs/web-controls/current-work/#the-elementui |
18:28 | <Hixie> | showPopup() |
18:28 | <Hixie> | we're still going to need that, for when people implement <select> with web components |
18:29 | <Hixie> | unfortunately aria basically killed that approach, instead making their hacky approach the way you do this |
18:37 | <Hixie> | heycam|away: ping |
18:38 | <Hixie> | heycam|away: (wondering about news on https://www.w3.org/Bugs/Public/show_bug.cgi?id=22346 ) |
18:40 | <SteveF> | hixie: "unfortunately aria basically killed that approach, instead making their hacky approach the way you do this" how did aria do that? |
19:02 | <Domenic_> | Hixie: my point was that you could probably get away without replace-system-menu if you mandated that the system menu get shoved into a single menu item. it might be a compromise that makes both the keep-the-system-menu and kill-the-system-menu camps happy. |
19:23 | <Yuhong> | annevk: I don't think mutation events are going away anytime soon when IE9/10 do not support mutation observers. |
19:23 | <zewt> | ... nginx disables tls compression? wtf? |
19:26 | <zewt> | man, why is it hard to get stream-level compression over http |
19:38 | <zewt> | and ios's https api doesn't turn it on? madness |
19:41 | <Yuhong> | annevk: And I expect the effects of this to persist long after IE9/10 dies. |
19:41 | <Hixie> | Domenic_: we can't really mandate anything, it's UI. There might not be any visible menu items, it could be an audio browser. |
19:42 | <Ms2ger> | Hixie, but we can suggest |
19:43 | <Hixie> | yeah, we can certainly suggest more than we do now |
19:43 | <Yuhong> | IE11 finally supports mutation observers, BTW. |
20:18 | <Hixie> | annevk: what's the status of http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0030.html -- do you still think it needs changes? |
20:23 | <annevk> | Hixie: Well, I do think Fetch needs those hooks. I also quite haven't figured out how to do them... |
20:24 | <Hixie> | even with that e-mail answering my questions, i don't really understand what you want changed |
20:24 | <annevk> | Hixie: I want hooks for XMLHttpRequest and ensured tasks for "headers in", "body bytes in", "all bytes in" |
20:25 | <annevk> | Hixie: and a hook for "transmitting to server" |
20:25 | <Hixie> | aah ok |
20:25 | <Hixie> | well that's easy enough |
20:25 | <Hixie> | we have one for "all bytes in" |
20:26 | <Hixie> | you want to just add them to your spec? |
20:26 | <annevk> | Hixie: I guess, I'm not sure what phrasing to use |
20:27 | <Hixie> | can't you just queue the tasks? |
20:27 | <Hixie> | i don't understand the trouble |
20:27 | <annevk> | Hixie: The trouble I have is creating a task that has a specific hook. |
20:28 | <Hixie> | "When the resource is available, or if there is an error of some description, queue a task that uses the resource as appropriate. If the resource can be processed incrementally, as, for instance, with a progressively interlaced JPEG or an HTML file, additional tasks may be queued to process the data as it is downloaded. The task source for these tasks is the networking task source." |
20:29 | <annevk> | So it's mostly the prose that makes it work? Nothing like queue a task annotated <b>headers available</b> or some such? |
20:29 | <Hixie> | or for "headers in": "Immediately after receiving the last header for the resource, or immediately before sending the first task to process the resource's data, if there are no headers, queue a task to <dfn>process the headers</dfn> of the resource, passing it all the metadata received." or some such |
20:33 | <Hixie> | (let me know if that does not sufficiently address your requests in that e-mail) |
20:33 | <annevk> | Hixie: I think that's what I was looking for, thanks. |
20:33 | <Hixie> | np |
20:34 | <annevk> | Hixie: In particular what I don't want is queue tasks for transmitting towards the server to trigger "spec code paths" that listen for networking tasks but only care about downloading. We might just have to clarify those listeners. |
20:45 | <annevk> | I wonder if Yuhong thinks he's the only one keeping track of mutation stuff... |
20:53 | <Hixie> | annevk: k |
21:13 | <annevk> | TabAtkins: https://groups.google.com/forum/#!topic/mozilla.dev.platform/3q-rId_KMpU |
21:13 | <annevk> | TabAtkins: please fix :) |
21:20 | <annevk> | heycam|away: fwiw, I hate the name EnsureUTF16, but that's prolly a good thing |
21:29 | <annevk> | smaug____: yo, could you review my fix in that mutation bug? |
21:32 | <smaug____> | looking |
21:33 | <smaug____> | er, what fix |
21:33 | <smaug____> | the spec looks the same |
21:34 | <smaug____> | oh, the bug |
21:40 | <galant> | do you have any idea why it can be so I can't click some paragraphs? |
21:42 | <galant> | I have 6 paragraphs in a section, they have click event assigned, when I rotate by X axis the section for 360 deg I can't click and select the text from the 2 paragraphs that are on the bottom of the seciton others I can, they should change color on click, butwhen section is rotated 0 deg by X axis I can select text and click all paragrahs why? |
21:43 | <annevk> | smaug____: so yeah, those transient observers, that's what the context object bit is about |
21:46 | <smaug____> | ah, right |
21:51 | <galant> | I have this |
21:51 | <galant> | http://jsfiddle.net/CrUYH/1/ |
21:51 | <galant> | ups sry |
23:35 | <Hixie> | annevk: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22714 |
23:36 | <annevk> | Hixie: just came up here |
23:36 | <heycam> | Hixie, I'll look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=22346 this morning |
23:36 | <Hixie> | heycam: thanks |
23:38 | <annevk> | Hixie: I think the general thing is there's no disctinction between a Date and DOMTimeStamp other than Date being more heavyweight |
23:39 | <Hixie> | makes sense since DOMTimeStamp was originally defined as a typedef for Date |
23:39 | <Hixie> | does that mean the bug is invalid? |
23:39 | <annevk> | What it means is that we shouldn't use Date probably |
23:39 | <Hixie> | ? why? |
23:40 | <annevk> | Especially since it gives APIs such as obj.startTime != obj.startTime |
23:40 | <annevk> | which is just terrible |
23:40 | <Hixie> | it's not great, but *shrug* |
23:53 | <Yuhong> | annevk: I am mentioning this because WHATWG DOM suggests that mutation events be eventually removed from browsers completely. |
23:55 | <Yuhong> | And I am not sure if that is possible. |
23:57 | <annevk> | Yuhong: It's not like we are not paying attention ;) |
23:58 | <Yuhong> | But IE9 and IE10 is a pretty long period. |
23:59 | <Yuhong> | It may end soon, but the effects may persist long after that. |