Options:
- # Session Start: Wed Mar 25 00:00:00 2009
- # Session Ident: #whatwg
- # [00:00] * Quits: annodomini (n=lambda@wikipedia/lambda)
- # [00:04] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
- # [00:05] * heycam wonders why he was CCed on the "localStorage and IE8" thread
- # [00:07] * gsnedders asks "Why not?"
- # [00:08] <heycam> i really need to sort out my .procmailrc so that multiple copies of the same mail get put in different maildirs for the appropriate mailing lists
- # [00:08] <heycam> on that mail, all three copies (via public-html, via public-webapps, and the CCed one) just get dumped in my public-html maildir :/
- # [00:09] <shepazu> Hixie: I'm not gainsaying what SVG Tiny 1.2 says, but note that that is much more specific than SVG 1.1, and the SVG WG might be willing to adopt a different script processing model for SVG-in-text/html and SVG 2.0 than in SVG Tiny 1.2
- # [00:11] <shepazu> the goal for script processing in SVGT1.2 was to make it simpler and clearer, and I believe Opera had quite a lot of input there
- # [00:11] <heycam> and also to do effectively the same thing as html
- # [00:11] <shepazu> but if that causes problems for SVG-in-text/html, please feel free to make a proposal, and we will review it
- # [00:11] <heycam> if something's wrong there, i think we'd be pretty open to making an erratum for it
- # [00:12] <shepazu> yeah, I can't speak for everyone, but I'd tend to agree
- # [00:12] <heycam> Hixie, can you explain how the script blocking in HTML differs from that in SVG?
- # [00:12] <Hixie> shepazu: i don't think it causes any problems unless we actually want to support synchronous document.write()
- # [00:13] <Hixie> heycam: you were cc'ed because you contributed to some thread on the same topic over on the whatwg list
- # [00:13] <heycam> don't even remember saying anything about localStorage :)
- # [00:13] <heycam> Hixie, so SVG's script handling is not reentrant or something?
- # [00:13] <Hixie> let's see if i can construct an example
- # [00:13] <shepazu> this might be a relatively painless change, since there is unlikely to be content that relies heavily on the script processing model, and since browsers are really getting clearer on that, it would be a big win for SVG to align here
- # [00:14] <Hixie> (i can guarantee that this won't be painless, the text/html model is unbelievably complicated and brittle)
- # [00:14] <shepazu> oh, all the better
- # [00:14] <Hixie> imagine you have the following document:
- # [00:15] <Hixie> <html><script>A</script></html>
- # [00:15] <Hixie> and imagine the script A does the following:
- # [00:15] <Hixie> 1. document.write an external <script src="1"></script> block followed by an inline <script>2</script> block
- # [00:15] <Hixie> 2. document.append()s an inline <script>3</script> block
- # [00:16] <Hixie> the execution order will be, iirc, A, then 3, then 1, then 2
- # [00:16] <heycam> oh
- # [00:16] <Hixie> and in the DOM, the script nodes will be in the order 1, 3, 2
- # [00:16] <heycam> that is different from SVG then
- # [00:17] <shepazu> hmmm, well... at least this way, we'll be so numb with pain that we won't notice the order of processing
- # [00:17] * Quits: xcombelle (n=chatzill@AToulouse-158-1-21-252.w90-50.abo.wanadoo.fr) (Remote closed the connection)
- # [00:18] <Hixie> if we do as i propose, namely say that document.write() is not synchronous from an SVG script block, then if you replace <html> with <svg> in the text/html snippet above, the execution order would be A, 3, 1, 2
- # [00:18] <Hixie> and the DOM order will also be A, 3, 1, 2
- # [00:19] <heycam> if it's not synchronous, would it still be defined the order things get inserted/run? (a queue of them is maintained or something?)
- # [00:19] <Hixie> if you switch 1 and 2 around so that 1 is inline and 2 is external instead, then in HTML, the execution order, iirc, becomes A, 1, 3, 2 and the DOM order becomes A, 1, 2, 3
- # [00:19] <Hixie> but along my proposed model, in SVG it would still be A, 3, 1, 2 both in execution and DOM
- # [00:19] <shepazu> so, this sucks... honestly, I think the latter way is cleaner and more predictable, but paradoxically unintuitive because HTML does it the other way...
- # [00:20] <heycam> Hixie, does script processing differ in XHTML?
- # [00:20] <shepazu> then again, I don't know how much authors rely on execution order... any data?
- # [00:20] <Hixie> heycam: yeah, it's still all well-defined; you just end up parsing/executing all the document.written() stuff after the script ends
- # [00:20] <Hixie> heycam: in XHTML, document.write() throws.
- # [00:20] <heycam> awesome
- # [00:20] <heycam> :)
- # [00:20] <Hixie> yes.
- # [00:21] <shepazu> Hixie: can't you apply the same rules as you apply for SVG to XHTML?
- # [00:21] <Hixie> SVG in text/html?
- # [00:21] <shepazu> sorry, yes.
- # [00:21] <shepazu> (whichever those rules end up being)
- # [00:22] * Philip` isn't sure it's worth adding support for XHTML in text/html
- # [00:22] <Hixie> not really, because an SVG <script> block could just invoke an HTML <script> block and then we'd be back in the same world
- # [00:23] * shepazu is going to suggest a silly suggestion he will be crucified for: how about a new method, similar to .write(), that works async in all languages?
- # [00:23] <Hixie> we have that
- # [00:23] <Hixie> it's called document.appendChild()
- # [00:23] <Hixie> :-)
- # [00:23] <shepazu> oh.
- # [00:23] <shepazu> lol
- # [00:23] <shepazu> ok
- # [00:23] <heycam> given that the SVG spec only deals with SVG/XML, i wonder what the best way to define SVG script processing in text/html is -- i.e., in the SVG spec? or only in the HTML spec?
- # [00:23] <heycam> what changes would you need from the SVG spec for this?
- # [00:23] <Hixie> none
- # [00:24] <Hixie> if we want to just make document.write() async in SVG <script>
- # [00:24] <heycam> ok a secondary question then: does script processing in SVG/XML different from script processing in XHTML?
- # [00:24] <heycam> (my guess is yes?)
- # [00:24] <Hixie> if we want to make SVG use the same crazy-ass stuff HTML does, which we presumably would one if we ever want to support async="" or defer="" in SVG, then, uh, a lot. i dunno. see the <script> element definition in HTML5.
- # [00:24] <shepazu> sorry to stray here, but what about .innnerHTML()?
- # [00:25] <Hixie> innerHTML conveniently disables script execution.
- # [00:25] <shepazu> Hixie: we've already planned to add @async and @defer
- # [00:25] <Hixie> heycam: yes, though not in any particularly painful way other than SVG requiring sync I/O on the UI thread
- # [00:25] <Hixie> shepazu: oh.
- # [00:25] <Hixie> well that ought to be fun.
- # [00:25] * Quits: dimich (n=dimich@72.14.227.1)
- # [00:26] <heycam> Hixie, could you explain why sync I/O on the UI thread follows from the current script processing definitions in SVG?
- # [00:26] <Hixie> shepazu: in that case we really should just have svg and html use the same mechanism with the event loop and everything
- # [00:26] <shepazu> just so authors are dealing with the same platform
- # [00:26] <heycam> what i would like is for scripts in SVG/XML to act the same as those in XHTML
- # [00:27] <shepazu> I think it would be useful to summarize this in an email, if you don't mind...
- # [00:27] <Hixie> heycam: well, parsing and script execution block, and parsing happens as part of processing a task on the event loop.
- # [00:27] * Quits: aroben (n=aroben@unaffiliated/aroben) ("Leaving")
- # [00:27] <heycam> perhaps then it is just a matter of poor wording on my part then in that script processing section
- # [00:28] <Hixie> shepazu: summarise what?
- # [00:28] <heycam> it should just block the parser, no?
- # [00:28] <Hixie> heycam: the parser is on the ui thread (well, on the event loop)
- # [00:28] <Hixie> heycam: put it this way:
- # [00:29] <Hixie> heycam: what happens if an external SVG <script> is inserted, does the appendChild() call return before or after the script runs?
- # [00:30] <heycam> by the current text, i think it is after
- # [00:30] <Hixie> oh. that's different than html.
- # [00:30] <heycam> ok
- # [00:30] <Hixie> so if i appendChild() two <Script> blocks back to back
- # [00:30] <Hixie> the second will be inserted before the first executes?
- # [00:30] <Hixie> when will it execute?
- # [00:30] <Hixie> i don't understand the model anymore. :-/
- # [00:31] * Joins: annodomini (n=lambda@wikipedia/lambda)
- # [00:32] * heycam brb
- # [00:34] * Quits: dglazkov (n=dglazkov@nat/google/x-7806233b6d1c0733)
- # [00:35] * Quits: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au) (Remote closed the connection)
- # [00:49] <heycam> i think my intention was for the first to be inserted, then executed, then the second is inserted, then executed
- # [00:50] <heycam> if you want to mail www-svg with suggestions on making it saner / more compatible with XHTML, that'd be appreciated
- # [00:51] <Hixie> i don't really know what to suggest, short of just referencing html5's processing model and defining everything either in terms of tasks and event loops or the scripting lists
- # [00:51] <heycam> :)
- # [00:51] <Hixie> but i don't see much point in saying that in e-mail
- # [00:52] <heycam> maybe i need to take a closer read of the html5 model
- # [00:52] <Hixie> ("hi please depend on my spec that i've said isn't going to be ready for a decade k thx bye" isn't likely to go down well)
- # [00:52] <heycam> ha
- # [00:52] <heycam> anyway, for the svg script in text/html case, i think you can just do whatever is sensible
- # [00:53] <Hixie> (to be honest though i think long term we probably will have to use a common event loops model)
- # [00:53] <heycam> sounds sensible
- # [00:54] <heycam> that'd be one of those things that would go into a split out "Web platform" spec (with things like Window, etc.)
- # [00:54] <annevk3> If I define XMLHttpRequest in terms of event loops SVG would need to be defined in it too for it to work "right"... In theory anyway.
- # [00:54] <Hixie> heycam: yeah... let me know when you find someone to do that! :-)
- # [00:54] <heycam> :)
- # [00:55] <Hixie> i know it wouldn't be a popular suggestion but i'm somewhat of the opinion that at this point html and the core dom stuff are so tightly bound together that we should just keep them in one spec and have everything depend on html
- # [00:55] <Hixie> but i know that would offend the purists
- # [00:55] <heycam> indeed i think it wouldn't be a popular suggestion :)
- # [00:56] <Hixie> so right now the web sockets, web storage, web workers, html5, and event source specs are all generated from one source document
- # [00:57] <heycam> those other things seem much more easily separable than "web platform" stuff though
- # [00:57] <Hixie> yes, absolutely
- # [00:57] <heycam> at least from a single-source-document-generating-them PoV
- # [00:57] <Hixie> if it wasn't for hte obvious process issues with it, and the difficulty of coordinating work, it would be interesting to consider putting svg, dom core and dom events, http, and pretty much everything else into that same document
- # [00:58] <heycam> it might make certain things easier (cross references e.g.)
- # [00:58] <Hixie> i'm considering hosting a spec on the whatwg site that is web sockets, web storage, web workers, html5, and event source in one doc
- # [00:58] <Hixie> heycam: yeah, exactly
- # [00:58] <Hixie> anyway realistically this has zero chance of happening
- # [00:58] <annevk3> it's also an awful lot of work
- # [00:59] <Hixie> yeah
- # [00:59] <Hixie> thing is
- # [00:59] <Hixie> we already have to do that work
- # [00:59] <Hixie> zcorpan is rewriting dom core
- # [00:59] <annevk3> i.e. I can't even begin to imagine rewriting CSS the HTML5 way though I think it should be done :)
- # [00:59] <Hixie> dom events is probably going to need a rewrite at some point
- # [00:59] <Hixie> css needs a rewrite now that 2.1 has nailed down the behavior, so that it actually is defined in a sane way
- # [01:00] * Quits: wakaba_ (n=wakaba@87.162.210.220.dy.bbexcite.jp) ("Leaving...")
- # [01:00] <heycam> dom 3 events is being worked on at the moment. maybe you can comment on it?
- # [01:00] <Hixie> range and traversal desperately need rewrites
- # [01:00] <Hixie> svg is pretty vague, as noted by the questions we just had about <script> behavior
- # [01:00] <Hixie> etc
- # [01:00] <annevk3> and everyone is inventing new features on top of the undefined stuff
- # [01:00] <annevk3> yay
- # [01:01] * fakeolliej is now known as olliej
- # [01:02] <Hixie> heycam: my comments on dom3 events would be along the same lines as my comments on svg
- # [01:02] <Hixie> heycam: and thus likely just as unpopular
- # [01:02] <annevk3> and in ten years we'll prolly discuss mistakes similar to cross-origin <script>, global object mess, etc.
- # [01:02] <heycam> "whine whine this isn't defined well enough blah blah" :)
- # [01:02] <annevk3> "and please drop the namespace crap"
- # [01:03] <Hixie> heycam: (i'd recommend splitting out the events into a separate doc that actually defines when they fire, i'd recommend rewriting all the dom api definitions to actually be phrased as requirements not descriptions, and i'd suggest making everything be defined in terms of the event loop mechanism)
- # [01:04] <heycam> shepazu, ↑
- # [01:04] <Hixie> heh
- # [01:04] <Hixie> i'm sure i've discussed this with him before :-)
- # [01:04] <heycam> ok
- # [01:04] <Hixie> i had similar comments on the progress spec with chaals
- # [01:05] <Hixie> e.g. the dom apis are vague, the spec has far too many redundant or untestable requirements, the spec shouldn't have conforming requirements defined for author scripts, and there are no or few hooks defined for specs using the technology
- # [01:05] <Hixie> chaals disagrees :-)
- # [01:05] <Hixie> and who's to say he's not right and i'm not wrong
- # [01:06] <annevk3> I'd say he's wrong, but I'm biased
- # [01:07] <heycam> biased against him because he's your boss? :)
- # [01:07] <Hixie> i'd say if you had a bias you'd be biased in his favour but ok :-)
- # [01:08] <atw> MessagePorts are supposed to implement EventTarget - does that mean that if I register an onmessage listener on a port, that my onmessage listener can get a reference to the port via the event.target attribute? Or is that only for DOM events?
- # [01:08] <Hixie> yes, it does mean that
- # [01:08] <annevk3> well yeah, I'm biased both ways, but chaals appreciates honesty
- # [01:08] <Hixie> annevk3: feel free to support me on the list then :-P
- # [01:09] <annevk3> Hixie, since when are we doing +1 emails? :p
- # [01:09] <Hixie> :-P
- # [01:09] <atw> That implies that we can't GC message ports if there are any messages in-flight even if there are no references to either endpoint's message port, since the messages themselves contain an inherent reference to the port. I could ping-pong messages back and forth between two ports using only listeners, with no active references to the ports.
- # [01:10] <Hixie> atw: correct, the spec even explicitly says that iirc
- # [01:11] <atw> Not so - the spec says: "Thus, a message port can be received, given an event listener, and then forgotten, and so long as that event listener could receive a message, the channel will be maintained.
- # [01:11] <atw> Of course, if this was to occur on both sides of the channel, then both ports would be garbage collected, since they would not be reachable from live code, despite having a strong reference to each other."
- # [01:11] <atw> Ah, but.
- # [01:11] <atw> The next line :)
- # [01:12] <atw> It does say that you can't GC a port while there's a message in flight, and the previous paragraph implies that this would keep the entangled port from being GC'd. OK, thnx.
- # [01:12] <atw> I for some reason couldn't hold those two facts in my brain at once.
- # [01:12] <Hixie> i can make it clearer if you want
- # [01:12] <Hixie> drop me a mail?
- # [01:12] <Hixie> i'm in the middle of the svg edits right now
- # [01:12] <Hixie> so can't make changes
- # [01:12] <atw> Sure, but in retrospect I think it's plenty clear. Thx.
- # [01:13] * Joins: bgalbraith (n=bgalbrai@corp-241.mountainview.mozilla.com)
- # [01:15] * Parts: ojan (n=ojan@72.14.229.81)
- # [01:16] * Quits: MikeSmith (n=MikeSmit@EM114-48-133-202.pool.e-mobile.ne.jp) (Read error: 104 (Connection reset by peer))
- # [01:29] * Quits: olliej (n=oliver@nat/apple/x-211fdd897d34a195)
- # [01:30] <annevk3> Hixie, SVG is going to be commented "in"?
- # [01:30] <annevk3> (I guess the quotemarks should have been around commented....)
- # [01:31] * annevk3 clearly needs to go to sleep; night all!
- # [01:31] * Joins: olliej (n=oliver@nat/apple/x-9fa25b7c394cb0e7)
- # [01:35] * Quits: bgalbraith (n=bgalbrai@corp-241.mountainview.mozilla.com)
- # [01:42] * Parts: olliej (n=oliver@nat/apple/x-9fa25b7c394cb0e7)
- # [01:42] * Quits: tantek__ (n=tantek@c-67-160-236-52.hsd1.ca.comcast.net)
- # [01:46] * Joins: olliej (n=oliver@nat/apple/x-78722e6bd9d2d6d7)
- # [01:50] * Quits: olliej (n=oliver@nat/apple/x-78722e6bd9d2d6d7) (Client Quit)
- # [01:51] <Lachy> Hixie, personally, I think supporting <![CDATA[]]> sections in SVG scripts, but not in HTML scripts is silly. I would prefer that we just made <script> parse as CDATA for both HTML and SVG, as that makes it easier for authors
- # [01:51] <Lachy> well, at least, it makes it more consistent
- # [01:51] <Hixie> we can't do that while satisfying the svgwg's goal
- # [01:51] <Lachy> I don't agree with the SVG WG's goal
- # [01:52] <Hixie> neither do i, but we can't just throw out people's requirements willy nilly just because we don't like them
- # [01:52] <Lachy> I think making SVG as XML entirely compatible with text/html, including XML's syntactic sugar, is a non-goal
- # [01:52] <Lachy> er, I don't think I said that quite right. But you should get what I mean
- # [01:52] * Joins: olliej (n=oliver@nat/apple/x-29175c3d6ffb901d)
- # [01:53] <Hixie> their goal is to be able to take svg documents created by xml serialisers and paste them into text/html docs
- # [01:53] <Lachy> yeah. I don't agree with that
- # [01:53] <Hixie> you think we should prevent it, or you think it's not important?
- # [01:53] <Hixie> i.e. do you think it's an anti-goal, or a non-goal?
- # [01:53] <Lachy> I think text/html SVG and XML SVG should be just as compatible as HTML and XHTML
- # [01:54] * Joins: MikeSmith (n=MikeSmit@EM114-48-191-34.pool.e-mobile.ne.jp)
- # [01:54] <Hixie> that's a fine goal too, but it conflicts with their goal
- # [01:54] <Lachy> I know. i don't care about their goal
- # [01:55] <Hixie> they do
- # [01:55] <Lachy> I care about making the authoring requirements consistent for authors
- # [01:56] <Hixie> they care about being able to paste svg images into text/html
- # [01:57] <Hixie> wtf, windows is actually forcing me to reboot with a 30 minute countdown
- # [01:58] <Lachy> sure. But I don't think it's necessary to be able to do that with SVG designed for XML processing to be copy and pasteable entirely without modification. I think requiring authors to strip (or comment out) unsupported XML syntactic sugar like CDATA sections
- # [01:58] <Hixie> and they disagree
- # [01:58] <Lachy> so the same way authors do <script>/*<![CDATA[ */ ... /* ]]> */</script> for XHTML as text/html, so should they for SVG as text/html
- # [01:58] <Hixie> this is why opinion-based arguments don't work. there's no way to win them.
- # [01:59] <Lachy> mine isn't opinion based. It's based on making rules consistent for authors
- # [01:59] <Lachy> so hand coding is easier
- # [02:01] <shepazu> what about sicking's suggestion for script/css CDATA parsing?
- # [02:01] <Hixie> and theirs isn't opinion based, it's based on making authoring easier for authors
- # [02:01] <Hixie> so hand coding is easier
- # [02:01] <Hixie> (they're both opinions)
- # [02:01] <Hixie> shepazu: that breaks your goal
- # [02:02] <shepazu> hmmm... how so?
- # [02:02] <heycam> the opinion part of it is which is more important: hand authoring, or paste authoring from existing SVG authoring tools
- # [02:02] <shepazu> sorry if I'm being dense, but it seemed to solve the issue...
- # [02:02] * Quits: weinig (n=weinig@17.246.16.246)
- # [02:03] <Hixie> shepazu: making text/html not use xml-like parsing means that you can't guarantee that an xml svg file will work in text/html, no?
- # [02:04] <Lachy> Hixie, the SVG WG's goals seem to be to try and maintain as much XML-like strictness as possible. I have not seen any suggestion from the SVG WG specifically designed to optimise hand coding
- # [02:04] * Quits: tndH (n=Rob@adsl-77-86-107-105.karoo.KCOM.COM) ("ChatZilla 0.9.84-rdmsoft [XULRunner 1.9.0.1/2008072406]")
- # [02:05] <Lachy> anyway, I'm not looking forward to try and explain the rules for dealing with script elements to authors now that the rules differ for HTML and SVG fragments.
- # [02:05] <shepazu> I thought sicking suggested supporting <![CDATA[]]> sections in HTML scripts and SVG scripts?
- # [02:05] * Joins: xydyx (n=hdh@118.71.77.216)
- # [02:06] <Hixie> i don't see any sane way to support <![CDATA[ ]]> in regular HTML given the crazy "magic <!-- -->" processing
- # [02:06] <shepazu> <![CDATA[]]> is not strictly necessary with SVG scripts... just when Offending Characters might be present, right?
- # [02:06] <Hixie> <![CDATA[ ]]> is never necessary in XML
- # [02:07] <Hixie> it's just a syntactic alternative to escaping characters using numeric character references ("entities")
- # [02:07] <heycam> i think it was a mistake for CDATA sections to be exposed in the DOM
- # [02:07] <shepazu> right
- # [02:08] <Lachy> shepazu, the problem is when authors using XML don't use CDATA sections and encode <, >, and & as character refs
- # [02:08] <Hixie> heycam: me too, but that's actually academic here
- # [02:08] <Lachy> when they do use them, the solution to make the script compatible with both XML and text/html is to comment out the <![CDATA[ ]]> markup. with /* */ or //
- # [02:09] <Hixie> the best thing would be to have a browser with significant market share implement a consistent mechanism (whatever that might be), and prove that it doesn't break sites and is implementable
- # [02:10] <Hixie> changing html parsing rules is a very dangerous sport
- # [02:10] <Hixie> and not one i particularly enjoy
- # [02:10] <shepazu> I thought that sicking seemed to say that you *could* do CDATA in script and style?
- # [02:10] <Hixie> sicking: can you explain to me how you would do it?
- # [02:10] <Hixie> i didn't see anything that wasn't rather handwavy
- # [02:11] <Hixie> and the parsing of CDATA blocks in text/html (not <![CDATA[ ]]> blocks) is significantly non-trivial right now
- # [02:11] <shepazu> (Hixie, did you BCC me on that email? I got 3 copies)
- # [02:11] <Hixie> yeah, i bcc'ed anyone who wrote an e-mail on the thread
- # [02:11] <shepazu> ok, thanks, mystery solved
- # [02:14] * Quits: heycam (n=cam@zot.infotech.monash.edu.au) ("bye")
- # [02:14] <Lachy> ah, that explains why I got an extra copy, even though I wasn't quoted. Though I don't remember writing anything in that thread
- # [02:21] * Quits: hdh (n=hdh@118.71.77.119) (Read error: 113 (No route to host))
- # [02:22] * Joins: heycam (n=cam@zot.infotech.monash.edu.au)
- # [02:34] * Quits: davidb (n=davidb@bas4-toronto06-1242458518.dsl.bell.ca)
- # [02:47] * Quits: jwalden (n=waldo@corp-241.mountainview.mozilla.com) (Remote closed the connection)
- # [03:08] * Joins: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
- # [03:10] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
- # [03:15] * Joins: kig (i=ilmarihe@melkki.cs.helsinki.fi)
- # [03:15] * Quits: erlehmann (n=erlehman@86.59.25.121) (Read error: 110 (Connection timed out))
- # [03:17] * Quits: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com) (Read error: 113 (No route to host))
- # [03:37] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
- # [03:41] * Quits: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
- # [03:41] * Quits: dave_levin (n=dave_lev@72.14.227.1)
- # [03:42] * Joins: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
- # [03:43] * Joins: erlehmann (n=erlehman@86.59.25.121)
- # [03:43] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
- # [03:48] <gsnedders> http://code.google.com/p/html5lib/source/list — there's far too much me there
- # [03:52] * Joins: karlcow (n=karl@nerval.la-grange.net)
- # [03:58] * Parts: erlehmann (n=erlehman@86.59.25.121)
- # [04:03] * Quits: heycam (n=cam@zot.infotech.monash.edu.au) ("bye")
- # [04:11] * Joins: Kuruma (n=Kuruman@www1664.sakura.ne.jp)
- # [04:11] * Joins: dave_levin (n=dave_lev@72.14.224.1)
- # [04:19] * Joins: heycam (n=cam@zot.infotech.monash.edu.au)
- # [04:24] * Quits: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
- # [04:26] * Joins: slightlyoff (n=slightly@67.218.105.209)
- # [04:29] * Joins: tantek (n=tantek@c-67-160-236-52.hsd1.ca.comcast.net)
- # [04:52] * Joins: hdh (n=hdh@118.71.77.216)
- # [04:53] * Quits: roc (n=roc@202.0.36.64)
- # [04:53] * Joins: roc (n=roc@202.0.36.64)
- # [04:54] * Quits: slightlyoff (n=slightly@67.218.105.209)
- # [05:10] * Quits: xydyx (n=hdh@118.71.77.216) (Success)
- # [05:15] * Quits: tantek (n=tantek@c-67-160-236-52.hsd1.ca.comcast.net)
- # [05:20] <gsnedders> Weee… from 136s (r1274) to 50s (HEAD) to tokenize the spec
- # [05:20] * Quits: hdh (n=hdh@118.71.77.216) (Remote closed the connection)
- # [05:41] * Quits: roc (n=roc@202.0.36.64)
- # [05:45] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
- # [05:50] * Joins: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au)
- # [06:06] * Quits: doublec (n=doublec@202.0.36.64) ("Leaving")
- # [06:57] * Quits: annodomini (n=lambda@wikipedia/lambda)
- # [07:05] * Quits: heycam (n=cam@zot.infotech.monash.edu.au) ("bye")
- # [07:06] * Joins: olliej_ (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
- # [07:14] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
- # [07:37] * Quits: MikeSmith (n=MikeSmit@EM114-48-191-34.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
- # [07:40] * Joins: jwalden (n=waldo@c-76-102-160-171.hsd1.ca.comcast.net)
- # [07:45] * Joins: heycam (n=cam@124-168-80-126.dyn.iinet.net.au)
- # [07:49] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
- # [07:58] * Joins: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
- # [08:04] * Parts: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
- # [08:06] * Joins: danbri (n=danbri@s55927ef8.adsl.wanadoo.nl)
- # [08:07] * Quits: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au) ("This computer has gone to sleep")
- # [08:10] * Joins: zalan (n=kvirc@80.99.193.98)
- # [08:20] * Joins: ap (n=ap@194.154.88.41)
- # [08:22] <hsivonen> lots of scrollback :-(
- # [08:32] <shepazu> here's the summary, hsivonen: SVG script is easier and more consistent than HTML script, so we will probably go with HTML's model, and Hixie rejected all the SVG WG's feedback for SVG-in-HTML
- # [08:33] <hsivonen> shepazu: thanks. I also read the logs at krijnhoetmer.nl. writing email now
- # [08:33] <shepazu> the speed with which he did so suggests a remarkably organized mind with a singular coherency of thought
- # [08:44] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
- # [08:45] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
- # [08:47] * Joins: pesla (n=retep@procurios.xs4all.nl)
- # [09:02] * Joins: itpastorn (n=itpastor@ne.keryx.se)
- # [09:14] * Quits: dave_levin (n=dave_lev@72.14.224.1)
- # [09:23] * Quits: itpastorn (n=itpastor@ne.keryx.se) (Read error: 104 (Connection reset by peer))
- # [09:24] * Joins: itpastorn (n=itpastor@ne.keryx.se)
- # [09:37] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
- # [09:37] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
- # [09:37] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
- # [09:41] * Quits: ap (n=ap@194.154.88.41)
- # [09:47] * Joins: pesla\work (n=retep@78-27-53-137.dsl.alice.nl)
- # [09:56] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("Ex-Chat")
- # [10:04] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
- # [10:05] * Quits: pesla (n=retep@procurios.xs4all.nl) (Read error: 110 (Connection timed out))
- # [10:06] * Quits: pesla\work (n=retep@78-27-53-137.dsl.alice.nl) (Read error: 110 (Connection timed out))
- # [10:30] <annevk3> http://www.w3.org/mid/1e3451610903250034g69513bdvedd39f04dc270339@mail.gmail.com o_O
- # [10:31] * Joins: doublec (n=doublec@118-93-172-205.dsl.dyn.ihug.co.nz)
- # [10:35] * Joins: mat_t (n=mattomas@nat/canonical/x-495adc23aea44c9a)
- # [10:43] * annevk3 was hoping hsivonen would run the sane script story campaign :)
- # [10:55] <Hixie> ok bed time nn
- # [10:55] * jgraham wonders what the sane script story campaign is
- # [10:55] <jgraham> gn
- # [10:55] <hsivonen> nn
- # [10:56] <annevk3> jgraham, run scripts the same way in text/html regardless of whether they are SVG or HTML <script> elements
- # [10:57] <jgraham> Ah, OK. I thought by "sane" you might mean doing something other than html behaviour
- # [10:57] <jgraham> (which would be silly but could be described as "sane")
- # [10:58] <jgraham> (as the opposite to "insane script handling required by html")
- # [10:58] <annevk3> I'm not necessarily saying that's what in the spec now is insane. I just needed to name my campaign :p
- # [10:59] <jgraham> Well I agree doing anything inconsistent is insane
- # [10:59] <jgraham> More insane than just copying whatever HTML already does
- # [10:59] <jgraham> However weird
- # [11:05] * Quits: itpastorn (n=itpastor@ne.keryx.se) ("Leaving.")
- # [11:08] * Joins: ROBOd (n=robod@89.122.216.38)
- # [11:11] * Joins: svl (n=chatzill@a194-109-2-36.dmn.xs4all.nl)
- # [11:14] * Joins: itpastorn (n=itpastor@ne.keryx.se)
- # [11:20] * Quits: olliej_ (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
- # [11:21] <jgraham> For someone who thinks that it is a wate of time to discuss rsayre is really fast to reply
- # [11:24] * Joins: MikeSmith (n=MikeSmit@EM114-48-77-51.pool.e-mobile.ne.jp)
- # [11:25] <MikeSmith> hsivonen: you around?
- # [11:28] <hsivonen> MikeSmith: yes
- # [11:28] <hsivonen> MikeSmith: I saw the scrollback. Haven't processed the Schematron part yet.
- # [11:29] <MikeSmith> hsivonen: I made a minor change just to some message strings in the Assertions.java source
- # [11:29] <MikeSmith> built and tested it with my local v.nu instance and no problems and works as expected
- # [11:30] <hsivonen> MikeSmith: great. feel free to check in
- # [11:30] <MikeSmith> OK
- # [11:30] <MikeSmith> will do
- # [11:30] <hsivonen> MikeSmith: thanks!
- # [11:31] <MikeSmith> and I'm looking at the Assertions.java source now to try go see if I can add the label@for constraints
- # [11:44] * Quits: MikeSmith (n=MikeSmit@EM114-48-77-51.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
- # [11:47] * Joins: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au)
- # [11:49] * Joins: ap (n=ap@194.154.88.41)
- # [12:01] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
- # [12:17] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
- # [12:21] * Joins: mstange (n=markus@pD9579410.dip0.t-ipconnect.de)
- # [12:27] * Joins: tndH (n=Rob@adsl-77-86-107-105.karoo.KCOM.COM)
- # [12:29] * Joins: myakura (n=myakura@122.29.116.63)
- # [12:32] * Joins: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
- # [12:36] * Parts: kig (i=ilmarihe@melkki.cs.helsinki.fi)
- # [12:41] * Joins: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
- # [13:05] * Quits: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au) ("This computer has gone to sleep")
- # [13:19] * Quits: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
- # [13:22] * Joins: aroben (n=aroben@unaffiliated/aroben)
- # [13:23] * Quits: doublec (n=doublec@118-93-172-205.dsl.dyn.ihug.co.nz) ("Leaving")
- # [13:36] * Quits: mat_t (n=mattomas@nat/canonical/x-495adc23aea44c9a) ("This computer has gone to sleep")
- # [14:29] * Joins: taf2 (n=taf2@65.210.82.235)
- # [14:31] * Parts: annevk3 (n=annevk@77.163.243.203)
- # [14:32] * Joins: davidb (n=davidb@76.64.59.165)
- # [14:32] * Joins: mpilgrim (n=mark@155.229.51.170)
- # [14:34] * Joins: mat_t (n=mattomas@nat/canonical/x-9ec96ea626317a01)
- # [14:36] * Joins: annevk3 (n=annevk@77.163.243.203)
- # [14:36] * Joins: annodomini (n=lambda@wikipedia/lambda)
- # [14:37] * Quits: annodomini (n=lambda@wikipedia/lambda) (Client Quit)
- # [14:43] * Parts: itpastorn (n=itpastor@ne.keryx.se)
- # [14:54] * Quits: mstange (n=markus@pD9579410.dip0.t-ipconnect.de) ("ChatZilla 0.9.84-2009030221 [Firefox 3.6a1pre/20090324030703]")
- # [15:04] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Remote closed the connection)
- # [15:06] * Joins: mstange (n=markus@pD9579410.dip0.t-ipconnect.de)
- # [15:07] * Quits: zalan (n=kvirc@80.99.193.98) (Read error: 110 (Connection timed out))
- # [15:07] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
- # [15:09] * Joins: zdobersek (n=zan@cpe-92-37-68-207.dynamic.amis.net)
- # [15:14] * Joins: annodomini (n=lambda@wikipedia/lambda)
- # [15:22] * Quits: mpilgrim (n=mark@155.229.51.170) (Read error: 104 (Connection reset by peer))
- # [15:50] <Lachy> it seems really strange that attempting to get the insertId attribute can potentially raise an exception. http://dev.w3.org/html5/webstorage/#dom-sqlresultset-insertid
- # [15:54] * Joins: sid0_ (n=sid0@unaffiliated/sid0)
- # [16:01] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
- # [16:03] * Joins: hdh (n=hdh@58.187.21.114)
- # [16:04] <jgraham> Should contentEditable elements be focusable?
- # [16:05] <Philip`> Hmm, my laptop's CPU fan seems to have become noisy, and the only way I can find to fix it is to run "perl -e'fork; 1 while 1'" for a minute so my CPU gets really hot and the fan goes to maximum speed, and then press the Tab or Caps lock or Q key, which makes the fan stop annoyingly whirring, and then it's fine once I let it cool down
- # [16:05] * jgraham wonders how Philip` managed to find that methodology
- # [16:06] * Philip` wonders if there's a more direct solution, that doesn't involve disassembling his laptop using screwdrivers that he doesn't have
- # [16:06] <Philip`> jgraham: It seemed a pretty obvious plan to me
- # [16:07] <jgraham> Philip`: Hit your laptop with a large hammer. Hard. It will soon stop making any annoying noise
- # [16:07] <Philip`> The whirring changed when I pressed down on the keyboard directly over the fan, so it seemed reasonable to try changing the fan speed and seeing if it spun itself back into a quiet state
- # [16:08] <Philip`> (The problem came back after I switched it off and on again, so I had an opportunity to discover the solution was repeatable)
- # [16:08] <Philip`> jgraham: Don't have a hammer
- # [16:09] <Philip`> and if I went to a store to purchase a hammer, I should purchase some screwdrivers too
- # [16:09] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Remote closed the connection)
- # [16:09] <jgraham> Philip`: A brick? A tin of beans?
- # [16:10] <Philip`> I suppose I could bash it with another laptop
- # [16:14] * Joins: zdobersek1 (n=zan@cpe-92-37-72-115.dynamic.amis.net)
- # [16:16] * Joins: dglazkov (n=dglazkov@nat/google/x-841424654c544763)
- # [16:19] * Quits: dglazkov (n=dglazkov@nat/google/x-841424654c544763) (Client Quit)
- # [16:19] * Joins: dglazkov (n=dglazkov@216.239.45.4)
- # [16:20] * Joins: zalan (n=kvirc@80.99.193.98)
- # [16:22] <svl> http://ilia.ws/archives/196-IE8-X-UA-Compatible-Rant.html :/
- # [16:29] * Quits: zdobersek (n=zan@cpe-92-37-68-207.dynamic.amis.net) (Read error: 110 (Connection timed out))
- # [16:29] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
- # [16:29] * Joins: sid0 (n=sid0@unaffiliated/sid0)
- # [16:32] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
- # [16:41] * Joins: mlpug (n=mlpug@a91-156-60-13.elisa-laajakaista.fi)
- # [16:43] * Quits: sid0_ (n=sid0@unaffiliated/sid0) (Remote closed the connection)
- # [16:54] * Joins: weinig (n=weinig@67.180.35.124)
- # [17:04] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
- # [17:04] * Joins: bgalbraith (n=bgalbrai@corp-241.mountainview.mozilla.com)
- # [17:07] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 60 (Operation timed out))
- # [17:19] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
- # [17:21] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
- # [17:25] * Quits: mstange (n=markus@pD9579410.dip0.t-ipconnect.de) ("ChatZilla 0.9.84-2009030221 [Firefox 3.6a1pre/20090325032457]")
- # [17:25] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Remote closed the connection)
- # [17:29] * Joins: sid0 (n=sid0@unaffiliated/sid0)
- # [17:32] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Client Quit)
- # [17:35] * Joins: davidb_ (n=davidb@bas4-toronto06-1279277989.dsl.bell.ca)
- # [17:35] * Quits: davidb (n=davidb@76.64.59.165) (Read error: 104 (Connection reset by peer))
- # [17:36] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
- # [17:39] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
- # [17:47] * Joins: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
- # [17:54] * Quits: myakura (n=myakura@122.29.116.63) ("Leaving...")
- # [17:56] * Joins: Maurice (n=copyman@5ED548D4.cable.ziggo.nl)
- # [18:04] * Quits: weinig (n=weinig@67.180.35.124)
- # [18:13] * Joins: smaug (n=chatzill@cs181146100.pp.htv.fi)
- # [18:17] * Quits: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
- # [18:17] * Quits: hdh (n=hdh@58.187.21.114) (Remote closed the connection)
- # [18:20] * Joins: Lachy (n=Lachlan@85.196.122.246)
- # [18:38] * Quits: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
- # [18:39] <atw> The chrome team is wondering about the behavior of window.postMessage() - since the destination window/iframe may not be loaded yet, what is the expected behavior if I post a message to a window whose contents aren't yet loaded. Should the message get dropped on the floor, or queued?
- # [18:39] <atw> Both Safari and Chrome just drop it on the floor now, which seems unideal.
- # [18:54] * Joins: dave_levin (n=dave_lev@72.14.227.1)
- # [18:56] * Joins: mstange (n=markus@pD9579410.dip0.t-ipconnect.de)
- # [19:02] * Quits: mat_t (n=mattomas@nat/canonical/x-9ec96ea626317a01) ("This computer has gone to sleep")
- # [19:04] * Quits: svl (n=chatzill@a194-109-2-36.dmn.xs4all.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
- # [19:10] <gsnedders> Philip`: How many tags have mixed case names?
- # [19:10] * Joins: dimich (n=dimich@72.14.227.1)
- # [19:11] <jwalden> atw: why is this a problem? I always understood postMessage to be for establishing communication with an already-loaded window, most particularly an iframe during the parent window's onload
- # [19:12] * Joins: weinig (n=weinig@17.246.16.246)
- # [19:14] <Philip`> gsnedders: About six
- # [19:15] <Philip`> gsnedders: I see 4580419 tags matching [a-z], 594677 [A-Z], and 5585 matching both
- # [19:15] <jwalden> atw: that's also interoperable with Gecko, fwiw; IE is too much effort for me to test right now
- # [19:16] * Quits: dave_levin (n=dave_lev@72.14.227.1)
- # [19:16] <atw> jwalden: Why would postMessage() not be useful for communicating with other windows?
- # [19:17] <gsnedders> Philip`: thx
- # [19:17] <jwalden> atw: um, please rephrase to ask what you meant to ask :-)
- # [19:17] <atw> Also, is the implication that onload on a parent window is invoked only after all iframes have been fully loaded? I have to admit I'm not 100% up on the semantics of onload.
- # [19:17] <jwalden> yes
- # [19:17] <jwalden> to the latter
- # [19:17] <gsnedders> Philip`: huh… "six" being the number of unique values?
- # [19:19] <atw> That use case makes sense to me (send messages on onload()) - I guess the intent of postMessage() is that the behavior is undefined if you are sending it to another window while that window's content is still loading?
- # [19:20] <Philip`> gsnedders: No, six being a number I made up off the top of my head, which turned out to not be a good approximation of 5585
- # [19:20] * Joins: dave_levin (n=dave_lev@72.14.227.1)
- # [19:20] <jwalden> "intent" I think is putting it a bit strongly, but I don't think it was considered a serious limitation
- # [19:20] <jwalden> atw: do consider that all the hash-and-poll hacks already required the target window to be loaded
- # [19:21] <gsnedders> Philip`: ah
- # [19:22] <jwalden> also seems to me that making early messages get queued is mostly unneeded complexity in the implementation, and sites can work around the "problem" without much trouble
- # [19:22] <jwalden> a limitation, but not pejoratively
- # [19:23] <atw> jwalden: Sure. We do that work for MessagePorts (queue messages before the port is started) so this seemed like an analogous situation, which is why the behavior surprised me.
- # [19:24] <atw> But I'm not arguing that it's unreasonable.
- # [19:25] <jwalden> messageports came along after I last really looked at postMessage, so I don't know the details of how they work
- # [19:25] * aroben is now known as aroben|meeting
- # [19:25] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
- # [19:26] * Joins: davidb (n=davidb@bas4-toronto06-1279277989.dsl.bell.ca)
- # [19:26] * Quits: davidb_ (n=davidb@bas4-toronto06-1279277989.dsl.bell.ca) (Read error: 104 (Connection reset by peer))
- # [19:36] * Quits: weinig (n=weinig@17.246.16.246)
- # [19:52] * Quits: dolske (n=dolske@firefox/developer/dolske)
- # [19:54] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
- # [19:55] * aroben|meeting is now known as aroben
- # [20:00] * Joins: weinig (n=weinig@17.246.16.246)
- # [20:03] * Quits: weinig (n=weinig@17.246.16.246) (Client Quit)
- # [20:06] * Quits: jwalden (n=waldo@c-76-102-160-171.hsd1.ca.comcast.net) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
- # [20:10] * Joins: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
- # [20:14] * Quits: mstange (n=markus@pD9579410.dip0.t-ipconnect.de) ("ChatZilla 0.9.84-2009030221 [Firefox 3.6a1pre/20090325032457]")
- # [20:15] * Joins: hdh (n=hdh@58.187.21.114)
- # [20:16] * Quits: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
- # [20:18] * aroben is now known as aroben|meeting
- # [20:28] * Joins: weinig (n=weinig@17.246.16.246)
- # [20:30] <Philip`> gsnedders: "This gives a fair performance boost on the spec (~12s)" - you should run your tests on a slower computer, then you could easily get a ~24s performance boost from the same patch
- # [20:31] * Joins: jwalden (n=waldo@corp-241.mountainview.mozilla.com)
- # [20:35] <gsnedders> :D
- # [20:36] * Joins: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
- # [20:40] * Joins: olliej_ (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
- # [20:44] * Joins: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
- # [20:45] * Quits: ap (n=ap@194.154.88.41)
- # [20:46] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
- # [20:51] * Quits: smaug (n=chatzill@cs181146100.pp.htv.fi) (Remote closed the connection)
- # [20:55] * Joins: weinig_ (n=weinig@17.246.16.246)
- # [20:55] * Quits: weinig (n=weinig@17.246.16.246) (Read error: 104 (Connection reset by peer))
- # [20:58] * Quits: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
- # [20:59] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
- # [21:23] * Joins: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au)
- # [21:34] * Quits: olliej_ (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
- # [21:37] * Joins: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
- # [21:52] <gsnedders> Man, I really am awesome at procrastinating.
- # [21:57] * Joins: rubys1 (n=rubys@213.sub-75-211-158.myvzw.com)
- # [21:59] <nessy> lol
- # [22:01] * Quits: mlpug (n=mlpug@a91-156-60-13.elisa-laajakaista.fi) (Remote closed the connection)
- # [22:01] <jgraham> gsnedders: Or you're just arrogant ;)
- # [22:06] * Quits: zalan (n=kvirc@80.99.193.98) ("KVIrc 3.4.0 Virgo http://www.kvirc.net/")
- # [22:06] <annevk3> svl, did you verify that? it sounds weird
- # [22:07] <svl> annevk3: I didn't.
- # [22:07] <svl> Just stumbled across it in the midst of doing other things
- # [22:08] <annevk3> atw, waiting for <iframe onload> seems like a long time; though I don't really have a better solution (other than the <iframe> pinging the parent)
- # [22:15] * Joins: pauld_ (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
- # [22:21] * Quits: pauld_ (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
- # [22:23] * Quits: weinig_ (n=weinig@17.246.16.246)
- # [22:24] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
- # [22:28] * Quits: heycam (n=cam@124-168-80-126.dyn.iinet.net.au) ("bye")
- # [22:28] * Joins: doublec (n=doublec@202.0.36.64)
- # [22:33] <annevk3> rubys1, while <b><i>x</b></i> is a somewhat simple example and "works", adding a character (e.g. <b><i>x</b>x</i>) already gives you a DOM that authors would not expect
- # [22:34] <annevk3> I'm not sure if it's worth distinguishing between the two as it's likely that the cost of implementing in validators would be so high that the resulting messages would be terribly confusing to authors.
- # [22:35] <annevk3> (And validators are already confusing. E.g. validator.nu is a multi-year project and still has a lot of error messages that are quite confusing.)
- # [22:35] <annevk3> (Not to speak of validator.w3.org...)
- # [22:35] * Joins: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
- # [22:35] * Joins: roc (n=roc@202.0.36.64)
- # [22:37] * Quits: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net) ("Leaving.")
- # [22:37] <annevk3> As for "<meta charset=utf-8>". I think zcorpan suggested it might have been that older browsers just looked for the string "charset". That actually seems more plausible than that they tried to work with content that didn't work in any browser whatsoever. (And because they did that authors didn't have to care about quotes...)
- # [22:48] * Joins: zdobersek (n=zan@cpe-92-37-72-115.dynamic.amis.net)
- # [22:48] * Quits: zdobersek1 (n=zan@cpe-92-37-72-115.dynamic.amis.net) (Read error: 104 (Connection reset by peer))
- # [22:48] * Quits: taf2 (n=taf2@65.210.82.235)
- # [22:50] * Joins: zdobersek1 (n=zan@cpe-92-37-68-80.dynamic.amis.net)
- # [22:51] <Philip`> annevk3: Maybe a better example is <meta name=description content=an unquoted sentence>
- # [22:51] * Quits: zdobersek1 (n=zan@cpe-92-37-68-80.dynamic.amis.net) (Client Quit)
- # [22:51] <Philip`> annevk3: It looks like about 1% of <meta name=description>s have that error
- # [22:51] <Philip`> (and about 1% of <meta name=keywords>s too)
- # [22:52] <Philip`> (Some of those are because people accidentally use fancy Word quotes, or put double quotes inside the double quoted attribute value, but I think many are from intentionally unquoted attributes)
- # [22:53] <annevk3> Philip`, what affect did that have on browsers? The ability to handle lots of attributes?
- # [22:53] <annevk3> effect, geez
- # [22:54] <Dashiva> Death to fancy quotes
- # [22:56] * Philip` saw one site with two thousand attributes on its <meta name=keywords>
- # [22:57] <Philip`> annevk3: I wasn't thinking of the effect on authors - I was just thinking of it as evidence that unquoted attributes encourage authoring errors, and so perhaps they should be discouraged
- # [22:58] <Dashiva> Know of any cases where meta @keywords is actually used as keywords, and not just treated as normal text or ignored?
- # [22:59] <Hixie> Philip`: that's very common
- # [22:59] <Hixie> <meta name=keywords content=a, b, c, ... for megabytes>
- # [22:59] <Hixie> i had to make serious changes to my parser to handle this case
- # [22:59] <annevk3> Philip`, I thought rubys1 was talking about fallout
- # [23:00] <annevk3> oh help, <br> and 'clear' is brought up again on www-style
- # [23:01] * annevk3 remembers a certain F2F where that was discussed for more than 10min
- # [23:01] <Hixie> only 10min?
- # [23:02] <annevk3> I'm being conservative here. My recollection has it on 1h :)
- # [23:02] <Hixie> that sounds more like it
- # [23:03] * annevk3 goes to read AC minutes
- # [23:04] * rubys1 is now known as rubys
- # [23:04] * annevk3 didn't know AC meetings where also for chairs
- # [23:04] <annevk3> s/where/were
- # [23:05] * Joins: ojan (n=ojan@nat/google/x-91ad1fc8aee6f677)
- # [23:05] <annevk3> hmm, I write English phonetically and I'm pretty bad at it too :)
- # [23:05] <rubys> Philip` got my intent. I agree that misnested closes are often indication of an error, and that dropping quotes can lead to errors... the line between the two is fuzzy.
- # [23:08] <annevk3> Historically the line has been pretty clear :)
- # [23:09] <rubys> ???
- # [23:09] <rubys> not to me.
- # [23:09] <annevk3> I'm not that opposed to requiring quotes everywhere personally. It's an easy XSS target. However, seems a bit burdersome for existing content and XSS should likely be checked using dedicated tools (e.g. a public version of scanmus) as there are many other potential holes.
- # [23:10] <annevk3> rubys, quotes have always been optional and misnested inlines have always been disallowed
- # [23:10] <rubys> My problem is more basic than that: What would "requiring" mean? What does "disallowed" mean?
- # [23:11] <rubys> Will Opera refuse to show a page that doesn't meet one or the other criteria?
- # [23:11] <rubys> (that was rhetorical, the answer is "of course not")
- # [23:11] <annevk3> (right)
- # [23:11] <annevk3> That has also been pretty consistent from a historical perspective :)
- # [23:12] <annevk3> I was talking about authoring requirements. Much like the SVG WG was.
- # [23:12] <rubys> Is it best practice to nest corectly? To always use quotes? I can see arguments for both.
- # [23:13] * Joins: weinig (n=weinig@64.168.229.50)
- # [23:14] <annevk3> I don't really know about best practice. Sounds fuzzy :)
- # [23:15] <karlcow> [17:54] <Dashiva> Know of any cases where meta @keywords is actually used as keywords, and not just treated as normal text or ignored?
- # [23:15] <karlcow> spotlight on mac os x
- # [23:15] <annevk3> If it's really that unclear, I was simply talking about what prior HTML specifications required from authors. E.g. HTML4.
- # [23:16] <Hixie> wilhelm_: any news on the timeout spec?
- # [23:16] * Quits: zdobersek (n=zan@cpe-92-37-72-115.dynamic.amis.net) (Read error: 110 (Connection timed out))
- # [23:17] * rubys really, really, really didn't want to use the "alt" attribute as my example, which is a case where HTML5 attempts to legislate "best practices" in a way that differs from HTML4
- # [23:17] * Hixie wonders what to do with setTimeout() and company
- # [23:20] <karlcow> Yahoo too it seems if the claim is right http://help.yahoo.com/l/us/yahoo/search/ranking/ranking-02.html
- # [23:22] <annevk3> rubys, I'm not saying we can't make changes either way. As I said, I'd be happy with required quotes. I'm just saying that historically allowing unquoted attributes and disallowing misnested tags has been the way to go.
- # [23:23] <gsnedders> What's an example of something where all browsers interoperably break the spec?
- # [23:25] <annevk3> <datagrid>
- # [23:25] <annevk3> :)
- # [23:25] <Hixie> i don't think "don't implement any of it" counts as "breaking the spec" :-P
- # [23:25] <annevk3> (actually, I guess there are parsing differences in text/html)
- # [23:26] <rubys> gsnedders: http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.3
- # [23:27] <rubys> In particular, shorthand markup.
- # [23:27] * gsnedders was trying to avoid SGMLisms
- # [23:28] <gsnedders> rubys: Also, where in HTML 4.01 does it require an SGML parser to be used?
- # [23:28] <gsnedders> rubys: If there isn't such a thing, as I believe to be the case, then it isn't breaking the spec.
- # [23:29] <rubys> OK, here's a non GML HTML5 issue: "'Boolean attributes in HTML5 can't use the values "true" or "false" and I can't get myself to accept that fact." -- http://www.w3.org/QA/2009/03/a_rough_view_of_the_future.html
- # [23:31] * Quits: Maurice (n=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
- # [23:31] <annevk3> I guess he never used HTML4 :)
- # [23:32] * gsnedders would like a better thing which is certainly against the spec
- # [23:32] * Quits: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au) (Read error: 60 (Operation timed out))
- # [23:33] <annevk3> (Boolean attributes came pretty much straight from HTML4 although we removed the silly SGMLism that you specify the value rather than the attribute.)
- # [23:34] <Hixie> yeah that's not new in HTML5
- # [23:35] <gsnedders> So PHP html5lib tokenizer is currently at 10.2s to tokenize the spec
- # [23:35] <gsnedders> Compared with 7.46s for Python
- # [23:39] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
- # [23:44] * jcranmer is now known as jcranmer|away
- # [23:44] * jcranmer|away is now known as jcranmer
- # [23:53] * Quits: weinig (n=weinig@64.168.229.50)
- # [23:59] * aroben|meeting is now known as aroben
- # Session Close: Thu Mar 26 00:00:00 2009
The end :)