02:12
<falken>
Hixie: Thanks for the patch. I'm implementing it now and may have comments later.
07:28
<othermaciej>
at this point I can't tell whether w3cmemes is my fan club or is making fun of me
07:46
<annevk-cloud>
othermaciej: I would go with both
07:47
<annevk-cloud>
Looking forward to read up on that thread
07:47
<othermaciej>
oh man
08:05
<hsivonen>
what's a lone 'i' in attribute selectors? http://html5.org/tools/web-apps-tracker?from=8469&to=8470
08:32
<MikeSmith>
hsivonen: from those examples I'd guess case-insensitive
08:33
<MikeSmith>
but doesn't it match case-insensitively anyway?
08:33
<MikeSmith>
oh the attribute values
08:35
<MikeSmith>
me finds http://dev.w3.org/csswg/selectors4/#attribute-case
08:48
<hsivonen>
MikeSmith: ok. thanks. I learned something new about Selectors.
08:48
<MikeSmith>
me too
08:48
<MikeSmith>
must have been added recently
08:48
<MikeSmith>
it's onlyin the ED
08:49
<hsivonen>
in other news, I'm eager to see telemetry from Firefox 29 release and 30 release
08:50
<hsivonen>
people who do experimental science by following the health of people from birth to death must have awesome patience
08:50
<MikeSmith>
heh
08:50
<MikeSmith>
I would think that'd be some group of people doing the following of the other people
08:51
<MikeSmith>
and handing off the data
08:51
<MikeSmith>
but I get your point
08:51
<hsivonen>
MikeSmith: well, you need to have even more patience when knowing the experiment won't finish in your own lifetime
08:52
<hsivonen>
at least these Firefox releases will be out this year
08:54
<MikeSmith>
jgraham: so I'm testing a fresh wpt submodule checkout with plan to update the readme with "git submodule update --init --recursive" but I find now that no matter what flavor of submodule update I do, I end up with a resources/ subdir that only has the pywebsocket/ and wptserve/ and not the coverage/ etc. subdirs
08:54
<hsivonen>
Now I'm mainly hoping that management won't decide to add the charset menu to Firefox OS before telemetry from Fennec 30 is ready
08:55
<MikeSmith>
hsivonen: wait why are they thinking about that
08:55
<hsivonen>
MikeSmith: because CJK
08:55
MikeSmith
shakes head
09:02
<MikeSmith>
jgraham: nm what I just said (pilot error)
09:08
<zcorpan>
hsivonen: also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24005
09:18
<annevk>
To be fair to Google, Apple hasn't exactly been good at standardizing some of its inventions either, such as touch events.
10:08
<annevk>
zcorpan: I'm not sure how to fix that paragraph :/
10:11
<zcorpan>
annevk: say "the HTML standard"?
10:11
<annevk>
zcorpan: did you see my comment?
10:11
zcorpan
looks
10:12
<zcorpan>
annevk: if it's no longer a goal, just drop the whole paragraph?
10:13
<annevk>
But then some of the features coming from HTML would no longer be explained
10:23
<annevk>
http://lists.w3.org/Archives/Public/www-style/2014Feb/0242.html :/
10:23
<annevk>
There's a lot of those emails
10:39
<yoav>
zcorpan: Going over the Blink image loading code, I bumped into an old comment :https://github.com/yoavweiss/Blink/blob/master/Source/core/loader/ImageLoader.h#L61
10:40
<yoav>
I want to make sure I understand current behavior and cement it with tests before touching these parts
10:41
<yoav>
So, if I understand correctly, a load event must be fired for every time 'src' (and prob 'srcset' is set from JS, even if the selection algo came up with the same final image
10:41
<yoav>
is that correct?
10:43
<zcorpan>
yoav: interesting, that's different from what the spec says. see "change" in http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#dom-trees
10:44
<zcorpan>
and http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element "A user agent that obtains images immediately must also synchronously update the image data of an img element whenever that element has its src, srcset, or crossorigin attribute set, changed, or removed."
10:44
<yoav>
Hmm
10:46
<yoav>
So maybe I'm mis-reading the comment
10:46
<zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2800
10:46
<zcorpan>
no i think you read it right
10:48
<yoav>
Firefox & Chrome show different results here...
10:49
<yoav>
IE fires the event twice as well
10:50
<zcorpan>
i happen to have old chrome 21 which fires the event once
10:51
<zcorpan>
firefox 27 fires it once
10:52
<yoav>
Firefox 26 fires it twice...
10:52
<yoav>
OK, so current behavior is firing it once (module IE)
10:52
<yoav>
s/module/modulo)
10:53
<yoav>
So the comment probably outlived the actual code behavior
11:07
<SteveF>
questions for MikeSmith: https://twitter.com/stevefaulkner/status/431738798314369024
12:16
<hsivonen>
for those at home who are wondering what Pasifika Nexus is, it looks like it's a Fiji-based think-tank.
12:16
<hsivonen>
how come there's not w3cmeme about this yet? www-style getting all the attention?
12:23
<Ms2ger>
Pasi-what?
12:23
<hsivonen>
Ms2ger: still not reading HTML WG administrative email, eh?
12:23
<Ms2ger>
No
12:23
<Ms2ger>
Still perfectly happy without that timesink :)
12:24
<Ms2ger>
r? https://critic.hoppipolla.co.uk/r/744
13:06
<annevk>
hsivonen: that list
13:06
<annevk>
o_O
13:08
<darobin>
since hsivonen seems to read it anyway, I wonder how much he'd charge to give me a summary every once in a while :)
13:09
<Ms2ger>
darobin, I can offer that service too
13:09
<Ms2ger>
I'll just set up a monthly cronjob to send you an email saying "Nothing interesting happened."
13:18
<zcorpan>
anyone object if i add webvtt stuff to HTML IDL tests?
13:19
<Ms2ger>
Not me
13:24
<zcorpan>
ok good
13:29
<darobin>
Ms2ger: I so saw that one coming :)
13:46
<smaug____>
good that the shadow dom encapsulation is being discussed again. Not that I'm optimistic that to lead any changes in the spec
13:53
<zcorpan>
Ms2ger: r? https://critic.hoppipolla.co.uk/showcommit?first=cb28b226&last=acab08eb&review=74
14:06
<jgraham>
Is someone trying to do something with critic and experiencing an error?
14:27
<Enzo90910>
Hi everyone. I am currently working on a JavaScript project in which in response to a user event, a Javascript loads data from local storage, works on it a bit, and then writes a new version in localStorage. My problem is that when a user has several tabs open on my site, data corruption happens because several threads are reading/writing the localStorage at the same time. My understanding is that it happens only on Ch
14:27
<Enzo90910>
because Chrome uses one event loop for each tab and doesn't use a storage mutex. I am currently investigating several possible solutions: implementing mutexes using localStorage (hard, maybe impossible), trying to leverage the "storage" event to implement transactions (hard), or switching to IndexedDB (not supported by Safari). Has anyone encountered such use cases yet and how do you suggest to solve it? Any input is
14:27
<Enzo90910>
appreciated.
14:31
<Ms2ger>
zcorpan: r+
14:31
<Ms2ger>
jgraham, no error
14:32
<Ms2ger>
zcorpan: (I didn't review carefully, but I assume you can c/p)
14:34
<jgraham>
Ms2ger: I am getting an error about git merge-base failing, but I'm not sure why
14:34
<Ms2ger>
Weird
14:43
<zewt>
i haven't even really tried indexeddb yet; far too unidiomatic compared to every other database system i've used...
15:05
<odinho>
I know idb, but never used for anything. :p
15:28
<Ms2ger>
odinho!
15:40
<Ms2ger>
http://www.theregister.co.uk/2014/02/07/opera_founder_its_all_gone_to_crap/
15:48
<zewt>
the words "unprofessional" and "childish" spring to mind
16:31
<smaug____>
how could we kill non-worker-sync XHR
16:33
<annevk>
smaug____: more warnings?
16:33
<annevk>
smaug____: sendBeacon?
16:34
<smaug____>
sendBeacon maybe, though I've seen plenty of non-beacon-like usage too
16:35
<smaug____>
but would need to get all the browser engines start warning
16:35
<smaug____>
and then just kill it next year or so
16:35
<smaug____>
2% is way too much
16:36
<smaug____>
that is what telemetry data seems to hint currently
16:36
<annevk>
JakeA: getting to your email now
16:36
<annevk>
JakeA: should've done this earlier :/
16:36
<annevk>
smaug____: ouch
16:37
<annevk>
smaug____: we cannot just kill it with 2%
16:37
<smaug____>
yeah
16:37
<smaug____>
web sites do silly things like start sync xhr on keydown and such
16:38
<smaug____>
right now we don't warn about sync xhr, I think
16:39
<JakeA>
annevk: I'm over the jet lag so I can think things
16:39
<JakeA>
Although I have a beer so the thinking is temporary
16:45
<annevk>
smaug____: we should warn, we should warn harder for showModalDialog
16:46
<annevk>
JakeA: depends, https://xkcd.com/323/ :p
16:46
<smaug____>
sync XHR is worse
16:46
<annevk>
dunno, nested event loops...
16:47
<smaug____>
well, in Gecko sync XHR uses nested event loop. And in all the browsers it means the UI of the website isn't responsive during the XHR processing
16:47
<annevk>
fair
16:47
<JakeA>
annevk: do we still get a lot of JS served without a js content type?
16:48
<annevk>
JakeA: JavaScript MIME types are not really a thing in browsers, although it seems developer consoles made them into some kind of thing which is odd
16:49
<Domenic_>
developer consoles?
16:49
<Domenic_>
how so?
16:50
<JakeA>
annevk: ahh ok, I was hoping a js content type wouldn't be a barrier to entry these days
16:50
<Domenic_>
re: sync XHR. I wonder if you could convince the jQuery core team to remove the ability to do it.
16:51
<annevk>
Domenic_: I think they complain if you don't specify a MIME type, even though you don't have to per spec
16:51
<annevk>
Domenic_: and then the list of MIME types developer tools support depends on who implemented the tool prolly
16:51
<smaug____>
Domenic_: yeah, I think we'd need to get all the script libraries stop using it
16:51
<smaug____>
that would be the first step
16:53
<annevk>
Well, best of luck!
16:54
<annevk>
smaug____: if you want me to add something to the specification I could do that I suppose, not sure where the best place would be
16:55
<Soraya_>
Enzo90910: n8dy84xuwt
16:55
<smaug____>
annevk: somewhere near open() I guess
16:56
<smaug____>
another thing to deprecate is mutation events
16:56
<Soraya_>
Hi guys ?
16:58
<smaug____>
hmm, mutation event usage has been going down
17:04
<Domenic_>
blink already killed several..
17:04
<smaug____>
well, no one has ever supported them all
17:07
<annevk>
smaug____: http://xhr.spec.whatwg.org/#sync-warning
17:08
<smaug____>
thanks
17:09
<smaug____>
annevk: I wonder if we should have a version of open without async param
17:10
<smaug____>
void open(ByteString method, [EnsureUTF16] DOMString url, [EnsureUTF16] DOMString? username = null, optional [EnsureUTF16] DOMString? password = null);
17:11
<annevk>
You cannot distinguish that from what we have now
17:28
<annevk>
Domenic_: any timeline for getting streams in browsers?
17:28
<annevk>
I sorta think we should have streams before we design a "replacement" for XMLHttpRequest
17:29
<Hixie>
annevk: i don't follow https://www.w3.org/Bugs/Public/show_bug.cgi?id=23810 - what's the story there?
17:30
<annevk>
Hixie: http://www.whatwg.org/specs/web-apps/current-work/#affected-by-a-base-url-change
17:30
<annevk>
Hixie: since I removed it, it's no longer in DOM
17:31
<Hixie>
annevk: why did you remove it?
17:31
<Hixie>
annevk: you just want me to move the relevant bits to HTML?
17:31
<Hixie>
annevk: is this part of dropping xml:base?
17:31
<annevk>
Hixie: seemed better to just inline it
17:31
<Hixie>
wasn't this in HTML originally?
17:32
<annevk>
Hixie: in HTML it can also be inlined, but yeah, given that xml:base will be gone the only thing that will change is the document base URL going forward
17:32
<annevk>
Hixie: yeah could be
17:32
<Hixie>
and DOM doesn't want to handle base URLs changing?
17:32
<annevk>
Hixie: it has "base URL change steps"
17:32
<annevk>
Hixie: I think that's all we need as a concept
17:32
<Hixie>
?
17:33
<Hixie>
i thought you just said it was removed
17:33
Hixie
is confoosed
17:33
<annevk>
Hixie: there's also "affected by a base URL change" which is kinda double
17:33
<annevk>
Hixie: that was removed
17:33
<Hixie>
ok so this is very confusing
17:34
<Hixie>
we originally just had one term
17:34
<Hixie>
then you took over that term and split it into two
17:34
<Hixie>
and now you've removed the first term, leaving only the second?
17:34
<annevk>
Are you sure?
17:34
<Hixie>
see r1970
17:34
<Hixie>
actually it dates from even before that
17:35
<Hixie>
r1820
17:37
<Hixie>
r6505 is when i converted to your terminology
17:38
<Hixie>
r1820 is when i added the base URL processing stuff
17:38
<annevk>
http://html5.org/tools/web-apps-tracker?from=1819&to=1820
17:38
<annevk>
oh http://html5.org/tools/web-apps-tracker?from=1820&to=1821
17:38
<Hixie>
sorry, r1821
17:39
<Hixie>
i think all i really need from DOM here is that when a node is adopted, its subtree is "affected by a base URL change"
17:40
<Hixie>
i don't really understand why we need the "base URL change steps" term
17:40
<Hixie>
but anyway
17:40
<Hixie>
you just want me to change "is affected by a base URL change" to "must cause the user agent to run the base URL change steps for that node"?
17:40
<annevk>
yeah
17:40
<annevk>
sorry :/
17:40
<annevk>
there might be some more churn here going forward because of custom elements and the xml:base stuff
17:41
<Hixie>
my bigger concern is over <img> adoption
17:41
<annevk>
I prefer change steps because that's consistent with copy steps and such
17:41
<Hixie>
i need a hook for <img> adoption that isn't the same as the hook for base URL changing
17:41
<annevk>
so we might actually start offering some kind of callback thing for adoption
17:41
<Hixie>
does DOM actually do anything with base URL changes?
17:41
<annevk>
no, it just notifies
17:41
<Hixie>
maybe the right thing here is for DOM to forget about base URL change notification, and just notify on adoption
17:42
<annevk>
yeah that actually makes sense
17:42
<Hixie>
and then i can make that notification cause the element to be "e base URL
17:42
<annevk>
that ties in with that callback thing before
17:42
<Hixie>
and then i can make that notification cause the element to be "affected by a base URL change" (even)
17:42
<annevk>
can you update the bug? I need to go
17:42
<Hixie>
sure
17:42
<Hixie>
thanks
17:42
<annevk>
thanks!
17:42
<annevk>
hah
17:44
<Ms2ger>
https://github.com/operasoftware/presto-testo
17:57
<Domenic_>
annevk-cloud: we're trying to move pretty fast on streams, but a timeline seems hard to nail down at this point. we do have buy-in now after convergence that should help get it in everywhere, and lots of specs want it, so those are all forces pushing things quickly.
17:57
<Hixie>
who's implementing?
17:58
<Ms2ger>
There's various vaguely positive noises, I think
17:58
<Domenic_>
there's interest from mozilla, blink, and microsoft
17:58
<Domenic_>
i think blink actually had a guy working on code; mozilla mostly wants it to support other of their specs like TCP socket
18:11
<MikeSmith>
blink already had an implementation of the webapps Streams API from last year
18:11
<MikeSmith>
Zach Kuznia did it
18:12
<MikeSmith>
partial implementation at least but most if what was there at the time
18:12
<MikeSmith>
but maybe that's largely been overcome by circumstances
18:14
<MikeSmith>
maybe tyoshino is on deck for implementing for where it's at now
18:15
<smaug____>
scott_gonzalez: ping
18:16
<smaug____>
Ms2ger: boo, I thought they released their engine source code
18:17
<Ms2ger>
Heh
18:17
<Ms2ger>
That'd have been interesting too
18:17
smaug____
still wants to know what kind of garbage/cycle collector they have
18:18
<Ms2ger>
I've heard claims that the gc was simple mark-and-sweep
18:20
<jgraham>
I think it's true — although perhaps others would disagree — that the Opera philosophy was to avoid overengineering where possible
18:31
<smaug____>
Ms2ger: but what about edges to and from C++ side?
18:31
<smaug____>
or maybe everything was GCed
18:32
<Ms2ger>
That seems somewhat plausible
18:59
<Ms2ger>
Yay, a new JAM season next week
19:07
<jgraham>
Isn't this more the time of year for marmalade?
19:07
<jgraham>
(I note that I did actually understand and it is indeed something to look forward to :)
19:23
<karlcow>
lady marmalade
19:35
<GPHemsley>
For your consideration: https://bugs.freedesktop.org/show_bug.cgi?id=41155
19:36
<GPHemsley>
(re MIME types, Google, WebP...)
19:40
<GPHemsley>
(also re registries, specs, intent...)
20:35
<Domenic_>
Report from a Real Web Developer sitting next to me at work: "I really enjoyed the Shadow DOM kerfluffle, as now I'm more aware of the technologies and actors involved, whereas before web components was all very abstract to me."
20:47
<othermaciej>
so kerfuffles have one positive side effect, I guess
20:47
<hober>
:/
20:49
<arunranga>
Hi #whatwg :) Would anyone weep for DOMError if we take it out of IndexedDB and File API (and others) as per https://www.w3.org/Bugs/Public/show_bug.cgi?id=21740#c11 ?
20:50
<alecf>
just replace with DOMException?
20:50
<Domenic_>
Kill it!1!1!!one kill it with fire!
20:50
<arunranga>
Yes, Domenic_, I think we know how you feel :)
20:51
<alecf>
if so SGTM
20:51
<Domenic_>
just making sure... :)
20:51
<arunranga>
alecf, yes, pretty much use DOMException, which becomes a first class citizen of WebIDL.
20:53
<alecf>
as long as it has the same/subset of attributes as DOMError (I can't figure out if the attributes line up) that sounds good to me
20:55
<arunranga>
alecf, snooping around in Chromium (and Fx) source, you find DOMError, so there'll have to be some code changes going forward, since I think Chrome returns one during an error event for IDB and File*
20:55
<alecf>
heh yes, I implemented DOMError in blink
20:56
<arunranga>
alecf, heh :) OK, so, unless others object (on the mailing list or here), I'll change the spec. I'll weep a bit for DOMError, but connecting to the Error object for stack and stuff outweighs my tears
21:02
<Ms2ger>
"Awaiting decision in WhatWG. May 2007."
21:04
<arunranga>
Along those same lines, does anyone care if we strip out FileList and just make it an Array, along the lines of https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682 ?
21:05
Domenic_
stays quiet this time
21:06
<Ms2ger>
arunranga, please wait for that bug to be fixed
21:06
<arunranga>
Heh :) We'll lose code of the sort files.item(0) (which was weird anyway) and we'll have to think carefully about adding to FileList.
21:07
<arunranga>
Ms2ger, are you talking about waiting on replacing FileList with Array, or waiting before we strip out DOMError?
21:07
<Ms2ger>
arunranga, FileList
21:09
<arunranga>
OK, that seems reasonable; what will break for sure is stuff like files.item(0) but I don't know how common that usage is. Also, extending FileList will be tricky (e.g. fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125).
21:09
<arunranga>
Ms2ger ^^
21:10
<Ms2ger>
I'm staying out of the specifics :)
22:08
<Hixie>
hsivonen: yt?
22:08
Hixie
wonders how to make progress on this registry thing
22:45
<Hixie>
abarth|gardener: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22731
22:47
Hixie
is months behind reading his bugmail, and just got to the closures mentioned in http://www.w3.org/2011/webappsec/minutes/webappsec-minutes-27-Aug-2013.html
22:47
<Hixie>
good times, good times.
22:47
<abarth|gardener>
Hixie: looking
22:50
<abarth|gardener>
Hixie: what is the security concern?
22:50
<abarth|gardener>
that two different strings decode to the same thing?
23:16
<TabAtkins>
annevk-cloud: Yo, I finally did like you wanted and just said that the data model for Selectors in an HTML document is just the DOM.
23:17
<TabAtkins>
http://dev.w3.org/csswg/selectors/#data-model
23:20
<Hixie>
abarth|gardener: not sure, hence asking you :-)
23:28
<scott_gonzalez>
smaug____: pong
23:28
<smaug____>
scott_gonzalez: I was going to ask about sync XHR and unload
23:28
<scott_gonzalez>
I figured :-)
23:29
<smaug____>
so , I think I'll add warning for the cases when we're not in unload/beforeunload/pagehide listeners
23:29
<scott_gonzalez>
I've been pushing to replace jQuery.ajax() with jQuery.xhr() and kill sync XHR requests.
23:29
<smaug____>
any other cases you think would be somewhat valid before we have sendBeacon
23:30
<scott_gonzalez>
I think that's the only case that comes up, but the whole jQuery team will be together next week in San Diego, so I can see if anyone else knows of other scenarios.
23:31
<smaug____>
k
23:31
<smaug____>
I'll probably push this change even before that
23:31
<smaug____>
I'm sure there will be tons of warnings
23:31
<smaug____>
I don't even know if google has fixed their docs
23:32
<scott_gonzalez>
Dave Methvin has already said he's going to file a jQuery ticket about the warning in anticipation of lots of duplicates as soon as a browser starts logging the warning.
23:33
<scott_gonzalez>
Anything a browser warns about, we get dozens of tickets for.
23:33
<smaug____>
good
23:33
<smaug____>
hmm, can I file blink bugs without a google account?
23:38
<TabAtkins>
Yeah, I think you can sign up for a chromium.org account without a google account.
23:38
<TabAtkins>
(I could be wrong - I had one given to me.)
23:44
<jamesr__>
i believe you need a google account to use chromium/blink's bug tracker
23:45
<smaug____>
anyone want to then file a blink bug to warn about use of sync XHR in main thread
23:45
<smaug____>
jamesr__: TabAtkins: similar to https://bugzilla.mozilla.org/show_bug.cgi?id=969671