#whatwg on 2008-06-17

01:04	<takkaria>	could anyone confirm my reading of the tokenisation part of the spec, that '<h a="&not">' should result in an 'a' attribute containing the not symbol?
01:05	<takkaria>	oh, wait, I think I see my problem
07:00	<heycam>	Dashiiva, fixed the thing you mentioned earlier
07:14	<othermaciej>	Hixie: sicking said almost everything I would have said in his reply to Microsoft's feedback
07:14	<othermaciej>	I am tempted to +1
07:15	<Hixie>	heh
07:15	<Hixie>	i haven't read it yet
07:15	<Hixie>	i can't believe they stuffed so much filler crap into that feedback
07:16	<Hixie>	on another note, the htmlwg bugzilla hasn't had any activity for at least 6 hours
07:16	<othermaciej>	I was dismayed that many of their quotes were clearly out of context
07:17	<othermaciej>	or at least, they turned them towards ends that I am pretty sure the authors of said comments did not intend
07:17	<othermaciej>	this cast doubt on the contextual validity of their other quotes for me
07:18	<Hixie>	hence the version i provded that just has their actual feedback
07:18	<Hixie>	stripping out the stuff that doesn't actually contibute
08:05	<heycam>	Dashiva, in your mail you said s14 of the [[Put]] can be removed. why's that?
08:13	<Dashiva>	heycam: If you would jump in s14 there's no such property. That means that in s15, there can't be a property with putforwards either (since there's no property)
08:15	<heycam>	but you jump in s14 if there is no property
08:15	heycam	confused
08:16	<Dashiva>	And you jump in s15 if there is no property (or there is a property, and it's not putforwards)
08:16	<Dashiva>	Essentially s15 is all of s14 + check putforwards
08:18	<heycam>	true i could combine s14 and s15 to say "If O does not have a property with name P, or if it does but it does not blah blah [PutForwards] ..."
08:19	<heycam>	i split them only to avoid a big conditional thing like that
08:19	<Dashiva>	I just figured 'does not correspond to an attribute' included the case 'there is no such attribute'
08:20	<heycam>	ah, k
08:20	<Dashiva>	Also, it seems a bit string to split on attribute exists/not in step 14, and then combine them into step 19, and then split again in step 21
08:20	<Dashiva>	s/string/strange/
08:20	<heycam>	or you figured "If the property on O with name P does not correspond ..." could still evaluate to false if there is no such property
08:21	<Dashiva>	Yeah. I see it might not be spec-level clarity.
08:23	<heycam>	so with the splitting on 14 / combining on 19 / splitting on 21... could you elaborate?
08:24	<Dashiva>	If the property does not exist, or if the property exists but is not putforward, in both cases it is necessary to run [[CanPut]].
08:24	<Dashiva>	(which is step 19)
08:26	<heycam>	yep...
08:26	<Dashiva>	And step 19 leads to step 21, where it checks if the property exists. Again.
08:30	<heycam>	so you'd rather have two branches from s14/s15, and include the [[CanPut]] in both?
08:31	<heycam>	or i could bring the [[CanPut]] up above s14 (but then it's irrelevant if we get to s16)
08:31	<Dashiva>	I'd rather not branch on 14, and just send both cases to 19.
08:32	<Dashiva>	Hmm... actually...
08:33	<Dashiva>	PutForwards implies a Readonly attribute, so we can't CanPut before it anyhows, I believe
08:34	<heycam>	right (well, the [[CanPut]] could be done, but not the return based on it)
08:35	heycam	wonders if he should write up his algorithms as C code and then run gcc -S -O9 on them to try to minimise them :)
08:36	<Dashiva>	Would unifying 14 and 15 be easier if the conditional was inverted? e.g. if there is a property with name P and that property has extattr putforwards, jump to steps equivalent to 16-18. And then the canput stuff following instead of in a jump.
08:38	<heycam>	yeah that probably would
08:39	<Dashiva>	Oh well. As long as [[CanPut]] happens for both new and old properties, I suppose this is just bikeshedding.
08:40	<heycam>	i should have a "you can implement these how you want as long as the observable effects are the same" in the spec somewhere (but don't yet)
08:41	<Dashiva>	By the way, is the special casing of 2^32-1 for integer indexes explained somewhere?
08:42	<heycam>	not in the document
08:42	<heycam>	although now i wonder if it is really necessary
08:42	<heycam>	since such host objects won't necessarily have a .length property on them
08:42	<heycam>	(which is the reason it is like that for Array objects)
08:44	<Dashiva>	Oh, of course. Then it makes perfect sense.
08:45	<Dashiva>	I didn't think of .length being greater than the max index
08:45	<heycam>	yeah it makes sense for Array. not sure for IndexSetters...
08:45	heycam	adds an ednote
08:45	<Dashiva>	It's good for consistency, though. :)
08:46	<heycam>	true
08:52	heycam	dinners
08:52	Dashiiva	avoids comments about barbies
08:55	<virtuelv>	Dashiiva: wanna go shopping?
10:19	<Hixie>	rb is 50% of the html4all traffic too
10:19	<Hixie>	that's funny
10:20	<zcorpan>	Hixie: does it make sense for the ratechange event to be cancelable?
10:21	<Hixie>	does it have a default action?
10:21	<zcorpan>	not afaict
10:21	<Hixie>	then it doesn't matter
10:21	<zcorpan>	fair enough
10:23	<Hixie>	teehee, on june 6th rb asked gregory to forward many of his comments on html5 to the xhtml2 group
10:23	<Hixie>	but as far as i can tell, that didn't happen
10:26	<zcorpan>	"When the defaultPlaybackRate or playbackRate attributes change value", setting to the value it already has means it hasn't changed right
10:31	<Hixie>	i guess
10:32	<Hixie>	i can specify it the other way if that's what UAs want
10:32	<Hixie>	hey does anyone know what the status of the svgwg's work on the svg parsing thing is?
10:32	<Hixie>	i don't recall ever hearing back from them
10:32	<Hixie>	and it's been what, two months now?
10:34	<hsivonen>	ouch. document.write writing a script that document.writes is more complex than I first thought :-(
10:35	<hsivonen>	Hixie: do you know if Gecko and WebKit really call the parser re-entrantly or whether they interleave parser and script execution using a run queue?
10:35	<Hixie>	no idea what their implementation does
10:35	<Hixie>	the net result is basically what the spec says though
10:35	<Hixie>	though the spec is mildly more complex to handle script async and script defer
10:36	<hsivonen>	I had happily assumed a run queue model, but now that I try to write it down in the case where document.write document.writes, it starts to get ugly
10:36	<virtuelv>	hsivonen: document write is evil
10:37	<virtuelv>	I hacked up a bunch of testcases that indicates that no two browsers behave the same
10:37	<Hixie>	the browsers are pretty close to each other, most of the differences are obvious bugs
10:37	<virtuelv>	Hixie: I'll ask if I can release the TC's somewhere
10:37	<virtuelv>	I'm not sure what are bugs or not
10:38	<virtuelv>	document.write in setTimeout calls are so much fun
10:38	<hsivonen>	Hixie: anyway, I have trouble wrapping my head around the spec assertion that the tree builder is re-entrant
10:38	<Hixie>	they should just blow away the document
10:38	<Hixie>	hsivonen: oh?
10:38	<hsivonen>	Hixie: it seems to me that the parser doesn't need to be re-entrant
10:39	<virtuelv>	Hixie: suffice it to say that browsers in general don't cancel the timeout
10:39	<Hixie>	hsivonen: just like any thing that you can implement as a recursive function can be implemented with a hand-managed stack? or more so?
10:39	<hsivonen>	Hixie: right
10:39	<Hixie>	hsivonen: well sure
10:40	<Hixie>	hsivonen: recursive algorithms are what the spec uses generally because they're easier to explain and understand, but they're not what i'd recommend implementing
10:40	<Hixie>	hsivonen: though iirc the parser's re-entrancy is only ever one level deep
10:41	<hsivonen>	Hixie: instead of recursing, a single-threaded browser engine should be able to put the parser state on the heap and spin through the event loop
10:42	<Hixie>	well the parser has to be interruptible in a browser anyway
10:42	<Hixie>	so it would just interrupt itself
10:42	<Hixie>	returning to the vent loop
10:43	<Hixie>	event
10:43	<hsivonen>	Hixie: right. and once you make it interruptible, I don't see why you'd ever want the tree builder to be re-entrant
10:43	<Hixie>	indeed
10:43	<hsivonen>	So I'm again in a situation where I'm trying to unroll the spec definition into something else but equivalent
10:43	<Hixie>	that is an expected situation, yes
10:44	<Hixie>	no spec will ever directly map to all implementations
10:47	<hsivonen>	Hmm. I can't figure how to make three-level-deep document.write have the right execution order in a GWT context where the browser owns the script execution but the script owns the parser
10:47	<hsivonen>	too bad. I can't use GWT to fully try stuff out then
10:49	<Hixie>	heh
10:49	<annevk>	http://www.p01.org/releases/DHTML_contests/files/20lines_hypno_trip_down_the_fractal_rug/
10:50	<roc>	Hixie: there was a discussion here with Doug Schepers a while ago about the SVG parsing thing
10:50	<Hixie>	roc: yeah, i think i saw that
10:50	<roc>	annevk: wow
10:50	<hsivonen>	hmm. I'm starting to suspect the "generic [R]CDATA algoritm" and the way Gecko executes document.written scripts doesn't match
10:50	<hsivonen>	hmm.
10:51	<roc>	annevk: somewhat abusive use of "20 lines" though
10:51	<annevk>	Hixie, I don't think there was much progress, though they assigned some actions
10:51	<annevk>	roc, "20 lines" is a dubious concept anyway :)
10:51	<hsivonen>	roc: I seriously think the same tokenizer should handle both HTML and SVG islands
10:52	<Hixie>	hsivonen: gecko has some thing where adding text to a script that hasn't executed will still execute
10:52	<Hixie>	hsivonen: i'm not sure if we need to put that in html5 or if gecko can change, it's something i should probably look at
10:52	<roc>	it seemed clear that a) the SVG group has a requirement that parsing of SVG fragments should impose XML-esque validation with strict error handling and that b) you have a requirement that parsing SVG fragments should not impose strict error handling
10:53	<Hixie>	that appears to be the case, yes
10:53	<hsivonen>	roc: in addition to requiring non-strict error handling for SVG fragments, I also want to require avoiding complexity in the parser
10:53	<roc>	so it doesn't really matter what the proposed solution is, since those two requirements are irreconcilable
10:54	<hsivonen>	roc: I'm OK with complexity imposed by the legacy Web
10:54	<hsivonen>	roc: I'm not OK with introducing new complexity for XML purity
10:54	<hsivonen>	we have to define what document.write does inside an SVG fragment
10:55	<hsivonen>	if the same tokenizer is used, document.write inside SVG doesn't cause new complexity
10:55	<Hixie>	roc: they're not completely irreconcilable, you could come up with some schemes where you fall from one to the other (and the remainder is treated as html, not svg)
10:55	<Hixie>	roc: but it does seem unlikely that such a scheme would fit into the various constraints we have
10:55	<Hixie>	anyway
10:55	<hsivonen>	if we'd change to an XML parser mid-stream, we'd have to figure out what exactly document.write does and how it can be implemented sanely
10:55	<annevk>	that's what they're looking at, but it's not really clear to me how that works with tokenizing etc.
10:55	<roc>	that's what Doug wanted to do actually
10:56	<Hixie>	i was just wondering if there was anything i needed to work on
10:56	<Hixie>	apparently there isn't yet
10:56	<annevk>	<keygen>
10:56	<Hixie>	<keygen>?
10:56	<roc>	okay, so if you would accept strict SVG parsing with errors falling back to HTML parsing, then progress is possible
10:56	<roc>	in theory
10:57	<Hixie>	potentially
10:57	<hsivonen>	I'd much rather spend my time delivering an additional serializer to address the copy-paste requirements of the SVG WG than to spend my time writing two tokenizers that can be switched mid-stream
10:57	<Hixie>	i'm not convinced such a scheme would work, but we'll find out in due course
10:57	<annevk>	Hixie, I guess that's part of WF2, but it'd be nice if it was in a spec so it becomes easier to advocate Koreans for instance into using it
10:57	<roc>	someone should ping them
10:58	<roc>	hsivonen: it's clear that having browsers reserialize as XML when copy/pasting is the right thing, but the SVG WG insists that copy-pasting in a text editor is a requirement
10:58	<hsivonen>	I'm not convinced the complexity imposed by additional strictness is a good use of anyone's limited resources
10:58	<hsivonen>	roc: I'd prefer to go with the right thing
10:58	<roc>	they want both
10:59	<Dashiiiva>	<pony/>
11:00	<hsivonen>	roc: it's easy to want it if writing the parser is Someone Else's Problem
11:00	<roc>	such is the life of the implementor
11:01	<annevk>	it doesn't really make sense to just accept that roc, imo
11:01	<roc>	I'm just the messenger
11:01	<Hixie>	annevk: send me a spec
11:02	<annevk>	if we just implemented whatever the W3C came up with we'd never beat Flash
11:02	<Philip`>	I think it wasn't clear whether they'd be unhappy with using the current SVG-in-HTML parsing rules and just defining conformance so that the content must be well-formed XML, so that conforming HTML5 SVG could always be copied into a real XML document, which seems to me kind of nicer than actual XML parsing since it wouldn't affect the parser at all
11:02	<annevk>	Hixie, I can't really get anything better than the old Netscape one, I guess I should try harder
11:02	<annevk>	:/
11:02	<roc>	Philip`: what do you mean "conforming"? They want browsers to check for well-formed XML of the SVG fragment before rendering it.
11:03	Philip`	suggests black-box reverse engineering of <keygen>
11:03	<hsivonen>	Philip`: it does affect at least a parser if you expect that level of conformange to be checked in software
11:03	<Hixie>	annevk: neither could i, and that was basically useless
11:04	<Hixie>	right well. bed time. nn.
11:04	<hsivonen>	Hixie: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Adocument.write(%27a%27)%3B%0Adocument.write(%27%3Cscript%3Edocument.write(%22c%22)%3C\%2Fscript%3E%27)%3B%0Adocument.write(%27b%27)%3B%0A%3C%2Fscript%3E%0A has the same result in Gecko and WebKit
11:04	<Philip`>	roc: I don't think all of 'they' considers that as an absolute requirement, so they could perhaps be convinced away from that
11:05	<roc>	I tried
11:06	<roc>	with Doug at least. The WG as a whole hasn't been all that responsive to my other issues
11:06	<roc>	I wonder what heycam's position is on all this
11:19	<hsivonen>	I guess I should go read some browser source on how document.write is implemented
11:21	<othermaciej>	document.write writes at the current insertion point
11:21	<othermaciej>	which might be beyond the end of the current script element
11:22	<othermaciej>	if it document.wrote something already
11:23	<hsivonen>	othermaciej: in WebKit, does the script engine call into the parser on document.write or schedule stuff for running and return to the main loop?
11:23	<othermaciej>	actually the insertion point starts right after the script, per-script, so when you document.write a script and then document.write something else, and that script document.writes, I think the content gets inserted before whatever was written after the second script
11:23	<othermaciej>	it just inserts stuff into the queue of characters to process
11:23	<othermaciej>	it does not return to the main loop at all
11:23	<othermaciej>	script execution during parsing is synchronous and blocks the parser
11:24	<hsivonen>	but when document.written data gets parsed, are there script engine stack frames on the call stack?
11:25	<hsivonen>	so if document.write document.writes, will the script engine be entered re-entrantly?
11:25	<othermaciej>	the script engine can be re-entered via the parser using innerHTML
11:25	<othermaciej>	but not document.write, I don't think
11:25	<othermaciej>	since nothing that document.write writes (to the current, parsing document) is processed until after the script completes execution
11:26	<hsivonen>	othermaciej: that doesn't seem to be the case
11:26	<hsivonen>	http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Adocument.write('a')%3B%0Adocument.write('%3Cscript%3Edocument.write(%22b%22)%3C%5C%2Fscript%3E')%3B%0Adocument.write('c')%3B%0A%3C%2Fscript%3E
11:26	<othermaciej>	well I could be misremembering it, this is a very confusing area
11:27	<hsivonen>	the document.written script runs before the script that wrote it finishes
11:27	<othermaciej>	is that true?
11:27	<othermaciej>	the live dom viewer does not prove that
11:27	<othermaciej>	the output ("abc") is consistent with what I described
11:28	<Lachy>	hsivonen, no, othermaciej is right.
11:28	<othermaciej>	first 'a<script>document.write("b")<\/script>c' is injected into the character stream right after the first script
11:28	<othermaciej>	then a is parsed
11:28	<othermaciej>	then the second script
11:28	<othermaciej>	which causes b to be injected into the token stream right after the second script
11:29	<othermaciej>	then c is parsed
11:29	<othermaciej>	each script starts with an insertion point right after its end tag
11:29	<hsivonen>	ah. excellent. That's what I thought at first, and then I got tangled in confusion
11:29	<othermaciej>	which may not be the same as the end of all currently inserted content
11:29	<annevk>	I wonder why Opera has two separate text nodes for bc
11:30	<hsivonen>	so why does the spec talk about re-entrant calls to the tree builder?
11:30	<Lachy>	hmm, maybe not.
11:30	<Lachy>	document.write('a');
11:30	<Lachy>	w(1);
11:30	<Lachy>	document.write('<script>document.write("b");w(3);<\/script>');
11:30	<Lachy>	w(2);
11:30	<Lachy>	document.write('c');
11:30	<Lachy>	that doesn't work as I'd expect it to.
11:31	<Lachy>	at least in Firefox.
11:32	<Lachy>	or in WebKit.
11:32	<Lachy>	w(3) is executing before w(2), so it seems it's not waiting until the first script is finished.
11:38	<othermaciej>	yeah that didn't do what I expected either
11:39	<othermaciej>	seems like it can re-enter to arbitrary levels
11:39	<othermaciej>	<script>
11:39	<othermaciej>	document.write('a');
11:39	<othermaciej>	alert(1);
11:39	<othermaciej>	document.write('<script>document.write("b<script>document.write(\'c\'); alert(4);<\\/script>"); alert(3);<\/script>');
11:39	<othermaciej>	alert(2);
11:39	<othermaciej>	document.write('d');
11:39	<othermaciej>	</script>
11:42	<hsivonen>	alert requires UI to be responsive
11:42	<hsivonen>	does alert establish a nested event loop or does alert cause the call stack to unwind to the main event loop?
11:43	<hsivonen>	document.write is hard
11:55	<othermaciej>	alert makes a modal event loop
11:55	<othermaciej>	it does not cause all UI to be responsive
11:56	<hsivonen>	in Firefox 3, alert is window-modal, although, as I understand it, the windows have their UI run on one thread
11:57	<hsivonen>	alert seems app-modal is Safari
12:07	<heycam>	roc, sorry for the delay on your www-svg issues
12:07	<heycam>	(note that a couple of them are on the agenda for today's telcon (which i won't be at))
12:08	<hsivonen>	I'm getting curious about support for incremental rendering of document.written content
12:09	<annevk>	<script> without async is not so good for incremental rendering
12:11	<heycam>	as for html in svg, i have to say that i (persionally) haven't had time to look into it. i believe the others did something on it at the F2F recently, and are writing up some text, but i haven't seen it.
12:11	heycam	tv ⇒ afk
12:15	<hsivonen>	annevk: <script> without async could be good for incremental rendering, if a) layout runs on a different thread or b) the script engine stack is really on the heap, so that the C++ stack can unwind without breaking script state
12:16	<hsivonen>	however, I just saw some Gecko code that makes me want to write a test case to see if incremental layout works from document.written content
12:17	<hsivonen>	it seems safe to assume that Presto and Trident have concurrency models that differ significantly from Gecko and WebKit, which I gather are more alike
12:50	<Lachy>	hey, I just realised that <iframe sandbox=""> could potentially create a false sense of security. If a website author uses it to embed user comments and hosts the comment file on the same domain as the parent page, it only protects the user as long as the comment page isn't viewed outside of the iframe.
12:52	<Lachy>	so websites would still need to filter out as much as possible, and keep sandbox="" only as a last line of defence.
12:54	<Philip`>	That would matter if you used <iframe sandbox src=...>, but you can't use that because it's unsafe in UAs that don't support sandboxing
12:54	<Lachy>	at the moment, that's the only way to do it, since there isn't yet a way to embed the markup inline.
12:54	<Philip`>	so you'd have to use <iframe sandbox doc="user's raw comment" src="some-file-with-user's-sanitised-comment.html"> and then it's alright anyway
12:55	<Lachy>	doc="" isn't specced yet.
12:56	<Lachy>	if you were going to sanitise the comment, then why embed the raw comment inline?
12:57	<Lachy>	I'm just not convinced sandox is a good solution for sandboxing user contribued content. It could be good for embedding content from 3rd party sites though.
12:58	<Philip`>	The sanitised comment might strip out lots of safe content and styles that aren't in the whitelist, so it's uglier for users than the original unsanitised (sandboxed) comment
12:59	<Philip`>	so if their UA supports sandboxing then they can benefit from getting the unsanitised version
12:59	<Lachy>	if your sanitiser code is that bad, it's time to rewrite it.
13:01	<Philip`>	If it was possible to write a sanitiser that wasn't bad, why would anyone want client-side sandboxing?
13:01	<Lachy>	I just don't think it's a good idea to ever send unsanitised code to browsers. Imagine if there was a browser bug that inadvertently allowed something it shouldn't, and there were sites that published fully unsanitised comments, then you can bet there would be exploits pretty quickly.
13:02	<Lachy>	incase their sanitiser missed something by mistake, not because it could accidently remove something it shouldn't.
13:04	<othermaciej>	having both sanitization and client-side sandboxing is safer
13:04	<othermaciej>	to get an exploit through, you'd need matching mistakes on both ends
13:04	othermaciej	is failing to sleep
13:05	<Lachy>	othermaciej, right. But if the server didn't sanitise, then the browser is the only line of defence, and you'd better hope there's no bug in it.
13:05	<othermaciej>	why is that a "but"?
13:06	<Lachy>	because I'm concerned that sandbox="" could create a false sense of security, where silly developers don't bother sanitising the code, and then it really doesn't depend on there being matching mistakes on both ends.
13:07	<Lachy>	it's just one really big mistake on the server side and whatever small mistake in the browser is enough.
13:08	<Lachy>	and if even Philip` is suggesting sending unsanitised code to browsers, I'm sure there will be developers in the wild crazy enough to do so as well.
13:10	<othermaciej>	one obviously shouldn't even remotely consider sending unsanitized code to browsers until sandbox="" is widely implemented, which won't be for a while
13:11	<othermaciej>	but even then it's probably not a good idea
13:11	<othermaciej>	defense in depth and all
13:11	<Philip`>	You could send unsanitised code in doc="" even if sandbox="" isn't implemented yet, as long as nobody implements doc="" before implementing sandbox=""
13:12	<othermaciej>	I'm willing to entertain the notion that adding sandbox="" could in some cases hurt security through second-order effects like you describe
13:13	<othermaciej>	but I think it is likely not the case, because the vast number of sites currently doing blacklist-based instead of whitelist-based sanitization may well be better off with sandbox="" and no server-side sanitization at all
13:19	<Lachy>	why? Blacklist sanitation is better than nothing, even though it's clearly a flawed approach.
13:20	<virtuelv>	blacklists do not scale
13:20	<Lachy>	virtuelv, yeah, I know that.
13:20	<virtuelv>	and especially if it's about cleaning markup
13:20	<othermaciej>	I would expect every blacklist-based filter to have holes, while browsers could plausibly implement sandbox="" close to correctly
13:21	<othermaciej>	nontheless, I think it is best to both filter on the server and use client-side restrictions
13:27	<Lachy>	jgraham__, yt?
13:28	<Lachy>	jgraham__, are you ever intending to finish and publish that @media blog post on the whatwg blog?
13:49	<zcorpan>	Hixie: shouldn't currentLoop be readonly?
15:55	<annevk>	If someone else wants to reply again to the sandboxing thread, be my guest. It seems obvious to me that his solution is flawed, but I can't really put it in words.
15:57	<annevk>	<applet> use case: http://wordle.net/gallery/Faux_Columns
15:57	annevk	can't see the outcome
15:58	annevk	isn't sure whether that justifies <applet> or whether it's a sign that plugins are harmful
15:58	<Philip`>	<applet ... /> ... </applet>
15:59	<Philip`>	Oh wait
15:59	<Philip`>	Ignore me, I can't read
15:59	<Philip`>	(I missed the '><param' in the middle)
15:59	<annevk>	quirks mode :/
16:00	<Philip`>	That seems like an unnecessarily fancy way to display a static image
16:01	<annevk>	<applet> has a print() method?
16:01	<Philip`>	Oh, apparently that is actually necessary, in order to put the computation load on the clients instead of the server
16:04	<Philip`>	(and it's not possible to do on the client even with the not-yet-implemented canvas text support, since it needs to analyse the shape of the characters)
16:35	<csarven>	Is Safari treating it properly if <object type="text/html" data="#foo"></object> includes the current document? Firefox2, Opera9.5 and IE7 doesn't.
16:36	<annevk>	per HTML5, yes
16:37	<annevk>	per HTML4, probably also yes
16:40	<csarven>	Good to here that.
16:43	<csarven>	Except that Safari includes the whole document and not just the contents of the element with id "foo"
16:43	<gsnedders>	csarven: that's right
16:43	<annevk>	csarven, that would be correct, actually
16:43	<gsnedders>	csarven: It should load the same as what loading a URI with a fragment would do normally
16:43	<annevk>	csarven, there's no special treatment specified
16:44	<csarven>	Is there a user for the fragment identifier then?
16:44	<csarven>	s/user/use
16:52	<annevk>	it will show that within the <object>
16:52	<annevk>	http://simon.html5.org/html5-elements uses that for instance
17:01	<csarven>	annevk I see an <iframe> instead of <object>
17:01	<annevk>	it would work the same way
17:20	<csarven>	annevk If data value is a fragment identifier of the current page, is it expected for the UA to not request the current page seperately?
17:22	<annevk>	they're not handled specifically so I'd expect an additional request
17:22	<annevk>	though given that three browsers disagree with WebKit it might be worth noting somewhere to see whether Opera/Firefox are planning on fixing this
19:15	<Hixie>	hsivonen: as far as i can tell, all the examples you posted and what othermaciej was saying are consistent with the spec
19:16	<hsivonen>	Hixie: yeah, they are. my understanding of document.write was flawed. sorry.
19:19	<Hixie>	np
20:04	<hsivonen>	I could use a more detailed diagram of how document.write is supposed to work
20:05	<hsivonen>	I'm having doubts about whether the "insertion point" is the most intuitive concept
20:06	<hsivonen>	and if treating document.written data as separate buffers that get pushed to the tokenizer would be easier to grasp
20:19	<zcorpan_>	googling for "acid3" shows a link "FAIL" to http://acid3.acidtests.org/empty.txt , that's pretty funny
20:20	<zcorpan_>	Hixie: clearly, google isn't standards compliant
20:22	<Lachy>	is anyone here actually able to load getfirefox.com and download FF3 now? I can't connect.
20:22	<webben>	Lachy: That's a common experience.
20:23	<Lachy>	it's not good enough. How do they expect to break a world record like this?
20:23	<webben>	are they trying to?
20:23	<Lachy>	yes, haven't you heard?
20:23	<zcorpan_>	Lachy: wfm
20:23	<didymos>	Lachy, John Gruber at Daring Fireball is saying the same thing
20:24	<Lachy>	http://weblogs.mozillazine.org/asa/archives/2008/06/download_day_st.html
20:24	<webben>	nah, I've studiously avoided all the hypes and just kept downloading latest prereleases ;)
20:24	<didymos>	personally, I got there at first attempt (just now)
20:24	<Lachy>	the link to the world record page won't work either.
20:24	<webben>	yeah, was just gonna say ;)
20:25	<Hixie>	google fails acid2 as well iirc
20:26	<zcorpan_>	Hixie: that clearly shows google's commitment to standards ;)
20:26	<Lachy>	google is a non-visual UA with little, if any, support for JS. So it doesn't really have much hope of fully passing the tests.
20:32	zcorpan_	finds registerProtocolHandler() in the firefox advanced tips
20:37	zcorpan_	finds that http://www.mozilla.com/js/firefox-video-launch.js is text/html
20:38	<gsnedders>	zcorpan_: Who needs correct MIME types?
20:38	<zcorpan_>	gsnedders: indeed
20:53	<hsivonen>	Hixie: I'm reading https://bugzilla.mozilla.org/show_bug.cgi?id=95487#c39
20:53	Hixie	learns his backup system has been broken since february
20:53	<Hixie>	"oops"
20:54	<hsivonen>	Hixie: which seems to confirm my guess that document.written content is parsed without letting the event loop breathe
20:54	<Hixie>	sounds plausible
20:55	<hsivonen>	Hixie: does the spec expect the relationship of normal parsing and the first level of doc.write and the relationship of the first and second levels of doc.write to be different somehow
20:55	<hsivonen>	?
20:55	<Hixie>	yes, you can only recurse once
20:56	<hsivonen>	Hixie: what takes care of preventing deeper recursion?
20:56	Hixie	looks
20:57	hsivonen	wonders if document.write was considered a simple feature in the Netscape 2 design phase
20:58	<Philip`>	I imagine they designed it to be simple to implement in their architecture, and as hard as possible for any competitors to implement in their different architectures :-)
21:00	<Hixie>	hsivonen: step 3 of document.write()
21:00	<hsivonen>	"If there is a script that will execute as soon as the parser resumes, then the method must now return without further processing of the input stream."?
21:01	<hsivonen>	why does the behavior othermaciej showed earlier follow?
21:01	<Hixie>	yeah
21:02	<hsivonen>	in that case, the second level of document.write wrote a third level of script that executed similarly relative to the second level as the second level did relative to the first level
21:03	<Hixie>	give me a concrete example and i'll try to describe how it runs
21:03	<hsivonen>	http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3E%0D%0Adocument.write('a')%3B%0D%0Aalert(1)%3B%0D%0Adocument.write('%3Cscript%3Edocument.write(%22b%3Cscript%3Edocument.write(%5C'c%5C')%3B%20alert(4)%3B%3C%5C%5C%2Fscript%3E%22)%3B%20alert(3)%3B%3C%5C%2Fscript%3E')%3B%0D%0Aalert(2)%3B%0D%0Adocument.write('d')%3B%0D%0A%3C%2Fscript%3E%0D%0A
21:03	<othermaciej>	it looks like in Firefox and WebKit at least execute scripts that are document.written while executing another script
21:03	<othermaciej>	I made this test case:
21:03	<othermaciej>	<script>
21:03	<othermaciej>	document.write('a');
21:03	<othermaciej>	alert(1);
21:03	<othermaciej>	document.write('<script>document.write("b<script>document.write(\'c\'); alert(4);<\\/script>"); alert(3);<\/scr\
21:03	<othermaciej>	ipt>');
21:03	<othermaciej>	alert(2);
21:03	<othermaciej>	document.write('d');
21:03	<othermaciej>	</script>
21:03	<othermaciej>	(sorry for bad line break)
21:03	<othermaciej>	it alerts 1 4 3 2
21:03	<othermaciej>	but prints abcd
21:05	<Hixie>	ok hsivonen
21:05	<Hixie>	so
21:05	<gsnedders>	jgraham__: ping
21:06	<Hixie>	we tokenise up to the bottom of the input
21:06	<jgraham_>	gsnedders: Here, sorta
21:07	<gsnedders>	jgraham_: How do you get what's under `elif rank(element) >= rank(self.current_section.heading):` from the spec?
21:07	<Hixie>	then we create a <Script> element and mark it "parser-inserted"
21:08	<Hixie>	let "old insertion point" be "uninitialised"
21:08	<Hixie>	let "insertion point" be just after the </script>
21:09	<Hixie>	we then insert the element into the DOM and run the script, which goes as follows:
21:10	<Hixie>	first a call to document.write()
21:10	<Hixie>	step 1: insertion point is defined, skip this step
21:11	<Hixie>	step 2: "a" is inserted after </script>
21:11	<Hixie>	step 3: skip this step
21:11	<gsnedders>	jgraham_: As far as I can see, you deviate from the spec
21:12	<Hixie>	step 4: run the tokeniser on the new input (just "a"), which just causes a text node saying "a" to be appended after the <script> in the DOM
21:12	<Hixie>	step 5: return
21:12	<Hixie>	next an alert. we alert "1".
21:12	<Hixie>	next another document.write().
21:12	<Hixie>	step 1: insertion point is defined, skip this step
21:12	<jgraham_>	gsnedders: I'll have a look.
21:13	<gsnedders>	jgraham_: Meaning Hixie's algorithm is broken, and it's not an implementation bug on my behalf
21:13	gsnedders	hopes it is Hixie's fault so then he doesn't have to deal with it :P
21:13	<Hixie>	step 2: just after the "a" (and before the insertion point) we insert \|<script>document.write("b<script>document.write('c'); alert(4);<\/script>"); alert(3);</script>\|.
21:13	<Hixie>	step 3: skip this step
21:14	<Hixie>	step 4: run the tokeniser:
21:14	<Hixie>	we tokenise a <script>
21:14	<Hixie>	create a <script> element.
21:14	<Hixie>	mark it as "parser-inserted".
21:15	<Hixie>	tokenise until we get the </script>, and append that string to the <script>
21:15	<Hixie>	let "old insertion point" be just after the last inserted piece of text (basically the end of the file)
21:16	<gsnedders>	jgraham_: I must be blind if it is in the spec :)
21:16	<Hixie>	we let "insertion point" be the same, actually.
21:17	<Hixie>	append the <script> to the DOM
21:17	<Lachy>	hmm, weird. Whenver I'm able to load getfirefox.com, it still links to Firefox 2
21:17	<Hixie>	this is the script that says \|document.write("b<script>document.write('c'); alert(4);<\/script>");alert(3);\|
21:18	<Hixie>	it's inline, so it executes.
21:18	<jgraham_>	gsnedders: I really should have commented this code more :)
21:18	<Hixie>	we call document.write() again.
21:18	<jgraham_>	The relevant part of the spec is "Otherwise, if the element being entered has a rank equal to or greater than the heading of the current section, then create a new section and append it to the outline of the current outlinee element, so that this new section is the new last section of that outline. Let current section be that new section. Let the element being entered be the new heading for the current section."
21:18	<jgraham_>	But I have no idea if that's the same as my implementation or not
21:19	<hsivonen>	Hixie: so far, we haven't had "a script that will execute as soon as the parser resumes", right?
21:19	<Hixie>	correct (in fact i think we won't because in this example you never have <script src="">)
21:19	<gsnedders>	jgraham_: It's totally different
21:20	<gsnedders>	jgraham_: the spec needs three lines
21:20	<Hixie>	so i guess the spec doesn't (and shouldn't) limit it to two deep for inline scripts
21:20	<gsnedders>	jgraham_: and no loop
21:20	<Hixie>	do you want me to continue?
21:20	<hsivonen>	Hixie: no need to. thank you.
21:20	<Hixie>	k
21:21	Hixie	breathes a sigh of relief because this was getting complicated
21:21	<hsivonen>	Hixie: the concept of "a script that will execute as soon as the parser resumes" could be more clearly named so that the reader wouldn't try to see if an inline script can be it
21:21	<Hixie>	any suggestions for a better name?
21:22	<Hixie>	an external script, maybe?
21:22	<hsivonen>	not before I have figured out what exactly it is
21:22	<gsnedders>	http://pastebin.com/m7524f744 — that's the rather bogus TOC I'm getting
21:22	<jgraham_>	gsnedders: http://lists.w3.org/Archives/Public/public-html/2008Mar/0032.html
21:22	<hsivonen>	if it always an external script, then, yes, "external script" would be good
21:22	<gsnedders>	Hixie: Fix that!
21:22	<hsivonen>	no I have to learn why their execution has different steps :-/
21:22	gsnedders	runs and hides
21:23	gsnedders	implements jgraham_'s prose
21:23	<Hixie>	hsivonen: external scripts have to be downloaded
21:23	<hsivonen>	Hixie: did my email "Re-entrant invocation of the tree builder" make sense?
21:23	<Hixie>	when did you send it?
21:23	<hsivonen>	public-html
21:24	zcorpan_	wonders if public-html is a moment in time
21:24	<Hixie>	oh just now
21:24	<hsivonen>	oops. I misread when as where
21:25	<hsivonen>	45 minutes ago
21:26	Hixie	works out why his backup wasn't working
21:27	<Hixie>	it was trying to back up three machines
21:27	<Hixie>	the first one is one that i turned off in february
21:27	<Hixie>	so my makefile was failing
21:27	<Hixie>	oops
21:28	<jgraham_>	gsnedders: You can always vote in favour of the issue :)
21:28	<gsnedders>	jgraham_: Coward! Just bully Hixie!
21:28	<hsivonen>	a <script src> load stops the world until loaded, right?
21:29	<Hixie>	gsnedders: (will get to your issue momentarily)
21:29	<Hixie>	hsivonen: not if it's nested deeply enough, iirc
21:31	gsnedders	realises he has no way to get at the parent of a section
21:32	<hsivonen>	Hixie: I guess I should convert othermaciej's example to use external scripts and see how the scripts run
21:32	<hsivonen>	having them run differently than in the inline case seems counter-intuitive
21:33	<gsnedders>	jgraham_: self[::-1] — what do two colons do?
21:33	<Hixie>	hsivonen: oh, no, wait
21:33	<Hixie>	hsivonen: the problem is this
21:33	<Hixie>	hsivonen: it's a script the document.write()s multiple things in a row
21:33	<Hixie>	hsivonen: one of which is external
21:33	<Hixie>	hsivonen: it doesn't block script execution iirc
21:33	<Hixie>	hsivonen: only the parser
21:34	<hsivonen>	like document.write("<script src=foo><\/script><script src=bar><\/script>")
21:34	<hsivonen>	?
21:35	<Philip`>	gsnedders: things[x:y:z] means things[x], things[x+z], things[x+2z], ... up to things[x+nz] where n is the maximum number such that x+n*z < y, or something like that
21:35	<Philip`>	gsnedders: and if x is omitted it means 0, and if y is omitted it means len(things)
21:36	<Philip`>	gsnedders: oh but my explanation breaks down a bit
21:36	<Hixie>	hsivonen: more like document.write("<script src=alert2><\/script>");alert(1);
21:36	<Philip`>	gsnedders: but if you ignore all the details, then that means self[::-1] is just reversed(self)
21:36	<hsivonen>	Hixie: that seems counter-intuitive
21:36	<Philip`>	gsnedders: (but compatible with older Pythons that don't have 'reversed')
21:37	<gsnedders>	Philip`: ah
21:37	<Hixie>	hsivonen: specifically, <script>document.write("<script src=alert2><\/script>");document.write("this won't be tokenised until after the alert1 and alert2");alert(1);</script>
21:37	<Hixie>	hsivonen: see the /topic
21:37	<hsivonen>	Hixie: thanks. I need to study this in detail.
21:39	<Hixie>	when you test this beware of hitting the cache; in some browsers that changes the behaviour
21:39	<Hixie>	html5 goes out of its way not to be cache-sensitive here
21:39	<hsivonen>	fun!
21:41	<jgraham_>	gsnedders: What Philip` said. http://www.python.org/doc/2.3.5/whatsnew/section-slices.html
21:41	<Hixie>	hsivonen: specifically in the spec this is implemented by having the "pause until the script has completed loading" be only ever executed in the very outer tree construction invokcation
21:41	<Hixie>	invocation
21:47	<hsivonen>	Hixie: so regarding my email, I could substitute checking if the tree builder is invoked recursively with checking if there's a document.write on the call stack?
21:49	<Hixie>	i believe that is currently equivalent, yes
21:49	<Hixie>	be wary of changes that violate that assumption, in case we ever add other ways to be reentrant
21:49	<hsivonen>	Hixie: thanks
21:50	<hsivonen>	Hixie: it seems that it's necessary to keep track of document.write nesting level anyway: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/document/src/nsHTMLDocument.cpp&rev=3.785&mark=2417-2420#2413
21:53	<Hixie>	hsivonen: there are other ways to implement that restriction
21:53	<Hixie>	replid to your mail btw
21:54	<Hixie>	replied
21:54	<hsivonen>	Hixie: restricting recursion depth?
21:54	<hsivonen>	Hixie: thanks
21:55	<Hixie>	well what you really want to make sure is that a document.write() doesn't write a script that does another document.write(), but there's no guarantee that the second will be run while the first is on the call stack
21:55	<Hixie>	(or rather, you want to block that but only when it's in an infinite loop)
21:56	<Hixie>	another way is just to limit how much cpu/ram a script can use
21:56	<gsnedders>	Infinite loops are _awesome_!
21:57	<gsnedders>	I mean, how else are you going to use a modern CPU?
21:57	<hsivonen>	Hixie: I'll have to ponder your point about appending to a buffer on stack tomorrow
21:57	<hsivonen>	it's past my bed time
21:57	<Hixie>	nn
21:58	<hsivonen>	nn.
21:58	<Hixie>	and thanks for implementing this
21:58	<Hixie>	it's good to have someone look at it this closely
22:14	<zcorpan_>	Hixie: the spec annotation system gives 500 when trying to log in
22:15	<Hixie>	yeah
22:15	<Hixie>	i need to reboot the server
22:15	zcorpan_	was going to add a pointer to http://simon.html5.org/test/html/dom/interfaces/HTMLElement/HTMLMediaElement/ somewhere
22:15	<Hixie>	for some reason dreamhost have apache set to spawn more processes than the server can handle, and it doesn't reap them
22:15	<Hixie>	so we run out of ram
22:15	<zcorpan_>	buy more ram :)
22:16	<Hixie>	send me money :-)
22:16	<zcorpan_>	doh :(
22:16	<zcorpan_>	you should be happy i'm writing tests! :-p
22:17	<zcorpan_>	though the ones i've got so far are pretty boring
22:18	<Hixie>	:-)
22:18	<Hixie>	try now
22:19	<zcorpan_>	still 500
22:19	<Hixie>	sigh
22:20	<Hixie>	try now
22:20	<zcorpan_>	still
22:20	<zcorpan_>	i'll try tomorrow
22:20	<zcorpan_>	bedtime
22:20	<Hixie>	nn
22:21	<zcorpan_>	nn
22:23	<Lachy>	Hixie, how much does dreamhost charge for your private server?
22:24	<Hixie>	$1 per 10 MHz CPU and 10MB RAM per month
22:24	<Lachy>	and how much do you pay for?
22:25	<Hixie>	varies based on load
22:25	<Lachy>	ok
22:25	<Hixie>	right now (high load on acid3 for no apparent reason) i'm using just under 1.5GB RAM
22:27	<Philip`>	The release of Firefox 3 seems like an apparent reason for people to try Acid3
22:28	<Lachy>	it only scores 51
22:28	<Hixie>	yeah that was my reasoning too, but the referrers were all over hte place
22:28	<roc>	Lachy: no way, it should be over 70
22:28	<Lachy>	oh, 71. It just paused at 51 for some reasonj
22:28	<Philip`>	You ought to just cache the results based on UA string - there's no point having a hundred million people run the same test with an identical browser, and it's an awful waste of energy
22:28	<Hixie>	heh
22:29	<othermaciej>	there's some networking in the middle of the test
22:29	<Hixie>	yeah run it twice to get real results, otherwise your network will have too much effect on the test
22:30	Lachy	just runs his localhost copy of the test so it doesn't suffer from network issues
22:30	<othermaciej>	I told people to try the Safari 4 Developer Preview on Acid3 at WWDC, but I doubt that generated a whole lot of traffic
22:30	<Hixie>	ok yeah running the logs through just checking the UA string instead of the referrer does indeed indicate that it's all ff3 users
22:30	<Hixie>	mostly on xp
22:30	Philip`	just looks on Wikipedia to get the Acid3 results
22:30	<Hixie>	some opera 9.5 users too
22:31	<Lachy>	othermaciej, how recent is Safari 4 compared to the latest nightly WebKit?
22:31	<gsnedders>	Hixie: Can you deal with <http://lists.w3.org/Archives/Public/public-html/2008Mar/0032.html>; over night?
22:31	<othermaciej>	Lachy: it's an older WebKit, but a newer Safari (although you can run a nightly with S4DP installed)
22:32	<Lachy>	is Safari 4 only available to people with ADC accounts?
22:32	<othermaciej>	the preview is up on ADC, which you need an account to access, but getting an ADC account is free
22:33	<Lachy>	ok, I have a free account.
22:33	<Hixie>	gsnedders: ok
22:34	<othermaciej>	Lachy: you should be able to get it then (though I am not sure how to find the download, probably the search feature will find it)
22:35	<Lachy>	yeah, found it.
22:35	<Lachy>	when you log in, there's a link that says downloads and it's the 3rd listed under What's New
22:35	<othermaciej>	cool
22:36	<Lachy>	does it have any cool new UI features that weren't in Safari 3?
22:37	<smedero>	Lachy: It handles what Fluid does nicely http://fluidapp.com/ (creating dedicated "apps" for websites)
22:39	<Lachy>	ok. Why do I have to restart after installing Safari? It's like a Windows installer! :-(
22:39	<Lachy>	brb
22:44	<othermaciej>	Lachy: you can actually force quit the installer when it tells you to reboot, as long as you quit all WebKit apps
22:44	<othermaciej>	Lachy: if you are willing to live on the edge a little
22:45	<Lachy>	ah, too late. I already restarted.
22:45	<othermaciej>	anyway, it has "Save as Web Application" which among other things supports HTML5 <link rel="icon" sizes=...> and <meta name="application-name" ...>
22:45	<Lachy>	oh, nice.
22:46	<Hixie>	the installer should probably list the applications you have to close instead of just rebooting :-)
22:46	<othermaciej>	http://webkit.org/blog has the right markup
22:46	<othermaciej>	if you wanna test it out
22:46	<Lachy>	better yet, the installer should just tell me which applications it wants to close, ask if it's ok and do it automatically
22:47	<othermaciej>	(but it will genreate a name and icon if needed)
22:47	<othermaciej>	sadly I am not an installer engineer, but I see you rpoint
22:51	<Lachy>	othermaciej, http://webkit.org/images/surfin-safari.icns is served as text/plain.
22:51	<othermaciej>	Lachy: I guess I should figure out how to reconfigure the server
22:51	<Lachy>	and although Firefox sniffed it as binary, Safari didn't and displayed a lot of jibberish.
22:52	<Lachy>	if it's Apache, then .htaccess: AddType image/whatever-it-is .icns
22:56	<Hixie>	that it works in safari4 when using the save as app feature is a bug in safari4 according to the spec :-)
22:56	<Hixie>	(spec doesn't allow sniffing of types for <link> at the moment)
23:00	<othermaciej>	Is it common for favicons to be sent with the wrong MIME type?
23:00	<Lachy>	hey, with Web Applications like that, adding support for the new <menu> features in HTML5 would be cool, since the app could add its own menus to the system's menu bar.
23:00	<othermaciej>	(though I guess we could at least avoid poisoning the new thing)
23:00	<Hixie>	othermaciej: i expect so
23:01	<Hixie>	othermaciej: i expect to change the spec at some point and allow sniffing, frankly
23:02	<othermaciej>	yes, a way to add to app menus would be cool , though I don't think HTML5 <menu> is sufficient for that as currently spec'd
23:02	<othermaciej>	we're looking at what kinds of things developers want to add
23:02	<othermaciej>	back in a few, getting coffee
23:02	<Lachy>	othermaciej, I don't think the default apache inlcudes the correct MIME type for .ico files, so probably quite a lot are sent as text/plain.
23:02	<Hixie>	you'd need a new type on the menu element
23:04	<Lachy>	I thought that's what the type="toolbar" was for
23:04	<Lachy>	have I remembered incorrectly?
23:04	<Hixie>	that's inline
23:05	<Lachy>	oh, ok.
23:05	<Lachy>	well, do we want to add a new type for it then?
23:07	<Hixie>	what would it do when the page isn't installed?
23:07	<Lachy>	dunno.
23:07	<Lachy>	probably nothing. It could be reserved for when it is installed as a web app.
23:08	<Hixie>	that would be bad
23:08	<Lachy>	or fallback to type=toolbar
23:08	<Hixie>	that would make people use it as toolbar and then installing pages would break their rendering
23:08	<gsnedders>	Hixie: (and by overnight, I mean anytime by 20080618T154500+01)
23:08	<Lachy>	hmm, then I don't know. This is obviously not a well thought out idea.
23:09	<gsnedders>	(which is a bit longer than overnight)
23:09	<Hixie>	gsnedders: am having mail problems right now but it's next on my list :-)
23:09	<Philip`>	Out of 99 favicons, I see 53 image/x-icon, 20 text/html, 15 text/plain, 4 image/vnd.microsoft.icon, 4 image/gif, 3 image/png
23:09	<Hixie>	Lachy: it's something i spent a lot of time thinking about when speccing <menu> :-)
23:09	<Hixie>	Philip`: send mail asking for me to make sniffing allowed :-)
23:09	gsnedders	sniffles
23:09	<Philip`>	(That's counting 404 pages, which is probably exaggerated by there being a few months between getting the list of icons and checking the content-types)
23:10	<Lachy>	right, so this probably was discsussed back then, and that's probably why I thought toolbar worked like that!
23:10	<Hixie>	Lachy: :-)
23:10	<Philip`>	(Oh, not that many - 81 were 200, 13 were 404)
23:11	<gsnedders>	othermaciej: Speaking of Saf4, does it support @rel='feed'?
23:12	<Lachy>	Maybe when it's not installed as a webapp, the browser could add some UI to indicate that there's a menu available and allow the user to switch into webapp mode for that site, which would then replace the menu bar.
23:13	<Lachy>	though I have no idea what kind of UI would be appropriate for that.
23:13	<smedero>	What other site-specific browsers are there? Prism (web-runner). Fluid. Safari 4. (there's also several kiosk-mode like browser plugins, hacks, and modified versions.)
23:14	<othermaciej>	gsnedders: for feed autodiscovery? I assume so
23:14	<othermaciej>	though probably not w/ the HTML5 algorithm for such
23:14	<gsnedders>	othermaciej: @rel='feed' _is_ the HTML 5 way
23:16	<gsnedders>	othermaciej: it seems not
23:16	<Lachy>	I think Firefox 3 supports rel=feed.
23:17	<gsnedders>	Lachy: Yeah, it does
23:25	<smedero>	confusing webpge... but I guess Hana (http://alloutsoftware.com/hana/) is another WebKit based site-specific browser tool
23:25	<smedero>	There's also an my.opera blog entry on how to do something similar to Prism with Opera: http://my.opera.com/zomg/blog/2007/10/29/mozilla-prism-a-fancy-name-for-a-technology-as-old-as-the-browser
23:28	<roc>	that blog entry is a bit confused
23:28	<smedero>	agreed.
23:29	<Lachy>	indeed. Although we can make Opera behave in a similar way, the steps for setting it up is way too complicated.
23:29	<smedero>	Just finished reading through it... it only grazes the point of Prism.
23:29	<smedero>	but still, was just curious as to what other implementations were out in the wild....
23:30	smedero	goes back to his cave
23:36	<othermaciej>	gsnedders: what's the pre-HTML5 way?
23:36	<gsnedders>	othermaciej: link[@alt='alternate'][@rel='application/atom+xml'], link[@alt='alternate'][@rel='application/rss+xml']
23:37	<Hixie>	(that's also supported in html5, iirc)
23:37	<gsnedders>	(yes, it is)
23:37	<gsnedders>	(but link[@alt='feed'] is preferred IIRC)
23:37	<othermaciej>	gsnedders: ok, I'll make sure we put rel="feed" on the roadmap
23:38	<gsnedders>	othermaciej: thx
23:39	<Hixie>	gsnedders: fixed the spec
23:39	<gsnedders>	Hixie: I'll fix the implementation when I get back from school, having gone to bed and got back up before hand
23:40	<Hixie>	hehe
23:40	<Hixie>	it's a very simply fix
23:40	gsnedders	makes the naïve mistake of looking
23:42	<Hixie>	probably a one line fix in your code
23:42	<gsnedders>	yeah
23:42	<gsnedders>	No, the comment that quotes the spec text too :)
23:42	<Hixie>	heh
23:44	<gsnedders>	Hixie: That still looks badly wrong
23:44	<Hixie>	oh?
23:44	<Hixie>	does it fix jgraham__'s example, at least?
23:44	<gsnedders>	http://pastebin.com/m7a8c10a9
23:44	<gsnedders>	Hixie: yeah, it does
23:45	<gsnedders>	That's the TOC of the HTML5 spec according to the outline algorithm
23:45	<gsnedders>	Which is obviously rather broken
23:45	<Hixie>	yeah
23:46	<Hixie>	looks like it's breaking on <body><h1><h2><h3><h3>
23:46	<Hixie>	treating it as <body><h1><h2><h3><h1> or something
23:46	<Hixie>	i can't see why that would happen, i expect you have a bug :-)
23:46	<gsnedders>	Hixie: I've looked over it endlessly :)
23:47	<Hixie>	is the source online?
23:47	<gsnedders>	It'd be easier to check if there were more impls of the spec (as jgraham__'s moves away from it)
23:47	<gsnedders>	http://pastebin.com/m2141a4ca — that's the latest copy
23:50	<Hixie>	uh
23:50	<Hixie>	line 136
23:50	<Hixie>	shouldbn't the > be < ?
23:50	<gsnedders>	No, my impl. is just odd :)
23:50	<gsnedders>	See line 31
23:51	<gsnedders>	I need to make that more logical, though
23:51	jgraham__	notes that his outline algorithm only diverges from the spec in the exact way specified in the email he sent
23:52	<Hixie>	i changed the spec in a way different than what you suggested
23:53	<Hixie>	gsnedders: i'd need to step through your code with a debugger to really figure out what's going on
23:53	<jgraham__>	I seem to recall thinking for a bit about the changes that were needed to make it work as expected, so if it turns out it works in all cases using a much simpler algorithm, it means that I'm even stupider than I previously thought :)
23:53	<Hixie>	gsnedders: i recommend finding the smallest source markup you can and then walking through the code with it
23:53	<Hixie>	gsnedders: and seeing why it backs out so far
23:53	<jgraham__>	s/as expected/as I expected/
23:54	gsnedders	tries hacking jgraham__'s impl to match the spec
23:54	<gsnedders>	Yeah, it must be an impl bug
23:54	<Hixie>	jgraham__: i just checked in the change in reply to your e-mail, if you want to compare
23:55	<gsnedders>	Heh. Slight understatement of the difference in complexity :)
23:58	<jgraham__>	Hmm I should go to sleep at the moment. gsnedders: I'll be interested to see what happens if you implement the new spec in my code
23:58	Philip`	wonders why Yahoo Slurp seemingly follows links in <a src="...">, as well as <a href> and <embed src> and <object data> and none of the other elements/attributes he's tested
23:59	Philip`	also wonders why Googlebot seemingly follows <a href> and <embed src> and nothing else, since he expects it to be far more aggressive than that