| 00:00 | MikeSmith | needs to get better fonts.. or bigger ones.. or better eyes |
| 00:01 | <Hixie> | a lot of these restrictions are there purely for compatibility with xml |
| 00:02 | <Hixie> | if it wasn't for staying roughly compatible with xml, we could make some pretty good changes |
| 00:02 | <MikeSmith> | so maybe it could help if I wrote up an informational document about those |
| 00:02 | <MikeSmith> | unless somebody else already has |
| 00:02 | <MikeSmith> | on the wiki or somewhere |
| 00:03 | <Hixie> | help how? |
| 00:03 | <Philip`> | Help who? |
| 00:04 | <Philip`> | (Oh, are there really no more anagrams for "how"? :-( ) |
| 00:04 | <MikeSmith> | heh |
| 00:04 | <MikeSmith> | help people who want to put together documents that are going to be processing as they'd expect without having side effects they don't want |
| 00:04 | <Hixie> | i don't follow |
| 00:04 | <MikeSmith> | e.g, the reason why you should not put an XML declaration in a document served as text/html |
| 00:05 | <MikeSmith> | well, one of the reasons |
| 00:05 | <MikeSmith> | the most important one being that it will put IE6 into quirks mode |
| 00:05 | <MikeSmith> | most people don't know that |
| 00:05 | <Hixie> | isn't that basically the only reason? |
| 00:05 | <MikeSmith> | or don't remember it |
| 00:06 | <MikeSmith> | Hixie: I guess another reason would be that it doesn't otherwise have any effect |
| 00:06 | <MikeSmith> | e.g., if you try to use it set encoding, it's not going to do anything |
| 00:06 | <Philip`> | MikeSmith: Like a subset of HTML5's conformance criteria, but only for compatibility concerns, ignoring all the issues of good taste and readability and accessibility and whatever? |
| 00:06 | <MikeSmith> | yeah, pretty much |
| 00:07 | <MikeSmith> | just listing things that are "gotchas", I guess |
| 00:07 | <MikeSmith> | I occasionally get questions about this kind of stuff off-list |
| 00:07 | <Hixie> | MikeSmith: then there's a lot of other crap we should make illegal :-) |
| 00:07 | <Hixie> | like xmlns="" |
| 00:07 | <Hixie> | and /? |
| 00:07 | <Hixie> | er /> |
| 00:08 | <MikeSmith> | well, yeah |
| 00:08 | <Hixie> | the only reason they're allowed is to make polyglots possible |
| 00:08 | <Hixie> | though personally i wish we could go in the other direction |
| 00:08 | <Hixie> | far, far in the other direction |
| 00:09 | <MikeSmith> | Hixie: I know but that position seems to be out of sync with the range of authors/content providers who say they want to do it and seem to feel pretty strongly about it |
| 00:10 | <Hixie> | most of them think that they're doing stuff simple enough that it won't be a problem |
| 00:11 | <Hixie> | and i think (a) they're likely to either be wrong already or soon will be, and (b) they are misleading others into thinking they are in a similar situation |
| 00:11 | <MikeSmith> | I don't know about most but I am sure many |
| 00:11 | <Hixie> | those who don't think they're doing stuff simple enough that it won't be a problem are unlikely to want to do it, since by definition they think they'd have a problem :-) |
| 00:12 | <MikeSmith> | I think point (b) is the more important one |
| 00:13 | <Hixie> | the xml/html dichotomy is worse than the c/C++ dichotomy |
| 00:13 | <MikeSmith> | perhaps we should require that people who believe they know what they are doing should include a disclaimer in their content along the lines of "Trained professional driver. Don't try this as home." |
| 00:13 | <MikeSmith> | of course then others would just cargo-cult copy that disclaimer too |
| 00:14 | <MikeSmith> | we clearly need some certification/regulation here |
| 00:15 | <MikeSmith> | what we have now is more kinda like the gun-control (or lack of gun-control) situation in the US |
| 00:15 | <Hixie> | sam's the only person whose source i have examined whom i know has done this seriously enough to really be considered a train professional driver |
| 00:15 | <Hixie> | and he recommends against it |
| 00:15 | <MikeSmith> | right |
| 00:15 | <Hixie> | but i'm tired of arguing this point, if people want to do it, then fine |
| 00:16 | <MikeSmith> | yeah |
| 00:16 | <MikeSmith> | so to get back to the context for my original question, my motivation is just my own general laziness |
| 00:16 | <Philip`> | Don't bother with certification, just make the technology as complex as possible then charge people $1500 for a three-day course on it |
| 00:16 | <Philip`> | Saves all the effort of printing proper certificates |
| 00:17 | <MikeSmith> | yeah, that seems to be working well for a lot of technologies/standards |
| 00:17 | <MikeSmith> | we must raise the barrier for entry |
| 00:17 | <MikeSmith> | make it much more painful |
| 00:17 | <MikeSmith> | people learn best from pain |
| 00:18 | <MikeSmith> | I know I do |
| 00:20 | <MikeSmith> | anyway, I would just rather be able to point people to "list of stuff that you really should not be doing even though you think it should be OK" doc instead of answering (or attempting to answer) the same kinds of questions in private e-mail repeatedly |
| 00:22 | <MikeSmith> | or instead of people using reading docs like http://www.w3.org/TR/xhtml-media-types/ and assuming they actually reflect real-world best practices |
| 00:24 | <MikeSmith> | I can see that there are sections of that doc that simon pointed out specific problems with more than a year ago but for which no changes were ever made |
| 00:25 | MikeSmith | apologizes for the monologue |
| 01:00 | <AryehGregor> | Hixie, FWIW, MediaWiki serves HTML5 as well-formed XML by default now because some people screen-scrape with bots that use XML parsers. |
| 01:00 | <AryehGregor> | Of course, they should be using our bot API anyway, but oh well. |
| 01:07 | <Hixie> | did they use such parsers before you used XHTML? |
| 01:11 | <AryehGregor> | MediaWiki has always used XHTML, as far as I know. |
| 01:12 | <AryehGregor> | If we hadn't, I assume they would have just done it with regex, which is worse by most standards. |
| 01:14 | <AryehGregor> | Hmm, no, it looks like it started as 4.01. |
| 01:14 | <AryehGregor> | But it's been XHTML for years. |
| 01:20 | <AryehGregor> | http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=3087 |
| 01:20 | <AryehGregor> | Since April 2004. |
| 01:31 | <AryehGregor> | http://validator.nu/?doc=http://en.wikipedia.org/wiki/ |
| 01:31 | <AryehGregor> | Hurrah. |
| 01:32 | <AryehGregor> | Now we just need to convince people to clean up their cruddy table markup. :) |
| 01:32 | AryehGregor | will e-mail the list when he's reasonably certain the change won't be reverted |
| 01:33 | <AryehGregor> | I think this now gives HTML5 a few orders of magnitude more web deployment than any XHTML beyond 1.0 ever had. *Maybe* not 1.1, dunno. |
| 01:34 | <Hixie> | i guess if you'd never used xhtml, people might be using the api :-) |
| 01:34 | <AryehGregor> | Well, we first supported XHTML a few years before we had an API. |
| 01:35 | <AryehGregor> | Anyway, no. From experience, people would screen-scrape with regex. |
| 01:35 | <AryehGregor> | An amazing number do that even when we use XHTML. |
| 01:35 | <AryehGregor> | (which we're no longer doing as of six minutes ago) |
| 01:35 | <AryehGregor> | (although still serving well-formed XML, so it amounts to the same for this) |
| 01:37 | <Hixie> | yeah fair point |
| 01:39 | <AryehGregor> | Actually, to be fair to bot authors, most of the screen-scraping bots date to back when we didn't have a good bot API. |
| 02:15 | <mpilgrim> | boy, that old discussion on tbray's blog brings back some memories |
| 02:18 | <AryehGregor> | Error: syntax error |
| 02:18 | <AryehGregor> | Source File: http://en.wikipedia.org/w/index.php?useskin=monobook&title=User%3ASimetrical%2FTest%20Twinkle&action=submit |
| 02:18 | <AryehGregor> | Line: 1, Column: 1 |
| 02:18 | <AryehGregor> | Source Code: |
| 02:18 | <AryehGregor> | <!doctype html> |
| 02:18 | <AryehGregor> | Um, yay? |
| 02:39 | <AryehGregor> | Okay, so apparently nobody noticed or cared to point out that switching to <!doctype html> will cause all XHR to fail with a syntax error? |
| 02:40 | <AryehGregor> | At least, that's what I'm seeing. |
| 02:47 | <AryehGregor> | Ah, it has to be <!DOCTYPE html> for well-formedness. Now they tell me. |
| 03:17 | <AryehGregor> | . . . that just leaves the fact that named entities are syntax errors. |
| 03:19 | <AryehGregor> | Okay, so apparently if you use <!DOCTYPE html>, named entities become XML well-formedness errors, so it's impossible to use XMLHttpRequest. |
| 03:19 | <AryehGregor> | This seems like a pretty significant problem. Is there any way around it? If not, can some other kind of doctype be allowed that doesn't trigger it? |
| 03:20 | AryehGregor | looks at Hixie |
| 03:20 | <othermaciej> | or don't use named entities |
| 03:20 | <othermaciej> | or don't use XML, and just parse your results as HTML (for example by putting in an iframe) |
| 03:20 | <AryehGregor> | Okay, let's assume that I'm not willing to find every single use of named entities in an application that's several hundred thousand LOC with gigabytes of content in the database. |
| 03:21 | <AryehGregor> | So you're saying don't use XHR, make people use <iframe>s instead? |
| 03:21 | <AryehGregor> | Surely that must have some disadvantages? To begin with, it breaks all legacy codebases that expect XHR to work, so it's sort of out of the question for me right now. |
| 03:21 | <AryehGregor> | I thought <!doctype html> was chosen so that it had no significant compat issues. |
| 03:22 | <AryehGregor> | It seems like there's no way to have a valid HTML5 document that contains a named entity and works with XHR? |
| 03:22 | <MikeSmith> | doesn't the spec allow HTML4 and XHTML1 doctypes too? |
| 03:23 | <AryehGregor> | MikeSmith, doesn't seem like it: http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#the-doctype |
| 03:23 | <othermaciej> | it makes them work - I don't think it makes them conforming |
| 03:23 | <othermaciej> | AryehGregor: you could use XHR and inject into an iframe to get HTML parsing, is what I'm saying |
| 03:24 | <othermaciej> | AryehGregor: I don't think anyone though of the compat issue around named entities, and in fact what browsers do there for XML is weird |
| 03:24 | <AryehGregor> | So in other words do XHR, but instead of using requestXML, create an iframe and stick requestText into its innerHTML or such. |
| 03:24 | <othermaciej> | yeah |
| 03:24 | <MikeSmith> | the conforming-but-obsolete section allows them, I think |
| 03:24 | <MikeSmith> | or did |
| 03:24 | <othermaciej> | although if it were me I would sooner sacrifice HTML5 conformance in the XHR-transmitted content than do that |
| 03:25 | <AryehGregor> | Well, consider this some real-world experience with trying to move to HTML5. It lasted under two hours before being disabled due to blocker compatibility problems. |
| 03:25 | <AryehGregor> | othermaciej, yep. |
| 03:25 | <AryehGregor> | Of course, XHR-transmitted content is potentially any page on the site, so. |
| 03:25 | <AryehGregor> | Oh, hmm: http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#obsolete-permitted-doctype |
| 03:26 | <othermaciej> | is processing XHTML via XHR a common use case? (I have no idea) |
| 03:26 | <othermaciej> | I guess any XHTML you send as XML, if you have to fix entities, that's a big stumbling block to migrating |
| 03:26 | <othermaciej> | file a bug IMO |
| 03:26 | <AryehGregor> | othermaciej, I know it took less than thirty minutes for me to receive a report of a widely-used tool on Wikipedia breaking. |
| 03:26 | <AryehGregor> | I was thinking I'd post to the list. |
| 03:27 | <othermaciej> | oh, obsolete permitted doctype |
| 03:27 | <MikeSmith> | a bug on this would be great |
| 03:27 | <AryehGregor> | In the W3C bug tracker? I'm not sure I have an account. |
| 03:27 | <othermaciej> | do those trigger a warning or error? it's not clear |
| 03:27 | <TabAtkins> | AryehGregor: XHR will parse HTML properly in the future. It's there in the XHR2 spec. |
| 03:27 | <othermaciej> | anyone can make a W3C bugzilla account |
| 03:27 | <othermaciej> | same as any other bugzilla |
| 03:28 | <AryehGregor> | othermaciej, it says obsolete but conforming, so I assume that means it's conforming. |
| 03:28 | <MikeSmith> | AryehGregor: http://www.w3.org/Bugs/Public/ |
| 03:29 | <MikeSmith> | yeah, that obsolete-permitted-doctype thing is only in the full (implementor) view |
| 03:29 | <MikeSmith> | not in the author view |
| 03:29 | <MikeSmith> | seems like it should be in the Writing HTML section too |
| 03:30 | <MikeSmith> | anyway, I think the intent was for those to trigger a warning, not an error |
| 03:30 | <MikeSmith> | I don't think v.nu has been updated yet to reflect that |
| 03:32 | <MikeSmith> | yeah, section 12.1.1 explicitly says they should trigger warnings |
| 03:38 | karlcow | is wondering if html5 mandates Accept headers depending on the tag (html) or property (css) used. |
| 03:38 | <karlcow> | for now, it's kind of nightmarish and create issues for Web development. |
| 03:47 | <AryehGregor> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=8268 |
| 03:48 | <AryehGregor> | Okay, I'm going to bed. |
| 03:48 | <MikeSmith> | karlcow: example? |
| 03:48 | <MikeSmith> | AryehGregor: thanks man |
| 03:48 | <MikeSmith> | (for filing the bug) |
| 03:49 | <AryehGregor> | Shall I post to the list too? |
| 03:49 | <AryehGregor> | Not many people follow Bugzilla. |
| 03:54 | <karlcow> | MikeSmith: once/when the html file is downloaded by the browser, other resources are being requested by an HTTP GET |
| 03:54 | <karlcow> | Let's say in the case of IMG |
| 03:55 | <karlcow> | <img src="http://example.net/toto"/>; |
| 03:55 | <MikeSmith> | karlcow: ah, content negotation stuff? |
| 03:56 | <karlcow> | Firefox sends Accept: image/png,image/*;q=0.8,*/*;q=0.5 |
| 03:56 | <karlcow> | which is cool |
| 03:56 | <karlcow> | but webkit seems to send "*/*" |
| 03:57 | MikeSmith | nods |
| 03:57 | <karlcow> | and Opera |
| 03:57 | <karlcow> | and Opera text/html, application/xml;q=0.9, application/xhtml+xml, application/x-obml2d, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 |
| 03:57 | <thedj> | karlcow: you should see what some mobile browsers send. that will kill you on the spot :D |
| 03:57 | <karlcow> | the issue popped up last week end in a real case |
| 03:58 | <karlcow> | and killed one of our site |
| 03:58 | <karlcow> | The <img src="http://example.net/toto"/>; was on a very high trafic Web site. |
| 03:59 | <karlcow> | unfortunately the URI was an html resource and not an image. |
| 03:59 | <karlcow> | ooops |
| 03:59 | <karlcow> | s/and not an image/but an image/ |
| 03:59 | <karlcow> | rha |
| 03:59 | <karlcow> | tired |
| 03:59 | <karlcow> | unfortunately the URI was an html resource and not an image. |
| 04:00 | <karlcow> | so the little site sent thousands of html file by minutes |
| 04:00 | <karlcow> | and eventually died |
| 04:01 | <AryehGregor> | What does Accept have to do with this? |
| 04:01 | <AryehGregor> | Do web servers even pay attention to Accept in normal configuration? |
| 04:01 | <karlcow> | One of the way to avoid it would have been when you see this "Accept: image/*" and the URI is known to be html, reply with a "406 Not Acceptable" |
| 04:02 | <AryehGregor> | Mostly things just ignore content negotiation. |
| 04:02 | <AryehGregor> | Probably better to, um, not put a large HTML page as an image src? |
| 04:02 | <karlcow> | AryehGregor: the big site with high trafic was not under the control of the little guy. |
| 04:03 | <karlcow> | Basically it creates a (not voluntary) DDOS |
| 04:03 | <AryehGregor> | So I guess your point is that forums and so on allow people to post <img>, so people could do that maliciously on a really big file. |
| 04:03 | <AryehGregor> | Thus DDoS. |
| 04:03 | <AryehGregor> | Interesting thought. |
| 04:03 | <karlcow> | :) |
| 04:03 | <AryehGregor> | I dunno if Accept is the way to do it. |
| 04:04 | <AryehGregor> | Maybe ask some browser vendors why they have */* at the end there instead of image/*. |
| 04:04 | <karlcow> | Accept could have been a way but not in the state of implementations so far |
| 04:05 | <karlcow> | in Rails it took only 2 minutes to implement the method to filter on the Accept and URI combinations, but was working only with firefox |
| 04:07 | AryehGregor | sends an e-mail to the list about his doctype issue |
| 04:08 | <AryehGregor> | Oh, looks like MikeSmith echoed it to public-html already. |
| 04:08 | <AryehGregor> | Oh well. |
| 08:15 | <Hixie> | AryehGregor: was your question earlier about doctypes for xml or html? |
| 08:19 | <othermaciej> | Hixie: his question was about xml (well, really polyglot documents) |
| 08:20 | <othermaciej> | apparently in the context of Wikipedia, which serves HTML but would like to continue to work with screen-scraping clients that read its content via XMLHttpRequest, but at the same time does not want to stop using HTML named entities |
| 08:20 | <annevk2> | so the scraping clients all use overrideMimeType ? |
| 08:20 | <annevk2> | or does Wikipedia actually serve its contents as XML? |
| 08:20 | <othermaciej> | (conclusion being that <!DOCTYPE html> does not work for them) |
| 08:20 | <othermaciej> | I have no idea, didn't get that far |
| 08:21 | <othermaciej> | it must be either overrideMimeType or they serve conditionally somehow |
| 08:21 | <Hixie> | now i'm even more confused than before |
| 08:21 | <othermaciej> | if every Wikipedia document is well-formed XML then I am truly amazed |
| 08:21 | <annevk2> | XML5 would solve this :) |
| 08:22 | <annevk2> | XHR2 solves it too, though if people use overrideMimeType they're still screwed |
| 08:22 | <othermaciej> | yeah, responseHTML (or whatever) would solve it |
| 08:24 | <annevk2> | it's called responseXML as well |
| 08:24 | <annevk2> | I'm treating responseXML as a misnomer for responseDocument |
| 08:25 | <othermaciej> | fair enough (although that means you can't feature-test for it) |
| 08:25 | <othermaciej> | (which might suck if you want to decide to use overrideMimeType or send different Accept headers based on its presence) |
| 08:26 | <annevk2> | for overrideMimeType it would work |
| 08:26 | <annevk2> | if(this.responseXML == null) { this.overrideMimeType(...) ... } |
| 08:27 | <othermaciej> | so UAs are supposed to respect overrideMimeType even if you set it after the fact? |
| 08:27 | othermaciej | wonders if that actually works |
| 08:27 | <annevk2> | it might not work that way in Firefox |
| 08:27 | <annevk2> | i think it does in WebKit |
| 08:27 | <annevk2> | I think I copied WebKit |
| 08:28 | <othermaciej> | it looks like it would not work in WebKit if you ask for responseXML first |
| 08:28 | <othermaciej> | from code inspection (didn't test) |
| 08:29 | <othermaciej> | when you first ask for responseXML in the DONE state, it sets the createdDocument flag to true, even if it returned null due to a bad MIME type |
| 08:34 | <annevk2> | interesting |
| 08:34 | <annevk2> | XHR2 does not have that flag currently |
| 08:34 | <annevk2> | we can add it I suppose |
| 08:34 | <ment> | hsivonen: btw, i had a discussion with you about entity lookup implementation for html5; i doubt you can do better than this: http://ibawizard.net/~thement/ent/ |
| 08:34 | <annevk2> | though that imposes other requirements... |
| 08:35 | <othermaciej> | well I have no idea if that was a deliberate decision or just an accident of our implementation |
| 08:35 | <ment> | hsivonen: (for example, try ./state "notinx") |
| 08:35 | <othermaciej> | we could just as easily set it only in the case where you create a document, or clear it if overrideMimeType is called, or whatever |
| 08:35 | <annevk2> | kk |
| 08:37 | <hsivonen> | ment: will you have incremental trie lookup in the tokenizer? |
| 08:37 | <hsivonen> | ment: is your tokenizer suspendable after any input character? |
| 08:38 | <ment> | hsivonen: ad incremental trie: i'm thinking about it, but it's not an issue now. |
| 08:39 | <ment> | hsivonen: ad suspendability: my tokenizer seeks in input anyway, so no (but the lookup algorithm is suspendable) |
| 08:46 | <hsivonen> | ment: ok. |
| 08:47 | <hsivonen> | ment: I take it that you aren't designing your tokenizer to be used in an environment that has document.write. |
| 08:50 | <ment> | hsivonen: no, but that could be easily fixed |
| 09:15 | Hixie | accidentally takes his server down |
| 09:15 | <Hixie> | can't blame dreamhost this time |
| 09:16 | <Hixie> | though of course as soon as i do this the tools i need to fix it get flaky |
| 09:24 | <BenGerrissen> | Hey peeps, I can ask questions concerning html5 here right? =P |
| 09:25 | <annevk2> | you can certainly try |
| 09:26 | <BenGerrissen> | I'm currently writing a document about semantic html for our developers and am looking at the W3C specs and fail to spot good semantic guidelines for elements (for example Tables) |
| 09:27 | <BenGerrissen> | Should semantic guidelines be present in the W3C spec for HTML5? |
| 09:28 | <BenGerrissen> | Like in a dictionary, context of a word |
| 09:28 | <annevk2> | what exactly is missing under the definition of the table element? |
| 09:28 | <BenGerrissen> | Usage context |
| 09:29 | <BenGerrissen> | My description of a table for my newbie document is: |
| 09:29 | <BenGerrissen> | Tables are used for tabular data where columns and rows have meaning and more important, each iteration of a column has the same meaning as the next/previous and the same for each iteration of a row. |
| 09:30 | <BenGerrissen> | Was checking specs to see if that description is actually right and am seeing it can still be interpeted for wrong usage |
| 09:30 | <annevk2> | it doesn't seem correct |
| 09:31 | <gsnedders> | jgraham: I'm here now |
| 09:31 | <hsivonen> | on balance, using tables for layout is less bad that authors trying to use non-<table> markup for stuff that should be a table |
| 09:32 | <annevk2> | Hixie, tables seem to have the issue of author content pointing into UA content |
| 09:33 | <annevk2> | Hixie, e.g. the definition of "table" is in an impl-marked section |
| 09:33 | <Hixie> | annevk2: yeah, what should i do about it? |
| 09:34 | <annevk2> | presumably the first part of the processing model be for both authors and implementors |
| 09:34 | <annevk2> | just like writing and parsing html you could have writing and parsing a table |
| 09:34 | <annevk2> | I suppose |
| 09:36 | <Hixie> | file a bug |
| 09:36 | <gsnedders> | Hixie: You need to go back to fixing bugs though :P |
| 09:36 | <Hixie> | next week i'm on vacation |
| 09:36 | <Hixie> | we'll see after that :-) |
| 09:37 | <gsnedders> | Going anywhere nice? |
| 09:37 | <Hixie> | staying at home |
| 09:37 | <Hixie> | just not dealing with all the process BS of standards |
| 09:38 | <annevk2> | nice :) |
| 09:38 | gsnedders | goes back to reading the BS |
| 09:38 | <hsivonen> | Hixie: are you going to be working but without Process? :-) |
| 09:39 | <BenGerrissen> | appologies, just found http://www.w3.org/TR/html4/appendix/notes.html#notes-tables >.< |
| 09:42 | <Hixie> | hsivonen: nah, probably gonna be working on a game |
| 09:42 | <Hixie> | either writing or playing |
| 09:42 | <Hixie> | probably writing |
| 09:43 | <Hixie> | maybe i'll see if i can write a websocket server in pascal for fun |
| 09:43 | <Hixie> | i've never written pascal code on unix |
| 09:43 | <Hixie> | heck i haven't written any pascal in about a decade |
| 09:44 | <hsivonen> | why would you write pascal for fun? |
| 09:45 | <hsivonen> | (sorry if that was offensive. pascal just doesn't strike me as a "for fun" language) |
| 09:45 | <Hixie> | object pascal |
| 09:46 | <Hixie> | not the stuff of olde days |
| 09:46 | hsivonen | is still bitter at textbook authors who used 1-based indeces |
| 09:46 | <Hixie> | pascal in any sane environment is always 0-based |
| 09:48 | <Hixie> | object pascal (the stuff borland used to ship, and now the stuff of the FreePascal project) bears about the same resemblance to the "textbook pascal" as visual basic does to basic |
| 09:49 | <Hixie> | except the starting point is about six orders of magnitude better |
| 09:51 | jgraham | injects the tangentially related fact that many "famous" scientific codes written in C use deliberately 1 based indexing for arrays simply by leaving index 0 empty |
| 09:54 | <ment> | jgraham: that's mostly because many formulas work only with 1-based indexing |
| 09:55 | <ment> | jgraham: (for example, index of parent node in binary heaps stored in array) |
| 09:56 | <annevk2> | so if we get a local sandboxed file system per origin why should localStorage support File too? |
| 09:56 | Philip` | injects the note that Perl lets you dynamically change between 0-based and 1-based and n-based array indexing |
| 09:57 | <annevk2> | Perl sounds awesome |
| 09:57 | <MikeSmith> | gun, meet foot |
| 09:58 | <jgraham> | ment: I have no idea how a formula could only work with 1 based indexing. You just need to subtract 1 to get a zero based index |
| 09:58 | <jgraham> | ment: I was under the impression that people did this because a) fortran uses 1 based indexing |
| 09:58 | <gsnedders> | http://krijnhoetmer.nl/irc-logs/html-wg/20071219#l-609 |
| 09:59 | <jgraham> | and b) most textbooks use 1 based indexing for vectors |
| 09:59 | <Hixie> | Philip`: even the perl documentation says "we don't talk about that" |
| 09:59 | <jgraham> | So the formulae look more familar |
| 09:59 | <gsnedders> | But I guess they're stuck with it for compat |
| 10:01 | <jgraham> | ment: Also I wasn't suggesting that there actually was a HTML5 parser written in Go, only that there could be |
| 10:03 | <jgraham> | (I guess I have no evidence that there isn't except that it seems unlikely; for all I know each google employee was given a party bag when they left work on Friday containing a small black book entitled "How to be evil" and a 5.25" floppy disk containing a conforming HTML5 parser implemented in Go) |
| 10:06 | <ment> | jgraham: i was only pointing out, that the reason for using 1-based indeces is not only matter of habit |
| 10:06 | <hsivonen> | http://www.schleef.org/blog/2009/11/11/theora-on-ti-c64x-dsp-and-omap3/ |
| 10:07 | <ment> | jgraham: 0-based indeces are natural to computer because of pointer arithmetic, but some algorithms for computing positions in array work only with 1-based indeces because of various properties of number one |
| 10:08 | <ment> | jgraham: one example is the heap (you need 3x more arithmetic operation for computing parent with 0-based indeces), i have dozen more examples in combinatorical algorithms textbook |
| 10:24 | <hsivonen> | what's the situation of data: URIs working with XHR? |
| 10:26 | <annevk2> | not same-origin so won't work |
| 10:26 | <hsivonen> | ah. |
| 10:26 | <hsivonen> | thanks |
| 10:26 | <virtuelv> | fairly absurd, though |
| 10:27 | <hsivonen> | yet another case of specs making it harder to write test cases |
| 10:29 | <othermaciej> | data: URIs are surprisingly complex in terms of their security implications |
| 10:29 | <annevk2> | we could make them work |
| 10:29 | <annevk2> | but the idea was rejected iirc |
| 10:29 | <othermaciej> | in XHR? or in general? |
| 10:29 | <annevk2> | in XHR |
| 10:29 | <annevk2> | by also allowing URLs whose scheme is data |
| 10:30 | <othermaciej> | it would be sad (and only really useful for test cases I think) for XHR to be different from the rest of the Web platform on this |
| 10:30 | <virtuelv> | is the situation any different from in canvas? |
| 10:30 | <annevk2> | yes |
| 10:30 | <othermaciej> | I think it might be possible to make data: URIs same-origin with their opener/parent, like about:blank, but then you have to forbid anyone but the opener or parent frame navigating a window to a data: URI |
| 10:30 | <annevk2> | images with data URLs are considered same-origin |
| 10:31 | <annevk2> | (forgot how that worked again in detail) |
| 10:31 | <othermaciej> | or track whether the data: load was initiated by something that is same-origin as the current parent or whatever |
| 10:31 | <annevk2> | I believe we special case data URLs currently in XSLT to allow for easy tests... |
| 10:31 | <annevk2> | though what's next, special casing E4X too? |
| 10:32 | <othermaciej> | in <img> it's clearly not a security hole, though I think that is also true for XHR |
| 10:32 | <othermaciej> | for frames, the security risk if you treat it like about:blank is that an attacker will navigate one of your subframes to an evil data: URI |
| 10:33 | <othermaciej> | there are ways to fix it up, but so far no one has decided data: URIs are useful enough |
| 10:33 | <othermaciej> | javascript: URIs have to be handled the way data: URIs would be sorta |
| 10:33 | <othermaciej> | you can't navigate a frame you don't own to a javascript: URI |
| 10:33 | <annevk2> | yeah, nobody liked handling javascript: for XHR |
| 10:33 | <annevk2> | so I dropped the idea |
| 10:34 | <othermaciej> | I don't think handling data: for XHR would require handling javascript:, I'm just saying if you wanted data: <iframes> to be same-origin with their parent (so you could use it as a replacement for src="about:blank" / document.write or src="javascript:'contents here'") |
| 10:35 | <othermaciej> | then you would have to handle data: sort of the same as javascript: |
| 11:15 | <hsivonen> | gotta love how data: URLs seem so simple but are a can of worms for Same Origin |
| 11:17 | <Philip`> | If someone redesigned the web with no legacy constraints, is there a better security model than Same Origin that they should use? |
| 11:27 | <jgraham> | Philip`: Security people seem to love object capability models these days |
| 11:28 | jgraham | notes he doesn't have the level of understanding needed to have a useful discussion about whether that would actually be better |
| 11:33 | <othermaciej> | "If someone redesigned the web with no legacy constraints" is such a huge hypothetical that you could imagine almost everything |
| 11:33 | <othermaciej> | it does kind of seem like same-origin evolved somewhat accidentally |
| 11:46 | <krisives> | Philip`: Did I show you http://santiance.com/2009/11/better-html-form-cryptography/ ? |
| 11:47 | <krisives> | Philip`: Anything you would like to add about the subject would be excellent |
| 11:49 | <krisives> | My post isn't very good, but it's a start |
| 12:07 | <hsivonen> | is sync xhr supposed to call into the readystate handler? |
| 12:12 | <hsivonen> | hmm. a quick look at the spec suggests that it doesn't |
| 12:19 | <gsnedders> | hsivonen: There was a long discussion on the moz bug about that with anne about what the spec should say, AFAIK that's where most of the discussion was |
| 12:20 | <hsivonen> | gsnedders: was there a conclusion? |
| 12:20 | <gsnedders> | I think so. |
| 12:20 | <hsivonen> | as far as I can tell, Gecko doesn't fire progress events |
| 12:20 | <gsnedders> | That's true, I know that much |
| 12:21 | <hsivonen> | writing test cases that try to be evil shows how little I know about the evil parts of the platform |
| 12:21 | <hsivonen> | I've never used sync XHR for real work, so this all is a surprise to me |
| 12:21 | gsnedders | wonders what the non-evil parts of the platform are |
| 12:25 | <othermaciej> | depends on what you consider evil |
| 12:26 | <othermaciej> | personally I think being the biggest distributed infosystem in the world gives the Web a lot of points in the "good" column |
| 12:26 | <othermaciej> | to the point that it seems petty to nitpick the oddities |
| 12:27 | <jgraham> | good: it works bad: everyone is surprised |
| 12:31 | <Philip`> | krisives: Why do you say SSL is "in shambles"? |
| 12:32 | <hsivonen> | othermaciej: I consider spinning nested event loops evil |
| 12:32 | <Philip`> | krisives: Also, what exactly is "the old technology, which should be deprecated, and eventually removed"? |
| 12:33 | <Philip`> | hsivonen: "to avoid regressing the parsing performance of existing XHTML 1.0 pages" - do you have any data on how much of a difference the number of entities makes? |
| 12:34 | <othermaciej> | hsivonen: seems more stupid than evil to me (though perhaps using it is slightly morally blameworthy) |
| 12:34 | <hsivonen> | Philip`: no data, just guessing |
| 12:34 | <hsivonen> | Philip`: the mathml DTD is larger, so I'd assume it to take longer to parse |
| 12:34 | Philip` | can't imagine it making a significant difference, with a suitable data structure |
| 12:35 | <Philip`> | Hmm, is this in the context of browsers or other XML tools? |
| 12:35 | <hsivonen> | Philip`: I don't mean lookup time. I mean DTD parse time. |
| 12:35 | <hsivonen> | Philip`: in the context of the current Gecko/expat setup |
| 12:35 | <hsivonen> | Philip`: that doesn't do fancy optimizations inside expat |
| 12:35 | <Philip`> | Seems silly to parse an unchanging DTD for every page |
| 12:35 | <hsivonen> | Philip`: but actually parses a bogo-DTD |
| 12:36 | <hsivonen> | Philip`: maybe |
| 12:36 | <othermaciej> | krisives: submitting a salted hash of the password is an interesting idea (though you can do that "by hand" with client-side JS if you really want) |
| 12:36 | <Philip`> | It should be hard-coded or cached or something |
| 12:36 | <hsivonen> | Philip`: hacking expat would be smarter if you believe it is worthwhile to polish the XML code path |
| 12:37 | <krisives> | othermaciej: I think a novel solution could use a composite hash with the salt also containing a hash of the document payload |
| 12:37 | <othermaciej> | krisives: it seems like a fair criticism that over HTTPS, this won't be very effective against the man-in-the-middle attack vector |
| 12:37 | <hsivonen> | Philip`: anyway, the concern applies to any implementation that uses a vanilla XML processor |
| 12:37 | <krisives> | othermaciej: As I tried to stress as much as possible in the article, this is primarily to STOP SENDING PLAINTEXT PASSWORDS |
| 12:38 | <hsivonen> | Philip`: Gecko happens to be such an impl. at the moment |
| 12:38 | <othermaciej> | a password sent over SSL (or really nowadays TLS) is not being sent in plaintext |
| 12:38 | <krisives> | othermaciej: It's plain text is sent, it's obscured, but it's sent |
| 12:38 | <othermaciej> | it's sent encrypted |
| 12:38 | <krisives> | The fact of the matter is that the data is there, when it doesn't need to be |
| 12:39 | <krisives> | Security isn't really a sliding scale, you're either secure or not secure. Sending such information is what opens this vulnerability. |
| 12:40 | <Philip`> | hsivonen: Hmm, I suppose the concern makes sense then |
| 12:40 | <othermaciej> | if the vulnerability is man-in-the-middle attack against SSL (presumably using a "self-signed" cert) then your proposed fix does not fix it |
| 12:40 | <Philip`> | Incidentally, "entity resolver" is a horribly confusing name |
| 12:40 | <Philip`> | I'd expect it to be the thing that resolves character entities |
| 12:40 | <hsivonen> | Philip`: the XML spec uses 'entity' in multiple confusing ways |
| 12:41 | jgraham | suggests that security is exactly a sliding scale |
| 12:41 | <othermaciej> | and yes, security is a sliding scale |
| 12:41 | <hsivonen> | Philip`: your vocabulary has been poisoned by HTML. You need to think in SGML terms. |
| 12:41 | <jgraham> | Like pulling my network cable out would dramatically increase security. But it would have downsides too |
| 12:41 | <krisives> | othermaciej: A MITM attack today will yield your plain-text password if carried out successfully. A MITM attack with this system would at best give you a very local and useless hash |
| 12:41 | <othermaciej> | the binary conception of security may apply to a scenario with a determined attacker with unlimited resources, but in that case you almost certainly will lose |
| 12:41 | <othermaciej> | but most attackers are opportunistic |
| 12:41 | <Philip`> | jgraham: Then you'd be using wireless which is even less secure |
| 12:42 | <othermaciej> | krisives: an MITM attacker against SSL can send you different content, or even a modified version of the supplied content |
| 12:42 | <krisives> | This isn't going anywhere really, and it appears that this discussion continiously gets side tracked as some kind of "end all" to security, usually with HTTPS, SSL, etc. being dragged into the mix. So here is my response: Can anyone tell me a good reason why we are including the plain-text password over the wire when it's not needed? |
| 12:42 | <jgraham> | Philip`: I don't have a wireless capability in this computer |
| 12:43 | <othermaciej> | krisives: your idea might be effective as a defense against passive network listeners finding passowrds in non-SSL traffic (which the user may have also unwisely used ona s ecure site) |
| 12:43 | <Philip`> | jgraham: Oh, okay |
| 12:43 | <krisives> | I'm not really interested in the argument that old technology is what "breaks" the idea |
| 12:43 | <othermaciej> | krisives: if you claim a change defends against a security vulnerability, you can expect people will investigate and possibly question that claim |
| 12:44 | <krisives> | othermaciej: I don't think I made any claims |
| 12:44 | <Philip`> | krisives: Sending plain-text passwords is easier, so there needs to be an adequately compelling reason to do something more complex |
| 12:45 | <othermaciej> | krisives: personally, I get very suspicious of anyone promoting a security idea who gets defensive when you apply analysis |
| 12:45 | <krisives> | Philip`: That's drivel. I'm sorry, but it's not compelling in any way. |
| 12:45 | <Lachy> | krisives, are you concerned about 3rd parties obtaining the plain text password (which SSL protects against), or are you concerned that the site itself, to which an SSL connection is made, can ultimately read the submitted password? |
| 12:46 | <othermaciej> | krisives: is your scheme safe against replay attacks using the hashed password? |
| 12:46 | <krisives> | Firstly, this has nothing to do with SSL. I mearly mentioned it, since we've all put our eggs into a now broken basket. |
| 12:46 | <krisives> | othermaciej: I have no format scheme yet |
| 12:46 | <krisives> | othermaciej: However, yes, it would be tolerant to a replay attack with proper salting and server-side components |
| 12:46 | <othermaciej> | if your threat model is man-in-the-middle attack, then your scheme does not really do anything, regardless of the transport protocol |
| 12:47 | jgraham | still doesn't understand why SSL is being described as "broken" |
| 12:47 | <krisives> | othermaciej: This is to stop the sending of plain-text passwords, not prevent MITM attacks |
| 12:47 | <othermaciej> | if your threat model is passive listener, then I think your scheme could be helpful, if it's made safe against replay attacks |
| 12:47 | <krisives> | jgraham: You can sign your own certs for other authorities? Is this not broken ? |
| 12:47 | <othermaciej> | (but I think not really helpful in the case of SSL, since it doesn't seem vulnerable against passive listeners) |
| 12:48 | <krisives> | Can anyone answer the question of why we're sending the sensitive details to begin with? |
| 12:48 | <othermaciej> | krisives: browsers are starting to take a harder line on rejecting self-signed certs (or at least letting sites opt into stricter security using something like STS) |
| 12:49 | <Philip`> | MD5 is broken but SSL is moving to better hashes |
| 12:49 | <othermaciej> | krisives: you're asking the wrong question - if you propose making a change for security, it's up to you to justify it, and only then is it even relevant for anyone to argue the other side |
| 12:49 | <othermaciej> | Philip`: there are two serious problems with SSL, one a UI issue and one a social/business issue |
| 12:49 | <othermaciej> | 1) when you get certain kinds of bogus certs, the UI in many browsers is just an "OK/Cancel" dialog |
| 12:50 | <krisives> | othermaciej: So, I haven't justified that we shouldn't be sending a password? |
| 12:50 | <krisives> | Let's try it this way: If the password was to NOT be sent, then an attacker would never have it. |
| 12:50 | <othermaciej> | so an attacker that can control your DNS can pose as a valid secure site and the user's only defense is a clickthrough dialog that they won't read |
| 12:51 | <othermaciej> | 2) it's way too easy to get a low-grade cheap SSL cert, and the process of some CAs may not do a good job at preventing people from obtaining valid certs for domains they do not own |
| 12:52 | <jgraham> | krisives: You seem to be saying X is a problem. I assert Y solves X. Then people say how does Y cope with Z, you reply "I already justified that X is a problem" |
| 12:52 | <krisives> | Solve for X, Y, and Z please? |
| 12:52 | <othermaciej> | krisives: encryption is one way to protect a password, a cryptographically strong hash (with a salt and a nonce) is another |
| 12:53 | <jgraham> | krisives: e.g. X == "sending plain text passwords" Y == "your hasing scheme" and Z == "replay attacks" |
| 12:53 | <othermaciej> | krisives: to show that adding cryptographic hashing over an encrypted channel is worthwhile, one would need to propose a threat model where the hashing will defend you even if the encryption fails |
| 12:53 | <krisives> | jgraham: Did you read my posting ? |
| 12:54 | <jgraham> | krisives: No, I'm just following the discussion here |
| 12:54 | <othermaciej> | I don't think it's accurate to describe transmission over an encrypted channel as "sending plain text passwords" |
| 12:54 | <othermaciej> | ciphertext is not plaintext |
| 12:55 | <krisives> | Imagine we need to test a safe way to launch people 30ft into the air and have them land without being harmed. I'm basically saying we should be using a test dummy, while others are saying "Don't worry" we'll just build a strong enough test-suite and they won't be harmed. SSL here being the "strong enough" suite, that we hope won't break and kill our friend plummeting from 30ft. |
| 12:55 | <jgraham> | (It is possible that you do address these issues in the post, or that I have not been understanding the discussion) |
| 12:56 | <othermaciej> | when analyzing the security of a system, the first question should always be, "what's the threat model?" |
| 12:56 | <othermaciej> | once you answer that, you can then meaningfully investigate whether various defenses are likely to be effective |
| 13:03 | <Philip`> | othermaciej: I was assuming krisives was referring to http://www.win.tue.nl/hashclash/rogue-ca/ |
| 13:04 | <othermaciej> | Philip`: that is indeed yet another weakness in SSL |
| 13:05 | <krisives> | Philip`: SSL broken or not doesn't warrant sending my passphrase, IMO |
| 13:31 | <krisives> | Philip`: Thanks for that link, it's awesome |
| 13:56 | <hsivonen> | hmm. is <script src=""> magic like <img src="">? |
| 13:56 | <hsivonen> | or will it just resolve to the doc itself? |
| 13:57 | <gsnedders> | It will just resolve to the doc itself |
| 13:57 | <gsnedders> | (que weird things like zcorpan's HTML/JS file) |
| 13:57 | <hsivonen> | thanks |
| 13:58 | hsivonen | is a bit disoriented trying to grok how Gecko deals with "" vs. absent attribute in this case |
| 13:59 | <AryehGregor> | Hixie, othermaciej, annevk2: I'm talking about text/html that also happens to be well-formed XML. Yes, currently almost every page on Wikipedia is well-formed XML -- there are a few known bugs so this isn't true in corner cases, but it's true very reliably. And yes, XHR uses do overrideMimeType(). |
| 14:00 | <annevk> | I wonder how that works in IE... |
| 14:00 | <annevk> | Or does IE always parse as XML regardless of the media type? |
| 14:02 | <AryehGregor> | It's possible these user scripts don't work in IE. |
| 14:03 | <thedj> | lemme check that. |
| 14:04 | <annevk> | anyway, once XHR2 is more widely deployed they could stop using overrideMimeType and things will work fine |
| 14:04 | <thedj> | nah, IE is not supported (as with most complicated JS tools we use) |
| 14:04 | <annevk> | at least the bit of XHR2 that makes resonseXML work for text/html resources |
| 14:04 | <AryehGregor> | But this is a problem for any XML-parsing tool, I assume. There are others that are implemented in other languages and use those languages' XML libraries to parse the pages. |
| 14:04 | <hsivonen> | annevk: I wonder how many scripts that breaks... |
| 14:05 | <AryehGregor> | One of the goals of our switch to HTML5 was to continue serving well-formed XML so as not to break those tools. |
| 14:05 | <AryehGregor> | Which seems to be harder than I thought, since XML well-formedness is a lot stupider than I thought . . . |
| 14:05 | <hsivonen> | AryehGregor: it's a bit amazing that there's existence proof of someone *actually* using real XML tools with XHTML-as-text/html |
| 14:05 | <annevk> | hsivonen, I don't see how it would break anything |
| 14:05 | <AryehGregor> | hsivonen, well, it's ubiquitous on Wikipedia. |
| 14:06 | <AryehGregor> | Because Wikipedia is reliably well-formed XML. |
| 14:06 | jgraham | wonders why XHTML entities work in Real XML Tools |
| 14:06 | <annevk> | (well, as with all changes I can dream up something theoretical, but nothing quite obvious) |
| 14:06 | <AryehGregor> | jgraham, maybe they don't, and some hack is used which would cause it to not break on <!doctype html> either. I can hope. |
| 14:06 | <hsivonen> | jgraham: Real XML Tools could hit w3.org :-) |
| 14:06 | <annevk> | Yeah, most XML tools would choke on Wikipedia XML |
| 14:07 | <hsivonen> | the only reason why I've parser wikipedia as XML has been benchmarking the HTML parser vs. Xerces |
| 14:07 | <hsivonen> | s/I've parser/I've parsed/ |
| 14:08 | <AryehGregor> | Do most XML tools really refuse to work with named entities even if a proper DTD is given (which Wikipedia does)? |
| 14:09 | <hsivonen> | AryehGregor: no, they work until the w3.org DoS control mechanism blacklists their IP address :-) |
| 14:10 | <jgraham> | (assuming they download the DTD) |
| 14:10 | <jgraham> | (which you would hope they don't by default) |
| 14:10 | <jgraham> | (hope is not always matched by reality though) |
| 14:11 | <hsivonen> | jgraham: hope indeed doesn't match reality here |
| 14:11 | <hsivonen> | for XML awesomeness try this: |
| 14:11 | <hsivonen> | put the entire enterprise behing a single firewall IP to the public Internet |
| 14:11 | <hsivonen> | batch parse XML |
| 14:12 | <hsivonen> | try to get work done that requires reading w3.org in a browser |
| 14:13 | <Philip`> | (Are there specific examples of that being a real problem?) |
| 14:14 | <hsivonen> | Philip`: various JDK/Xerces releases |
| 14:15 | Philip` | means specific examples of enterprises, rather than of parsers |
| 14:19 | jgraham | confirms that lxml dies when parsing http://en.wikipedia.org/wiki/Main_Page |
| 14:19 | <jgraham> | XMLSyntaxError: Entity 'nbsp' not defined, line 390, column 50 |
| 14:23 | <jgraham> | (although I guess there is some way to make it use the DTD) |
| 14:35 | thedj | reading up more about responseXML |
| 14:38 | <MikeSmith> | krijnh: you there? |
| 14:39 | <MikeSmith> | wanted to ask if you can add a new channel to your IRC logger |
| 14:48 | <hsivonen> | does anyone happen to remember if SVG is supposed to treat xlink:href="" the same way as absent attribute? |
| 14:48 | <hsivonen> | (maybe I should locate an SVG channel) |
| 14:48 | <hsivonen> | (or read the spec) |
| 14:50 | <annevk> | unless otherwise indicated "" is a valid reference so should work |
| 14:50 | hsivonen | is trying to find out if SVG indicates otherwise |
| 14:52 | <hsivonen> | grr. the SVG Tiny 1.2 spec crashes my browser |
| 15:13 | <AryehGregor> | MikeSmith, why aren't all new bug reports echoed to public-html subscribers automatically? |
| 15:14 | <jgraham> | AryehGregor: Can't wikipedia convert entities on output |
| 15:14 | <MikeSmith> | AryehGregor: because of the comment box, and people fucking around using that |
| 15:14 | <jgraham> | to real UTF8? |
| 15:14 | <MikeSmith> | the comment box in teh spec I mean |
| 15:14 | <Philip`> | or to &#nnn; |
| 15:15 | <AryehGregor> | jgraham, in real UTF-8 is very confusing. :) Numbered entities are also annoying. |
| 15:15 | <AryehGregor> | Also, it's a lot of code to audit. |
| 15:16 | <jgraham> | The lot of code to audit I can agree with\ |
| 15:16 | gsnedders | wonders how hard it is to make Wikipedia not well-formed XML |
| 15:16 | <AryehGregor> | Sticking with a legacy DOCTYPE seems like am ore sensible solution. |
| 15:16 | gsnedders | doubts it's that hard |
| 15:16 | <jgraham> | But the other issues don't seem like real issues |
| 15:16 | <jgraham> | At least utf-8 is less confusing for non-whitespace characters |
| 15:16 | <AryehGregor> | gsnedders, https://bugzilla.wikimedia.org/show_bug.cgi?id=209 |
| 15:17 | <gsnedders> | AryehGregor: But you still have the issue with XML tools using a legacy DOCTYPE, as if they are validating parsers and check the document for conformance, and you use new HTML 5 stuff |
| 15:17 | <jgraham> | and you could transform whitespace characters to numeric codepoints |
| 15:17 | <jgraham> | s/codepoints/entities/ |
| 15:17 | <jgraham> | and it is only the final output, not something that people typically edit |
| 15:17 | <AryehGregor> | gsnedders, you can get non-well-formed XML fairly trivially if you're an admin, since some messages are still raw HTML. As a user, there are a few known parser bugs that will misnest tags or such in weird circumstances. |
| 15:18 | <AryehGregor> | gsnedders, validation errors aren't necessarily fatal, though. |
| 15:18 | <AryehGregor> | jgraham, maybe, but remember that I have to convince the Wikimedia sysadmins of all this, and they aren't as enthusiastic about HTML5 as I am. |
| 15:19 | <gsnedders> | AryehGregor: Validation errors can be fatal, likewise not having read an external entity and not knowing what is can be fatal. |
| 15:19 | <thedj> | AryehGregor: we could use a request specific doctype.... since we will know most tools that use responseXML, we could easily adapt them to add responseXML=yes to the url request. |
| 15:19 | <AryehGregor> | gsnedders, if a parser dies on encountering an unknown attribute, then we're in a situation where it's either ignore that parser or refuse to add any new HTML features to Wikipedia ever. |
| 15:19 | gsnedders | also thinks PHP in general is not a good language for making sure you are well-formed in |
| 15:20 | <AryehGregor> | gsnedders, s/ for making sure.*$// |
| 15:20 | <gsnedders> | AryehGregor: You could use the HTML 5 DTD, as it should work then :) |
| 15:20 | <gsnedders> | *XML |
| 15:20 | <gsnedders> | (As making sure you don't have characters like U+FFFD isn't fun in PHP) |
| 15:20 | <gsnedders> | *FFFF |
| 15:20 | <AryehGregor> | thedj, that's something of a thought. We could let $wgHtml5/$wgWellFormedXml be overridden on a per-request basis. |
| 15:22 | <gsnedders> | That means double the amount of cached data |
| 15:22 | <thedj> | if used by normal people, but this is used by editors who change pages. |
| 15:22 | <AryehGregor> | Well, a lot of the stuff screen-scrapers want is uncacheable anyway. |
| 15:23 | <thedj> | exactly |
| 15:23 | <AryehGregor> | Either because it's stuff like edit pages, or (as thedj points out) because it's being runned by a logged-in user. |
| 15:23 | <AryehGregor> | But that's something to keep in mind, yeah. |
| 15:23 | <AryehGregor> | I think going with a legacy doctype is the safest way for now. |
| 15:23 | thedj | too |
| 15:23 | <AryehGregor> | Example of malformed XML in MediaWiki: https://bugzilla.wikimedia.org/show_bug.cgi?id=13909 |
| 15:25 | <AryehGregor> | It's actually not that easy. |
| 15:25 | <AryehGregor> | But there are some bugs. |
| 15:32 | <thedj> | anyway, perhaps this "quirk" should at least be mentioned/warned about in the spec ? |
| 15:33 | <gsnedders> | That entities might not work? |
| 15:33 | <AryehGregor> | thedj, I've suggested that XHTML1 Strict should be a second conforming, non-obsolete doctype that authors should only use if necessary. |
| 15:33 | <AryehGregor> | I'll wait for feedback on that before changing MediaWiki's doctype. |
| 15:33 | <gsnedders> | We already have in 10.1 |
| 15:33 | <AryehGregor> | (again) |
| 15:33 | <gsnedders> | 'According to the XML specification, XML processors are not guaranteed to process the external DTD subset referenced in the DOCTYPE. This means, for example, that using entity references for characters in XHTML documents is unsafe if they are defined in an external file (except for <, >, &, " and ').' |
| 15:34 | <thedj> | gsnedders: perhaps add a note about XHR1 +responseXML there ? |
| 15:34 | <gsnedders> | There's nothing special about that case |
| 15:35 | <gsnedders> | It's no different to the normal case |
| 15:36 | <hsivonen> | thedj: on the list there were opinions against documenting the entity reality in the HTML5 spec itself |
| 15:36 | <hsivonen> | (the list being public-html in this case, not the whatwg list) |
| 15:39 | <AryehGregor> | hsivonen, that was for the XML MIME type case, though, right? |
| 15:40 | <hsivonen> | AryehGregor: for XML parsing case |
| 15:40 | <hsivonen> | AryehGregor: which is what this XHR issue is about |
| 15:40 | <hsivonen> | it's the same magic list |
| 15:41 | <AryehGregor> | I seriously hate XML. |
| 15:42 | <thedj> | hehe |
| 15:43 | gsnedders | notes html5lib has a module called ihatexml |
| 15:43 | <gsnedders> | Also, html5lib has bugs caused by not using that module enough |
| 15:43 | <jgraham> | And caused by that module being wrong |
| 15:43 | <jgraham> | hence the name |
| 15:51 | <Philip`> | AryehGregor: "a lot of code" - just stick a nice simple HTML-tidying proxy in front of all the servers and then you won't have much to change :-) |
| 15:51 | <AryehGregor> | Philip`, we do run HTML Tidy, actually. |
| 15:51 | <AryehGregor> | It would be possible, I guess. |
| 15:52 | <thedj> | grah, no HTML tidy. |
| 15:52 | <AryehGregor> | Assuming there are no *other* XML well-formedness gotchas around? |
| 15:52 | <thedj> | i messes with whitespace |
| 15:52 | <hsivonen> | performance FTW! |
| 15:53 | <Philip`> | By "HTML-tidying" I don't mean actually HTML Tidy, just something that tidies HTML |
| 15:53 | <Philip`> | like an HTML5 parser + an HTML5 serialiser configured to not emit named entities |
| 15:53 | <Philip`> | (and to emit XML-compatible slashes and whatever) |
| 15:53 | <hsivonen> | Philip`: itym an (X)HTML5 polyglot serializer |
| 15:54 | <Philip`> | hsivonen: I wouldn't use the term "polyglot" since that suggests impossible things |
| 15:54 | <Philip`> | (since it can't produce identical DOMs when the input contains stuff like <pre>) |
| 15:55 | <hsivonen> | Philip`: sure it can as long as it zaps leading LFs |
| 15:55 | <Philip`> | It just needs to be a serialiser that emits well-formed XML that is also valid HTML5 |
| 15:55 | <hsivonen> | server-side dataloss FTW! |
| 15:55 | <Philip`> | hsivonen: Well, okay, and it could also just return an empty document regardless of the input :-p |
| 15:55 | Philip` | was assuming no dataloss when the output is parsed as HTML5 |
| 15:56 | <Philip`> | s/also valid HTML5/also identical to the input when parsed as HTML5/ |
| 16:00 | <AryehGregor> | thedj, do you know of any non-JS-based frameworks that use XML parsers? |
| 16:00 | <AryehGregor> | Do they actually work with named entities, and if so, how? |
| 16:00 | <thedj> | i have no idea. |
| 16:00 | <thedj> | AzaToth might know. |
| 16:01 | <gsnedders> | So if I want to get the spec changed nowadays do I need a full change proposal? |
| 16:01 | <AryehGregor> | gsnedders, only if the editor disagrees with you. |
| 16:01 | <gsnedders> | Hixie: You shall never disagree with me. |
| 16:03 | <AryehGregor> | thedj, where does he usually hang out? |
| 16:03 | <thedj> | uses nick AzaTht today it seems |
| 16:11 | <Philip`> | "[Genx] doesn't barf when you try to write out an element and pass NULL as the name" - actually it's passing ":" as the name, and NULL as the namespace (which is the proper way of saying no namespace) |
| 16:11 | <Philip`> | but I'm not going to bother posting to public-html just to say that |
| 16:13 | jgraham | just bothered posting to point out he wasn't saying "don't use a library" |
| 16:13 | <erlehmann> | gsnedders, any chance theres going to be a public html5lib serializer service where you can try out things? or is hixies dom viewer that already for every reasonable purpose ? |
| 16:14 | <jgraham> | erlehmann: Already exists |
| 16:14 | <erlehmann> | jgraham, where ? |
| 16:14 | <AryehGregor> | You were saying "don't use XML because it's fragile even with a library". :) |
| 16:15 | <erlehmann> | i use XML, you insensitive clod. but gsnedders is right, my blog breaks when someone searches for U+FFFF |
| 16:15 | <jgraham> | There are a couple based on the validator.nu parser and one (possibly broken) based on a (very old version of) html5lib |
| 16:15 | <erlehmann> | wordpress is so ugly. maybe i should really try out habari next. |
| 16:15 | <Philip`> | erlehmann: What if someone writes U+FFFF in a comment? |
| 16:16 | <erlehmann> | i'll try that |
| 16:16 | <Philip`> | Libraries that fatally abort instead of outputting ill-formed content aren't any less fragile than print()ing content, because they just shift the error from client-side to server-side |
| 16:17 | <jgraham> | Philip`: In theory you can deal with that somehow |
| 16:18 | <Philip`> | You could use libraries that automatically clean the input (delete invalid characters etc) instead |
| 16:19 | <Philip`> | Then it's extremely unlikely you'll encounter fatal errors |
| 16:19 | <Philip`> | (since bugs are rare) |
| 16:20 | <AryehGregor> | On the other hand, why not just do that on the client side? |
| 16:20 | <AryehGregor> | Like, you know, HTML5 does? |
| 16:20 | TabAtkins | just realized that he duplicated a helper array independently less than a screen-height from each other. |
| 16:20 | <Philip`> | so fragility doesn't seem like a practical argument against that; a better argument is that few people can be bothered to use such libraries, because print() is far easier |
| 16:20 | <zcorpan> | you could reject any comment that is not "LOL", which makes sure it'll be well-formed |
| 16:21 | <Philip`> | (and you can avoid fragility of print() by putting error-correction on the client) |
| 16:21 | <TabAtkins> | That has the nice side effect of guaranteeing the quality of your comments. |
| 16:22 | <TabAtkins> | And eliminating spam! |
| 16:24 | <jgraham> | Have I horribly misunderstood something or would XML5 mainly be targetted at the web? |
| 16:24 | <jgraham> | and not pitched as a replacement for all possible uses of XML? |
| 16:25 | <Lachy> | re the XHTML character entity thread, is the proposal just to support entities for known legacy XHTML DOCTYPEs (like XHTML 1.0, etc), but XHTML5 with no DOCTYPE or <!DOCTYPE html> will continue not supporting them? |
| 16:25 | <TabAtkins> | My understanding aligns with yours. |
| 16:25 | <MikeSmith> | jgraham: it's targeted toward financial-transaction systems mainly |
| 16:26 | <TabAtkins> | And I'm not sure why Cowan is talking at all if he doesn't have an opinion about web-based languages. |
| 16:26 | <MikeSmith> | jgraham: and for nuclear-weapons targeting systems |
| 16:26 | <Lachy> | some of the replies I've read seem to be confused about that point, and seem to be making arguments against supporting them in XHTML5, which I hope isn't the case anyway. |
| 16:26 | <AryehGregor> | Lachy, that's what I understood too. |
| 16:26 | <jgraham> | MikeSmith: heh |
| 16:26 | <AryehGregor> | jgraham, I don't why XML5 shouldn't be a general XML replacement. |
| 16:26 | <AryehGregor> | XML brittleness can't be a problem only on the web. |
| 16:27 | <TabAtkins> | To be fair, I like draconian-ness in things that I have direct control over. |
| 16:27 | <Philip`> | When you call it "XML5", it shouldn't be surprising if people think you're trying to replace all XML |
| 16:29 | <erlehmann> | AryehGregor, you obviously a verb |
| 16:30 | <MikeSmith> | maybe it should be called fuXML |
| 16:30 | <erlehmann> | 5 is the magic number :) html5, url5, xml5 — what about safari 5 ? |
| 16:30 | <TabAtkins> | erlehmann: ?_? There's no verb missing. |
| 16:30 | <Lachy> | XML5 should be completely backwards compatible with XML 1.0 (not sure about 1.1), so there's no reason it shouldn't simply replace it |
| 16:30 | <Philip`> | TabAtkins: Yes there is - AryehGregor said he didn't why |
| 16:30 | <AryehGregor> | erlehmann, well, we should have Chrome 5 within two weeks or so at the current rate. |
| 16:31 | <TabAtkins> | ... Wow that flew past me. |
| 16:31 | <AryehGregor> | Philip`, I would look up "why" in the OED and try to find a verb meaning for it, but I really can't be bothered. |
| 16:31 | <Philip`> | Chrome will have to slow down version increments else they'll hit double digits and break UA sniffing |
| 16:31 | <erlehmann> | AryehGregor, chrome is weirding me out on so many levels o.0 |
| 16:31 | <MikeSmith> | Lachy: you're clearly not thinking about the dangers carefully -- the malformed telegrams that result in financial ruin for rail barons, etc. |
| 16:32 | <Philip`> | AryehGregor: The OED says "why, adv. (n., int.)" |
| 16:32 | <erlehmann> | Philip`, break it? you've seen their version string. nothing to break, all broken. |
| 16:32 | <Philip`> | so it doesn't include any verbish meanings |
| 16:32 | <annevk> | it's also compatible with XML 1.1 afaict |
| 16:32 | <AryehGregor> | Philip`, aw. |
| 16:34 | <Philip`> | http://www.layer7tech.com/main/products/xml-firewall.html - you can get whole boxes that protect against XML parsing attacks |
| 16:35 | <Philip`> | Not sure how that's relevant to the discussion but never mind |
| 16:35 | <Philip`> | (Maybe http://www.f5.com/glossary/xml-firewall.html is a better link) |
| 16:36 | <Lachy> | MikeSmith, XML5 processors should still be able to abort on fatal errors if they choose, just like HTML5 allows in some cases. The difference is that if they choose to recover, the recovery procedure should be defined |
| 16:36 | <Philip`> | Maybe the relevance is that changing XML across the entire world is hard |
| 16:36 | <Lachy> | so rail barons relying on well formed telegrams can still abort |
| 16:36 | <AryehGregor> | Lachy, the difference is that they should be allowed to recover period; and on top of that, the recovery procedure should be well-defined. |
| 16:37 | <MikeSmith> | "WSDL poisoning" |
| 16:37 | <AryehGregor> | Right now they're forbidden from recovering. |
| 16:37 | <Lachy> | AryehGregor, right. that's effectively what I said. |
| 16:38 | <AryehGregor> | Speaking of which, by total coincidence (not?) I received an error report in another chat today: https://jira.toolserver.org/plugins/servlet/streams?key=10301&os_authType=basic&maxResults=10 |
| 16:38 | <AryehGregor> | Three cheers for XML! Hurrah, hurrah, hurrah! |
| 16:38 | <TabAtkins> | That's behind an authent wall. |
| 16:38 | <Lachy> | AryehGregor, what's the password? |
| 16:39 | <Philip`> | What's the username? |
| 16:39 | <AryehGregor> | Oh, there's a password? |
| 16:39 | <AryehGregor> | Oh well. |
| 16:39 | <AryehGregor> | "Error occured getting activity: The data "<p>Here is the public key.</p><div class="thunmbnails"><a href="https://jira.toolserver.org/secure/attachment/10823/%1B%5BA.pub" >[A.pub</a></div>" is not legal for a JDOM character content: 0x1b is not a legal XML character." |
| 16:39 | <Philip`> | https://jira.toolserver.org/plugins/servlet/streams?key=10301&maxResults=10 |
| 16:39 | <annevk> | I think certain classes of products should be required to recover |
| 16:40 | <Philip`> | That's surprisingly easy authentication to sidestep |
| 16:40 | <annevk> | though I suppose you can leave that up to market forces |
| 16:40 | <TabAtkins> | Philip`: Hahahahahaha |
| 16:41 | <AryehGregor> | Philip`, that's pretty sad. |
| 16:41 | <MikeSmith> | I think I need to get my a piece of this XML Firewall business.. maybe we can sell fuXML/XML5 to the XML business community as something that provides new business opportunities -- they can provide new types of XML Firewalls that prevent XML non-well-formedness attacks |
| 16:42 | <MikeSmith> | their is a pot of gold waiting under the rainbow of every new poorly designed technology |
| 16:44 | Philip` | wonders what fuXML is |
| 16:44 | <Philip`> | http://www.fuxml.de/index.php?option=com_content&task=view&id=3 - Ubiquitous Learning ! |
| 16:44 | <TabAtkins> | MikeSmith's name suggestion for "the good bits of XML". |
| 16:45 | <MikeSmith> | damn, somebody beat me to the fuxml domain name |
| 16:45 | MikeSmith | tries effyouXML |
| 16:46 | <gsnedders> | Oh MikeSmith... |
| 16:46 | <annevk> | I like it |
| 16:46 | <gsnedders> | Still, I own thereshouldbenored.com, so I win :P |
| 16:47 | <annevk> | i think that site ought to host the picture of the toilet at the engineering seminar |
| 16:47 | <TabAtkins> | The Re Should Be Nored. |
| 16:47 | <TabAtkins> | ^-- my first reading of the domain name. |
| 16:47 | <annevk> | you're obviously not in QA |
| 16:47 | <Philip`> | gsnedders: You should be more optimistic, and call it thereisnored.com |
| 16:47 | <Philip`> | which can also be misread interestingly |
| 16:47 | <AryehGregor> | gsnedders, Chrome won't let me input U+FFFF into the search box. :( |
| 16:48 | gsnedders | notes the phrase "thre should be no red" has been said in this room around ten times today |
| 16:48 | <gsnedders> | AryehGregor: Then type something else in and change the query string to contain %EF%BF%BF |
| 16:48 | <Dashiva> | What's the accessible version of no red? |
| 16:48 | <gsnedders> | AryehGregor: Then send someone a link to that URI. |
| 16:48 | <Lachy> | does that test pass about 1 out of every 100 times? |
| 16:48 | <gsnedders> | Lachy: Yes. |
| 16:49 | <AryehGregor> | gsnedders, when I try that in Chrome, the URL bar becomes empty. :D |
| 16:49 | <gsnedders> | (given a perfect distribution over the range) |
| 16:49 | <annevk> | I was just about to say, some poor QA dude that made that site |
| 16:49 | <AryehGregor> | But it looks like Wikipedia can also be made non-well-formed that way. |
| 16:49 | <gsnedders> | annevk: Why? Because it fails so often? |
| 16:50 | <Lachy> | yay, I got green once |
| 16:51 | gsnedders | has never actually seen it green |
| 16:51 | <Philip`> | javascript:s='';for(i=0;i<100;++i)s+='<iframe src=http://thereshouldbenored.com/ width=20 height=20></iframe>';s |
| 16:52 | <Lachy> | clearly, the test is meant to ensure that the Math.rand() function is written like this: |
| 16:52 | <Lachy> | function rand() { |
| 16:52 | <Lachy> | return 0.42; |
| 16:52 | <Lachy> | } |
| 16:53 | <Dashiva> | It could be 0.4201 too |
| 16:53 | <Philip`> | With 1000 iframes, 6 were green |
| 16:53 | <Dashiva> | Silly Philip |
| 16:53 | <Lachy> | sure, the decimals after the 3rd decimal place are irrelevant |
| 16:54 | <Dashiva> | No |
| 16:54 | <gsnedders> | I've seen it green! |
| 16:54 | <Dashiva> | It also applies to 3rd place |
| 16:54 | <Dashiva> | Since 0.421 passes, but 0.428 doesn't |
| 16:54 | <Lachy> | so 0.4248908 should work too. But 0.425 would fail |
| 16:55 | <Lachy> | Dashiva, right. I did say after the 3rd, not from the 3rd. |
| 16:56 | <Dashiva> | Yes, and sine 3rd place matters your definition of the test is invalid :) |
| 16:56 | <Dashiva> | *since |
| 16:56 | <Lachy> | or the test could be faulty, and should instead use Math.floor() |
| 16:56 | <gsnedders> | Hence Lachy is a fail. |
| 16:56 | Philip` | wonders why Gmail thinks gsnedders' latest email is spam |
| 16:56 | <gsnedders> | Philip`: Because it contained <script>? |
| 16:57 | <Dashiva> | http://dashiva.net/test/nored.html |
| 16:57 | <Dashiva> | For your testing pleasure |
| 16:58 | <Lachy> | Dashiva, I seem to be getting green about 4 times each reload |
| 16:58 | <Dashiva> | Yeah, I've getting low valuestoo |
| 16:58 | gsnedders | watches as the bandwidth on his VPS shoots up |
| 16:58 | <Lachy> | oh, I got a 5! |
| 16:58 | <Dashiva> | Clearly the random function is broken |
| 16:58 | gsnedders | watches as his irssi connection slows down |
| 16:59 | <Dashiva> | It isn't giving 0.42 nearly often enough |
| 16:59 | <Lachy> | I wonder how long it would take for someone to get all 100 squares green, and whether or not that is actually possible given the pseudo-random number generators in browsers |
| 17:00 | <Lachy> | oh, 400 squares |
| 17:00 | <Lachy> | that explains why I'm averaging about 4 green squares |
| 17:00 | <Lachy> | oh, I got 7 :-) |
| 17:00 | <Dashiva> | Eh? |
| 17:01 | <Dashiva> | It's supposed to be 400 green squares |
| 17:01 | <Dashiva> | Says so in the test URL! |
| 17:02 | <Philip`> | No it doesn't |
| 17:02 | <Philip`> | There's lots of colours that are not red |
| 17:03 | <Philip`> | For example, blue |
| 17:03 | <gsnedders> | It's just not as cool as green |
| 17:04 | <Lachy> | Dashiva, write a script that randomly sets one of the squares to blue after they've all loaded |
| 17:05 | <Lachy> | (or just load bikeshed.com in one of the frames) |
| 17:05 | <Dashiva> | Should green be CSS gree or CSS lime? Discuss |
| 17:06 | <Dashiva> | (Also, why can't I spell anymore) |
| 17:06 | <gsnedders> | "anymore"? |
| 17:06 | <Lachy> | technically, the CSS 'lime' value is green, and 'green' is a darker green |
| 17:07 | <Lachy> | so it should use 'lime' |
| 17:09 | <Philip`> | ""Everything's shiny, Cap'n. Not to fret!" Unfortunately, you'll need to refresh. Wanna tell Dr. Wave what happened?" |
| 17:09 | <Philip`> | Hmm, the Wave web client doesn't like me putting funny characters into messages |