| 00:38 | <TabAtkins> | Oh jeez, they had to use the one frame where I look like a drunk hobo as the poster: http://blog.siliconvalley-codecamp.com/2010/10/12/presentation-horror-stories/ |
| 00:40 | <hober> | anyone going to AEA San Diego? |
| 00:46 | <peterhil> | Good article on Ars Technica about mobile advertising company using html 5 local storage to create a really persistent database on iOS devices: http://arstechnica.com/apple/news/2010/09/rldguid-tracking-cookies-in-safari-database-form.ars |
| 00:48 | <TabAtkins> | Yeah, that's probably exploiting the same combination of tracking devices as the supercookie. |
| 00:56 | <peterhil> | Probably |
| 02:35 | <heycam> | is microdata implemented anywhere yet? |
| 02:38 | <heycam> | that reminds me, i really should watch The Castle |
| 02:38 | <boogyman> | good movie |
| 02:38 | <heycam> | supposedly :) |
| 04:04 | <Hixie> | heycam: google search supports it, dunno about others |
| 04:04 | <heycam> | k |
| 04:05 | <heycam> | just wondering about it from the DOM perspective, though |
| 04:08 | <paul_irish> | last i heard getItems hasnt landed anywhere yet. |
| 04:19 | <Hixie> | heycam: not aware of any dom implementations yet |
| 09:17 | <annevk> | from the IRI meeting |
| 09:18 | <annevk> | "4. Next steps: Larry: let's see if we can get more attendees & agenda items for next interim meeting." |
| 09:20 | <zcorpan> | sounds like a useful meeting |
| 09:20 | <Hixie> | aren't they all |
| 09:21 | <Hixie> | zcorpan: re http://www.w3.org/Bugs/Public/show_bug.cgi?id=10419#c7 , value->defaultValue has proven really unpopular, which is why i am skeptical of doing it for that one |
| 09:21 | <Hixie> | what i really want is an attribute where we can stick all the "initial state" stuff |
| 09:21 | <Hixie> | default playback rate, volume, muted... except only support muted for now |
| 09:22 | <Hixie> | i guess autoplay is already its own thing |
| 09:22 | <Hixie> | and automute doesn't really sound right |
| 09:23 | <zcorpan> | i dunno, having to type defaultmuted="" defaultvolume="0.5" defaultplaybackrate="2" seems more annoying than muted="" volume="0.5" playbackrate="2" |
| 09:23 | <Hixie> | i agree |
| 09:23 | <Hixie> | not sure what to do |
| 09:23 | <zcorpan> | pointers to defaultValue unpopularity? |
| 09:23 | <zcorpan> | (would it be less unpopular if the attribute was called defaultvalue=""?) |
| 09:24 | <Hixie> | search for "The HTML DOM got this very wrong" in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028755.html |
| 09:25 | <Hixie> | it would be less unpopular with sicking if value="" was the default value and editing muted the DOM |
| 09:25 | <Hixie> | i'm not personally convinced that's great either though |
| 09:25 | <Hixie> | mutated |
| 09:25 | <Hixie> | not muted :-) |
| 09:27 | <Hixie> | the other thing is that this isn't an attribute whose values are "muted" and "not muted", it's an attribute whose values are "mute initially in all cases" and "use the user's default for this video" |
| 09:27 | <zcorpan> | foolip: what do you think? ^ |
| 09:27 | <Hixie> | so "muted" isn't necessarily the most obvious name |
| 09:27 | <Hixie> | it should also be pointed out that a lot of people don't think we should have the mute/volume state be remembered on a per-video basis |
| 09:28 | <zcorpan> | from the author's perspective, he mutes the video if he adds the attribute |
| 09:28 | <Hixie> | and that instead we should have a browser-level mute (maybe per tab) that can't be controlled by JS, and that video.muted should only be the author override for the video |
| 09:29 | <zcorpan> | sure |
| 09:29 | <Hixie> | but that would make the video's mute indicator and the system mute indicator not be the only indicators of relevance, instead adding at least one more to the mix |
| 09:29 | <annevk> | it seems end users would want to mute a video, but not necessarily want to unmute it |
| 09:29 | <Hixie> | which i'm not sure is a good idea |
| 09:29 | <Hixie> | end users? |
| 09:29 | <Hixie> | or authors? |
| 09:29 | <annevk> | so having muted just be an author thing seems fine to me |
| 09:30 | annevk | forgot .muted currently reflects the end user setting |
| 09:30 | <Hixie> | i almost never want videos muted personally, if i want audio off i want all audio off and turn it off at the system level |
| 09:30 | <annevk> | yeah me too |
| 09:30 | <annevk> | I think .muted should just turn into an author setting |
| 09:31 | <annevk> | like it is for Flash video as well |
| 09:31 | <Hixie> | i'd love a "this tab is a source of sound" indicator, but i don't think i care about turning the sound off at that level (though a shortcut to override all the <video> elements on the page in one go mighht be ok) |
| 09:31 | <annevk> | mute control on youtube can say it should give sound, but I often have it turned off system wide anyway |
| 09:31 | <Rik`> | sometimes, I want to mute manually |
| 09:31 | <Hixie> | i don't understand, are you saying that .muted should not reflect the muted indicator you get from controls=""? |
| 09:32 | <Rik`> | when a website is playing a sound and I can't figure out how to stop it |
| 09:33 | <Rik`> | I'd like browsers to provide some UI to find which tabs are currently playing some sound |
| 09:33 | <zcorpan> | Hixie: on a second thought, maybe it's not so bad to just mutate the dom |
| 09:34 | <annevk> | Hixie, I guess in that case mutating the DOM might be ok, though I am not sure |
| 09:35 | <annevk> | Hixie, for <details> UAs could remember the state too which would mutate the DOM |
| 09:35 | <Hixie> | i think mutating the dom would be really weird for the reason given by the CSS example I gave in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028755.html |
| 09:35 | <Hixie> | (that problem isn't such a big deal for <details>) |
| 09:36 | <zcorpan> | why is it weird? if the author wants special styling for muted videos, it makes sense to have video[muted] match when the video is muted |
| 09:36 | <annevk> | isn't it the same problem for <details>? |
| 09:37 | <annevk> | author assumes it is open/closed but it's the other way around based on earlier interaction (or maybe a preference/extension that expands all those controls by default) |
| 09:43 | <Hixie> | i would expect a difference because an author might have a bunch of muted videos that are always muted, and he uses that as a hook for styling them differently from the main video that isn't muted |
| 09:43 | <Hixie> | e.g. imagine if the small poster frames on a youtube page were all live <video>s |
| 09:43 | <Hixie> | muted ones |
| 09:43 | <Hixie> | and they were made small because all muted videos were small |
| 09:44 | <Hixie> | that's different than <details> and [open] because the most likely reason to style [open] is that you're trying to do something for when it's open vs when it's not |
| 09:44 | <Hixie> | but i agree that this argument is weak |
| 09:44 | <zcorpan> | it seems stupid to hook that styling off muted="", and anyway youtube would want to use a different video stream for those to save bandwidth, and could just remove the audio stream altogether and not bother with muted="" |
| 09:45 | <Hixie> | yeah i'm not saying it'd be a good idea |
| 09:46 | <zcorpan> | what if the author only has the main video and wants to style it specially when it's muted |
| 09:46 | <zcorpan> | we could introduce :muted for that, but having [muted] just work is simpler |
| 09:47 | <Hixie> | that argues for exposing the entire API in content attributes |
| 09:47 | <Hixie> | i'm not sure that's a reasonable line of argumentation |
| 09:47 | <zcorpan> | true |
| 09:48 | <Hixie> | fwiw, flash apparently makes a mess of this particular issue (muting by default), so they're not useful as inspiration here. |
| 09:49 | <annevk> | the styling would only be affected if the user agent remembered the muted settings, I wonder how likely such a scenario is |
| 09:50 | <zcorpan> | annevk: it seems like better user experience to remember the mute setting on reload |
| 09:51 | <annevk> | is it worth the trouble? |
| 09:52 | <annevk> | however, having muted and .defaultMuted also works for me |
| 09:53 | <Hixie> | zcorpan is right that defaultmuted="" is kinda ugly |
| 09:56 | <zcorpan> | annevk: remembering checkbox states is apparently worth the trouble |
| 09:57 | <zcorpan> | although a form taken together can take a long time to fill, while muting a video is trivial |
| 09:57 | <zcorpan> | so i dunno |
| 09:57 | <zcorpan> | i'm not an UX guy :) |
| 09:57 | <zcorpan> | s/an/a/ |
| 10:00 | <annevk> | Hixie, I meant following the <input value> design |
| 10:00 | <Hixie> | ah |
| 10:00 | <Hixie> | sicking would hate that |
| 10:00 | <annevk> | Hixie, sicking is right that it's not nice, but it would be internally consistent and somewhat predictable |
| 10:01 | <annevk> | and not give weird DOM stuff |
| 10:01 | Hixie | thinks that remembering mute state may be more important for some settings than remembering checked state, btw :-) |
| 10:01 | <annevk> | (though in the case of <details> it would require a pseudo-class of some kind to be introduced) |
| 10:01 | <Hixie> | yeah, <details> is kind of my experiment in this space |
| 10:01 | <Hixie> | i want to see what authors think of the straight-DOM-mutation design |
| 10:05 | <zcorpan> | seems bad to ship Hixie experiments with known bad design that are impossible to revert later on |
| 10:05 | <zcorpan> | if it is bad design |
| 10:05 | <zcorpan> | can't we already test this since some versions of ie mutate the dom? |
| 10:06 | <Hixie> | well it's not known bad, that's the point |
| 10:06 | <Hixie> | the IE experiment suggested it might be good, but was confused because authors were more annoyed with the lack of interop than either particular behaviour. |
| 10:09 | <zcorpan> | maybe we can get help from the html5 doctors here |
| 10:09 | <zcorpan> | post a simplequiz |
| 10:09 | <zcorpan> | Which Way Sucks Less? |
| 10:09 | <annevk> | might be interesting |
| 10:10 | zcorpan | summons the doctors |
| 10:10 | <Hixie> | that would certainly be interesting, but it's more the organic blog rants and how many pages use it and so on that i am interested in |
| 10:11 | <Hixie> | e.g. finding how many people use [open] vs how many people detect onopen and set a class or whatnot |
| 10:11 | <zcorpan> | that would be a function of what works in existing browsers |
| 10:11 | <Hixie> | yes |
| 10:12 | <Hixie> | it's a long-term experiment |
| 10:12 | <zcorpan> | so when we know the answer it's too late to change the feature |
| 10:12 | <Hixie> | yeah, <details> is stuck this way forever. |
| 10:13 | <Hixie> | the point is to find out the results for future ideas. |
| 10:13 | <annevk> | well, <details> is not stuck yet |
| 10:46 | <annevk> | hsivonen, how does the parser know the difference between network and document.write() characters? |
| 10:51 | <jgraham> | annevk: What are you reading? |
| 10:52 | <jgraham> | Presumably the "script nesting level" is non-zero when processing document.written characters |
| 10:53 | <annevk> | the <meta http-equiv> thing |
| 10:53 | <annevk> | that is a good point |
| 10:54 | <jgraham> | Bug 11013? |
| 10:54 | <Hixie> | not necessiraly |
| 10:54 | <Hixie> | necessarily |
| 10:55 | <Hixie> | consider document.write('<script src=""></script><meta ...>'); |
| 10:56 | <Hixie> | also note crazy things like <script>document.write('<script src=""></script><meta');</script> http-equiv="Content-Type" content="text/html;charset=gah"> |
| 10:56 | <hsivonen> | annevk: data that has come from document.write is in a different queue of buffers than data that has come from the network |
| 10:57 | <jgraham> | Well it isn't even clear to me what behaviour hsivonen wants for the latter case :) |
| 10:57 | <hsivonen> | annevk: when the parser parses the data and generates tree operations, the informantion about where the element came from is baked into the op code |
| 10:58 | <hsivonen> | jgraham: I want to ignore the meta if the > character that caused the token to be emitted came from document.write |
| 10:58 | <jgraham> | Hixie: Is there some clear explaination of the *point* of the script nesting level concept? I can follow things through the algorithm but I don't have an intuitive sense of why it is needed |
| 10:59 | <hsivonen> | in Hixie's document.write('<script src=""></script><meta ...>'); |
| 10:59 | <hsivonen> | example, the meta came from document.write |
| 10:59 | <hsivonen> | in Hixie's next example, it didn't |
| 10:59 | <annevk> | hsivonen, that sounds like implementation details |
| 11:00 | <hsivonen> | annevk: we're always speccing details |
| 11:00 | <jgraham> | For example I can't instantly see why the script nesting level would be 0 for the meta in the first example |
| 11:00 | <hsivonen> | annevk: I want my details to be specced so that I don't need to change anything |
| 11:00 | <annevk> | hsivonen, I guess I'm saying it would be nice to not have this one, but the "script nesting level" makes sense |
| 11:00 | <jgraham> | (I assume it would be 0 from context) |
| 11:00 | <Hixie> | jgraham: it's just used to keep track of when the parser should be unblocked in the case of the parser getting blocked during a re-entrant document.write() |
| 11:01 | <Hixie> | jgraham: e.g. if you document.write() a script that document.write()s an external script, the parser should not be unblocked by the second por third nested parsers, only the first (not-nested) parser. |
| 11:02 | <hsivonen> | Currently, Gecko doesn't differentiate between elements that originated from tokens that came from synchronous document.write tokenization and that came from asynchronous document.write tokenizations |
| 11:03 | jgraham | feels like a diagram would help here |
| 11:06 | <Hixie> | i just noticed that the description of http://www.w3.org/Bugs/Public/show_bug.cgi?id=11013 doesn't match the summary |
| 11:06 | <Hixie> | for the record, i don't read the summaries generally |
| 11:06 | <Hixie> | so please don't put important information in the summaries :-) |
| 11:07 | <Hixie> | (i similarly don't read subject lines in e-mails) |
| 11:08 | <Hixie> | ok bed time |
| 11:08 | <Hixie> | nn |
| 11:32 | <hsivonen> | ooh. Decisions. |
| 11:55 | <zcorpan> | Hixie: did you mean to have the link continue to the end of the paragraph in r5618? |
| 14:32 | <annevk> | oh, Simon is gone |
| 14:33 | <annevk> | zcorpan, if there's logs, it looked good otherwise |
| 14:40 | <annevk> | http://vimeo.com/15775937 -- howcome on CSS |
| 14:43 | <annevk> | kind a like that original World Wide Web slogan he shows |
| 14:43 | <annevk> | "you click, we do the rest!" |
| 14:48 | <annevk> | http://people.opera.com/howcome/2008/talks/tour/cern-2853749.jpg |
| 15:18 | <sean`> | a |
| 15:44 | <micheil> | annevk: is Greg Wilkins from opera? |
| 15:45 | <annevk> | no |
| 15:45 | <micheil> | (or rather, where is he from) |
| 15:45 | <micheil> | I can't recall. |
| 15:47 | <jgraham> | Presumably from Webtide ("the java experts behind jetty") |
| 15:47 | <micheil> | k |
| 15:47 | <jgraham> | http://www.webtide.com/about/management.jsp |
| 17:04 | <karlcow> | huh http://images.vizworld.com/wp-content/uploads/2010/05/Apple-Flash-Infographics.jpg |
| 17:29 | <annevk> | hmm, [Supplemental] does not work for constructor additions |
| 17:41 | <MikeSmith> | annevk: status on publications is that I have been traveling and I will attempt to get everything ready for publication on Thursday |
| 17:42 | <MikeSmith> | but if not, it will be next Tuesday instead |
| 17:46 | <annevk> | hey MikeSmith, wb then :) |
| 17:47 | <annevk> | should have realized you were away |
| 17:48 | <MikeSmith> | I'm going to be in and out this week as well |
| 17:48 | <MikeSmith> | I'm in Australia at the Web Directions South event |
| 17:48 | <annevk> | aah, good times |
| 17:48 | <MikeSmith> | and some other things around that |
| 17:48 | <annevk> | emailed you one question about TPAC |
| 17:48 | <MikeSmith> | yep |
| 17:48 | <MikeSmith> | just replied |
| 17:48 | <annevk> | kk |
| 17:49 | <annevk> | as far as I'm concerned publishing next week is fine |
| 17:49 | <annevk> | was just wondering what the holdup was |
| 17:52 | <MikeSmith> | holdup is me as usual :) |
| 18:16 | <othermaciej> | jgraham: looks like it got fixed |
| 18:30 | <Ms2ger> | Did Opera submit their WebSockets tests anywhere? |
| 18:40 | <annevk> | Ms2ger, they're up for grabs |
| 18:41 | <annevk> | Ms2ger, guess one of us ought to email public-webapps... |
| 19:13 | <jgraham> | Ms2ger: They often depend on th -76 protocol. Also they require pywebsockets which is not sutiable for public-facing servers |
| 19:14 | <jgraham> | So whilst we encourage people implemening -76 (really: -00) to use the tests, it's not clear that they are in a state where they should be submitted anywhere |
| 19:14 | micheil | should really get around to write the node.js powered websocket protocol tests. |
| 19:15 | <Ms2ger> | At least dump them on www-archive, then |
| 19:15 | <jgraham> | Sure, we can send a link to www-archive |
| 19:16 | jgraham | wishes for a bot to ask zcorpan to do that when he returns |
| 19:16 | jgraham | hopes that zcorpan reads the logs with bot-like diligence |
| 19:16 | <othermaciej> | the WebKit layout tests also have a bunch of WebSocket tests |
| 19:17 | <othermaciej> | (I am not sure how many would be useful as standards tests of the protocol) |
| 19:17 | <jgraham> | othermaciej: Presumably in specs-theory-land we curenly dn't want tests of the protocol, only of the API |
| 19:18 | <jgraham> | Of course it is hard to test the API without some assumptions about the protocol |
| 19:18 | <Ms2ger> | Presumably the point of the WHATWG was to get out of specs-theory-land |
| 19:19 | <jgraham> | right, and we made the tests public :) |
| 19:19 | Ms2ger | sends jgraham a cake |
| 19:20 | <jgraham> | I guess webapps can take the tests that we have and adapt them for the new protocol if it happens |
| 19:20 | <AryehGregor> | sicking, how could I provide a diff that takes me from one version of the patch to another, when there's no common base commit that both patches will apply to? |
| 19:21 | <AryehGregor> | (Also, do I have to do anything now on the bug, or someone else will handle everything and I can forget about it for now?) |
| 19:22 | micheil | is still of opinion that when we have a spec X vs spec Y discussion, there should be PoC's made and tested. |
| 19:23 | <sicking> | AryehGregor: add "checkin-needed" keyword |
| 19:23 | <sicking> | AryehGregor: for dealing with merge conflicts interdiffs are indeed hard to produce |
| 19:24 | <sicking> | AryehGregor: basically what you'd do in this case is: |
| 19:24 | <sicking> | 1. update to tip |
| 19:24 | <jgraham> | PoCs? I guess not Pieces of Cake, although I am avaliable to test cake if needed |
| 19:24 | <sicking> | 2. make necessary changes |
| 19:24 | <jgraham> | Depending on the provenance of said cake |
| 19:24 | <sicking> | 3. create a diff between code in 1 and 2 |
| 19:24 | <jgraham> | No horrible supermarket cake |
| 19:25 | <sicking> | AryehGregor: a good way to do 3, if you're using mq, is to push a new patch on the queue before you start with 2 |
| 19:25 | <micheil> | jgraham: proof-of-concept or proof-of-code |
| 19:25 | <AryehGregor> | What does "make necessary changes" mean? |
| 19:26 | <sicking> | AryehGregor: well, in this case no changes were needed |
| 19:26 | <Ms2ger> | Fix review comments, I guess |
| 19:26 | <sicking> | AryehGregor: but otherwise make whatever changes are needed to make things work on tip |
| 19:27 | <jgraham> | micheil: You are free to do that of course; don' feel you have to ask permission. And I encourage it; it would be very useful. Although it can't settle many interesting questions, like relative securiy properties or deployability on large scales |
| 19:27 | <AryehGregor> | sicking, so how is that different from just a new version of the patch? My v3 was just the same exact patch as v2 but with conflicts resolved. |
| 19:27 | <sicking> | AryehGregor: in this case simply answering "yes" to my question if the only thing you changed was to remove the HTMLObjectElement changes would have been enough :) |
| 19:27 | <AryehGregor> | Okay. |
| 19:28 | <micheil> | jgraham: true, but it'd weed out the specs that don't aid the protocol. |
| 19:29 | <jgraham> | micheil: I don' really know what you mean "don't aid the protocol" |
| 19:30 | <jgraham> | It might be helpful for answering certain specific questions |
| 19:30 | <micheil> | I'm not sure either there. I'm just saying that it'd be good to see something being done in code rather then just theory. |
| 19:31 | <jgraham> | But it's hard to see how to use it to assess the relative importance of obfuscating all user-supplied data for security vs making routing using extant HTTP infrastructure possible, for example |
| 19:31 | <jgraham> | Which is the current big issue |
| 19:32 | <jgraham> | Note that I am not trying o discourage you; making rough implementations of draft specs is one of my favourite ways to beter understand those specs |
| 19:35 | <micheil> | jgraham: well, I'll probably be implementing a -02 parse for packets soon. |
| 19:35 | <micheil> | just got big problems in my new -00 parser first. |
| 19:38 | <karlcow> | hmmm not interop for lastModified between browsers http://www.w3.org/TR/html5/dom.html#dom-document-lastmodified |
| 19:38 | <karlcow> | I tried on a page without LastModified defined at the HTTP level. |
| 19:38 | <karlcow> | javascript:alert(document.lastModified) |
| 19:38 | <karlcow> | Opera 10.63 - January 1, 1970 GMT |
| 19:38 | <karlcow> | Safari 5.0.2 - Nil |
| 19:38 | <karlcow> | Firefox 4.0b6 - 10/13/2010 14:36:31 (date of the cache) |
| 19:39 | <karlcow> | "If the last modification date and time are not known, the attribute must return the current date and time in the above format." |
| 19:42 | <lsxq> | what's the deal with motion jpeg? |
| 19:44 | <lsxq> | i tried reading up on it and i'm wondering how it originally got supported? and is it formally discouraged/depreciated somewhere? |
| 19:48 | <lsxq> | and if not what's the case for not allowing it to be used in conjunction with the video tag? |
| 19:48 | <Hixie> | in http://www.w3.org/2002/09/wbs/40318/issues-74-and-105-objection-poll/ how are #2 and #3 different? |
| 19:48 | <Hixie> | othermaciej? ^ |
| 19:49 | <TabAtkins> | Hixie: I read them, and I assume there's some subtle point that I don't get. I just gave the same objection to both. |
| 19:49 | <Ms2ger> | lsxq, the spec allows it, but nobody has implemented it |
| 19:49 | <Hixie> | this poll seems very poorly constructed |
| 19:50 | <othermaciej> | Hixie: I dunno, looks like a bug in the poll |
| 19:50 | <TabAtkins> | Oh, wait, wrong one. I havent' answered that. |
| 19:50 | <othermaciej> | I believe one of questions 2 or 3 is redundant and should be deleted |
| 19:51 | <karlcow> | IE8 - 10/13/2010 14:53:22 (date of now) |
| 19:51 | <karlcow> | chrome v6.0.472.63 - Nil |
| 19:51 | <lsxq> | Ms2ger: so i guess i should be complaining to browser vendors then? |
| 19:51 | <karlcow> | ok only IE8 gives what the spec says (or maybe the spec says what IE8 does) |
| 19:51 | <TabAtkins> | lsxq: Yup, if you want it that's the course to take. |
| 19:52 | <Ms2ger> | lsxq, you could try |
| 19:56 | <Philip`> | lsxq: There's probably little interest in supporting it for web video since its compression performance is very poor |
| 19:58 | <othermaciej> | Hixie: Sam removed the dupe |
| 20:00 | <lsxq> | Philip`: i'm definitely not going to argue with that, it's just that even the newer browsers have added in mjpeg playback under <img> and well.. it's really video right? doesn't it make sense to be able to use it under the video tag? |
| 20:00 | <Hixie> | k |
| 20:01 | <AryehGregor> | lsxq, do you also think animated GIF should be supported in <video>? |
| 20:01 | <AryehGregor> | In theory, maybe, but nobody does, I don't think. |
| 20:02 | <lsxq> | well you can't stream gif like you can mjpeg.. i don't think |
| 20:09 | <Hixie> | annevk: yt? |
| 20:44 | <annevk> | Hixie, somewhat |
| 20:45 | <annevk> | Hixie, if you wonder about CSSOM View, my idea is to add the UA-agnostic stuff for scrolling |
| 20:45 | <annevk> | Hixie, elsewhere it also deals with other media (usually simply returning zero) zo it can do that here too |
| 20:47 | annevk | is enjoying Twin Peaks |
| 20:49 | <Hixie> | annevk: k |
| 20:49 | <Hixie> | annevk: sounds good |
| 20:49 | <Hixie> | annevk: do you want me to do anything with the text currently in HTML? e.g. archive it in the bug and assign the bug to you? |
| 20:50 | <annevk> | that sounds good |
| 20:50 | <Hixie> | k |
| 20:50 | <Hixie> | thanks |
| 21:04 | <Hixie> | annevk: btw is there a magical invocation i can use to use the scroll into view stuff? |
| 21:04 | <Hixie> | for frag id nav |
| 21:05 | <Hixie> | also, please put a link to the dev.w3.org version on the TR/ version, i can never find the editor's draft and the TR/ draft has higher pagerank |
| 21:06 | <Hixie> | oh, i see, "scroll the element into view [CSSOMVIEW]" should do it |
| 21:59 | <annevk> | Hixie, Bert removes those links when publishing |
| 22:00 | <annevk> | Hixie, apparently that is within his rights and I have been so far the only person to vocally argue against it within the CSS WG |
| 22:01 | <TabAtkins> | I've never had a draft on TR with the dev links removed, or else I'd argue against it too. |
| 22:03 | <Hixie> | annevk: refuse to publish again until he backs down |
| 22:04 | <annevk> | I'm not sure how not having published anything yet is relevant. Either it is useful or it is not. The relevant thread is http://lists.w3.org/Archives/Member/w3c-css-wg/2010JulSep/thread.html#msg43 (W3C Member-only; no idea why) |
| 22:04 | <Hixie> | the whole TR/ page is such an anachronism |
| 22:05 | <annevk> | Hixie, I get enough trouble as it is within the CSS WG, but this is one of the reasons CSSOM hasn't been published at all yet |
| 22:05 | <annevk> | get into* |
| 22:06 | <Hixie> | annevk: well if you don't publish on the TR/ page at all, my life is easier cos i can't find the TR/ one by mistake :-) |
| 22:06 | <Hixie> | so that works for me :-) |
| 22:09 | <Hixie> | i think it's ludicrous that the IETF publishes its specs in a manner that is optimised for 1970s-era line printers and the W3C publishes its specs in a manner optimised for 1980s-style closed-room development |
| 22:09 | <Hixie> | s/closed-room/magazine publishing/ |
| 22:10 | <TabAtkins> | IETF's spec publishing actively angers me. It feels like they are slapping me in the face every time I look at one. |
| 22:11 | <Hixie> | oh i wouldn't take the IETF's practices personally |
| 22:11 | <Hixie> | it says more about their community than about how they feel about other communities |
| 22:13 | <Dashiva> | Hixie: That's because most of the IETF members still use 1970s-era line printers |
| 22:13 | <Hixie> | lol |
| 22:14 | <Hixie> | IETF doesn't have members actually |
| 22:14 | <Hixie> | they have a model more like the WHATWG than the W3C |
| 22:14 | <TabAtkins> | The only thing I can possibly see it saying about their community is that every person in it uses ancient terminals. That's not true, so I consider it an insult every time. |
| 22:14 | <Dashiva> | TabAtkins: Every person with some clout does, apparently |
| 22:14 | <TabAtkins> | All those people are clearly senile and useless. |
| 22:14 | <Hixie> | TabAtkins: no it just says that they are stuck in their ways, not that they think it's actually sensible |
| 22:14 | <Dashiva> | We discussed this like a year ago, when someone posted a link to discussion and remarked that Julian was the voice of sanity there |
| 22:15 | <TabAtkins> | Hixie: There is a difference between "this isn't great, but shrug, it's kinda tradition" and "let's just screw everyone in the face every time they look at what we produce, because we can! Bwahahahaha!". |
| 22:15 | <Hixie> | TabAtkins: i've never heard any IETF people actually say that the lien printer thing makes sense, they're just institutionally stuck |
| 22:16 | <Dashiva> | Let's see... |
| 22:16 | <Hixie> | TabAtkins: i don't think i've seen any evidence that anyone holds the latter opinion. I've only heard the former one, even from old timers in the IETF. |
| 22:17 | <Hixie> | but frankly i think the text thing is just quirky, it's not harmful. What's harmful is the snapshot-style development. |
| 22:17 | <TabAtkins> | My point was that the current setup is *so* bad, that you can't actually hold the former opinion. |
| 22:17 | <jgraham> | I distinctly remember people arguing that ascii plain text was the only format with the necessary longetivity |
| 22:17 | <jgraham> | Anyway this is just another example of standards organisations being a product of the era in which they are set up |
| 22:17 | <Hixie> | and IETF is even worse than W3C there, because they don't even require a CR-like phase in theory |
| 22:18 | <Hixie> | (w3c doesn't require it in practice, but at least they require it in theory) |
| 22:18 | <Hixie> | jgraham: i feel like it's more like they're hte product of the era before the era they were set up in |
| 22:18 | <Hixie> | jgraham: IETF was set up in the late 80s, not the early 70s |
| 22:18 | <Dashiva> | Unicode is impossible: http://www.ietf.org/mail-archive/web/ietf/current/msg60589.html |
| 22:19 | <Dashiva> | NRoff is easy and sane and everything else is hard: http://www.ietf.org/mail-archive/web/ietf/current/msg60573.html |
| 22:20 | <Hixie> | i don't think the text/plain stuff is that bad. The real problem is that they page their specs, IMHO. |
| 22:20 | <Hixie> | s/page/paginate/ |
| 22:20 | <jgraham> | Maybe that's because they adopt the stuff from the previous decade as "immutable stuff that will always stay with us" and treat anything too new as dangerous to their credibility now they are a fledgling standards organisation looking to be taken seriously |
| 22:20 | <Hixie> | most RFCs nowadays are written as XML that can be converted to a variety of formats |
| 22:20 | <Hixie> | jgraham: yeah |
| 22:20 | <jgraham> | The pagination thing sucks so badly it hurts |
| 22:20 | <Hixie> | jgraham: which is funny given the point is to improve standards :) |
| 22:21 | <Hixie> | anyway |
| 22:21 | <jgraham> | Well probably all the kids now wonder why WHATWG doesn't publish its specs in twitter-sized chunks using flash. Or something. |
| 22:22 | jgraham | is not very down with the kids |
| 22:22 | <Dashiva> | Semantics are crap: http://www.ietf.org/mail-archive/web/ietf/current/msg60581.html |
| 22:23 | <karlcow> | jgraham: I think it is more a question of community and habits, processes which are being carved by the cowpath. Things which are written sealed practices for the good or the bad. Both actually. It is visible in any community practices. |
| 22:23 | <Hixie> | Dashiva: you have successfully convinced me that the IETF has crazies |
| 22:24 | <jgraham> | It is not that surprising that the IETF has crazies, after all the world has crazies and anyone can join |
| 22:24 | <jgraham> | The problem is, the crazies are winning |
| 22:24 | <Hixie> | jgraham: we did use twitter. When they changed their API the twitter stuff broke and nobody complained. So the kids probably don't want that after all. :-) |
| 22:24 | <Dashiva> | If Hixie is convinced I guess I don't have to force my self to read more mails :) |
| 22:25 | <jgraham> | Hixie: No I meant one 140 characterconformance requirement at a time |
| 22:25 | <Hixie> | hsivonen: yt? |
| 22:26 | <Hixie> | hsivonen: should "a style sheet that is blocking scripts", when it's from an ancestor browsing context, be required to be inserted by a parser also? |
| 22:26 | <jgraham> | "Using HTML or PDF for RFCs is about the same as moving from |
| 22:26 | <jgraham> | English language RFCs to mandarin language RFCs" |
| 22:26 | <jgraham> | This stuff is comedy gold |
| 22:28 | <TabAtkins> | ... |
| 22:36 | <jgraham> | Actually I wish I hadn't read any more of that thread |
| 22:36 | <jgraham> | It becomes somewhat scary |
| 22:41 | <TabAtkins> | annevk: Well, I commented. |
| 22:47 | <annevk> | ta |
| 22:51 | <Hixie> | http://toki-woki.net/p/scroll-clock/ |
| 22:52 | <Hixie> | similar to the text-editor-made-of-radio-buttons i hypothesised about in the canvas a11y thread and got ridiculed for |
| 22:55 | <TabAtkins> | I could make it in pure CSS. ^_^ |
| 22:56 | <TabAtkins> | Just figure out the animations necessary for each element as it cycles through the 10 digits, then apply it to each place with successively longer animation-durations. |
| 22:57 | <Hixie> | heh |
| 23:55 | <kinetik> | is it intentional that vorbis_synthesis_init returns > 0 on error? (https://bugzilla.mozilla.org/show_bug.cgi?id=604067#c3) |
| 23:58 | <TabAtkins> | kinetik: Wrong room? |
| 23:58 | <kinetik> | ah, all my irssi windows have changed numbers--sorry |
| 23:58 | <kinetik> | (that explains why xiphmont failed to tab complete...) |
