| 00:11 | <Lachy> | I think the problem with figuring out how to improve the support for indeterminate checkboxes is that there aren't clear use cases to help determine whether or not submitting the indeterminate state to the server is necessary, or whether the state is merely something needed for UI |
| 00:11 | <Lachy> | I think the IE design is meant for UI-only use cases, not submission cases |
| 00:35 | <Hixie> | indeed |
| 01:17 | <gsnedders> | what does the s[i:j:k] syntax do in Python? |
| 01:18 | <gsnedders> | Ah, it changes the step |
| 02:41 | <weinig> | annevk5: ping |
| 03:48 | <Hixie> | woo, dreamhost use <canvas> in production! |
| 03:54 | <gsnedders> | Man, ElementTree's handling of namespaces sucks |
| 03:55 | <roc> | <canvas> is spreading. IE might have to implement it |
| 03:57 | <Hixie> | roc: i loved their announcement, too. something along the lines of "pretty graphs, except in IE". |
| 03:58 | <roc> | apparently IE8 standards-mode busts VML, so some of the <canvas> workarounds no longer work |
| 04:12 | <gsnedders> | Man |
| 04:12 | <gsnedders> | (Man, I'm saying man too much) |
| 04:12 | <gsnedders> | The RFC index doesn't actually give any reference about _where_ to get the RFC. |
| 05:39 | <gsnedders> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/#dom-document-getelementsbyclassname — what's a class? |
| 05:55 | <Hixie> | gsnedders: how do you mean? |
| 05:56 | <gsnedders> | Hixie: "that have all the classes specified in that argument, having obtained the classes by splitting a string on spaces." |
| 05:56 | <gsnedders> | Hixie: But splitting what? |
| 05:56 | <gsnedders> | Hixie: I assume all @class on HTML elements |
| 05:56 | <Hixie> | the argument |
| 05:57 | <gsnedders> | Hixie: "that have all the classes" |
| 05:57 | <Hixie> | yes? |
| 05:57 | <gsnedders> | Hixie: How does an element have a class? |
| 05:57 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#classes |
| 05:58 | gsnedders | realizes he missed the paragraph two paragraphs below |
| 05:58 | gsnedders | is dumb, again |
| 05:59 | <gsnedders> | Ignore feedback from me at 5am in the morning in the future :) |
| 05:59 | <Hixie> | k :-) |
| 06:01 | gsnedders | will live to regret that statement, probably |
| 06:02 | <gsnedders> | Yay! I have a refer file which has all RFCs in it. |
| 06:03 | <gsnedders> | There are some rather obvious bugs, though |
| 08:43 | <annevk5> | jruderman, you just left but in case you read the logs I suppose I can figure out if we want to share that today |
| 08:44 | <annevk5> | weinig, I am here now, haven't checked my e-mail yet though in case you e-mailed your question |
| 08:57 | Hixie | replies to an mpt e-mail and a jgraham e-mail from nov 2004 |
| 08:57 | hsivonen | finishes editing the normalization wiki page |
| 08:57 | mpt | is glad he's still alive to read the reply :-) |
| 08:57 | <annevk5> | Hixie, there is no base URL concept in HTML5 that I can use here? |
| 08:58 | <Hixie> | annevk5: as far as i can tell, the behavior you are describing is not one that anything in html5 has |
| 08:58 | <annevk5> | I wonder how to make it work in such a way that it will also work in Web Workers |
| 08:59 | <annevk5> | I suppose I have to provide a hook for Web Workers |
| 09:01 | <ap> | hsivonen: what's the URL for the normalization wiki page? I don't see it mentioned in the logs |
| 09:01 | <hsivonen> | ap: http://esw.w3.org/topic/I18N/CanonicalNormalization |
| 09:01 | <ap> | thx |
| 09:02 | <Hixie> | annevk5: yeah just add a hook that says "if the XMLHttpRequest object's constructor is not on a Window object, then the /XMLHttpRequest base URI/ is defined by another specification." or some such |
| 09:03 | <annevk5> | the problem is that currently it is wrong |
| 09:03 | <annevk5> | because currently it only has a base URL once constructed |
| 09:03 | <annevk5> | it needs to change so that the interface object has an associated base URL |
| 09:06 | <annevk5> | e.g. in case the interface object gets copied across Windows before any object creation takes place |
| 09:06 | <jgraham> | Interesting, it turns out that what I said in 2004 isn't entirely stupid |
| 09:07 | <annevk5> | "H:TML" is confusing |
| 09:08 | <hsivonen> | annevk5: the full title is long and I want to avoid expressions like "Mike's document" and "Hixie's document" |
| 09:09 | <Hixie> | i don't really think "The Markup Language" is the least ambiguous of names, but I'm not really sure what a better name would be |
| 09:10 | <annevk5> | it looks like a qname |
| 09:10 | <hsivonen> | annevk5: your imagination has been dirtied by XML! |
| 09:25 | <Hixie> | annevk5: should cssom be in charge of firing onresize and onscroll events? |
| 09:27 | <annevk5> | CSSOM View maybe, yeah |
| 09:27 | <annevk5> | though maybe not for this revision of that document |
| 09:27 | <Hixie> | is there an ETA on the revision that would include this? |
| 09:27 | <Hixie> | (for planning purposes) |
| 09:29 | <annevk5> | 2015? |
| 09:30 | <annevk5> | I don't really know, I want to work out XHR and CORS |
| 09:30 | <annevk5> | I suppose alternatively it could be included and it would just sit longer in WD status |
| 09:30 | <annevk5> | I don't really mind WD status, but some people do |
| 09:31 | <Hixie> | i can work with 2015, sure |
| 09:32 | <Hixie> | (you don't have a timetable for when things like xhr will be done?) |
| 09:32 | <annevk5> | I did, but then HTML5 raised the bar |
| 09:33 | <Hixie> | heh |
| 09:33 | <Hixie> | well html5's timetable has been pretty well established for several years now, you should have expected changes :-) |
| 09:33 | <annevk5> | also, implementors are not really helping that much (apart from when ap was still reviewing) so it's hard to figure out how much is still to be done |
| 09:34 | <Hixie> | ah |
| 09:34 | <Hixie> | you'll get better at estimating it with more experience i expect |
| 09:34 | <Hixie> | took me years to get an idea of how long it would take |
| 09:34 | <annevk5> | but now it is mainly figuring out how to deal with the base URL issue and event loops for XHR 1 |
| 09:34 | <annevk5> | for XHR 2 it depends on when the File Upload stuff gets done |
| 09:35 | <Hixie> | yeah i have a bunch of stuff waiting on file upload |
| 09:36 | <Hixie> | i think it's ridiculous that after years of people complaining about how html5 wasn't going to be ready for them in time, html5 is now blocking on other specs |
| 09:36 | <annevk5> | CORS is done, apart from non-normative details and server requirements and potential feedback from implementors |
| 09:36 | <Hixie> | cool |
| 09:37 | <hsivonen> | annevk5: so CORS will use Origin regardless of how the more general ID goes? |
| 09:37 | <annevk5> | hsivonen, there are three known implementations of CORS that use Origin and will ship soonish |
| 09:37 | <annevk5> | hsivonen, of which one at least has indicated it cannot be possibly changed |
| 09:37 | <hsivonen> | annevk5: ok. |
| 09:37 | <annevk5> | hsivonen, not counting Chrome here |
| 09:38 | <annevk5> | hsivonen, so I guess that although I appreciate the discussion on the HTTP WG mailing list, it's pretty much a done deal |
| 09:40 | <Hixie> | someone should tell the http group |
| 09:40 | <Hixie> | (not it!) |
| 09:40 | <annevk5> | "not it!"? |
| 09:41 | <annevk5> | I'm not sure they care much for reality, but I suppose I can give it try if the discussion surfaces again |
| 09:42 | <hsivonen> | Hixie: as in http://www.youtube.com/watch?v=VT8uiT_rZ5k ? |
| 09:43 | <Hixie> | "not it" is an idiomatic english expression meaning "i decline to volunteer for the responsibility that has most recently been put on the table" |
| 09:43 | <annevk5> | heh |
| 09:43 | <annevk5> | I love Borat |
| 09:48 | <annevk5> | time to go to work o_O |
| 10:23 | <annevk5> | so when describing use cases for CORS, would it be wrong to mention XMLHttpRequest, <eventsource>, @font-face, <?xml-stylesheet?>, XBL, etc. explicitly? |
| 10:24 | <Hixie> | no? |
| 10:24 | <Hixie> | why would it? |
| 10:25 | <annevk5> | ta, not sure |
| 10:49 | <Hixie> | zcorpan: yt? |
| 10:50 | <Hixie> | zcorpan: have you tested http://simon.html5.org/specs/html-color-attributes against IE by giving it random strings and checking the computed values? |
| 11:59 | <Hixie> | how can we work out the computer value of css properties in IE8? |
| 12:00 | <Hixie> | oh currentStyle |
| 12:00 | <Hixie> | not runtimeStyle |
| 12:03 | <annevk5> | the DreamHost thingie was "Pretty graphs unless $browser eq 'IE'." |
| 12:03 | <Hixie> | hm, zcorpan's algorithm doesn't seem to be right |
| 12:04 | <Hixie> | fails in about 13% of cases |
| 12:04 | <Hixie> | http://www.hixie.ch/tests/adhoc/html/parsing/color-attributes/001.html |
| 12:04 | <annevk5> | http://simon.html5.org/test/html/parsing/color-attributes/ has tests |
| 12:04 | <Hixie> | (12% rather) |
| 12:07 | <annevk5> | http://simon.html5.org/test/html/parsing/color-attributes/the-algorithm/ does seem to use random strings |
| 12:11 | <zcorpan> | Hixie: it doesn't match ie when the input is in the format "#rgb" |
| 12:11 | <Hixie> | hm |
| 12:11 | Hixie | pokes around |
| 12:11 | <zcorpan> | Hixie: we changed it to support pages that were written against ie pocket/firefox/safari |
| 12:16 | <Hixie> | no i get fails for other things too |
| 12:16 | <Hixie> | e.g. #3 |
| 12:19 | Hixie | gets more debug output |
| 12:20 | <zcorpan> | -> #030000 ? |
| 12:20 | <Hixie> | hm actually the problem is the way i'm reading the colors |
| 12:21 | <zcorpan> | oh yeah, currentStyle is weird in ie |
| 12:21 | <Hixie> | it's saying #3 => #300 instead of #030000 |
| 12:21 | <Hixie> | i wonder how to get around that |
| 12:22 | <zcorpan> | use <body bgcolor> and document.bgColor |
| 12:22 | <Hixie> | they serialise differently? |
| 12:22 | <zcorpan> | yes |
| 12:22 | <Hixie> | ok that's just fucked up |
| 12:23 | <annevk5> | though please spec document.bgColor as just reflecting the string value |
| 12:23 | <Hixie> | send feedback |
| 12:23 | <zcorpan> | annevk5: document.bgColor should take css into account |
| 12:23 | <Hixie> | (if it isn't already done) |
| 12:23 | <annevk5> | zcorpan, for compat with sites? |
| 12:23 | <zcorpan> | annevk5: think so but not sure |
| 12:24 | <annevk5> | I believe Opera doesn't do it |
| 12:25 | <zcorpan> | oh right we don't |
| 12:25 | <zcorpan> | nor do webkit and firefox |
| 12:25 | <zcorpan> | so i guess it's ok |
| 12:29 | <Hixie> | wtf |
| 12:29 | <Hixie> | i think i should do this tomorrow when i'm awake |
| 12:29 | <Hixie> | IE should have a label on the side |
| 12:29 | <Hixie> | "do not operate while drowsy" |
| 12:30 | <annevk5> | zcorpan, much rather have them as simply reflecting the DOMString than some interaction with the CSSOM |
| 12:32 | <Hixie> | zcorpan: http://www.hixie.ch/tests/adhoc/html/parsing/color-attributes/001.html shows some failures i don't think you are expecting |
| 12:32 | <Hixie> | nn |
| 12:32 | <zcorpan> | nn |
| 12:34 | zcorpan | also has http://simon.html5.org/test/html/rendering/color-attributes/ |
| 12:40 | <hsivonen> | I should probably file the hyphenation issue away as an example of a case of claims of internationalization needs gone too far, but we are able to recognize it because German and Swedish are more familiar to us. |
| 12:41 | <hsivonen> | which leaves the question of how many claims about the needs of unfamiliar (to us) languages have gone way beyond what's needed into the what might be nice to have department |
| 12:52 | <jgraham> | hsivonen: Correctly distinguishing between "nice to have" and "needed" is a generally difficult problem (and, I guess, people who are good at it, or even just get it right once, can become rather rich and/or famous) |
| 12:53 | <jgraham> | e.g. AIUI, HTML has rather a lot less features than earlier hypertext systems but it turns out they were not needed |
| 12:54 | <hsivonen> | Aside: I can't find a single non-normalizing text input method among the ones that ship with Leopard |
| 12:54 | <hsivonen> | although I'm not quite sure about Tibetan |
| 12:54 | <jgraham> | So it's not really a problem specific to i18n |
| 12:55 | <hsivonen> | jgraham: no, but with i18n it is too easy for people to portray they pet feature requests as something that others are under a moral imperative to implement to remove discrimination |
| 12:55 | <hsivonen> | s/they/their/ |
| 12:55 | <jgraham> | hsivonen: Indeed. |
| 12:56 | <hsivonen> | I become *very* skeptical about i18n "needs" when I learned what pet features of a handful of linguistics were paraded as needs of Finnish orthography in international committees |
| 12:59 | <annevk5> | to be honest, I don't think it's worth changing anything here; doing it at the equality checking level seems way to complex and doing it during parsing will most likely break scripts |
| 13:00 | <annevk5> | and doing it for a handful CSS identifiers as fantasai suggested in some issue she filed is also way too much complexity for very little gain |
| 13:01 | <hsivonen> | annevk5: if there indeed are still non-normalizing Vietnamese input methods on Windows, I do think it would be worthwhile to change them to behave like the OS X Vietnamese input method |
| 13:02 | <jgraham> | Having not read everything about the selectors thing, it seems like normalizing everything in the parser could have worked if that design was chosen from the start but now the right solution is probably to do nothing |
| 13:03 | <hsivonen> | fwiw, normalizing in the encoding decoder is the sane thing to do in the case of converting Windows-1258 to UTF-* |
| 13:03 | <annevk5> | jgraham, that would have averse affect if you had both NFD and NFC XML documents (which is possible) |
| 13:03 | <annevk5> | s/had/have/ |
| 13:03 | <zcorpan> | hmm i get ie8 to hang by just doing a seach-in-page |
| 13:03 | <annevk5> | s/affect/effects/ |
| 13:03 | <annevk5> | wow |
| 13:04 | <jgraham> | annevk5: What would have adverse effects? |
| 13:05 | Philip` | likes it when he can dump a bunch of bytes into a system and get pretty much the same bytes out again, and gets confused and unhappy when there's all sorts of fancy transformations going on in the middle |
| 13:05 | <annevk5> | normalizing the CSS document to NFC would cause it to no longer function with an NFD XML document |
| 13:06 | <hsivonen> | jgraham: I doubt that people who use XML as a surrogate for ASN.1 would like running normalization at all in their XML processors |
| 13:06 | <annevk5> | and congrats for finding more typos :) |
| 13:07 | zcorpan | fails to find failures in http://www.hixie.ch/tests/adhoc/html/parsing/color-attributes/001.html that he wasn't expecting |
| 13:08 | <jgraham> | annevk5: You would have to normalise everything, HTML, CSS, XML, (ECMAScript should already be normalised although there are ways to break that) |
| 13:09 | <hsivonen> | jgraham: do actual ECMAScript implementations normalize e.g. function names upon compilation? |
| 13:10 | <jgraham> | hsivonen: It is unclear to me what the ASN.1 problem is, how bad the problem is, and whether it's worse than the current problem |
| 13:10 | <jgraham> | hsivonen: Dunno. Will test |
| 13:11 | <hsivonen> | jgraham: the ASN.1 problem is using XML as a message format in distributed computing and wanting marshalling and unmarshalling to be *fast* |
| 13:11 | <hsivonen> | in which case it's probably a bad idea to use XML at all, but... |
| 13:15 | <annevk5> | jgraham, ECMAScript should not be normalized |
| 13:15 | <annevk5> | jgraham, there's an authoring requirement that ECMAScript is written in NFC, but that's all there is to it |
| 13:15 | <annevk5> | jgraham, I'd be fine with adding such an authoring requirement to CSS, HTML, and XML if that solves it for i18n |
| 13:16 | <jgraham> | annevk5: Hmm, I guess you can read the spec that way |
| 13:16 | <jgraham> | I had read it as "the text should be normalized to NFC when it is converted to UTF-16" |
| 13:16 | <jgraham> | but there's not much to support my reading |
| 13:17 | <jgraham> | Mind you there's not much I can see to support the idea that non-UTF-16 text can be used as source at all |
| 13:17 | <annevk5> | "Conforming ECMAScript implementations are not required to perform any normalisation of text, or behave as though they were performing normalisation of text, themselves." |
| 13:18 | <annevk5> | and "The text is expected to have been normalised to Unicode Normalised Form C" |
| 13:19 | <annevk5> | at best it's optional (which is exactly "best", it's bad) |
| 13:19 | <jgraham> | annevk5: In my mind I was making a distinction between "the ecmascript implementation" and "the rest of the web browser" where "the ecmascript engine" does nothing to text and "the rest of the web browser" converts it to UTF-16 NFC |
| 13:19 | <annevk5> | not exactly* |
| 13:20 | <annevk5> | jgraham, I see |
| 13:23 | <jgraham> | Anyway it seems that real browsers do not match my interpretation |
| 13:24 | <jgraham> | So add ECMAScript to my previous list |
| 13:55 | <hsivonen> | https://build.mozilla.org/tryserver-builds/2009-02-09_03:22-hsivonen⊙if/ might be of interest to those who have asked about HTML5 Gecko builds |
| 13:55 | <hsivonen> | (layout notification perf still sucks, though) |
| 13:56 | <ap> | hsivonen: one way to get non-NFC text on Mac OS X is to paste a file name from Finder into editable content in browser |
| 13:57 | <ap> | hsivonen: I want to add normalization to most pasting/dragging code paths in WebKit, but there will still be edge cases, not to mention other browser engines |
| 14:00 | <hsivonen> | ap: the exposure of HFS+ internal representation in various places in quite annoying |
| 14:00 | <hsivonen> | ap: including byte-oriented file system APIs |
| 14:18 | <takkaria> | hsivonen: oo, an OS X build |
| 14:22 | <jgraham> | hsivonen: Still crashes on startup for me :( |
| 14:30 | <zcorpan> | hsivonen: crashes on startup for me too (on win32) |
| 14:32 | <zcorpan> | hsivonen: also with a fresh profile |
| 14:34 | <annevk5> | wfm, cool |
| 14:35 | <annevk5> | Ubuntu FTW! |
| 14:40 | jgraham | also had Ubuntu |
| 14:48 | <annevk5> | did you unzip it in some random dir and then just run it from there without any other Firefox installation running? |
| 14:48 | <annevk5> | (and with that random dir being empty) |
| 15:00 | <jgraham> | annevk5: Yes |
| 15:04 | <annevk5> | weird |
| 15:04 | <Philip`> | jgraham: Are you running it in a way that makes it attempt to open the profile manager on startup? |
| 15:04 | <Philip`> | (I think I had problems with that when I tried it ages ago) |
| 15:05 | <jgraham> | Philip`: Oh yeah, I had forgotten that |
| 15:05 | <jgraham> | What is the magic option? |
| 15:06 | <Philip`> | jgraham: "-p profilename" or something, maybe? |
| 15:08 | <jgraham> | Ah, that kindof works |
| 15:11 | <jgraham> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cb%3E%3Ci%3E%3Cp%3Efoo%3C%2Fb%3E%3C%2Fi%3E seems to have broken rendering |
| 15:23 | <weinig> | annevk5: hey, I was curious what the reasoning behind the table with a caption exception in the getClientRects algorithm was |
| 15:25 | <annevk5> | legacy iirc |
| 15:25 | <annevk5> | these APIs originate with IE |
| 15:26 | <annevk5> | roc would be the best person to ask :) |
| 15:27 | <annevk5> | jgraham, hmm yeah |
| 15:28 | <annevk5> | hsivonen, http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cb%3E%3Cp%3Efoo%3C%2Fb%3E is a more minimal version of jgraham's bug |
| 15:35 | <zcorpan> | hmm doing firefox.exe -p default worked for me :) |
| 15:39 | weinig | annevk5: nods |
| 16:09 | <annevk5> | in the GNOME Terminal, is there a "clear" that removes all text so that when I scroll up after an operation I hit the place where I invoked "clear" rather than going back in history |
| 16:10 | <jgraham> | annevk5: What do you mean "go back in history"? Are you scrolling through your input history or just scrolling up the screen? |
| 16:10 | <jgraham> | s/screen/output/ |
| 16:11 | <Philip`> | annevk5: Do you mean something like the "clear" command? |
| 16:12 | <annevk5> | Philip`, yes |
| 16:12 | <annevk5> | jgraham, scrolling up the output |
| 16:13 | <Philip`> | annevk5: I suggest using the "clear" command, then |
| 16:13 | <jgraham> | Philip`: But clear (in gnome-terminal at least) just places the existing output further up in the scroll history, it doesn't remove it |
| 16:13 | <jgraham> | If that makes sense |
| 16:13 | <annevk5> | Philip`, I know about clear, it doesn't work as I want |
| 16:14 | jgraham | doesn't really know how to refer to the total amount of output that one can scroll over |
| 16:14 | jgraham | wonders if there is an easy way to make a suicidal subprocess in Python |
| 16:15 | <takkaria> | jgraham: "buffer", I believe |
| 16:15 | <jgraham> | Specifically I want something that will automatically kill itself after some timeout if it didn't already die but without having to do proc.wait() |
| 16:16 | <jgraham> | (which means that killableprocess.py isn't itself quite enough afaict) |
| 16:16 | <jgraham> | takkaria: Ah, yes, that would be it |
| 16:17 | <hsivonen> | jgraham: I cherry-picked a patch that was supposed to address one startup crash on intrepid |
| 16:18 | <jgraham> | annevk5: You can do Terminal - Reset and Clear in the menu, if that helps |
| 16:18 | <hsivonen> | It runs for me on Windows 7 |
| 16:18 | <jgraham> | hsivonen: It worked after I didn't go through the profile manager |
| 16:18 | <jgraham> | the codepath startup -> profile manager -> running instance seems to be the broken one |
| 16:19 | <hsivonen> | apparently the crash at startup also happens with fresh profile on the Mozilla servers. I wonder why it works for me. |
| 16:19 | <annevk5> | jgraham, "reset" is a command |
| 16:19 | <annevk5> | thanks |
| 16:20 | <annevk5> | it keeps input history and resets output |
| 16:20 | <annevk5> | neato |
| 16:21 | <hsivonen> | jgraham, annevk5: the foofoo case looks like the DOM and the CSS render tree get out of sync. I have no idea why. I'll investigate. thanks |
| 16:21 | <Philip`> | annevk5: "reset" doesn't seem to clear the scrollback history, at least in Konsole |
| 16:21 | <Philip`> | so it's not really any different to "clear" |
| 16:21 | <annevk5> | Philip`, it's different in GNOME Terminal |
| 16:22 | <Philip`> | (except that reset is more helpful if e.g. you've catted a binary file and it's messed up all the terminal output state) |
| 16:22 | annevk5 | actually tested it |
| 16:23 | <Philip`> | annevk5: I'm not doubting you, just wondering if it's a terminal-dependent thing, which apparently it is, so that's okay now :-) |
| 16:45 | <hsivonen> | doesn't crash for me on Windows XP, either |
| 16:50 | <gsnedders> | Man, this really isn't fun :\ |
| 16:51 | <gsnedders> | <http://www.w3.org/2002/01/tr-automation/tr.rdf>; is crazy |
| 16:52 | <jgraham> | gsnedders: Doesn't RDF make consuming arbitary data foolproof, even if you have no idea what the semantics of the data are? |
| 16:53 | <gsnedders> | I looked at one RDF lib for Python, and pretty much concluded, "WTF is this on about?" |
| 16:53 | <gsnedders> | I don't want a fucking graph. I want the data in that file. |
| 16:54 | <hsivonen> | gsnedders: the data is a graph. there's no tree. these aren't the droids you are looking for. |
| 16:54 | <Philip`> | It looks like a very tree-shaped graph |
| 16:54 | <gsnedders> | Touché Philip`. |
| 16:54 | <jgraham> | gsnedders: Curiously I did exactly the same thing with exactly that file last time you were working on this :) |
| 16:55 | <Dashiva> | They hide the non-tree links to fool you |
| 16:55 | <annevk5> | it looks suitable for line by line processing :) |
| 16:55 | <Philip`> | gsnedders: Can't you just use regular expressions? |
| 16:55 | <gsnedders> | Philip`: Hey, the XML parsing isn't the issue. |
| 16:55 | <gsnedders> | What's in <FirstEdition> seems more or less random |
| 16:56 | <jgraham> | Although I think I didn't mind the graphiness so much. |
| 16:56 | <hsivonen> | gsnedders: XML-data is self-describing |
| 16:57 | <gsnedders> | What the… XML went from /REC-xml to /xml/ |
| 16:57 | <gsnedders> | so doc:version-of doesn't even work |
| 16:57 | <hsivonen> | gsnedders: does it work if you reference URIs and follow redirects? |
| 16:58 | <jgraham> | I think I got hung up on the fact that rdflib seemed to want me to learn sparql just to access any data |
| 16:58 | <gsnedders> | jgraham: Me too |
| 16:59 | <gsnedders> | hsivonen: It doesn't actually redirect, it just treats them as identical |
| 17:05 | <gsnedders> | Also, if I just want to get what the current undated TR is, using doc:versionOf won't always work because of PERs |
| 17:08 | <annevk5> | hsivonen, seems you ended up in a wiki edit war :/ |
| 17:08 | <hsivonen> | annevk5: yeah |
| 18:26 | <yecril71> | The preferred image resolution can go as media option in Content-Type. |
| 18:26 | <yecril71> | (i.e. in Accept) |
| 19:22 | <gsnedders> | heh |
| 21:01 | <hober> | http://lists.w3.org/Archives/Public/www-tag/2009Feb/0040.html |
| 21:09 | <Philip`> | Hmm, Google says to use 301 redirects if you're moving your site, but what are you meant to do if you can't set up 301 redirects? |
| 21:10 | <Philip`> | (All I can do is upload static HTML files) |
| 21:10 | <Lachy> | Philip`, which hosting service are you using that only allows static HTML? |
| 21:11 | <Lachy> | are you sure you can't upload a .htaccess file or some PHP or python scripts, or something? |
| 21:11 | <gsnedders> | http://wiki.whatwg.org/wiki/FAQ — That needs a validating parser :( |
| 21:13 | <Philip`> | Lachy: My ISP's one, which hasn't really changed since at least 1996, except for increasing the disk quota to 20MB |
| 21:14 | <Philip`> | Lachy: Scripting is limited to a choice of 4 CGI scripts (count, imagemap, mailform, testform) |
| 21:15 | <Lachy> | have you actually tried using a .htaccess file? What happens? |
| 21:15 | <Philip`> | Lachy: I have tried it; nothing happens |
| 21:15 | <Lachy> | ok |
| 21:16 | <Philip`> | (Seemingly the server is running thttpd) |
| 22:25 | <Hixie> | zcorpan left last night after saying he didn't find any of the failures unexpected |
| 22:25 | <Hixie> | but he didn't say why! |
| 23:05 | <Hixie> | hm, looks like it was a bug in my escaping code |