| 03:24 | <MikeSmith> | http://svwebbuilder.wordpress.com/2008/10/16/html-5-the-future-is-now/ |
| 03:24 | <MikeSmith> | "The WebSocket JavaScript API provides the equivalent of a desktop style TCP connection, limited to text-based payloads for now, because JavaScript does not yet have a byte or ByteArray type." |
| 03:24 | <MikeSmith> | I thought Javascript does actually have a byte type |
| 03:26 | <doublec> | nope |
| 03:26 | <doublec> | arrays of numbers is what you need to do for byte arrays |
| 03:27 | <MikeSmith> | I see |
| 03:27 | <MikeSmith> | What's the rationale for it not having a byte type? |
| 03:27 | <othermaciej> | array of numbers and improper string are the two ways of doing it |
| 03:28 | <othermaciej> | there is no rationale, just hasn't been done yet |
| 03:28 | <othermaciej> | (although I don't think there is really a good strawman spec before the ECMAScript committee yet for a type to hold binary data) |
| 03:28 | <othermaciej> | array of numbers is much much much less efficient than a proper ByteArray could be |
| 03:29 | <MikeSmith> | I guess it'll be especially limiting in the case of WebSocket-based apps |
| 03:29 | <doublec> | yes |
| 03:30 | <MikeSmith> | "The WebSocket wire protocol itself can represent either binary or text payloads, so languages other than JavaScript that do have a binary representation can choose to send binary data to a WebSocket server in the raw, rather than having to encode the binary data as text." |
| 03:30 | <doublec> | I wrote some code to read/process Ogg files from JavaScript and used the improper string approach |
| 03:30 | <doublec> | but it's not cross platform afaik since there's no way to say 'give me binary data' from xmlhttprequest |
| 03:31 | <MikeSmith> | well, seems like we are going to have a much more compelling need for it, once websocket gets supported in browsers |
| 03:36 | <othermaciej> | there is already a pretty compelling need for it |
| 03:36 | <othermaciej> | binary XHR is a pretty big use case |
| 03:36 | <othermaciej> | IMO |
| 03:36 | <othermaciej> | there's no clean way to either upload or retrieve binary data via XHR |
| 03:41 | <MikeSmith> | othermaciej: so nobody's submitted a spec proposal to the ECMAScript TC yet? |
| 03:43 | <othermaciej> | MikeSmith: there have been some vague proposals |
| 03:43 | <othermaciej> | maybe I will try to propose something more concrete |
| 03:43 | <othermaciej> | this is the biggest hole in standards development right now IMO |
| 03:47 | <MikeSmith> | othermaciej: concrete proposal would be great to have |
| 03:48 | <MikeSmith> | I want to be the first to write a VOIP server in Javascript :) |
| 03:48 | <othermaciej> | there's bigger pieces missing there than binary data |
| 03:49 | <othermaciej> | like the ability to play and record raw audio data |
| 04:18 | <heycam> | Web IDL has arrays now though, so you can have a type octet[] |
| 04:19 | <heycam> | it's not quite the same as the original ES3 ByteArray |
| 04:19 | <heycam> | no constructor |
| 04:23 | <othermaciej> | that solves the Web IDL side, but not how you represent it in ECMAScript |
| 04:24 | <heycam> | there's http://dev.w3.org/2006/webapi/WebIDL/#es-array |
| 04:24 | <heycam> | or do you mean something else |
| 04:28 | <othermaciej> | I see, I didn't know about that |
| 04:28 | <othermaciej> | I will amend my comment to: I don't think that's a very good way to represent binary data in ECMAScript |
| 04:30 | <slightlyoff> | othermaciej: generally as an objection to some sort of binary array? or the particulars of this outline which doesn't require changes to JS to do it? |
| 04:30 | <othermaciej> | slightlyoff: I think it's a poor design for a type to deal with binary data |
| 04:30 | <slightlyoff> | ah, OK, +1 to that = ) |
| 04:31 | <othermaciej> | I think a binary data type should be immutable, like JS strings |
| 04:31 | <slightlyoff> | hrm |
| 04:31 | <othermaciej> | or maybe have an explicit copy to get a mutable variant |
| 04:31 | <slightlyoff> | I'd prefer that we have a Packed array type |
| 04:31 | <slightlyoff> | and maybe we have fixed and non-fixed variants |
| 04:32 | <slightlyoff> | with ByteArray being a subclass of that |
| 04:32 | <slightlyoff> | (or uses it to mix in) |
| 04:33 | <slightlyoff> | making it immutable seems maybe less important than not needing to accomidate the sparseness |
| 04:33 | <heycam> | othermaciej, is it just the mutability that you think is a poor choice? |
| 04:33 | <othermaciej> | because a key use case is to hold underlying raw data buffers |
| 04:34 | <slightlyoff> | so there are some cases where we'd like to enforce the length that was handed up? |
| 04:34 | <heycam> | there's a concept of read only arrays: http://dev.w3.org/2006/webapi/WebIDL/#dfn-read-only-array |
| 04:34 | <othermaciej> | heycam: well, I'm concerned in general about Web IDL minting new types to that extent |
| 04:34 | <heycam> | and fixed length ones too: http://dev.w3.org/2006/webapi/WebIDL/#dfn-fixed-length |
| 04:34 | <slightlyoff> | ugg |
| 04:35 | <slightlyoff> | I mean, not bad, but they seem poorly integrated w/ JS as a language |
| 04:35 | <slightlyoff> | (which prolly means JS needs to catch up) |
| 04:35 | <othermaciej> | I think it has a whole lot of concepts that aren't really used by the existing IDL-using specs, and defining them in this way will make things awkward when/if JS can better represent some of these concepts in the language itself |
| 04:35 | <othermaciej> | I have to go soon |
| 04:35 | <othermaciej> | but as a parting note |
| 04:36 | <heycam> | that's a good point, sure |
| 04:36 | <othermaciej> | perhaps programming in Cocoa has spoiled me, but my experience with NSData convinces me that binary data should be its own kind of basic data type, like strings, rather than treating it like a kind of array |
| 04:37 | <heycam> | i've never programmed in cocoa so i don't know what goodness NSData gives you |
| 04:37 | <heycam> | but anyway, please do comment on the list when you get a chance |
| 04:37 | <slightlyoff> | fair enough, but I'd like that discussion to happen vis-a-vie JS rather than WebIDL, which sounds like what you're suggesting too |
| 04:37 | <othermaciej> | it's not really specific goodness, just the clarity |
| 04:37 | <othermaciej> | yeah, I think this is an issue for the ECMAScript group |
| 04:38 | <heycam> | they don't seem interested in pushing ByteArray right at the moment |
| 04:38 | <othermaciej> | I think Web IDL should maybe trim back some of the more novel inventions |
| 04:38 | <heycam> | and i think we (the platform) need something like that soon |
| 04:38 | <slightlyoff> | they is us....I say we push it = ) |
| 04:38 | <heycam> | othermaciej, sure, sometimes i think i get carried away with the novelties |
| 04:38 | <othermaciej> | I will try to do a review with an eye towards that soon |
| 04:39 | <heycam> | great thanks |
| 04:52 | <MikeSmith> | Hixie: by "input table", I think Simon meant this: |
| 04:53 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#input-type-attr-summary |
| 04:53 | <Hixie> | oh |
| 04:53 | <Hixie> | not sure what to do about that |
| 04:53 | <MikeSmith> | yeah, I don't see what can be done about it either |
| 04:53 | <MikeSmith> | no way to fit the width on a normal page |
| 04:55 | <MikeSmith> | hmm, I guess the headings could be shortened/abbreviated |
| 08:04 | <hsivonen> | Hixie: seen https://bugzilla.mozilla.org/show_bug.cgi?id=503632 yet? |
| 08:06 | <Hixie> | bug in bugzilla? |
| 08:07 | <hsivonen> | Hixie: sure, but I think it reveals a parser compat issue |
| 08:07 | <Hixie> | i get screwed up output in safari |
| 08:08 | <zcorpan> | hi everybody |
| 08:08 | <hsivonen> | zcorpan! |
| 08:08 | <hsivonen> | zcorpan: did you see the XMLSerializer text/html issue yet? |
| 08:08 | <hsivonen> | zcorpan: are you planning on working on a spec that covers XMLSerializer? |
| 08:08 | <zcorpan> | i haven't seen anything yet :) |
| 08:09 | <Hixie> | i don't understand what's going on here |
| 08:09 | <Hixie> | why is this breaking safari? |
| 08:09 | <Hixie> | the testcase works as it claims it should in safari |
| 08:09 | <zcorpan> | hsivonen: dunno |
| 08:09 | <Hixie> | oh i guess there might be comments in the source or something? |
| 08:09 | <Hixie> | fundamentally, if we don't have reparsing, which we can't for security reasons, there's not much we can do as far as i can tell |
| 08:10 | <Hixie> | we can't be perfectly backwards compatible with browsers that have the security bug |
| 08:10 | <hsivonen> | Hixie: there is. If you are not in escape |
| 08:10 | <hsivonen> | Hixie: and |
| 08:10 | <Hixie> | without having that bug ourselves |
| 08:10 | <hsivonen> | Hixie: you see ", you open an escape until " that prevents <!-- from starting an escape |
| 08:10 | <hsivonen> | Hixie: likewise for ' |
| 08:10 | <Hixie> | say what? |
| 08:11 | <Hixie> | and what if there's a \' in the string? |
| 08:11 | <Hixie> | or if it's in a regexp? |
| 08:11 | <hsivonen> | If you are parsing CDATA and you aren't in a <!-- escape, and you see ", start a new kind of escape until " |
| 08:11 | <Hixie> | that's ridiculously overly complicated |
| 08:11 | <hsivonen> | Hixie: true |
| 08:12 | <hsivonen> | Hixie: But I think we do need some restrictions on where a <!-- escape can start |
| 08:12 | <hsivonen> | Hixie: some approximation that prevents it from starting within a JS statement or a CSS property |
| 08:13 | <Hixie> | i would much rather remove the entire cdata escaping mechanism nonsense, than try to handle this case. |
| 08:14 | <Hixie> | especially given that as written, the spec actually handles this case in the authoring conformance criteria |
| 08:14 | <Hixie> | i blanch at the thought of explaining even more complicated rules |
| 08:14 | <hsivonen> | Hixie: whether that helps depends on how often this happens in the wild |
| 08:14 | <hsivonen> | Hixie: and whether it appears on high-profile sites |
| 08:15 | <hsivonen> | Do IE, Gecko, WebKit and Opera all parse back and forth in this case? |
| 08:16 | <othermaciej> | standards land is a wacky wacky place |
| 08:16 | <hsivonen> | othermaciej: what now? |
| 08:16 | <jgraham> | What is the point of the escaping test span stuff? |
| 08:16 | <zcorpan> | hsivonen: which case is being discussed? |
| 08:16 | <othermaciej> | just everything about it |
| 08:17 | <hsivonen> | jgraham: the point is that <!-- ... </script> ... --> should not end scripts |
| 08:17 | <hsivonen> | zcorpan: https://bugzilla.mozilla.org/show_bug.cgi?id=500937 |
| 08:17 | zcorpan | has 1182 unread emails |
| 08:17 | <hsivonen> | zcorpan: oops. I answered the wrong question |
| 08:18 | <hsivonen> | zcorpan: https://bugzilla.mozilla.org/show_bug.cgi?id=503632 |
| 08:18 | <Hixie> | hsivonen: does it? |
| 08:18 | <jgraham> | hsivonen: Is that needed for compat? |
| 08:18 | <hsivonen> | Hixie: does it appear on high-profile sites? I don't know. |
| 08:18 | <jgraham> | zcorpan: Welcome back :) |
| 08:19 | <hsivonen> | jgraham: I believe <!-- ... </script> ... --> is required for compat |
| 08:19 | <zcorpan> | jgraham: thanks |
| 08:19 | <hsivonen> | jgraham: I haven't researched it myself |
| 08:20 | <Hixie> | hsivonen: i'd like to see how far we can go without having to support this case. given that bugzilla is already broken in safari because of it, i have optimism |
| 08:20 | <Hixie> | possibly misplaced optimism |
| 08:20 | <Hixie> | but optimism nonetheless! |
| 08:20 | <zcorpan> | hsivonen: disabling <!-- in strings won't do much for web compat i think |
| 08:20 | <hsivonen> | Hixie: maybe we should make <!-- have the escaping effect only if it is preceded by: |
| 08:20 | jgraham | only has pessimism |
| 08:20 | <hsivonen> | 1) only whitespace |
| 08:20 | <hsivonen> | or |
| 08:20 | <hsivonen> | 2) // and then only whitespace |
| 08:20 | <hsivonen> | or |
| 08:20 | <hsivonen> | 3) /* and then only whitespace |
| 08:21 | <zcorpan> | hsivonen: there are pages that have <!-- at the end of scripts |
| 08:21 | <hsivonen> | zcorpan: and they require the escaping effect? |
| 08:22 | <jgraham> | hsivonen: Equivalent to the cases where ecmascript engines treat <!-- as the start of a comment |
| 08:22 | <hsivonen> | whee! do we need to roll an ES parser into the HTML5 tokenizer? |
| 08:22 | <Hixie> | hsivonen: given the effects on conformance, i'd rather not make any changes unless it is deemed absolutely necessary for compat. (which isn't that high a bar, in practice) |
| 08:23 | <Hixie> | hsivonen: (but is a high enough bar to slow us down here) |
| 08:24 | <jgraham> | hsivonen: See http://wiki.whatwg.org/wiki/Web_ECMAScript#HTML_comments for the treatment of <!-- by ecmascript engines |
| 08:24 | <hsivonen> | how hard it would be to make a small state machine that picks up regexp literals from within an EcmaScript program? |
| 08:24 | <hsivonen> | with reasonable probability that is |
| 08:24 | <hsivonen> | not with 100% accuracy |
| 08:25 | jgraham | is hopeful that you are overcomplicating this |
| 08:26 | <Lachy_> | Hixie, hsivonen, which existing browser requires that <!-- ... </script> ... --> doesn't end scripts? I just tested non-HTML5 parsing Minefield, Safari, and Opera, and they all close it |
| 08:26 | <Hixie> | Lachy_: make sure you have a trailing </script> |
| 08:26 | <Hixie> | Lachy_: so you don't get caught by the reparsing behaviour |
| 08:27 | hsivonen | wonders who introduced this stuff into browsers in the first place |
| 08:27 | <hsivonen> | not that it matters anymore |
| 08:28 | <Lachy> | oh, wow. Yeah, my original test was flawed. |
| 08:28 | <Lachy> | that's crazy |
| 08:33 | <othermaciej> | probably Lou Montulli |
| 08:33 | <othermaciej> | or at least, I mentally blame him for anything that is terrible about browsers |
| 08:37 | <hsivonen> | Hixie: which browser is the "script-created parser" stuff and document.open() modeled on? |
| 08:39 | <Hixie> | a composite sketch of the various browsers |
| 08:39 | <hsivonen> | hmmkay. |
| 08:39 | <zcorpan> | hsivonen: you could have used window.name to store state across form submission in v.nu |
| 08:40 | <hsivonen> | zcorpan: interesting. thanks |
| 08:40 | <hsivonen> | Hixie: I *think* Gecko doesn't have the concept of a script-created parser |
| 08:40 | <hsivonen> | Hixie: in the sense that you could find out later if a parser was script-created |
| 08:40 | <hsivonen> | I guess I should add that! |
| 08:41 | <Hixie> | you can tell without a separate flag |
| 08:41 | <Hixie> | by checking to see if the insertion mode is defined or not |
| 08:41 | <Hixie> | iirc |
| 08:42 | <zcorpan> | hsivonen: they expect reparsing but only break in minor ways |
| 08:42 | <Hixie> | whether it's undefined or whether the nesting level is non-zero, maybe |
| 08:42 | <Hixie> | i forget |
| 08:43 | <Hixie> | oh maybe also the encoding confidence being irrelevant is another way of telling if it's script-created or not |
| 08:43 | <hsivonen> | Hixie: my test for insertion point defined is a bit of a hack |
| 08:43 | <Hixie> | basically the only thing "script-created parser" matters for is whether d.o and d.c do anything |
| 08:43 | <zcorpan> | hmm. i now have 2046 unread emails :( |
| 08:44 | <hsivonen> | Hixie: I'm a bit nervous about trusting that certain invariants hold so that I don't need a dedicated flag |
| 08:44 | <Hixie> | yeah |
| 08:44 | zcorpan | considers reading the spam and deleting everything else |
| 08:44 | <jgraham> | zcorpan: How did the number increase? Did you unread some mail? |
| 08:44 | <Hixie> | hsivonen: that's why i have a separate flag in the spec :-) |
| 08:44 | <zcorpan> | jgraham: opera didn't download it all at first |
| 09:05 | <hsivonen> | Hixie: editorial: "not undefined" is not quite nice. "defined" is nicer |
| 09:06 | <Hixie> | defined means something different than not undefined in this context, sadly |
| 09:06 | <Hixie> | or can be interpreted differently, shall we say |
| 09:06 | <hsivonen> | oh |
| 09:07 | hsivonen | hopes !mParser->IsInsertionPointDefined(key) does the right thing nonetheless |
| 09:09 | <Hixie> | well the point is that in the context of the spec, the insertion mode is always defined, it's just sometimes defined to have the value "undefined" |
| 09:10 | <Hixie> | if you see what i mean |
| 09:10 | <hsivonen> | ok |
| 09:11 | <hsivonen> | fwiw, in order to avoid refactoring the Gecko script execution code, my IsInsertionPointDefined() is quite detached from the spec |
| 09:12 | <hsivonen> | I hope it is black-box equivalent, though |
| 09:12 | <hsivonen> | in particular, I think it's quite easy to break it accidentally when implementing async scripts |
| 09:14 | <hsivonen> | Hixie: do you happen to have a test suite for document.open() and insertion point? |
| 09:15 | <Hixie> | you might find some stuff on hixie.ch either under tests/adhoc/html/parsing or adhoc/dom/level0/ or something |
| 09:15 | <Hixie> | dunno how correct it is though |
| 09:15 | <hsivonen> | Hixie: ok. thanks |
| 09:18 | <hsivonen> | Hixie: the vague mention of form submission encoding in the non-UTF-8 case seems good enough for me |
| 09:18 | <Hixie> | k |
| 09:35 | <hsivonen> | http://hixie.ch/tests/adhoc/dom/level0/write/004.html doesn't have a pass condition, right? |
| 09:35 | <hsivonen> | ah. demos |
| 09:35 | hsivonen | *always* misses the text at the bottom of the directory listing |
| 09:37 | <Hixie> | yeah it's not very clear. and i don't always mark up which are demos anyway. |
| 09:42 | <MikeSmith> | sayrer: you there? |
| 09:43 | <hsivonen> | http://hixie.ch/tests/adhoc/dom/level0/write/005.html just says Kittens! and doesn't stop loading |
| 09:45 | <hsivonen> | oh noes. the failure to load is caused by my upcoming patch. :-( |
| 09:56 | <Hixie> | is it supposed to lead? |
| 09:56 | <Hixie> | load |
| 09:56 | <Hixie> | (i didn't check the test) |
| 09:57 | <olliej> | hsivonen: i like the idea of a kittens only version myself |
| 09:57 | <olliej> | Hixie: maybe kittens and puppies rather than budgies? |
| 09:57 | <boblet> | hey all |
| 09:57 | olliej | doesn't particularly like budgies |
| 09:58 | <hsivonen> | Hixie: it finishes loading in Gecko without my upcoming patch and in Safari and in Opera |
| 09:59 | <hsivonen> | Hixie: I didn't test IE yet |
| 09:59 | <hsivonen> | Hixie: so I assume it should finish loading! |
| 09:59 | <Hixie> | these tests are funny, the server is explicitly inserting pauses |
| 10:00 | <Hixie> | i'm not really sure why that test should finish loading |
| 10:00 | <Hixie> | i mean... there's no EOF as far as I can tell |
| 10:01 | <olliej> | Hixie: timeout perhaps? |
| 10:01 | <hsivonen> | Hixie: ooh! maybe my flush timer just sucks |
| 10:01 | <Hixie> | what if it was running in another frame and some other script poked more text into it? |
| 10:01 | <Hixie> | long after the timeout fired? |
| 10:01 | <Hixie> | i dunno |
| 10:01 | <Hixie> | these tests give me headaches |
| 10:02 | <hsivonen> | me too. at least if I defer lunch due to them any longer |
| 10:07 | <hsivonen> | on a completely different note, I think Theora.org should have a page that authors can link to in order to clue their users in on how to get a Theora-capable browsing setup |
| 10:07 | <hsivonen> | the page should be vendor-independent |
| 10:08 | <hsivonen> | currently pointing to Firefox 3.5 and XiphQT for Safari |
| 10:08 | <hsivonen> | and over time adding Opera 10.next and Chrome 3 as those ship |
| 10:09 | <hsivonen> | (I think an association that I'm a member of might find such a page useful, since simply promoting one vendor wouldn't look right for the association) |
| 10:09 | <boblet> | A question regarding the header element; the content model is flow but no header or footer element descendants. That means it could contain a section, but the contained section couldn’t contain a header, right? |
| 10:09 | <Hixie> | right |
| 10:09 | <boblet> | So that means a complex page header (eg containing sections with headers) will need to be a section huh |
| 10:10 | <Hixie> | the nested section could contain <h1>s and <hgroup>s and such like |
| 10:10 | <Hixie> | but it couldn't contain its own <header> |
| 10:10 | <Hixie> | if you have an example of when that might make sense, though, let us know |
| 10:10 | <Hixie> | the idea of restricting it was we couldn't find any case where it made sense, and we found lots of cases where it didn't and we wanted to discourage people misusing it for those cases |
| 10:11 | <boblet> | hmm, ok. It does make sense, I just wanted to check I was understanding it |
| 10:18 | <Hixie> | i wonder if what i specced about the origin of <img> elements in the case of redirects, data:, javascript:, etc, is true |
| 10:19 | <Hixie> | is the origin of <img> elements only relevant for <canvas>? |
| 10:19 | <Hixie> | or do we use it for anything else? |
| 10:57 | <boblet> | later all |
| 10:59 | <hsivonen> | wow. in IE8, 005.html fails and gives an MS KB reference |
| 10:59 | <hsivonen> | KB297917 |
| 11:00 | <hsivonen> | why don't I get to bail out and point to a KB article on hard stuff? |
| 11:01 | <Hixie> | did it give a url? i can't find that kb on the web |
| 11:01 | <hsivonen> | It didn't |
| 11:01 | <hsivonen> | Google found me a page in Polish |
| 11:01 | <Hixie> | yeah me too |
| 11:02 | <hsivonen> | Oops. my typo |
| 11:02 | <hsivonen> | KB927917 |
| 11:03 | <Hixie> | it says it doesn't occur in IE8 |
| 11:03 | <hsivonen> | Well, I got the number from IE8 |
| 11:04 | <Hixie> | was it in IE7 mode? |
| 11:04 | <Hixie> | it explicitly says this was an IE7 bug fixed in IE8 |
| 11:04 | <hsivonen> | it says <!DOCTYPE HTML> |
| 11:04 | <Hixie> | on that page |
| 11:04 | <zcorpan> | i wonder when js libraries will implement sessionStorage with fallback to window.name |
| 11:05 | <hsivonen> | Hixie: Browser Mode: IE8 Document Mode: IE8 Standards |
| 11:05 | <hsivonen> | Hixie: says IE8 |
| 11:05 | <Hixie> | weird |
| 11:06 | <hsivonen> | Hixie: wouldn't be the first time MSDN isn't quite precise about IE behavior |
| 11:06 | <Hixie> | this is beyond "not quite precise" |
| 11:13 | <zcorpan> | + <p>Authors should not specify a <code |
| 11:13 | <zcorpan> | + title="attr-img-border">border</code> attribute on an |
| 11:13 | <zcorpan> | + <code>img</code> element if its value is the string "<code |
| 11:13 | <zcorpan> | + title="">0</code>". |
| 11:13 | <zcorpan> | Hixie: sounds like border="1" is fine |
| 11:13 | <Hixie> | i've fixed that already |
| 11:13 | <zcorpan> | oh |
| 11:13 | <zcorpan> | ok |
| 11:13 | <Hixie> | :-) |
| 11:13 | <Hixie> | i realised the same thing later when i was editing something else |
| 11:13 | <Hixie> | i was like, wait, wtf am i saying here |
| 11:14 | <Hixie> | it now reads: |
| 11:14 | <Hixie> | Authors should not specify a border attribute on an img element. If the attribute is present, its value must be the string "0". CSS should be used instead. |
| 11:15 | <hsivonen> | this is interesting: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/020961.html |
| 11:15 | <hsivonen> | the bit about GStreamer |
| 11:19 | <othermaciej> | I wonder if they are going to end up plugging into system media frameworks + ensuring availability of an Ogg codec set |
| 11:19 | <Lachy> | hsivonen, yeah, I was surprised he mentioned that publicly. We've known about it internally for a while. |
| 11:20 | <othermaciej> | the part that had me curious was "when using GStreamer" which implies it is used sometimes but not always |
| 11:20 | <othermaciej> | Lachy is probably not free to comment on the matter (but if you are, feel free to enwisen us) |
| 11:21 | <hsivonen> | othermaciej: could be for non-desktop Linux-based deployments |
| 11:22 | <hsivonen> | oh, this is just great. I get different results inside and outside gdb |
| 11:22 | <hsivonen> | or I'm doing something wrong |
| 11:23 | <hsivonen> | No, I'm just confused |
| 11:24 | <hsivonen> | I'm getting different results loading 005.html by navigating to it and loading it by session restore |
| 11:27 | <Lachy> | othermaciej, I haven't been informed about what exactly we can say about this, so I probably shouldn't reveal any more |
| 11:31 | <foolip> | it's been publically known that we use GStreamer internally since OVC |
| 11:32 | <Hixie> | hey, it's philipj |
| 11:32 | <Hixie> | foolip: thanks for all your feedback on the spec so far, it's been great |
| 11:32 | <foolip> | but certainly won't always, on embedded devices as such |
| 11:33 | <foolip> | Hixie, and thank you for editing it :) |
| 11:33 | <hsivonen> | foolip: what about Windows and Mac? |
| 11:34 | <foolip> | well... what specifically about them? |
| 11:35 | <foolip> | how do we guarantee support for our "baseline"? |
| 11:35 | <hsivonen> | foolip: presumably Windows and Mac don't use GStreamer, so what will they use? |
| 11:36 | <foolip> | we'll bundle the decoders we need |
| 11:36 | <foolip> | if that's DirectShow decoders, internal decoders or something else I'm quite sure I shouldn't say yet |
| 11:36 | <hsivonen> | foolip: I see |
| 11:37 | <foolip> | as I mentioned at OVC we've tried doing DirectShow, it kind of works, but I wouldn't recommend it to anyone |
| 11:39 | <foolip> | the primary reason to use GStreamer on UNIX is to not have to handle the 10^10 different audio output API:s, not because it can decode theora/vorbis |
| 11:41 | <foolip> | anyway, rest assured that we won't simply use the platform framework in all instances, that way it's impossible (very hard) to get consistent behavior of even the simplest stuff |
| 11:53 | <hsivonen> | Hixie: in 005.html, the first document.write should fire when insertion point is not defined, because the act of inserting a script-created script element with src causes the script to run only when src has loaded, right? |
| 11:54 | <hsivonen> | Hixie: so the script shouldn't be running at the appendChild stage anyway? |
| 11:56 | <hsivonen> | hmm. I think my insertion point hack might not be handling all event loop interleavings right |
| 11:56 | <hsivonen> | aaargh |
| 11:57 | <hsivonen> | basically, it seems that I get the wrong results when I think the next script that going to be run from the event loop is one whose load is parser-requested, but a script-inserted script gets run from the event loop |
| 11:58 | <hsivonen> | I wonder if it's even possible to get the insertion point stuff right without refactoring how Gecko loads an runs external scripts |
| 12:05 | <hsivonen> | if it happens that the code I now have is correct per spec, the behavior I get doesn't match any shipped browser |
| 12:06 | <hsivonen> | I'm not sure what I've done exactly |
| 12:07 | <hsivonen> | I get confused by which document JS 'document' points to after document.open() |
| 12:08 | <hsivonen> | specifically, if a script was created by parser 1, then an implied document.open() happened that blew the parser away and then the parser-created script does document.write() I'm not sure if I got insertion points right |
| 12:08 | zcorpan | agrees with roc about (new Audio()).autobuffer |
| 12:09 | <hsivonen> | Hixie: if the parser that created a script was aborted by document.open() and then the script does document.write(), where should it write? |
| 12:09 | <hsivonen> | Hixie: into the new script-created parser whose insertion point is always defined? |
| 12:10 | <Hixie> | i want to say yes |
| 12:10 | <Hixie> | but i'm too tired to stand by that yes with the full force of my convictions |
| 12:10 | <hsivonen> | Hixie: I see |
| 12:10 | <hsivonen> | I think I'm going to hack on the validator for the rest of the day and sleep on document.write |
| 12:11 | <hsivonen> | it would be awesome to have expected results for 005.html |
| 12:11 | <Hixie> | i'm not 100% sure on what your earlier question means, but it will probably make more sense when i awake in about 10 hours |
| 12:11 | <Hixie> | send me an e-mail asking me to update the tests |
| 12:11 | <Hixie> | and i'll try to do it |
| 12:11 | <hsivonen> | Hixie: OK |
| 12:13 | hsivonen | wonders if Gecko distinguishes between the HTML5 pending external script concept and script-created external scripts spinning the event loop while waiting for the network to do its thing |
| 12:16 | <zcorpan> | Hixie: does prince support css transforms? |
| 12:16 | <Hixie> | no idea |
| 12:16 | <Hixie> | howcome would know |
| 12:21 | <Hixie> | ok now i must sleep |
| 14:36 | <zcorpan> | ooooh |
| 14:36 | zcorpan | reads the news about the xhtml2 wg |
| 14:37 | <takkaria> | you did have a lot of mail ^_^ |
| 14:49 | <zcorpan> | i wonder why http://www.w3.org/2009/06/xhtml-faq.html doesn't mention microdata or ?style=author |
| 14:55 | <zcorpan> | Hixie: the spec should use <hgroup> |
| 14:55 | <Lachy> | zcorpan, is today the first time you heard about the XHTML2 being discontinued? |
| 14:56 | <zcorpan> | Lachy: yeah, i've been on vacation |
| 14:56 | <Lachy> | ok |
| 14:57 | <jgraham> | takkaria: So when are you going to become the HTML5 test czar? |
| 14:57 | Lachy | wonders if you missed any other big news for the past few weeks |
| 14:57 | <zcorpan> | http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Fw3.org - now with alt="" support! |
| 14:58 | <zcorpan> | Lachy: likely, i still have 1700 unread emails |
| 14:58 | <jgraham> | zcorpan: We came surprisngly close to something that may yet lead to consensus on the @summary issue |
| 14:59 | <Lachy> | jgraham, we did?! |
| 14:59 | <gsnedders> | (Anolis does different stuff with img in the TOC) |
| 14:59 | <takkaria> | jgraham: it's hard to say. I might get round to looking at it around the end of August, I suppose |
| 15:00 | <Lachy> | zcorpan, yeah, but I was also thinking about major world news stuff too. Though I'm going to assume you haven't been completely cut off from civilisation. |
| 15:01 | <takkaria> | the world news can be summed up mostly as "the world is still going to shit, some good things happened too" |
| 15:02 | <jgraham> | Lachy: The use of should not rather than an implied must not and specific advice about how to do better seemed to bring us closer to agreement than we have been at any point so far, although I may be misreading the situation |
| 15:03 | <Lachy> | jgraham, I thought the change that made summary conforming but obsolete would make people happy, but there are still a lot of people sustaining their objections |
| 15:03 | <Lachy> | (even though that particular change made me unhappy, I can live with it if I have to) |
| 15:06 | <Lachy> | takkaria, I don't remember anything good happening recently |
| 15:08 | <takkaria> | someone did a cool bike stunt in London the other night |
| 15:09 | <MikeSmith> | Lachy: good things happening recently: dhyatt starting working on a datagrid implementation for Webkit, Chrome team started on Web Sockets implementation, and there's also a Web Sockets patch for Mozilla that's received some review |
| 15:09 | <MikeSmith> | oh, and Mozilla has hashchange support now too |
| 15:11 | <Lachy> | takkaria, got a link to a video? |
| 15:11 | <Lachy> | MikeSmith, cool. I didn't know that. |
| 15:12 | <takkaria> | Lachy: Lachy http://news.bbc.co.uk/2/hi/uk_news/8147714.stm |
| 15:14 | <Lachy> | wow |
| 15:15 | <gsnedders> | takkaria: Got a link that doesn't need Flashy? |
| 15:16 | <gsnedders> | *Flash |
| 15:16 | <takkaria> | no |
| 15:18 | <Lachy> | from the more bad news desk http://science.slashdot.org/story/09/07/13/1330220/NASA-Plans-to-De-Orbit-ISS-in-2016?from=rss |
| 15:19 | <jgraham> | Lachy: That hardly counts as bad news. ISS has been a total disaster |
| 15:20 | gsnedders | wonders when it's meant to be completed |
| 15:20 | <jgraham> | gsnedders: Well it was /meant/ to be completed years ago |
| 15:20 | <gsnedders> | jgraham: I mean the current meaning. :P |
| 15:21 | <takkaria> | jgraham: I was actually thinking about the html5 testsuite the other day. I guess it would be useful to have it in place by October for LC, and I should have time and energy before then to sort it out |
| 15:21 | <Lachy> | jgraham, in what way? |
| 15:21 | <takkaria> | jgraham: someone else can always do it, though. :) |
| 15:23 | <jgraham> | Lachy: It has taken forever, cost far more money than it was supposed to and done no useful science (whilst taking money that could otherwise be used for science projects) |
| 15:24 | <zcorpan> | Lachy: i guess i was more exposed to world news during my vacation compared to when i work |
| 15:24 | <gsnedders> | jgraham: s/science projects/useful science projects/ I assume you mean as it has done some, just not useful ones. |
| 15:26 | <jgraham> | I think it has done some stuff like "lets do some experiments designed by schoolkids about growing crystals in space" |
| 15:26 | <jgraham> | It may even have done the odd actually valuable thing. But a lot of stuff that was designed to work with the ISS had to be abandoned or reworked as independant missions |
| 15:27 | <jgraham> | So per unit currency it has been an epic failure for science |
| 15:27 | <Lachy> | jgraham, that depends if you consider experiments like this to be useful or not. http://www.youtube.com/watch?v=zaHLwla2WiI In any case, it's pretty cool; |
| 15:28 | <gsnedders> | Lachy: That hardly needs a space station to do, just something in freefall |
| 15:28 | <gsnedders> | A plane in freefall would work as a container for that |
| 15:29 | <jgraham> | I'm not even convinced that it has taught us anything useful about going into space aprt from maybe "don't do it like this" |
| 15:29 | <Philip`> | It has ushered in an era of International cooperation! |
| 15:30 | <gsnedders> | Philip`: But Mongolia isn't involved! |
| 15:30 | <Lachy> | gsnedders, the Zero G company that does flights like that only last about 30 seconds each time, which isn't much for doing experiments. |
| 15:30 | <gsnedders> | Lachy: It depends what experiment you want to do :) |
| 15:30 | <Phae> | those Zero G experiences are expensive. i was looking them up just the other day. |
| 15:31 | <Lachy> | Phae, how much are they? |
| 15:31 | <jgraham> | To the extent that that counts as a science experiment it could be done on the shuttle or something |
| 15:32 | <Phae> | well, once you've got there... http://www.elite-expeditions.co.uk/zgbook.htm |
| 15:32 | <Philip`> | Phae: Probably cheaper than the ISS, though :-) |
| 15:32 | <Phae> | sure |
| 15:34 | <Lachy> | wow, they even charge $195 for the non-flyer package. https://www.gozerog.com/index.cfm?fuseaction=reservations.welcome |
| 15:34 | <gsnedders> | Phae: When NASA owns both such things and the shuttle, I'm sure they'd say it was cheaper in terms of operation costs :) |
| 15:34 | <Phae> | aye |
| 15:35 | <Phae> | it would be ace, but it's a pretty expensive rollercoaster like experience, i imagine :) |
| 15:35 | <gsnedders> | Phae: I doubt rollercoasters let you fall vertically without being attached to anything at 9.81 m/s :) |
| 15:36 | <Lachy> | I wonder why they cost so much. They're just flying a modified Boeing 727, and surely they aren't that costly to operate |
| 15:36 | <Phae> | yeah, but for such a short period of time |
| 15:36 | <Phae> | by the time you got the hang of it, you'd be onthe floor again |
| 15:36 | <gsnedders> | Lachy: Probably insurance, as flying vertically down is somewhat dangerous. Then you have supply/demand. |
| 15:37 | <Phae> | and there's not a competitive enough number of operators, probably |
| 15:37 | <Lachy> | I think they're the only commercial operators of such flights |
| 15:37 | <Phae> | well, there you go |
| 15:37 | <jgraham> | Lachy: They might well be quite costly to operate given the number of passengers, but it is more about market economics |
| 15:37 | <jgraham> | I was surprised at how cheap they are |
| 15:38 | <Lachy> | jgraham, cheap?! |
| 15:38 | <gsnedders> | Likewise |
| 15:38 | <jgraham> | (for the record ISS cost something like 100 billion euros over its lifetime) |
| 15:38 | <gsnedders> | Lachy: They could quite easily charge 5 times what they do. You get a whole 727 between around 10–15 people or so I guess |
| 15:39 | <gsnedders> | Lachy: And provided they are the only supplier, there is a fair amount of demand, so I expect they could charge more. |
| 15:40 | <Phae> | but still, would you spend �2500 to be weightless for 30 seconds, 15 times? |
| 15:40 | <Phae> | that's what makes it expensive or not |
| 15:41 | <jgraham> | If I liked that sort of thing and had the cash, sure |
| 15:41 | <jgraham> | It's aimed at people with substantial disposable income |
| 15:41 | <jgraham> | not at people who go to butlins |
| 15:41 | <gsnedders> | Phae: I don't particularly have much interest in it. |
| 15:41 | <Phae> | yeah, so to those people it's cheap |
| 15:42 | <Phae> | if you think you ened to have substantial disposable income to make it worthwhile, ti's not cheap :P |
| 15:42 | <Phae> | it's* |
| 15:42 | <Phae> | need* ugh. |
| 15:42 | <takkaria> | it sounds like one of those things that if you had a lot of money just lying around, you might as well do, really |
| 15:42 | <Phae> | sure |
| 15:42 | <Phae> | i would if i did |
| 15:42 | <Lachy> | jgraham, what is "butlins"? |
| 15:42 | <Phae> | haha |
| 15:42 | gsnedders | looks behind his sofa |
| 15:43 | <Phae> | butlins is like, cheesy family vacation place. think cold, bored, brits in seaside resorts |
| 15:43 | <takkaria> | also used for festivals sometimes |
| 15:44 | <gsnedders> | Mainly used by those who cannot afford to go abroad, as far as I can tell. |
| 15:45 | <jgraham> | http://www.butlins.com/ |
| 18:48 | <Philip`> | http://blog.digitalbazaar.com/2009/07/13/html5rdfa/ (plus page 2) |
| 18:51 | <Philip`> | Oh, it was already posted to the list |
| 18:52 | <Lachy> | from a quick glance, it seems they're ignoring all the concerns over namespaces, prefixes, CURIEs, etc. Oh well. |
| 18:53 | <Lachy> | although, they have notes about it. So maybe they will do something about it |
| 19:08 | <hober> | could someone with wiki admin privleges delete http://wiki.whatwg.org/wiki/Hafez |
| 19:09 | <Lachy> | ok |
| 19:12 | <Lachy> | done |
| 19:12 | <Lachy> | hober, do you have a wiki account? |
| 19:12 | <Lachy> | I can give you admit privilages if you like |
| 19:12 | <Lachy> | *admin |
| 19:25 | <hober> | I have an account, I'm User:EdwardOConnor |
| 19:25 | <hober> | sure, thanks |
| 20:38 | <jgraham> | gsnedders: I just pushed something to html5lib that might make the not putting of html elements in a namespace work |
| 20:38 | <jgraham> | Needs tests though |
| 20:38 | <gsnedders> | jgraham: Well seeming I'll probably soon move on to making Anolis work with the namespaces (so it works with XHTML too), I'm not entirely sure how relevant it is :) |
| 21:13 | <gmiernicki> | oi... anyone know if localStorage is accessible via web workers? |
| 21:14 | <gmiernicki> | ive been reading through the forum threads, and got quite confused as most discussions pertain the the browser implementations |
| 21:31 | <jgraham> | gsnedders: There's no pleasing some people |
| 21:31 | <gsnedders> | jgraham: No, there isn't. |
| 22:16 | <gmiernicki> | there's no helping people it seems either, sometimes |
| 22:16 | <gmiernicki> | back to google i suppose... |
| 22:25 | <Spark^> | I need to use a more recent version of html5lib for python than 0.11 as I'm getting infinite recursion problems. Can anyone suggest what reasonably stable version I should check out as the trunk (or the mercurial equivalent term) gives me other errors. |
| 22:27 | <gsnedders> | Spark^: Before jgraham started merging stuff around a month ago. |
| 22:28 | <gsnedders> | Spark^: 759c5bd902 is what I use in places |
| 22:30 | <Spark^> | nothing like me dropping in at the deep end! i like the visualisation of branches in google code, but haven't a clue how i check out a particular revision! |
| 22:32 | <Spark^> | will hg update 759c5bd902 |
| 22:32 | <Spark^> | do it? |
| 22:33 | <Philip`> | You probably want "-r 759etc" |
| 22:33 | <Philip`> | but I don't know if you want "update" or not |
| 22:35 | <Spark^> | hmmm, i guess 'invalid syntax' on "byte-compiling build/bdist.linux-x86_64/egg/html5lib/treewalkers/_base.py to _base.pyc isn't good" :( |
| 22:36 | <gsnedders> | Philip`: update or up |
| 22:36 | <gsnedders> | Spark^: What version of Python? |
| 22:36 | <Spark^> | 2.5 |
| 22:36 | <gsnedders> | Can I shrug my shoulders and go to bed? |
| 22:37 | <Spark^> | i should do the same. you've got me a lot further on, so thanks for your help. |
| 22:38 | <gsnedders> | That rev worked today for me |
| 22:38 | <Spark^> | if i could drive google's thingy to show me changes to that file i'd maybe be able to select a revision close by |
| 22:38 | <Spark^> | probably something stupid i'm doing |
| 22:38 | <Spark^> | like, i'm not 100% sure that update or pull worked |
| 22:38 | <gsnedders> | You'll know if it failed. |
| 22:40 | <jgraham> | Spark^: try latest tip |
| 22:41 | jgraham | has to go now |
| 22:51 | <Spark^> | i take it tip == my idea of head |
| 22:51 | <Spark^> | get errors with that |
| 22:51 | <Spark^> | byte-compiling build/bdist.linux-x86_64/egg/html5lib/treewalkers/_base.py to _base.pyc |
| 22:51 | <Spark^> | File "build/bdist.linux-x86_64/egg/html5lib/treewalkers/_base.py", line 40 |
| 22:51 | <Spark^> | "data": []} |
| 22:51 | <Spark^> | SyntaxError: invalid syntax |
| 22:52 | <Spark^> | then when i run my code i get |
| 22:52 | <Spark^> | File "build/bdist.linux-x86_64/egg/html5lib/html5parser.py", line 468, in processDoctype |
| 22:52 | <Spark^> | TypeError: insertDoctype() takes exactly 4 arguments (2 given) |
| 23:07 | <Lachy> | wow, I just read through that RDFa in HTML draft, and there are so many issues with it |
| 23:09 | <Lachy> | from the last paragraph: "Since CURIE prefix mappings have been specified using xmlns:, and since HTML attribute names are case-insensitive, CURIE prefix names declared using the xmlns:attribute-name pattern xmlns:<PREFIX>="<URI>" should be specified using only lower-case characters. For example, the text "xmlns:" and the text in "<PREFIX>" should be lower-case only. This is to ensure that prefix mappings are interpreted in the same way between HTML (case |
| 23:09 | <Lachy> | -insensitive attribute names) and XHTML (case-sensitive attribute names) document types." |
| 23:11 | <Lachy> | that seems to indicate that there are some unspecified problems when using uppercase, but says nothing about how to handle it. Though, presumably, it doesn't really matter, since the parser lowercases them anyway, and it's only a problem if you are making a polyglot document |
| 23:12 | <Lachy> | it's not really clear if that's what it means though |
| 23:14 | <Lachy> | "If an author is unsure of the final encapsulating DOCTYPE for their markup..." -- what the? |
| 23:17 | Hixie | tries to understand what happened to the "URLs" stuff in http://tools.ietf.org/html/draft-duerst-iri-bis |
| 23:17 | <Hixie> | did larry just make invalid URIs conforming? |
| 23:17 | <Hixie> | i'm confused |
| 23:20 | <Hixie> | man in that algorithm has gotten seriously corrupted since it was in html5 |
| 23:20 | <Hixie> | and there are entire sections missing now |
| 23:20 | <Hixie> | sigh |
| 23:20 | Hixie | adds it to his list of things to e-mail about |
| 23:23 | <Lachy> | that mail from Larry doesn't have a link to the draft. Where can I find it? |
| 23:24 | <Hixie> | i just posted it |
| 23:24 | <Hixie> | :-) |
| 23:25 | <Lachy> | oh. I didn't read that far back, that's a whole 8 messages back |