| 00:00 | <SadEagle> | gsnedders: that's pretty much it, though there is math involved. Short conceptual summary, though.. Let n = 10^6. |
| 00:00 | <Philip`> | O(foo(N)) means the running time scales like foo(N) in the limit of large N |
| 00:00 | <Philip`> | (except it's stupid because for large N you're going to run out of memory) |
| 00:01 | <jgraham> | (unless you're Google) |
| 00:01 | <gsnedders> | Philip`: how does it deal with memory too? |
| 00:01 | <gsnedders> | (or me) |
| 00:01 | <gsnedders> | :P |
| 00:01 | gsnedders | needs more memory, badly. |
| 00:01 | <SadEagle> | gsnedders: An O(1) algorithm will take some small number of operations... An O(n) will do ~1 million. O(n^2) one will do ~10^12, a trillion... An O(log n) one will do something to the order of 20, etc. |
| 00:01 | <SadEagle> | Philip`: not really. Quadratic complexity shows up easily for very small input sizes. |
| 00:02 | <SadEagle> | gsnedders: it can be applied to that, yes, though that's not as common. |
| 00:02 | <Philip`> | gsnedders: You can say you're measuring memory rather than processing time, like saying that an array of size n requires O(n) memory |
| 00:02 | <gsnedders> | SadEagle: surely the number of ops. depends on the size of n? |
| 00:02 | gsnedders | squints |
| 00:03 | <SadEagle> | gsnedders: yes. but if you look at my examples, something that does about n^2 operations does a lot more work then something that does about n operations, when n is large enough. |
| 00:03 | gsnedders | forgot you stated what value n was |
| 00:04 | gsnedders | is too tired |
| 00:04 | <SadEagle> | 1 million for illustrative purposes.. |
| 00:04 | <SadEagle> | hmm, surely someone made a nice chart someplace.. Like probably on the WP article takkaria linked to. |
| 00:04 | gsnedders | needs to go sleep |
| 00:04 | <gsnedders> | g'nite |
| 00:05 | <jgraham> | goodnight |
| 00:11 | <annevk> | Hixie, Acid3 loads xhtml.1 three times |
| 00:11 | <Hixie> | duh |
| 00:11 | <Hixie> | suck, i do |
| 00:11 | <Hixie> | fixed, it is |
| 00:11 | <Hixie> | thanks |
| 00:14 | <annevk> | good, we still pass :) |
| 00:15 | <jwalden> | gsnedders: so, for O(f(n)), that implies that, given an input of size n, the algorithm runs in time/uses space in the range [c_1 * f(n), c_2 * f(n)], for all n > some k |
| 00:15 | <jwalden> | basically, long-run the runtime/space is proportional to f(n) |
| 00:16 | <jwalden> | oh, he left |
| 00:16 | <Dashiva> | Strictly speaking that's theta, not O |
| 00:16 | <Philip`> | O is only an upper bound |
| 00:16 | <SadEagle> | I am pretty sure he went to sleep :-) |
| 00:16 | <jwalden> | wrong; I said "in", not bounded by on both sides |
| 00:17 | <Philip`> | If it's in a range then that's bounding it on both sides |
| 00:17 | <Philip`> | (if it's a finite range, anyway) |
| 00:17 | <SadEagle> | well, he did permit c_1 to be 0, but also c_1 wasn't constraint to be positive :-) |
| 00:17 | <jwalden> | har har |
| 00:17 | jwalden | pulls out clrs |
| 00:17 | <Philip`> | What's wrong with an algorithm that takes negative time? |
| 00:18 | <Philip`> | You're dragging down the theory with mere practical concerns |
| 00:18 | <Dashiva> | There are algorithms based on answers from the future |
| 00:18 | <Dashiva> | Does that count as negative time? |
| 00:18 | <SadEagle> | f(n) = O(g(n)) iff \exists c > 0, n_0 >= 0. \forall n >= n_0. f(n) <= cg(n). |
| 00:19 | <Philip`> | What happens if your algorithm involves extreme gravitational forces and causes time itself to change as a function of n? |
| 00:19 | <SadEagle> | Philip`: yeah, it's probably extraneous if you actually want O and not theta :-) |
| 00:19 | <Hixie> | er guys, i don't want to worry y'all, but it looks like your keyboards have got errors |
| 00:19 | <Hixie> | the text you're writing is all coming out with lots of weird punctuation |
| 00:19 | <jwalden> | latex ftw |
| 00:20 | <jwalden> | yeah, I did mistype the bounds for O |
| 00:20 | <jwalden> | I meant the right thing, tho! |
| 00:20 | jgraham | notes there have been far too few \ for latex |
| 00:21 | <jwalden> | c_0 is totally latex |
| 00:21 | <Dashiva> | Intelligent sort is O(0), I wonder if you could make it negative somehow |
| 00:21 | <jgraham> | jwalden: Only in $ or some other math mode :) |
| 00:21 | <SadEagle> | Hixie: would you prefer MathML? |
| 00:22 | <jwalden> | heh |
| 00:22 | <Hixie> | SadEagle: :-P |
| 00:22 | <SadEagle> | (I guess that's one way of making me shut up :-) ) |
| 00:23 | <Hixie> | so, not to drag the topic of conversation back to html5 or anything, but i think i'm gonna have to make it so documents in session history always know what the last state object (from pushState) that was activated on that document is |
| 00:32 | <Hixie> | wow, i didn't mean to kill the conversation |
| 00:42 | <jgraham> | Hixie: What's the use case? |
| 00:42 | <Hixie> | making state objects work at all in the face of session history navigation |
| 00:42 | <Hixie> | the current algorithm is complete BS |
| 00:43 | <Hixie> | (this doesn't affect the APIs at all) |
| 00:57 | <Hixie> | jgraham__: very well expressed |
| 01:09 | <Hixie> | i checked in the aforementioned change |
| 03:24 | <Hixie> | hmmm |
| 03:24 | Hixie | investigates .query = '' and .hash = '' |
| 03:34 | <Hixie> | (s/query/search/. blame netscape people. probably brendan.) |
| 03:55 | <Lachy> | I wonder how the i18n WG realistically expects selectors api to require unicode case folding, given that an implementation of that in JavaScript is not trivial and would be ignored by most authros. |
| 04:08 | <Hixie> | what would it mean? |
| 04:08 | <Hixie> | case folding for what? |
| 04:08 | <Hixie> | prefixes? |
| 04:08 | <Lachy> | yes |
| 04:08 | <Hixie> | i thought the csswg had agreed to making that case-sensitive or something |
| 04:08 | <Hixie> | or ascii-only |
| 04:08 | <Lachy> | they somehow expect authors to implement that in their NSResolver |
| 04:09 | <Lachy> | the CSSWG agreed to make case sensitivity dependent upon the mechanism used to declare it |
| 04:09 | <Hixie> | oh |
| 04:09 | <Hixie> | so just make it sensitive |
| 04:09 | <Hixie> | and be done |
| 04:09 | <Lachy> | it basically is |
| 04:09 | <Hixie> | so what's the problem? |
| 04:10 | <Lachy> | did you read the mail from i18n WG on public-webapi? |
| 04:10 | <Hixie> | i read enough of it to know it wasn't my problem :-) |
| 04:10 | Hixie | looks again |
| 04:11 | <Hixie> | oh i see |
| 04:11 | <Lachy> | from the point of view of the UA, prefixes need to be treated case sensitively, so "foo" and "FOO" prefixes would need to be resolved separately. |
| 04:11 | <Hixie> | right |
| 04:11 | <Hixie> | but NSResolver can do whatever |
| 04:12 | <Hixie> | I would just remove all mention of the fact that the resolver can fold case |
| 04:12 | <Hixie> | since effectively that just means it's defining a set of prefixes |
| 04:12 | <Lachy> | yeah, so if the author implements a case insensitive NSResolver, they're effectively just declaring all variants of "foo", "Foo", "FOO", etc. |
| 04:12 | <Hixie> | right |
| 04:13 | <Hixie> | that removes your issue with the i18nguys |
| 04:13 | <Lachy> | I just need to figure out how to adjust the spec, without actually changing any requirements to keep them happy, and to respond to their mail |
| 04:15 | <Hixie> | hehe |
| 04:20 | Hixie | checks in his weird .search = '' issue |
| 04:21 | <Lachy> | I changed the first note to read: "Although prefixes are case sensitive, the implementation of the NSResolver object may internally handle them case insensitively. However, such an approach is effectively the same as declaring all case variants of the prefix with the same namespace URI." |
| 04:22 | <Hixie> | i think they'll still complain |
| 04:22 | <Hixie> | if they do, i'd just remove the note altogether :-) |
| 04:22 | <Hixie> | (after all, does it really help with anything?) |
| 04:22 | <Hixie> | brb |
| 04:26 | <Lachy> | I think I can resolve it in a way that they won't complain |
| 04:27 | <Lachy> | I think the original reason for the note was because Selectors required case insensitive prefixes |
| 04:27 | <Lachy> | but that's no longer the case |
| 04:30 | <Hixie> | right |
| 04:40 | <Hixie> | ok let |
| 04:40 | <Hixie> | us |
| 04:40 | <Hixie> | look |
| 04:40 | <Hixie> | at... |
| 04:40 | <Hixie> | the <m> element |
| 04:41 | <Hixie> | anyone have any opinions i should consider in addition to the tons of feedback? |
| 04:48 | <Lachy> | keep it! |
| 04:49 | <Lachy> | ignore everyone's feedback that disagrees with my opinion |
| 04:49 | <Hixie> | yeah, reading this i'm convinced there are good use cases for it |
| 04:49 | <Hixie> | i think we should change the name though |
| 04:49 | <Lachy> | to what? |
| 04:49 | <Hixie> | <m> is too short given that this won't be used that much |
| 04:49 | <Hixie> | i dunno |
| 04:50 | <Hixie> | <mark> maybe. <highlight> would be way too misspelt... |
| 04:51 | <Lachy> | <mark> is ok |
| 04:51 | <Lachy> | highlight also suffers from the perception of being presentational, which tends to receive a lot of complaints |
| 04:53 | <Hixie> | yes |
| 04:59 | <Hixie> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-February/009286.html is a great UI idea |
| 05:05 | <Hixie> | jesus, a lot of people mailed about <m> |
| 05:16 | <Lachy> | do you mean the aural example of the UA saying "begin mark. (content) end mark.", or the UI of skipping between marked text? |
| 05:16 | <Hixie> | ui |
| 05:18 | <Lachy> | how do I deal with the unicode normalisation issue? |
| 05:19 | <Lachy> | I obviously can't require the NSResolver to normalise the prefix. Could I require the UA to normalise the prefix before passing it to the resolver? |
| 05:21 | <Lachy> | I would rather not, since that would create more surface area for bugs, and be really annoying for authors if one UA had a bug in its normalisation algorithm, resulting in a different string being passed from other UAs |
| 05:35 | <Hixie> | well |
| 05:36 | <Hixie> | it depends on whether you want to require that UAs normalise before parsing the selectors, or whether you want to require that they not normalise |
| 05:36 | <Hixie> | might be easiest to jus check what implemenations are doing |
| 05:37 | <Lachy> | yeah. |
| 05:37 | <Lachy> | weinig, what does webkit do? |
| 05:38 | <weinig> | Lachy: sorry, i missed the beginning of the conversation. What is the question? |
| 05:39 | <Hixie> | Lachy: i wouldn't rely on implementors knowing what they do :-P |
| 05:39 | <weinig> | Hixie: :( |
| 05:39 | <Lachy> | [06:25] <Lachy> I obviously can't require the NSResolver to normalise the prefix. Could I require the UA to normalise the prefix before passing it to the resolver? |
| 05:39 | <Lachy> | [06:27] <Lachy> I would rather not, since that would create more surface area for bugs, and be really annoying for authors if one UA had a bug in its normalisation algorithm, resulting in a different string being passed from other UAs |
| 05:39 | <Hixie> | weinig: when it comes to unicode normalisation, am i wrong? :-) |
| 05:39 | <weinig> | Lachy: we have not implemented the NSResolver part of the spec yet |
| 05:39 | <weinig> | Hixie: no, you are not wrong :) |
| 05:39 | <Hixie> | see :-D |
| 05:40 | <Lachy> | oops, missed [06:24] <Lachy> how do I deal with the unicode normalisation issue? |
| 05:41 | <Lachy> | weinig, see point 3 in http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0095.html |
| 05:42 | <Lachy> | so, basically, the question is should the UA pass the prefix to the resolver in normalised form or exactly as it was used in the selector |
| 05:43 | <Hixie> | Lachy: xml requires normalisation of tag names right? |
| 05:43 | <Hixie> | Lachy: so the selector has to be normalised to that normalisation form anyway |
| 05:43 | <Hixie> | Lachy: so i'd say require that the selector be normalised to whatever normalisation form xml requires |
| 05:44 | <weinig> | Lachy: hm, it seems that if we normalization of the prefix, that also means we have to normalize the selectors |
| 05:44 | <Lachy> | I'm not sure what XML says about normalisation |
| 05:44 | <Hixie> | check :-) |
| 05:44 | <weinig> | Lachy: oh, I see Hixie just said that :) |
| 05:44 | <Lachy> | do you normalise the selectors? |
| 05:44 | <weinig> | Lachy: I don't believe so |
| 05:45 | <weinig> | Lachy: though, as Hixie noted, I may not know :) |
| 05:45 | <Hixie> | spec writing involves doing a lot of study work, examining implementations and other specs :-P |
| 05:45 | weinig | nods |
| 05:45 | Lachy | is too lazy for that :-) |
| 05:46 | <Hixie> | could be a problem :-) |
| 05:46 | <weinig> | I am going to say that we in fact do not normalize the string before parsing the selector |
| 05:47 | <Hixie> | you sure? i wouldn't bet in your js layer did it for you... |
| 05:47 | <Hixie> | er |
| 05:47 | <Hixie> | s/bet/be surprised/ |
| 05:47 | weinig | checks there |
| 05:48 | <Hixie> | afk |
| 05:48 | Lachy | wonders how to write a test to see how browsers handle normalisation |
| 05:49 | <weinig> | Lachy: that could obviate most of these questions :) |
| 05:49 | <Lachy> | the Selectors spec says nothing about normalisation |
| 05:49 | <weinig> | I didn't think ECMAScript required normalization of strings |
| 05:50 | <Lachy> | I don't think it does either |
| 05:51 | <weinig> | in that case, I really don't think we normalize, but I would still like to test it |
| 05:51 | <weinig> | ap would know for sure |
| 05:52 | <Lachy> | can you find out from whoever knows and send feedback about it to public-webapi? |
| 05:53 | <weinig> | Lachy: yes |
| 05:53 | Lachy | needs to discuss it with the devs at opera |
| 05:53 | <Lachy> | thanks |
| 05:53 | <weinig> | no problem |
| 08:27 | <annevk> | Lachy, no need to do normalization |
| 08:27 | <annevk> | Lachy, nobody does that |
| 08:33 | <hsivonen> | jgraham++ |
| 08:37 | <Hixie> | annevk: it's done more than you think |
| 08:38 | <Hixie> | (and there are multiple types of normalisation) |
| 08:38 | <Hixie> | (some of which make a lot of sense to do at certain points, others don't) |
| 08:39 | <Hixie> | however, it seems xml doesn't require normalisation |
| 08:39 | <Hixie> | so it would seem best to not do it here |
| 08:39 | <Hixie> | why am i doing this research :-P |
| 08:40 | Hixie | goes back to doing the research for his own spec :-P |
| 08:41 | <annevk> | I'd be interested to know where NFC is applied in specifications authors deal with and authors provide the strings |
| 08:42 | <Hixie> | NFKC is applied when creating the punycode form of IDN, iirc |
| 08:44 | <annevk> | ah, yeah |
| 08:45 | <annevk> | I guess that's because i18n experts have been actively involved in that |
| 08:45 | <Hixie> | it would be a security disaster if it wasn't |
| 08:45 | <Hixie> | it's bad enough as it is |
| 08:46 | <annevk> | true |
| 11:14 | <annevk> | heycam, any chance you can make an update for test 69 in Acid3? the summary for instance is bogus now |
| 11:14 | <annevk> | well, partially bogus |
| 11:28 | <webben> | Lachy: Hi there, with http://lachy.id.au/log/2005/05/script-comments in the "The Correct Method for XHTML" what's the // in //]]> for? contrasting with http://www.w3.org/TR/xhtml1/#h-4.8 |
| 11:29 | <Lachy> | that applies when serving as text/html, as the article should point out |
| 11:29 | <Lachy> | it's to comment it out so it doesn't cause a JS error |
| 11:30 | <Lachy> | oh, oops |
| 11:30 | <Lachy> | yeah, it's not needed. |
| 11:30 | <Lachy> | but harmless |
| 11:30 | <hsivonen> | What's the browser support status of http://contentlabel.org/ ? |
| 11:31 | <hsivonen> | (the technology advocated--not the site itself) |
| 11:34 | <Lachy> | Since it uses RDF and believes it can some how use it to increase trust (highly unlikely), I'm going to guess zero support |
| 11:37 | <webben> | I http://contentlabel.org/firefox-extension-that-reads-semantic-labelled-sites/ |
| 11:38 | <webben> | so it's vapourware except for their own Fx extension |
| 11:39 | <webben> | (which isn't as bad as some things, I guess) |
| 11:40 | <hsivonen> | it's not clear to me what the motivation is. 1) Protecting children? 2) Causing an illusion of porn self-regulation in order to lessen government interest in statutory regulation 3) find a nail for a SemWeb hammer. 4) something else? |
| 11:41 | <gsnedders> | It's possible to filter the web. kthxbai. |
| 11:41 | <webben> | hsivonen: Sell Segala trust labels I suspect. |
| 11:42 | <hsivonen> | webben: hmm. yeah, that's a very plausible explanation |
| 11:43 | <webben> | I think currently their main customer is O2. |
| 11:44 | <webben> | how useful segala certification is perhaps open to doubt however: http://www.blether.com/archives/2006/06/da_vinci_code_t.php |
| 11:44 | <annevk> | "Using W3C standards such as RDF makes mass adoption for Content Labels more seamless in our opinion." hmm |
| 11:45 | <webben> | well, using standards /should/ help adoption (at least, assuming the standards are workable) |
| 11:47 | <webben> | and there are plenty of tools that can extract stuff from RDF |
| 11:47 | <gsnedders> | All W3C standards are totally widespread. |
| 11:47 | <webben> | gsnedders: well, all w3c standards are at least open to implementors |
| 11:47 | <gsnedders> | webben: That's not overly relevant if nobody uses them, though |
| 11:48 | <annevk> | though not all are implementable |
| 11:48 | <webben> | like I said: "assuming the standards are workable" |
| 11:48 | <webben> | RDF has been implemented, so it is workable. |
| 11:50 | <Lachy> | RDF is too complicated and only solves imaginary problems |
| 11:50 | <webben> | indeed, it's even implemented in browsers to some degree. |
| 11:54 | <webben> | 'saying stuff about stuff in a machine-readable manner" is an imaginary problem? |
| 11:55 | <webben> | or do you mean the added complications only solve imaginary problems in that task? |
| 12:01 | <hsivonen> | hmm. looks like Segala is into the MobileOK stuff as well |
| 12:01 | <hsivonen> | I don't like MobileOK at all |
| 12:02 | <webben> | how come? |
| 12:02 | webben | hasn't looked at it. |
| 12:03 | <webben> | http://www.w3.org/TR/mobileOK-basic10-tests/ ... interesting worked on by a google fellow and someone who used to work at Segala |
| 12:03 | <hsivonen> | webben: the Mobile OK thing is based on the assumption that mobile browsers suck and that content needs to be dumbed down |
| 12:04 | <webben> | well, that's probably true of a lot of current deployment |
| 12:05 | <webben> | hopefully not so true in future |
| 12:05 | <hsivonen> | webben: The mobile browsers I use can do much more than what is assumed by Mobile OK |
| 12:05 | <webben> | yes, I'd tend to assume web-loving folk would use better clients than average |
| 12:05 | <hsivonen> | webben: the mobile browsers I use are based on Gecko, Opera and WebKit |
| 12:06 | <webben> | yes, but those are very much a new breed aren't they? |
| 12:07 | <webben> | guess it depends how fast such devices get rolled out into growth markets |
| 12:07 | <hsivonen> | webben: I have about zero sympathy for bad products when at least three better ones are available |
| 12:08 | <hsivonen> | webben: Opera Mini works on remarkably sucky phones |
| 12:08 | <webben> | opera mini is good |
| 12:08 | <webben> | dunno what the state of its localization is though |
| 12:11 | <webben> | http://operawatch.com/news/2007/11/opera-mini-translated-into-over-50-languages-15-more-to-come-later-this-month.html |
| 13:03 | <hsivonen> | http://lists.w3.org/Archives/Public/public-html-comments/2008Feb/0011.html |
| 13:03 | <hsivonen> | I'm not sure how I should react |
| 13:05 | <annevk> | http://annevankesteren.nl/2007/04/html-red-pill |
| 13:23 | Philip` | wonders why Opera uses 1005MB of memory and then takes two minutes to exit |
| 13:28 | <hsivonen> | well, replied anyway. |
| 13:42 | <jwalden> | "The reference image for Acid3 as rendered by WebKit r30069." wow, Wikipedia, thanks for telling me that this *reference image* screenshot was done with WebKit, and with a revision number too! |
| 13:48 | <annevk> | you can fix that :p |
| 13:49 | <annevk> | I wonder why they took out the screen shots of beta releases though |
| 13:53 | <krijnh> | Philip`: I have that constantly |
| 13:56 | <krijnh> | Hope it's fixed with 9.5 |
| 13:59 | <annevk> | for real? |
| 13:59 | annevk | doesn't have that problem at all |
| 13:59 | <krijnh> | I haven't installed 9.2 |
| 14:00 | <krijnh> | Perhaps that's the problem |
| 14:00 | <Philip`> | Steps to reproduce: Visit lots of web pages for a couple of days |
| 14:00 | <krijnh> | I had a laptop crash, bought a new one, and copied the Opera dir from my other disk |
| 14:00 | <Philip`> | (I'm using 9.2something) |
| 14:00 | <krijnh> | (which is one of the best things Opera provides) |
| 14:00 | <Philip`> | (It's not a problem with e.g. Flash, because I've got plugins disabled since Flash didn't work anyway) |
| 14:01 | <krijnh> | (and we both like parentheses) |
| 14:02 | <Philip`> | (They are an aesthetically pleasing curve) |
| 14:02 | <krijnh> | Perhaps it's Vista |
| 14:02 | Philip` | is using Linux |
| 14:03 | <krijnh> | I don't think it's Vista |
| 14:03 | <krijnh> | :p |
| 14:03 | <krijnh> | Mem usage here is around 200MB, even after closing Opera |
| 14:03 | <krijnh> | And it drops after a few minutes |
| 14:04 | <krijnh> | And if you restart it when it's not closed down yet, I get a mail init error |
| 14:04 | <krijnh> | s/you/I |
| 14:05 | <krijnh> | Anyway, I'm still alive, so it's probably not a big issue :) |
| 14:13 | <annevk> | Philip`, I almost never reboot Opera and I don't encounter this problem (I'm on Linux too, Opera 9.2x) |
| 14:13 | <annevk> | hopefully it's better in 9.5 |
| 14:18 | <krijnh> | annevk: you also use M2? |
| 14:18 | <annevk> | yeah |
| 14:19 | <annevk> | and IRC |
| 14:19 | <krijnh> | Hmm |
| 14:19 | <krijnh> | 9.5 also takes a while to close down for me, on a different machine |
| 14:45 | <annevk> | hmm, I can project my laptop on my TV, but not both at the same time :( |
| 14:55 | <Philip`> | The laptop display switches off when you connect the TV? |
| 14:57 | <annevk> | some distorted display, now it sort of works |
| 14:58 | <annevk> | it's not perfect though as my TV only shows 2/3 of the screen |
| 14:59 | <annevk> | tv has a res of 1360x768 and the laptop has 1680x1080 |
| 15:00 | <annevk> | but I can watch movies now, sort of |
| 15:01 | <annevk> | (oh also sound isn't patched through, but I guess that's to be expected with a VGA connector :) ) |
| 15:06 | <hsivonen> | annevk: hmm. 1080p laptop. nice. what are the physical dimensions? |
| 15:07 | <Philip`> | 1080p is usually 1920x1080, so it's a bit misleading to call it that |
| 15:08 | <hsivonen> | oh. right |
| 15:11 | Philip` | discovers that Ubuntu's do-release-upgrade is not foolproof, as it failed with "Could not install the upgrades. The upgrade aborts now. Your system could be in an unusable state." |
| 15:11 | <hsivonen> | I went to a home eletronics store the other day. they had a wall full of flat 720p and 1080p TVs and the same blu-ray 1080p feed into all of them |
| 15:11 | <hsivonen> | I couldn't tell the difference between 1080p and 720p |
| 15:12 | <hsivonen> | and I couldn't tell the difference between 890 euro models and 1700 euro models |
| 15:12 | <hsivonen> | makes one go hmm. |
| 15:15 | <Philip`> | The only TV I watch is over streaming Flash and costs me £0 (plus no TV Licence fee) and the quality seems perfectly adequate :-) |
| 15:16 | <Philip`> | But movies are different, since quality is often much more important there |
| 15:20 | <jwalden> | Philip`: exactly what drugs were you on when you decided you wanted to do Element.setAttribute(":", ...) anyway? :-P |
| 15:21 | <Philip`> | jwalden: I just wanted to do things http://philip.html5.org/tools/parser/?%3Ctest%3Atest%20test%3Atest%20%3Atest%3E and detect when I was about to create an invalid attribute so I could get rid of the offending characters |
| 15:22 | <Philip`> | s/things/things like/ |
| 15:23 | <Philip`> | but that turns out to be impossible because "invalid attribute" varies between browsers, rather than following any standard |
| 15:26 | <jwalden> | not like anyone actually specified that at the time browsers implemented it, really |
| 15:26 | jwalden | wonders why hand-waving is so prevalent in specs |
| 15:26 | <Philip`> | I'd be happiest if nothing was considered an invalid attribute, since otherwise it's impossible to write a conforming HTML5 parser using the JS DOM |
| 15:27 | <jwalden> | Element.setAttribute(" foo='bar' baz", "quux") |
| 15:27 | <jwalden> | attribute injection! |
| 15:29 | <Philip`> | Wouldn't it be easier to do Element.setAttribute('foo', 'bar') if you're able to control the arguments? :-p |
| 15:29 | <jwalden> | not necessarily, if the first argument was checked against a blacklist |
| 15:30 | <jwalden> | I don't presume to expect rational behavior in random web apps |
| 15:30 | <jwalden> | cf. ":" ;-) |
| 15:31 | <Philip`> | IE and Opera users would already be vulnerable if a web app did that |
| 15:31 | <Philip`> | hence web apps can't do that |
| 15:32 | <Philip`> | hence it's not a security problem :-) |
| 15:32 | jwalden | defines security problems out of existence |
| 20:38 | <Fiboknight> | hello |
| 20:38 | <Lachy> | Fiboknight, hi |
| 20:38 | <Fiboknight> | how may i get access to your irc log script? |
| 20:38 | <Lachy> | ask krijnh |
| 20:38 | <Lachy> | he runs it |
| 20:39 | <Fiboknight> | oh ok |
| 20:39 | <Fiboknight> | are you a dev as well? |
| 20:40 | <Lachy> | I was a web developer |
| 20:42 | <Fiboknight> | cool |
| 21:53 | <gsnedders> | do adjacent text nodes have implicit whitespace between the two? |
| 21:54 | <gsnedders> | Lachy: see the email I sent? |
| 22:08 | <Hixie> | they do not |
| 22:11 | <gsnedders> | that's what I expected |
| 22:11 | <gsnedders> | Why would (in Python) `else Element.textContent:` cause a syntaxerror? |
| 22:11 | <Dashiva> | why not? |
| 22:12 | <hasather> | gsnedders: elif |
| 22:12 | <gsnedders> | hasather: oh duh. |
| 22:12 | gsnedders | headdesks |
| 22:12 | <gsnedders> | thx |
| 22:12 | <Dashiva> | This is not the syntax you're looking for *handwave* |
| 22:13 | <gsnedders> | Dashiva: hey! I'm allowed to be dumb at times! :) |
| 22:13 | <gsnedders> | Dashiva: don't be mean to the kid! |
| 22:14 | <Dashiva> | I'm just trying to lighten the mood with some humor |
| 22:15 | <gsnedders> | And I'm being totally serious :) |
| 22:15 | <gsnedders> | (obviously) |
| 22:15 | <gsnedders> | </sarcasm> |
| 22:15 | <Dashiva> | Parse error |
| 22:15 | <gsnedders> | Dashiva: what? you think you need a start tag! Silly XML making you think such things. |
| 22:15 | <Hixie> | <sarcasm> is an optional start tag |
| 22:16 | <gsnedders> | like <html>, <head>, and <body> |
| 22:16 | gsnedders | actually saw a real site which omitted the opening head tag, but not the closing one, a few weeks ago |
| 22:16 | <Dashiva> | gsnedders: Since when is IRC sent as text/html? :P |
| 22:17 | <gsnedders> | Dashiva: it's text/plain;charset=unknown, so why any parser error ever? :P |
| 22:18 | <Dashiva> | I have to parse your writing to understand it |
| 22:18 | <gsnedders> | peh! |
| 22:18 | <gsnedders> | parsing is overrated. |
| 22:19 | <Hixie> | wow, the whatwg copy of html5 sure has dropped down the rankings |
| 22:19 | <gsnedders> | Hixie: talking of HTML 5, you have any need for ul.toc on _every_ nested ul in the TOC? |
| 22:20 | <gsnedders> | actually, why isn't it an ol? |
| 22:21 | <Hixie> | no idea on either point |
| 22:21 | <gsnedders> | it should be an ol, no? |
| 22:21 | <Hixie> | probably |
| 22:22 | gsnedders | goes back to designing an algorithm to actually create the TOC |
| 22:22 | <Hixie> | the html5 spec has one of those :-) |
| 22:23 | <Hixie> | though it's hard to understand |
| 22:23 | <gsnedders> | it does? |
| 22:23 | <gsnedders> | oh, that one |
| 22:23 | gsnedders | totally forgot |
| 22:25 | <gsnedders> | the creating an outline section? |
| 22:26 | <Lachy> | gsnedders, the proxy script you sent me doesn't correctly pass the username and password |
| 22:26 | <gsnedders> | Lachy: I just realised that |
| 22:28 | jgraham | has an imp. of the HTML 5 algorithm somewhere but doesn't recommend it |
| 22:31 | gsnedders | emails Lachy the "don't write PHP scripts quickly thinking you can write them fine" edition. |
| 22:31 | <Hixie> | jgraham: the alg, or the results? |
| 22:32 | <jgraham> | Hixie: What do you mean results? |
| 22:32 | <jgraham> | I think the algorithm does the right thing |
| 22:32 | <jgraham> | (more or less) |
| 22:32 | <Hixie> | that's what i meant by results |
| 22:34 | <jgraham> | I mostly meant that I don't recommend my implementation, although I have no particular love for the way the algorithm is expressed either |
| 22:34 | gsnedders | is scratching his head at parts of the description |
| 22:35 | <Hixie> | jgraham: k |
| 22:35 | <Hixie> | bbl |
| 22:35 | <gsnedders> | bye |
| 22:37 | <gsnedders> | (I actually meant creating the actual TOC output, not creating it internally, but hey) |
| 22:39 | <Lachy> | gsnedders, you still didn't get it quite right :-) |
| 22:39 | <Lachy> | but I fixed it |
| 22:39 | <gsnedders> | Lachy: what now? |
| 22:39 | <gsnedders> | oh. ). |
| 22:39 | <Lachy> | yeah |
| 22:39 | <Lachy> | it all works |
| 22:40 | <gsnedders> | A change so minor that "nothing" can go wrong. But of course it now causes parse errors. Typical :) |
| 22:46 | gsnedders | waves g'nite |
| 23:58 | <Fiboknight> | please someone help me with an irc logger |