01:09
<GPHemsley>
Filed DOM 3 Events spec bug for event order: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22641
02:20
<jpwhiting_>
MikeSmith: yep, I'm hitting something different this time, I moved the sources to package it as a debian package, and when I try to build jing-trang's ant can't find apache-ant for some reason
02:24
<GPHemsley>
...and closed as INVALID
02:24
GPHemsley
shrugs
02:24
<jpwhiting_>
http://pastebin.com/DV0Z3FLT
02:25
<jpwhiting_>
MikeSmith: the issues I was having earlier were because my spec was added to validator/presets.txt but not validator/w3c-presets.txt where it needed to be
02:29
<MikeSmith>
jpwhiting_: yeah that bit of complexity is my fault I guess
02:30
<MikeSmith>
jpwhiting_: so you're creating a Debian package of the validator? Are you planning to actually get it in the main Debian package repo?
02:32
<MikeSmith>
jpwhiting_: Maybe the reason you're seeing http://pastebin.com/DV0Z3FLT during the build is that it's ignoring your system CLASSPATH
02:33
<Yuhong>
MS just fixed document.createElement("th").cellIndex in older versions of IE to conform to the standard in the just released Cumulative Update.
02:33
<Yuhong>
Old behavior was an address leak.
02:33
<jpwhiting_>
MikeSmith: my System CLASSPATH?
02:33
jpwhiting_
is new to java, sorry
02:33
<Yuhong>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16757#c10
02:33
<jpwhiting_>
I have JAVA_HOME set, but that's about it
02:34
<jpwhiting_>
no, not packaging for debian itself, just making a debian package out of validator.nu for a client
02:34
<jpwhiting_>
to use inside their ubuntu based virtualmachine
02:34
<MikeSmith>
ok
02:34
<jpwhiting_>
the weird thing is it works fine when I run it from one path
02:35
<MikeSmith>
jpwhiting_: so if you look at the jing-trang/ant script, you'll see it feeds -cp to java
02:35
<jpwhiting_>
but I tar up the original sources gotten with build/build.py checkout && build/build.py dldeps
02:35
<jpwhiting_>
then untar it when creating the package and do python build/build.py --local build to build it
02:35
<jpwhiting_>
ah, I see, /me dives deeper
02:35
<MikeSmith>
-cp jing-trang/lib/ant-launcher.jar
02:36
<jpwhiting_>
ok, I do have that file, maybe $JING_TRANG_HOME is getting mucked up somehow?
02:36
jpwhiting_
reads build.py again
02:37
<MikeSmith>
I guess you could just hack the build script to call "ant" instead of "./ant" there
02:37
<MikeSmith>
line 558 of build.py
02:38
<jpwhiting_>
the difference being that ./ant sets classpath, where my system's ant doesn't?
02:38
<MikeSmith>
- runCmd(os.path.join(".", "ant"))
02:38
<MikeSmith>
+ runCmd("ant")
02:38
<jpwhiting_>
yep, gotcha, /me tries
02:39
<MikeSmith>
jpwhiting_: I dunno what that jing-trang/ant script is attempting to do. It's upstream code that we pull into the validator build as a dependency.
02:40
<jpwhiting_>
still it's very weird to me that it works when untarred in one place on my disk, and fails when untarred in another place
02:40
<MikeSmith>
yeah that is weird
02:40
<jpwhiting_>
maybe build/build.py checkout sets some paths or something?
02:40
<MikeSmith>
I don't think it does
02:40
<MikeSmith>
though not sure
02:41
MikeSmith
checks
02:41
<jpwhiting_>
my system doesn't know what "ant" is
02:41
<MikeSmith>
hmm, OK
02:42
<jpwhiting_>
no ant in $JAVA_HOME/bin either
02:42
<jpwhiting_>
using openjdk-7-jdk
02:42
<jpwhiting_>
one other weird thing I found is that the one checkout of validator.nu that's working has manifest and such in jing-trang/ but the one that doesn't is missing them
02:42
<jpwhiting_>
does ant create those?
02:43
<MikeSmith>
no, ant doesn't create those
02:43
<MikeSmith>
and you won't find "ant" in $JAVA_HOME/bin normally
02:44
<MikeSmith>
so anyway, forget what I said about running "ant" instead
02:44
<jpwhiting_>
erm, sorry not manifest, I meant modbuild.xml, modules.xml and the build folder
02:44
<MikeSmith>
yeah, so those are needed
02:44
<MikeSmith>
and I think they do get created by ant
02:45
<Yuhong>
Actually, only IE9 is fixed in the July update.
02:46
<jpwhiting_>
MikeSmith: even if I set JING_TRANG_HOME to the path where jing-trang is checked out to, then run ,/ant I get the java.lang.ClassNotFoundException: org.apache.tools.ant.Main
02:47
<jpwhiting_>
maybe the ant jar is bad?
02:47
<Yuhong>
Hixie: w() in the DOM Viewer is broken in IE8.
02:47
<Hixie_>
i think you mean, IE8 is broken
02:47
<MikeSmith>
jpwhiting_: the ant-launcher.jar and ant.jar binaries are distributed as part of jing-trang, so those are what your java environment should be using for the jing-trang build
02:47
<jpwhiting_>
yeah, I see them in jing-trang/lib
02:48
<Yuhong>
I use this a lot for tests.
02:48
<MikeSmith>
if it's not finding them, then I'd guess it's because your build environment doesn't have $JING_TRANG_HOME set
02:48
<Yuhong>
For example, I was trying to use http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1673 to test the latest Cumulative Update to see if the behavior is fixed.
02:49
<jpwhiting_>
why would it have JING_TRANG_HOME set?
02:49
<jpwhiting_>
I mean, what sets that?
02:49
<jpwhiting_>
heh, jing-trang/ant sets it to dirname $0
02:50
<MikeSmith>
jpwhiting_: yup
02:50
<Yuhong>
It is fixed for IE9 in the just released cumulative update, BTW. Old behavior is an address leak.
02:50
<zewt>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22641 filing bugs on dom events seems like a waste of time, heh
02:52
<Yuhong>
Unfortunately, as I said before, I can't imagine mutation events going away any time soon, as IE9/10 do not support mutation observers.
02:53
<jpwhiting_>
MikeSmith: k, I'll figure this out, thanks for the pointers :)
02:53
<MikeSmith>
k
03:00
<jpwhiting_>
MikeSmith: hmm, does java not cope well with : in path names maybe?
03:01
jpwhiting_
is using this from within an obs checkout, so part of the path is home:jwhiting:branches:blah blah
03:03
<jpwhiting_>
heh, seems so, that's working much better from a path without : in it
03:03
<jpwhiting_>
phew, problem solved
04:00
<MikeSmith>
jpwhiting: good to hear
04:01
<MikeSmith>
and ":" is the right path separator on Linux
04:01
<MikeSmith>
for java
04:01
<MikeSmith>
but on windows it needs to be ";" I think
04:04
<zewt>
things that need to die: code that uses a variable for platform path separators
04:04
<zewt>
(do people really not know that / is a valid path separator in windows)
08:32
<JakeA>
Do we have a way to get the base url of the page? As in, what relative paths will be resolved against?
08:37
<MikeSmith>
JakeA: not in the URL spec?
08:38
<JakeA>
Not that I can see, new urls have a default base of about:blank
08:38
<JakeA>
I remember Anne telling me why it didn't default to the base of the current page, but I can't remember
08:38
<JakeA>
…what it actually was
09:05
<galant>
animations for anniversaries on google homepage can't be viewed on mobile phones? Because they are done in canvas..
12:10
<JakeA>
I just got a 50k bounce on the mailing list, is anyone able to clear it through?
12:10
<JakeA>
It's a reply to @getify so it's naturally over 50k
12:12
<Ms2ger>
You could trim?
12:12
<Ms2ger>
But I believe Hixie_ moderates
12:14
<JakeA>
Yeah, I've done a lot of that already, but I'm worried I'll get accused of editing & misrepresenting the original view
12:14
<JakeA>
most of the content is the original email with replies inline
13:03
<galant>
canvas hit regions are supported by older browsers?
13:07
<Ms2ger>
They're not supported anywhere
13:09
<galant>
yeah
13:09
<galant>
I have no idea how to make canvas drawings responsive to mouse events, if you know some link for reading on this please tell me thanks
13:10
<smaug____>
you just add mouse event listener and check the coordinates in the event listener?
13:11
<JakeA>
You can test the x/y position of the click, or absolutely position an a[href] over the hit areas. The latter may be more accessible.
13:15
<galant>
thanks for ideas
13:15
<galant>
so Google uses this? :D
13:15
<galant>
for their animations
13:15
<galant>
hehe
13:15
<galant>
Hixie do the Google homepage animations on anniversaries? :DDD
13:15
<galant>
hehe
13:16
<galant>
JakeA, that absolutely positioned <a> is best idea and easiest lol it can be done in seconds
13:16
<galant>
Im not sure about other ideas though never done that
13:16
<galant>
JakeA, how to test x/y position of the click just curious?
13:17
<JakeA>
When you add a click listener to the canvas you'll get one of these as an event object https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent
13:18
<galant>
on older browsers too>?
13:18
<JakeA>
clientX/Y is what you're looking for
13:18
<JakeA>
well… certainly everything that supports canvas
13:19
<galant>
event.clientX is the thing right?
13:19
<galant>
yeah this works on every element not just canvas :) nice
13:21
<galant>
guys
13:22
<galant>
if I create some kind of interface for some API as a side effect of working on my projects do you want me to give it to you you can them implement such things in the APIs you make if you decide too, so others can have use of my work too
13:32
<JakeA>
you should make your code available on github for people. If it turns out to be super-popular and could be done much faster natively, it might make it into the spec
13:32
<JakeA>
this happened with selector matching in jQuery etc
13:32
<JakeA>
became querySelectorAll in the spec
13:36
<galant>
ok JakeA thanks
14:25
<MikeSmith>
...and Hallvord announces
14:26
<MikeSmith>
and post-mortems
14:31
<gsnedders>
MikeSmith: Opera lost him first.
14:32
<Ms2ger>
I did see him pop up in bugzilla a lot lately
14:37
<jgraham>
pointer?
14:38
<Ms2ger>
His blog
14:38
<gsnedders>
http://my.opera.com/hallvors/blog/goodbye
14:56
<jgraham>
Interesting post mortem. Things to agree with and things to disagree with.
15:08
<Ms2ger>
Someone should count how many former Operians we hired now
15:08
<Ms2ger>
/ will hire
15:10
<gsnedders>
Ms2ger: Going how far back? :P
15:11
<Ms2ger>
Last year or so?
15:13
<gsnedders>
I can only think of four off-hand.
16:07
<Hixie_>
JakeA: you still need help with moderation?
16:09
<JakeA>
nah, I cut it down & went plain text
16:09
<JakeA>
cheers
17:07
<Ms2ger>
Github slow for anyone else?
17:11
<jgraham>
I'm not getting spammed so I assume it isn't down
17:11
<jgraham>
Website doesn't seem slower than normal
17:13
<jgraham>
Fetching worked OK
17:13
<jgraham>
So, no?
17:26
<esprehn>
annevk: is there a reason you removed document.body from DOM core?
17:26
<esprehn>
it's used by every application ever... seems weird
17:27
<esprehn>
also document.title which is used by tons of apps
17:33
<gsnedders>
esprehn: Removed? Were they ever added? They've always been in HTML 5.
17:34
<esprehn>
oh I see, DOM Core just defines a subset of the Document interface :/
17:34
<esprehn>
yeah this is missing lots of stuff, that should have tipped me off :)
17:49
<esprehn>
Hixie_: steps 3 and 4 of the document.body setter algorithm are backwards
17:55
<Hixie_>
esprehn: file a bug
17:55
<Hixie_>
there's a tool on the page to do so :-)
17:56
<annevk>
esprehn: euhm wut
17:56
<esprehn>
annevk: nothing I was just confused
17:56
<annevk>
ah I see
17:56
<Hixie_>
esprehn: (but why do you think they're backwards?)
17:57
<annevk>
yeah, the separation is not exactly ideal, but I don't think we've completely figured out yet whether or not to merge all document objects so we'll see I guess
17:57
<Hixie_>
esprehn: (they're mutually exclusive)
17:57
<esprehn>
Hixie_: step 4 null checks the documentElement, step 3 calls replaceChild on it
17:57
<Hixie_>
esprehn: step 3 can't get to the replaceChild call unless documentElement has a child
17:58
<esprehn>
ah yeah
17:58
<esprehn>
still seems weird to do that step before looking for a missing documentElement
17:59
<Hixie_>
*shrug*
17:59
<esprehn>
yeah, I won't file a bug
18:00
<esprehn>
btw WebKit's behavior here is all kinds of fun. document.body returns the first <body> unless there's a <frameset> in which case we return that
18:01
<Hixie_>
that's per spec
18:01
<Hixie_>
more or less
18:01
<esprehn>
hmm?
18:01
<Hixie_>
spec says "the first child of the html element that is either a body element or a frameset element"
18:02
<esprehn>
the spec doesn't say <html><body><frameset></html> and document.body should return <frameset> right?
18:02
<esprehn>
the spec says pick the first one you see
18:03
<Hixie_>
yeah, it's not quite webkit's behaviour
18:03
<Hixie_>
hence the "more or less"
18:03
<esprehn>
webkit also throws HierarchyRequestError if you do document.body = <frameset>
18:04
<jgraham>
Sounds like you have some bugs to fix ;)
18:06
<esprehn>
yeah
18:33
<annevk>
Hixie_: so how stable is the canvas in worker stuff?
18:33
<annevk>
Hixie_: given http://wiki.whatwg.org/wiki/CanvasInWorkers it might be not very stable?
18:38
<Ms2ger>
annevk, nobody's implemented it, so, unstable :)
18:38
<annevk>
Ms2ger: so we're thinking about it but if there's major outstanding feedback...
18:38
<tantek>
Ms2ger - I like your reasoning :)
18:38
<annevk>
Ms2ger: but if there's no major outstanding feedback, it'd be more attractive
18:39
<Ms2ger>
That page was last edited 1 March
18:41
<annevk>
so yeah
18:41
<annevk>
unstable
18:41
<Ms2ger>
Anyway, make Hixie_ prioritize any feedback
18:44
<annevk>
Hixie_: http://cdn.meme.li/instances/400x/39616780.jpg
18:45
<tantek>
LOL
18:46
<zcorpan>
sup guys
18:48
<annevk>
sup zcorpan
18:49
<zcorpan>
having vacation :-)
18:49
<Ms2ger>
Did we hire zcorpan already?
18:50
<zcorpan>
is that a website?
18:54
<Ms2ger>
Arewemployingzcorpanyet.com
18:55
<annevk>
zcorpan: sounds good :)
18:57
<zcorpan>
402 Payment Required
18:58
<Ms2ger>
I'm sure we can arrange something
19:11
zcorpan
leaves again
19:30
<annevk5>
Hixie_: so "exposed to JavaScript"... where is defined that Event is exposed to workers?
19:30
<annevk_>
Hixie_: or WebSocket?
19:31
<annevk_>
Hixie_: I think I'd prefer it if you changed the defaults
19:31
<annevk_>
Hixie_: say that everything is exposed to JavaScript regardless of global
19:31
<annevk_>
unless stated otherwise
19:31
<annevk_>
Hixie_: and then I'll have DOM and such say otherwise
19:36
<Hixie_>
annevk: looked around for feedback on canvas and workers, but didn't see any
19:36
<Hixie_>
annevk_: do you have a link to the e-mail or bug in question?
19:36
<Hixie_>
annevk_: we should say that events and websocket are exposed.
19:37
<Hixie_>
annevk_: in general, the default is not to expose, i think
19:37
<Hixie_>
annevk_: since most things involve the dom
19:37
<annevk_>
really?
19:38
<annevk_>
I think if you exclude Node and its descendants most things are non-DOM
19:39
<annevk_>
there's http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/thread.html#msg18
19:39
<Hixie_>
i responded in that thread
19:40
<annevk_>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0160.html
19:40
<annevk_>
(minor)
19:40
<Hixie_>
yeah, that's the issue of workers not listing all the things yet
19:41
<annevk_>
I wonder why http://wiki.whatwg.org/wiki/CanvasInWorkers is not mentioned on the list
19:41
<annevk_>
Maybe because Gregg left Google?
19:43
<annevk_>
Hixie_: in my experience pretty much any new API we create we want in workers
19:45
<jsbell>
Has the "should APIs in Workers be sync or async?" debate recurred since Futures arrived?
19:46
<Hixie_>
apis in workers can be both
19:46
<annevk_>
smaug____: should we remove [NoInterfaceObject] from XMLHttpRequestEventTarget?
19:47
<annevk_>
jsbell: http://infrequently.org/2013/05/the-case-against-synchronous-worker-apis-2/ is there
19:47
<annevk_>
jsbell: when we discussed this at Mozilla, opinions were split
19:47
<annevk_>
jsbell: also, promises
20:21
<annevk_>
Hixie_: so Window, Node and descendants, bits of Navigator-related interfaces, anything else not going into Worker?
20:22
<annevk_>
Hmm, NodeList, HTMLCollection, DOMTokenList
20:22
<Ms2ger>
Everything that touches nodes? :)
20:22
<Hixie_>
there's a ton of them
20:22
<Hixie_>
"Node and descendants" alone is a list longer than my arm
20:22
<Ms2ger>
webperf?
20:23
<Hixie_>
we shouldn't enable things in workers without carefully thinking about it
20:26
<annevk_>
our current list is https://etherpad.mozilla.org/WorkerThreadAPIs
20:30
<jsbell>
annevk: damnit, I typed Promises then edited it to Futures. Get with the program, brain!
20:30
<annevk_>
Hixie_: I think I'll just go and list for each interface if they're exposed in both environments
20:32
<annevk_>
Hixie_: although for that having "Exposed to document and worker environments" and such as shorthands would be useful
20:32
annevk_
files a bug with that idea
20:34
<annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22646
20:54
<Hixie_>
you want a shorthand for a five-word phrase that says two things? :-)
20:55
<annevk>
Hixie_: basically below each IDL block I'd be able to say x, y, or z
20:56
<annevk>
Hixie_: makes it somewhat clearer what the worker situation is for everyone and doesn't involve 3 cross-references
20:58
<Hixie_>
i don't understand
20:58
<Hixie_>
what do you think you have to say today?
20:59
<annevk>
So I define [Constructor] interface Foo {};
20:59
<annevk>
I expect I have to say somewhere it works in both workers and documents
20:59
<annevk>
or just in documents
21:00
<annevk>
I'm also running into minor issues with e.g. XMLHttpRequest
21:00
<Hixie_>
oh you want to change "The SharedWorkerGlobalScope interface must only be exposed to JavaScript if the JavaScript global environment is a shared worker environment." to something shorter?
21:00
<Ms2ger>
Anyone got interesting things to test for document.images?
21:00
<annevk>
Hixie_: yes
21:00
<Hixie_>
we could just have [Exposed=Worker], [Exposed=Window] (default), [Exposed=Window,Worker]
21:01
<annevk>
(The issue I'm running into is how to deal with Document appearing in the IDL, and HTMLFormElement appearing in FormData's IDL.)
21:01
<Hixie_>
heycam: ^
21:01
<Hixie_>
annevk: how do browsers deal with it?
21:01
<annevk>
Hixie_: they just deal
21:01
<annevk>
"prose"
21:01
<annevk>
(which I've added for now)
21:02
heycam
acks, will think when I'm off the phone
21:02
<Ms2ger>
Yeah, the hard part is when only part of an interface is exposed to workers
21:03
<annevk>
could maybe make [Exposed] work everywhere somehow?
21:03
<annevk>
send(([Exposed=Window] Document or DOMString) data)
21:04
<Ms2ger>
[[Exposed=Window]Constructor...?
21:04
<annevk>
readonly attribute ([Exposed=Window] Document or null) responseXML
21:04
<Hixie_>
or just have two different IDLs
21:04
<annevk>
Ms2ger: yeah something like that
21:04
<annevk>
Hixie_: like you do for navigator?
21:05
<annevk>
seems kinda overkill for most of XHR, although I guess we could make that work in some way
21:05
<Ms2ger>
Navigator actually is called WindowNavigator in workers
21:07
<annevk>
I know
21:17
<Hixie_>
annevk: yeah
21:19
<annevk>
Hixie_: I guess if we have [Exposed] we could name it the same even
21:20
<annevk>
but still, kinda bloaty
21:22
<Hixie_>
Ms2ger: i assume you mean WorkerNavigator
21:22
<Hixie_>
we could use the same name, just need some prose to say which one you mean
21:22
<Ms2ger>
Er, yes
21:22
<Ms2ger>
I can't speel
21:40
<heycam>
how many things do we have in the middle of an interface that we want to turn off in workers?
21:42
<annevk>
heycam: FormData, XMLHttpRequest, cannot really think of something else
21:42
<heycam>
but, members of an interface? or are these interface members which mention those types?
21:43
<annevk>
It might be good to not expose responseXML in Workers
21:43
heycam
wonders how bloating it would be to put [Exposed=…] on those interface members, if there are only a couple of them
21:43
<annevk>
I think responseType = "document" we deal with in prose
21:43
<annevk>
heycam: ah yeah, we could just duplicate definitions I suppose
21:43
<heycam>
ah, so the issue I guess is that we mention Document in the return type?
21:44
<annevk>
one send() for Window and one for Worker
21:44
<heycam>
I guess it's not technically a problem
21:44
<annevk>
heycam: that's the issue
21:44
<heycam>
as long as prose never returns a Document object
21:44
<annevk>
heycam: I'd prefer not to expose responseXML at all, but e.g. for FormData I'd want a constructor in workers that doesn't take an argument
21:45
<heycam>
I see
21:45
<annevk>
heycam: we could maybe have some wording around interfaces not existing in workers?
21:45
<annevk>
heycam: e.g. Document doesn't exist, therefore (Document or DOMString) ends up meaning DOMString
21:45
<annevk>
and Document? ends up meaning null
21:46
<heycam>
maybe
21:46
<annevk>
and optional HTMLFormElement x means no argument?
21:46
<annevk>
dunno
21:46
<heycam>
would it result in members disappearing altogether?
21:46
<heycam>
might be a bit nonobvious
21:46
<annevk>
seems somewhat more complicated
21:46
<heycam>
looking at the idl
21:47
<annevk>
saying Constructor is X in Window and Y in Worker seems easier
21:47
<heycam>
yeah
21:47
<annevk>
and responseXML is only in Window, and send() is X in Window and Y in Worker
21:47
<heycam>
in prose you mean?
21:47
<annevk>
no with the flag
21:47
<heycam>
ah
21:47
<annevk>
well or prose
21:47
<heycam>
[[Exposed=…][Constructor(…)] looks funny to me :)
21:48
<annevk>
needs moar ]
21:48
<annevk>
or less [ I guess
21:49
heycam
hopes to avoid mentioning "workers" in Web IDL itself
21:50
<heycam>
ok, time for coffee
21:58
<annevk>
I hope Kyle doesn't expect anyone to actually read those emails o_O
22:18
<annevk>
heycam|away: So the way you can do it is by having the [Global] annotation and then other specs can say [Expose=GlobalName]
22:19
<annevk>
heycam|away: plus maybe some shortcut so they two Worker globals can also have a shared Global name
22:19
<annevk>
heycam|away: that way you'd avoid mentioning specific globals yet we could still have per-global IDL