| 00:11 | <Hixie> | heycam: ToUInt32(-1) == 2**32-1? |
| 00:11 | <Hixie> | right? |
| 00:11 | <bga_> | yes |
| 00:11 | <heycam> | Hixie, yep\ |
| 00:11 | <Hixie> | k |
| 01:07 | <roc> | I need to add an API to extract a MediaStream from an HTML media element |
| 01:08 | <roc> | I have to decide whether the stream should represent "whatever's currently playing in the media element" or "just the current resource, until it ends" |
| 01:09 | <roc> | in the latter case, loading a new resource or restarting playback after "ended" would start a new stream |
| 01:09 | <roc> | Hixie: any opinion? |
| 01:09 | <Hixie> | hmm |
| 01:09 | <Hixie> | what's the use case? |
| 01:09 | <Hixie> | pushing to a peer / WebAudio processing? |
| 01:09 | <Hixie> | or saving the resource to disk? |
| 01:09 | <roc> | those are all use-cases |
| 01:10 | <Hixie> | displaying it in a monitor <video>? |
| 01:10 | <roc> | the latter is less interesting I think |
| 01:10 | <Hixie> | if the use case is to take whatever the user is currently watching and essentially fork it for use elsewhere, i'd go with having a "live" copy that just streams whatever is being rendered |
| 01:10 | <roc> | my main use cases are audio/video playback with mixing and processing; stream it out to a peer is a secondary use-case |
| 01:10 | <Hixie> | so e.g. it would start displaying a static image if the media element was paused, etc |
| 01:11 | <Hixie> | though that would act really weird if you then could pause and rewind it |
| 01:11 | <roc> | the main problem with the "whatever's currently playing" approach is that it means the stream can end, and then start producing data again later |
| 01:11 | <roc> | the RTC people don't like that |
| 01:11 | <Hixie> | why would it end? |
| 01:12 | <roc> | if you treat the "ended" state of the media element as ending the stream |
| 01:12 | <roc> | which would be intuitively appealing, and useful as well |
| 01:13 | <Hixie> | if you're just outputting what the media element is playing, i don't think you'd do that |
| 01:14 | <Hixie> | "ended" just means that the current playback position is at the end |
| 01:14 | <Hixie> | doesn't mean that there won't be more later |
| 01:14 | <roc> | then we'd need a different API to let authors load a media resource and get a MediaStream for it that ends when the resource ends |
| 01:15 | <Hixie> | well, i could certainly see a use case for "get a mediastream for a resource", but it wouldn't "end", it would just represent the (possibly finite) resource, right? |
| 01:15 | <roc> | we could have both APIs on the media element, but that might be confusing |
| 01:16 | <Hixie> | i guess it would "end" when the whole resource was obtained |
| 01:16 | <Hixie> | which might be immediately if the resource is cached |
| 01:16 | <roc> | MediaStreams end when they will no longer produce any new data |
| 01:17 | <Hixie> | right |
| 01:17 | <roc> | the MediaStream for a resource ends when we've finished playing it back |
| 01:17 | <Hixie> | so a MediaStream of a finite resource that happens to be already cached would end immediately after providing all the data to whatever consumer exists |
| 01:17 | <roc> | MediaStreams play back in real time, they can't instantly deliver all their data to some consumer |
| 01:18 | <Hixie> | oh |
| 01:18 | <roc> | at least, the way I understand it |
| 01:18 | <Hixie> | well then it doesn't make much sense to get one for a static resource |
| 01:18 | <Hixie> | surely |
| 01:18 | <roc> | sure it does |
| 01:18 | <Hixie> | what if the user wants to fast-forward? |
| 01:19 | <Hixie> | it'd be really weird to tell the user that he can pause, rewind, etc, but he can't fast-forward ahead of where the mediastream happens to have reached |
| 01:19 | <roc> | you can't fast-forward a MediaStream |
| 01:19 | <roc> | you can pause, but not rewind |
| 01:19 | <Hixie> | especially if the user just gave you the File in question |
| 01:20 | <roc> | if the user just gave you a File then you can make a BlobURL and just play that |
| 01:20 | <roc> | MediaStreams need not be involved |
| 01:20 | <roc> | and then you can do everything |
| 01:21 | <roc> | defining a media processing graph where you can control the playback rate of individual streams gets very problematic |
| 01:21 | <Hixie> | well to answer your original question, i think if mediastream represents live data and only live data, and you create one from an HTMLMediaElement, it should represent whatever frame/audio is currently playing |
| 01:21 | <Hixie> | and it shouldn't ever "end" |
| 01:22 | <roc> | (you end up being able to consume a single stream at different rates, and therefore at different time offsets, which is not really implementable) |
| 01:22 | <roc> | ok |
| 01:23 | <roc> | then we'll need a separate API to create a MediaStream for a resource that ends when the resource playback ends |
| 01:23 | <roc> | any suggestions on where that should lvie? |
| 01:23 | <Hixie> | what's the use case for that one? |
| 01:23 | <roc> | because if it doesn't live on the media element, then we have to duplicate all the source selection logic and probably more, which would really suck |
| 01:24 | <Hixie> | why wouldn't you just create an HTMLMediaElement that the user can't mess with, and use that to feed the MediaStream? |
| 01:24 | <roc> | I can do that I guess |
| 01:24 | <roc> | then I have to add an API somewhere to forcibly end the stream |
| 01:25 | <Hixie> | MediaStream.end() |
| 01:25 | <roc> | people want to add features that trigger when streams end |
| 01:25 | <roc> | OK |
| 01:25 | <Hixie> | if it's the kind of feature where precise timing matters, i guess you could just create a MediaStream from a fixed URL, and screw the source selection stuff |
| 01:26 | <roc> | precise timing is not really an issue |
| 01:26 | <Hixie> | if someone needs to pick a source, they can create a <video> and have it do the source selection and then use the result from that |
| 01:26 | <roc> | that's a bit ugly |
| 01:26 | <Hixie> | not the most efficient, certainly |
| 01:26 | <Hixie> | what kind of thing are we triggering on end? |
| 01:27 | <TabAtkins> | Hmm. <http://jsfiddle.net/leaverou/e77P2/>; shows a style element being disabled, and then it gets automatically reenabled when you set .textContent on it. Is that supposed to happen? |
| 01:27 | <roc> | disconnecting the stream from downstream mixers, for example |
| 01:27 | <Hixie> | roc: oh if it's just cleanup then yeah, i'd go with an explicit .end(). |
| 01:27 | <Hixie> | ok i gotta go, bbl |
| 01:27 | <roc> | ta |
| 03:28 | <jarek> | what is the more efficient way to convert DOM tree into string (with all HTML tags stripped)? |
| 03:28 | <jarek> | I have created a new range that wraps the whole tree, then I do: |
| 03:29 | <jarek> | myRange.toString() |
| 03:29 | <jarek> | but it strips all new lines |
| 03:30 | <annevk> | that sounds like a bug... |
| 03:31 | <annevk> | only Selection should do that |
| 03:31 | <jarek> | http://stackoverflow.com/questions/1146730/problem-detecting-newlines-in-javascript-range-object |
| 03:32 | <jarek> | the poster says this behavior could be reproduced on all major browsers |
| 03:32 | <jarek> | (I have checked only Chrome) |
| 03:33 | <jarek> | no, wait... he is using getSelection() method |
| 03:34 | <annevk> | hmm, I thought only Selection.toString() was affected by this |
| 03:34 | <annevk> | but maybe it normalizes its Ranges somehow, that sound weird |
| 03:34 | <annevk> | AryehGregor would prolly know |
| 03:35 | <jarek> | annevk: the specification does not say anything about how new lines should be handled |
| 03:35 | <jarek> | I would expect them to be preserved |
| 03:35 | <Hixie> | jarek: element.textContent |
| 03:37 | <jarek> | Hixie: thanks, exactly what I needed |
| 04:26 | <annevk> | Hixie, is the whitespace thing clear now? |
| 04:26 | <annevk> | Hixie, note that cue text tokenizing uses a different notion of whitespace (there's a bug on that too) |
| 04:35 | <annevk> | paul_irish_, querySelectorAll is not discussed on a WHATWG list, it's discussed on public-webapps |
| 05:05 | <Hixie> | annevk: that part of the parser can never hit a newline, because it is parsing a string that was created by collecting characters that aren't newlines |
| 05:05 | <annevk> | except for FF |
| 05:06 | <annevk> | there's 5 white space characters and you only work with 4 of them |
| 05:06 | <Hixie> | oh right |
| 05:06 | <Hixie> | you confused me with your talk of newlines |
| 05:06 | <annevk> | I think that was sylvia |
| 05:07 | <annevk> | nm |
| 05:07 | <Hixie> | aah, indeed |
| 05:07 | <Hixie> | sorry about that |
| 05:07 | <Hixie> | hmmm |
| 05:08 | <Hixie> | looking at this i think it would just be confusing to list FF as an allowed character |
| 05:08 | <Hixie> | i think it's the right thing to do to be consistent in the parsing, but not much point allowing it |
| 05:08 | <Hixie> | any opinions? |
| 05:08 | <annevk> | that works for me |
| 05:09 | <annevk> | are you willing to annotate the parser section at some point btw with things that are conformance errors? |
| 05:09 | <annevk> | that'd be so much more useful |
| 05:09 | <Hixie> | i saw the bug about it |
| 05:09 | <Hixie> | i dunno |
| 05:09 | <Hixie> | is it really worth it? |
| 05:09 | <Hixie> | for html it made sense because the parsing is so messed up |
| 05:09 | <annevk> | for http://quuz.org/webvtt/ yes |
| 05:09 | <Hixie> | that you really need to implement it to do conformance checking |
| 05:09 | <Hixie> | but webvtt is so simple in comparison... |
| 05:10 | <annevk> | still you need to figure out the differences which is kind of awkard |
| 05:10 | <Hixie> | yeah |
| 05:10 | <annevk> | I can imagine browsers also want to say things in their error console |
| 05:10 | <annevk> | the syntax section is useful for authors I guess |
| 05:10 | <annevk> | but the parser section is used by everyone else I'd imagine |
| 05:10 | <Hixie> | it's kind of a pain to add though |
| 05:11 | <Hixie> | i would imagine most syntax checkers would just be implemented as regexp or bnf-like things |
| 05:11 | <Hixie> | you wouldn't want to write a parser, surely |
| 05:11 | <annevk> | I wrote a parser to give better error messages |
| 05:11 | <annevk> | I could at some point also highlight the errors in the input stream this way |
| 05:12 | <annevk> | and you can report multiple errors |
| 05:12 | <annevk> | not just the first instance |
| 05:13 | <Hixie> | i dunno, just doesn't seem that hard to find the errors even if you do the parser by hand |
| 05:13 | <Hixie> | whereas updating the spec to list all the places will mean bugs in the spec all over the place, which confuses people, makes the parser look more complicated than necessary... |
| 05:14 | <Hixie> | i don't think i would have done it for html were it not for the way html is just ridiculously complicated to parse |
| 05:17 | <annevk> | okay that is fair I guess and it is not too hard, just might miss a lot of things |
| 05:17 | <annevk> | and if you want to simplify the parser, pre-process CRLF like you do with zero bytes |
| 05:18 | <Hixie> | yeah, i should do something like that |
| 05:18 | <Hixie> | foolip suggested it already once |
| 05:18 | <annevk> | I also wanted to say that you yourself once said that writing a good validator requires custom code and cannot be done by schema. Even if you're no longer convinced of that I very much think it's true |
| 05:18 | <Hixie> | for writing a good validator for HTML that is certainly true |
| 05:18 | <Hixie> | it's not true for everything |
| 05:19 | <Hixie> | if the language is sane and regular, that's what regular languages are for :-) |
| 05:19 | <Hixie> | it rarely works well for XML languages because it is so trivially easy to make an XML language too complicated to sanely describe in a schema |
| 05:19 | <annevk> | WebVTT is not that regular, it's a lot of different syntaxes compounded :) |
| 05:20 | <Hixie> | regular in this sense http://en.wikipedia.org/wiki/Regular_language |
| 05:20 | <Hixie> | though i've no idea what "it is the preimage of a subset of a finite monoid under a homomorphism from the free monoid on its alphabet" means |
| 05:21 | <annevk> | "it can be defined in monadic second-order logic" makes total sense |
| 05:21 | <Hixie> | man the math and theoretical CS parts of wikipedia are so opaque |
| 05:21 | <Hixie> | anyway |
| 05:21 | <Hixie> | i didn't just mean "simple" :-) |
| 05:22 | <annevk> | fair enough |
| 05:22 | <Hixie> | validating the cue text part probably wouldn't be sane with regexp-like tech |
| 05:23 | <erlehmann> | nothing is sane with regexes |
| 05:23 | <annevk> | I guess once I've fixed some more of the bugs my validator, people can use that to write new validators if they desire |
| 05:24 | <annevk> | or at least look up the error conditions |
| 05:28 | <erlehmann> | Ḫ̣̩e̞̺ ̮̣w͎̬̰h̼̜͉̹̳͉͙͚o̮̬̜̟̞ ͙̻W̩̮̪̝a̖̩̣͍̠̜̯̮̺i̱͇̼̗t͎͇̘͖̼͖͈͕ͅs̹̲͎̝̳ ͎̬͔B̟͎̯͔̮͕̰͉ͅe̞̦̭̗͎̩͎̯h͙̳͍̖͚̳i͈̝͔ṋ̭̜d̰͉͇̳̖̩̻̞ ͔̳̝̰̭͍ͅT̳̰̦̺̩̜̳̖h͎̩̜̞̬̬̻̖e̪͕͇̻̺̱ ̘R͕̯̮̩̺e͇̺g̱ẹ̖x͓͇.̟ |
| 05:28 | <erlehmann> | ZALGO! |
| 05:28 | <Hixie> | oh dear |
| 05:40 | <Hixie> | any opinions on http://www.w3.org/Bugs/Public/show_bug.cgi?id=14101 ? (queuing a task to fire an event on <details> when open="" is added or removed) |
| 06:19 | <zewt> | feels like people are selectively reading threads, heh |
| 06:20 | <zewt> | <me> do X <me> do X <sicking> do X <other people> thanks sicking |
| 06:48 | <nessy> | offff! glad that newline change to WebVTT time specs didn't get included - that just didn't feel right |
| 06:50 | <annevk> | newline change? |
| 06:50 | <annevk> | form feed is just some weird whitespace character |
| 06:50 | <annevk> | we decided it would still be parsed as whitespace, but would not be conforming |
| 06:52 | <annevk> | Hixie, seems like a good idea |
| 06:52 | <annevk> | Hixie, otherwise you have synchronous mutation events |
| 08:23 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=14210 do we want "http://foo bar" to be a resolvable url? |
| 08:27 | <mkanat> | zcorpan: It would seem that the last comment indicates so, no? |
| 08:33 | <annevk> | I guess I don't really care |
| 08:33 | <annevk> | but I would have to update XMLHttpRequest and maybe CORS if everything resolves |
| 08:33 | <annevk> | and we should really define URLs somewhere |
| 08:35 | <zcorpan> | maybe someone from mozilla cares about this |
| 08:38 | <annevk> | could ask the network guys |
| 08:38 | <annevk> | from Opera that is |
| 13:41 | <MikeSmith> | http://www.lemonodor.com/archives/images/dijkstra-quick-n-dirty.jpg |
| 13:42 | <MikeSmith> | http://blografia.net/vicm3/wp-content/uploads/2011/10/doing-it-wrong1.jpg |
| 14:28 | <jgraham> | http://blog.jquery.com/2011/10/24/announcing-the-jquery-standards-team/ - with the word "sub-team" appearing in the first sentence, these people are clearly ahead of the game |
| 14:28 | <jgraham> | I suggest that the subteam be further split into task forces |
| 14:30 | <annevk> | is this the new http://www.css11.navy.mil/ ? |
| 14:30 | <annevk> | they never did anything either |
| 14:31 | <zcorpan> | jgraham: i think you have misunderstood. you don't split subteams into task forces. you introduce task forces for each pair of subteams. |
| 14:32 | <annevk> | doesn't that depend on the chair? |
| 14:32 | <jgraham> | zcorpan: You do both, afaict |
| 14:32 | <Philip`> | But how will the task forces coordinate with each other, unless you set up a task subforce for each pair of task forces? |
| 14:32 | <zcorpan> | use the force |
| 14:33 | <annevk> | and extra mailing lists |
| 14:33 | <annevk> | one can never have enough mailing lists |
| 14:33 | <jgraham> | Philip`: It can all be neat as long as you have the number of top level task forces as a power of two |
| 14:34 | <jgraham> | Or, I guess that's not really how it works |
| 14:40 | <hsivonen> | annevk: awesome URL for css11 |
| 14:40 | <miketaylr> | i'm tempted to call the EMO office at http://www.css11.navy.mil/Contact.htm |
| 14:42 | <hasather> | miketaylr: this is him: http://a4.l3-images.myspacecdn.com/images02/129/82213099634047f79eb60293e6b17156/l.jpg |
| 14:42 | <miketaylr> | D: |
| 14:42 | <miketaylr> | maybe i won't then... |
| 14:48 | <karlcow> | maybe the two subteams parts have confidence on the pillow. (Pardon my French) |
| 15:04 | jgraham | wonders what pillows have to do with anything |
| 15:05 | <hsivonen> | is there a spec for parsing HTTP headers? |
| 15:06 | <hsivonen> | in particular, is the a parsing spec for the Content-Type header? |
| 15:11 | <karlcow> | jgraham: it is because you are not French. anythni |
| 15:11 | <karlcow> | ooops |
| 15:12 | <karlcow> | anything which needs coordination, resolution in France goes on a trajectory which crosses a bed at a point in time. |
| 15:13 | <jgraham> | Politics is obviously more sexy in France |
| 15:13 | <karlcow> | jgraham: definitely :) |
| 15:15 | <kennyluck> | Everytime I see something like "The reality is that whilst many of us would like to see change, due to … lengthy formal processes", I get angry. |
| 15:15 | <zewt> | the word "whilst" automatically makes me take someone less seriously |
| 15:23 | <broquaint> | Where do the docs for the URL API mentioned in this change live? http://html5.org/tools/web-apps-tracker?from=6744&to=6745 |
| 15:24 | <miketaylr> | https://github.com/abarth/url-spec ? |
| 15:26 | <broquaint> | Thanks, miketaylr :) |
| 15:26 | <miketaylr> | np |
| 15:27 | <karlcow> | kennyluck: yup, it seems like there is a magical process which shorten agreements in distributed communities. |
| 15:28 | <karlcow> | more exactly it shows a poor understanding of what are communities and their social dynamics. |
| 15:32 | <zewt> | formal processes != social dynamics, heh |
| 16:35 | <hsivonen> | MikeSmith: I pushed the html parser patch. |
| 16:50 | <dglazkov> | good morning, Whatwg! |
| 17:10 | <Ms2ger> | Evening, dglazkov |
| 17:11 | <Ms2ger> | broquaint, http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html |
| 17:12 | <miketaylr> | ah, better link |
| 17:16 | <broquaint> | Brilliant, thanks :) |
| 17:47 | <AryehGregor> | rniwa, thanks for the bug. |
| 17:47 | <rniwa> | AryehGregor: np |
| 17:48 | <zewt> | an unlikely thing to be thankful for |
| 17:48 | <AryehGregor> | jarek/annevk (in case you read logs), I don't think Range.toString() should do that, but I don't think I ever wrote tests for it, so I dunno how browsers actually behave. |
| 17:48 | <AryehGregor> | On reflection, my guess is that "strips all newlines" means "doesn't add newlines", i.e., <div>foo</div><div>bar</div> -> "foobar". This is expected behavior. |
| 17:49 | <AryehGregor> | At least, for spec writers. |
| 17:49 | <AryehGregor> | For authors, not so much. |
| 17:49 | <AryehGregor> | Oh well. |
| 17:50 | <AryehGregor> | Good grief, does Google Docs really have to advertise every little new not-even-deployed feature with an obnoxious popup when I visit it? |
| 17:50 | <AryehGregor> | Part of the reason I use Linux is to keep annoying unsolicited popups to a few per week max. |
| 18:28 | <paul_irish> | there isn't a standard for test cases is there? like standalone pages with pass/fail.. seems that everyone has their own setup, yah? |
| 18:31 | <miketaylr> | paul_irish: http://www.w3.org/html/wg/wiki/Testing/Authoring/ |
| 18:33 | <paul_irish> | thx |
| 18:36 | <rniwa> | AryehGregor: every developer thinks their feature is the best thing that happened to the world |
| 18:36 | <rniwa> | it's hard to convince them his/her feature is not worthly of a big giant popup i guess |
| 19:30 | <Hixie> | smaug____: re http://www.w3.org/Bugs/Public/show_bug.cgi?id=14534 - what if there's no documentElement? |
| 19:30 | <Hixie> | smaug____: shouldn't we just target the Document if there's no body? |
| 19:30 | <Ms2ger> | Crash |
| 19:31 | <smaug____> | Hixie: just a second, testing.. |
| 19:31 | <Hixie> | if you have a test case i can poke at, that would be great |
| 19:31 | <smaug____> | Hixie: and currently implementation target documentElement if there is no body |
| 19:31 | <smaug____> | implementations |
| 19:32 | <Hixie> | IE/opera/mozilla/webkit ? |
| 19:32 | <Hixie> | wow |
| 19:32 | <Hixie> | well if there's interop who am i to argue, i guess |
| 19:33 | <smaug____> | Hixie: I just uploaded a patch to make Gecko to work like IE9 and Webkit |
| 19:33 | <smaug____> | Opera had still some issues with my test case |
| 19:33 | <smaug____> | but let me test |
| 19:33 | <Hixie> | looks like webkit doesn't fire the event in the no-dE case |
| 19:35 | <Hixie> | yeah i can't get opera to remove the body or html nodes |
| 19:36 | <smaug____> | you can remove body in opera |
| 19:37 | <Hixie> | as soon as i do, a new one replaces it |
| 19:37 | <Hixie> | oh, that's only while parsing |
| 19:37 | <Hixie> | ok, onload i can remove it |
| 19:37 | <smaug____> | oh, removing root has strange effects in Opera |
| 19:37 | <smaug____> | the ui isn't updated, but event handling breaks down or something |
| 19:38 | <Hixie> | i don't get any events if there's no body |
| 19:38 | <Hixie> | similar to what the other browsers do when there's no root element |
| 19:38 | <Hixie> | so i guess they're just sending the events to the body element or nowhere |
| 19:38 | <Hixie> | whereas webkit sends it to the body element or the root element or nowhere |
| 19:38 | <Hixie> | haven't tested IE, don't have it easily accessible right now |
| 19:38 | <Hixie> | ok |
| 19:39 | <Hixie> | i guess i'll spec that the order of precedence is activeElement, body, root element, nowhere |
| 19:39 | <Hixie> | sound right? |
| 19:39 | <smaug____> | sounds right |
| 19:39 | <smaug____> | that is how gecko and webkit works now, and I think also IE9 |
| 19:39 | <Hixie> | k |
| 19:39 | <smaug____> | though I haven't tested the nowhere case in it |
| 19:46 | <AryehGregor> | Opera's DOM handling is just generally messed up. |
| 19:46 | <AryehGregor> | It also behaves very strangely with doctype nodes, I've found. |
| 19:47 | <smaug____> | Hixie: just curious, has there ever been talk about reviewing spec changes before changing the spec? |
| 19:47 | <smaug____> | similar to how software/code development happens |
| 19:47 | <Hixie> | there's been talk, but since nobody is willing to review the changes at the rate i make them, it wouldn't really work |
| 19:47 | <smaug____> | are you sure it wouldn't work? |
| 19:48 | <Hixie> | have you seen the rate at which i make changes? |
| 19:48 | <AryehGregor> | Also, no one but Hixie actually understands more than about half the spec. |
| 19:48 | <Ms2ger> | Does Hixie? |
| 19:48 | <smaug____> | AryehGregor: that is no good argument. |
| 19:48 | <AryehGregor> | smaug____, well, it's really a matter of resources. We have *very* few people willing to put much time into spec editing. |
| 19:49 | <smaug____> | I do understand most of Gecko's event handling, yet I do want someone to review my patches |
| 19:49 | <Hixie> | i don't really see how it would be better to do review-then-commit instead of commit-then-review, anyway |
| 19:49 | <smaug____> | AryehGregor: I know, it is a problem to have so few having time for spec editing |
| 19:49 | <AryehGregor> | smaug____, if implementers devoted more resources to it, we might have the capacity to do more review. But as it stands, we don't have enough people to write the specs in the first place. |
| 19:49 | <smaug____> | but reviewing is different thing |
| 19:49 | <Hixie> | in practice the patches do get reviewed, and when there's a problem, it's reverted pretty quickly. |
| 19:49 | <AryehGregor> | smaug____, there is a mailing list that all the changes get posted to, but no way for people to sign off on them. |
| 19:50 | <michaelw> | Hixie: a proposed/stable split wouldn't be bad, IMO |
| 19:50 | <AryehGregor> | If someone wanted to make a system that let people mark diffs as reviewed or approved or whatever, I'm sure no one would expect. |
| 19:50 | <AryehGregor> | michaelw, then you have to deal with merges. |
| 19:50 | <Hixie> | michaelw: yeah, that's been suggested |
| 19:50 | <AryehGregor> | Since Hixie still uses SVN . . . :) |
| 19:50 | <Hixie> | michaelw: nobody's volunteered to maintain that either :-) |
| 19:51 | <michaelw> | AryehGregor: why is that a problem? that's how much software development works... |
| 19:51 | <Hixie> | smaug____: what might make sense is to have two trees, and to have one be what i edit, and another be what i edit but only with the patches up to the oldest not-reviewed patch |
| 19:51 | <AryehGregor> | michaelw, if it has enough resources, sure. |
| 19:51 | <Hixie> | smaug____: we could automate that that pretty well |
| 19:51 | <AryehGregor> | Also, the spec automatically gets review before implementation, because the implementers review it to some degree. |
| 19:51 | <smaug____> | Hixie: in software development review-then-commit has so far been better than the opposite |
| 19:51 | <Hixie> | smaug____: so people could look at the patches, and if they ok them, the tree moves on |
| 19:52 | AryehGregor | agrees that review-then-commit works better, but *only* if you have suitable review resources |
| 19:52 | <Hixie> | smaug____: software development has some key differences: there's multiple checking in, and it matters if the code doesn't compile |
| 19:52 | <AryehGregor> | If you don't have enough review resources to promptly review every revision, review-then-commit simply doesn't work. |
| 19:52 | <michaelw> | Hixie: from experience, the overhead is little. you would commit to a "proposed" branch, and when people sign-off of a commit, or there has been no outcry, you merge every now and then |
| 19:52 | <Hixie> | michaelw: if you're willing to do the "sign-off of a commit, or there has been no outcry, you merge every now and then" part, go for it |
| 19:52 | <smaug____> | AryehGregor: we haven't even tried the "review-before-commit" approach for HTML spec, or WebApps WG specs |
| 19:53 | <zewt> | nothin' like more layers of procedure |
| 19:53 | <smaug____> | AryehGregor: have you tried implementing anything from spec drafts. It is quite frustrating that you know even before reading the spec that it will have bugs which need to be fixed before implementing it |
| 19:54 | <Hixie> | basically at the moment we could add review-then-commit or proposed/stable as a trivial layer on top of what we have now, without it affecting me at all |
| 19:54 | <Hixie> | so anyone who wants to do either of those should just set it up |
| 19:54 | <Hixie> | smaug____: that applies to all specs |
| 19:54 | <michaelw> | Hixie: actually, I might, a bit later this year. have to convince $COMPANY to allocate resources |
| 19:55 | <Hixie> | michaelw: cool. it would be awesome to have a more stable branch. |
| 19:55 | <zewt> | smaug: heh, well, trying to reliably find bugs in a spec without implementing it is like trying to find bugs in source without compiling it |
| 19:56 | <michaelw> | zewt: good observation, hence that's what I'm doing :) |
| 19:57 | <smaug____> | Hixie: if http://twitter.com/#!/WHATWG shows all the changes to HTML spec, it isn't *that* many changes per day |
| 19:57 | <smaug____> | there sure are several possible reviewers |
| 19:57 | <zewt> | michaelw: reviewing a spec change by eye is not testing it in the same way as compiling and testing a code change |
| 19:57 | <smaug____> | and most of the changes, I hope, would be trivial to review |
| 19:57 | <zewt> | you'll find more bugs than one pair of eyes, of course |
| 19:57 | <Hixie> | smaug____: nothing is stopping you from setting it up. do it! :-) i'm certainly all for more review. |
| 19:58 | <smaug____> | Hixie: so, would you upload patches to bugzilla for each patch :) |
| 19:58 | <zewt> | but you won't fix the "implementing a draft spec finds bugs" problem, any more than you can fix the "your code doesn't compile on the first attempt" "problem" :) |
| 19:58 | <Hixie> | smaug____: no, i'd just check them into svn, and that would be my working copy, and the reviewed copy would be a separate tree |
| 19:59 | <smaug____> | well, how could I see the patch then |
| 19:59 | <Hixie> | smaug____: http://html5.org/tools/web-apps-tracker lists them |
| 19:59 | <smaug____> | I hope there is some better tool for svn |
| 20:00 | <Hixie> | well it's an open svn repo so any tool you like can do it |
| 20:00 | <zewt> | sort of seems like the case for git |
| 20:00 | <zewt> | not that i'd argue heavily for git (i use it, but ... it's cranky) |
| 20:02 | <zewt> | has anyone implemented BlobBuilder at all? (it's not in FF6 or Chrome stable) |
| 20:04 | <smaug____> | zewt: it is in FF |
| 20:04 | <smaug____> | Moz prefixed, IIRC |
| 20:04 | <smaug____> | zewt: isn't FF6 kind of ol |
| 20:04 | <smaug____> | d |
| 20:05 | <zewt> | dunno, the "new version every 3 hours" thing gets tiresome |
| 20:05 | <Ms2ger> | Chrome stable, you mean? |
| 20:05 | <smaug____> | zewt: https://bugzilla.mozilla.org/show_bug.cgi?id=648997 |
| 20:05 | <smaug____> | that says FF6 |
| 20:06 | <zewt> | (and it'll be a long time before I'm willing to trust Firefox to autoupdate, I always back up my profile, make sure extensions still work, etc. before committing) |
| 20:06 | <zewt> | k |
| 20:06 | Ms2ger | shrugs |
| 20:18 | <_bga> | http://plan9.bell-labs.com/plan9/img/mirtchov/plan9-normal.png << Opera & plan9 |
| 20:21 | <Hixie> | blimey there's a lot of <track> bugs. ok, guess i know what i'm doing this afternoon. |
| 20:21 | <Ms2ger> | Emails? :) |
| 20:22 | <Hixie> | soon, soon. |
| 20:22 | <Hixie> | i'm at record low numbers of bugs |
| 20:22 | <Hixie> | record in like a year |
| 20:24 | <smaug____> | time to file some more bugs :) |
| 20:24 | <Hixie> | noooooo |
| 20:24 | <Hixie> | at some point soon i'm going to switch back to e-mail |
| 20:25 | <Ms2ger> | Then we'd better get in our bugs before that |
| 20:26 | <Hixie> | just don't file a bug that's too much work, cos that will then make me switch early :-) |
| 21:01 | <jgraham> | Hmm, we can't even manage review-then-commit for testcases and they are updated *way* less often than the spec |
| 21:02 | <jgraham> | And not only will the tools not save us, they don't even exist |
| 21:02 | <jgraham> | Seriously, there are like 0 good code review tools for mercurial and 0 I have seen for svn |
| 21:03 | <jgraham> | I don't know how people cope |
| 21:03 | <jgraham> | Are they all emailing patches around or something? |
| 21:03 | AryehGregor | cough git cough |
| 21:03 | <jgraham> | git has one code review tool which might be good |
| 21:04 | <zcorpan> | foolip: maybe supporting comments in cue data is a bad idea, regardless of syntax |
| 21:04 | <jgraham> | In that I have heard it is a bit like the rather excellent homebrew thing we use at opera |
| 21:28 | <zewt> | maybe the spec comment form should throw away inputs with no vowels, heh |
| 21:39 | <zcorpan> | zewt: Hixie accepts patches :) |
| 21:39 | <zcorpan> | zewt: i had an idea the other week about counting keystrokes to prevent bugs where the reporter pasted something |
| 21:40 | <zcorpan> | but didn't look into implementing that |
| 21:52 | <TabAtkins> | One helpful change would be to auto-reject things that have a significant portion of the instructions for submitting a bug (or the introduction text in general). Those make up a decent chunk of the junk bugs. |
| 21:52 | <TabAtkins> | You could probably do a really simple entropy analysis to find the keyboard-mashing junk bugs, too. |
| 21:54 | <zewt> | zcorpan: well, i'm not the one that has to spend time cleaning them up :) |
| 22:33 | <zewt> | so tired of the ridiculous "encryption is useless without a trusted certificate" from people who should know better |
| 22:35 | <_bga> | trusted certificate is another way to get your money |
| 22:35 | <zewt> | that's a separate issue, heh |
| 22:40 | <abarth> | Hixie: http://html.spec.whatwg.org/ has broken images and is missing the style sheet |
| 22:41 | <zcorpan> | hsivonen: afaik, the answer is "no" (re content-type header parsing) |
| 22:43 | <Hixie> | abarth: yeah, that url isn |
| 22:43 | <Hixie> | 't live yet |
| 22:43 | <abarth> | ah |
| 22:43 | <abarth> | ok |
| 22:43 | <abarth> | what's the best way to hack into the Referer calculation in the spec |
| 22:44 | <abarth> | ? |
| 22:44 | <Hixie> | have me change it :-) |
| 22:44 | <abarth> | 2.7 Fetching resources ? |
| 22:44 | <abarth> | http://wiki.whatwg.org/wiki/Meta_referrer |
| 22:44 | <Hixie> | it happens in the "fetch" algorith, yeah |
| 22:44 | <abarth> | is the context |
| 22:44 | <abarth> | i'm trying to write the "semantics" section |
| 22:45 | <Hixie> | ah, i see |
| 22:45 | <Hixie> | ok |
| 22:45 | <Hixie> | hopld on |
| 22:46 | <zcorpan> | abarth: what's the difference between default and always? (use case for always?) |
| 22:47 | <Hixie> | zcorpan: https |
| 22:47 | <abarth> | zcorpan: suppose you want to move your search engine over to HTTPS but folks are sad that they don't get referrers anymore |
| 22:47 | <Hixie> | abarth: ok yeah. You'd override step 3 (I recommend just giving an entirely new replacement text), and then providing a replacement for the relevant paragraph in step 4 |
| 22:47 | <zcorpan> | aha |
| 22:48 | <abarth> | Hixie: ok, I didn't see the HTTPS -> HTTP supression there, but maybe i need to override that from HTTP |
| 22:48 | <Hixie> | abarth: you might also need something in the HTTP spec, i think that may be where that is, yeah |
| 22:48 | <abarth> | ok |
| 22:48 | <abarth> | i think techincally its illegal in HTTP to send the origin in the Referer header |
| 22:48 | <abarth> | but Firefox has had an option to do that for a while |
| 22:49 | <zcorpan> | abarth: does origin act like default or like always? |
| 22:49 | <Hixie> | abarth: (if you don't find it there, add it to your new text, and if your new text doesn't end up in the spec for whatever reason, let me know and i'll fix the spec for that particular part of it anyway) |
| 22:49 | <abarth> | ok |
| 23:03 | <Hixie> | abarth: you want to replace the text of step 3 in all cases, and have the text examine the state of the (first/last) meta header |
| 23:03 | <Hixie> | abarth: you can't exactly have the user agent be required to change the spec based on the state of a meta header each time it loads a page :-P |
| 23:03 | <abarth> | ok |
| 23:03 | <abarth> | which meta header usually controls? |
| 23:03 | <abarth> | meta element |
| 23:03 | <abarth> | rather |
| 23:03 | <abarth> | (the first or the last) |
| 23:04 | <Hixie> | this is a meta name="" value? |
| 23:04 | <Hixie> | looks like none of the existing meta name values have UA requirements |
| 23:05 | <Hixie> | abarth: for http-equiv, looks like there's a slight preference for first-wins |
| 23:05 | <Hixie> | of course, <base> is last-wins |
| 23:50 | <michaelw> | after "e.onload = f;" (f being a valid function object), what should e.getAttribute("onload"); return? |
