| 00:00 | <Hixie> | that has too-high latency |
| 00:00 | <othermaciej> | didn't the i18n people request this a while ago? |
| 00:00 | <othermaciej> | or am I confusing it with something else? |
| 00:00 | <Hixie> | dunno |
| 00:00 | <Hixie> | i'm adding it based on feedback to the whatwg 0ist |
| 00:00 | <Hixie> | list |
| 00:01 | <AryehGregor> | othermaciej, I don't think it's relevant to i18n at all. |
| 00:01 | <AryehGregor> | It's about which direction the user selected the text in, nothing to do with the text direction. |
| 00:01 | <othermaciej> | oh |
| 00:02 | <othermaciej> | in that case I have no idea what it's about so I have no real opinion |
| 00:02 | zcorpan | thinks someone will complain on the basis that there's always someone who complains for just about anything |
| 00:03 | <AryehGregor> | It seems unlikely to be controversial. |
| 00:03 | <AryehGregor> | As much as anything is. |
| 00:03 | <Hixie> | othermaciej: it's the equivalent of m_baseIsFirst is webkit, as i understand it |
| 00:04 | <Hixie> | AryehGregor: so should setSelectionRange() reset the direction to forward or preserve the direction? (i'm adding an optional argument to set the direction, but i mean in the absence of that) |
| 00:04 | <AryehGregor> | Hixie, if it helps, Selection.removeAllRanges() resets the direction, but calling removeRange() on the last range doesn't. :) |
| 00:05 | <Hixie> | if we make it preserve the direction then pages that try to preserve the selection today will magically work better |
| 00:05 | <Hixie> | but pages that try to reset the selection will have the direction the user last used, somewhat arbitrarily |
| 00:05 | <AryehGregor> | Selection.collapse() doesn't reset direction per spec, but I don't know if that's correct. |
| 00:06 | <AryehGregor> | I'd say reset it, offhand. |
| 00:06 | <Hixie> | k |
| 00:06 | <AryehGregor> | It's simpler, it only gives two behaviors. |
| 00:06 | <AryehGregor> | Also, it won't make anything work any worse than it currently does. |
| 00:06 | <AryehGregor> | Actually, how would it make anything work better, except by chance? |
| 00:07 | <AryehGregor> | I mean, the alternative. |
| 00:07 | <AryehGregor> | Of preserving the current direction. |
| 00:07 | AryehGregor | shrugs |
| 00:07 | <Hixie> | it would mean pages that today remember the start/end would magically also remember the direction |
| 00:08 | <AryehGregor> | How? |
| 00:08 | <Hixie> | nothing would reset the direction |
| 00:08 | <Hixie> | so... it would be preserved |
| 00:08 | <Hixie> | am i missing something? |
| 00:08 | <Hixie> | this seems simple :-) |
| 00:08 | <AryehGregor> | The user selecting something different would reset the direction. |
| 00:08 | <AryehGregor> | Or are you saying in the case where the user didn't select something different? |
| 00:08 | <AryehGregor> | I.e., the point is that setSelectionRange() with the current start and end is a no-op? |
| 00:08 | <Hixie> | sure, but if the user selects something, then the script manipulates the control and puts the selection back, it would presevre the direction |
| 00:09 | <AryehGregor> | Manipulates the control how? |
| 00:09 | <Hixie> | (sure was to your first of the three lines here) |
| 00:09 | <Hixie> | input.value = 'abc' + input.value + 'def'; or whatever |
| 00:09 | <Hixie> | the problem we're trying to solve here |
| 00:09 | <AryehGregor> | Oh, hmm. |
| 00:10 | <AryehGregor> | Have you defined what value changes do to the selection info? |
| 00:10 | <AryehGregor> | Are you suggesting that setting the value should clear the selection but preserve its direction, even when there's no selection? |
| 00:10 | <Hixie> | i don't think it's specced currently |
| 00:10 | <AryehGregor> | I dunno, I still think it's simpler to reset. |
| 00:10 | <AryehGregor> | More deterministic. |
| 00:11 | <AryehGregor> | Especially if we don't spec what causes selection to change. |
| 00:11 | <Hixie> | sounds good |
| 00:14 | <Hixie> | hm, Mac selections have three directions |
| 00:14 | <AryehGregor> | I think someone mentioned that. |
| 00:14 | <AryehGregor> | It sounds evil. |
| 00:15 | <Hixie> | i didn't see anything about mac in the thread |
| 00:16 | <AryehGregor> | In other threads, about Selection. |
| 00:16 | <Hixie> | ah |
| 00:17 | <Hixie> | well i'm gonna have three values, forward,backward,none |
| 00:17 | <AryehGregor> | That doesn't match Selection, FWIW. |
| 00:17 | <AryehGregor> | Probably best to keep them in sync. |
| 00:17 | <Hixie> | how do you model a mac neutral selection? |
| 00:17 | <Hixie> | i'll use whatever you do |
| 00:18 | <Hixie> | don't want conflicting terminology |
| 00:43 | <benschwarz> | Hixie: I was offline— what does zcorpan mean by |
| 00:44 | <benschwarz> | saying that its not updating for him? |
| 00:45 | <Hixie> | AryehGregor: i've gone with "none" for now, file a bug to let me know what you used instead and i'll update accordingly |
| 00:45 | <Hixie> | benschwarz: dunno |
| 00:45 | <Hixie> | benschwarz: he was saying there's some sort of corruption or something |
| 00:45 | <Hixie> | benschwarz: see the validator link he sent |
| 00:45 | <benschwarz> | Hixie: I'll have to ask him… |
| 00:45 | <benschwarz> | nope |
| 00:46 | <Hixie> | benschwarz: http://validator.nu/?doc=http%3A%2F%2Fdevelopers.whatwg.org%2Fvideo.html |
| 00:46 | <Hixie> | i gotta go, meeting |
| 00:46 | <Hixie> | bbiab |
| 00:47 | <benschwarz> | holy shit |
| 00:47 | <benschwarz> | ok |
| 01:54 | <jamesr> | are thingies defined on IDL functions or methods? |
| 01:54 | <jamesr> | thingies that you can call, that is |
| 02:04 | <heycam> | jamesr, "operations" :( |
| 02:04 | <heycam> | maybe I should change that, sounds sucky |
| 02:04 | heycam | lunches |
| 02:05 | <jamesr> | clearTimeout in the WHATWG spec uses 'method' |
| 02:37 | <jamesr> | anyone around familiar with mercurial? |
| 04:39 | GPHemsley | wonders where to report typos in the latest CSS 2.1 spec |
| 04:44 | <GPHemsley> | The mailing list, I guess? |
| 04:45 | <heycam> | yes I think that's fine |
| 04:48 | <tw2113> | is it a typo that makes things sort of work in IE6? |
| 04:56 | <GPHemsley> | tw2113: It's much less important than that. :) |
| 04:57 | <GPHemsley> | s/less important/smaller/, if you prefer |
| 04:57 | <GPHemsley> | (e-mail sent, FWIW) |
| 04:57 | <tw2113> | if it broke things in IE6, and you were trying to fix it, i was going to have to stop you |
| 09:55 | <jgraham> | "Holy crap, I though that I'm member of working group and not a member of |
| 09:55 | <jgraham> | absurd comedy company here." |
| 09:55 | <jgraham> | You must be new here? |
| 11:01 | <MikeSmith> | heh |
| 11:25 | <hsivonen> | is the first Ask Professor Markup box correct per spec on http://diveintohtml5.org/offline.html ? |
| 11:25 | <hsivonen> | the one that says "Every page of your web application needs a manifest attribute that points to the cache manifest for the entire application." |
| 11:29 | <hsivonen> | boohoo. the spec, dev.opera.com and Dive into HTML5 all make it hard to find out at a glance if the app cache events fire on window, document or window.applicationCache |
| 11:30 | <hsivonen> | ah. the specs answers the question in a non-normative section http://www.whatwg.org/specs/web-apps/current-work/#appcacheevents |
| 11:30 | <hsivonen> | I failed to work it out from the normative bits |
| 11:31 | <Lachy> | hsivonen, it's probably wise to confirm that in the normative bits, since I've come across non-normative parts in the spec that contradicted the normative parts |
| 11:36 | <hsivonen> | testing this stuff sure is hard |
| 11:41 | <hsivonen> | ok. there's something wrong with my test case, since I get the checking event but not the cached event |
| 11:43 | <hsivonen> | great. one of my cache manifest entries pointed to a non-existent file |
| 11:43 | <hsivonen> | Dive into HTML5 is right about debugging this stuff! |
| 12:43 | <hsivonen> | how do I ask an app cache error event object what went wrong? |
| 12:44 | <hsivonen> | ok. now I see what went wrong without asking the object... |
| 12:56 | <hsivonen> | soo. if I navigate a window.open()ed window via the outer window object, I'm supposed to get a load event visible to the outer window, right? |
| 14:19 | <MikeSmith> | hsivonen: hyphenation feature looks pretty cool |
| 14:19 | <hsivonen> | MikeSmith: yeah. too bad it seems the dictionaries total to too many bytes to be all bundled always |
| 14:19 | <mpilgrim> | lol </hgroup> |
| 14:20 | <MikeSmith> | hsivonen: yeah, well, that's to be expected I guess |
| 14:22 | <mpilgrim> | hsivonen: if Professor Markup is wrong, I'll happily make corrections |
| 14:22 | <hsivonen> | mpilgrim: seems to me that hgroup is one of those things were Hixie gets yelled at by the usual suspects no matter what |
| 14:23 | <hsivonen> | mpilgrim: I have a bug assigned to me where the premise of the bug disagrees with Professor Markup |
| 14:24 | <hsivonen> | mpilgrim: so at least Firefox 3.6 made it possible to load an HTML file that itself doesn't have a manifest attribute from a previously declared app cache |
| 14:24 | <mpilgrim> | what happens when you visit that HTML file? |
| 14:26 | <hsivonen> | mpilgrim: "if there is no such attribute, or its value is the empty string, or resolving its value fails, run the application cache selection algorithm with no manifest" |
| 14:26 | <hsivonen> | mpilgrim: which is what Firefox 3.6 does |
| 14:26 | <hsivonen> | and Firefox 4 doesn't |
| 14:26 | <hsivonen> | and hopefully Firefox 5 will do |
| 14:27 | <mpilgrim> | Slightly confused. what should Professor Markup say instead? |
| 14:27 | mamund_ | is here |
| 14:28 | <hsivonen> | mpilgrim: that if the user has previously visited an HTML file that caused an application cache to be populated, it is then possible to navigate to other HTML pages that were declared in the manifest of the first page but that don't themselves need a manifest because they got cached already |
| 14:29 | <hsivonen> | mpilgrim: except that this doesn't work in Firefox 4 due to this bug |
| 14:29 | <mpilgrim> | what happens if the user navigates to those unlisted HTML pages first, before visiting a page with a manifest attribute? |
| 14:29 | <mpilgrim> | the page isn't listed in a manifest, and there's no manifest attribute, so it's just a regular online page |
| 14:29 | <hsivonen> | mpilgrim: then the browser hits the server |
| 14:30 | <mpilgrim> | that's an inconsistent experience |
| 14:30 | <hsivonen> | mpilgrim: maybe |
| 14:30 | <mpilgrim> | the page is allegedly part of an offline web app |
| 14:30 | <mpilgrim> | except it depends on which page you hit first |
| 14:30 | <mpilgrim> | try debugging THAT |
| 14:30 | <hsivonen> | mpilgrim: but it addresses the problem you, IIRC, had that you had to bother people with the caching authorization on all diveintohtml5 entry points |
| 14:31 | <hsivonen> | mpilgrim: as opposed to having one URL for bootstrapping an offline experience |
| 14:31 | <hsivonen> | mpilgrim: anyway, I don't try to defend the spec |
| 14:31 | <mpilgrim> | ah. that's interesting. |
| 14:31 | <mpilgrim> | a "go offline" page |
| 14:31 | <mpilgrim> | yes, now i see it |
| 14:31 | <hsivonen> | mpilgrim: I'm not even trying to understand the spec beyond fixing the bug and, worse, writing the test case for it |
| 14:32 | <hsivonen> | (which we evidently need to have, because if we had had it in time, we wouldn't have shipped Firefox 4 with this bug) |
| 14:33 | <mpilgrim> | more test cases is always the right answer |
| 14:33 | <mpilgrim> | now i'm trying to figure out how to phrase this in Professor Markup-speak |
| 14:37 | <jgraham> | Writing automated offline tests for the testsuite is going to be "fun" |
| 14:37 | <jgraham> | I wonder what tests we have for that… |
| 14:38 | <hsivonen> | jgraham: can't do it without a special powers API that allows you to grant offline caching authorization and to move the browser to the offline mode |
| 14:39 | <hsivonen> | jgraham: I also added a way to evict normal HTTP cache entries into our special powers API |
| 14:39 | <hsivonen> | in order to test this |
| 14:43 | <MikeSmith> | hsivonen: I think we are going to need similar special-powers APIs for some other things |
| 14:43 | <MikeSmith> | e.g., the Geolocation API |
| 14:43 | <MikeSmith> | and the Web Notifications API |
| 14:45 | <jgraham> | For geolocation and device orientation it's not really clear what you can do |
| 14:45 | <jgraham> | Or for notifications really |
| 14:45 | <jgraham> | Unless the plan is to have some magic environment that mocks out the real world |
| 14:45 | <jgraham> | But that seems… complex |
| 14:51 | <MikeSmith> | jgraham: what about the WATIR stuff? |
| 14:52 | <jgraham> | MikeSmith: I don't think that has the capacity to lie about system API calls |
| 14:52 | <MikeSmith> | ok |
| 14:52 | <jgraham> | which is probably what you would need to test e.g. geoloc |
| 14:53 | <jgraham> | Well apart from manual testing ofc |
| 14:54 | <wilhelm_> | You could fake it somewhere inside the browser. And expose an API for poking the system API-faking-API with Watir or JavaScript. |
| 14:55 | <MikeSmith> | seem like you could you make it automateable using a browser build that had the API-lying support compiled in |
| 14:55 | <MikeSmith> | that is, not a build that you would actually make available to end users |
| 14:55 | <MikeSmith> | or however |
| 14:56 | <MikeSmith> | my point being you can test with a browser build that had some dangerous stuff enabled just for the purposes of making the testing automateable |
| 14:58 | <jgraham> | Yes you could |
| 14:58 | <wilhelm_> | I doubt exposing that in public builds would be particularly harmful, though. Once a Watir script has control over your browser, it can mess up anything it wants to anyway. (c: |
| 14:58 | <jgraham> | There is of course the danger that the code is broken in the real environment |
| 14:59 | <wilhelm_> | Yes. And faking the location is useful if you're writing tests for a location-based web application too. |
| 15:00 | <Philip`> | Just add a precondition to the test case that says you have to move your computer to a particular location before running it |
| 15:00 | <Philip`> | Get Google to donate an office for it or something |
| 15:00 | <wilhelm_> | Woo! Free travels! |
| 15:00 | <Philip`> | preferably in an area without much seismic activity so it's not going to move frequently |
| 15:02 | <jgraham> | No California trip then. Much less Japan. |
| 15:11 | <MikeSmith> | heh |
| 15:12 | <MikeSmith> | somewhat ironically, I now use a browser extension that pops up a notification any time there's an earthquake here that's magnitude 4 or greater |
| 15:13 | <wilhelm_> | So every few hours, then? |
| 15:13 | <MikeSmith> | there is a similar feature enabled in most mobiles here too |
| 15:13 | <MikeSmith> | wilhelm_: yep, pretty much |
| 15:13 | <MikeSmith> | get the notification, then 15 seconds or so later, feel the earthquake |
| 15:14 | <MikeSmith> | since most of them currently are still coming from the same fault where the big one happeneed |
| 15:18 | <MikeSmith> | zcorpan: about the element-id changes |
| 15:18 | <MikeSmith> | you will probably need to update some links in the HTML5-HTML4 diffs doc |
| 15:19 | <MikeSmith> | actually, there are already some broken links in that doc, btw |
| 15:19 | <MikeSmith> | I have just been fixing them each time we publish a WD |
| 15:19 | <MikeSmith> | I mean, I have been fixing them in the WD |
| 15:19 | <MikeSmith> | not in the source ED |
| 15:20 | <zcorpan> | MikeSmith: ah. yeah, file a bug and i'll go through the links |
| 15:20 | <MikeSmith> | but they should probably be fixed in the ED before we publish the Last Call draft |
| 15:20 | <MikeSmith> | hai |
| 15:21 | <foolip> | Philip`, the spec splitter seems to have gone bonkers, <video> is now part of the iframe document: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-video-element |
| 15:23 | <MikeSmith> | foolip: been that way for a while |
| 15:23 | <MikeSmith> | not bonkers |
| 15:23 | <MikeSmith> | it's expected behavior |
| 15:23 | <MikeSmith> | the file names are just generated from whatever ID is at the point where it does the split |
| 15:23 | <Philip`> | It's expected to be bonkers |
| 15:23 | <MikeSmith> | heh |
| 15:23 | <foolip> | ok, and it's intentional that iframe and video are in the same chunk? |
| 15:24 | <zcorpan> | before video+audio+source was on one page and media elements was on one page |
| 15:24 | <MikeSmith> | Philip`: doesn't it have some way to force splits at particular places? |
| 15:24 | <Philip`> | It tries to split on id="video" but it looks like that's been renamed to id="the-video-element" |
| 15:24 | <MikeSmith> | aha |
| 15:24 | <foolip> | so it is a bug then :) |
| 15:25 | <MikeSmith> | hmm, the W3C version was already doing that, I think |
| 15:25 | <Philip`> | It does give the impression of being a bug |
| 15:26 | <zcorpan> | i'd prefer if there was a split just before the video element so that all video-related stuff is on one page |
| 15:26 | <foolip> | looks like Hixie renamed a bunch of things: http://html5.org/tools/web-apps-tracker?from=6049&to=6050 |
| 15:26 | <foolip> | might want to go through that and see if there was any other unintended breakage |
| 15:27 | <foolip> | there are a few more similar commits |
| 15:27 | <Philip`> | Might be better to start from scratch and redo all the split ids, since things have probably been added or grown or rearranged in the meantime so the splits won't be sensible anyway |
| 15:28 | <Philip`> | plus there's some bug you reported aeons ago that I never bothered doing anything about |
| 15:30 | <MikeSmith> | looking at split_exceptions in http://html5.googlecode.com/svn/trunk/spec-splitter/spec-splitter.py it doesn't look so much would have to change due the ID renaming at least |
| 15:51 | <MikeSmith> | hsivonen: I'm working on adding support for http://bugzilla.validator.nu/show_bug.cgi?id=828 and will have a patch to you by tomorrow |
| 15:52 | <MikeSmith> | after that I don't have any feature changes that I'm planning to add soon |
| 15:53 | <MikeSmith> | I would really like to add the Prohibit Duplicate Charset Declarations thing |
| 15:53 | <MikeSmith> | http://bugzilla.validator.nu/show_bug.cgi?id=589 |
| 15:53 | <hsivonen> | MikeSmith: ok. |
| 15:54 | <hsivonen> | MikeSmith: did you decide to implement microformat wiki scraping? |
| 15:54 | <MikeSmith> | hsivonen: no, thought about it |
| 15:54 | <MikeSmith> | but what I would like to propose to you instead is that we just hardcode the values |
| 15:54 | <MikeSmith> | and then update them when the page gets updated |
| 15:55 | <hsivonen> | MikeSmith: radical |
| 15:55 | <hsivonen> | MikeSmith: I was thinking of actually implementing the scraping in the near future if you aren't doing it |
| 15:55 | <jgraham> | MikeSmith: On an entirely different topic did you come to any conclusion about annotated versions of the spec for test coverage? |
| 15:55 | <hsivonen> | MikeSmith: but your suggestion is a radically easy approximation |
| 15:55 | <jgraham> | (feel free to queue replying to that question indefinitely) |
| 15:55 | <MikeSmith> | yeah, I think it will make our lives easier |
| 15:56 | <MikeSmith> | hsivonen: same goes for meta name checking |
| 15:57 | <MikeSmith> | jgraham: I have not come to any conclusion |
| 15:58 | <MikeSmith> | but in the mean time, Peter Linss told me about something similar he has put together |
| 15:58 | <MikeSmith> | example at http://test.csswg.org/cascade.html |
| 15:58 | <Ms2ger> | Has HP already allowed him to release his code? |
| 15:58 | <MikeSmith> | scroll down, see the test-annotation boxes |
| 15:58 | <MikeSmith> | Ms2ger: dunno |
| 15:59 | <jgraham> | Interesting |
| 16:00 | <MikeSmith> | the beauty of that thing is that it to make it work, all you have to do is add a single script to a copy of whatever spec you want to do it for |
| 16:00 | <MikeSmith> | <script src='http://test.csswg.org/harness/annotate.js#CSS21_RC6'; type='text/javascript' defer></script> |
| 16:00 | <MikeSmith> | frag ID tells it what test suite you want it to use |
| 16:01 | <MikeSmith> | of course it does require you have the spec set up in a certain way |
| 16:01 | <MikeSmith> | and it only lets you associate tests with existing IDs |
| 16:01 | <MikeSmith> | I think |
| 16:02 | <jgraham> | It would be neat to do per-section then per-regexp for better granularity |
| 16:04 | <foolip> | Philip`, would you like a bug in some kind of BTS, or will the link http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#getting-media-metadata magically start working when you decide to fix it? |
| 16:04 | <MikeSmith> | btw, I can't add the Prohibit Duplicate Charset Declarations because it's blocked on Hixie actually making it clear in the spec what the expected validator behavior should be. I guess I should ping him about it |
| 16:06 | <zcorpan> | MikeSmith: just implement what you think the spec should say, tell Hixie what you implemented and if he specs something different you whine about it until he makes the spec say what you implemented |
| 16:06 | <MikeSmith> | heh |
| 16:07 | <jgraham> | zcorpan: Ssh you are giving away the secrets of the vast browser-wing conspiracy |
| 16:07 | <MikeSmith> | zcorpan: because Hixie clearly always responds very positively to whining |
| 16:07 | <zcorpan> | oh this is #whatwg? wrong window |
| 16:08 | <Philip`> | foolip: That link ought to work already, since the 404 page is meant to redirect, but it looks like Hixie broke the 404 page there :-( |
| 16:09 | <zcorpan> | the 404 page was not found? |
| 16:09 | Philip` | has no idea when it last used to work |
| 16:10 | <MikeSmith> | it works still in the W3C version I think |
| 16:10 | <MikeSmith> | or did a couple days ago at least |
| 16:11 | <Philip`> | foolip: I seem to generally ignore BTSes and emails etc, so they're probably not a good way to get me to do things |
| 16:11 | <Philip`> | I could probably try doing it this afternoon if I have time before I forget, though |
| 16:11 | <foolip> | Philip`, ok, so I'll poke you here every time I get annoyed :) |
| 16:11 | <Philip`> | That's the most reliale approach :-) |
| 16:12 | <zcorpan> | foolip: set up a bot that pings Philip` on irc every hour |
| 16:12 | <zcorpan> | or with random intervals |
| 16:13 | <MikeSmith> | btw, i'm wondering again about the fact that given that we have validator conformance criteria defined in the spec, if we hold that to the "two interoperable implementations" requirement, we are going to end up blocking progress of the spec out of CR for quite a long while. unless somebody puts a couple thousand or so man hours into implementing another validator |
| 16:13 | <zcorpan> | MikeSmith: depends on what we decide the CR exit criteria should be |
| 16:13 | <MikeSmith> | yeah |
| 16:14 | <MikeSmith> | I can't recall, but maybe the last time we talked about this, the sentiment was that having one validator implementation for those assertions was enough |
| 16:14 | <zcorpan> | we aren't gonna get two implementations of all possible conformance classes |
| 16:14 | <MikeSmith> | true, I guess |
| 16:15 | <MikeSmith> | but it really would be good to have another validator implementation to compare things with |
| 16:15 | <MikeSmith> | and to compete against |
| 16:16 | <hsivonen> | I really need to get to pending non-Gecko work for real |
| 16:16 | <hsivonen> | (validator, standalone parser in C++) |
| 16:16 | <MikeSmith> | standalone parser in Javascript… |
| 16:17 | <Ms2ger> | In Haskell... |
| 16:17 | <hsivonen> | maybe I should allocate days in a round-robin fashion to these tasks |
| 16:17 | <hsivonen> | otherwise, the Gecko stuff will continue starving everything else |
| 16:18 | <hober> | MikeSmith: there already is one, though it's not hsivonen's |
| 16:19 | <MikeSmith> | hober: yeah, I know |
| 16:19 | <hsivonen> | actually, it's HTML5 parser in Gecko fallout that's starving everything else |
| 16:19 | <hsivonen> | including the Gecko XML codepath rewrite |
| 16:19 | <MikeSmith> | hober: and it's conformant now too, right? |
| 16:20 | <MikeSmith> | hober: the only downside of that I noticed is that it seems to be relatively slow |
| 16:20 | <MikeSmith> | hober: like, it takes about 1 minute and 30 seconds to parse the HTML5 spec |
| 16:21 | <MikeSmith> | whereas Henri's parser takes only a few seconds, maybe 5 seconds or less |
| 16:22 | <hsivonen> | MikeSmith: did you test both with a browser-provided DOM impl? |
| 16:22 | <hsivonen> | or does the other parser always use a pure-JS DOM? |
| 16:22 | <MikeSmith> | that |
| 16:22 | <MikeSmith> | I think |
| 16:22 | <hsivonen> | ok |
| 16:22 | <MikeSmith> | so I guess it's not surprising that it's slower |
| 16:25 | <hsivonen> | JITted JS shouldn't be *that* slow |
| 16:28 | <MikeSmith> | hsivonen: well, I tested it in node, actually |
| 16:28 | <MikeSmith> | but it's still JITted there too, I would think |
| 16:29 | <jgraham> | It's possible they hit a slow case in V8 string handling |
| 16:29 | <jgraham> | http://my.opera.com/emoller/blog/2011/05/01/javascript-performance |
| 16:31 | <MikeSmith> | I think the slowness in this case may be from jsdom, which this html5 JS parser depends on |
| 16:32 | <MikeSmith> | hmm, or it doesn't depend on it itself |
| 16:32 | <MikeSmith> | but the parsing test I tried does |
| 16:33 | <MikeSmith> | anyway, I'm sure hober knows far more about the details then me |
| 16:34 | <hober> | I'm pretty sure the longest document I've shoved into aria's parser is at least a couple of orders of magnitude smaller than the html5 spec |
| 16:34 | <hober> | so I can't say the performance has bothered me :) |
| 16:34 | <Philip`> | I presume a JS parser shouldn't be any slower than the Python html5lib one |
| 16:35 | <Philip`> | (although that's certainly a lot slower than a Java or C one) |
| 16:35 | <hober> | oh hey, MikeSmith, any chance you'll be in kyoto around the time of the css & svg f2fs? |
| 16:36 | <jgraham> | I would assume that a js parser should be faster |
| 16:36 | <jgraham> | If it was well optimised |
| 16:37 | <jgraham> | Although I would be interested in profiling html5lib in PyPy to see what's slow |
| 16:38 | <jgraham> | (it is supposedly about twice as fast as CPython) |
| 16:41 | <gsnedders> | http://speed.pypy.org/comparison/?exe=2%2B35%2C4%2B35%2C1%2BL%2C3%2BL&ben=6&env=1&hor=false&bas=2%2B35&chart=normal+bars |
| 16:42 | <gsnedders> | Interestingly that claims Pysco makes html5lib *slower* |
| 16:51 | <MikeSmith> | hober: I can certainly plan to head down there, especially if you're planning to be there |
| 16:52 | <MikeSmith> | I also encourage you to visit Tokyo if you can, before or after you go to Kyoto |
| 16:53 | <MikeSmith> | you're welcome to stay at my place if you do, though it's really small |
| 16:53 | <MikeSmith> | it's kind of like hanging out in a treehouse |
| 16:53 | Ms2ger | loves treehouses |
| 16:54 | <MikeSmith> | or a moonshiner shack |
| 17:09 | <Philip`> | gsnedders: Psyco make html5lib much faster when I tested it ages ago, I believe |
| 17:10 | <Philip`> | s/make/made/ |
| 17:10 | <Philip`> | where "much" might be a factor of 2x or so |
| 17:11 | <MikeSmith> | what's Psyco? |
| 17:12 | <Philip`> | I tried writing a trivial tokeniser in Python that just understood element names (I think), with the input just being a string, and tried iterating over characters or using regexps etc, and couldn't find any way that was appreciably faster than running the whole of html5lib on the same string |
| 17:12 | <Philip`> | so I think that's the main bottleneck and I think it's probably impossible to overcome with pure Python :-( |
| 17:13 | <Philip`> | MikeSmith: It's kind of a JIT for Python |
| 17:13 | <MikeSmith> | ok, yeah |
| 17:13 | <MikeSmith> | I was just reading the Info page for it |
| 17:13 | <MikeSmith> | pretty impressive |
| 17:14 | <MikeSmith> | hober: what are the dates for the CVS f2f? |
| 17:15 | <MikeSmith> | (or anybody else who knows) |
| 17:16 | <MikeSmith> | 2-4 June (Thu-Sat) it seems |
| 17:17 | <MikeSmith> | "1 Jun is a forum with designers, implementers, etc." |
| 17:17 | <MikeSmith> | and SVG f2f the beginning of the week after that |
| 17:21 | <MikeSmith> | hober: fwiw, I will be around during those dates |
| 17:22 | <MikeSmith> | from the 6th to the 10th, I have to go to Beijing |
| 17:23 | <MikeSmith> | so if you wanted to visit Tokyo during those days, you would be welcome to have my apartment to your own then |
| 17:30 | jgraham | likes the idea of a CVS f2f |
| 17:31 | Ms2ger | screams at the idea |
| 17:31 | <jgraham> | "So… guys… everyone hates us. Hell we even hate ourselves. Beer?" |
| 17:34 | <karlcow> | houla… dean waking up threads which are 4 years old |
| 17:35 | <hober> | MikeSmith: I think I'm flying through kansai, so the odds are sadly low that I'll make it that far north |
| 17:51 | <MikeSmith> | hober: OK. anyway, there is plenty to do and see in Kyoto/Osaka area |
| 17:52 | <MikeSmith> | and people in that area are usually a lot more fun to spend time with than people in Tokyo anyway :) |
| 18:54 | <Hixie> | wow, multipage/ has been broken since feb 8 and nobody noticed until now |
| 18:54 | <hsivonen> | https://twitter.com/#!/johnfoliot/status/65815344433991680 |
| 18:54 | <Hixie> | i suck |
| 18:54 | <AryehGregor> | Hixie, broken how? |
| 18:54 | <AryehGregor> | I've been using it on almost a daily basis. |
| 18:54 | <Hixie> | the 404 page is missing, and the htaccess file is bogus in various ways |
| 18:54 | <hsivonen> | I only use multipage or the parser and the parser has been stable |
| 18:54 | <Hixie> | the content still works |
| 18:55 | <hsivonen> | I use single-page for everything else |
| 18:57 | <Hixie> | ok 404 page fixed |
| 18:57 | <Hixie> | what was the thing MikeSmith was blocked on? |
| 18:57 | <Hixie> | something about Prohibit Duplicate Charset Declarations? |
| 18:57 | <MikeSmith> | Hixie: yeah |
| 18:58 | <Hixie> | is there a bug# or e-mail? |
| 18:58 | <Hixie> | i'm not sure what the problem is |
| 18:58 | <MikeSmith> | yeah, hang on |
| 18:58 | <MikeSmith> | lemme find it |
| 18:58 | <Hixie> | or just tell me the problem :-) |
| 18:58 | <MikeSmith> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=12054 |
| 18:59 | <MikeSmith> | problem is, I can't tell from the spec what the document-conformance criteria are for the case of multiple character-encoding declarations in a document |
| 18:59 | Hixie | looks |
| 19:00 | <MikeSmith> | Hixie: basically, if you just add one sentence saying something like "There must be only one character encoding declaration in the document.", then I think that's all we need |
| 19:01 | <MikeSmith> | or however you want to state it |
| 19:02 | <Hixie> | apparently that's not quite accurate |
| 19:02 | <Hixie> | there's a comment in the spec: |
| 19:02 | <Hixie> | <li>There can only be one character encoding declaration in the |
| 19:02 | <Hixie> | document.</li> <!-- conformance criteria for this one are given in |
| 19:02 | <Hixie> | the XML spec, the <meta> section just after defining charset="", |
| 19:02 | <Hixie> | and the character encoding pragma section. And actually this |
| 19:02 | <Hixie> | statement isn't quite true, since you can have an XML one and an |
| 19:02 | <Hixie> | HTML one at the same time if they match. --> |
| 19:03 | <Hixie> | what prohibits there being two <meta http-equiv="Content-Type"> headers is "There must not be more than one meta element with any particular state in the document at a time." |
| 19:04 | <Hixie> | so you can't have multiple <meta charset>s, you can't have multiple "meta http-equiv="Content-Type">s, and you can't have one of each |
| 19:04 | <Hixie> | but you _can_ have both an XML one and an HTML one, so long as they match |
| 19:12 | <hsivonen> | Hixie: but in that case they must say utf-8, right |
| 19:12 | <Hixie> | right |
| 19:12 | <Hixie> | MikeSmith: i've clarified the statements a bit |
| 19:12 | <Hixie> | MikeSmith: hopefully it'll help |
| 19:12 | <MikeSmith> | OK |
| 19:12 | <Hixie> | regenning now |
| 19:12 | <MikeSmith> | thanks |
| 19:13 | <MikeSmith> | I appreciate it |
| 19:13 | <Hixie> | (note, if you have both the xml one and the html one, it must be an xml doc, it must be utf-8 as hsivonen says, and it must be <meta charset>, no <meta content-type text/html> in xml) |
| 19:14 | <Hixie> | ok, committed |
| 19:54 | <AryehGregor> | On what basis are WML or XHTML-MP actually harmful? Assuming that there are devices out there that cannot realistically handle full HTML, isn't an alternative standard needed regardless? |
| 19:55 | <Hixie> | wml resulted in two webs |
| 19:55 | <Hixie> | yet was no lighter on UAs than HTML |
| 19:55 | <Hixie> | XHTML-MP didn't go anywhere useful so i don't know that it was harmful in practice |
| 19:59 | <AryehGregor> | So is WML an argument against forking? |
| 19:59 | <wilhelm_> | Hixie: It cost certain browser vendors a lot of time, frustration and some added compexity. |
| 20:00 | <wilhelm_> | Not quite as much as ES-MP (oh, please kill me now), but still harmful. |
| 20:01 | <AryehGregor> | I guess WML is a weaker argument against forking than HTML5 is in favor of forking, because WML eventually died. |
| 20:01 | <AryehGregor> | Since it was the worse standard. |
| 20:01 | <AryehGregor> | Which is the point. |
| 20:01 | <wilhelm_> | Oh, it's still around. |
| 20:01 | <Hixie> | AryehGregor: forking itself is terrible |
| 20:01 | <AryehGregor> | Oh, hmm. |
| 20:02 | <Hixie> | AryehGregor: allowing forking is indispensible |
| 20:02 | <AryehGregor> | Okay, I'll have to revise a lot of what I just wrote. |
| 20:02 | <Hixie> | AryehGregor: well, successful forking such that there are multiple active incompatible forks is terrible, anyway |
| 20:02 | <Hixie> | AryehGregor: but that's what most people mean when they refer to forks |
| 20:04 | <AryehGregor> | So really the argument is that competing standards are very bad, but a single bad standard is even worse -- because then it will just compete against nonstandard technologies. |
| 20:04 | <AryehGregor> | And lose, since it's bad. |
| 20:05 | <wilhelm_> | On the Web, I'd say HTML5 really is the odd one out. One beneficial fork among many harmful. |
| 20:05 | <AryehGregor> | Were the harmful forks, all added together, as harmful to the open web as Flash? |
| 20:05 | <AryehGregor> | Which got almost total market share because HTML stagnated and didn't add support for basic things like video? |
| 20:06 | <Hixie> | flash has done both good and bad to the web |
| 20:06 | <hober> | wilhelm_: how is the W3C fork of HTML5 not harmful? |
| 20:06 | <AryehGregor> | Man, you guys are really making it hard for me to write a persuasive argument. :P |
| 20:06 | <Hixie> | hober: i assume he meant the fork in 2004 |
| 20:06 | <hober> | oh, indeed. that was quite harmful. |
| 20:06 | <AryehGregor> | What good has Flash done, compared to the same standards being standardized in comparable timeframes? |
| 20:07 | <wilhelm_> | Yes, I was referring to 2004. |
| 20:07 | <AryehGregor> | Or are we assuming they wouldn't have been, even if forking were allowed? Since in fact, forking was allowed . . . |
| 20:07 | <AryehGregor> | Effectively. |
| 20:07 | <Hixie> | AryehGregor: you need an R&D lab |
| 20:07 | <AryehGregor> | I mean, is this really mostly a moral argument and not an empirical one, here? |
| 20:07 | <AryehGregor> | I guess it has to be, since the result is irrelevant given that HTML5 is forkable anyway. |
| 20:08 | <Hixie> | AryehGregor: flash and gears both did significant research, effectively, into how to improve the web |
| 20:08 | <AryehGregor> | That could have been done with prototype standards too. |
| 20:08 | <wilhelm_> | Yes. A great way to establish cowpaths for us to pave later. (c: |
| 20:09 | <Hixie> | what's a "prototype standard"? |
| 20:10 | <AryehGregor> | Something where you devise it with the goal from the beginning of standardizing it, soliciting feedback early on and planning to retire it in favor an equivalent standard when one becomes available. |
| 20:10 | <Hixie> | othermaciej: any chair instructions at this time? (either on hgroup or on drawfocusring, or anything else for that matter) |
| 20:10 | <AryehGregor> | Like how a lot of new standards are developed. |
| 20:11 | <Hixie> | AryehGregor: proprietary extensions to UAs, you mean? |
| 20:11 | <AryehGregor> | Vendor-specific, let's say, yes. Could be extensions too. |
| 20:11 | <Hixie> | AryehGregor: sure. that's what flash is. :-) |
| 20:11 | <Hixie> | at least, up to the bit about adobe's intent |
| 20:11 | <Hixie> | dunno what their intent is |
| 20:12 | <AryehGregor> | There's no way to integrate Flash into web standards. It's a totally different platform. |
| 20:12 | <AryehGregor> | As opposed to adding features that are accessible from HTML/CSS/JS, and could be easily translated to standards. |
| 20:12 | <AryehGregor> | Plus, there's no attempt to get wider feedback or plan for multiple interoperable implementations from an early stage. That makes a big difference. |
| 20:13 | <Hixie> | it's a spectrum |
| 20:13 | <jgraham> | AryehGregor: Forking seems to be bad when people want to use it to create a platform that isn't the web |
| 20:13 | <Hixie> | i agree flash isn't in the ideal place on the spectrum for use as R&D |
| 20:13 | <Hixie> | it's still there, though |
| 20:13 | <jgraham> | But they do that regardless of the license so it's not a very strong argument against forking |
| 20:14 | <jgraham> | The best way to counter that is to make the web platform better |
| 20:14 | <jgraham> | And forking can be essential to that end |
| 20:18 | <Hixie> | there are lots of reasons why allowing forking is beneficial. as far as i'm aware, none of the arguments in favour of disallowing forking would actually prevent the problems they portend. |
| 20:18 | <Hixie> | that's the crux of the argument, imho. |
| 20:18 | <AryehGregor> | Hmm. |
| 20:19 | AryehGregor | tries rewriting a second time |
| 20:19 | <Hixie> | heh |
| 20:20 | <wilhelm_> | Diverging specifications isn't really a problem in itself. It's when there are diverging implementations the trouble starts. |
| 20:24 | <jgraham> | wilhelm_: To a point. But XHTML2 was damaging even though no one implemented it because W3C decided that what the world needed was a backwards-incompatible clean-up of HTML4 with no substantial changes in the feature set and a less forgiving parsing model. To get there they blocked (or tried to block) work on what was actually good for the web |
| 20:26 | <wilhelm_> | jgraham: Sure. And that triggered the 2004 fork, which is the one beneficial HTML fork among a pile of harmful ones. (c: |
| 20:27 | <AryehGregor> | Hixie, see, if the W3C could actually license HTML5 restrictively (no WHATWG copy), it would prevent forks very effectively, at least forks that plan to be compatible with existing contents. |
| 20:27 | <AryehGregor> | content. |
| 20:27 | <wilhelm_> | AryehGregor: Nah. You could do a diff spec. |
| 20:27 | <jgraham> | So one impact of granting others the ability to fork is that it lessens the burden of decision making because it is much more likely that someone will pick up the pieces if it all goes wrong |
| 20:27 | <AryehGregor> | wilhelm_, only if you wanted to change limited parts. |
| 20:27 | <AryehGregor> | Also, diffs might be derivative works. |
| 20:28 | <Hixie> | AryehGregor: WF2 was a diff spec of HTML4 originally |
| 20:28 | <jgraham> | wilhelm_: Aren't most of those bad forks actually diff specs? |
| 20:28 | <wilhelm_> | jgraham: Yes. |
| 20:28 | <jgraham> | It is at least unclear if that counts |
| 20:28 | <Hixie> | AryehGregor: it would significantly raise the barrier to creating a fork, but it wouldn't prevent it altogether. someone could always just start from scratch like we did. |
| 20:28 | <wilhelm_> | I'm in favour of a permissive license, but I disagree with anyone saying forks are good. (c: |
| 20:28 | <jgraham> | Especially if they take advantage of Modularization which positively encourages forking |
| 20:28 | <AryehGregor> | Yeah, but the amount of work you'd have to waste to replicate HTML5 would be ridiculous. |
| 20:29 | <Hixie> | AryehGregor: clearly, that's why it should be allowed |
| 20:29 | <AryehGregor> | That doesn't answer the original question. |
| 20:29 | <Hixie> | jgraham: good point |
| 20:29 | <Hixie> | jgraham: what's with that! |
| 20:29 | <AryehGregor> | You just said that "none of the arguments in favour of disallowing forking would actually prevent the problems they portend", but they'd actually do a lot to make serious forks harder. |
| 20:29 | <jgraham> | Hixie: I don't know. The W3C policy seems to be very inconsistent |
| 20:30 | <AryehGregor> | Not ones that just subsetted or added a handful of features, but they'd kill rewrites. |
| 20:30 | <AryehGregor> | jgraham, didn't you get the memo? Proprietary features count as standard if they have a colon in them. |
| 20:30 | <jgraham> | AryehGregor: I don't even know that you need a colon in this case |
| 20:30 | <jgraham> | Maybe you do |
| 20:31 | <jgraham> | But really it makes no difference to implementors |
| 20:31 | <AryehGregor> | I assume so. After all, otherwise the XHTML people would have had to not taken an opportunity to use namespaces, and I find that implausible. |
| 20:31 | <jgraham> | Yes, that seems like a reasonable argument |
| 20:32 | <AryehGregor> | Anyway, I see no strong arguments in favor of allowing forking at this point other than "We don't trust the W3C to do the right thing", and/or "The only ones who would bother really forking HTML5 instead of just doing a diff spec are implementers, and implementers are right by definition." |
| 20:33 | <jgraham> | Who said that implementors are right by definition? |
| 20:34 | <jgraham> | One can be quite wrong |
| 20:34 | <jgraham> | and be an implementor |
| 20:34 | <AryehGregor> | Well, a standard that implementers don't implement is kind of useless. |
| 20:34 | <jgraham> | e.g. one could add an <xml> element for xml data islands |
| 20:34 | <AryehGregor> | So as far as standardization goes, implementers are collectively right by definition, if by "right" you mean "listening to them is the only sensible thing to do". |
| 20:35 | <jgraham> | Yes, because in some market-dynamic way they reflect the will of the people |
| 20:35 | <AryehGregor> | No, independent of that. |
| 20:35 | <AryehGregor> | Even if they're totally wrong, you can't force them to implement what's right. |
| 20:36 | <AryehGregor> | You can only spec what's wrong. |
| 20:36 | <AryehGregor> | It's also true that implementers are directly responsible to users, unlike anyone else in this whole picture, so they're the best ones to decide things. |
| 20:36 | <jgraham> | No, but if they are totally wrong people won't upgrade to browsers with the new features |
| 20:36 | <AryehGregor> | Well, yes, if they're really extraordinarily wrong. |
| 20:36 | <jgraham> | Right |
| 20:36 | <AryehGregor> | Or if they're not so extraordinarily wrong, but only some are wrong and others are right. |
| 20:37 | <jgraham> | There's only so far off the rails an implementor can go |
| 20:37 | <AryehGregor> | Well, the same is true for a standards body. |
| 20:37 | <AryehGregor> | If they get too impractical, no one will follow the standards. |
| 20:37 | <AryehGregor> | But that's an extremely weak safeguard. |
| 20:37 | <AryehGregor> | It only kicks in at ridiculous levels of fail. |
| 20:38 | <wilhelm_> | It's not much of a standard if noone follows it, is it? (c: |
| 20:38 | <jgraham> | Yeah, but if the standard is proprietary and a huge amount of work to replicate it is hard to route around a rouge standards body |
| 20:38 | <jgraham> | wilhelm_: Don't tell the IETF that </rimshot> |
| 20:39 | <AryehGregor> | Likewise, if you have enough of a browser monoculture it can be hard to route around the browser even if it's terrible. |
| 20:39 | <jgraham> | Indeed. Browser monoculture is bad |
| 20:39 | <AryehGregor> | Eventually you will, in either case. |
| 20:39 | <wilhelm_> | jgraham: :P |
| 20:40 | <jgraham> | Happily these days we don't have a browser monoculture |
| 20:40 | <jgraham> | To be fair we also don't have a HTML5 spec monoculture |
| 20:40 | <AryehGregor> | We have multiple independent interoperable specifications of HTML5? |
| 20:41 | <jgraham> | Huh? |
| 20:41 | <jgraham> | We have the spec under multiple licenses managed by multiple bodies |
| 20:41 | <AryehGregor> | We only have one HTML5 spec, basically. It may come in several flavors, but it's basically one spec. |
| 20:41 | <jgraham> | If one goes insane we can use the other one |
| 20:42 | <jgraham> | I'm not saying that having differences is good |
| 20:42 | <jgraham> | It's not |
| 20:42 | <AryehGregor> | Well, so that's like saying we don't have a WebKit monoculture in mobile because the WebKit forks are under multiple licenses managed by multiple bodies. |
| 20:42 | <AryehGregor> | It's still WebKit. |
| 20:42 | <jgraham> | This is a critical difference between specs and implementations I think |
| 20:43 | <jgraham> | Although one can argue that a WebKit monoculture is better than an IE monoculture for this reason |
| 20:43 | <AryehGregor> | Or worse, because at least IE6 is a consistent target . . . |
| 20:43 | <AryehGregor> | (but maybe that makes it better, not worse) |
| 20:43 | <Hixie> | AryehGregor: arguments in favour of allowing forking: it motivates the w3c not to screw up again, it allows easier resolution of the situation if they do screw up again. |
| 20:43 | <AryehGregor> | (because it gives more room for competition) |
| 20:44 | <jgraham> | Flash is a consistent target |
| 20:44 | <jgraham> | I'm not sure it's also good |
| 20:44 | <AryehGregor> | Hixie, but at the same time also allows easier harmful forking, and it's non-obvious that that's a lesser problem. |
| 20:45 | <Hixie> | AryehGregor: can you describe a scenario where there is harmful forking? |
| 20:45 | <AryehGregor> | You'd have to argue either that harmful forks from a good spec are less of a problem than a single bad spec, or that license restrictions somehow disproportionately affect good forks. |
| 20:45 | <AryehGregor> | Hixie, WML was being discussed here a little while ago. |
| 20:46 | <jgraham> | I am personally of the opinion that the people who want to change the spec in a bad way and will be deterred by the license will also be open to reasonable arguments about why it is bad |
| 20:46 | <Hixie> | WML was written from scratch. No copyright can stop that. |
| 20:46 | <AryehGregor> | HTML5 was also written from scratch. |
| 20:46 | <Hixie> | indeed. |
| 20:46 | <wilhelm_> | It's still a fork of the Web, although not of the specification text. |
| 20:46 | <jgraham> | People who won't listen to reasonable arguments won't be deterred by the license |
| 20:46 | <AryehGregor> | But that's because HTML 4 and earlier were very short standards and easy to rewrite from scratch. |
| 20:47 | <Hixie> | so? |
| 20:47 | <Hixie> | forks of the HTML standard now are possible regardless of the W3C license |
| 20:47 | <AryehGregor> | Well, I guess WML would have been rewritten largely from scratch regardless, since the point was to be stripped-down. |
| 20:47 | <Hixie> | WML wasn't stripped down really, it was a new language altogether. |
| 20:47 | <jgraham> | wilhelm_: Since we can't stop people forking the web through any license text it seems relevant to note that a strict licence would have no effect vas a liberal one |
| 20:47 | <AryehGregor> | Its goal was to be stripped-down compared to HTML. |
| 20:48 | <AryehGregor> | jgraham, that's not an argument either way, though. |
| 20:48 | <Hixie> | AryehGregor: any other examples (even theoretical) of a bad fork? |
| 20:48 | <jgraham> | AryehGregor: It's an argument that WML isn't a valid reason to have a less permissive license |
| 20:48 | <Hixie> | AryehGregor: i'm having trouble understanding how a copyright could prevent it, that's why i'm asking for examples |
| 20:48 | jgraham | wonders if people consider ePub good or bad |
| 20:48 | <AryehGregor> | Hixie, I'm not familiar with the history here. |
| 20:49 | <wilhelm_> | jgraham: I agree. I'm in favour of a permissive license, with a big sticker that says “Forks are bad. Really. Don't go there.”. |
| 20:49 | <Hixie> | ePub, whether good or bad, happened again regardless of whether we allow forking or not |
| 20:49 | <wilhelm_> | That includes previously W3C-approved forks. |
| 20:49 | <AryehGregor> | jgraham, it's an argument that nothing is a valid reason to have a more or less permissive license, so we should stop wasting our time arguing about it. |
| 20:49 | <AryehGregor> | Which is a fair point of view, but doesn't favor either side. |
| 20:49 | <jgraham> | AryehGregor: Only if you ignore the arguments unrelated to extant forks |
| 20:50 | <AryehGregor> | jgraham, how does that follow? |
| 20:50 | <AryehGregor> | Hixie, so are you suggesting that bad forks would be disproportionately unlikely to actually want to use the existing specification text, or something like that? |
| 20:51 | <jgraham> | AryehGregor: I am saying that the ability to create WML is unaffected by the license. Nevertheless the knowledge that a specification can be forked if it diverges from what the community wants provides a useful measure of oversight |
| 20:51 | <Hixie> | AryehGregor: i am arguing that bad forks have happened and there's no reason to believe they'll happen more if we change the license |
| 20:51 | <Hixie> | AryehGregor: but that it is invaluable to have the _ability_ to fork in case the w3c screw up again. |
| 20:52 | <Hixie> | AryehGregor: the w3c should be the place people want to write specs not because they have a legal position of power, but because they are the best place to write specs. |
| 20:52 | <AryehGregor> | Hixie, but if you say changing the license would increase the ability to fork or threat of forking, surely it would also increase the incidence of forks? |
| 20:52 | <AryehGregor> | One has to go with the other, surely. |
| 20:53 | <Hixie> | AryehGregor: why? |
| 20:53 | <AryehGregor> | Hmm. |
| 20:53 | <Hixie> | AryehGregor: is there any evidence that people have avoided "harmful" forks because of the license? |
| 20:53 | <Hixie> | AryehGregor: or any evidence that since the whatwg has started, the number of "harmful" forks has increased? |
| 20:53 | <AryehGregor> | The license was much less relevant pre-HTML5 because it was relatively easy to rewrite from scratch, so that's not an argument either way. |
| 20:53 | <AryehGregor> | Now that's a good point. |
| 20:54 | <AryehGregor> | HTML5 has been permissively licensed since 2004, and we've seen no harmful forks that use much of its license text. |
| 20:54 | <Hixie> | it would be my contention that the people who make harmful forks don't care about the parts of the spec that make it hard to fork without a liberal license |
| 20:54 | <AryehGregor> | Right, that's what I was asking. |
| 20:54 | <Hixie> | the detailed content in teh spec is only useful for those who want interoperability |
| 20:54 | <wilhelm_> | AryehGregor: Depends on what other measures you take. The W3C can, say, stop endorsing forks. It can talk to those who have started forking elsewhere and ask them nicely to stop, and see if their problems can be solved within the existing specs. |
| 20:54 | <Hixie> | which by definition one does not need if one is forking harmfully |
| 20:54 | <AryehGregor> | Whether you thought good forks were disproportionately harmed by an anti-forking license. |
| 20:55 | <AryehGregor> | Okay, let me start on that rewrite again. |
| 20:55 | <Hixie> | i think forks that want to preserve compatibility with the work we're doing now are disproportionally affected by the license, yes. |
| 20:55 | <jgraham> | wilhelm_: FWIW I would very much like like W3C to do that |
| 20:55 | <Hixie> | or maybe another way to put it is that forks are affected by the license in proportion to how compatible they want to be with what they are forking from |
| 20:56 | <jgraham> | ePub 3 doesn't seem to have any normative UA conformance changes |
| 20:56 | <AryehGregor> | What does it do, then? |
| 20:57 | <wilhelm_> | jgraham: Yes, that could make a much greater impact than choosing one license over another. |
| 20:57 | <jgraham> | wilhelm_: I wonder why we are having this pointless series of votes than rather than doing stuff |
| 20:57 | <jgraham> | then |
| 20:58 | <wilhelm_> | Bikesheds are easy. Work is hard and expensive. |
| 20:59 | <AryehGregor> | ISO HTML doesn't allow client-side scripting? |
| 20:59 | <AryehGregor> | Did anyone actually ever use it. |
| 20:59 | <wilhelm_> | Telling people they are wrong on the Internet may even be entertaining. |
| 21:00 | <mpilgrim> | so when will we get RDFa5 that matches facebook's processing requirements? |
| 21:00 | jgraham | hasn't really found much to hate about ePub 3 yet |
| 21:00 | <jgraham> | mpilgrim: When hell freezes over? |
| 21:01 | <jgraham> | I suppose I should send the email suggesting to the RDFa people that they cut out 2/4 ways of writing values allowed in RDFa |
| 21:01 | <jgraham> | So that they can tell me "no" |
| 21:02 | <jgraham> | (but there do seem to be 4 mutually redundant ways of doing exactly the same thing) |
| 21:06 | <AryehGregor> | Okay, so what's HTML 4.1, exactly? |
| 21:06 | <AryehGregor> | I can't figure out. |
| 21:06 | <AryehGregor> | Oh, an a11y fork? |
| 21:07 | <AryehGregor> | Wait, do some of the HTML 4.1 supporters also oppose forking licenses? |
| 21:07 | <AryehGregor> | Steve Faulkner is listed as a supporter here: http://html4all.org/wiki/index.php/Mission_Statement |
| 21:08 | <AryehGregor> | As is John Foliot. Both said that cannot live with CC0/MIT, and support anti-forking licenses. |
| 21:08 | <AryehGregor> | . . . |
| 21:08 | <AryehGregor> | Hey, Philip Taylor is an HTML 4.1 supporter. |
| 21:08 | <AryehGregor> | Philip`, so what's it about, exactly? |
| 21:13 | <Hixie> | different philip taylor |
| 21:13 | <AryehGregor> | Oh. |
| 21:13 | <AryehGregor> | That's horribly confusing. |
| 21:13 | <Hixie> | he's no longer in the wg |
| 21:13 | <Hixie> | it was far more confusing when he was |
| 21:13 | <AryehGregor> | So Philip` is Philip Taylor, and that one's Philip TAYLOR? |
| 21:13 | <Hixie> | yes |
| 21:13 | <AryehGregor> | Kind of like Mike(tm) Smith? |
| 21:15 | <Philip`> | Sometimes he's just called Philip Taylor |
| 21:15 | <Philip`> | Usually it should be obvious which is which by the context :-) |
| 21:16 | <AryehGregor> | Now that I know there's two of you, it's pretty obvious, yeah. :) |
| 21:17 | <Philip`> | I don't understand the confusion - it's always been perfectly clear to me |
| 22:21 | <Hixie> | every browser except IE uses the last meta refresh. IE uses the first one. |
| 22:21 | <Hixie> | weird. |
| 22:32 | <jgraham> | Oh. ePub has badness hidden behind :s |
| 22:32 | <jgraham> | It seems to require XML Events support |
| 22:35 | <AryehGregor> | Okay, so now my response for the licensing survey is a bit short of 2000 words. Review appreciated: http://pastebin.com/PA7dZ2d1 |
| 22:39 | AryehGregor | is busy reviewing it right now himself, too |
| 22:39 | <karlcow> | hmmmm the lines 27 and 29 make me uncomfortable. |
| 22:40 | <AryehGregor> | Which parts, and why? |
| 22:41 | <karlcow> | difficult to explain, it might take a few lines :) let me try |
| 22:43 | <karlcow> | "W3C has failed very, very badly at its job" The W3C organization has followed the opinion of the W3C members who collectively, genuinely, decided to adopt XML as the future of the Web. The decision was not really made in 2004 but before that. |
| 22:43 | <AryehGregor> | Sure. That doesn't contradict what I said. |
| 22:44 | <AryehGregor> | It just explains the nature of and reasons for the failure. |
| 22:45 | <karlcow> | the really important workshop is not the one in 2004 |
| 22:46 | <karlcow> | the one in 2004 for me is the expression of the failures of communications and understandings, not a failure of a bad job. |
| 22:46 | <karlcow> | It's the abandon of negotiation from all parts participating |
| 22:46 | <karlcow> | no winners, only losers on every side |
| 22:47 | <AryehGregor> | The job of a standards body is to be a place where people want to develop standards. |
| 22:47 | <AryehGregor> | If, for any reason, groups that the standards body wants to attract decide to go someplace else, that's a failure of the standards body. |
| 22:48 | <karlcow> | It's a failure of the community as large |
| 22:48 | <karlcow> | the important workshop is here http://www.w3.org/MarkUp/future/ |
| 22:48 | <AryehGregor> | The real failure was not when the W3C decided to pursue XML. That turned out to be wrong, but there was reason to believe it was right at the time. |
| 22:49 | <karlcow> | http://www.w3.org/MarkUp/Group/HTML-Future-minutes.html (Members only) |
| 22:49 | <karlcow> | AryehGregor: exactly. that's the nuance which is missing. |
| 22:49 | <AryehGregor> | The real failure was when the browsers said "This isn't working for us and we need to support legacy content better", and the W3C refused to let them. |
| 22:49 | <AryehGregor> | That was in 2004. |
| 22:49 | <jgraham> | karlcow: I think the essential point is that whatever W3C was doing between it stopping work on HTML4 and starting work on HTML5, it wasn't "leading the web to its full potential" because the technology that it developed has been abandonded and the technology that is being used on the web was developed by an outside body |
| 22:49 | <karlcow> | It's why the license issue is a red herring |
| 22:49 | <karlcow> | because it is not a license issue |
| 22:50 | <jgraham> | Regardless of the reasons for the failure, the W3C failed by its own terms |
| 22:50 | <karlcow> | but a community issue on the way we accommodate a change of pace, way, direction and sometimes parallel works |
| 22:51 | <jgraham> | The license seems like a big part of how we accomodate parallel works |
| 22:51 | <karlcow> | nope |
| 22:51 | <jgraham> | and indeed changes of pace way and direction |
| 22:51 | <karlcow> | the license is how we dissolve a community creating a parallel work. It doesn't have the same constraints in terms of Contrat Social. |
| 22:52 | <jgraham> | Hmm? |
| 22:52 | <karlcow> | As in "Do we solve it together?" or "Go elsewhere do your own thing". I prefer the 1st option even if it's often more painful and longer. |
| 22:53 | <karlcow> | and because of the involvement of many people inside W3C, the work on html has finally been restarted. |
| 22:53 | <AryehGregor> | The work on HTML was restarted by Apple, Mozilla, and Opera in the WHATWG. Not by anyone at the W3C. |
| 22:54 | <Hixie> | not for lack of trying to get the w3c to restart it |
| 22:54 | <karlcow> | Basically a fork is a too easy answer for a "social" issue. |
| 22:54 | <jgraham> | I prefer the first option too. But the possibility of doing the second is critical |
| 22:54 | <jgraham> | karlcow: That's not really how I see this in practice |
| 22:54 | <jgraham> | People don't just go "oh well I'm forking" |
| 22:54 | <jgraham> | Because maintaining a fork is hard |
| 22:55 | <jgraham> | It's almost always better to solve the problem |
| 22:55 | <jgraham> | together |
| 22:55 | <jgraham> | But sometimes there are irreconcilable differences |
| 22:55 | <karlcow> | well if the cost of forking is super easy and really light, the fork will happen more often, and then you come into the social issue. No big will to maintain the value of the community |
| 22:56 | <jgraham> | karlcow: So why don't people create lots of forks of the WHATWG copy of HTML5? |
| 22:56 | <AryehGregor> | Forking a standard the size of HTML5 will never be anything but very hard. |
| 22:56 | <karlcow> | AryehGregor: I was working at W3C during that time, I have a different view on the issue ;) |
| 22:56 | <jgraham> | Or indeed of the huge numbers of open source projects |
| 22:56 | <AryehGregor> | People do create lots of forks of some open-source projects. |
| 22:56 | <AryehGregor> | The Linux kernel has about seventy bajillion forks. |
| 22:57 | <AryehGregor> | Many of which don't actually obey the license terms. |
| 22:57 | <karlcow> | jgraham: because there is little conflicts between the main proponents right now |
| 22:57 | <jgraham> | When there is a fork in a big open source project it almost always results in one or the other forks dying, or them coexisting for a while and remerging |
| 22:57 | <wilhelm_> | If a license is all that prevents a viable fork, the process and the standards body in question has already failed. |
| 22:58 | <karlcow> | wilhelm_: It's exactly why I think the license is not the right issue |
| 22:58 | <wilhelm_> | karlcow: Then we are in agreement on that point. (c: |
| 22:58 | <AryehGregor> | jgraham, well, if the fork poses itself as a competitor, yes. Not if it's meant for internal use or such. |
| 22:58 | <jgraham> | AryehGregor: The kernel is quite unusual I think. Things like emacs and XFree86 have had notable forks that followed the pattern I described |
| 22:58 | <karlcow> | I would prefer to modify the way the W3C works in terms of process and decisions to allow such a thing inside the organization. |
| 22:59 | <AryehGregor> | The kernel has never had any fork that actually intended to replace mainline, I don't think. |
| 22:59 | <jgraham> | AryehGregor: Right |
| 22:59 | <AryehGregor> | Just lots of forks that add specific features or whatnot, and maybe sync up with mainline occasionally. |
| 22:59 | <AryehGregor> | BSD has had forks that stayed permanently separate. |
| 22:59 | <AryehGregor> | But those are definitely the exception, not the rule. |
| 23:04 | <karlcow> | The HTML WG participants portrait was quite different more than 10 years ago. If you look at the 1998 workshop participants, there were a lot more content and authoring tools organization than now. |
| 23:06 | <karlcow> | For me the biggest issue is often are the implementers in the WG (any WGs), if not why, how do we detect that, how do we change that? This is the more interesting question which would really solve a lot of issues |
| 23:08 | <AryehGregor> | As long as the W3C can keep the implementers happy enough to stay their of their own free will, it doesn't have to worry about licensing. |
| 23:08 | <AryehGregor> | A license that allows forks is necessary in case implementers find the W3C to no longer be an acceptable place to develop HTML5, and are not able to resolve their issues by discussion. |
| 23:08 | <AryehGregor> | As happened in 2004, and could happen again. |
| 23:09 | <AryehGregor> | There are more than a few individual implementers who participate in the WHATWG and mostly ignore the HTMLWG as it stands, because they view the WHATWG as a better place to work. Otherwise the WHATWG would have been shut down. |
| 23:10 | <karlcow> | AryehGregor: That's why a more permissive license doesn't solve anything with the risk of higher costs such as we had to already bear with for the last 7 years |
| 23:11 | <AryehGregor> | HTML 4.01 wasn't worth forking, so license didn't matter in 2004. It matters with a spec as big as HTML5. |
| 23:11 | <Hixie> | it's a motivator for the w3c |
| 23:12 | <karlcow> | That's another issue ;) I do not think HTML5 is right in its current form ;) |
| 23:12 | <karlcow> | It should not be that big |
| 23:12 | <karlcow> | :) it should be separate documents |
| 23:12 | <karlcow> | but that's yet as I said a complete different issue |
| 23:12 | <zewt-> | (your :) key appears stuck) |
| 23:13 | <jgraham> | karlcow: The number of documents is irrelevant |
| 23:13 | <jgraham> | The platform is as big as it is |
| 23:13 | <AryehGregor> | The form isn't nearly as important as the substance. |
| 23:13 | <Hixie> | it should be fewer documents, imho, it would be far easier to maintain |
| 23:13 | <jacobolus> | karlcow: a fork is just the BATNA |
| 23:13 | <karlcow> | zewt-: because it is exactly the translation of my face. I'm very rarely aggressive |
| 23:13 | <Hixie> | and to keep track of what was considered part of teh platform |
| 23:14 | <Hixie> | but that's just my opinion, i don't mind how many documents we generate :-) |
| 23:14 | <karlcow> | Hixie: I know your position on it :) |
| 23:14 | <jgraham> | The fact that I have to look for some bits in a spec called "HTML5" and some in a spec called "device Orientation" and some in a spec called "CSS Backgrounds and Borders" is almost irrelevant to me |
| 23:15 | <AryehGregor> | Okay, new version: http://pastebin.com/BU6ghf5K |
| 23:15 | <jgraham> | Except that it is a bit harder to know where to find stuff when you don't know where to look |
| 23:15 | <karlcow> | jgraham: it's why I have never read War and Peace ;) |
| 23:16 | <jacobolus> | you should. it's fantastic. |
| 23:16 | <jacobolus> | :) |
| 23:16 | jgraham | sighs as another Opera employee falls into the TR/ trap :( |
| 23:17 | <karlcow> | jacobolus: puts it into small orthogonal chapters <kidding/> |
| 23:17 | <jacobolus> | karlcow: it's kind of tolstoy's whole theory of history that you can't do that :) |
| 23:18 | <karlcow> | heh |
| 23:19 | <karlcow> | jgraham: TR/ has its own issues which are not solved by one big document either. |
| 23:19 | <jgraham> | I prefer to think of HTML 5 as "Rememberance of Things Past" |
| 23:19 | <jgraham> | Not that I have read that |
| 23:20 | <jgraham> | karlcow: I'm not saying that TR/ is affected by the big/small document thing. TR belies a broken model of how specs work |
| 23:20 | <jacobolus> | AryehGregor: I agree that the "w3c has failed very very badly" bit could be rephrased to clarify your intent |
| 23:20 | <karlcow> | À la recherche du temps perdu - Proust. Exactly ;) |
| 23:20 | <AryehGregor> | jgraham, like how? |
| 23:21 | <jacobolus> | AryehGregor: I would put "within recent memory" before "failed badly" |
| 23:21 | <jacobolus> | also, skip the "very, very"; those don't really add much |
| 23:21 | AryehGregor | confused jacobolus with jgraham |
| 23:22 | <AryehGregor> | So "Unfortuately, such forks are not only theoretical, because in recent memory, the W3C has failed badly at its job."? |
| 23:22 | <jacobolus> | something like that |
| 23:22 | <AryehGregor> | Probably I could try to rewrite that part to be more convincing to W3C people, but I doubt my basic argument will ever be convincing to them, because they think the WHATWG fork was bad. |
| 23:24 | <jacobolus> | maybe something like "The need for such forks is more than a theoretical concern: within recent memory the W3C process broke down entirely...." |
| 23:25 | <AryehGregor> | What does that really change? |
| 23:25 | <karlcow> | "The HTML interested parties were not participating anymore in the old W3C HTML WG creating a structural fork on the technology." |
| 23:25 | <jacobolus> | AryehGregor: the current one makes it sound like the W3C is still failing |
| 23:25 | <AryehGregor> | Surely "has failed" is clearly past? |
| 23:26 | <jacobolus> | "X has failed" implies (at least possibly implies) an ongoing failure |
| 23:27 | <AryehGregor> | I guess so. |
| 23:27 | <AryehGregor> | Let me rephrase. |
| 23:27 | <jacobolus> | which is why I think if you put "within recent memory" before it's clearer |
| 23:27 | <AryehGregor> | karlcow, the W3C as an organization failed badly by being unwilling to accommodate the needs of its most key members. If you're not willing to accept that, then you're never going to like what I write. |
| 23:27 | <AryehGregor> | Blaming the failure on the members or whatever misses the point. |
| 23:27 | <karlcow> | "The browser vendors not finding a place to continue working on HTML had unfortunately to restart the work outside of W3C" |
| 23:27 | <Hixie> | we did find a place |
| 23:27 | <AryehGregor> | "Unfortuately, such forks are not only theoretical, because the W3C did fail badly at its job in recent memory." |
| 23:27 | <Hixie> | unfortunately the place turned us away :-( |
| 23:27 | <karlcow> | AryehGregor: "the needs of its most key members" |
| 23:28 | <karlcow> | history rewriting and focussing on one part of the Web :) |
| 23:28 | <AryehGregor> | karlcow, standards are worthless unless they're implemented. Implementers are the only essential members of a standards body. |
| 23:28 | <Hixie> | (actually we found two places, an incubator group and the htmlwg. both refused us.) |
| 23:28 | <jacobolus> | AryehGregor: that's better |
| 23:28 | <karlcow> | I know that browser vendors are important and have become more important in the last 10 years but tsss tsss |
| 23:28 | <AryehGregor> | If you lose non-implementers, the quality of your standards might suffer. If you lose the implementers, your standards are worthless. |
| 23:28 | <AryehGregor> | The entire point of a standard is to be implemented. |
| 23:29 | <AryehGregor> | Okay, anyone have other comments? Otherwise I'll submit it shortly. |
| 23:29 | <karlcow> | AryehGregor: agreed with losing implementers - this is the issue to solve |
| 23:30 | <AryehGregor> | And the W3C failed at it in 2004. Right? |
| 23:30 | <jacobolus> | AryehGregor: the argument that governments couldn't create forks of HTML if it had a license that forbid forking seems almost too laughable to answer |
| 23:30 | <karlcow> | before that |
| 23:30 | <AryehGregor> | jacobolus, yeah, I know. |
| 23:30 | <AryehGregor> | karlcow, they didn't leave until 2004. |
| 23:30 | <karlcow> | yes they did |
| 23:30 | <AryehGregor> | jacobolus, the patent argument is also crazy. |
| 23:31 | <AryehGregor> | karlcow, when was this? |
| 23:31 | <jacobolus> | yes |
| 23:31 | <jacobolus> | I don't know if including those answers improves your essay |
| 23:31 | <AryehGregor> | Maybe not. |
| 23:31 | <karlcow> | they stop participating to the HTML WG before 2004. You could read the *valid* frustration of people on www-html mailing list |
| 23:32 | <AryehGregor> | I'll remove those two paragraphs. |
| 23:32 | <karlcow> | erratas not being fixed, issue trackers not clear, comments not taken into accounts |
| 23:32 | <AryehGregor> | Shorter is better. |
| 23:32 | <AryehGregor> | karlcow, okay, fine. They didn't start working elsewhere until 2004, though. |
| 23:33 | <karlcow> | it's why I said structural fork before. They did work elsewhere individually by working in the bug trackers and slowly not participating to a deaf htmlwg |
| 23:33 | <jacobolus> | AryehGregor: in general, I think it's decently argued |
| 23:33 | <karlcow> | respective vendor bug trackers |
| 23:34 | <Hixie> | AryehGregor: 2003 actually |
| 23:34 | <AryehGregor> | Really? |
| 23:34 | <AryehGregor> | The spec seems to say 2004, in the history section. |
| 23:35 | <Hixie> | AryehGregor: what happened is that the browser vendors slowly dropped away until xforms came up for PR vote in 2003, at which point the frustration was enough that opera/mozilla/opera/and a few others asked for a rethink of the strategy |
| 23:35 | <Hixie> | some of us showed what could be done by writing "xforms basic", an early wf2 prototype spec |
| 23:36 | <Hixie> | the w3c responded by having a workshop in 2004 at which the various points of view were put forward |
| 23:36 | <Hixie> | then when that concluded with the creation of a doomed wg on compound documents and nothing for html, we announced the whatwg list and moved xforms basic to the whatwg site |
| 23:36 | <Hixie> | i was blogging a lot back then, you can see some of the history in my blog posts from 2003/2004 |
| 23:37 | <Hixie> | last copy of xforms basic was http://www.hixie.ch/specs/html/forms/xforms-basic-1 |
| 23:37 | <Hixie> | note how it was proposed as an xhtml m12n module :-) |
| 23:38 | <Hixie> | wow, some parts of that have lasted all the way to the current spec |
| 23:38 | <karlcow> | hmmm let's call this crash, the pink crash. That was surprising. Third crash today 2 with grayish screens and one with pink screen |
| 23:38 | <Hixie> | check out the table in appendix B |
| 23:38 | <Hixie> | that became the table in the <input> element section |
| 23:38 | <Hixie> | same styles and everything |
| 23:40 | <Hixie> | anyway, that's dated dec 2003 |
| 23:40 | <Hixie> | ooh, apparently wa1 predates the whatwg too: http://www.hixie.ch/specs/html/apps/web-apps-1 |
| 23:41 | <karlcow> | yup |
| 23:41 | <Hixie> | though almost everything there then became part of web controls 1.0 which then died |
| 23:41 | Hixie | leaves memory lane and gets back to work :-) |
| 23:43 | <karlcow> | I guess an archivist work could be done by going through the past HTML WG minutes and you could decipher who, when people participated. Mailing lists too. |
| 23:44 | <karlcow> | http://www.w3.org/MarkUp/Group/Archives (Member only) |
| 23:45 | <Hixie> | sadly that will all be lost to archeologists since it's all member-only |
| 23:45 | <Hixie> | hsivonen: yt? |
| 23:45 | <karlcow> | Hixie, tss tss |
| 23:46 | <karlcow> | Most of the libraries have old books not accessible. Archivists can still work :) |
| 23:46 | <Hixie> | tss tss? |
| 23:46 | <Hixie> | ? |
| 23:46 | <jamesr> | maybe in the future everyone will be a w3 member and have access |
| 23:47 | <karlcow> | jamesr: that's one possibility. :) |
| 23:47 | <Hixie> | even members don't have access to the team lists :-) |
| 23:48 | <karlcow> | As I do not have access to your private emails :) or anyone has access to the internal mails of any organizations. |
| 23:52 | <Hixie> | there's a moral difference between an organisation that has paying members and decides things for those members that then affect the entire world, and most other kinds of organisations |
| 23:52 | <Hixie> | certainly there will always be a need for private lists |
| 23:53 | <Hixie> | but e.g. the sub total of private e-mails in the whatwg in the past two or so years is literally zero, and i'm sure one couldn't say the same for the w3c. |
| 23:53 | <AryehGregor> | The WHATWG is vastly smaller. |
| 23:53 | <karlcow> | Hixie: comparing orange and tomatoes |
| 23:53 | <AryehGregor> | I don't think it's a moral issue, just an issue of effectiveness. |
| 23:54 | <Hixie> | AryehGregor: not that smaller. it has 1700 subscribers and a dozen "staff"-equivalent. |
| 23:54 | <karlcow> | transparency != trust |
| 23:54 | <Hixie> | karlcow: not sure the relevance of oranges, tomatoes, transparency, or trust here. i was just talking about archeologists of the future. |
| 23:55 | <AryehGregor> | Hixie, W3C lists combined surely have vastly more than 1700 subscribers. W3C staff and WHATWG steering committee are not at all comparable, W3C staff actually devote a significant fraction of their time to working at the W3C. |
| 23:56 | <karlcow> | archeologists of the future might have access to it. I don't know. I just know that the lists are archived. |
| 23:57 | karlcow | doesn't have a crystal ball |
| 23:59 | karlcow | found "voyager" again, the code name for the future of html4 |