#whatwg on 2012-05-31

00:02	<heycam>	Philip`, that SVG-in-<img> is not scaling nicely when zooming the page is https://bugzilla.mozilla.org/show_bug.cgi?id=600207
00:33	<MikeSmith>	Hixie: looking into the cvs problem now
00:59	<MikeSmith>	Hixie: cvs problem should be fixed now
01:06	<Hixie>	MikeSmith: k thanks
04:11	<Hixie>	is there any equivalent of the fillText() method's last argument in CSS? something that says "try really hard to fit this text in this width"?
04:11	<Hixie>	i have a heading that i'd really like to have fit on one line, even if it has to be condensed to fit, regardless of screen width
04:11	<Hixie>	(it's only two words and on desktops it just looks fine but on some phones with particularly narrow screens it ends up wrapping to two lines which just looks ugly)
05:44	<MikeSmith>	looks like CSAIL has a major scheduled network outage on the weekend of June 9 and 10 that I think will mean bugzilla and probably a lot of other stuff will not be available
05:45	<MikeSmith>	mail too I guess
05:45	<Hixie>	k
05:57	<Hixie>	does JS have some mechanism by which an object can respond to method calls for methods i haven't yet defined?
05:58	<Hixie>	like perl's autoload?
05:58	<Hixie>	i have an object that represents something on the server but at the time the js object is instantiated i don't yet know what the object's type is cos i'm still waiting on the server
05:58	<Hixie>	the object's methods are all async
05:58	<Hixie>	so i want the methods, if called before i have the data, to just queue up the info and wait until we have it and then call back
06:01	<MikeSmith>	Hixie: google finds http://stackoverflow.com/questions/5422754/javascript-equivalent-of-perls-autoload
06:01	<MikeSmith>	no idea if that's helpful or not
06:02	<Hixie>	yeah, __noSuchMethod__ is what i want
06:02	<Hixie>	wonder if they're adding this to new ES versions
06:02	<MikeSmith>	I thought that was already in 5.1
06:02	<Hixie>	https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/NoSuchMethod (first hit on google) says "non-standard"
06:03	<MikeSmith>	oh
06:03	<Hixie>	hm, there's something called "proxies" in some version of JS
06:04	<Hixie>	blimey
06:05	<Hixie>	"simplicity" is the first thing on their requirements list
06:05	<Hixie>	but it's not clear that they managed it
06:06	<MikeSmith>	speaking of simplicity the powers that be in the CSS WG seem to be doing a great job making it a really good illustration of Conway's Law
06:06	<Hixie>	fullscreen?
06:06	<MikeSmith>	bingo
06:08	<Hixie>	yeah ok this proxies thing is going so far above my head i can't even feel it
06:08	<Hixie>	i guess i'll try something dumber
07:22	<dbaron>	MikeSmith, what has the CSS WG done to fullscreen?
07:25	<jgraham>	In the interests of what journalists like to call "balance" http://www.zdnet.com/blog/btl/women-in-tech-manuela-hutter-sees-endless-possibilities/68158
07:28	<annevk>	http://tumbledry.org/2012/05/30/5_things_about_television o_O
07:30	<MikeSmith>	dbaron: discussion on the chairs list
08:13	<annevk>	odinho: haha, that IDL typo bug
08:13	<odinho>	annevk: heh, yeah, embarrasing
08:13	<annevk>	notices double ;, does not notice glaring typo
08:14	<annevk>	that's a meme for the "IDL junky" face
08:18	<odinho>	annevk :P
08:18	<odinho>	annevk: I can said that was implied, too easy, anyone could see it :P
08:19	<wodemaye__>	how do i get at the hostname of an href the DOM-standard-compliant way?
08:20	<wodemaye__>	getElementsByTagName("a")[0
08:20	<wodemaye__>	oops
08:20	<wodemaye__>	is getElementsByTagName("a")[0].href.hostname standards-compliant?
08:21	<odinho>	wodemaye__: Don't think so, but it should be best to check spec.
08:21	<wodemaye__>	odinho, any specific place/doc u would look in?
08:21	<annevk>	wodemaye__: it.s [0].hostname
08:22	<annevk>	http://whatwg.org/C#htmlanchorelement
08:22	<wodemaye__>	annevk, is that guaranteed standards-compliant/cross-browser compatible?
08:22	<odinho>	wodemaye__: Write a test and test it :-)
08:22	<annevk>	well it's in the HTML standard
08:22	<annevk>	it probably works everywhere as it's ancient (iirc), but who knows
08:23	<wodemaye__>	annevk, but it's not deprecated?
08:23	<annevk>	no
08:24	<wodemaye__>	annevk, ur link fails.
08:24	<odinho>	wodemaye__: Works in Opera, Firefox, Chromium, and IE10. So that's them done.
08:24	<annevk>	DreamHost is having some issues I guess
08:24	<wodemaye__>	annevk, whatwg is hosted on dreamhost?
08:24	<annevk>	should work in a bit
08:25	<annevk>	yeah
08:25	<wodemaye__>	the goog couldn't spare a bit of hosting space, Hixie ?
08:26	<annevk>	they probably can, but we like to run the show without using company resources (other than time)
08:27	<odinho>	annevk: hmmz. the spec at w3, can't click stuff to get backlinks etc. Is that disabled for w3 compat mode?
08:28	<annevk>	odinho: W3C had issues with running scripts at some point
08:28	<MikeSmith>	no such issues now
08:28	<odinho>	wodemaye__: http://dev.w3.org/html5/spec/the-a-element.html#the-a-element http://dev.w3.org/html5/spec/the-a-element.html#dom-a-hostname
08:28	<MikeSmith>	the backlinks work in the author-view
08:29	<MikeSmith>	including the multi-page
08:29	<MikeSmith>	for the full spec, I thought I had them working, for the single-page version at leat
08:30	<odinho>	wodemaye__: Ah, look at author view instead. http://dev.w3.org/html5/spec-author-view/the-a-element.html#htmlanchorelement
08:30	<odinho>	MikeSmith: Yes, it did work in author view. :]
08:30	<MikeSmith>	I should fix it for the full spec if it's not working
08:31	<MikeSmith>	I guess I would notice these things if I actually used that when I needed to look up something
08:32	<odinho>	MikeSmith: lol, what do you mean, where do you look? at whatwg? at w3schools? (:P)
08:32	<odinho>	I gave you some heavy opposites there.
08:32	<jgraham>	MikeSmith is actually the secret villian behinf w3schools
08:32	<odinho>	babambmaaaaamm!!! :-o
08:33	<MikeSmith>	I put the "cool" in w3schools
08:33	<jgraham>	It is run from his HQ inside a Japanese volcano
08:33	<wodemaye__>	except there is no "cool" in w3schools.
08:33	<wodemaye__>	is w3s at all associated with w3c?
08:33	<annevk>	nope
08:33	<MikeSmith>	I only write my w3schools content when I'm loaded
08:33	<odinho>	lol
08:36	<MikeSmith>	the problem with sites like MDN is that they value accuracy too highly
08:36	<MikeSmith>	leaves no room for free improvisation
08:37	<wodemaye__>	loaded? MikeSmith
08:38	<MikeSmith>	wodemaye__: piped up
08:39	<wodemaye__>	MikeSmith, piped up?
08:39	<odinho>	MikeSmith: As a reader, there's also way too much relevant information on those pages, I find it much better when you can just get some incorrectly written super small non-helping description instead.
08:39	<MikeSmith>	odinho: now you're talking
08:39	<wodemaye__>	not a native english speaker so i don't know some slang, sorry.
08:39	<wodemaye__>	does it mean drunk?
08:39	<MikeSmith>	you'd understand w3schools much better if you used it while listening to Albert Ayler's "Love Cry"
08:40	<MikeSmith>	there are messages in there waiting to be heard
08:40	<wodemaye__>	but doesn'nt MDN specifically document the mozilla implementation of the standards?
08:40	<Ms2ger>	Not anymore
08:40	<wodemaye__>	Ms2ger, seriously?
08:40	<Ms2ger>	The documentation for web-exposed APIs should be vendor-neutral
08:42	<benvie>	they discuss vendor specifics but for all vendors
08:42	<benvie>	which is useful
08:42	<Ms2ger>	With help from paul_irish and other Googlers, too
08:43	<odinho>	Helpful list at the bottom too: https://developer.mozilla.org/en/http_access_control#Browser_compatibility
08:44	<odinho>	Although stuff does hang in there: Requires Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1)
08:44	<wodemaye__>	web-exposed APIs?
08:44	<odinho>	Well, Access-Control-Expose-Headers works in most all browsers now AFAIK, not just Gecko 2 :P
08:44	<odinho>	At least in Opera 12, which I know best.
08:45	<Ms2ger>	MDN also documents a lot of Gecko internals; not much point in trying to make those vendor-neutral
08:45	Ms2ger	glares at his inbox
08:46	<wodemaye__>	Ms2ger, i almost never used mdn cus i wanted to code to standards and not implementations, but holy shit there's some badass document'n in there.
08:46	<wodemaye__>	thanks dude. Ms2ger
08:46	<Ms2ger>	Np :)
08:47	<benvie>	it's often not clear when you've drifted out of the standard JS stuff into mozilla-specific land
08:47	<odinho>	benvie: Yeah, -- it would be nice to have them more seperated.
08:47	<benvie>	but it's usually noe just a section of an article, but like the whole section of the site
08:47	<benvie>	but they look the same and interlink
08:48	<odinho>	Although I can really see why Mozilla doesn't want to move it to a more neutral place :P
08:48	<Ms2ger>	There's been talk of separating them more, not sure how that's going ahead
08:48	<benvie>	hah yeah
08:48	<MikeSmith>	do we really not have any contributed test cases for postmsg?
08:49	<odinho>	I seem to remember Opera and Google wanting to part with their docs for a W3-hosted place like this. But Mozilla has the most thorough and best docs, so would be giving away most stuff by far.
08:49	<benvie>	well it seems like everyone's moving in the same general direction, which towards more js-centric and standardized in that fashion
08:49	<MikeSmith>	jgraham: btw and fwiw I agree it'd be better at this point to end the approved/submitted division
08:50	<wodemaye__>	benvie, what's a good/comprehensive/reliable/accurate documentation effort that aims primarily to document only standards with maybe some notes sprinkled through about implementation but explicitly made known as such.
08:50	<MikeSmith>	jgraham: I guess details about whether a test is approved or not could go into a manifest or something
08:50	<benvie>	well
08:50	<benvie>	I don't know that there is one
08:50	<Ms2ger>	jgraham, I approve of anything that makes the paths shorter, that would make life easier for thunderbird developers on windows :)
08:50	<benvie>	MDN does a good job as it is
08:51	<benvie>	so there's no push to redo its efforts
08:51	<wodemaye__>	what about the official w3/whatwg docs? those aren't the most readable...
08:51	<wodemaye__>	would u recommend referring to those often benvie ?
08:51	<benvie>	from my experience, the W3C specs combined with MDN are all that's eneded
08:51	<odinho>	MikeSmith: where is this email, if any?
08:51	<Ms2ger>	odinho, public-test-infra
08:52	<benvie>	let's see
08:52	<odinho>	All these lists I'm not on... finding
08:52	<benvie>	http://www.html5rocks.com/en/ is probably a big one for quality
08:52	<odinho>	benvie: Although often very WebKit-centric
08:52	<benvie>	yeah it's very much a google/webkit oriented thing
08:53	<wodemaye__>	benvie, but its fairly authoritative?
08:53	<benvie>	I guess it's kind of hard to find a party willing to put in the expertise resources to produce this content that ISN'T directly affiliated with one of the vendors
08:54	<Ms2ger>	Achievement unlocked: fantasai agrees with me on www-style
08:54	<jgraham>	Ms2ger: You sure?
08:54	<benvie>	and with how things are standardized, you can get away with doing a laege chunk of standardized...ish content that still favors your specific implementation's strengths
08:54	<benvie>	just because you know it best
08:54	<MikeSmith>	Ms2ger: watch out for lightening strikes
08:55	<jgraham>	Also, working backwards through time, lol windows
08:55	<benvie>	authoritative in this world is easy
08:55	<Ms2ger>	jgraham, yeah :/
08:55	<jgraham>	MikeSmith: Yeah that seems much more sensible to me
08:55	<benvie>	does it exist in an implemtnation or not
08:55	<benvie>	it either can be used or can't be
08:56	<Ms2ger>	jgraham, in a meta element! ;)
08:56	<jgraham>	Ms2ger: You unlocked the trolling #whatwg achievement a long time agao. No need to do it again :p
08:57	<Ms2ger>	Why thank you, dear
08:57	<benvie>	the web api sphere is a finely balanced dance of anarchy. It's like a house of cards that is reinforced by its own frailty
09:10	<MikeSmith>	benvie: a dancing spherical house of cards?
09:12	<Ms2ger>	Yay, unprefixed border-image coming to Gecko
09:12	Ms2ger	bets Opera did it first
09:12	<smaug____>	:p
09:13	<odinho>	Never gets old, does it :P
09:13	<Ms2ger>	No :)
09:15	<odinho>	Webbrowser getting bought by a website, Opera did it first (?) :
09:18	<smaug____>	well, ok, that is something NS managed to do first
09:18	smaug____	hopes the rumors about FB buying Opera aren't true
09:19	<odinho>	smaug____: Ah yes. Then it's no danger, because it's already done. So no reason to do it. *phew
09:22	wodemaye__	hopes they are true! :)
09:24	<smaug____>	it would be very sad to lose Opera to an evil empire.
09:24	<odinho>	It would be very sad to suddenly work for an evil empire.
09:24	<odinho>	I would probably even have to get a facebook account.
09:26	<AryehGregor>	zcorpan, yes, the stack trace can be annoyingly large, I agree. Unfortunately, since it's not in a standard format, we can't really do anything to make it better except not print it. Which is probably a good idea for most tests, but not for my crazy complicated tests. :)
09:28	<zcorpan>	AryehGregor: we should make it a standard already :-P
09:28	<AryehGregor>	annevk, in the United States, I noticed that after I kept an HTTP connection open for more than a second or so, bandwidth dropped drastically. I suspect my ISP was prioritizing short-lived TCP connections to benefit typical HTTP over long downloads and such.
09:29	<AryehGregor>	(which is a good form of network non-neutrality, IMO, although it might do the wrong thing for videoconferencing)
09:30	<annevk>	this was ssh
09:30	<AryehGregor>	(it shouldn't hurt VoIP as long as they only throttle the bandwidth of long-lived connections)
09:30	<AryehGregor>	Right, but they'd want to hit BitTorrent and FTP too, so if I were them I'd just do it at the TCP level and ignore the protocol.
09:30	<AryehGregor>	That also means you don't have to actually inspect the traffic.
09:30	<AryehGregor>	Which is good because often you can't.
09:48	<jgraham>	AryehGregor: FWIW we don't actually have any local branches yet
09:49	<jgraham>	But it is a use case we have had, and addressed badly for non-W3C testsuites so it doesn't seem unlikely that we will have to address it for W3C ones
09:50	<jgraham>	(e.g. if there is some test that hardcodes domains due to testing document.domain, we would want to patch it to use different domains)
09:51	<jgraham>	Life would be much easier if Hixie didn't sleep. Does anyone understand navigation well enough to explain https://www.w3.org/Bugs/Public/show_bug.cgi?id=17245 to me?
09:54	<annevk>	didn't we have a copy of the Design Principles on the WHATWG Wiki at some point?
09:54	<AryehGregor>	jgraham, why not just fix it in the repo? You have commit access.
09:54	<annevk>	or was it a W3C Wiki page?
09:56	<odinho>	AryehGregor: Hmmm. Like it is now, it's not looked nicely upon to go into other vendors folders and just rewrite them :P
09:56	<annevk>	http://www.w3.org/html/wg/wiki/ProposedDesignPrinciples
09:56	<AryehGregor>	odinho, I think it's considered fine once they're formally submitted, at least if you talk to the submitter first, right?
09:56	<AryehGregor>	It should be, anyway . . .
09:56	<annevk>	seems to be have become quite the mess
09:57	<jgraham>	AryehGregor: Fix what?
09:57	<AryehGregor>	jgraham, if the test isn't usable from non-W3C-land.
09:57	<odinho>	AryehGregor: yea, -- but I don't feel like I should mess around in e.g. the submitted/Microsoft/ folder, I don't belong in there.
09:58	<jgraham>	It is quite possible that for some tests different servers will be needed on the public internet and on our internal network
09:58	<AryehGregor>	odinho, I think CSSWG policy, at least, is that you're allowed to. Anyway, you certainly can give it as feedback before it gets approved.
09:58	<Ms2ger>	odinho, I'm happy to mess around in the Opera folders ;)
09:58	<AryehGregor>	jgraham, sure, but there should be some way to do that without patching the tests.
09:59	<MikeSmith>	annevk: it seems like there was something on the WHATWG wiki
09:59	<jgraham>	AryehGregor: Perhaps, I guess it depends on the details of the tests
09:59	<MikeSmith>	um, what does "frictionless" mean in terms of Web development?
09:59	<odinho>	AryehGregor: Yea, I already have a support.js file where you can set some variables. Those should be possible (and most maybe want) to override at least.
10:00	<odinho>	Ms2ger: Yea, I'm okay with people messing around in the Opera folder. We're just that kind of company ^^
10:01	<annevk>	MikeSmith: I cannot find it
10:01	<jgraham>	In any case I wouldn't like to design in the assumption that we will never have to make local patches
10:03	<MikeSmith>	annevk: yeah, I can't either
11:12	<jgraham>	There's nothing I like more than spec threads where someone says "we should change the spec to say X" and then others say "yeah we changed our implementation to do that already (but didn't tell anyone)"
11:12	<odinho>	Seems to have been a few lately.
12:00	<MikeSmith>	how is the word skägg pronounced?
12:02	<jgraham>	If you are a human? By configuring your vocal chords/tounge/lips in the correct way and modulating the flow of air through them as needed. If you are Ms2ger? By sending electrical signals that cause vibrations in the cone of a speaker.
12:03	<jgraham>	I imagine
12:03	<jgraham>	Not that I have ever examined his hardware of course
12:06	<zcorpan>	MikeSmith: http://sv.forvo.com/word/sk%C3%A4gg/#sv
12:08	<MikeSmith>	tack
12:10	<Ms2ger>	*takk
12:10	<annevk>	zcorpan: we should nail down that list then
12:12	<MikeSmith>	annevk: plh is going to shut down our working group if we don't get remaining issues resolved and publish a LCWD
12:12	<MikeSmith>	charter expires in 1 month
12:15	<annevk>	MikeSmith: for a guy that claims to care about patent commitments he seems to care little
12:16	<annevk>	MikeSmith: did he miss that Apple joined the Notifications WG?
12:16	<MikeSmith>	no, he knows that
12:16	<MikeSmith>	he would just kind of like to see some actual further progress made on the spec I guess
12:17	<annevk>	I did actually ping John again earlier today
12:17	<annevk>	apparently he's on the YouTube team so doesn't have much time
12:17	<annevk>	but I'll see what he says
12:18	<annevk>	I happen to not care much for WGs so threatening to close mine down seems counter-productive
12:18	<MikeSmith>	k
12:18	<annevk>	but I do care somewhat about Notifications
12:19	<Ms2ger>	Shut down the WG and move to the WHATCG?
12:19	<MikeSmith>	annevk: I wonder whether other John might be willing to work on the spec
12:19	<MikeSmith>	John Lee
12:19	<MikeSmith>	Apple
12:20	<MikeSmith>	he seems a bit more motivated right now
12:21	<MikeSmith>	annevk: hey there's a new CSS group for you to join
12:21	<MikeSmith>	http://www.w3.org/community/blog/2012/05/31/proposed-group-css-specifications-community-group/
12:21	<MikeSmith>	no idea who floated that one
12:21	<MikeSmith>	"This group addresses and discusses proposed ideas for CSS specifications."
12:21	<MikeSmith>	both addresses and discusses
12:21	<MikeSmith>	in that order
12:22	<annevk>	MikeSmith: we could ask him if John doesn't do anything
12:22	<annevk>	MikeSmith: or I could do it; I have some time now
12:22	<MikeSmith>	whatever works for you
12:23	<annevk>	I have doubts John Lee has the time
12:23	<MikeSmith>	OK
12:25	<zcorpan>	hmm, seems nobody supports MutationNameEvent?
12:25	<annevk>	s/hmm, seems/yay/
12:25	<Ms2ger>	Seems correct for Gecko
12:26	<annevk>	also Opera/WebKit checking window.MutationNameEvent
12:27	<gsnedders>	wilhelm: Given you keep on complaining about it, you might be interested in what the latest snapshot has a fix for. ;)
12:27	<annevk>	IE also doesn't have it
12:28	<Ms2ger>	IE10?
12:28	<annevk>	ooh
12:28	<annevk>	MutationNameEvent was a DOM Level 3 Events addition?
12:28	<annevk>	it's not in http://www.w3.org/TR/DOM-Level-2-Events/events.html anyway
12:29	<Ms2ger>	For document.renameNode(), apparently
12:29	<zcorpan>	filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=17270
12:29	<annevk>	fast zcorpan is fast
12:31	<wilhelm>	gsnedders: I have already been informed. Thanks, I'll try it out. (c:
12:32	<annevk>	I guess it would prudent to check Level 3 against Level 2 to see what else was added that's not actually useful
12:33	<kennyluck>	Can we publicly criticize Google on the WHATWG blog for not making enough effort in the standardization work?
12:33	<MikeSmith>	eh?
12:33	<Ms2ger>	And Apple?
12:33	<Ms2ger>	And Mozilla?
12:33	<Ms2ger>	And Microsoft?
12:33	<zcorpan>	and w3c?
12:33	<MikeSmith>	heh
12:33	<Ms2ger>	Not Opera, I guess
12:33	<zcorpan>	nope, we did it first
12:34	<gsnedders>	We shipped a Native HTML6 implementation last year.
12:34	<Ms2ger>	You were first not to make enough effort?
12:34	<Ms2ger>	Glad you got over that, then ;)
12:35	<annevk>	kennyluck: if that's the summary of the post I'm not sure how that's a useful post for the WHATWG blog
12:35	<kennyluck>	shrug
12:36	<gsnedders>	kennyluck: What's the justification for them not putting in enough effort?
12:36	<MikeSmith>	kennyluck: shop that idea out to due at .Net magazine. I bet he'd love it
12:37	<kennyluck>	gsnedders, why ask me? It seems pretty clear that we have very little or no expectation for Apple, but Google… hmm...
12:37	<annevk>	so why do FocusEvent and such still have init*Event()?
12:38	<zcorpan>	why does DOMActivate still exist in the spec?
12:38	<zcorpan>	why does DOM3 Events still suck?
12:38	<zcorpan>	so many questions :-)
12:39	<kennyluck>	why does CSS2.1 read like an advanced tutorial instead of a spec?
12:39	<annevk>	because it's CSS 2.0 patched instead of the rewrite it deserved
12:40	<Ms2ger>	I guess that applies equally to D3E
12:40	<annevk>	Media Queries too :(
12:42	<Ms2ger>	ALL THE SPECS
12:43	<Ms2ger>	Who's going to try and get CSS to define what "critical subresources" are?
12:44	annevk	frowns
12:46	<MikeSmith>	if berjon is working on updating the WebIDL stuff in respec, would be good to update it to use the same biblio stuff as anolis
13:57	<annevk>	I hope he succeeds
14:02	<codacoder>	anyone here?
14:06	<jgraham>	No
14:06	<codacoder>	I can tell ;)
14:07	<codacoder>	it's that vacant look
14:08	<jgraham>	We're so pretty
14:08	<codacoder>	Was hoping someone could explain something about the specs - specifically, about DEPRECATED/OBSOLETE
14:08	<codacoder>	lol
14:08	<codacoder>	a Brit I see. Prob as old as me too
14:08	<Philip`>	Which specs?
14:09	<codacoder>	html5
14:09	<Philip`>	HTML5 doesn't do deprecated - things are either allowed, or not allowed
14:09	<jgraham>	Some are "obsolete but conforming"
14:09	<Philip`>	(which is totally independent of whether browsers must implement support for those things or not)
14:09	<jgraham>	Which sounds a lot like "deprecated with delicious figs"
14:10	<codacoder>	well... yes... but the spec I'm reading seems to be sitting painfully right on the fence re obsolete
14:10	<Philip`>	I think "deprecated" is more like "conforming but obsolete"
14:10	<codacoder>	Phil: yep
14:11	<codacoder>	I woundered why, then, there's a whole section on rendering obsolete crap
14:11	<codacoder>	so a definition of obsolete would be good
14:12	<Philip`>	Most people write non-conforming content (never mind obsolete-but-conforming content), so browsers are required to render that stuff correctly anyway, because that's necessary for real-world interoperability
14:12	<codacoder>	example: FRAMESET
14:12	<codacoder>	I agree - but the spec is not clear about what it means
14:13	<codacoder>	as a reader, it's not clear and can cause endless "going in circles" trying to tie it down
14:13	<Philip`>	"obsolete" means nothing more than "conformance checkers will warn about this" and "the spec writers would prefer you not to do this (but we know you're going to anyway)"
14:13	<codacoder>	right
14:13	<Philip`>	(Rather, "obsolete but conforming" means that)
14:14	<Philip`>	frameset is entirely non-conforming, which means "conformance checkers will give an error about this" and "the spec writers would prefer you not to do this (but we know you're going to anyway)"
14:14	<codacoder>	I guess it's an unfortunate flow I'm "carrying" that, deprecated -> obsolete -> gone
14:15	<Philip`>	The "obsolete -> gone" step never occurs in practice
14:15	<codacoder>	agreed
14:15	<Philip`>	(Browsers still support things that were deprecated in the first ever published HTML specs)
14:15	<codacoder>	but the spec does not make that clear, is my point
14:15	<codacoder>	I know
14:16	<zcorpan>	codacoder: the spec usually says something like "authors must not do X" and then "user agents must do Y when authors do X"
14:16	<codacoder>	context: I'm writing a test suite, I wanna make sure my wording is as correct as poss
14:16	<zcorpan>	test suite aimed at browsers?
14:17	<Philip`>	Would it be clearer if somewhere like http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#obsolete repeated something like the text from http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#conformance-requirements-for-authors ("this specification defines in some detail the required processing for invalid documents as well as valid documents.")?
14:17	<codacoder>	and to "defend" my statements i need a "source" <- the spec aint helping (much)
14:17	<codacoder>	reading...
14:17	<zcorpan>	what are you testing?
14:17	<codacoder>	test-suite aimed at browser based app
14:20	<zcorpan>	if your test is testing the user agent (the browser), then you should ignore all requirements on authors/documents
14:20	<codacoder>	no, it's testing the content
14:22	<codacoder>	Philip: it needs to be clear what obsolete means in practice
14:23	<codacoder>	I think (IMO) it's less than clear and is missing the (old) "MUST" etc definitions. What I've read is wishy-washy (sorry)
14:26	<Philip`>	I think in pretty much every case there is a relevant series of "must"s somewhere in the spec, but it tries to only require things once and then uses wishy-washy language elsewhere to describe consequences of those requirements
14:26	<kennyluck>	Yeah, I guess I don't get the "obsolete but conforming" idea either. So here's a concrete question: If I were to write a book about HTML, should I include elements/syntax that are "obsolete but conforming"?
14:26	<Philip`>	and it's hard to find the right "must" if you don't know where to look
14:27	<codacoder>	kenny: Zackly!
14:27	<codacoder>	any of you here part of the authorship team?
14:27	<jgraham>	kennyluck: No
14:27	<Philip`>	kennyluck: If you're writing a reference book for people who have to maintain old pages, you should include everything that's ever used in practice, including non-conforming features
14:28	<jgraham>	(unless it is some very special case like Philip` says)
14:28	<kennyluck>	Philip`, yes, but what I am talking about new books. I don't exactly get what the middle class is for.
14:28	<codacoder>	Imagine - test fails. Reason: blah. Why -> link
14:28	<jgraham>	If you were writing a handbook for implementors with a catchy title like "HTML: Living Standard" then yes
14:28	<Philip`>	kennyluck: If you're writing a tutorial-style book for new content authors, you should just describe the features that you think they ought to use, which should be a subset of the non-obsolete conforming features
14:29	<codacoder>	It's almost impossible using the spec as it is
14:29	<Philip`>	(There's probably a lot of conforming features that aren't worth taking the effort to describe, so it depends on where you choose to focus as the author of the book)
14:30	<codacoder>	or in my case as the author of tests
14:30	<webben>	Philip`: "The "obsolete -> gone" step never occurs in practice". I wonder if that's really true. Didn't that happen with <layer>?
14:30	<kennyluck>	That I don't quite agree. I thought the whole point of making a subset of what browsers implement conforming is for educational purposes and yet you are telling me to build my own thing.
14:31	<Philip`>	webben: As far as I'm aware, that was never supported outside of Netscape
14:31	<Philip`>	(and never in a spec)
14:31	<codacoder>	layer was netscape - not a spec
14:32	<webben>	Philip`: True AFAIK, though a single browser supporting something is not necessarily a blocker to it becoming widespread in the corpus.
14:32	<webben>	Maybe <layer> never did.
14:33	<codacoder>	sticking to my point tho - this spec is too loose in the context i mentioned. It's not aiding me aid "them"
14:33	<Philip`>	http://philip.html5.org/data/tag-count-pages.txt says <layer> is on about 1% of pages, but I think it's almost always perfectly acceptable to treat it like <span>, which is what most browsers do now
14:34	<webben>	codacoder: I find it easiest to think of these things as: browsers need to support whatever features are needed to give users access to the corpus. authors should be encouraged to use whatever features give the best results for users
14:34	<Philip`>	codacoder: Could you give a more concrete example of the kind of information you can't find in the spec?
14:35	<codacoder>	said it earlier - may have scrolled past... imagine: test fails. Reason: blah. Why -> link
14:35	<webben>	codacoder: Yeah ... like what test are you unsure how to write?
14:35	<codacoder>	webben: I am not unsure
14:35	<codacoder>	I know exactly what I want to write
14:35	<Philip`>	kennyluck: I think there's a fundamental problem with different people having different ideas on what's a good subset for educational purposes; the spec just gives one idea (its notion of conformance) and a compromise with a slightly different idea (its notion of obsolete but conforming), under the belief that it's better to say something than nothing
14:36	<webben>	codacoder: Are you writing a document conformance checker of some sort?
14:36	<codacoder>	no - a test suite
14:36	<Philip`>	but that doesn't preclude anyone else from coming up with their own definition of 'good' HTML
14:36	<codacoder>	runs against an app
14:36	<Philip`>	codacoder: That didn't sound very concrete to me :-)
14:36	<webben>	codacoder: But testing for HTML conformance violations?
14:37	<codacoder>	Philip: test is (eg) FRAMESET or CENTER
14:37	<webben>	codacoder: You're looking for some text to link to that gives rationale for why FRAMESET (say) is not conforming HTML?
14:38	<codacoder>	more detail... $("center").length === 0
14:38	<codacoder>	webben: yep
14:38	<codacoder>	it's too linky-linky-linky
14:38	<webben>	codacoder: It would be nice if the spec had rationale for all its design decisions, but I'm not sure that's realistics.
14:38	<codacoder>	like i said, it's not helping me help them
14:39	<codacoder>	and the terminology is way too wishywashy
14:39	<webben>	codacoder: For one thing, to a large extent the spec is an artefact of compromises.
14:39	<codacoder>	webben: you got it nailed there
14:39	<webben>	codacoder: So it's not necessarily reducible to fundamental design principles.
14:40	<webben>	codacoder: Worse still, this is true of pretty much all specifications where multiple parties need to agree, so the spec isn't really exceptional here.
14:40	<webben>	codacoder: Also, the rationale could easily be longer than the spec itself...
14:41	<webben>	codacoder: There are occasional efforts to write up some rationale outside the spec tho.
14:41	<codacoder>	I sort of agree. But in this case (dare I say it) the w3c older specs were better
14:42	<webben>	codacoder: http://wiki.whatwg.org/wiki/FAQ#Is_design_rationale_documented.3F
14:42	<codacoder>	in this regard, HTML5's definition of obsolete has no teeth and becomes pretty meaningless
14:42	<codacoder>	thanks
14:42	<webben>	codacoder: The older specs omitted a lot of rationale.
14:42	<webben>	They also omitted a lot of spec ;)
14:43	<webben>	codacoder: HTML5's definition of obsolete seems pretty straightforward.
14:43	<kennyluck>	Philip`, that's reasonable. But just like some people write specs because browser implementers don't bother reverse engineering each other. The idea of a conforming class for authors should be similar: not everyone would bother reading all rationale and going into the debates of why something is conforming and not and come up with his/her own class. The existence of the class in the middle means that the spec doesn't address this use
14:43	<codacoder>	understand I'm not here to "knock the specs" - here to improve them if I can
14:43	<webben>	Not sure what teeth you expect it to have.
14:43	<webben>	codacoder: Yep, understood.
14:44	<codacoder>	obsolete is absolutely (my baggage acknowledged) meaningless
14:44	<webben>	codacoder: It just means discouraged. That's it.
14:44	<codacoder>	and if I managed to link to the right spot in the spec, it would go against me, not for me
14:44	<codacoder>	but that was what deprecated means (meant)
14:45	<webben>	codacoder: No.
14:45	<webben>	codacoder: Deprecated implied future UAs could drop support.
14:46	<codacoder>	haha. see? it's a freakin nightmare!
14:47	<codacoder>	when i said "my baggage" this is what I meant!
14:47	<webben>	codacoder: I don't think these terms have ever been used or understood consistently. But you can just use the definition in the spec at hand.
14:47	<codacoder>	If i had a spec that was definitive (what else is a spec for at base values?) It would remove ALL baggage!
14:47	<webben>	codacoder: It is definitive.
14:48	<codacoder>	nope - it's "loose"
14:48	<codacoder>	I guess I should code as though I was writing a validator and take their suggestions for that
14:49	<webben>	codacoder: I don't get how http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html is loose.
14:49	<webben>	codacoder: It says authors must not use X, conformance checkers must warn about X, user agents must do Y with X.
14:50	<webben>	codacoder: In your test justification text, you could entirely ignore the language about "obsolete" if you think it's confusing.
14:50	<codacoder>	which is a toothless definition of obsolete
14:50	<kennyluck>	It says author should not use X.
14:50	<codacoder>	right
14:50	<kennyluck>	It really should be "must not" if that's the intention.
14:51	<webben>	kennyluck: Only for obsolete but conforming.
14:51	<codacoder>	I guess we're getting to it now... what in the hell does obsolete mean? I think they need a different term
14:51	<kennyluck>	I think it should probably be called "non-conforming but only triggers warning in conformance checker class"
14:52	<webben>	codacoder: Use the dictionary definition: http://www.merriam-webster.com/dictionary/obsolete
14:52	<codacoder>	webben: it's not about my ignoring something... it's about where I send a failing programmer to read something - what he reads should be clear, meaningful and "absolute"
14:52	<codacoder>	kenny: yep
14:52	<webben>	it is absolute
14:53	webben	shrugs
14:53	<codacoder>	webben: within its own confined context <- I say its chosen a bad one
14:53	<webben>	I'd prefer "discouraged" to "obsolete but conforming" and "forbidden" to "obsolete".
14:54	<codacoder>	RIGHT - much better
14:54	<webben>	In general, changing what goes into these categories let alone what they are called is a political minefield.
14:55	<codacoder>	oh yes.
14:55	<codacoder>	however, it should be better than it is
14:55	<webben>	Compromise often does result in things that are worse than they should be, but are better than not having them at all.
14:56	<codacoder>	agreed
14:56	<webben>	I often feel we'd have been better off just not bothering with author conformance requirements and leaving the whole business to linters.
14:57	<webben>	If nothing else it would have saved a lot of fairly pointless arguments.
14:57	<codacoder>	you got it
14:57	<kennyluck>	webben, that's true.
14:58	<codacoder>	in many ways, this entire conv is "evidence"
14:58	<webben>	I've been involved in a lot of those arguments, trying to make the conformance requirements make sense (from my perspective).
14:58	<webben>	It's very difficult to get people to agree.
14:58	<webben>	And I don't much like the set of conformance requirements we've got at the moment.
14:58	<jgraham>	No it's not!
14:58	<webben>	:)
14:58	<codacoder>	lol
15:00	<kennyluck>	But still, the problem here is quite obvious. "conforming" and "should not" are opposite words.
15:00	<webben>	kennyluck: They're not.
15:00	<webben>	kennyluck: That's standard IETF stuff.
15:00	<webben>	kennyluck: SHOULD NOT = don't do unless you've got good reason
15:00	<webben>	kennyluck: MUST NOT = non-conforming
15:01	<kennyluck>	webben, hmm.. ok I guess it makes some sense now.
15:03	<codacoder>	LEt's say I link to 15.2 (http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html) because someone has used (say) FRAMESET
15:03	<codacoder>	they read, then click on Frameset link...
15:04	<codacoder>	which takes them to a section talking about how frameset is meant to work (which is hardly my personal definition of obsolete)
15:04	<kennyluck>	webben, the IETF RFC for these keywords doesn't define what "conforming" means so I can't tell if that's true though. http://tools.ietf.org/html/rfc2119
15:05	<kennyluck>	I think the normal practice is, though, when writing a test suite, is to include those "should"s and "should not"s.
15:05	<kennyluck>	In that sense, a violation of "should" seems to indicate that it is non-comforming… but I am not sure...
15:05	<codacoder>	kenny: agreed. I wanted to use the spec as definitve "why" - complaint is, it's not
15:08	<codacoder>	will you guys all sign wavers so I can store this entire thread in my tests? LOL
15:09	<codacoder>	anyway, I'm out of here. Thanks. It was informative and "confirming" (if not conforming) ;)
15:10	<kennyluck>	I have no problem and the channel log is public (see title) anyway.
15:10	<Philip`>	codacoder: "$("center").length === 0" - that makes it sound like you're implementing a conformance checker
15:10	<Philip`>	which would be an easier way to describe the problem :-)
15:11	<codacoder>	ok - just for Philip: that's only a tiny part of it, but yes, in this context, it pretty much is
15:12	<codacoder>	the test engine tests app functionality too
15:13	<codacoder>	ok going this time. Thanks again all.
15:13	<annevk>	smaug____: http://www.w3.org/TR/progress-events/#interface-progressevent
15:13	<annevk>	smaug____: btw
15:13	<odinho>	Seems I was under the false impression that Firefox nightly didn't allow sync XHR with CORS. But testing it, it does in fact do that.
15:13	<annevk>	smaug____: did Gecko disable cross-origin XMLHttpRequest?
15:14	<annevk>	oh
15:14	<odinho>	So time seems to be running out for that.
15:14	<odinho>	I don't see how they can wait so long with it if Moz really wants to do it.
15:15	<odinho>	annevk: A mozilla girl said it at the F2F. :-)
15:17	<smaug____>	annevk: disable CORS?
15:17	<smaug____>	oh, sync
15:17	<smaug____>	I don't think so
15:17	<smaug____>	sicking did suggest that
15:18	<smaug____>	annevk: yes, ProgressEvents spec has that, but implementations do have, IIRC, init*Event
15:18	<smaug____>	and createEvent("progressevent"); is supported, again, IIRC
15:18	<smaug____>	also some event related to storage handling...
15:19	<smaug____>	annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=736058
15:19	<annevk>	and bugs cannot be fixed?
15:19	<annevk>	aah
15:19	<annevk>	what nonsense is that
15:19	<annevk>	for a test you add that?
15:20	<odinho>	smaug____: So then I don't have to rewrite the CORS-tests to be async? Well, I'll make them more readable again then :P
15:21	<smaug____>	well, we haven't disabled CORS yet
15:21	<smaug____>	odinho: would be better to ask sicking
15:21	<smaug____>	I think disabling CORS could be quite risky
15:22	<odinho>	Yes, seems to be, esp. after CORS with sync XHR has worked for so long on the wild web.
15:22	<odinho>	But you have some release trains to test with.
15:25	<smaug____>	unfortunately surprisingly many sites are tested only with release builds
15:25	<smaug____>	but
15:25	<smaug____>	hmm
15:25	<smaug____>	perhaps a warning first
15:25	<smaug____>	"CORS with sync XHR will be disabled"
15:26	<smaug____>	warning are effective in some cases
15:26	<smaug____>	+s
15:30	<odinho>	smaug____: I meant for sitecompat, - I guess you'll have people reporting broken sites etc.
15:30	<smaug____>	sure
15:31	<smaug____>	but certain kinds of sites are used only with release builds
15:31	<smaug____>	like intranets
15:31	<smaug____>	some intranets
15:31	<odinho>	So if they're like "omg web iz broken!1" it might be hard, but if it's all like ... crickets ... it might be more okay.
15:31	<odinho>	smaug____: Yeah, I can see that.
15:58	<dglazkov>	good morning, Whatwg!
16:41	<TabAtkins>	Ms2ger: What spec talks about "critical subresources"?
16:41	<Hixie>	html
16:41	<Ms2ger>	CSS doesn't, that's the issue :)
16:41	<TabAtkins>	Ms2ger: Okay, then I don't get the context.
16:41	<Ms2ger>	https://www.w3.org/Bugs/Public/show_bug.cgi?id=17011
16:42	<TabAtkins>	Ah, kk. Was wondering if you were just kvetching about a CSS problem without bringing it up with us again. ^_^
16:43	<TabAtkins>	Hixie: If you need any help with Proxies for whatever reason, I can help. They're not hard.
16:44	<Hixie>	i want an object that just forwards all unknown method calls to another
16:44	<TabAtkins>	"critical subresources" sounds like it's potentially a useful term for CSS to define anyway.
16:44	<Hixie>	it's like 2 lines of code in perl
16:44	<TabAtkins>	Hixie: Slightly more than two lines in JS, but not much.
16:45	<Hixie>	it looked to be a lot more than two when i was looking at the proxy api
16:45	<Hixie>	and some long lines of unintuitive api calls at that
16:45	<TabAtkins>	You were looking at "proxy" instead of "direct proxy", weren't you.
16:46	<TabAtkins>	(It's the first google hit, I know.)
16:46	<Hixie>	no idea what the difference is
16:46	<Hixie>	i was looking at brendan' slide show, amongstother things
16:46	<TabAtkins>	The wiki page says, right at the top, that the "proxy" proposal is obsolete and superceded by direct proxies.
16:47	<TabAtkins>	iirc, all you need is:
16:47	<Hixie>	oh. if the stuff i was reading is dead then that's awesome.
16:48	<Hixie>	it was all claiming to be accepted and stuff
16:48	<Hixie>	is there a spec somewhere?
16:48	<Hixie>	that represents the latest thinking on js?
16:49	<Hixie>	[javascript direct proxy] doesn't help me
16:49	<TabAtkins>	var wrapped = Proxy(obj, {get: function(target, name, receiver) { if( methodIWantToCatch(name) ) { return doStuff(name); } else return target[name]; });
16:50	<TabAtkins>	http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies
16:50	<Hixie>	yeah, that looks like what i was looking at
16:51	<TabAtkins>	Okay, that's not exactly hard.
16:51	<Hixie>	surely what you describe would result in the \|this\| pointing to the wrong object
16:51	<Hixie>	i want it pointing at the thing i'm proxying, not the proxy
16:51	<TabAtkins>	No, it works.
16:52	<Hixie>	how?
16:52	<TabAtkins>	The "return target[name]" part soft-binds this appropriately.
16:52	<TabAtkins>	For the unknown properties.
16:52	<TabAtkins>	var wrapped = Proxy(obj, {get: function(obj, name) { if( methodIWantToCatch(name) ) { return doStuff(name); } else return obj[name]; });
16:53	<TabAtkins>	Easier to see now?
16:53	<Hixie>	oh sorry i think i misexplained
16:53	<Hixie>	let me be more clear
16:54	<Hixie>	i'm creating an object A at time t0. When A is created, it does a network request, and at time t1>t0, i'll use that data to create an object B. I want all calls to A to get proxied to B once A has created B.
16:55	<TabAtkins>	And before A has created B, what happens?
16:55	<Hixie>	does that make sense?
16:55	<Hixie>	before A has been created, some other code I write will do stuff, in particular, it will queue the requests to be run once I have B (all these calls are async)
16:56	<Hixie>	A will also have other methods
16:56	<Hixie>	e.g. to see how the network is doing
16:56	<TabAtkins>	Okay, the line I have above will work, with the obvious modifications inside the get trap.
16:56	<Hixie>	(an alternative would be for A to replace itself with B somehow... maybe i can do that with some prototype magic)
16:56	<Hixie>	your use of the word "obvious" is foreign to me :-P
16:56	<TabAtkins>	Check if the property being got is one that A "natively" has. If so, do it.
16:57	<TabAtkins>	Otherwise, check if B has been craeted. If not, queue it up. If so, forward it.
16:57	<Hixie>	what is "obj" in the first argument to Proxy?
16:57	<TabAtkins>	You can't swap things out. A has to be a Proxy the whole time.
16:57	<TabAtkins>	The object that you're wrapping with the proxy.
16:57	<Hixie>	A?
16:58	<TabAtkins>	No, it's B.
16:58	<TabAtkins>	A is the proxy.
16:58	<Hixie>	B doesn't exist yet
16:58	<TabAtkins>	Right.
16:58	<TabAtkins>	So.
16:59	<TabAtkins>	Hm.
16:59	<Hixie>	(what if i'm proxying to different objects depending on what the method is? or one of the arguments?)
17:00	<Hixie>	i just want to trap "method was called but not defined", i don't really want the JS system to know i'm proxying
17:00	<TabAtkins>	The JS doesn't know that you're proxying. That's the point of proxies - they're undetectable except by the isProxy method.
17:00	<TabAtkins>	So actually, I got it. You need some indirection because of your swap-out.
17:01	<Hixie>	i mean the JS compiler
17:01	<TabAtkins>	Then you have to invoke magic.
17:01	<smaug____>	ah, innerHTML serializes html:script and svg:script in a different way.
17:01	<TabAtkins>	Magic which is perfectly possible to do with proxies.
17:01	<TabAtkins>	Why do you care aout the J?S compiler?
17:02	<Hixie>	TabAtkins: oh i completely believe this is possible, my thesis is just that it's way more complicated than perl.
17:02	<smaug____>	hsivonen: ping
17:02	<TabAtkins>	I... somehow doubt that your actual use-case is two lines in perl.
17:02	<Hixie>	TabAtkins: i don't care about the compiler, i mean, if it needs to know it needs to know, i just don't know why i need to tell it
17:02	<TabAtkins>	A simple "forward everything I dont' have to thsi other object", sure.
17:03	<TabAtkins>	But you actually want something more complicated.
17:03	<Hixie>	use AutoLoader; sub AUTOLOAD { ...do whatever i want with $AUTOLOAD... }
17:03	<Hixie>	the code in that block will get run for any undefined method
17:04	<TabAtkins>	While not built-in, that's doable easily with the line I posted above.
17:04	<Hixie>	(it's almost identical to __noSuchMethod__, which would work fine too)
17:04	<Hixie>	TabAtkins: i believe that it's doable, i just don't see how
17:04	<TabAtkins>	Okay, let me send you an email with real code.
17:04	<Hixie>	k :-)
17:05	<TabAtkins>	Proxies is purposely a low-level API that allows any other proxy-style abstraction to be built on top, so it maps directly to ES's fundamental operations.
17:06	<Hixie>	yes
17:06	<MikeSmith>	TabAtkins: maybe post it as a gist and link to it here (along with e-mailing to Hixie). for people wandering across the logs
17:06	<Hixie>	TabAtkins: again, i'm not arguing that it's not powerful, or whatnot, just that it isn't simple.
17:07	<Hixie>	TabAtkins: i'm sure it is great for people who understand JS fundamentals
17:07	<TabAtkins>	Okay, I'll grant you that. I think it's simple because it's easy to think about in terms of those fundamentals, and easy to build abstractions on top of.
17:07	<TabAtkins>	MikeSmith: Sure, I'll do a blog post.
17:08	<Hixie>	when i look at the API definition and the first thing I see is "getOwnPropertyDescriptor", i wonder how many JS authors have any clue what that means
17:08	<TabAtkins>	The fundamental traps are confusing. ^_^ Most of the time you just need to worry about the derived traps like "get".
17:09	<Hixie>	i guess what i don't understand is the difference between "proxy" and "target". If I just want to have an object that traps all these operations, it's unclear to me whether that's the Proxy object, or the object I pass to the Proxy method.
17:09	<Hixie>	(also why is it a method and not a constructor?)
17:10	<TabAtkins>	It's a constructor. A lot of the fundamental constructors dont' require "new".
17:10	<Hixie>	that's confusing
17:10	<gsnedders>	[[Construct]] is mostly just a slightly magic [[Call]]
17:10	<TabAtkins>	The proxy stands between the author and the target.
17:11	<Hixie>	say i wanted to make an object that just logged all these traps
17:11	<Hixie>	so if i call foo.bar, it says "getting bar!"
17:11	<Hixie>	and if i call foo.quux = 2, it says "setting quux!"
17:12	<Hixie>	how do i do that?
17:12	<Hixie>	var proxy = Proxy(null, { get: ... }); ?
17:12	<Hixie>	var proxy = Proxy({}, { get: ... }); ?
17:12	<TabAtkins>	Proxy({}, {get: function(obj,name){ console.log("getting "+name+"!"); }, set: function(){...}), ...});
17:12	<Hixie>	ok
17:13	<Hixie>	i think it's ridiculous that you have to pass {} in that case.
17:13	<Hixie>	that's what i mean by "i don't want to have to tell the compiler what i'm proxying"
17:13	<TabAtkins>	It wasn't seen as worthwhile to provide a variant API that is in all ways identical to just passing an empty object as the first argument.
17:14	<Hixie>	i don't understand what the purpose of that argument is at all
17:14	<TabAtkins>	Though there is http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api which is similar, but it requires you to define all the fundamental traps.
17:14	<TabAtkins>	Say you were not just throwing out console spam, but actually doing the operations (and also console spamming).
17:14	<gsnedders>	Hixie: [], {}, function(){} produce different objects.
17:14	<gsnedders>	Hixie: or host objects
17:14	<TabAtkins>	Then your call would look more like:
17:15	<TabAtkins>	Proxy(obj, {get: function(obj, name) { console.log("getting "+name+"!"); return obj[name]; }...});
17:15	<TabAtkins>	The proxy is a wrapper around some other object, intercepting calls to that object.
17:16	<TabAtkins>	Thus the name - it's a proxy for the original object.
17:16	<Hixie>	i don't understand the use case (other than logging/debugging) for wrapping a single object that already existed when the proxy was made
17:16	<TabAtkins>	There's tons.
17:16	<Hixie>	i see lots of use case for proxying to multiple objects or objects that don't yet exist
17:16	<Hixie>	or for proxying to nothing at all but doing lots of magic
17:17	<gsnedders>	Hixie: Make array-like methods (filter, reduce) available on a NodeList, as an example
17:17	<Hixie>	but when do you just want to proxy to an existing object?
17:17	<Hixie>	for that you'd presumably just poke at the prototype, why would you make a proxy?
17:17	<TabAtkins>	Hixie: Before I start writing this code, what's your actual use-case? Making sure I capture the details correctly.
17:17	<Hixie>	in fact how would you even use a proxy to do that?
17:18	<TabAtkins>	...that's precisely the main and most direct use-case for Proxies. I have no idea how you're missing it.
17:18	<gsnedders>	Hixie: A lot of libraries don't want to mutate built-in prototypes. Proxy get to return Array.prototype.reduce when "reduce" is got.
17:19	<Hixie>	TabAtkins: i want to gsnedders i don't understand why that is better, can you elaborate?
17:20	<Hixie>	TabAtkins: i have JS objects that represent objects in a server-side data structure, which is lazily loaded as needed. I don't know the types of the objects until I get them, but I need to instantiate the objects before I get them. The API to those objects is all async (callback-based).
17:20	<gsnedders>	Hixie: Consider the case of having mutliple libraries loaded. You don't want them defining slightly different NodeList.prototype.reduce with different APIs
17:21	<Hixie>	gsnedders: oh, you do in fact mean "Make array-like methods (filter, reduce) available on a NodeList" and not "Make array-like methods (filter, reduce) available on NodeList", i see
17:22	<TabAtkins>	Hixie: Okay, cool. You mentioned possibly having multiple objects to dispatch to, based on which method is called. Is that necessary, or was it just theorizing?
17:23	<Hixie>	TabAtkins: that's a different use case that i've had before, but not relevant to my immediate problems (though i'm curious how it would work too)
17:23	<gsnedders>	Hixie: Most libraries like jQuery return a wrapper around NodeList or so
17:23	<TabAtkins>	Okay. It's a trivial modification, but I'll ignore it for now.
17:32	<ap>	Hi Hixie! I spent some time refreshing my memory of appcache spec, but am still unsure of the answer: can an iframe use a different appcache than main frame? The use case is to cache main application in one cache, and also have a cache with localized data per language. Localized data would be loaded in an invisible iframe.
17:32	<ap>	Hixie: from what I see, that should work, right?
17:32	<Hixie>	yes, iframes are inependent
17:32	<Hixie>	d
17:32	<ap>	Hixie: thanks
17:42	<Ms2ger>	Heh
17:42	<Ms2ger>	css3-marquee
17:43	<Hixie>	i really should be working at the office rather than at home. bbl. :-)
17:43	<Ms2ger>	Why? :)
17:43	<MikeSmith>	whew
17:44	<gsnedders>	Work from offices? Pff!
17:44	<MikeSmith>	glad that all the tedious discussion about boring technical stuff is over for now
17:44	<gsnedders>	Though sometimes I think I should do so more…
17:44	<MikeSmith>	let's please get back to discussing responsible images
17:48	<MikeSmith>	oh man
17:48	<MikeSmith>	https://twitter.com/stevefaulkner/status/208252675110871040
17:48	<MikeSmith>	but hey that's a very normal thing that happens very often
17:49	<MikeSmith>	where multi-year business agreements are extended for only a single month
17:49	<MikeSmith>	so that's probably not a sign of anything else going on at all
17:49	<MikeSmith>	they probably just plan to keep extending it for one month at a time for the next 5 years, right?
17:54	<hober>	could someone remind me who the Redundancy Activity Lead is? [ context: https://twitter.com/w3c/status/208170557169090560 ]
17:57	<Ms2ger>	You should tell glazou
18:02	<hober>	Ms2ger: there's already a Member-space thread about it
18:03	<Ms2ger>	You shouldn't tell me that in a public channel, dear :)
18:09	<Ms2ger>	hober++
18:10	rniwa	wonders where ++ came from
18:10	<rniwa>	or attributed to
18:12	<TabAtkins>	Hm. Queueing method calls with proxies is kinda annoying.
18:13	<rniwa>	AryehGregor: yt?
18:13	<AryehGregor>	rniwa, briefly.
18:13	<TabAtkins>	Because the traps don't know it's a method call, they just know that a property is being requested.
18:13	<rniwa>	AryehGregor: hi, did you get what I mean for the pre bug?
18:13	<AryehGregor>	(usually I'm not around at this hour, though)
18:13	<AryehGregor>	rniwa, I replied on the bug asking for more details, didn't I?
18:13	<TabAtkins>	So you have to return a special object that'll intercept the call and queue the info for you.
18:13	<rniwa>	AryehGregor: maybe I'll go visit you in Israel one of these days :) unless you're coming to the TPAC in France this year
18:14	<rniwa>	AryehGregor: yeah and I replied
18:14	<AryehGregor>	rniwa, didn't see that yet. I'll look tomorrow. Nope, not coming to TPAC.
18:14	<rniwa>	AryehGregor: with an example
18:14	<rniwa>	AryehGregor: okay.
18:14	<rniwa>	fwiw, i've been to google's tel-aviv office for bidi work :)
18:14	<AryehGregor>	:)
18:14	<rniwa>	AryehGregor: it'll be nice to catch up in person every now and then
18:15	<rniwa>	latency is killing our lively conversatino sometimes :\
18:15	<AryehGregor>	Yes, true.
18:19	<Philip`>	MikeSmith: I guess that's a hint that Google's going to announce next month that it's finished organising the world's information and will henceforth shut down, and they don't want any outstanding contracts at that time
18:19	<MikeSmith>	heh
18:19	<rniwa>	AryehGregor: maybe I can go to Israel after/before TPAC
18:20	<MikeSmith>	Philip`: they should hire me for that job
18:20	<rniwa>	AryehGregor: I'd rather go fly to Israel from/to France
18:20	<rniwa>	AryehGregor: than from bay area.
18:20	<MikeSmith>	Philip`: the shutting down part, I mean
18:20	<rniwa>	since i got really sick both ways the last time I flew :(
18:20	<AryehGregor>	rniwa, make sure you coordinate with me well in advance -- I don't work full-time, so I'd have to make sure it's at a time that works for me.
18:20	<rniwa>	AryehGregor: of course, only if you have a free time around that time
18:20	<AryehGregor>	rniwa, want to send me an e-mail?
18:20	<rniwa>	AryehGregor: yeah, will do that :)
18:20	<AryehGregor>	Thanks!
18:20	<rniwa>	AryehGregor: but TPAC is in October
18:21	<rniwa>	AryehGregor: so will probably contact you around August or so
18:21	<AryehGregor>	rniwa, okay.
18:21	<rniwa>	it's waaay too early to book a plane ticket, etc... :)
18:21	<MikeSmith>	Philip`: I like shutting stuff down. I wish I could shut down some more things. Failed social experiments...
18:21	<MikeSmith>	failed organizations
18:22	<MikeSmith>	refund us finally our confiscated gods
18:22	<MikeSmith>	and all that
18:23	<Ms2ger>	Failed standards organizations?
18:24	<divya>	:))
18:24	<rniwa>	MikeSmith: since you're here...
18:24	<rniwa>	MikeSmith: is there anyway to codify instructions for manual tests?
18:25	<rniwa>	MikeSmith: in HTML or JavaScript?
18:25	<rniwa>	MikeSmith: the thing is WebKit has a bunch of test automation extensions like window.layoutTestController in our test runner
18:25	<rniwa>	MikeSmith: and we can emulate keyboard, mouse, etc... events with that.
18:26	<rniwa>	MikeSmith: so if we could codify instructions in W3C manual tests, we could automate those tests as well.
18:28	<MikeSmith>	um
18:28	<MikeSmith>	I don't understand what it means to automate manual tests
18:28	<AryehGregor>	rniwa, definitely coordinate with someone at Mozilla, because we have the same issue.
18:28	<MikeSmith>	wait
18:28	<MikeSmith>	what issue?
18:29	<MikeSmith>	I think I'm missing something here
18:29	<rniwa>	oops sorry
18:29	<rniwa>	MikeSmith: this is about W3C test suites
18:29	MikeSmith	nods
18:29	<rniwa>	MikeSmith: there are a bunch of manual tests in there
18:29	<MikeSmith>	yeah
18:29	<rniwa>	MikeSmith: which says something like "click X and do Y"
18:29	<MikeSmith>	ah
18:29	<MikeSmith>	WebDriver?
18:30	<MikeSmith>	emulating user actions?
18:30	<rniwa>	MikeSmith: right. we have WebDriver-like extension in our test runner
18:30	<rniwa>	MikeSmith: except that they're exposed as a javascript object.
18:30	<MikeSmith>	ok
18:30	<rniwa>	MikeSmith: so instead of you have an external program that drives a test
18:30	<MikeSmith>	yeah
18:30	<rniwa>	MikeSmith: the test itself can control what test runner does.
18:31	<rniwa>	MikeSmith: I suspect Mozilla has a similar mechanism from what AryehGregor just said.
18:31	<AryehGregor>	Yes.
18:31	<MikeSmith>	unless I'm missing something, this is exactly the scope of the standard Web driver API work
18:32	<MikeSmith>	Simon Stewart et all
18:32	<MikeSmith>	minus one l
18:33	<MikeSmith>	http://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html
18:33	<MikeSmith>	if not, it should be the scope
18:33	<MikeSmith>	the ultimate goal being, automate everything
18:33	<MikeSmith>	or "anything that can be automated must be automated"
18:33	<rniwa>	MikeSmith: hm... the last time i checked, WebDriver API was supposed to be used externally?
18:34	<MikeSmith>	sorry, what do you mean by "externally"?
18:34	<MikeSmith>	this is an API that's exposed to Web applications
18:34	<rniwa>	MikeSmith: oh is it?
18:34	<MikeSmith>	yeah man
18:34	<MikeSmith>	that's the whole idea
18:35	<rniwa>	MikeSmith: so if you have test.html
18:35	<MikeSmith>	unless I'm deeply confused
18:35	<rniwa>	MikeSmith: we can invole methods, etc... of WebDriver in test.html itself?
18:35	<MikeSmith>	yes
18:35	<MikeSmith>	once it's actually implemented of course
18:36	<MikeSmith>	but man you are talking to the village idiot here
18:36	<MikeSmith>	me I mean
18:36	<MikeSmith>	I recommend pinging Simon Stewart about it
18:36	<MikeSmith>	dude can make it much more clear than me
18:37	<rniwa>	MikeSmith: ok. is he n #testing at irc.w3.org?
18:37	<MikeSmith>	sometimes
18:37	<rniwa>	MikeSmith: the last time i talked with someone wokring on webdriver
18:37	<MikeSmith>	he may also be on #chromium
18:37	<MikeSmith>	David Burns is also working on this
18:38	<MikeSmith>	and Eran Messeri
18:38	<rniwa>	MikeSmith: oh, Simon Stewart is a googler :\
18:38	<MikeSmith>	rniwa: yeah?
18:38	<MikeSmith>	yeah man
18:38	<Ms2ger>	Boo, Googlers :)
18:38	<MikeSmith>	jesus
18:38	<rniwa>	MikeSmith: okay, I'll go talk with him. thanks!
18:38	<MikeSmith>	do you guys actually talk to each other?
18:39	<MikeSmith>	rniwa: your company is too big, chief
18:39	<rniwa>	hm... there are at least 3 Simon Stewart at Google :(
18:39	<MikeSmith>	wow
18:39	<MikeSmith>	that's a clear sign it's time to move on to somewhere smaller
18:39	<Ms2ger>	Consider Mozilla, for example...
18:39	<Ms2ger>	We're always looking for people who know things about editing :)
18:40	<MikeSmith>	we too
18:40	<MikeSmith>	and we have only 60 people on staff
18:40	<MikeSmith>	maybe 30 people if you count the ones that are actually doing productive work
18:40	<MikeSmith>	maybe
18:41	<MikeSmith>	hard to trump that
18:42	<rniwa>	Ms2ger: nah... you g!uys have AryehGregor & ehsan
18:42	<Ms2ger>	Do you know what our code looks like?
18:42	<rniwa>	oops s/g!uys/guys/ & s/ehsan/ehsan!/
18:42	<Ms2ger>	Hmm, ehsan factorial would be nice...
18:43	<rniwa>	MikeSmith: i think google has something like 30,000 employees now...
18:43	<rniwa>	LOL
18:43	<rniwa>	Ms2ger: that'll be a lot of ehsan indeed.
18:44	<MikeSmith>	rniwa: you should test all of those people to determine how well the can estimate how many basketballs can fit in the room
18:45	<Ms2ger>	MikeSmith, surely HR already did that?
18:45	<TabAtkins>	That's the first question you answer to get in the door.
18:45	<rniwa>	Ms2ger: to make you feel better, take a look at http://trac.webkit.org/browser/trunk/Source/WebCore/editing/ReplaceSelectionCommand.cpp
18:45	<MikeSmith>	OK, well at least make the draw the organizational structure of Google on a whiteboard
18:46	<rniwa>	Ms2ger: which is mutually recursive (we bail out when the actual recursion happens) with DeleteSelectionCommand (another class) & mergeParagraphs
18:46	<rniwa>	with moveParagraphs
18:46	<MikeSmith>	TabAtkins: my answer is, it's a fucking stupid question that reveals asshattedness in the person assking it
18:47	<MikeSmith>	but hey that's just me
18:48	<Ms2ger>	rniwa, hmm, that code seems to be calling RefPtr::get() a lot
18:48	<TabAtkins>	MikeSmith: Yes, I was joking. ^_^
18:48	<rniwa>	MikeSmith: someone said the joke that we should ask every SWE in our company to see if they can understand the recent "proof" of P != NP
18:48	<rniwa>	Ms2ger: that's okay. RefPtr::get() is an inline function that just obtains a raw pointer
18:49	<rniwa>	Ms2ger: it's basically zero-cost.
18:49	<Ms2ger>	rniwa, yeah, but our refptrs have an operator T*
18:49	<MikeSmith>	TabAtkins: problem is I guess I can't tell where the joke starts. the truth is actually stranger than the fiction
18:49	<rniwa>	Ms2ger: the reason we don't have that is due to PassRefPtr I believe
18:49	<Ms2ger>	Oh, how silly
18:50	<rniwa>	Ms2ger: it actually saves us a lot of CPU cycles :)
18:50	<rniwa>	s/ us//
18:50	<rniwa>	Ms2ger: not to mention it improves the cache locality
18:51	<rniwa>	although Darin (Adler) recently told me a depressing story about how editing was the reason we introduced RefPtr... :'(
18:51	<Ms2ger>	Heh
18:52	<MikeSmith>	anyway, building an organization where the product-dev work in largely driven by Assperghers-syndome engineers combined with the revenue side being driven by completely unethical moneygrubbers is clearly the recipe for long-term success
18:52	<TabAtkins>	Worked for us! (You gotta make sure the revenue-type people don't infiltrate management, is all.)
18:53	<MikeSmith>	TabAtkins: then you have the cases like Marius Milner who combine the best of both worlds
18:53	<rniwa>	TabAtkins: "revenue-type people don't infiltrate management" indeed is very important for almost all companies
18:54	<MikeSmith>	whoever decided to hire Marius and give him free reign should get a super-big gold star
18:55	<TabAtkins>	OMG, people are still talking about the wifi bullshit?
18:55	<MikeSmith>	yeah
18:56	<MikeSmith>	because I guess people sorta are surprised when other people blow smoke up their asses
18:56	<TabAtkins>	You send data to unencrypted websites over unencrypted wifi, everyone in your vicinity has access to it.
18:56	<MikeSmith>	yeah
18:56	<MikeSmith>	and then you lie about it
18:56	<MikeSmith>	nothing wrong with that
18:57	<MikeSmith>	you claim you had no clue what was going on
18:57	<MikeSmith>	was just one crazy dude out there doing stuff on his own
18:57	<MikeSmith>	nothing evil about that
18:58	<MikeSmith>	anyway
18:58	<MikeSmith>	we all work for really wonderful organizations
18:58	<TabAtkins>	It was random bits of data grabbed across a few seconds as a car drove by.
18:58	<MikeSmith>	yep
18:58	<MikeSmith>	exactly
18:58	<MikeSmith>	that's all it was
18:59	<MikeSmith>	so no reason to not be totally transparent publicly about the fact that's what you were doing
19:01	<MikeSmith>	on the bright side there's no record of Marius actively working to prevent people who love each other from having the legal right to get married
19:01	<MikeSmith>	so that's a plus
19:01	<MikeSmith>	like I said, we all work for really wonderful organizations
19:02	<MikeSmith>	with really exemplary leadership
19:03	Ms2ger	wonders what got MikeSmith on his horse
19:05	<MikeSmith>	Ms2ger: nothing but love, an
19:24	<jgraham>	Please stop writing so much when I'm not looking
19:24	jgraham	tries to figure out if people eventually got the right story about WebDriver
19:28	<jgraham>	rniwa: So the story with webdriver is that it's typically external; you have some script outside the browser that drives the interaction
19:28	<TabAtkins>	Hm. Hixie: After finishing the impl, I'm pretty sure you don't need proxies at all.
19:29	<jgraham>	But they have made a js API for it. I don't know if that could be self-driving
19:29	<rniwa>	jgraham: can it be inside?
19:29	<rniwa>	jgraham: e.g. it'll be useful to be able to do something like
19:29	<rniwa>	div.sendKeyDown();
19:29	<rniwa>	assertSomethingHappened()
19:30	<rniwa>	jgraham: if the API is only available to external programs
19:30	<rniwa>	jgraham: then asserting conditions will be much more complicated
19:30	<rniwa>	jgraham: because of concurrency, etc...
19:30	<jgraham>	Right. So the way we do that is to use watir which is a particularly crappy ruby wrapper around WebDriver
19:30	<jgraham>	Designed by the kind of people who says things like "tests can be specifications"
19:31	<jgraham>	And yes, I think concurrency is a problem
19:31	<jgraham>	Because it sort of tries to pretend that the API is sync, but it obviously isn't really
19:31	<rniwa>	jgraham: oh no :( cucumber...
19:32	<rniwa>	jgraham: yeah, so I'd vote for exposing it via JavaScript.
19:32	<rniwa>	jgraham: we certainly don't want to expose it all the time.
19:32	<TabAtkins>	Hixie: Ah, nm, I see the flaw in what I was going to write. You either need (a) proxies, (b) private names, or (c) to add the methods to every instance instead of them being on the prototype.
19:32	<jgraham>	Well it isn't really "exposed" in any sense
19:32	<rniwa>	but it's not an issue for browser vendors...
19:32	<jgraham>	I mean, you have to connect externally to the browser
19:33	<rniwa>	jgraham: right... so what I'm advocating is to expose it via DOM
19:33	<jgraham>	So, I don't really know how well that would work
19:33	<rniwa>	jgraham: webElementDiv = window.webDriver(div);
19:33	<jgraham>	It at the least sounds different to WebDriver
19:34	<jgraham>	But it was someone at Google who was working on the JS bindings
19:34	<jgraham>	I don't remember his name though
19:34	<rniwa>	jgraham: and then you can do something like webElementDiv.sendKeys(~~)
19:34	<jgraham>	... I don't know the API details
19:34	<benvie>	if you're referring to what I think you are, I did that here using code generation from IDL and prototye accessors https://github.com/Benvie/svgstuff/blob/master/lib/defs.js
19:35	<jgraham>	I know that Mozilla are using the python bindings and I think Google/FB use it to test their websites (probably with Java/PHP bindings, respectively)
19:35	<jgraham>	But about the JS bindings I know nothing
19:35	<rniwa>	Simon Stewart?
19:36	<jgraham>	Well he will know who knows
19:36	<jgraham>	But it wasn't him that wrote them
19:36	<jgraham>	But he is project lead or something
19:37	<jgraham>	None of the Opera\|ex-Opera people who would know more are here at the moment
19:37	<rniwa>	benvie: i don't understand. how are you emulating sendKeys, etc...
19:37	<rniwa>	benvie: from javascript?
19:37	<benvie>	well I did that using node and ffi but not really finished
19:38	<rniwa>	benvie: i don't think that's what we're looking for.
19:38	<benvie>	yeah
19:38	<benvie>	similar
19:38	<benvie>	but no =D
19:38	<rniwa>	benvie: yeah, the idea is similar.
19:38	<rniwa>	jgraham: i think there's a real value in exposing these APIs through javascript
19:38	<rniwa>	jgraham: so that tests can be self-contained
19:39	<rniwa>	jgraham: one drawback, however, is that we probably won't be shipping this API in production
19:39	<gsnedders>	rniwa: And that makes it impossible to test IE/Opera as a third-party.
19:39	<rniwa>	jgraham: so ordinary web developers can't use them to run tests :\
19:39	<gsnedders>	rniwa: Or even release builds of Safari, say
19:39	<rniwa>	gsnedders: right.
19:39	<rniwa>	gsnedders: but that's already true.
19:39	<rniwa>	gsnedders: we can leave a manual test instruction
19:40	<rniwa>	gsnedders: at least that's what we do in webkit
19:40	<rniwa>	gsnedders: we have window.eventSender which lets us emulate keyboard/mouse events
19:40	<rniwa>	gsnedders: but we also leave manaul test instruction
19:40	<rniwa>	gsnedders: so that we can run those tests in firefox, etc...
19:40	<gsnedders>	rniwa: WebDriver being external allows automated testing of the browsers, which is better than that
19:40	<rniwa>	gsnedders: I don't think everyone is on the page, however.
19:41	<rniwa>	gsnedders: I remember Microsoft explicitly said they won't be implementing it for example.
19:41	<rniwa>	s/said/saying/
19:41	<rniwa>	gsnedders: and I'm skeptical that we can use WebDriver API as is in our test harness
19:42	<rniwa>	gsnedders: what's the point of a test suite if browser vendors can't run them?
19:42	<rniwa>	or rather "don't"
19:43	<jgraham>	rniwa: Why are you skeptical?
19:43	<rniwa>	jgraham: that we can support WebDriver in our test harness.
19:43	<jgraham>	Hmm, well I guess I don't know how you run tests
19:43	<rniwa>	jgraham: fwiw, we don't use a full-blown web browser to run tests.
19:44	<jgraham>	Well we soert-of don't
19:44	<rniwa>	jgraham: we have a special test runner called DumpRenderTree or WebKitTestRunner (for webkit2)
19:44	<jgraham>	How unlike a real browser is it?
19:44	<rniwa>	jgraham: that exoses special objects such as layoutTestController, eventSender, textInputController in the global scope (i.e. on window object)
19:44	<rniwa>	jgraham: it's so unlike a real browser that it doesn't even have a window.
19:45	<rniwa>	jgraham: you can't see anything until the test completes
19:45	<jgraham>	Hmm, not having a window does sound like it could be a problem
19:45	<rniwa>	jgraham: and you can't interact with it.
19:45	<gsnedders>	jgraham: It literally just makes a render tree and (sometimes) a screenshot available. That's it.
19:45	<gsnedders>	jgraham: There is no interaction, you start it, it does that, over.
19:45	<rniwa>	gsnedders: right.
19:45	<jgraham>	Oh well that seems like a kind of broken way of testing
19:46	<jgraham>	In that it is very unlike anything you will ship
19:46	<jgraham>	(very different codepaths)
19:46	<rniwa>	jgraham: in practice, it can test things pretty well.
19:46	<rniwa>	jgraham: we do all the paining, layout, etc... normally
19:46	<rniwa>	it
19:46	<rniwa>	jgraham: it's just that it doesn't have any real UI to it.
19:46	<rniwa>	s/ to it//
19:47	<jamesr_>	we also do some testing with a fuller browser, of course, but we don't run every test that way
19:47	<rniwa>	jgraham: and doesn't let user interact because the whole point of the test runner is to automate testing
19:47	<rniwa>	jgraham: and run them as fast as possible.
19:47	<jgraham>	So it is rendering to an offscreen buffer, effectively?
19:47	<rniwa>	jgraham: if we were to start the entire web browser for each test case, it would be impratically slow.
19:47	<jamesr_>	correct
19:47	<rniwa>	jgraham: yes.
19:47	<jamesr_>	or in many cases not rendering at all
19:48	<jgraham>	rniwa: Sure, obviosuly you have to not do that
19:48	<rniwa>	jgraham: things like GPU acceleartion, etc... need a special treatment because of that.
19:48	<gsnedders>	Do you test stuff like GPU painting with it?
19:48	<jamesr_>	if the test doesn't depend on pixels
19:48	<jamesr_>	for tests that need it, we test that part of the GPU pipeline (normally using osmesa so it can run on VMs easily)
19:48	<jgraham>	We can use our remote-debugging support to load pages, wait for the browser to become idle (or for a result to be recieved) and load the next test, without restarting
19:49	<jgraham>	Although WebDriver/Watir tests are an exception, sadly
19:49	<gsnedders>	So you could, theoretically, have GPU pipeline bugs in layout tests that don't get found?
19:49	<rniwa>	gsnedders: our regular tests can't find them. but as jamesr said, we have special tests for those.
19:49	<jamesr_>	we could have bugs anywhere that don't get found, but exercise most of the GPU pipeline in layout tests (the parts that aren't covered are OS-integration things like IOSurface swapping, etc)
19:50	<jamesr_>	some of our regular layout tests run through the GPU path
19:50	<rniwa>	with GPU acceleration, though, testing everything is virtually impossible because you then have to try all permutations of OS, GPU chip/board, driver, etc...
19:50	<jamesr_>	but not all - most of our tests don't render at all, they just make JS assertions or dump the render tree without painting it
19:51	<jgraham>	(and we have a lightweight platform layer and render to a virtual buffer)
19:52	<gsnedders>	jgraham: That's not true, we render to Xvfb — our platform layer we run on is complete, just the platform beneath it isn't so standard.
19:53	<gsnedders>	jamesr_: Was mainly asking because I know we do have some general layout bugs with the GPU pipeline (though we equally don't normally run all tests through it)
19:53	<jgraham>	gsnedders: I meant "lightweight" as in "not the full desktop browser (except when we test that specifically)"
19:54	<jgraham>	Possibly that wasn't sufficiently obvious
19:54	<jamesr_>	i think it's a terminology thing but we would normally call that a rendering or paint bug, not layout
19:54	<jamesr_>	layout figures out parameters on a bunch of C++ objects representing what we call the render tree. painting goes through those data structures and generates pixels
19:54	<gsnedders>	jamesr_: Right, I wouldn't call that a layout bug per-se, but it's a bug affecting layout which is caught by the layout tests, even if the bug lies elsewhere
19:54	<jamesr_>	if the GPU pipeline is broken it'd tend to break the latter of those two steps but it couldn't really break the former
19:55	<gsnedders>	affecting layout insofar as what the user sees
19:55	<jamesr_>	yes definitely. we have tests to cover that
19:55	<rniwa>	gsnedders: we normally categorize those as painting bugs :)
19:55	rniwa	hates technical jargons
19:56	<rniwa>	why can't we stop inventing obnoxious jargons
19:56	<gsnedders>	jamesr_: I guess my point is more painting bugs can turn up (and hence regress!) in layout tests as well as painting tests.
19:56	<jgraham>	Hmm a painting bug sounds like you have the right information in layout but the gfx layer did something wrong (and it is often fixed by forcing a repaint)
19:56	<jamesr_>	jgraham, depends on the bug
19:57	<jamesr_>	gsnedders, certainly, and that's why we have the capability of going through the painting path (including GPU where applicable) in our layout test harness
19:57	<jgraham>	jamesr_: Sure, I think I'm just saying that I would draw a distinction along those lines
19:57	<jamesr_>	and then checking that those pixels either match a golden PNG or the rendering of a reference file
19:57	<jgraham>	Which might be an Opera thing or might be something I made up
19:57	<Hixie>	TabAtkins: still think it's trivial? :-)
19:58	<jamesr_>	we also have repaint tests which paint once, change something, then paint again and make sure we actually update all the pixels that are supposed to look different
19:58	<jgraham>	"then checking that those pixels either match a golden PNG" - I'm sorry :)
19:58	<jamesr_>	we have a lot of golden PNGs (as in golden file testing) in WebKit
19:58	<jgraham>	We still have too much of it in Opera
19:58	<jgraham>	It is evil and must die
19:59	<gsnedders>	jamesr_: And regressions could slip through if it's not done often.
19:59	<jamesr_>	we have bots that run it as fast as they can cycle (it's not every checkin, but it's every hour or two on the slowest configs)
19:59	<gsnedders>	Right, so it's part of the normal testing cycle, even if it isn't done on every run.
20:00	<gsnedders>	It just sounded as if it was exceptional and not normally done at all from what you said before.
20:00	<Philip`>	jgraham: I guess the problem is exacerbated by Opera supporting too many platforms?
20:00	<gsnedders>	Philip`: And subtle differences between products.
20:01	<rniwa>	anyways,
20:01	<jamesr_>	ah no, it's part of the configuration of the test so not all tests are configured to hit every path, but we run all the tests continuously in many configurations
20:01	<rniwa>	to re-iterate my point, it would be really nice if we could expose WebDriver API in tests themselves
20:01	<rniwa>	so that we can import W3C tests without havingt to manually modify them
20:02	<jgraham>	Philip`: > 1 you mean? :)
20:02	<jgraham>	Or really > 0
20:02	<gsnedders>	It'd bad enough with one platform, having to manually verify things :P
20:02	<jgraham>	Since even on one platform people do annoying things like change the font engine every so often
20:04	<gsnedders>	(Font rendering was a big reason why we tested on Windows 2000 for a long time, not wanting to go through n thousand screenshots and relabel them)
20:07	<rniwa>	gsnedders: yeah... font anti-aliasing kills us :(
20:08	<rniwa>	gsnedders: we have to generate thousands of very similar PNGs just to cope up with font-aliasing differences between different versions of Mac/Win/etc...
20:08	<rniwa>	(or maybe we've disabled anti-aliasing on Windows; /me doesn't remember)
20:14	<rniwa>	jgraham, gsnedders: so... do you think exposing it via JavaScript would be an option at all?
20:14	<rniwa>	with manual instructions?
20:15	<rniwa>	jgraham, gsnedders: alternatively, i would be fine with having some external file that instructs WebDriver what to do.
20:15	<rniwa>	jgraham, gsnedders: as long as it's machine-readable so that we can manipulate it to work with our test harness.
20:16	<gsnedders>	I'd much rather be able to test release browsers.
20:16	<rniwa>	gsnedders: that could be done manually, right?
20:16	<rniwa>	gsnedders: we already do that manually.
20:17	<rniwa>	gsnedders: but i'm open to options that allows automated testing of browsers in production.
20:17	<rniwa>	gsnedders: that sounds like a very valuable goal to have.
20:17	<rniwa>	gsnedders: as long as the configuration is such that we can also use it in our test harness
20:20	<TabAtkins>	Hixie: More details are needed. These async methods, are they part of a stable, closed set? Or are they determined by the server-side object?
20:21	<rniwa>	gsnedders: would that sound good with you?
20:22	<rniwa>	s/would/does/
20:22	<rniwa>	ugh... s/with/to/
20:25	<TabAtkins>	If they're a closed set, I can do this without proxies at all.
20:26	<TabAtkins>	Hixie: The difficulty here that makes it harder than other languages is that Javascript doesn't actually have any concept of "methods". It just has properties, whose values might be callable.
20:32	<Hixie>	TabAtkins: there is a finite number of known types that will be instantiated, each with a finite number of methods.
20:32	<Hixie>	TabAtkins: sure. s/method/field/ is fine.
20:32	<TabAtkins>	Okay, that's the "closed set" option. Cool.
20:32	<TabAtkins>	Hixie: Renaming doesn't help. ^_^ It just means that I need to be a little fancy to intercept method calls.
20:32	<Hixie>	(i actually do have an open-ended set of methods but one of the methods from the closed set is what i'll use to invoke the open set)
20:33	<Hixie>	TabAtkins: ah
20:41	<TabAtkins>	Unless I'm crazy, this turned out to be really easy once I stopped trying to use Proxies, because they're not necessary.
20:41	<TabAtkins>	Though you likely need Private Names to avoid exposing some of the data here.
20:43	<jgraham>	So what are you doing? Swapping prototypes from one that queues the results to one that doesn't. That's pretty evil so presumably not...
20:43	<jgraham>	s/./?/
20:44	<jgraham>	Or I guess you can just rewrite the properties at runtime in the object itself
20:45	<jgraham>	None of this sounds healthy though
20:45	<TabAtkins>	Hixie: http://www.xanthir.com/blog/b4JB0
20:45	<TabAtkins>	jgraham: Tell me if I'm doing anything wrong here.
20:47	<Hixie>	TabAtkins: swapping prototypes is what i suggested a few hours ago when you were saying to use proxies :-)
20:47	<TabAtkins>	Hixie: I'm not swapping protos...
20:47	<Hixie>	oh, i misread what jgraham said, my bad
20:47	<TabAtkins>	I thought proxies were necessary when I thought that the set of async methods was open-ended.
20:48	<Hixie>	wait so i have to list every function that every possible class of object might implement?
20:48	<TabAtkins>	No, you have different FarObject classes.
20:49	<Hixie>	i don't know the type of the FarObject until i get back the data from the server
20:49	<TabAtkins>	Oh!
20:49	<TabAtkins>	Hm, then. Let me think about this.
20:49	<Hixie>	if i knew the type of the object it would be trivial, i just wouldn't need to create a proxy at all
20:49	<TabAtkins>	We'll probably be back to needing a proxy if we want to be efficient.
20:49	<Hixie>	i could just create the object and have the object itself do the queuing
20:49	<TabAtkins>	Yeah, that's what I ended up doing. ^_^
20:50	<Hixie>	(which btw is what i think i will probably end up doing, by having every object ID actually include its type as well)
20:50	<Hixie>	(but i still wish it was easy to do it without that)
20:50	<TabAtkins>	If Type1 has asyncFoo and type2 has asyncBar, and you call asyncBar on the object before it's loaded but it ends up being Type1 when you get the data, what happens?
20:51	<Hixie>	in practice, you don't do that, because you'll have some idea of what the superclass of the object is and won't call things that that superclass doesn't support
20:52	<Hixie>	and only when you get information back from the methods of that superclass would you then call the methods of the subclass (the class it actually is)
20:52	<Hixie>	anyway i think my original point, which is that this is not as trivial as in perl, stands proven
20:52	<TabAtkins>	I think the "won't call" is more theory than practice. ^_^
20:52	<benvie>	I implemented synchronizing across remote DOM implementations by using unique IDs for every new object and recording all the inputs and outputs of every action
20:52	<TabAtkins>	I defy you to actually write this in two lines of perl.
20:52	<Hixie>	i gave you the two lines of perl to define a catchall method
20:53	<benvie>	so document.createElement becomes #1 GET #2, apply #2 'div' creates #3
20:53	<benvie>	and so on
20:53	<Hixie>	actually doing the dispatch would be a few more, but sure, hold on
20:53	<TabAtkins>	Yeah, the catchall part is easier because Perl has methods.
20:53	<Hixie>	Mozilla has (had?) __noSuchMethod__
20:53	<Hixie>	in JS
20:53	<Hixie>	which would make this easy too
20:54	<TabAtkins>	That doesn't obey the raw JS semantics. ^_^
20:54	<Hixie>	but it's easy :-)
20:54	<TabAtkins>	Of course it is!
20:56	<creis_>	Hixie: Do you know anything about the rel=external link type (http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-external)?
20:56	<creis_>	Looks useful for something I'm considering, but it doesn't appear to have made it into the spec.
20:57	<creis_>	Just wondering if it's a dead proposal or still being considered.
20:57	<Hixie>	creis_: it's defined here: http://microformats.org/wiki/rel-external
20:58	<Hixie>	creis_: and registered here: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
20:58	<Hixie>	creis_: the w3c had us remove it from the spec text itself for some reason or other, but i expect it'll be back in the spec sooner or later
20:58	<Hixie>	creis_: i'm planning on revamping how registration of things like rel values is done
20:58	<Hixie>	creis_: now that we're on a truly "living standard" model
20:59	<tantek>	Hixie - have there been any issues with using the microformats wiki?
20:59	<tantek>	(for rel registration)
20:59	<creis_>	Hixie: Cool, thanks. Slightly related, do you know if there's any consideration about applying similar link types to window.open, now that the "features" argument is supposed to be ignored?
21:00	<Hixie>	tantek: not especially, it's just not that great that the values that are "standard" aren't in the spec
21:00	<Hixie>	tantek: i don't expect use of the wiki to stop
21:01	<Hixie>	tantek: just that once things are "accepted" they be put in the spec so that people can find them more easily
21:01	<tantek>	ok cool. so the wiki helps with standardizing, then when things are stable, they can be incorporated into the spec. I'm fine with that.
21:01	<Hixie>	creis_: i don't think i've heard of any problem that that would solve
21:01	<tantek>	I'd like to avoid having redefining though - which is what happened with rel-tag
21:01	<Hixie>	tantek: indeed
21:02	<Hixie>	tantek: (well, rel=tag was more about matching existing practice than redefining)
21:02	<Hixie>	tantek: (but i agree in principle)
21:02	<tantek>	hixie - your opinion of existing practice, not without dispute
21:02	<creis_>	Hixie: One example is rel=noreferrer, which suppresses window.opener if used in combination with target=_blank. It would be nice to have a way to call window.open where opener was not set (e.g., with rel=external or something similar).
21:02	<tantek>	(document vs. blog post granularity)
21:03	<tantek>	Hixie, I'd say if you think the definition of a rel value on the wiki (and respective spec page there) is insufficiently detailed, it's probably not mature enough to make it into the standard
21:04	<Hixie>	creis_: makes sense. i don't recall if we have a solution for that offhand, but either way, please don't hesitate to file a bug or send e-mail about it to get it on the list.
21:04	<Hixie>	tantek: agreed, again in principle
21:04	<creis_>	Hixie: Thanks, I'll follow up.
21:04	<tantek>	Hixie, great. we'll cross further bridges when we get to them then.
21:07	<jgraham>	Hixie: It occurs to me that there is something I was going to ask you when you weren't around. Maybe I should work out what it was while you are around...
21:08	<jgraham>	Ah, maybe you already answered in a bug
21:09	<Hixie>	jgraham: yeah i think i answered in teh bug
21:10	<jgraham>	I wonder what happens if you don't use the location interface but set the src attribute
21:10	<Hixie>	on iframe?
21:10	<Hixie>	setting src on iframe iirc kills the browsing context entirely
21:10	<jgraham>	(this might also be covered already, the spec is still ladaing)
21:10	<Hixie>	and recreates it
21:11	<jgraham>	*loading
21:11	<jgraham>	But it is still possible that you would get one or two history positions in the joint session history
21:13	<Hixie>	when you set src="" the load happens with replacement enabled, iirc
21:13	<Hixie>	which means you get 1
21:13	<Hixie>	the about:blank is nuked
21:13	<Hixie>	but i don't recall exactly
21:14	<jgraham>	I don't see that in http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-src
21:14	<Hixie>	TabAtkins: http://damowmow.com/playground/perl-forwarder.pm (not tested, includes all the boilerplate as well except for the actual loading code)
21:14	<jgraham>	But it is quite possible I am missing something because navigation feels quite like "you are in a maze of twisty algorithms, all alike"
21:15	<TabAtkins>	Hixie: Take my last scenario, with Type1 and Type2. What's the desired behavior difference, before the data is loaded, between calling asyncBar() (valid function, but not for the type you eventually figure out for it) and calling asyncUnknown() (no type has this function)?
21:16	<Hixie>	jgraham: search for "Furthermore, if the browsing context's session history contained only one Document when the process the iframe attributes algorithm"
21:16	<Hixie>	jgraham: just below the "process the iframe attributes" algorithm
21:17	<Hixie>	TabAtkins: i guess while you're loading, both should just do nothing, and once you're loaded, both should throw an exception (so in particular, the former shoudl throw an exception when the queue of methods is flushed)
21:17	<Hixie>	TabAtkins: at least, that's what the perl impl i threw together did
21:18	<Hixie>	TabAtkins: the perl implementation of AUTOLOAD ended up being 11 lines, of which 6 are trivial
21:18	<jgraham>	Hixie: But is that right? I can have multiple entries in the iframe history e.g. I initially lood 001.html and while that is loading switch the location.href to 002.html and while that is loading set the src to 003.html
21:19	jgraham	thinks the autoload thing would be just as easy in python but with less line noise
21:19	<Hixie>	jgraham: since navigation cancels existing navigations, i don't think you can have more than one
21:19	<Hixie>	jgraham: oh uh
21:20	<jgraham>	What if one ran to completion?
21:20	<Hixie>	jgraham: i misunderstood (because i was assuming setting src blows away the browsing context)
21:20	<Hixie>	jgraham: actually what i said still stands
21:21	<Hixie>	jgraham: you'd have a race condition in the example you give
21:21	<Hixie>	jgraham: "while that is loading" could mean either before the session history is updated, or after
21:21	<Hixie>	jgraham: if it's before, then it's as if it never happened
21:21	<Hixie>	jgraham: if it's after, then the condition doesn't apply
21:23	<jgraham>	Hixie: It is the latter case I wonder about, I think
21:24	<Hixie>	jgraham: so we'd be talking about a case where an iframe is loaded with a file that, while it is loading, replaces the src, and the question is do you get one entry or two.
21:24	<Hixie>	jgraham: should be easy enough to test :-)
21:24	<jgraham>	Yeah I guess I will do that tommorrow
21:25	<Hixie>	jgraham: (i'd also check to see if you get 2 or 3 entries in the same case but with a page being loaded completely first)
21:25	<Hixie>	jgraham: (in case setting src="" does indeed blow away the session history)
21:25	<jgraham>	I am pretty sure the answer will be that you get N+1 entries rather than N+2 given that you start with N
21:25	<Hixie>	jgraham: (which i could have sworn it did, i dunno why the spec doesn't say that)
21:25	<jgraham>	But I will see
21:25	<Hixie>	i am pretty sure you end either with N+2 entries or 1 :-)
21:26	<Hixie>	but not N+1 :-)
21:26	<jgraham>	Heh
21:26	<Hixie>	N+1 will be hard to spec, so i hope i'm right :-P
21:26	<jgraham>	Let's go with ">0"
21:30	<smaug____>	jgraham: whenever doing something with session history, test the implementations (which all do different things) and pick up the behavior which you like the best :)
21:34	<jgraham>	smaug____: That's what I am doing. I am also doing step 2) Avoid hypocritsy and make the world a better place by giving feedback on the spec, especially where we want to diverge from it
21:34	<jgraham>	*hypocrisy
21:35	<smaug____>	jgraham: wasn't someone going to spec session history
21:35	<smaug____>	I mean the parts which aren't spec'ed
21:36	<smaug____>	jgraham: someone from Opera, not you
21:36	<TabAtkins>	Hixie: http://www.xanthir.com/blog/b4JB0
21:36	<TabAtkins>	32 lines.
21:37	<smaug____>	jgraham: session history becomes very interesting when you start defining what should happen when DOM is modified
21:37	<smaug____>	(remove/add iframes, move them, etc)
21:38	<jgraham>	smaug____: When does DOM modification affect history? Apart from document.open() of course. Which is more "demolition" than "modification"
21:38	<TabAtkins>	As written the object never advertises that it has the async methods, even after it's loaded. That'll take another line to add them to 'near' and make it distinguish them properly.
21:39	<jgraham>	Well when I tested that last moving iframes always caused them to reload, so I would always expect an extra position in session history
21:39	smaug____	tries to find some tests
21:39	<jgraham>	The only exception was chrome when you added/removed a node into the same place in a single step
21:40	<jgraham>	When it badly optimised away the action and missed the expected side effects
21:41	<smaug____>	where are my tests..
21:44	<smaug____>	jgraham: http://mozilla.pettay.fi/moztests/history2/Start.html
21:44	<smaug____>	that is a case which behaves quite differently in different browsers
21:45	<smaug____>	note, the comments about browser engines aren't valid anymore
21:45	<smaug____>	Gecko follows IE behavior nowadays, at least in most cases
21:45	<smaug____>	since IE has traditionally been the least broken
21:46	jgraham	frames that sentence and puts it on the wall
21:49	<jgraham>	smaug____: Interesting test, thanks
22:09	<Hixie>	TabAtkins: what is a Name?
22:10	<TabAtkins>	The syntax isn't decided yet, but the functionality is http://wiki.ecmascript.org/doku.php?id=strawman:private_names
22:10	<TabAtkins>	it's a gensym, basically.
22:10	<TabAtkins>	The way that JS finally gains private properties.
22:10	<TabAtkins>	Alternately, http://www.xanthir.com/blog/b4FJ0
22:12	<Hixie>	ah
22:12	<Hixie>	weird
22:12	<Hixie>	and "..." is an in-place array expansion operator?
22:13	<TabAtkins>	Yeah.
22:13	<Hixie>	well this is certainly simpler than i feared
22:13	<Hixie>	but not as simple as i'd like
22:13	<Hixie>	:-)
22:14	<Hixie>	whenever i look at the new JS stuff I feel like it's invented by computer science researchers
22:14	<Hixie>	rather than being copied from mainstream programming languages
22:14	<Hixie>	i can't help but wonder how regular authors will deal with it
22:15	<TabAtkins>	This is largely because it is. Also because the ESWG prefers to add new primitives, and then come along later and see what easy-to-use APIs to standardize on top of them.
22:15	<Hixie>	seems kinda like the opposite of what we do for the rest of the web
22:15	<TabAtkins>	Kinda, yeah.
22:15	<Hixie>	where we try desperately not to innovate
22:15	<Hixie>	anyway
22:15	<TabAtkins>	Or, wait.
22:16	<TabAtkins>	The point is that libraries get to innovate on top of the new primitives, and then we come through and bless the best solution.
22:17	<Hixie>	what i don't understand is why the primitives and libraries have to be in JS rather than in other languages
22:17	<Hixie>	as in
22:17	<Hixie>	why don't we look at existing libraries and languages and copy the already known best solutions
22:17	<Hixie>	rather than making JS have arcane computer science theory primitives, as well as, later, higher-level solutions to some problems
22:18	<TabAtkins>	Because without the primitives, a lot of problems can't be solved in a reasonable way?
22:19	<Hixie>	in the abstract, i find that hard to refute
22:20	<Hixie>	but for example, why do we need to provide a way for a property to be sealed dynamically, rather than just having statically defined classes with properties that can't be changed dynamically anyway?
22:21	<TabAtkins>	I can't comment much on the desire for sealing properties.
22:22	<TabAtkins>	But I suspect that at least some of it is that getting WG agreement on a class syntax is much harder than WG agreement on the ability to seal.
22:22	<TabAtkins>	(Which is why JS still doesn't have a class syntax.)
22:23	<Hixie>	fricking committee-driven design
22:25	<Hixie>	imageSmoothing... should affect patterns, right?
22:26	<TabAtkins>	I think so.
22:27	<TabAtkins>	Patterns can be resized and whatnot, right?
22:27	<TabAtkins>	If so, yes.
22:27	<Hixie>	yeah
22:32	<rafaelw_>	hixie: reference for H4X?
22:33	<Hixie>	dunno offhand
22:33	<Hixie>	it's basically just e4x but for html
22:33	<Hixie>	i don't think anything formal has been written, since it never gets any traction
22:34	<zewt>	heh, the worst features of all languages seem to be where they get "creative"
22:34	<rafaelw_>	ok. that makes it hard for me to respond =-)
22:36	<Hixie>	just imagine e4x but without namespaces and without comment support.
22:36	<Hixie>	(and with some of the <svg>/<math> namespace magic, i guess)
22:36	<Hixie>	if it's something you think we can get traction on amongst implementors of js engines, i'm sure we can come up with an actual proposal that a js person could turn into a real spec
22:37	<TabAtkins>	Unrelated: all of a sudden, today all the IE people started sending mail in large blue text.
22:37	<TabAtkins>	Maybe they all got a corporate Outlook upgrade?
22:38	<Hixie>	rafaelw_: (oh, another change from e4x would be that the elements created using h4x actually be DOM nodes, not a parallel data structure like in e4x)
22:38	<smaug____>	I don't think that was the idea with e4x. Brendan just never implemented the DOM binding
22:39	<rafaelw_>	I guess my question is how would it avoid the context element problem?
22:41	<Hixie>	smaug____: e4x had a kind of implied casting, but there were definitely two different types of objects in play
22:41	<Hixie>	smaug____: even with that mapping that never got implemented
22:41	<tantek>	objects are overrated
22:41	<Hixie>	rafaelw_: just always require end tags and don't do any optional tags
22:41	<Hixie>	rafaelw_: so there's only one parse mode
22:42	<Hixie>	rafaelw_: (it doesn't have to match the HTML syntax, it just has to be at least as terse for most purposes)
22:42	<rafaelw_>	And it wouldn't do any fixup?
22:42	<Hixie>	right, any syntax errors would be JS syntax errors
22:42	<rafaelw_>	So "<option>Foo<option>Bar" throws an error?
22:42	<Hixie>	and wouldn't compile
22:42	<Hixie>	it doesn't throw, it just doesn't compile
22:42	<Hixie>	like "var = foo"
22:43	<Hixie>	rafaelw_: i think maybe i misrememberd the proposal name. try googling for e4h?
22:43	<rafaelw_>	The main problem I see with this is it means required page authors to learn another HTML which is different from the HTML they know.
22:44	<Hixie>	i don't think that's a huge problem, authors dealt fine with JSON e.g.
22:44	<Hixie>	which isn't quite the same as JS
22:44	<smaug____>	it wouldn't be that different, at least in most cases
22:45	<Hixie>	rafaelw_: http://lists.w3.org/Archives/Public/public-script-coord/2011OctDec/thread.html#msg65
22:45	<Hixie>	E4H
22:46	<Hixie>	quasi-literals is the other thing people have proposed in this space
22:46	<Hixie>	which i think has a bit more traction over in JS land
22:46	<Hixie>	which isn't quite as cool imho but is more generic and, at least in some proposals, still gets you the syntax checking
22:48	<wodemay>	what's with these? why are y'all putting presentational elements back into html5? https://en.wikipedia.org/wiki/HTML_tag#Presentation What's the rationale?
22:48	<Hixie>	wodemay: ?
22:49	<Hixie>	wodemay: the premise of the question is incorrect, unless you mean <canvas>, i guess
22:49	<wodemay>	Hixie, <b>/<i>/<u> (i understand u, there's no semantic equivalent. but the other two...?)
22:49	<Hixie>	wodemay: please read the HTML spec, you'll find none of those are presentational
22:49	<TabAtkins>	The wikipedia page explains the semantic meaning of those elements.
22:50	<TabAtkins>	As does the HTML spec.
22:50	<wodemay>	TabAtkins, I have read both. But I find it a hard sell to believe that those are not presentational.
22:51	<Hixie>	what's your definition of "presentational"?
22:51	<TabAtkins>	Okay. Shrug, then. If the part where they say "these have meaning" doesn't mean "not presentational" to you, then I'm not sure what to say.
22:51	<wodemay>	as with <hr>, since it's explicitly horizontal.
22:51	<TabAtkins>	Huh?
22:51	wodemay	rereads the wiki and spec.
22:52	<TabAtkins>	<hr> will generate a vertical rule in vertical text.
22:52	<rafaelw_>	hixie: re: E4X & js quasi literals
22:52	<Hixie>	the definition of <hr> doesn't even mention the word "horizontal"
22:52	<rafaelw_>	Conceptually what E4X proposes are two complementary things:
22:53	<Hixie>	wodemay: make sure you're reading the latest spec, maybe you're looking at an out of date one. http://whatwg.org/html
22:53	<rafaelw_>	a) HTML literals in JS (so you get parse errors at load time)
22:53	<wodemay>	Hixie, okay, thanks.
22:53	<rafaelw_>	b) A new HTML parser
22:53	<rafaelw_>	Maybe it's worth separating these issues.
22:53	<Hixie>	rafaelw_: well it's not a new HTML parser, it's just a new set of literals in the JS parser
22:54	<rafaelw_>	So it wouldn't use any parser?
22:54	<Hixie>	it's JS
22:54	<Hixie>	it uses the same parser as parsing "function () { }" or "-35.23"
22:54	<Hixie>	same as E4X
22:55	<rafaelw_>	Would "<div><tr><td>Foo</td><tr></div>" be valid?
22:55	<rafaelw_>	Would "<div><tr><td>Foo</td></tr></div>" be valid?
22:55	<Hixie>	what do you mean by "valid" in this context?
22:55	<rafaelw_>	would it throw a parse error.
22:56	<rafaelw_>	is it "statically valid"
22:56	<Hixie>	the script var foo = <div><tr><td>Foo</td></tr></div>; would not throw a parse error, but would generate a DOM tree that is non-conforming to HTML.
22:56	<Hixie>	and assign it to the variable "foo"
22:56	<wodemay>	TabAtkins, sorry... I was a little confused and remembered somethiing different as the HTML5 subsections of those elements' sections on the wiki and was basing my memory of the official spec's explanations on that. But still, don't the tagnames derive their etymology from an earlier presentational incarnation? Shouldn't they get new names that are semantic to the core?
22:56	<Hixie>	or i should say, \|foo\|
22:56	<rafaelw_>	i see.
22:56	<rafaelw_>	what about
22:56	<rafaelw_>	var foo = <div>Foo</div><div>Bar</div>
22:57	<TabAtkins>	wodemay: Yes, they were presentational in old versions. But they were often used in a way that had a somewhat consistent meaning, which HTML5 now codifies.
22:57	<Hixie>	wodemay: the tag names are just opaque strings, where possible we reuse those that are already implemented because it means we get things for free (e.g. the default rendering of the "instance of term" element <i> is already italics in old browsers because those browsers think they mean "italics")
22:58	<Hixie>	rafaelw_: there's no concrete proposal, so it's hard to say. one could say that two HTML literals side by side result in an implied documentFragment, but personally I would prefer that we say that if you want a DF you have to wrap the elements in <>...</>
22:58	<rafaelw_>	i see.
22:59	<rafaelw_>	so it literally becomes a short-hand for equivalent calls to createElement, appendChild, setAttribute, etc...
22:59	<Hixie>	yeah
22:59	<TabAtkins>	Yeah, that's the easiest way to think of it.
23:00	<smaug____>	not so fun part would be that workers shouldn't allow that syntax
23:00	<wodemay>	Hixie, but isn't part of the html5 concept that webpages coded in the 90s will still work on browser versions released in 2020 anyway? Doesn't said concept cover your scenario? Can't HTML5-thespec name them something diff?
23:00	<TabAtkins>	wodemay: What's the value in naming them differently, then?
23:00	<zewt>	(<i> does mean italics, because that's how it renders and that's what everyone uses it for; you can wave your arms around fiercely trying to say it means something else, but that's what it means :)
23:01	<rafaelw_>	well. i can tell you that the ship has sailed on new features for ES6.
23:01	<rafaelw_>	JS quasi's are approved in proposal.
23:01	<rafaelw_>	presumably you could define that HTML quasis parse this way, but i don't think you'd get load-time parse errors like you want.
23:02	<rafaelw_>	in any case, you could look at what you're describing as an alternate proposal for the behavior of Document.parse().
23:02	<rafaelw_>	no?
23:02	<wodemay>	TabAtkins, Let's say someone is born 2015 and begins learning to code HTML5 docs in the year 2030. There shouldn't be any remnants of the stone ages of mixing pres and content. They shouldn't ever think of tags as having presentational meaning. Naming them differently will prevent them from getting misused.
23:03	<rafaelw_>	who is parsing doesn't matter to authors.
23:03	<Hixie>	smaug____: yeah, we'd have to define some solution to that
23:03	<TabAtkins>	wodemay: That seems gratuitous. There's nothing wrong with the name, and in a lot of cases, the legacy uses of it are consistent with the new semantics.
23:03	<Hixie>	smaug____: long term we need some solution to the DOM in workers anyway, even if it's just some nerfed versions of the objects
23:03	<wodemay>	its like the debate about @hidden vs. @irrelevant.
23:04	<Hixie>	wodemay: well, <i> still works, right? :-)
23:04	<wodemay>	Hixie, your point?
23:04	<smaug____>	I do think DOM will just work in workers
23:04	<Hixie>	wodemay: nameing them differently doesn't prevent them from being misused... just look at people using <blockquote> for indentation :-)
23:05	<wodemay>	Hixie, but accurate naming does have value (again, i'll cite the @hidden vs. @irrelevant debate)
23:07	<TabAtkins>	Hixie: Did you say somewhere that <intent> is okay to be a self-closing tag in the head?
23:07	<Hixie>	wodemay: certainly, but that value must be balanced against other concerns, e.g. backwards compatibility
23:07	<Hixie>	TabAtkins: my latest thinking on web intents is in a recent e-mail to the whatwg list, i do not recall my precise statements therein
23:07	<Hixie>	TabAtkins: though i intend to look at that topic again soon
23:07	<TabAtkins>	Darn, that means I"ll have to look it up.
23:08	<Hixie>	heh sorry :-)
23:09	<wodemay>	Anyone know when ECMA6 is meant to become widely implemented?
23:10	<TabAtkins>	Like HTML, it's implemented in bits and pieces.
23:10	<ojan>	Hixie: i think at some level the rub is what you svg/mathml magic you do
23:10	<wodemay>	How about `multi
23:10	<wodemay>	line
23:10	<ojan>	Hixie: i think also that lots of people will want <p>, <li>, <td> without a close tag to work
23:10	<wodemay>	string-literals`?
23:11	<ojan>	Hixie: other than that, i'm ok with your proposal as an alternative to implied context parsing
23:11	<ojan>	Hixie: wait are you saying also that things like <img> will require a close tag?
23:12	<Hixie>	ojan: i would just have the syntax support <foo/>
23:12	<gsnedders>	wodemay: I'd guess sometime in the next year and a half.
23:12	<ojan>	Hixie: ok...so it's basically xml?
23:12	<Hixie>	ojan: we could hardcode some specific tag names if people think that's necessary
23:12	<Hixie>	ojan: yeah
23:12	<wodemay>	gsnedders, but it's already in chromium/v8... right?
23:12	<Hixie>	ojan: like i said, it's very close to e4x
23:13	<ojan>	Hixie: would you be opposed to <p>, <li>, etc without a close tag?
23:13	<Hixie>	ojan: not especially, if it helped sell the feature :-)
23:13	<gsnedders>	wodemay: Not really. Both SM and V8 implement relatively small parts of ES6
23:13	<ojan>	lol, ok
23:13	<Hixie>	ojan: wouldn't be my first choice though :-)
23:13	<ojan>	Hixie: just trying to understand what you're proposing...
23:13	<gsnedders>	IE10 now supports at least Flash in Metro :(
23:13	<wodemay>	gsnedders, i was referring specifically to multiline string literal backtick syntax.
23:15	<gsnedders>	wodemay: Oh, that I don't know off-hand.
23:15	<Hixie>	ojan: making omitting an end tag work would be... interesting, because you end up having to hard-code into the JS parser the list of elements that imply the </p>
23:15	<gsnedders>	Please don't do that.
23:15	<roc_>	I'm a wee bit frustrated to post to the list saying "we're changing our behavior in Gecko and the spec needs to be updated" and get replies from other implementors saying "oh, we already changed that ages ago"
23:15	<Hixie>	roc_: agreed (and my apologies if the reason is that i'm not keeping the spec up to date fast enough)
23:16	<roc_>	I don't think so in this case :-)
23:16	<gsnedders>	Nor did jgraham when he mentioned it earlier :(
23:17	<wodemay>	rafaelw_, BTW, the "ship" isn't ever intended to "sail," so to speak, for new additions or features to HTML5, correct?
23:18	<Hixie>	wodemay: the ship sails when implementations ship
23:18	<Hixie>	boy that sentence could be clearer
23:18	<smaug____>	roc_: which case is this?
23:18	<wodemay>	Hixie, but that's a very regular sailing. It isn't a singular ship that sails and then never comes back. It's more like a ferry, right?
23:19	<Hixie>	wodemay: not sure a shipping metaphor is very apt to be honest :-)
23:19	<smaug____>	ah, some video thing
23:19	<Hixie>	wodemay: to put it in non-metaphorical terms, we can change the spec in any way that is compatible with the web
23:19	<wodemay>	hahah. but u follow me? Hixie
23:19	<Hixie>	wodemay: at any time
23:19	<wodemay>	Hixie, what does that mean?
23:19	<Hixie>	wodemay: e.g. we can't rename <p> to <b>, because that would cause zillions of pages to render differnetly than expected
23:20	<jamesr_>	they'd be upside down
23:20	<Hixie>	wodemay: but we can introduce a new element <askfjya78e6ads> because there is no page in the world that depends on it being implemented or not
23:20	<Hixie>	(i assume)
23:20	<Hixie>	(we'd have to check)
23:20	<wodemay>	so 20 years from now the current spec will still be some iteration of html5, but it might have some tags deprecated and some added, correct? and then the same will be true as compared to then 30 years from now?
23:21	<Hixie>	wodemay: well we don't call it "html5", we call it "html", but yes, essentially. until someone comes along with something that makes html obsolete once and for all.
23:21	<wodemay>	Hixie, hahah, talk about being thorough. ;) somehow i feel like there aren't!
23:21	<Hixie>	which i'm sure everyone here is hoping will happen as soon as possible
23:21	<wodemay>	Hixie, hahahahaha. me included!
23:21	<wodemay>	There should be something like JSON that makes it less redundant. or sthg that draws on HAML syntax.
23:22	<wodemay>	but why not call it "html5", Hixie ?
23:22	<roc_>	the thing is, people keep trying to kill HTML and we keep trying to stop them
23:23	<Hixie>	roc_: whose trying to stop them?
23:23	<roc_>	generally because the replacement is worse in some important dimension
23:23	<roc_>	Mozilla, other browser vendors, Web standards people
23:23	<Hixie>	roc_: people keep trying to kill html and they keep failing, i don't think we're stopping them
23:24	<roc_>	we're killing Flash
23:24	<Hixie>	adobe is killing flash
23:24	<kennyluck>	Who are trying to kill HTML?
23:24	<roc_>	Microsoft and Adobe tried
23:24	<Hixie>	wodemay: the question is not "why not", the question is "why" :-)
23:25	<smaug____>	W3C tried
23:25	<wodemay>	the answer in that case is "b/c it's more specific," Hixie
23:25	<Hixie>	wodemay: specific how?
23:25	<roc_>	hehe
23:26	<wodemay>	Hixie, it specifies the version number ..?
23:27	<Hixie>	roc_: i think the metaphor that applies here is something like "several people are building towers out of blocks. the people building the tower not labeled 'html' keep knocking down their towers by mistake or poor design. the tower labeled 'html' is a big heap and so doesn't fall."
23:27	<wodemay>	smaug____, what's the difference between WHATWG and W3C?
23:27	<Hixie>	roc_: it's not like the people building the html tower keep going over and knocking down the other towers
23:27	<roc_>	that is a good analogy
23:27	<gsnedders>	wodemay: But browsers never implement all of one version — they just implement bits and pieces.
23:27	<gsnedders>	wodemay: Version numbers only make sense if the spec gets implemented in full, but it never does.
23:28	<Hixie>	wodemay: there is no version. the spec changes daily, the browsers implement different slices of it at any one time and also change daily.
23:28	<wodemay>	is that why the html5 doctype dec is html and not html5?
23:28	<roc_>	that's not really what "kill" means in this context. No-one ever kills a competitor's product directly, only by out-competing it. And that's what we've done with HTML.
23:30	<ojan>	Hixie: what would you say the advantage of E4H is compared to implied context parsing?
23:30	<ojan>	Hixie: is it just that it's simpler for web developers? faster?
23:31	<gsnedders>	ojan: Harder to screw up. People notice syntax errors in JS.
23:31	<Hixie>	ojan: by "implied context parsing" you mean "runtime parsing of a string"? if so, the main advantage is compile-time syntax checking.
23:32	<Hixie>	roc_: i think there's a qualitative difference between out-competing by intentionally addressing a competitor's weaknesses and explicitly having as a goal the competitor's downfall, and out-competing by ignoring the competition and having them fall by the wayside
23:33	<Hixie>	roc_: and i would strongly suggest that HTML has done only the latter.
23:33	<Hixie>	ojan, rafaelw_: here's a strawman proposal: http://www.hixie.ch/specs/e4h/strawman
23:33	<ojan>	Hixie: oic...you wouldn't get syntax erros with the current quasis proposal either :(
23:33	<Hixie>	ojan, rafaelw_: (doesn't handle SVG yet)
23:33	<astearns>	<video> completely ignored everyone else, I'm sure :)
23:33	<Hixie>	ojan: oh, really? that's sad. i thought brendan said we would, based on the thread i cited earlier.
23:34	<ojan>	Hixie: i might be misreading http://wiki.ecmascript.org/doku.php?id=harmony:quasis
23:34	<Hixie>	astearns: <video> on HTML has basically failed, so i don't think it's a good example if you're trying to support roc's argument :-)
23:35	<Hixie>	astearns: (failed due to the codec gridlock; i don't think it's a permanent failure)
23:35	<astearns>	I hope it's not permanent
23:35	<TabAtkins>	It won't be.
23:35	<Hixie>	well worst case it'll resolve itself when the relevant patents expire
23:36	<astearns>	but whether something has succeeded or failed isn't relevant to whether it's a counterexample to "only the latter"
23:36	<roc_>	it'll resolve itself at the latest when improvements in video compression reach diminishing returns
23:36	<roc_>	but who knows? That could be 50 years away
23:36	<rafaelw_>	hixie: looking
23:36	<zewt>	roc: don't forget to add twenty years for patents to expire
23:37	<Hixie>	astearns: granted, but at least for me, adding <video> was just about filling in HTML's weaknesses, not trying to do something to hurt another platform
23:38	<Hixie>	astearns: e.g. if we wanted to hurt Flash we could have done things like make it click-to-play, or made it harder to sandbox, or made it not be able to see the DOM, or any number of things
23:38	<Hixie>	astearns: instead, alongside work on HTML there has been much work from browser vendors in actually making Flash work better
23:38	<Hixie>	hardly the sign of trying to damage a competing platform
23:39	<Hixie>	even Apple, who arguably did try to damage Flash on iOS, seem to be working to help Flash on MacOS with their sandboxing
23:39	<astearns>	I agree, but you're moving the goalposts from "ignoring" to "not intending to harm"
23:39	<wodemay>	Hixie, what does the term "HTML5" specify, then?
23:39	<roc_>	I think it's fair to say that a number of people have had a goal of enriching HTML to make Flash unnecessary, with the hope it will go away eventually
23:40	<Hixie>	astearns: "ignoring" was a poor choice of words; true. we do look at existing practices in other platforms.
23:40	<roc_>	on the grounds that we want authors to target multi-vendor royalty-free standards instead of single-vendor platforms.
23:40	<Hixie>	roc_: yeah, that's probably fair
23:41	<Hixie>	roc_: but i don't think that's the main reason flash has done poorly
23:42	<zewt>	bryan of the screaming caps name posting to a thread about mailing list practices is rather ironic
23:43	<Hixie>	ojan, rafaelw_: ok, added a strawman way of supporting svg and mathml too (requires that the element names be prefixed if they're in those namespaces)
23:44	<Hixie>	ojan:, rafaelw_: an alternative would be to only require that for the element that crosses to another namespace, and default the rest to the parent element's namespace
23:45	<Hixie>	ojan, rafaelw_: but that's a minor detail that could be figured out if this was to go anywhere
23:48	<ojan>	Hixie: i'm torn here. on the one hand, compile-time errors are nice. on the other, there's a cost in people needing to learn new things and there will perpetually be confusion about parsing that works in E4H, but not HTML or vice versa.
23:48	<ojan>	Hixie: at some level, how is this different from pushing for XHTML?
23:49	<ojan>	Hixie: also, I really like the API for quasis as a way of generating a DOM using javascript variables in an XSS-safe way
23:50	<ojan>	Hixie: see the safehtml function in the quasi's proposal to see what i mean
23:50	<ojan>	Hixie: and you don't get that with E4H, unless i'm missing something
23:51	<zewt>	ojan: compile-time errors aren't very nice; it makes code backwards-compat/polyfill/etc very hard
23:52	<zewt>	i don't want to have to serve entirely different scripts for different browser capabilities
23:53	<gsnedders>	zewt: That's true of any langauge extention, though
23:53	<gsnedders>	*language
23:54	<Hixie>	ojan: the substitution thing lets you sub in the value of expressions in e4h
23:54	<zewt>	gsnedders: sure, which is why language extensions shouldn't be used unless the justification is very strong
23:54	<Hixie>	ojan: but in general my argument isn't that we should do e4h, my argument is that hte use case of "make a dom tree" should be solved using a better solution than "parse a string at runtime" and a better solution than "use an excessively verbose api"
23:55	<ojan>	Hixie: well...the proposal with backing so far has been quasis + safehtml
23:55	<Hixie>	zewt: no, it's why the language should be designed to make syntax errors block-scopable, imho :-)
23:55	<ojan>	Hixie: i suppose you could make safehtml do roughly what e4h does
23:55	<ojan>	Hixie: while still using quasis
23:56	<Hixie>	ojan: i'm not very familiar with it, do you have a link? the only proposal i was aware of was "make the html parser even more complicated and add DocumentFragment.innerHTML" (or document.parse(), same idea)
23:56	<ojan>	Hixie: but you would still get a runtime erro instead of compile error
23:56	<ojan>	Hixie: i linked above
23:56	<Hixie>	got it
23:58	<Hixie>	ojan: so this just gets implemented as a JS lib? not in the browsers?
23:58	<Hixie>	ojan: the html-specific part, i mean
23:58	<ojan>	Hixie: it can be, but in the case of the html-specific part, the browser would also provide it builtin
23:59	<ojan>	Hixie: so, pages could polyfill w a JS function
23:59	<Hixie>	(btw, i don't really understand how the filtering is done, seems like it'd be a huge rathole of possible ways things should be escaped)
23:59	<Hixie>	so how does the HTML parsing happen here?
23:59	<ojan>	Hixie: for browsers that support quasies, but not the safehtml functio that is.