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.