| 00:20 | <sicking> | Hixie, ping |
| 00:20 | <Hixie> | wassup? |
| 00:22 | <sicking> | nevermind, shift-reload fixed it :) |
| 00:22 | <sicking> | though found a bug in workers spec: |
| 00:23 | <sicking> | "If the close event that this algorithm just added hasn't yet been dispatched, then abort the script currently running in the worker." |
| 00:24 | <sicking> | somewhere in there it should say to dispatch the close event i would have thought |
| 00:43 | <Hixie> | sicking: send mail? (just to me if you want, you can just paste your irc comments) |
| 00:43 | <Hixie> | i'm about to be afk |
| 00:43 | Hixie | sends his reply to Roy |
| 00:43 | <Hixie> | hopefully we'll get some clarity |
| 00:44 | sicking | is about to give up on discussion with roy |
| 00:44 | <sicking> | or rather, i already have |
| 00:44 | <sicking> | the question is if that should mean giving up on the whole discussion with TAG or not |
| 00:44 | <sicking> | i hope it doesn't mean that |
| 00:45 | <Hixie> | i wish the tag people would give clear explanations of wtf they want |
| 00:45 | <Hixie> | they all seem to want something different |
| 00:45 | <Hixie> | yet they use the same terms |
| 00:45 | <Hixie> | and in half the cases, we already do what they want |
| 00:45 | <Hixie> | anyway |
| 00:45 | <Hixie> | afk |
| 00:50 | <roc> | wait, is Roy Fielding in TAG? |
| 00:50 | <Philip`> | http://junkyard.damowmow.com/284 sort of backs up the idea that most static content was written before IE6, if you assume that all pages with last-modified dates are probably static content (because nobody bothers generating that header in dynamic pages) and that ~52% counts as "most" and if you ignore the obvious bogosity that leads to 13% of pages being last modified in the future |
| 00:51 | <Philip`> | roc: http://www.w3.org/2001/tag/ says no |
| 00:52 | <roc> | ew |
| 00:52 | <roc> | phew |
| 01:04 | <sicking> | wait, he's not in the TAG? |
| 01:04 | <sicking> | well then |
| 01:07 | <othermaciej_> | Philip`: any mod dates before 1990 are also probably false |
| 01:08 | <othermaciej_> | in fact probably most of the 1992s are false, given how few pages were on the web then |
| 01:22 | Hixie | considers renaming HTML5 to Web5 and seeing what people think of _that_ |
| 01:23 | <roc> | I recommend just "5" |
| 01:23 | <roc> | then people won't be able to complain about scope creep |
| 01:24 | <Hixie> | speaking of which, if we expand the scope we could include all of the DOM specs, CSS, HTTP, and XML into the same spec |
| 01:24 | <Hixie> | and SVG, too, while we're at it |
| 01:24 | <Hixie> | and MathML |
| 01:24 | <Philip`> | roc: Why bother with the version information at all? Just call it "" |
| 01:25 | <roc> | that's even harder to Google for |
| 01:25 | <Hixie> | that would solve that problem of multiple specs fragmenting the platform into different silos of technology |
| 01:34 | <sicking> | Hixie, well, so seems like this Roy guy is just a troll that we should ignore |
| 01:34 | <Hixie> | he's one the apache developers and vocal on the http wg |
| 01:35 | <Hixie> | i don't disagree that he's a troll, or at least, that he has opinions so far removed from what i see as reality that it has not been productive to communicate with him in general. |
| 01:35 | <sicking> | yep |
| 01:36 | <othermaciej> | he is considered an Important Web Architecture Person |
| 01:36 | <Hixie> | by whom? |
| 01:36 | <othermaciej> | see, that's why I used the passive voice |
| 01:37 | sicking | should do that more too |
| 01:37 | <othermaciej> | as a result of the acronym "REST" becoming popular, and him having invented it, many think therefore that he is an expert on Web architecture |
| 01:38 | <Hixie> | oh the REST nonsense is _his_ fault?! |
| 01:38 | <Hixie> | good to know |
| 01:38 | <othermaciej> | it was his PhD thesis |
| 01:38 | <othermaciej> | http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm |
| 01:39 | <Hixie> | i wish phd students were more like abarth and cjackson |
| 01:39 | <Hixie> | than roy and rburns :-) |
| 01:46 | <nessy> | we're not talking roy fielding, are we? |
| 01:46 | <gavin> | we are |
| 01:46 | <blooberry> | roy fielding? He's one of the main authors of the HTTP spec |
| 01:47 | <nessy> | http://www.ietf.org/rfc/rfc2396.txt |
| 01:47 | <nessy> | and of the original uri rfc |
| 01:47 | <nessy> | http://www.ietf.org/rfc/rfc2068.txt |
| 01:52 | <Hixie> | he's also the author of http://lists.w3.org/Archives/Public/public-html/2008Nov/0216.html |
| 01:55 | <roc> | ah |
| 01:55 | <roc> | gah |
| 01:55 | <Hixie> | that e-mail is fractally wrong, as far as i can tell |
| 01:55 | <Hixie> | that is, the more you study its flaws, the more flaws you find |
| 01:56 | <Hixie> | http://lists.w3.org/Archives/Public/public-html/2008Nov/0219.html was my reply |
| 01:56 | <roc> | yeah |
| 01:59 | <roc> | I'd be worried about responding ... it seems impossible to address all flaws, and therefore one risks appearing to tacitly endorse them |
| 02:00 | <Hixie> | did i miss any flaws? :-) |
| 02:03 | <roc> | "the original Firefox team has moved on" |
| 02:03 | <gavin> | bz corrected that one |
| 02:03 | <roc> | "in a year or two, there will be other fresh ideas on browsing |
| 02:03 | <roc> | implementations. Such has been the case for over 15 years now" |
| 02:04 | <Hixie> | i didn't even know where to begin with those two |
| 02:04 | <Hixie> | bz addressed the first one |
| 02:04 | <Hixie> | the second... i didn't understand it |
| 02:04 | <Hixie> | i mean, it's not untrue |
| 02:04 | <Hixie> | and i couldn't tell what assumed disagreement made him want to specify it explicitly |
| 02:06 | <roc> | he seems to be talking about browser engines, and no new competitive browser engine has appeared in the last five years |
| 02:06 | <othermaciej> | I think WebKit is the most recent fresh idea in browser engines |
| 02:06 | <othermaciej> | that has achieved any serious level of market success |
| 02:06 | <Hixie> | it's the last one i know about for sure |
| 02:06 | <roc> | right |
| 02:06 | <othermaciej> | and certainly innovation in html parsing was not something we ever did or wanted to do |
| 02:07 | <Hixie> | and one major point of html5 is to help make competition easier |
| 02:07 | <Hixie> | so as to introduce more such browsers |
| 02:07 | <Hixie> | so who knows what he meant |
| 02:07 | <roc> | anyway, measuring the wrongness of Roy's position with great precision is not a good use of our time |
| 02:07 | <Hixie> | but it is somewhat entertaining |
| 02:08 | <roc> | it's as compelling as any car wreck |
| 02:08 | <Hixie> | (more seriously, i really do wish i could understand his position, as it would help us address his concerns and hopefully reduce the number of times he complains) |
| 02:13 | <blooberry> | has he brought forward any of these concerns in the past in the WG? |
| 02:13 | <blooberry> | or is he apparently having a Bad Day (eg: he has always had some disagreements and something finally made him "snap") |
| 02:14 | <Hixie> | he's always complaining about html5 |
| 02:19 | <roc> | I think his position is quite clear. He has some false assumptions about Web browsers and Web developers, which you identified, and everything else flows from there. |
| 02:21 | <Hixie> | well hopefully we can correct those mistaken assumptions |
| 02:21 | <roc> | I'll bet money you can't |
| 02:24 | <roc> | you may impact lurkers who share some of those unexamined assumptions, though, so play on |
| 03:16 | <Hixie> | apparently i ignore feedback |
| 03:16 | <Hixie> | wow |
| 03:16 | <Hixie> | i wonder what these thousands of e-mails i've been replying to have been, if not feedback |
| 03:29 | <Hixie> | hmm |
| 03:29 | <Hixie> | window.resolveURL('test.html') or window.location.resolveURL('test.html') ? |
| 03:29 | <Hixie> | the former has more chance of clashing with scripts |
| 03:30 | <Hixie> | the latter might mislead authors when there's a <base> around |
| 03:30 | <sicking> | othermaciej, ping |
| 03:30 | <othermaciej> | sicking: yo |
| 03:30 | othermaciej | has a half-composed reply to Roy that he thinks better of |
| 03:30 | <sicking> | othermaciej, do you know where the ECMA spec for JSON lives? |
| 03:31 | <othermaciej> | sicking: you mean for the soon-to-be-standard JSON parsing API, or for the syntax of JSON? |
| 03:31 | <sicking> | othermaciej, both actually |
| 03:31 | <othermaciej> | sicking: the former is in ES3.1 drafts (see es3.x-discuss mailing list for latest draft link) and the latter is I believe an RFC |
| 03:31 | <sicking> | othermaciej, the latter more so |
| 03:32 | <othermaciej> | (IETF RFC) |
| 03:32 | <jcranmer> | http://www.ietf.org/rfc/rfc4627.txt |
| 03:32 | <sicking> | thanks! |
| 03:33 | <jcranmer> | thank awesomebar |
| 03:33 | <sicking> | othermaciej, is there a reason why it requires you to quote all attribute names? With double-quotes none the less? |
| 03:33 | <sicking> | othermaciej, took me quite a while to figure that one out |
| 03:34 | <othermaciej> | sicking: I am at a loss to explain any of the details of the JSON sytntax |
| 03:34 | <Hixie> | (fyi, s/none the less/no less/, probably) |
| 03:34 | <Hixie> | JSON syntax is Doug Crockford's brainchild |
| 03:34 | <Hixie> | as i understand it |
| 03:35 | <sicking> | bah, bummer |
| 03:35 | <Hixie> | ok window.location.resolveURL('foo'); will resolve the url 'foo' to an absolute URL |
| 03:35 | <Hixie> | then you can use that to pass the URL to a worker |
| 03:35 | <Hixie> | any objections? |
| 03:36 | <Hixie> | (sicking?) |
| 03:36 | <sicking> | Hixie, hmm.. the base thing seems like a problem :( |
| 03:36 | <sicking> | Hixie, or will that resolve against the base? |
| 03:36 | <Hixie> | it'll resolve against the base |
| 03:36 | <Hixie> | which is mildly confusing since Location doesn't have the base |
| 03:36 | <Hixie> | but oh well |
| 03:36 | <sicking> | right |
| 03:36 | <Hixie> | i'm scared of putting it on Window |
| 03:37 | <sicking> | don't feel strongly either way |
| 03:37 | <sicking> | right |
| 03:37 | <Hixie> | k |
| 03:37 | <Hixie> | well we'll try that |
| 03:37 | <Hixie> | and see who whines :-) |
| 03:40 | <sicking> | othermaciej, so i'd really like to be able to pass primitive values, such as 0 and false, through JSON.stringify/JSON.parse |
| 03:40 | <sicking> | othermaciej, i suppose that's not likely to happen at this point, right? |
| 03:40 | <othermaciej> | sicking: I haven't read up on what is spec'd for JSON |
| 03:40 | <othermaciej> | sicking: I think there is a desire to remain compatible with json2.js unless there is a major reason to do otherwise |
| 03:41 | <sicking> | othermaciej, ok |
| 03:41 | <othermaciej> | I think the root of a JSON structure has to be an array or object |
| 03:41 | <othermaciej> | so the strings "0" or "false" would not be valid JSON |
| 03:41 | <sicking> | othermaciej, the reason is that I want to allow JSON "values" to be passed through a bunch of the DOM APIs, such as postMessage or pushState |
| 03:42 | <sicking> | othermaciej, yeah, it seemed like that was what our JSON.stringify implementation accepted |
| 03:42 | <othermaciej> | sicking: that does seem like a good idea in general |
| 03:42 | <jcranmer> | A JSON text is a serialized object or array. |
| 03:42 | <sicking> | othermaciej, how so? |
| 03:42 | <othermaciej> | sicking: your idea |
| 03:42 | <Hixie> | sicking: i think when we define what is passed through postMessage(), we'll use something that is wider than JSON |
| 03:42 | <othermaciej> | " I want to allow JSON "values" to be passed through a bunch of the DOM APIs, such as postMessage or pushState" |
| 03:42 | <othermaciej> | I think you would want to define an extended JSON that can be either a JS primitive value, or a JSON-compatible object |
| 03:42 | <sicking> | i know what i said :) i was wondering why you didn't think its a good idea |
| 03:43 | <othermaciej> | I do think it is a good idea! |
| 03:43 | <othermaciej> | I said: "sicking: that does seem like a good idea in general" |
| 03:43 | <sicking> | oh :) |
| 03:43 | <Hixie> | man, you're so negative |
| 03:43 | <Hixie> | always saying ideas are bad :-P |
| 03:43 | <sicking> | what can i say |
| 03:43 | <sicking> | i hate stuff |
| 03:43 | <Hixie> | i meant maciej :-P |
| 03:43 | <othermaciej> | clearly it is what people expect of me |
| 03:43 | <jcranmer> | A JSON parser MAY accept non-JSON forms or extensions. |
| 03:44 | <Hixie> | go interoperability |
| 03:44 | <jcranmer> | I'd be surprised to find a JSON parser that couldn't parse the string "0" |
| 03:44 | <othermaciej> | sicking: anyway, I would make postMessage and pushState eventually use a string conversion algorithm which accepts either primitives or JSON-compatible objects, and deserialize on the other end |
| 03:45 | <othermaciej> | sicking: actually I guess it is not necessary per spec for it to even stringify; the implementation could serialize and deserialize however it wants |
| 03:45 | <sicking> | right, that's what bens patch does |
| 03:45 | <sicking> | (well, it does stringify, though that's not technically needed) |
| 03:46 | <Hixie> | right, i would just define a set of things that must be supported, and everything else would just be stringified |
| 03:46 | <Hixie> | not sure how to define it yet |
| 03:46 | <Hixie> | it's one reason i haven't specced it yet |
| 03:47 | <othermaciej> | one question is what to do with non-JSON-compatible object graphs |
| 03:47 | <othermaciej> | otherWin.postMessage({"a": 1, "b": 2, "c": document.body}) |
| 03:48 | <othermaciej> | I can think of at least 3 reasonable things to do |
| 03:48 | <othermaciej> | gotta head home |
| 03:48 | <othermaciej> | later folks |
| 03:53 | <Hixie> | null, exception, stringify? |
| 03:53 | <othermaciej> | null was not one I thought of |
| 03:53 | <othermaciej> | the two different ones were stringify generically at top level, vs stringify at JSON-compatibility failure point |
| 03:54 | <othermaciej> | so [object Object] |
| 03:54 | <othermaciej> | or something with [object HTMLBodyElement] somewhere in the middle |
| 03:54 | <othermaciej> | ciao |
| 03:55 | <deltab> | sicking: quoting names mean that there doesn't have to be a syntax rule for identifiers |
| 03:57 | <sicking> | deltab, how do you mean? {this: 0} should parse as {"this": 0} no? |
| 03:59 | <deltab> | yes, but {"foo:bar": 0} isn't equivalent to {foo:bar: 0} |
| 04:00 | <sicking> | sure |
| 04:00 | <sicking> | there can be parse errors |
| 04:01 | <sicking> | anyway, the discussion is moot since a decision has been made |
| 04:01 | <deltab> | I just thought you'd like to know why |
| 04:01 | <sicking> | sure, if you know why i'm curious :) |
| 04:02 | <deltab> | I don't |
| 04:02 | <sicking> | ah :) |
| 04:02 | <deltab> | I guess you're writing something |
| 04:03 | <sicking> | deltab, http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/017276.html |
| 04:03 | <sicking> | deltab, though unrelated to the quoting issue |
| 04:04 | <sicking> | deltab, the quoting issue came up because it took me about 5 times as long to test out the JSON support |
| 04:05 | <Hixie> | sicking: btw i definitely agree with the need to do this, and will be adding it in due course, though i'd really like to see more stability in those sections and implementation experience (thanks for sending this!) before i spec it out formally |
| 04:05 | <sicking> | Hixie, sounds good. Mostly wanted to check that people wasn't gonna get upset if we added support |
| 04:06 | <Hixie> | i don't think anyone thinks it's a bad idea, no. certainly i haven't heard anyone say it's a bad idea, and i've been floating around for a while. |
| 04:06 | <Hixie> | i'm a little apprehensive about how i'm gonna spec it, but we'll see |
| 04:22 | <sicking> | aboodman: you gotta stop top-quoting ;) |
| 04:23 | <jcranmer> | A: Because I said so. |
| 04:23 | <jcranmer> | Q: Why? |
| 04:24 | <aboodman2> | sicking: I usually bottom quote, not sure what was with me today. |
| 04:24 | <sicking> | aboodman2, cool :) |
| 04:24 | <aboodman2> | sicking: you top quoted too |
| 04:24 | <aboodman2> | sicking: were you just sticking to my convention or something? |
| 04:25 | <aboodman2> | I suppose I am getting lazy. |
| 04:25 | <sicking> | yeah, it's hard to reply to a top-quoted mail while bottom-quoting |
| 04:25 | <sicking> | i modified someone elses mail to bottom quote the other day and it seemed a bit rude |
| 04:25 | <sicking> | so i'll just be rude in here instead :) |
| 04:25 | <jcranmer> | bah, it's the internt |
| 04:25 | <jcranmer> | er, Internet |
| 04:26 | <jcranmer> | everything you're say is expected to be mangled and taken out of context |
| 04:26 | sicking | slaps jcranmer with a wet salmon |
| 04:26 | <sicking> | oh, sorry, i thought your point was that it's Internet, you're supposed to be rude :) |
| 04:26 | <aboodman2> | sicking: meh |
| 04:27 | <jcranmer> | oh, goodness gracious, no! |
| 04:27 | <jcranmer> | no one would be surprised if you were rude, though |
| 04:30 | sicking | slaps jcranmer with a pickled herring |
| 04:30 | jcranmer | eats the pickled herring |
| 04:30 | <sicking> | care for some sour-cream with it? |
| 04:31 | <jcranmer> | no, just ketchup |
| 05:40 | <Hixie> | sicking: i reformat and fix spelling and grammar mistakes in people's e-mails all the time :-) |
| 05:42 | <sicking> | Hixie, i'm a nicer guy than you :) |
| 05:42 | sicking | continues his new embrace of the way of the Internet to be rude |
| 05:42 | <Hixie> | sicking: :-P |
| 05:43 | <sicking> | sorry, in a grumpy mood today, backporting stupid patches to old stupid releases |
| 05:43 | <aboodman2> | the irc protocl makes me grumpy |
| 05:43 | <aboodman2> | protocol* |
| 07:26 | <Hixie> | hm the content model of <menu> is all wrong |
| 09:11 | <hsivonen> | As far as I can tell, the JSON practice towards errors in Draconianness |
| 09:11 | <hsivonen> | except when its not |
| 09:11 | <hsivonen> | which leads to interop trouble |
| 09:12 | <Hixie> | json is a mess |
| 09:14 | <hsivonen> | s/in/is/ |
| 09:17 | <hsivonen> | Hixie: do you have document.write test cases that I should walk through both with the spec and with the idea I sent to the list? |
| 09:18 | <Philip`> | Has anyone tested IE8's JSON implementation to see how spec-compliant it is? |
| 09:18 | <Hixie> | hsivonen: don't think so |
| 09:19 | <hsivonen> | Hixie: ok. did what I sent to the list look superficially reasonable? |
| 09:20 | <hsivonen> | I'm expecting that the following properties are true of the spec: |
| 09:20 | <hsivonen> | 1) If a given script has not document.written before, the insertion point is where the tokenization position is |
| 09:21 | <hsivonen> | 2) When the tokenizer reaches an insertion point, nothing can write to that insertion point any longer |
| 09:21 | <hsivonen> | (or if something document.writes to that point, it degenerates into case #1) |
| 09:21 | <Hixie> | i cannot offhand tell if the implementation strategy you describe is equivalent to the spec |
| 09:22 | <hsivonen> | Hixie: OK. I guess I'll try it and see if there are issues that I didn't consider |
| 09:22 | <hsivonen> | Hixie: thanks |
| 09:23 | <Hixie> | i'd just make an object that exposes a string that represents the concept in the spec, personally |
| 09:23 | <Hixie> | i.e. an object that has an insertion point and a current position |
| 09:23 | <Hixie> | and that keeps track of what strings have been inserted where |
| 09:24 | <Hixie> | so that it is transparent to the reader |
| 09:24 | <Hixie> | it could even do the CRLF expansion stuff transparently |
| 09:25 | <hsivonen> | doing CRLF expansion strictly before tokenization seems inefficient |
| 09:25 | <Hixie> | yeah this might not be the most efficient solution, certainly |
| 09:26 | <hsivonen> | Considering that HTML parsing is perf critical to a browser, I think I'm going to tolerate abstraction leaks here |
| 09:26 | <hsivonen> | or rather, not having a proper abstraction for the UTF-16 stream at all |
| 09:27 | <hsivonen> | Specifically, once the Unicode decoder has written data to a range of memory, I don't want to move that data |
| 09:28 | <Hixie> | yeah i was going to say that in general i advise against premature optimisation but in this case it may be a case where we know that that part will need optimising anyway |
| 09:51 | <hsivonen> | clearly, Roy Fielding has a different view of who are experts in the Web standards community |
| 09:52 | <jwalden> | sicking: so one reason, I think, is that JSON is then also a subset of Python syntax, but I don't know if that's an actual reason; simplicity might be, tho (same way XML requires attributes be quoted or something) |
| 09:53 | <Philip`> | jwalden: It's not a subset - Python doesn't have true and false and null |
| 09:54 | <hsivonen> | Philip`: but one could do |
| 09:54 | <hsivonen> | true = 1 |
| 09:54 | <hsivonen> | false = 0 |
| 09:54 | <hsivonen> | null = None |
| 09:54 | <hsivonen> | as boilerplate |
| 09:55 | <hsivonen> | although in practice, parsing JSON using anything but a dedicated JSON parser leads to interop problems |
| 09:55 | <Philip`> | Also Python doesn't seem to understand "\u1234" |
| 09:55 | <Philip`> | (since you have to do u"\u1234" instead) |
| 09:55 | <hsivonen> | good point |
| 09:58 | <Philip`> | That's why JSON is dangerous - people think they can parse it easily just by twiddling a few bits and using "eval" in their favourite language, and it sorts of works but isn't quite interoperable |
| 09:59 | <hsivonen> | I wonder what classes of products Roy has in mind that can't comply to HTML5 as written |
| 09:59 | <jwalden> | er, hm |
| 09:59 | hsivonen | avoids getting involved in the thread, though |
| 09:59 | <jwalden> | I could have sworn I read somewhere about that being true |
| 10:01 | <Philip`> | Oh, and even if Python did understand "\u1234" then it probably wouldn't understand "\ud800\udc00 etc" for non-BMP characters |
| 10:04 | <Philip`> | "Those [authoring] tools are developed based on language specifications and generic templates, not by "designing for current browsers" ..." - is he failing to consider that people actually design and develop and extend the markup templates and fragments generated by those tools, and that's basically the same as hand authoring? |
| 10:06 | <Philip`> | People write e.g. blog templates by writing some HTML in a text editor, telling the blog software to use it, then repeatedly testing it in their current browser and tweaking it until it looks alright |
| 10:07 | <Philip`> | and when we talk about "authors" we mean mainly those people (as far as I'm aware) rather than the people writing the textual content |
| 10:11 | Hixie | replies to roy |
| 10:15 | <Hixie> | ok bed time |
| 10:15 | <Hixie> | nn |
| 10:16 | <roc> | you made me look, and now I'm unhappy again |
| 10:17 | <Hixie> | aww |
| 10:17 | <Hixie> | i'm sorry |
| 10:18 | <roc> | people who say things like "a resident memory size of 141M is ridiculous", with no context at all, are very annoying |
| 10:19 | <hsivonen> | I'm sure there's a non-contrived context where Apache 2 takes 141 MB of resident memory |
| 10:20 | <Hixie> | my apache instance is taking upwards of half a gig |
| 10:20 | <Hixie> | 20mb per thread |
| 10:20 | <Hixie> | which is pretty insane too |
| 10:20 | <Philip`> | Resident, and not shared etc? |
| 10:21 | Philip` | tends not to worry until Opera's using ~1GB of memory, and then he restarts it and carries on |
| 10:22 | <Hixie> | my machine as a whole has 0kb swapped out, and about all that's running on it is apache |
| 10:22 | <Hixie> | and the total amount used is about 0.7gb |
| 10:22 | <Hixie> | so |
| 10:23 | Philip` | likes writing games, because you can get away with using half a gigabyte of RAM and nobody minds at all |
| 11:00 | <yecril71> | If an URI should mark a resource regardless of its form, |
| 11:01 | <yecril71> | the decision on which form to use should be entirely on the user agent. |
| 11:01 | <yecril71> | The author should have no say here. |
| 11:04 | <yecril71> | PUT and DELETE are outside the scope of user agents. |
| 11:04 | <yecril71> | User agents are for viewing content, not for publishing it. |
| 11:05 | <yecril71> | (except in the limited case of POST) |
| 11:08 | <yecril71> | An embedded device�s resources can be exhausted with setTimeout |
| 11:08 | <yecril71> | just as they can be exhausted with time update. |
| 11:09 | <yecril71> | If the user encounters a rogue site that does bad things to the device, |
| 11:09 | <yecril71> | he can just blacklist it so that it cannot do so any more. |
| 11:12 | <yecril71> | Oops, sorry, I was just repeating Adrian (unintentionally). |
| 11:17 | <Philip`> | URIs were a good idea because you could refer directly to concrete things - instead of saying "download this pretty document via FTP on example.org in /pub/stuff.pdf" you could say "download ftp://example.org/pub/stuff.pdf";. If you have to start saying "download http://example.org/pub/stuff using a PDF reader or with Accept:application/pdf" then that seems like a step in the wrong direction |
| 11:21 | <hsivonen> | Hixie: do you remember if Gecko has the kind of cache-related document.write behavior that we want to avoid with HTML5? |
| 11:38 | <hallvors> | URIs are a reasonable compromise between computers and humans |
| 11:55 | <yecril71> | Resources can have various representations, and the user is free to choose whatever representation suits him best. |
| 11:56 | <yecril71> | So I would rather say "Download this pretty document via HTML; |
| 11:56 | <yecril71> | oops, HTTP; |
| 11:57 | <yecril71> | the server will deliver your preferred format." |
| 11:57 | <hsivonen> | yecril71: with conneg, the user doesn't know what's available |
| 11:58 | <yecril71> | Well, if the preferred format is unavailable, the server can return the next preferred one. |
| 11:58 | <yecril71> | Why is the information of what is available needed? |
| 11:59 | <hsivonen> | yecril71: the automation is not needed |
| 11:59 | <hsivonen> | and the particular kind of automation suggested sucks |
| 12:03 | <hsivonen> | Somehow I'm not surprised: http://twitter.com/waka/statuses/1011080251 |
| 12:12 | <Lachy> | oh crap. Dmitry Turin has emailed me off list now about HTML6 :-( |
| 12:12 | Lachy | will not respond |
| 12:19 | hallvors | responds, realising part of the reason he reads public-html is that weird people are interesting :-p |
| 12:19 | <hallvors> | (I just said "noone will reply to that question because it's impossible to estimate and commercially sensitive information") |
| 12:20 | <Lachy> | hallvors, did Dmitry email you too? |
| 12:21 | <Lachy> | I would have told him that no-one is interested in implementing HTML6 at all, but he's on my do-not-respond list |
| 12:21 | hsivonen | guesses he emailed all Opera and Mozilla reps to the HTML WG |
| 12:22 | <hallvors> | no, just saw him on public-html. I'll see if that bait makes him too much of a nuisance. :-p |
| 12:22 | <Philip`> | yecril71: The hypothetical document is only pretty in PDF; the HTML one has ugly fonts and bad layout, which is why I was telling the hypothetical person to download the PDF |
| 12:23 | <hallvors> | yecril71: what type of content I think I'm getting is important to me. If I can choose between a .html and a .pdf link, I am in control. Content negotiation and extension-free links actually take that control away from the user. |
| 12:26 | Philip` | prefers to think about "things" rather than about "resources" and "representations", and considers a PDF document to be a thing, and wants to have a simple uniform way to refer to such things, because then the world is nice and simple and makes sense |
| 12:28 | hsivonen | sees http://html60.euro.ru/site/html60/ |
| 12:29 | <yecril71> | You can choose between .html and .pdf. |
| 12:29 | <yecril71> | You achieve that goal by setting your preferences. |
| 12:29 | <yecril71> | If the document in HTML is unusable, it should not be there in the first place. |
| 12:50 | <hallvors> | yecril71: I do NOT want to reconfigure my browser each time I need a specific variant of a resource. That is a rather silly suggestion. I happen to know how to do it (which most users don't) and even then it's a bad idea. |
| 12:51 | <mookid> | hey hey! someone else understands HTTP! |
| 12:51 | <mookid> | rejoice! |
| 12:52 | <mookid> | Philip`: read what I just posted to the mailing list - that approach breaks caching |
| 12:53 | <mookid> | if you have a seperate URL for each representation and you update one of those URLs |
| 12:53 | <mookid> | then caching will only account for the update to the one specific representation |
| 12:53 | <mookid> | the others will be considered unchanged |
| 12:53 | <BenMillard> | mookid, what do you do for the websites you make? |
| 12:54 | <mookid> | I'm implementing both URI and protocol level conneg because I have to :) |
| 12:54 | <mookid> | If HTML was good enough I'd just use HTTP conneg |
| 12:54 | <Philip`> | mookid: Even if all representations shared the same URL, then when I update the resource it'll often also be updating totally separate resources that provide an index of all resources and indicate their modification times, and resources that list recent changes to the site, and all sorts of other things |
| 12:55 | <BenMillard> | mookid, what did you do on previous website(s)? |
| 12:55 | <mookid> | if they're seperate reasources why are they at the same URL ? |
| 12:55 | <mookid> | BenMillard: that's not an argument you're just pointing out that HTML is insufficient |
| 12:55 | <mookid> | I agree with you on that. |
| 12:56 | <BenMillard> | mookid, I'm not making an argument or commenting on HTML's cababilities. :/ |
| 12:56 | <mookid> | If you read the original post on the mailing list I even pointed out that it would be best to have both options available. |
| 12:56 | <Philip`> | mookid: They aren't - there's e.g. http://example.com/exciting-document (which accepts GET and PUT as text/html or application/pdf), but also http://example.com/recent-changes-to-site (which is application/atom+xml or whatever it's called) |
| 12:57 | <Philip`> | mookid: so they're separate resources, at separate URLs, but updating one will cause changes to the other |
| 12:57 | <mookid> | right.. |
| 12:57 | <Philip`> | mookid: so any caching solution has to take into account the fact that updates to one URL might invalidate caches of another URL |
| 12:57 | <mookid> | why? |
| 12:57 | <mookid> | your designign your applications badly then. |
| 12:57 | <Philip`> | mookid: How else would it be designed? |
| 12:58 | <mookid> | well why would recent changes to site make a difference to exciting document? |
| 12:58 | <mookid> | that's a nonsense example |
| 12:58 | <Philip`> | mookid: When you change the exciting-document, that's a recent change to the site, so it'll cause the list of recent changes to change |
| 12:58 | <mookid> | BenMillard: I assumed you were going to accuse me of being ahypocrite because I have used URI's for conneg |
| 12:59 | <mookid> | I have to. |
| 12:59 | <mookid> | what value is there in caching that resource? |
| 12:59 | <mookid> | if it's constantly changing |
| 12:59 | <mookid> | that's a stupid example |
| 13:00 | <Philip`> | mookid: It's not constantly changing; it's only changing when something else (at a different URL) changes, which might be quite rare |
| 13:00 | <mookid> | well ten you would change the caching settings to reflect that |
| 13:00 | <mookid> | ... |
| 13:01 | <mookid> | it's not wise to cache documents that are beign altered on teh backend |
| 13:01 | <Philip`> | If the caching system is able to cope with updates to exciting-document invalidating the cache of recent-changes-to-site, then exactly the same system could cope with updates to report.pdf invalidating caches of report.html, so there wouldn't be the caching problem you mentioned |
| 13:02 | <mookid> | wow.. what a total and complete waste of developer time |
| 13:02 | <mookid> | my way is alot easier.. |
| 13:02 | <mookid> | caching systems support it out of the box.. |
| 13:03 | <mookid> | hey look - someone updated it - update the cache |
| 13:03 | <mookid> | they really are clever folks these HTTP guys |
| 13:03 | hsivonen | posits that according to REST lore, cacheability is regarded to be of higher importance than conneg |
| 13:04 | <mookid> | how many times do you hit a cache of some kind |
| 13:04 | <mookid> | do you know? |
| 13:04 | <mookid> | it's pretty often |
| 13:05 | <mookid> | and conneg works in conjunction with caching anyway.. if you use the HTTP conneg |
| 13:06 | <mookid> | that's the point I'm making.. |
| 13:06 | <mookid> | ! |
| 13:06 | <yecril71> | Each time you need a specific variant of the resource, you say |
| 13:07 | <BenMillard> | mookid, I was trying to figure out the conditions which made you feel existing features were insufficient for what you are doing. |
| 13:07 | Philip` | notes that his university has switched off its university-wide web cache because it wasn't worth continuing |
| 13:07 | <yecril71> | File.OpenIn AcrobatReader (for example). |
| 13:07 | <BenMillard> | which first requires me understand what you were doing before |
| 13:07 | <hsivonen> | mookid: my point is that if you need an additional datum to travel with the URI and you need the additional datum to derefence, the better design is to bake that datum in the URI itself |
| 13:07 | <mookid> | BenMillard: I've done a pretty good job describing it on the mailing list - I jeep having to repeat myself because people don't read my posts :( |
| 13:07 | <yecril71> | And the browser asks your favourite application |
| 13:07 | <yecril71> | to download the same resource in its favourite form. |
| 13:08 | <mookid> | hsivonen: that is complete nonsense..! |
| 13:08 | <hsivonen> | mookid: why? |
| 13:08 | <mookid> | additional datum? |
| 13:08 | <mookid> | the header is THERE in every request |
| 13:08 | <mookid> | HTML just provides no way of telling browsers how to do something intresting with it |
| 13:09 | <mookid> | the URI is for RESOURCE indentification.. not resource + representation identification |
| 13:09 | <hsivonen> | mookid: it's not there when you put the URI in a href. It's not there when you email an URI to someone. It's not there on IRC. It's not there in PDF, OOXML, ODF, etc. |
| 13:09 | <Philip`> | URIs are useful as a uniform way of referencing stuff, but if you now have to say "open http://{some URI} in Acrobat" then it's no longer a uniform way of referencing stuff |
| 13:09 | <mookid> | well shouldn't it be up to them how they decide to view the resource? |
| 13:10 | <mookid> | Philip`: YES IT IS |
| 13:10 | <mookid> | that's a GET on that URI |
| 13:10 | <mookid> | that's completely uniform |
| 13:10 | <mookid> | what are you talking abuot? |
| 13:10 | <mookid> | seriously. :/ |
| 13:10 | <hsivonen> | mookid: note that I don't accept as dogma that URIs should be used to identify abstract resources as opposed to be used for application-level network addressing |
| 13:10 | <yecril71> | Using File.OpenIn is uniform, it is even more uniform than using extensions in URLs. |
| 13:11 | <mookid> | hsivonen: that's because you incorrectly percieve HTTP as a transport protool |
| 13:11 | <mookid> | protocol |
| 13:11 | <mookid> | it's a TRANSFER ptorocol |
| 13:11 | <yecril71> | protocol |
| 13:11 | <mookid> | thanks.. :P |
| 13:12 | <mookid> | URI's are protocol level anyway |
| 13:12 | <hsivonen> | mookid: I said "application-layer" precisely to suggest the layer above the transport layer |
| 13:12 | <mookid> | and so.. |
| 13:12 | <mookid> | ignoreing that.. |
| 13:13 | <yecril71> | Content needs to be referenced, its particular representation does not. |
| 13:13 | <hsivonen> | Is the ISO C spec online with a paywall? |
| 13:13 | <yecril71> | Because it is content that matters. |
| 13:13 | <yecril71> | paywhat? |
| 13:14 | <mookid> | yecril71: you on WHATWG? |
| 13:14 | <hsivonen> | yecril71: a paywall is a thing where you have to pay in order to view documents behind the wall |
| 13:14 | <Philip`> | hsivonen: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf is a recent (most recent?) draft, and drafts are free |
| 13:14 | <hsivonen> | Philip`: thanks |
| 13:14 | <BenMillard> | mookid, can you link me to the message which describes the use-case where users of your website the current features lacking? I'm unable to find it... |
| 13:15 | <BenMillard> | s/website the current/website found the current/ |
| 13:15 | <mookid> | BenMillard: it's not a case of 'extra' ends.. it's better means.. |
| 13:15 | <Philip`> | "Septermber 7, 2007" (sic) - hmm |
| 13:15 | <yecril71> | I review the current progress at WHATWG. |
| 13:15 | <mookid> | well never mind HTTP lets concentrate on video tags! |
| 13:15 | <mookid> | serious business |
| 13:16 | <yecril71> | Or rather follow, since nobody is interested in my review :-) |
| 13:17 | <yecril71> | The ISO standards are on the ISO Web site. |
| 13:17 | <hallvors> | "content needs to be referenced, its particular representation does not" is a statement that I disagree with based on personal experience. I *often* want to reference a particular representation where multiple exist. |
| 13:17 | <mookid> | BenMillard: I just think HTML should do more to make HTTP more accessible |
| 13:17 | <mookid> | and you CANT |
| 13:17 | <mookid> | because |
| 13:17 | <mookid> | ... |
| 13:17 | <mookid> | HTML doesnt provide the mechanism for it |
| 13:17 | <mookid> | hello? |
| 13:17 | <mookid> | ! |
| 13:17 | <BenMillard> | sure it does, you just include the file extension at the end of the href value :) |
| 13:18 | <mookid> | that's using a URL for something it was never initially intended to do |
| 13:19 | <Philip`> | The whole web is being used for things it was never initially intended to do |
| 13:19 | <mookid> | well.. |
| 13:19 | <Philip`> | and that's good, because it's evolved to do things that people find useful |
| 13:19 | <mookid> | don't you think a new version of HTML is a good opporutity to fix that? |
| 13:19 | <mookid> | HTML has nothing to do with that |
| 13:19 | <mookid> | it's mor eof a hindrance than a help |
| 13:20 | <mookid> | look at the prevelance of javascript |
| 13:20 | <mookid> | moslty down to the failures of html/browsers |
| 13:20 | <mookid> | ajax is slightly difference |
| 13:20 | <mookid> | different |
| 13:20 | <yecril71> | Nothing precludes the particular representations from having their separate URIs. |
| 13:20 | <mookid> | and there's that^ |
| 13:21 | <mookid> | support HTTP - whcih is both methods |
| 13:21 | <yecril71> | However, the only use case for that I can think of is internal editorial review. |
| 13:21 | <mookid> | don't take that descision away from develoeprs |
| 13:21 | <mookid> | that's arrogant and it's wrong |
| 13:22 | <yecril71> | I still think the choice of format is on the viewer. |
| 13:22 | <Philip`> | The whole point of standards is to take decisions away from developers |
| 13:22 | <mookid> | er |
| 13:22 | <mookid> | the whole point? |
| 13:23 | <Philip`> | I might be exaggerating :-p |
| 13:23 | <yecril71> | It also helps the authors to produce reliable content. |
| 13:23 | <yecril71> | And it can help end users in obtaining technical support from their providers. |
| 13:24 | <mookid> | I love how hyper text's markup language has complete contempt for it's transfer protocol |
| 13:24 | <Philip`> | The whole point of standards is to take decisions away from developers and authors |
| 13:24 | <mookid> | the attitude of "well yeah they put that in but we dont need it" |
| 13:24 | <mookid> | what exactly did the HTTP guys produce an rfc for if it wasnt to tell you guys how to use their protocol properly |
| 13:25 | <mookid> | ? |
| 13:25 | <Philip`> | (as evidenced by standards being written as a set of restrictions and requirements on developers and authors) |
| 13:25 | <mookid> | like an rfc? |
| 13:25 | <yecril71> | HTTP and HTML should be kept separate. |
| 13:26 | <yecril71> | They meet at the implementor�s desk, and both are binding. |
| 13:26 | <yecril71> | HTML is for HTTP, but not vice-versa, since HTTP can trasfer other resources equally well. |
| 13:27 | <yecril71> | What did I say? It should be HTTP is for HTML. |
| 13:28 | <yecril71> | Since HTTP is not limited to HTML, there is no need for HTML to mirror HTTP in full. |
| 13:29 | <yecril71> | I hope this makes sense. |
| 13:35 | <Dashiva> | Is Smylers in here? |
| 13:37 | Philip` | frowns |
| 13:39 | <mookid> | I'm being asked to explain the advantages.. I'm giving them: It makes use of HTTP conneg and appropriate use of URIs.. |
| 13:39 | <mookid> | when I do that |
| 13:39 | <mookid> | I get the response |
| 13:39 | <mookid> | "real world examples please" |
| 13:40 | <mookid> | wel.. there are very few real world examples ebcause the browser support isnt there |
| 13:40 | <mookid> | that doesnt exactly encourage use does it |
| 13:40 | <mookid> | it encourages the complete opposite |
| 13:40 | <mookid> | (conneg in URIs) |
| 13:41 | <mookid> | it's like dealing with politicians or something.. constantly arguing circles so that it ends up being too late to do anything about it |
| 13:43 | <mookid> | the issue here is that the benefits are hard to understand because you have to ignore your preconceptions about what a URI is and how conneg should work |
| 13:43 | <mookid> | it's viewed as 'difficult' because its a change to what people are used to thinking |
| 13:44 | <mookid> | there are obvious benefits of using protocol level conneg with HTTP.. if there weren't - they wouldnt have spent the time including it in the HTTP spec |
| 13:45 | <mookid> | the fact that it is not used is a criticism of HTML and browsers |
| 13:45 | <Philip`> | It doesn't have to be examples that already exist in the real world and use the feature that doesn't exist - it's more about concrete examples where a realistic developer would encounter a problem and the best way to solve the problem would be the proposed solution, rather than abstract ideas like "supporting HTTP is inherently good" |
| 13:45 | <mookid> | what like the examples I gave |
| 13:45 | <mookid> | of telling people theres a report at a given URI |
| 13:45 | <mookid> | and they can use several different UA's ? |
| 13:46 | <hallvors> | ..my counter-claim is that those URLs are more usable with extensions.. |
| 13:46 | <mookid> | more usable? |
| 13:46 | <Philip`> | mookid: Yes, like that |
| 13:47 | <mookid> | read the latest email I wrote - it's completely confusing |
| 13:47 | <mookid> | if I update report.pdf.. does that update report.html ? |
| 13:47 | <Philip`> | mookid: (but in that example, people aren't convinced that it's easier than providing a different URI for each UA, so they want more convincing examples) |
| 13:47 | <ehird> | hallvors: i disagree |
| 13:48 | <mookid> | right.. they're two seperate methods |
| 13:48 | <mookid> | that both 'work' |
| 13:48 | <mookid> | having content negotiation in the URI has massive potential for misleading users, actually |
| 13:51 | <mookid> | at th end of the day.. the benefits are that you support HTTP transactions in browsers better - yuo provide more options for developers to use URIs appropriately.. whilst at the same time protecting backwards compatability |
| 13:52 | <mookid> | if the Accept attribute is optional, it makes no difference to developers who insist on using URIs for conneg |
| 13:52 | <mookid> | and gives the ability to those who would like to.. do I have to do market research or can we all be grown up about it? |
| 13:53 | <Philip`> | mookid: But one method (separate URI per target UA) already works, and the other would require dozens of browser developers to spend time writing and testing and security-analysing and documenting the feature and would result in some users being unable to use some sites because they haven't upgraded their UA yet, so it has a non-negligible cost |
| 13:54 | <mookid> | security analysing? |
| 13:54 | <mookid> | at the moment the browser sends Accept */* |
| 13:55 | <Philip`> | Someone might write <a href="whatever" accept="

oh no it's an unexpected request body"> and that'd be kind of bad, so you'd have to make sure nobody can do that |
| 13:55 | <mookid> | Actualyl there are clever things you can do at the server side to look at the client - if that was a problem |
| 13:55 | <mookid> | so you wouldn't necessarily have to update the UA |
| 13:56 | <mookid> | why would that be bad? |
| 13:56 | <mookid> | explain to me why that's bad |
| 13:57 | <mookid> | it's stupid.. but I can't see how "allowing" that is inherently a bad thign |
| 13:57 | <Philip`> | It would be bad for the same reasons that XMLHttpRequest doesn't let you set arbitrary HTTP headers, and blacklists things like "Host" and "Referer" |
| 13:57 | <mookid> | what reason is that? |
| 13:57 | hsivonen | agrees with hallvors about wanting to address particular representations |
| 13:58 | <mookid> | that's because that's what you're used to |
| 13:58 | <mookid> | it's just fear of change |
| 13:58 | <hallvors> | mookid: look up HTTP request splitting |
| 13:58 | <mookid> | why? |
| 13:59 | <hallvors> | it's a cache-poisoning technique that causes potential security problems |
| 13:59 | <mookid> | and..? |
| 13:59 | <Philip`> | mookid: Some sites trust Referer to check that users came from the right place, to prevent dangerous cross-site requests, and that works now because Referer is only set by UAs and an attacker can't set it to an arbitrary value |
| 13:59 | <hallvors> | that's why adding methods to set http headers must be done very carefully |
| 13:59 | <mookid> | hahahahaha |
| 14:00 | <mookid> | that's awesome |
| 14:00 | <mookid> | does security by obscurity mean anything to you? |
| 14:00 | <hsivonen> | mookid: in general, "if there weren't - they wouldn't have spent the time of including it in the HTTP spec" is a bogus argument |
| 14:00 | <mookid> | no it's not.. they designed the protocol they would knwo the most appropriate way of using it |
| 14:00 | <mookid> | en dof |
| 14:01 | <mookid> | the fact that HTML has FAILED miserably to provide adequate mechanisms for making full use of their protocol |
| 14:01 | <mookid> | and so it is common place for peolpe to hack conneg into URIs |
| 14:01 | <Philip`> | mookid: Sure, but the Referer thing can actually achieve its goal of making it impossible for a user using a standard web browser to be tricked into making cross-site requests |
| 14:02 | <mookid> | what has that got to do with anything? |
| 14:02 | <hallvors> | if they didn't consider "URL usability" when authoring the specs they may have drawn the wrong conclusions.. |
| 14:02 | <mookid> | well they did.. |
| 14:02 | <mookid> | URLs (funnily enough) are used to locate resoruces |
| 14:02 | <Philip`> | It's a bit of a rubbish way of doing it, but it works in practice, so people rely on it, so browsers can't now start violating the assumptions people made, so they have to be very careful about how a web page can control the HTTP requests they send |
| 14:02 | <mookid> | resources.. and nott representations |
| 14:03 | <hsivonen> | mookid: in general, it's bogus to assume that the WG that defined HTTP 1.1 (or HTML 4) was axiomatically enlightened but that the WHATWG isn't equally axiomatically enlightened |
| 14:03 | <hallvors> | well, I disagree that the result is usable :) because I want to identify representations.. |
| 14:03 | <mookid> | well from what I've read so far I'm onyl seeing circular disstractive arguments |
| 14:03 | <mookid> | so I'd say that wouldn't be a bad guess |
| 14:03 | <hsivonen> | to be clear, I'm not suggesting that the WHATWG is axiomatically enlightened. I'm suggesting that the HTTP 1.1 spec can contain bad stuff. |
| 14:04 | <Philip`> | Clearly the WHATWG should write HTTP5 which defines Uniform Representation Identifiers, and then we'd be okay |
| 14:04 | <hsivonen> | Philip`: nope, Locators! |
| 14:04 | <mookid> | you havent even given HTTP conneg a decent shot |
| 14:04 | <mookid> | so that is ridiculous logic |
| 14:05 | <Philip`> | hsivonen: Whatever, they're basically the same thing :-p |
| 14:05 | <mookid> | Uniform Resource and/or Representation Indentifiers |
| 14:05 | <mookid> | no.. no they arent. |
| 14:05 | <hsivonen> | Hixie: we should call the things that are not quite URIs in the HTML5 spec "Uniform Representation Locators" |
| 14:06 | <Dashiva> | Can't we endlessly debate what makes a Resource instead? |
| 14:06 | <hsivonen> | http://lists.w3.org/Archives/Public/www-tag/2008Mar/0026.html |
| 14:06 | <ehird> | well, a representation has to be a representation of SOMETHING |
| 14:06 | <ehird> | and resource is the generic term for something that can be represented, I guess |
| 14:07 | <Philip`> | hsivonen: Why does the acronym need to have an expansion? Just define it as an atomic term whose meaning is defined by some spec and not by a three-word description |
| 14:08 | <jcranmer> | like ISO |
| 14:08 | <mookid> | ehird: exactly. |
| 14:08 | <ehird> | hmm |
| 14:08 | <ehird> | you can represent a representation |
| 14:08 | <ehird> | os representations of resources are resources |
| 14:08 | <ehird> | xD |
| 14:08 | <ehird> | bizarre, but consistent |
| 14:09 | <mookid> | sure, there's nothing to say you cant do that in the http spec either |
| 14:09 | <ehird> | everything is a resource, a representation is of a resource. |
| 14:09 | <ehird> | representations are just a subset of resources |
| 14:09 | <mookid> | hmm |
| 14:09 | <mookid> | not really |
| 14:09 | <jcranmer> | it doesn't matter what the spec says |
| 14:09 | <Philip`> | If I can represent *any* representation, and representations represent resources, then all representations are resources, so we might as well call them all the same thing :-) |
| 14:10 | <jcranmer> | it matters what who implements the spec do |
| 14:10 | <ehird> | mookid: why not? |
| 14:10 | <ehird> | Philip`: well, yes, but |
| 14:10 | <ehird> | there are resources that are not representations |
| 14:10 | <hsivonen> | at the end of the day, representations are what cross the wire, so resources don't matter as much |
| 14:10 | <mookid> | jcranmer: well no it doesnt from my perspective - I know what the best practice is and why it would work - I've spent a while studying it |
| 14:10 | <ehird> | hsivonen: exactly |
| 14:10 | <ehird> | you can't send me, a person over the wire |
| 14:10 | <mookid> | that's how you see it at the moment.. |
| 14:10 | <ehird> | but you can send a representation of me over the wire |
| 14:10 | <ehird> | and yet that representation is also a resource |
| 14:10 | <mookid> | you're all looking at URIs in tehw ay they're used at the moment |
| 14:10 | <ehird> | just one that happens to not be in meatspace |
| 14:11 | <mookid> | can we just step back from that a second |
| 14:11 | <jcranmer> | mookid: example |
| 14:11 | <ehird> | mookid: sure, if you give us some reasons why |
| 14:11 | <jcranmer> | HTML is SGML, by definition |
| 14:11 | <jcranmer> | ever try using the advanced SGML features in HTML? |
| 14:11 | <mookid> | why do you ask? |
| 14:11 | <jcranmer> | in practice, then, HTML uses a subset of SGML |
| 14:11 | <Lachy> | jcranmer, HTML5 is not SGML by definition |
| 14:12 | <jcranmer> | Lachy: lemme clarify... HTML 4.01 |
| 14:12 | <jcranmer> | (hence why HTML5 is not SGML AIUI) |
| 14:12 | <mookid> | I still dont understand why it's so bad to include an optional attribute that will significantly help RESTful developers |
| 14:12 | <mookid> | is it laziness? |
| 14:12 | <mookid> | what? |
| 14:12 | <ehird> | mookid: what exactly is it |
| 14:12 | <ehird> | i'm uninformed |
| 14:13 | <Philip`> | mookid: It's cost vs benefit, both of which are non-zero |
| 14:13 | <mookid> | is it really that costly to implement oen attribute? |
| 14:13 | <mookid> | I think you might have problems with yoru processes. |
| 14:13 | <mookid> | -_- |
| 14:13 | <jcranmer> | mookid: you don't understand, I think |
| 14:13 | <ehird> | mookid: if every semi-useful attrib was added |
| 14:13 | <hsivonen> | mookid: it makes the address a pair instead of a single value, which sucks, because existing systems deal with one value |
| 14:13 | <ehird> | we'd have a monstrosity |
| 14:13 | <Dashiva> | Opportunity cost, maintenance costs, attack surface... |
| 14:13 | <ehird> | now someone tell me what it actually is ;) |
| 14:14 | <mookid> | hsivonen: it doesn't do anything of the sort |
| 14:14 | <jcranmer> | the mere virtue of adding something is a csot |
| 14:14 | <mookid> | HTTP already is a pri.. it's headers and body |
| 14:14 | <mookid> | pair^ |
| 14:14 | <ehird> | whats that got tot do with uris. |
| 14:14 | <jcranmer> | then there's the costs of the actual implementation of the attribute, and what it does |
| 14:14 | <mookid> | everything |
| 14:15 | <ehird> | i see. |
| 14:15 | <mookid> | well the attribute isn't exactly complicated is it |
| 14:15 | <mookid> | and there's no greater attack surface |
| 14:15 | <mookid> | it's restricting the header which is allready catcha ll |
| 14:15 | <mookid> | so.. |
| 14:15 | <mookid> | chill out on that one Neo |
| 14:15 | <ehird> | someone wanna tell me what it is yet? :q |
| 14:15 | <ehird> | or at least a link |
| 14:15 | <mookid> | a URI? |
| 14:16 | <jcranmer> | mookid: no HTTP uri mechanism, that I know of, allows you to specify headers |
| 14:16 | <Philip`> | ehird: What the proposed feature we're discussing is? I think it's <a href="report" accept="application/pdf"> |
| 14:16 | <ehird> | Philip`: ewwwwwwwww |
| 14:16 | <mookid> | HTTP uri mechanism?! |
| 14:16 | <ehird> | how is that represented in the browser's URI box? |
| 14:16 | <mookid> | wth is that? |
| 14:16 | <ehird> | if you copy the URI there |
| 14:16 | <ehird> | and paste it in a new window |
| 14:16 | <ehird> | might you get a different representation? |
| 14:16 | <ehird> | if so... awful, awful, just plain awful |
| 14:16 | jcranmer | heads off to class |
| 14:16 | <hsivonen> | ehird: details! :-) |
| 14:17 | <mookid> | if you put a URI into a browser 'uri box' then it will fetch HTML.. that's the desired behaviour in that use case |
| 14:17 | <Philip`> | ehird: Yes, but it'll be a representation appropriate to the UA you paste it into, and it'll be the same resource so you'll never mind the difference |
| 14:17 | <ehird> | Philip`: Except that the page evidently thought that it was important I get THIS representation |
| 14:17 | <ehird> | So... not irrelevant, evidently |
| 14:17 | <mookid> | why is it awful to get the most appropriate representation of the exact same data? |
| 14:18 | <Philip`> | Depends on what you mean by "most appropriate" - when someone tells me to look at something specific, the most appropriate thing for me to see is the same thing they're seeing, and not a UA-dependent variant in a different format |
| 14:18 | <mookid> | oh damn... my user agent got the information in the best format for it.. shock horror |
| 14:19 | <mookid> | well then use the same UA.. |
| 14:19 | <mookid> | einstein.. |
| 14:19 | <ehird> | mookid: snide jabs help nobody |
| 14:19 | <mookid> | well cmon.. that's just ridiculous |
| 14:19 | <Philip`> | Then they'd have to tell me what UA they were using, so they're now using a (uri, ua) pair (for which no nice uniform syntax is defined) as the reference |
| 14:20 | <mookid> | what? |
| 14:20 | <mookid> | you would just send them the URI and say 'i'm looking at the pdf' |
| 14:20 | <mookid> | why does it matter that much what the format of the data is? |
| 14:20 | <ehird> | mookid: I thought you were advocating ADDING the conneg attribute? |
| 14:20 | <ehird> | Bit of a turn around there .. ? |
| 14:21 | <mookid> | I am - conneg in this isntance is seperated from the URI |
| 14:21 | <mookid> | so, normally your UA woud have fixed defaults |
| 14:21 | <mookid> | like a PDF document |
| 14:21 | <mookid> | reader |
| 14:21 | <mookid> | or iTunes (mp3) |
| 14:21 | <mookid> | btu browsers Get lots of different stuff and pass it to the OS |
| 14:21 | <mookid> | so you need a way of making the browser Accept header dynamic |
| 14:21 | ehird | shrugs. My thoughts: Overly complex, not a nice user experience when copying&pasting the resulting URI, not worth the effort required to implement even for the gains it might bring. |
| 14:22 | <mookid> | well it's a better user experience because they can use the UA that suits them |
| 14:22 | <Philip`> | What about an iTunes-like music player that had an embedded web browser? |
| 14:22 | <ehird> | Philip`: cough - songbird - cough? |
| 14:22 | <ehird> | ;) |
| 14:22 | <mookid> | well it depends where in teh GUI you put the URI.. |
| 14:22 | <mookid> | doesnt it? |
| 14:23 | <mookid> | you keep saying stuff that you clearly think is valid when it's not.... :/ |
| 14:23 | <Philip`> | You put it in the text box at the top of the window, which is where you put all your URIs and search queries and other textual input |
| 14:24 | <mookid> | so the brwoser would open up the html page which would (heopfully) provide hyper text links to all the other representations.. if HTML5 works properly that will be the same URI but with a differet Accept headerconfiguration indicated |
| 14:24 | <mookid> | YES you can do that with URIs |
| 14:24 | <mookid> | I know. |
| 14:25 | <mookid> | please don't tell me that AGAIN |
| 14:25 | <Philip`> | You can do that with UR... oh, okay |
| 14:25 | <ehird> | you can do that with UR*shot* |
| 14:25 | <ehird> | damnit Philip` |
| 14:25 | <ehird> | :( |
| 14:25 | Philip` | is probably not being very helpful |
| 14:26 | <mookid> | essentially what you're saying is that in WHATWG's opinion.. the HTTP Accept header should be deprecated |
| 14:26 | <ehird> | what I'm saying is that you don't "get" Accept |
| 14:27 | <ehird> | accept is for the user/browser to dictate what formats they want. |
| 14:27 | <ehird> | not the page. |
| 14:27 | <mookid> | er |
| 14:27 | <ehird> | if the page must dictate the format, use file extensions |
| 14:27 | <ehird> | in the URI |
| 14:27 | <mookid> | I'm not even going to bother.. :/ |
| 14:27 | <ehird> | then you won't convince me. |
| 14:27 | <ehird> | nice way to have an argument, but a bit peculiar |
| 14:27 | <mookid> | I KNOW!!! :D |
| 14:28 | <ehird> | sooo |
| 14:28 | <ehird> | why are you talking if you don't want to convince |
| 14:28 | <mookid> | well you're arguing in circles and you arent making sense |
| 14:28 | <mookid> | I'm saying |
| 14:28 | <mookid> | ok |
| 14:28 | <mookid> | bear with me |
| 14:28 | <hsivonen> | mookid: I suggest going back to what BenMillard said: giving a rationale in terms of use cases instead of appealing to the authority of the definers of HTTP. |
| 14:29 | <mookid> | developers need a way to construct HTML that can allow the user.. a way of modifying the Accept header in an HTML interface |
| 14:29 | <ehird> | no |
| 14:29 | <ehird> | i disagre |
| 14:29 | <ehird> | e |
| 14:29 | <mookid> | that isnt possible at the moment.. so URIs are used instead as a hack |
| 14:30 | <mookid> | it's a hack though |
| 14:30 | <ehird> | i disagree with your first point |
| 14:30 | <mookid> | it's just what people are used to |
| 14:30 | <ehird> | therefore you cannot convince me without convincing me of your first point. |
| 14:30 | <hsivonen> | mookid: It's a hack only from the point of view of a particular dogma that you haven't justified |
| 14:30 | <BenMillard> | ehird, file extensions in href (or src and so forth) seem like an solution to me, too. I consider this a Solved Problem, although if mookid follows hsivonen's advice maybe that'll unearth a widespread user need we haven't thought of. |
| 14:30 | <mookid> | dogma? |
| 14:30 | <hsivonen> | mookid: yes |
| 14:30 | <mookid> | lol |
| 14:31 | <ehird> | i hate it when people say "lol" when they run themselves into a corner |
| 14:31 | <ehird> | and don't justify their position... |
| 14:31 | <mookid> | what |
| 14:31 | <mookid> | it's not dogma |
| 14:31 | <mookid> | he's being a douchebag |
| 14:31 | <ehird> | gee, that's very kind |
| 14:31 | <mookid> | so is describing my poitn of view as dogma. |
| 14:32 | <ehird> | that's not a personal attack, that's a criticism of your views. |
| 14:32 | <mookid> | that's not a criticism |
| 14:32 | <jcranmer> | mookid: look at it like this |
| 14:32 | <jcranmer> | under your proposal |
| 14:32 | <hsivonen> | mookid: you can make it non-dogma by explaining in terms of use cases and addressing use cases and problems and solutions why putting ".pdf" in the URI is inappropriate |
| 14:32 | <jcranmer> | the accept is static |
| 14:32 | <mookid> | I DID EXPLAIN THE USE CASE |
| 14:33 | <jcranmer> | the page itself defines what it wants |
| 14:33 | <mookid> | "here theres somethign interesting here: example.com/report - have a look" |
| 14:33 | <mookid> | user can use whatever UA they want |
| 14:33 | <mookid> | that's a use case. |
| 14:33 | <jcranmer> | mookid: if the page says, "I want this to be HTML" |
| 14:33 | <jcranmer> | why not just tack on the .html at the end? |
| 14:33 | <hsivonen> | mookid: s without specifying accept, they get whatever |
| 14:33 | <ehird> | mookid: and? |
| 14:33 | <hsivonen> | s/s /so / |
| 14:34 | <mookid> | you can't do that using URIs for conneg |
| 14:34 | <mookid> | how would you say |
| 14:34 | <hsivonen> | mookid: if you want to send someone a link to a pdf, why is putting ".pdf" in the URI not an acceptable way to address the use case? |
| 14:34 | <ehird> | hsivonen ++ |
| 14:34 | <ehird> | it's not a hack at all |
| 14:34 | <ehird> | if the type really is important, specify .pdf |
| 14:34 | <ehird> | BUT |
| 14:34 | <ehird> | Accept is for the user agent |
| 14:34 | <mookid> | "hey look at this URI and use whatever UA you want to look at it" if conneg is done in the URI ? |
| 14:34 | <ehird> | s |
| 14:34 | <ehird> | and the users |
| 14:34 | <ehird> | NOT the content authors |
| 14:34 | <mookid> | what? |
| 14:35 | <ehird> | the users, and their user agents, specify what types THEY personally want |
| 14:35 | <ehird> | it's not for the content authors to decide |
| 14:35 | <ehird> | for that, they should use .pdf and similar |
| 14:35 | <hsivonen> | mookid: should I try Firefox, iTunes, Word, Excel, OOo, etc. to see what you serve to each? |
| 14:35 | <mookid> | it's the SAME resource |
| 14:35 | <mookid> | it's the SAME data |
| 14:35 | <mookid> | it's just a DIFFERENT REPRESENTATION |
| 14:35 | <ehird> | I agree with that much. |
| 14:35 | <jcranmer> | at some point |
| 14:36 | <jcranmer> | you realize that idealism doesn't match up with reality |
| 14:36 | <mookid> | oh right |
| 14:36 | <ehird> | But I say that pragmatically, file extensions are the way to solve this |
| 14:36 | <ehird> | and the Accept changing damages repeatability |
| 14:36 | <mookid> | maybe that's becaue of belligerant spec writerS? |
| 14:36 | <ehird> | (copy&paste the uri and get the same thing) |
| 14:36 | <jcranmer> | no |
| 14:36 | <mookid> | possibly? |
| 14:36 | <hsivonen> | mookid: if it's same enough that the representation doesn't matter, why do you care about the accept value? |
| 14:36 | <mookid> | no? |
| 14:36 | <mookid> | thoguht not. |
| 14:36 | <ehird> | and is not good use of Accept |
| 14:36 | <ehird> | it's for users/user agents |
| 14:36 | <jcranmer> | mookid: no, implementors |
| 14:36 | <mookid> | omg.. |
| 14:36 | BenMillard | realises what the most productive thing to do at this point is. |
| 14:37 | <jcranmer> | specs mean nothing if they're not implemented |
| 14:37 | <ehird> | mookid: If you weren't being condescending and insulting, I'd talk more. |
| 14:37 | <jcranmer> | ask the ACAP author |
| 14:37 | <mookid> | hsivonen: because the accept value is the only way you can serve multiple content types from one URI |
| 14:37 | <ehird> | And? |
| 14:37 | <mookid> | that's important.. |
| 14:37 | <mookid> | that's how HTTP was designed |
| 14:37 | <ehird> | Is it now. |
| 14:37 | <mookid> | yes it is now. |
| 14:37 | <jcranmer> | mookid: are you are an HTTP developer? |
| 14:37 | <ehird> | Well, it'd be nice if you justified that. |
| 14:37 | <hsivonen> | mookid: but you shouldn't serve them from one URI unless you are indifferent towards which representation a user gets |
| 14:37 | <ehird> | exactly |
| 14:37 | <mookid> | no I'm an architect |
| 14:37 | <ehird> | if it matters, separate the URIS |
| 14:38 | <mookid> | I *actually use* this stuff |
| 14:38 | <jcranmer> | do you know the contents of the HTTP development meetings? |
| 14:38 | <danbri> | are the list archives borken? http://lists.whatwg.org/pipermail/help-whatwg.org/ |
| 14:38 | <mookid> | to do new interesting stuff. |
| 14:38 | <mookid> | and progress this stuff forwards.. |
| 14:38 | <mookid> | rather than continuing to do the same stuff that doesnt really work very well |
| 14:38 | <danbri> | ah, i'm mixing up lists |
| 14:38 | <ehird> | danbri: wfm |
| 14:38 | <jcranmer> | you seem to be claiming to channel the HTTP spec writers |
| 14:39 | <ehird> | spec development via spiritual energy |
| 14:39 | <mookid> | no I'm not.. I just look at the Accept haeder and thing.. hmm WHAT MIGHT BE THE REASON FOR THAT BEIGN THERE |
| 14:39 | <mookid> | OH I DONT KNOW |
| 14:39 | <mookid> | for fun. |
| 14:39 | <ehird> | mookid: for users |
| 14:39 | <ehird> | and |
| 14:39 | <ehird> | user agents |
| 14:39 | <mookid> | for suers? |
| 14:39 | <jcranmer> | for UAs |
| 14:39 | <ehird> | to specify what types they prefer to get data in. |
| 14:39 | <ehird> | NOT for content authors |
| 14:39 | <mookid> | YES |
| 14:39 | <mookid> | AND MOST UAs |
| 14:39 | <danbri> | (i read meaning into http://www.whatwg.org/mailing-list url and assumed was only one list) |
| 14:39 | <ehird> | USE ALL CAPS |
| 14:39 | <mookid> | have fixed Accept headers |
| 14:39 | <ehird> | that's their problem |
| 14:39 | <mookid> | brwosers |
| 14:39 | <ehird> | next |
| 14:39 | <mookid> | dont |
| 14:39 | <mookid> | they're Hypermedia brwosers |
| 14:40 | <mookid> | hypermedia provides a window for the OS |
| 14:40 | <ehird> | yawn, this is the part where I realise you're not actaully listening to us and stop talking to you |
| 14:40 | <jcranmer> | yep |
| 14:40 | <mookid> | well yuo're tlaking crap that's why |
| 14:40 | <mookid> | no offence |
| 14:40 | <jcranmer> | [ citation needed ] |
| 14:40 | <ehird> | mookid: no, i'm talking a representation of crap |
| 14:40 | <ehird> | obviously. |
| 14:40 | <mookid> | hillarious. |
| 14:41 | <ehird> | almost as hilarious as calling people who disagree with you douchebags! |
| 14:41 | <mookid> | you clearly don't knwo what yuo're tlaking abuot just pipe down |
| 14:41 | <ehird> | anyway, i thought i said i'd stop talking to you |
| 14:41 | <mookid> | good you do that |
| 14:41 | <jcranmer> | ehird: ever visit any Usenet groups recently? |
| 14:41 | <ehird> | jcranmer: No -- and there's a good reason for that |
| 14:41 | <ehird> | :) |
| 14:41 | <Philip`> | It's much easier to say you're going to stop talking to someone, than to actually stop talking to them |
| 14:42 | <ehird> | Philip`: yep |
| 14:42 | <hsivonen> | http://www.joelonsoftware.com/articles/fog0000000018.html |
| 14:42 | <mookid> | jcranmer: you stopped that train of thought I noticed |
| 14:42 | <mookid> | omg URI conneg! |
| 14:42 | <jcranmer> | ehird: shame... he reminds me of JSH or Twisted on sci.math and comp.lang.java.programmer in recent months |
| 14:42 | <jcranmer> | hmm, not so much JSH though |
| 14:42 | <ehird> | hsivonen: i was gonna link to that |
| 14:42 | Philip` | thinks joelonsoftware.com's URLs indicate great optimism as to how many articles will be published |
| 14:42 | <ehird> | when he said architet |
| 14:43 | <ehird> | *architect |
| 14:43 | <ehird> | Philip`: lol :) |
| 14:43 | <ehird> | Philip`: interestingly, the URIs actually go downwards |
| 14:43 | <mookid> | "there's no such thing as superior beings" - actually there is that's how genetics work deal with it |
| 14:43 | <ehird> | http://www.joelonsoftware.com/Archive.html |
| 14:44 | <ehird> | and then up again |
| 14:44 | <ehird> | go figure |
| 14:44 | <mookid> | jcranmer: we didnt finisht aht off |
| 14:45 | <mookid> | so.. most UAs have specific Accept requirements that dont change |
| 14:45 | <mookid> | Browsers are a special case that do hypermedia but ALSO pass other content types to the OS |
| 14:45 | <mookid> | HTML needs to take account for that if people are to start using URIs properly |
| 14:45 | <ehird> | *crickets* |
| 14:45 | <mookid> | the reasont hey dont do that now |
| 14:46 | <mookid> | is becaue its impossible |
| 14:46 | <mookid> | not because it's "hard" |
| 14:46 | <ehird> | i considered something similar when i first starting using content negotiation |
| 14:46 | <mookid> | if you look at Rails.. Jax-RS.. |
| 14:46 | <ehird> | except I realised why it was silly a few minutes after. |
| 14:46 | <mookid> | yeah silly.. |
| 14:46 | <mookid> | that's why JAX-RS is built around it |
| 14:46 | <ehird> | yeah- silly |
| 14:46 | <mookid> | I suppose |
| 14:46 | <mookid> | do you know what JAX-RS is? |
| 14:47 | ehird | sighs |
| 14:47 | <ehird> | appeal to authorityyyyyyy |
| 14:47 | <mookid> | look it up then |
| 14:47 | <mookid> | I am not affiliated with them |
| 14:47 | <hsivonen> | Repetitive Strain XML binding for Java? |
| 14:47 | <mookid> | no it's got nothing to do with XML actually |
| 14:48 | <mookid> | it's content-type neutral |
| 14:48 | <mookid> | but the syntax is designed around HTTP methods.. and as a subset.. requested representation |
| 14:49 | <mookid> | I wonder why they did that.. |
| 14:49 | <mookid> | a URI.. split up by methods.. |
| 14:49 | Philip` | thinks it's fun how http://www.intertwingly.net/code/mombo/htaccess process the Accept header via a collection of UA-specific regexps, so it's basically an obscured form of UA sniffing |
| 14:49 | <mookid> | and content-type.. |
| 14:49 | <ehird> | Philip`: cute |
| 14:49 | <hsivonen> | mookid: because WS-* went downhill, REST is in vogue and for each buzzword, Java has to hava a framework? |
| 14:50 | <mookid> | REST is just codeword for not using HTTP retardedly |
| 14:51 | <hsivonen> | mookid: right, so why do you need a framework beyond an HTTP framework? |
| 14:51 | <mookid> | RAD |
| 14:51 | <mookid> | duuuuh... |
| 14:51 | <mookid> | you can make a REST interface with folders and index.php scripts if you want |
| 14:51 | <mookid> | yuo've been able to do that for years |
| 14:51 | <ehird> | totally RAD |
| 14:51 | <mookid> | idiot. |
| 14:51 | <ehird> | hey, there go the personal insults again |
| 14:51 | <ehird> | i love this |
| 14:51 | hsivonen | subclasses HttpServlet, but whatever |
| 14:52 | <Philip`> | If I upload a few static pages and serve them via Apache, is that REST? |
| 14:52 | <mookid> | yes if you do it right |
| 14:52 | <mookid> | of course it is |
| 14:52 | <mookid> | REST isnt very complicated |
| 14:52 | <mookid> | people use big words to make it sound all clever |
| 14:53 | <mookid> | it's just "looking at HTTP and designing around it" |
| 14:53 | <mookid> | partically speaking at least |
| 14:53 | <mookid> | they get all beardy about it |
| 14:53 | <mookid> | because you can be RESTful with another protocol or whatveer |
| 14:53 | <ehird> | mookid: I believe we all know this |
| 14:54 | <mookid> | I dont |
| 14:54 | <hsivonen> | mookid: so why do you assume we are clueless but the HTTP folks and JAX-RS folks did everything for a good reason? |
| 14:54 | <mookid> | REsources + representations |
| 14:54 | <mookid> | caching |
| 14:54 | <mookid> | HTTP |
| 14:55 | <ehird> | REST = REsources? |
| 14:55 | <mookid> | conneg |
| 14:55 | <jcranmer> | hsivonen: because we disagree with him |
| 14:55 | <ehird> | lol! |
| 14:55 | <ehird> | Representational State Transfer |
| 14:55 | <mookid> | jcranmer: you've stopped our conversation before |
| 14:55 | <mookid> | why? |
| 14:55 | <ehird> | mookid: because you're ignoring us, treating us as idiots, insulting us, being condescending, ... |
| 14:56 | <mookid> | because I explained what a browser is supposed to do |
| 14:56 | <jcranmer> | I'm also in middle of class |
| 14:56 | <mookid> | and the function of hypermedia |
| 14:56 | <ehird> | jcranmer: :-P |
| 14:56 | <mookid> | ooh right ok my bad enjoy |
| 14:56 | <jcranmer> | mookid: to be precise, you explaing what you THINK a browser is supposed to do |
| 14:56 | <mookid> | well you tell me the alternative definition then |
| 14:56 | <ehird> | ... but not WHY |
| 14:57 | <mookid> | The benefits of protocol conneg are reasonably apparent I thin I've done a reasonable job putting them forwar |
| 14:57 | <mookid> | when I do that |
| 14:57 | <mookid> | I get |
| 14:57 | <mookid> | "real world examples please?" |
| 14:57 | <ehird> | well, you haven't |
| 14:57 | <ehird> | unfortunately |
| 14:57 | <mookid> | just be quiet you no one cares what you think.. :/ |
| 14:58 | <jcranmer> | invert speaker and listener of last sentence |
| 14:58 | <Dashiva> | mookid: It seems you just dismiss anyone who doesn't agree with you |
| 14:58 | <ehird> | and this is why peopel don't talk to you |
| 14:58 | <mookid> | no I dont I just dismiss people who dont do me the respect of reading and comprehending what I'm communicating to them |
| 14:58 | <Philip`> | ehird: People here are doing a very bad job if they're intending to not talk to him |
| 14:59 | <ehird> | indeed... |
| 14:59 | <mookid> | indded? |
| 14:59 | <mookid> | just shush please |
| 14:59 | <jcranmer> | true |
| 14:59 | ehird | shushes please |
| 14:59 | <mookid> | yeah I completely respect people for having thei opinion I just dont feel ilke some people are really opening up |
| 15:00 | <mookid> | in how they consier what I'm saying |
| 15:00 | <Dashiva> | Have you ever considered that you might be wrong? |
| 15:00 | <mookid> | because most of the respnses I get are already dealt with in other stuf I've said |
| 15:00 | <ehird> | Dashiva: oh, you joker! |
| 15:00 | <mookid> | well I've been looking at this for a while now |
| 15:00 | <mookid> | so.. |
| 15:00 | <mookid> | I havent heard antyhign from anyone |
| 15:00 | <mookid> | and actually |
| 15:00 | <mookid> | most of the peolpe who sound like they know what they're talkign abuot |
| 15:01 | <mookid> | arent suggesting i'm wrong |
| 15:01 | <jcranmer> | look up Michelson-Moore |
| 15:01 | <mookid> | they're suggesting I need to come up with a use case and real world examples |
| 15:01 | <jcranmer> | you can work on something for a while and still be wrong |
| 15:01 | <mookid> | yeah true |
| 15:01 | <mookid> | I agree. |
| 15:01 | <mookid> | you can get so caught up in a certain way of doing thigns |
| 15:01 | <Dashiva> | jcranmer: Morley, you mean? |
| 15:01 | <mookid> | that the alternative seems totally unviable |
| 15:01 | <jcranmer> | Dashiva: maybe? |
| 15:01 | <Philip`> | jcranmer: <troll>Or look up religion</troll> |
| 15:01 | <jcranmer> | I don't know off the top of my head |
| 15:02 | <jcranmer> | Philip`: what if they're ALL right? |
| 15:02 | <hsivonen> | http://en.wikipedia.org/wiki/Michelson-Morley_experiment |
| 15:03 | <jcranmer> | g'evening, MikeSmith |
| 15:03 | <mookid> | The strangest thing abuot this is tha tI'm not even the one claiming to be right.. I'm just saying we cant tell |
| 15:03 | <mookid> | until you provision it |
| 15:03 | <mookid> | there's no feasible way of testing HTTP conneg |
| 15:03 | <MikeSmith> | jcranmer: hei |
| 15:03 | <mookid> | because developers wont move |
| 15:03 | <mookid> | because they cant.. |
| 15:04 | <hsivonen> | mookid: you don't need to try everything. You can see problems with some things before implementation. |
| 15:04 | <mookid> | if your persepective is wrong sure. |
| 15:05 | <mookid> | The caching issue is an interesting one which no one seems to have adressed |
| 15:06 | <Philip`> | We can't afford to try every idea, so we have to imperfectly predict whether they'll be worthwhile based on what we already know |
| 15:06 | <Philip`> | particularly since it's impossible to ever remove a feature once it's been added, even if it turns out to be a terrible idea |
| 15:07 | <mookid> | why is it terrible to provide an optional mechanism for controlling Accept headers? |
| 15:09 | <Dashiva> | How about an optional mechanism to control font size? |
| 15:10 | <mookid> | css? |
| 15:10 | <Dashiva> | No, in the resources provided by the server |
| 15:10 | <mookid> | css? |
| 15:10 | <Dashiva> | CSS in a powerpoint file? A pdf? |
| 15:10 | <mookid> | er what? |
| 15:11 | <mookid> | we talkign abuot HTML here or not? |
| 15:11 | Philip` | doesn't understand Dashiva |
| 15:11 | <Dashiva> | <a href="file.pdf" accept-font-size="14pt"> |
| 15:11 | <Dashiva> | So it doesn't give me documents where I have to zoom in |
| 15:11 | <jcranmer> | :-) |
| 15:12 | jcranmer | winks |
| 15:12 | <mookid> | HTTP conneg is a bti mroe fundamental than font size |
| 15:12 | <jcranmer> | but why not? |
| 15:12 | <Dashiva> | Surely adding just this one attribute is easy |
| 15:12 | <Dashiva> | And we don't know if it'll work before we try |
| 15:12 | <jcranmer> | it's not like it's terribly costly to implement |
| 15:12 | <mookid> | if you think that's the same thing that explains alot |
| 15:12 | <mookid> | :) |
| 15:12 | <hsivonen> | mookid: why? Font size is relevant to all text. Conneg isn't. |
| 15:13 | <mookid> | Conneg is relevant to every request |
| 15:13 | <mookid> | conneg is part of the browser request |
| 15:13 | <jcranmer> | it's also pointing out something of your method |
| 15:14 | <mookid> | not really i't sjust more diversionary rubbish |
| 15:14 | <mookid> | to be expected |
| 15:14 | <jcranmer> | you rejected it offhand without giving it thought |
| 15:14 | <jcranmer> | the priniciples are the same |
| 15:15 | <jcranmer> | we essentially gave the same "reasons" that you did |
| 15:16 | <mookid> | we? |
| 15:16 | <jcranmer> | Dashiva and I |
| 15:16 | <mookid> | I really hope you arent involved in this in any significant sense |
| 15:16 | <mookid> | you've added nothing so far. |
| 15:16 | <jcranmer> | you've convinced us of nothing |
| 15:17 | <Dashiva> | Have you talked to XHTML2 yet? |
| 15:17 | <mookid> | not yet |
| 15:17 | <mookid> | why? |
| 15:18 | <Dashiva> | Just wondering |
| 15:18 | <Philip`> | mookid: That's just the standard "go talk to some group we don't like because maybe your idea is the kind of crazy thing they'll like" insult |
| 15:19 | <Dashiva> | Busted! |
| 15:19 | Dashiva | shakes fist |
| 15:19 | <Philip`> | rather than a constructive suggestion |
| 15:19 | <mookid> | god forbid. |
| 15:19 | Philip` | takes all Dashiva's guns and $100 |
| 15:19 | <jcranmer> | Philip`: you didn't have to say that out loud ;-) |
| 15:19 | <Dashiva> | But it's also a place where you're more likely to find agreement |
| 15:20 | <Dashiva> | Since they're more interested in architectural purity than HTML5 is |
| 15:22 | <ehird> | mookid is still talking? |
| 15:22 | <ehird> | wow :D |
| 15:22 | <Philip`> | It's also a place where (according to the groupmind here) the harmful effects of any crazy ideas will be prevented because nobody will implement XHTML2 |
| 15:23 | <Dashiva> | We don't get to be a hivemind? |
| 15:23 | <Philip`> | so it's a safe place to send people to |
| 15:23 | <jcranmer> | Philip`: so XHTML2 is the new ACAP? |
| 15:23 | <Philip`> | jcranmer: An Agreement on the Conservation of Albatrosses and Petrels? I don't think it is |
| 15:24 | <Dashiva> | Say, is html4all still around? |
| 15:24 | <jcranmer> | +++ Binet-Simon test: 1st modern intel test |
| 15:24 | <jcranmer> | ++++ abstract verbal reason skills |
| 15:24 | <jcranmer> | ++++ metnal age: metal ability typical of child |
| 15:24 | <jcranmer> | +++ -> |
| 15:24 | <jcranmer> | dammit |
| 15:25 | <jcranmer> | http://www.rfc-editor.org/rfc/rfc2244.txt |
| 15:25 | <jcranmer> | (forgot to Ctrl-C the URI) |
| 15:26 | <Philip`> | Dashiva: Their public list isn't dead, but I guess all the juicy stuff is happening behind closed doors |
| 15:26 | <Philip`> | (or maybe it isn't happening at all, but that would be boring so I prefer my world-view) |
| 15:27 | <Philip`> | jcranmer: What is its analogy with XHTML2? |
| 15:27 | <jcranmer> | Philip`: dead, highly dead |
| 15:27 | <jcranmer> | only one server implementation |
| 15:28 | <Dashiva> | Mr. Last week is failing |
| 15:28 | <Dashiva> | His suggestion for the new doctype to be <HIXIE> isn't compatible with standards mode |
| 15:29 | <Philip`> | jcranmer: There are plenty of RFCs without even that many implementations |
| 15:30 | <hsivonen> | Dashiva: and now there'd even be IRC material available |
| 15:30 | <ehird> | Dashiva: <!doctype hixie> |
| 15:30 | <ehird> | <hixie>...</hixie> |
| 15:30 | <Dashiva> | Oh right |
| 15:31 | <Dashiva> | We'll be famous for this |
| 15:31 | <Dashiva> | *infamous |
| 15:31 | <ehird> | just name every element after someone in here. |
| 15:31 | <jcranmer> | Philip`: I've always used ACAP as my example of a dead protocol |
| 15:31 | <Philip`> | Dashiva: That's why we just need everyone to upgrade to the Hixiefox and Hixiekit and Hixplorer and Hixpera browsers, and they can render it in standards mode |
| 15:32 | <Dashiva> | Philip`: Surely it would then be hixie mode |
| 15:32 | <jcranmer> | and quirks mode is hixie pixie mode! |
| 15:33 | <ehird> | <!doctype hixie><hixie><philip>hello world</philip><dashiva>An example Hixie5 page</dashiva><danbri>This is a paragraph</danbri></hixie> |
| 15:33 | <Philip`> | Actually, Hixplorer sounds stupid, it should be HixIE |
| 15:33 | <Dashiva> | FireFoxie |
| 15:33 | <ehird> | Philip`: HixIEplorer |
| 15:34 | <Dashiva> | What was HTML again, Hixie something Markup Language |
| 15:34 | <danbri> | that should be <danbri xmlns='http://danbri.org/'; /> :) |
| 15:34 | <ehird> | Dashiva: It's HIXIE |
| 15:34 | <ehird> | Stands for Hixie Ixie Xie Ie E |
| 15:34 | <ehird> | Because it's an "echo" of the content. Totally. |
| 15:35 | <ehird> | danbri: http://danbri.org/danbri |
| 15:35 | <Dashiva> | ehird: Yeah, but we had an expansion of HTML last year |
| 15:35 | <ehird> | :p |
| 15:35 | <ehird> | ah, wait |
| 15:35 | <ehird> | hmm, no |
| 15:38 | <Philip`> | jcranmer: You could use HTML 3.0 as a more appropriate example, perhaps |
| 15:38 | <jcranmer> | HTML 1.0 |
| 15:39 | Philip` | likes how HTML 3.0's <math> element defines a new syntax that would parse to the same DOM tree as the usual SGMLish tags |
| 15:40 | <Philip`> | e.g. <math>x^{1+2}</math> seems to be the same as <math>x<sup><box>1+2</box></sup></math> |
| 15:40 | <ehird> | wow, never heard of that |
| 15:41 | <Philip`> | since that's a nice extension of the idea that the character-level syntax and parsed representation are really independent concepts |
| 15:41 | <Lachy> | Dashiva, s/FireFoxie/FireHixie/ |
| 15:42 | <Philip`> | Oh, actually, I think that should be <math>x^{1+2}^</math> |
| 15:43 | <Philip`> | Fire Hixie? Then we wouldn't have an editor |
| 15:43 | <danbri> | that is interesting, yeah |
| 15:49 | <Philip`> | Easy solution to the problem of thinking of precise antonyms for rel values: use some pattern along the lines of rel="rev-author" |
| 15:52 | <Lachy> | I'm not even convinced of the need for rel='author", and even less convinced of the need for the reverse relationship |
| 15:54 | gsnedders | awves |
| 15:54 | <gsnedders> | *&waves |
| 15:54 | <Lachy> | and considering that the concept of a reverse relationship is difficult for authors to grasp correctly, it would be a mistake to add it simply to cater for theoretical cases |
| 15:54 | <gsnedders> | **waves |
| 16:02 | <jcranmer> | wouldn't *&waves = waves? |
| 16:03 | <Philip`> | Not if you overload the unary operator* |
| 16:03 | <jcranmer> | let's talk C here |
| 16:03 | <Philip`> | How boring |
| 16:04 | <Dashiva> | I'm still waiting for D to become popular |
| 16:04 | <Dashiva> | It looks kinda neat |
| 16:04 | <jcranmer> | doesn't DTrace use D? |
| 16:04 | <jcranmer> | oh wait, it's a different D |
| 16:04 | <Philip`> | jcranmer: That's a completely different D |
| 16:04 | <Philip`> | and isn't even Turing-complete |
| 16:04 | <jcranmer> | D therefore shouldn't be popular |
| 16:04 | <jcranmer> | don't want to confuse people |
| 16:05 | <Philip`> | Dashiva: It looks kind of neat, but not neat enough to overcome the huge legacy advantage of C for systems programming, or to compete with proper languages for other types of programming |
| 16:06 | <jcranmer> | any new language should be compatible with the C ABI |
| 16:06 | <jcranmer> | for bonus point |
| 16:07 | <jcranmer> | support C++ ABI |
| 16:08 | <Philip`> | That's kind of hard when even C++ doesn't support the C++ ABI (if you mix compilers or compiler versions) |
| 16:08 | <Philip`> | (unless I'm sadly mistaken about this) |
| 16:09 | <Philip`> | Passing STL objects across DLL boundaries is fun |
| 16:10 | <jcranmer> | ooh, I got caught by something similar |
| 16:11 | <jcranmer> | an object I was working with (growable array) wouldn't work if the original array had 0 size, but with non-zero size, it worked |
| 16:12 | <jcranmer> | all because of hidden static variables |
| 16:12 | <jcranmer> | basically, &sEmptyHdr != &sEmptyHdr :-) |
| 16:28 | <yecril71> | Lynx uses LINK[rev="made"] for me to complain about a Web page. |
| 16:28 | <yecril71> | Quite handy: press "C", no need to look around. |
| 16:29 | <yecril71> | Is it possible to have type of a hyperlink influence the Accept header the browser sends? |
| 16:30 | <yecril71> | s/possible/reasonable/ |
| 16:31 | <Philip`> | I imagine its handiness is significantly reduced by the problem that fewer than 1% of pages have rev=made |
| 16:32 | <Philip`> | and shouldn't that be using LINK[rel="author"] anyway? |
| 16:33 | <yecril71> | Perhaps it should; only Lynx does not support it. |
| 16:34 | Philip` | sees that nearly all <link rev=made> have href=mailto:... |
| 16:34 | <yecril71> | So, to make my page conveniently usable for Lynx users, I have to use rev. |
| 16:34 | <ehird> | the maker of the document is who you should contact about maintaining it |
| 16:34 | <ehird> | the author of a document is the author of the content in the document |
| 16:35 | <yecril71> | Now you are getting architectonic... |
| 16:35 | <yecril71> | I have decribed the reality, and the reality is brutal. |
| 16:36 | Philip` | sees about as many <link rev=made href=example⊙ec> (forgetting the "mailto:") as he sees <link rev=made href=http://...> |
| 16:37 | <Philip`> | whereas rel=author most commonly links to a page instead of an email address |
| 16:37 | <yecril71> | I guess that means it should really be rel="publisher"? |
| 16:38 | <Philip`> | so it seems the semantics are defined more by convention (i.e. people copying examples and tutorials that use rel=author and rev=made for pages and emails) than by what anyone intended the values to really mean |
| 16:39 | <yecril71> | rev=made is required as implemented. |
| 16:50 | <Lachy> | does anyone here understand RB's distinction of "browser behaviour" and "HTML parsing"? |
| 16:52 | <Dashiva> | does anyone here understand RB? |
| 16:53 | <Lachy> | rarely |
| 16:55 | <yecril71> | Is it reasonable to expect that specifying the type attribute of a hyperlink |
| 16:55 | <yecril71> | will also influence the Accept header sent by the browser? |
| 16:55 | <Dashiva> | Give an example? |
| 16:57 | <Philip`> | "making HTML depend on HTTP-specific features sounds like A Bad Idea" - like <form method> and <a ping> and <eventsource> and so on? |
| 17:00 | <yecril71> | <A HREF="report" TYPE="application/pdf" >? |
| 17:01 | <Dashiva> | I'm getting this intense feeling of deja vu here |
| 17:01 | <yecril71> | BTW, what does METHOD=POST mean for non-HTTP? |
| 17:02 | <yecril71> | D�ja vu of what? |
| 17:03 | <ehird> | yecril71: aaah! |
| 17:03 | <ehird> | kill! |
| 17:03 | <yecril71> | (except that METHOD=POST is a good way to avoid opening a HTA in IE) |
| 17:03 | <ehird> | begon, clone of mookid! |
| 17:04 | <yecril71> | Please, I only want to understand what is already supported. |
| 17:04 | <ehird> | i was joking |
| 17:04 | <ehird> | :) |
| 17:05 | <ehird> | but, no |
| 17:05 | <ehird> | that won't. |
| 17:05 | <Dashiva> | (or was he? DUN DUN DUN) |
| 17:05 | <ehird> | Dashiva: i am actually travelling to where yecril71 (aka MOOKID) is right now so that i may cut up his intestines |
| 17:05 | <ehird> | ... only kidding! haha! |
| 17:05 | <yecril71> | Joking is a good thing when you are also willing to help. |
| 17:05 | <Dashiva> | yecril71: The user agent can use the value as a hint if it wants to |
| 17:06 | <Dashiva> | But as far as I know, none of the major browsers do |
| 17:06 | <Philip`> | yecril71: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#form-submission-algorithm step 14 defines what it means in HTML5 for any protocol |
| 17:06 | <ehird> | yecril71: i answered |
| 17:06 | <ehird> | <ehird> but, no |
| 17:06 | <ehird> | <ehird> that won't. |
| 17:06 | <ehird> | re: <yecril71> <A HREF="report" TYPE="application/pdf" >? |
| 17:07 | <yecril71> | I must have missed your answer |
| 17:10 | <yecril71> | MSHTA treats GET file: as mutation. |
| 17:11 | <yecril71> | I do not know about ftp. |
| 17:11 | <yecril71> | Why is file: out of scope? |
| 17:12 | <yecril71> | OTOH, it does not modify the URL for POST file:, which is good. |
| 17:15 | <Philip`> | Oops, when I said "any protocol" I was lying |
| 17:15 | <yecril71> | "Attributes don�t reflect" means that getAttribute returns the initial value specified. |
| 17:16 | <Philip`> | yecril71: file: is out of scope because it's not considered an area where interoperability is needed, and UAs can just do whatever they want |
| 17:17 | <Philip`> | (I'm not entirely sure how to argue for why interoperability isn't needed in that case, though) |
| 17:19 | <yecril71> | Do you thing that METHOD=POST is a wrong thing overall? |
| 17:19 | <yecril71> | s/thing/think/ |
| 17:19 | <Philip`> | Uh... No? |
| 17:20 | <yecril71> | It works with HTTP only, and you are for separation of HTML and HTTP. |
| 17:20 | <Philip`> | I'm not for separation of HTML and HTTP :-) |
| 17:21 | <yecril71> | But here HTML depends on HTTP-specific features, |
| 17:21 | <yecril71> | which is a bad thing, Philip` said. |
| 17:21 | <yecril71> | I am trying to decipher that text. |
| 17:23 | <Philip`> | Do you mean when I said |
| 17:23 | <Philip`> | 17:00 < Philip`> "making HTML depend on HTTP-specific features sounds like A Bad Idea" - like <form method> and <a ping> and <eventsource> and so on? |
| 17:23 | <Philip`> | ? |
| 17:23 | <ehird> | yecril71: he was quoting |
| 17:23 | <ehird> | and using sarcasm |
| 17:23 | <ehird> | to rebut it :P |
| 17:23 | <Philip`> | That was quoting jcranmer |
| 17:24 | Philip` | attempts to increase the ratio of technical discussion on public-html, by pointing out a couple of terribly exciting typos |
| 17:24 | <jcranmer> | method is something that could be easily specifiable to not be protocol-dependent (in my eyes at least) |
| 17:25 | <jcranmer> | I'm not a fan of <a ping> to be honest |
| 17:25 | <jcranmer> | and I've not read up on <eventsource> |
| 17:28 | <yecril71> | How would you POST to file:? |
| 17:28 | <ehird> | replace the file, obviously :-P |
| 17:28 | <ehird> | <form method="POST" action="/etc/passwd"> |
| 17:28 | <yecril71> | That is not POST, that is PUT |
| 17:28 | <ehird> | well, true. |
| 17:29 | <ehird> | but it'd amount to the same thing for file:, probably. |
| 17:29 | <yecril71> | But it would be very different from what GET does, |
| 17:29 | <yecril71> | whereas it is not that different for http:. |
| 17:30 | <jcranmer> | get would be a URI composition |
| 17:30 | <yecril71> | How do you POST a file to file:? |
| 17:31 | <yecril71> | The exciting thing is POST, not GET. |
| 17:31 | <yecril71> | GET is already covered, assuming file: is similar to ftp:. |
| 17:32 | <jcranmer> | looks like Hixie disagrees with me on GET |
| 17:32 | <yecril71> | What does look like that? |
| 17:33 | <jcranmer> | a non-Flash, non-jemalloc-related FF crash? |
| 17:34 | <yecril71> | Am I getting every sixth message or what? |
| 17:57 | <yecril71> | All right, I got your point with GET. |
| 18:23 | <takkaria> | christ, it's obviously troll season at the moment |
| 18:25 | <yecril71> | I cannot see any at the moment. |
| 18:28 | Philip` | sees that occam has a keyword that is defined as performing an infinite loop |
| 18:29 | <Philip`> | which seems a peculiar but perfectly sensible thing to do |
| 18:33 | <takkaria> | I assume you can break out of it? |
| 18:43 | <tndH> | eh, 36 emails since yesterday |
| 18:43 | <tndH> | and i went to bed at 2 :| |
| 18:51 | <yecril71> | If a resource with alternative formats gets updated, |
| 18:51 | <yecril71> | all formats should be updated and not just one. |
| 18:52 | <yecril71> | Where "updated" can mean "removed until someone handles it". |
| 18:52 | <yecril71> | That is the publisher�s responsibility and it can be enforced by the server. |
| 18:54 | <yecril71> | However, the mechanisms of updating resources are often different from the mechanisms of viewing it. |
| 18:55 | <yecril71> | And that includes the URL, e.g. update ftp:, get http:. |
| 19:11 | <Philip`> | takkaria: No |
| 19:12 | <Philip`> | takkaria: but the language is designed to run stuff in parallel |
| 19:12 | <Philip`> | so all you're doing is sending one thread into an infinite loop |
| 19:12 | <Philip`> | which is observationally identical to terminating the thread |
| 19:12 | <Philip`> | (because it'll just stop outputting anything) |
| 19:13 | <Philip`> | (hence the keyword is "STOP") |
| 19:18 | <hallvors> | TAG fed the trolls.. |
| 19:34 | <takkaria> | Philip`: heh |
| 19:36 | <takkaria> | yecril71: see, all formats should be updated, but not all will be, always. and whilst a server *can* enforce this, it requires someone going out of their way to write code to do that, and as such will probably not be enforced most of the time |
| 19:54 | <yecril71> | Providing alternative representations already is going out of one�s way already. |
| 19:54 | <yecril71> | Once you decide to do that, you should make sure you have all the tools necessary to maintain this setup. |
| 20:08 | <webben> | Can anyone remember whether the problem with http://lists.w3.org/Archives/Public/public-html/2008Aug/0116.html was CSS generated text (content: "TODO") or just a border? |
| 20:09 | <webben> | wayback doesn't seem to have captured the relevant CSS |
| 20:28 | <Philip`> | In practice, if you have multiple formats for some resource, you'd quite possibly want to do the format conversion asynchronously as a batch operation rather than blocking the person who's doing the uploading while your really slow video transcoding / PDF OCRing / etc process goes on |
| 20:29 | <Philip`> | and so invalidating the cache at the moment of upload is not sufficient, since you'll need to invalidate all the other formats at some unknown time in the future |
| 20:31 | <Philip`> | webben: I'm pretty sure the CSS generated content was added ages ago, long before that email |
| 20:32 | <Philip`> | Maybe gsnedders could add non-CSS generated content support into Anolis :-) |
| 20:32 | <gsnedders> | Philip`: For what? |
| 20:33 | <gsnedders> | Philip`: I have feedback from Hixie about the ** stuff, and doing stuff to issues |
| 20:33 | <Philip`> | gsnedders: For the places where the spec currently uses CSS to add content:"Note" and content:"Warning" etc, since that's not just stylistic information and it means some UAs can't distinguish those notes/warnings |
| 20:34 | <Philip`> | *can't distinguish from plain text |
| 20:34 | <gsnedders> | Philip`: Yeah' I have an email from Hixie detailing what he wants there |
| 20:34 | <gsnedders> | s/'/,/ |
| 20:34 | <Philip`> | gsnedders: Okay |
| 20:34 | <Philip`> | webben: Blame gsnedders for not fixing it yet :-) |
| 20:35 | <gsnedders> | Blame Apple for making a laptop that broke slowing me down :) |
| 20:36 | <Philip`> | That's your fault for buying shoddy hardware |
| 20:36 | <Philip`> | You should have got a Dell |
| 20:38 | <Philip`> | Also you should have got a RAIL setup, so you have a hot-spare laptop to fall back on if one breaks |
| 20:39 | <gsnedders> | Philip`: Buy me one. :P |
| 20:39 | <Philip`> | Don't try shifting the blame! |
| 20:41 | <Dashiva> | I wonder if the people complaining about DOM are aware that the charter includes DOM APIs |
| 20:42 | <gsnedders> | Our charter doesn't :P |
| 20:44 | <Philip`> | Be careful about arguing based on what the charter says, because other people might start doing the same when arguing against you on other issues :-) |
| 20:44 | <Dashiva> | Are we talking about the same charter? |
| 20:45 | Philip` | assumes gsnedders was making some point about WHATWG vs HTML WG |
| 20:45 | <gsnedders> | Dashiva: Philip` understands me better than you. |
| 20:46 | <Dashiva> | A charter that nobody lawyers about isn't interesting :) |
| 20:52 | hsivonen_ | wishes the charter didn't have earmarks |
| 20:52 | <hsivonen_> | hmm. probably not the right political word |
| 20:55 | <Philip`> | Maybe "riders"? |
| 20:56 | <hsivonen_> | Philip`: that's the word I was looking for, yes |
| 20:56 | <hsivonen_> | thanks |
| 22:07 | <hallvors> | does anyone know documentation for differences in capabilities in IE between an XMLHttpRequest object created with ActiveXObject() and a native XMLHttpRequest() object? |
| 22:08 | <hallvors> | if that's hard to parse: it turns out that the object returned from "new XMLHttpRequest()" and "new ActiveXObject('MSXML2.XMLHTTP.3.0')" have different capabilities. I'd like to know if this is known/documented. |
| 22:10 | <gsnedders> | hallvors: IIRC they return exactly the same thing )the native object is just a wrapper) |
| 22:21 | <Hixie> | hm, burns is late with his trolls. he hasn't said anything since sunday. |
| 22:21 | <Hixie> | maybe he can only troll on weekends now. |
| 22:21 | <Hixie> | i wonder if he'll ever reply to http://lists.w3.org/Archives/Public/public-html/2008Nov/0161.html |
| 22:22 | <blooberry> | hallvors: using the ActiveXObject method requests a specific instantiation of a particular object. I believe there were previous iterations of xmlhttp? So, it makes sense that there might be some differences depending on which ActiveXObject you are requesting to create. The question I would have is: is there a version string for ActiveXObject that has the same behavior as new XMLHttpRequest? That would probably indicate which ActiveXO |
| 22:22 | <blooberry> | using as its default. |
| 22:38 | <Lachy> | Hixie, apparently, according to the comments in the forum, a new version of Requiem 1.8.2 has been released. |
| 22:39 | <Lachy> | I'm still waiting for my copy of freenet to update the download page for me before I can get it |
| 22:41 | Philip` | suggests using the web to download it instead |
| 22:44 | <Lachy> | Philip`, I would, but I can't find it elsewhere on the web yet |
| 22:49 | <Philip`> | Is there anything to stop some random person releasing a file on Freenet and claiming it's a new version of Requiem? |
| 22:50 | <takkaria> | hashes? |
| 22:51 | <Lachy> | they could, but only Brahms is able to update the official Requiem page with the links to the files |
| 22:52 | <Lachy> | so if you found a link to the file from elsewhere, you could be fooled into downloading the wrong file, but that's the same with anything. |
| 22:52 | <hallvors> | gsnedders, blooberry: I have a brand new test case where IE only supports xhr.open('SEARCH', ...) if the XHR object is created with the ActiveX call. Weird, and I have no idea why. |
| 23:01 | <blooberry> | hallvors: that is odd. Did you see if there are any other ActiveX strings that would work for XHR? |
| 23:03 | <hallvors> | since the next TC I wrote actually froze IE (IE8 beta2, that is) I haven't gotten much further yet, no :-p |
| 23:03 | <Hixie> | Lachy: i'm still on 1.7.x |
| 23:03 | <Hixie> | Lachy: but good to know :-) |
| 23:03 | <Hixie> | Lachy: any idea what it adds? |
| 23:04 | <blooberry> | hallvors: 8-} |
| 23:12 | <hallvors> | fun. tried all the identifiers from http://en.wikipedia.org/wiki/XMLHttpRequest |
| 23:12 | <hallvors> | they all work. only "new XMLHttpRequest()" makes it fail |
| 23:16 | <Lachy> | Hixie, I don't know yet. It probably adds windows support |
| 23:17 | <Hixie> | ah ok |
| 23:17 | <Lachy> | yeah, it does. My freenet node has updated now |
| 23:17 | Hixie | finds his mac is crashing on loginwindow on startup now |
| 23:17 | <Hixie> | wtf |
| 23:17 | <blooberry> | hallvors: I would have expected ActiveXObject to be the more restrictive specification method as MS has had the most probs with that tech over the years. |
| 23:22 | <hallvors> | If they have started limiting what HTTP verbs you're allowed to use it's pretty interesting. Especially since Outlook Web Access uses lots of funky verbs including SEARCH. The OWA team might not like IE8... :p |
| 23:23 | <takkaria> | they'll be in IE7mode, I bet |