| 00:09 | <Hixie> | many shows in the uk get broadcast twice, once with and once without the sign interpreter |
| 00:09 | <Hixie> | including, e.g., cartoons |
| 00:22 | <Hixie> | hsivonen: how do i distinguish RDF from MathML and SVG in a generic sense? |
| 00:23 | <Hixie> | as in, "elements that are from non-XHTML namespaces and whose semantics define metadata" might describe RDF |
| 00:23 | <Hixie> | but i can't see how to describe MathML/SVG |
| 00:28 | <othermaciej> | what is the purpose of the distinction? |
| 00:34 | <Hixie> | i want to allow rdf anywhere metadata is allowed |
| 00:34 | <Hixie> | and want to allow svg anywhere prose content is allowed |
| 00:35 | <Hixie> | (without calling them out by name, since i don't want to close teh set of namespaces allowed) |
| 00:37 | <Hixie> | 25 points to anyone who finds a reason why we can't allow <ol>, <div>, <ul>, <p>, etc, in <address> |
| 00:39 | <othermaciej> | "elements ... whose semantics define metadata" and "elements ... whose semantics define content" maybe? |
| 00:39 | <othermaciej> | that's pretty vague |
| 00:39 | <Hixie> | that's what i have but i argued with myself that metadata is a kind of content |
| 00:40 | <othermaciej> | what isn't a kind of content? |
| 00:41 | <othermaciej> | (you could also ask, what isn't a kind of metadata?) |
| 00:41 | <Hixie> | yeah |
| 00:41 | <Hixie> | that's my problem |
| 00:42 | <webben> | Philip`: Do you have a link for that? The impression I got was that you'd get a choice of non-interpreted vs interpreted. |
| 00:43 | <Hixie> | while i'm boiling the oceans over here getting rid of hte block vs inline distinction, maybe i should make <body> optional too... http://www.glazman.org/weblog/dotclear/index.php?post/2005/05/27/1055-adam-2 |
| 00:43 | <Hixie> | (see the paragraph starting "Steven Pemberton") |
| 00:44 | <Philip`> | webben: http://www.bbc.co.uk/iplayer/page/item/b008d36h.shtml is one (linked from the front page, with no link to an alternative version that I can see) |
| 00:44 | <webben> | ta |
| 00:44 | <othermaciej> | Hixie: isn't <body> already optional? |
| 00:44 | <Philip`> | (It's quite probable that the Windows downloadable version has more options than the Flash streaming one) |
| 00:45 | <Hixie> | othermaciej: not in the dom, only in the html serialisation |
| 00:45 | <othermaciej> | ah |
| 01:03 | <Hixie> | as part of the liberation of html elements, i'm allowing <style scoped> virtually anywhere |
| 01:03 | <Hixie> | let me know if you think <style scoped> should be a little more oppressed |
| 01:07 | <othermaciej> | where was it previously not allowed? |
| 01:09 | <Hixie> | only in section, nav, div, and article |
| 01:09 | <Hixie> | (i'm still requiring that it be at the top of its parent) |
| 02:29 | <deltab> | om_afk: in SGML terms at least, the body element is mandatory but its tags are optional |
| 02:30 | <deltab> | likewise html, head, and tbody |
| 02:34 | <Hixie> | hsivonen is going to have a field day when this is done |
| 02:34 | <Hixie> | there are so many subtle changes |
| 02:35 | <Philip`> | Only one field day? That doesn't sound too bad |
| 02:35 | <Hixie> | hsivonen is good |
| 02:35 | <Hixie> | :-P |
| 09:34 | <Hixie> | my edits are making the heading association algorithm even harder to understand |
| 09:35 | <Hixie> | so i'll definitely have to rewrite it at some point |
| 10:58 | <Hixie> | good lord <ins> is going to make my head explode |
| 10:59 | <Hixie> | it just totally screwed up my entire carefully designed content model |
| 10:59 | <Hemebond> | Why? |
| 10:59 | <Hemebond> | You working on HTML5? |
| 10:59 | <Hixie> | yeah |
| 10:59 | <Philip`> | Replace it by an attribute, so you can have <p ins> and <b ins> and <blockquote ins> and whatever, which won't affect the content model |
| 11:00 | <othermaciej> | the XHTML2 solution! |
| 11:00 | <Hixie> | <article> <ins> <em> hello </em> </ins> <ins> world </ins> of pain <ins> <p> how are you </p> </ins> </article> |
| 11:00 | <Hixie> | that has to become 2 paragraphs |
| 11:00 | <Hixie> | but it is legal |
| 11:01 | <Hixie> | and <article> <em> hello <ins> world </ins> </em> </article> is legal too |
| 11:01 | <Hemebond> | ins is block? |
| 11:01 | <Hixie> | it's... something |
| 11:01 | <Philip`> | It's not like people do much processing of <ins> today, so it wouldn't hurt much to change it |
| 11:01 | <Hemebond> | Old INS was only inline, right? |
| 11:02 | <Hixie> | <ins> was neither inline nor block in html4 |
| 11:02 | <Hixie> | it was an sgml inclusion |
| 11:03 | <Hemebond> | *boggle* |
| 11:03 | <Lachy> | Hixie, I thought this issue was solved using transparent content models, and that your first example wouldn't be legal |
| 11:16 | <Hixie> | what's wrong with the first example? |
| 11:17 | <Hixie> | the transparent content models don't really help determine where <ins> is allowed in the first place, only what's allowed inside it |
| 11:17 | <Lachy> | Hixie, because <article> <em></em> <p></p> </article> isn't allowed |
| 11:18 | <Hixie> | it is in the new model |
| 11:19 | <Lachy> | why? |
| 11:19 | <Hixie> | we're removing the requirement that <p> be required around paragraphs |
| 11:19 | <Hixie> | apparently it was causing too much confusion |
| 11:19 | <Lachy> | who was confused by it? |
| 11:19 | <Hixie> | sam ruby, e.g. |
| 11:20 | <Lachy> | oh, he's confused by a lot of things, and I generally disagree with him |
| 11:20 | <Hixie> | heh |
| 11:20 | <Hixie> | he wasn't the only one |
| 11:21 | <Hixie> | basically paragraphs are implied much like sections get implied |
| 11:21 | <Hixie> | at least, that's the model i'm writing up |
| 11:21 | <Hixie> | who knows if we'll keep it |
| 11:22 | <Lachy> | but that makes it possible to do things like this: <div><p>foo</p> bar <p>baz</p></div> and it represents 3 paragraphs. |
| 11:23 | <Lachy> | I really don't like that model |
| 11:23 | <Hemebond> | Ugh |
| 11:23 | <Hixie> | me either, but it's hard to find a good argument for why that's not ok |
| 11:23 | <Hixie> | (and note that html4 strict allows it) |
| 11:23 | <Lachy> | where are the arguments that it is ok? |
| 11:23 | <Hixie> | (so a lot of people will hit that when transitioning to html5) |
| 11:24 | <Hemebond> | Allows what? Dropping of tags? |
| 11:24 | <Hixie> | Lachy: it doesn't cause anyone any harm, and it's unambiguous |
| 11:24 | <Hixie> | Hemebond: allows mixing inline and block content in <div> elements |
| 11:25 | <Hemebond> | Ah, right. |
| 11:26 | <Hemebond> | Hixie: Are you the BDFL for WHATWG? |
| 11:27 | <Hixie> | pretty much |
| 11:27 | <Hemebond> | The intawebs just told me so. |
| 11:27 | <Hixie> | (except maybe for the "FL" part) |
| 11:27 | <Hixie> | Lachy: see, kinda hard to come up with a good counter argument |
| 11:28 | <Lachy> | Hixie, not hard, just busy with other stuff right now. |
| 11:29 | <Hixie> | well, if you can find an argument, do let me know, because i couldn't, and that backed me into the corner of allowing it. |
| 11:30 | <Hixie> | and i don't like it |
| 11:33 | <Lachy> | can you point me to Sam's arguments? |
| 11:37 | <Hixie> | he didn't really argue for anything as i recall |
| 11:37 | <Hixie> | but see the dogfood thread in public-html, e.g. |
| 11:38 | <Hixie> | wow i'm really confused about how to do <ins> and <del> with the implied paragraph stuff |
| 11:38 | <Hixie> | i'd better sleep and work on this tomorro |
| 11:38 | <Hixie> | nn |
| 11:42 | <Camaban> | what the... so hang on, if <p> isn't required, does that mean whitespace in HTML is going to become something to think about? (aside from a couple of browser bugs) |
| 11:44 | <Lachy> | Camaban, no |
| 11:44 | <Camaban> | presume I'm missing something, I'll go look it up |
| 11:45 | <Hemebond> | What makes it an implied <P>? |
| 11:45 | <Lachy> | Camaban, white space can't become significant because it would seriously break compatibility |
| 11:45 | <OmegaJunior> | It already does... browser bug in MSIE |
| 11:46 | <Hemebond> | And isn't whitespace kept in Mozilla too? |
| 11:46 | <Camaban> | Lachy: that's what I'm thinking, but if <div><p>foo</p> bar <p>baz</p></div> represents 3 paragraphs, then it looks like whitespace would be significant |
| 11:46 | <Hemebond> | Between parent and child elements? |
| 11:46 | <OmegaJunior> | It shouldn't... |
| 11:47 | <Lachy> | Hemebond, <p> will never be implied directly. But rather, the concept of an implied paragraph is a little more abstract |
| 11:47 | <Hemebond> | I believe (maybe they fixed it) if you iterated through the children of an <OL>, you'd pick up the whitespace/line-returns too. |
| 11:47 | <Lachy> | Camaban, even if you took out the whitepace in that example, it would still represent 3 paragraphs in the new model |
| 11:47 | <OmegaJunior> | Yes, Hemebond, that is normal |
| 11:47 | <Hemebond> | Lachy: So it isn't marked up with anything except the DIV? |
| 11:47 | <OmegaJunior> | But it shouldn't be displayed by the browser |
| 11:48 | <Hemebond> | OmegaJunior: But.... why is there whitespace between elements where there shouldn't be any other child elements? |
| 11:48 | <Hemebond> | <OL> can only have <LI> as a child element, no? |
| 11:48 | <Camaban> | ok, so how would soemthing like http://pastebin.com/d367d5a2c be interpreted? as 1 paragraph, or 2? |
| 11:48 | <OmegaJunior> | Hemebond: because the source contains new-line or carriage-return? |
| 11:48 | <OmegaJunior> | That counts as whitespace, too. |
| 11:49 | <Hemebond> | OmegaJunior: I'm talking about the DOM though. |
| 11:49 | <OmegaJunior> | Yes |
| 11:49 | <Lachy> | the whitespace will still be present in the DOM, but as far as semantics are concerned, it's very much irrelevant |
| 11:49 | <Lachy> | I gotta go |
| 11:49 | <OmegaJunior> | The DOM sees spaces, carriage returns, new-lines, tabs, etc. as white-space text nodes |
| 11:49 | <OmegaJunior> | unless they're already inside a text |
| 11:50 | <Hemebond> | OmegaJunior: I know. |
| 11:50 | <Philip`> | "Inter-element whitespace, comment nodes, and processing instruction nodes must be ignored when establishing whether an element matches its content model or not, and must be ignored when following algorithms that define document and element semantics." |
| 11:50 | <Philip`> | (says HTML5) |
| 11:50 | <OmegaJunior> | Excellent |
| 11:50 | <OmegaJunior> | Let's hope the browser vendors will implement it |
| 11:51 | <othermaciej> | that's not a requirement for browsers |
| 11:51 | <OmegaJunior> | How so? |
| 11:51 | <Philip`> | so they're in the DOM, and included in DOM childNodes and stuff, but are not relevant for conformance or for HTML5-defined algorithms (e.g. to find the list items in a list) |
| 11:51 | <othermaciej> | that rule applies to documents and validators |
| 11:52 | <Philip`> | othermaciej: The "must be ignored when following algorithms ..." sounds like browser conformance |
| 11:52 | <othermaciej> | "when following algorithms that define document and element semantics" |
| 11:52 | <OmegaJunior> | othermaciej: it applies to documents and validators but not to browsers? That seems contradictory. |
| 11:52 | <Philip`> | at least to the extent that browsers run those algorithms |
| 11:52 | <othermaciej> | in particular it wouldn't apply to the parsing algorithm, as written |
| 11:52 | <Philip`> | (which should be a non-zero extent, I guess) |
| 11:52 | <othermaciej> | since that does not define document or element semantics |
| 11:53 | <OmegaJunior> | No... but it interprets it... |
| 11:53 | <Hemebond> | The DOM isn't the document? |
| 11:53 | <OmegaJunior> | No, just a model of it |
| 11:53 | <Hemebond> | Which the browser uses to build the document. |
| 11:54 | <othermaciej> | I don't know what algorithms are considered to define document and element semantics and which browsers must follow |
| 11:54 | <othermaciej> | off hand |
| 11:54 | <othermaciej> | but I don't think the quote from Philip` is primarily aimed at browser algorithms that would be relevant here, thus, "let's hope browser vendors will implement it" is not really a proper response |
| 11:55 | <OmegaJunior> | I disagree |
| 11:55 | Philip` | agrees with othermaciej :-) |
| 11:55 | <othermaciej> | it's true that <div><p>foo</p> <p>bar</p></div> should generate a text node in the DOM for the space, but not render it |
| 11:56 | <OmegaJunior> | What good does it do, to describe how whitespace should be handled, if that description doesn't apply to how a browser should handle whitespace while parsing and displaying a document? |
| 11:56 | <othermaciej> | but the reasons are the HTML5 parsing algorithm and CSS whitespace collapsing rules |
| 11:56 | <othermaciej> | there are descriptions of how whitespace should be handled while parsing and displaying a document |
| 11:56 | <othermaciej> | for parsing, that is the parsing algorithm |
| 11:57 | <othermaciej> | for display, it is CSS (mainly whitespace collapsing, possibly some other stuff) |
| 11:57 | <Hemebond> | the parsing alg is different to the alg for generating a DOM? |
| 11:57 | <Philip`> | The parsing algorithm is what generates the DOM |
| 11:57 | <OmegaJunior> | othermaciej, And as everyone will understand, the parsing algorythem is developed without any contact with the rest of the HTML5 spec. |
| 11:57 | <OmegaJunior> | Difficult word, algorythm |
| 11:57 | <othermaciej> | the HTML5 parsing algorithm describes how to take a text/html document and generate a DOM (with various possible side effects along the way) |
| 11:58 | <Hemebond> | This is confusing. And messy. |
| 11:58 | <OmegaJunior> | So how whitespace should be handled in a document has no bearing on how a parser should handle whitespace in a document? |
| 11:58 | <OmegaJunior> | Hemebond: I agree |
| 11:59 | <Hemebond> | I think I'll go learn XHTML2. |
| 11:59 | <Philip`> | If you have <div><p>foo</p> <p>bar</p></div> in XHTML, you get a text node between the two 'p' nodes, exactly the same as in HTML |
| 12:00 | <Philip`> | (in terms of the DOM, which the document gets parsed into) |
| 12:00 | <OmegaJunior> | Yes, I'd expect as much. |
| 12:00 | <Philip`> | (and if you write scripts to manipulate the DOM, you'll hit those text nodes) |
| 12:00 | <othermaciej> | the web is messy |
| 12:00 | <Hemebond> | Very. |
| 12:00 | <Philip`> | so XHTML2 won't make this any less confusing :-) |
| 12:00 | <Hemebond> | So why is HTML5 trying to validate that mess instead of cleaning it up? |
| 12:00 | <OmegaJunior> | The HTML5-project should try to avoid adding to the mess. |
| 12:01 | <Philip`> | What should HTML5 do instead? |
| 12:01 | <Philip`> | (in this particular case) |
| 12:01 | <Hemebond> | Well, is inline content allowed in a DIV? |
| 12:02 | <Philip`> | Today HTML5 says "Content model: Zero or more style elements, followed by either zero or more block-level elements, or inline-level content (but not both)." |
| 12:02 | <Philip`> | (but that is being rewritten by Hixie) |
| 12:02 | <Philip`> | so it depends on what "is" is :-) |
| 12:03 | <OmegaJunior> | Yes, inline-content is allowed in a DIV, but not together with block-content. |
| 12:03 | <OmegaJunior> | (current spec) |
| 12:03 | <Hemebond> | Then document is invalid and should fail. |
| 12:04 | <Philip`> | But the current spec says inter-element whitespace is not significant for whether a document is valid; otherwise it'd be horrible because you couldn't e.g. write a list with one <li>item...</li> per line |
| 12:05 | <Hemebond> | I was thinking of the original example that had text between the nodes. |
| 12:05 | <Hemebond> | Whitespace between elements should be ignored. |
| 12:06 | <OmegaJunior> | Agreed |
| 12:06 | <OmegaJunior> | That whitespace exists for the benefit of the source programmers and readers. |
| 12:06 | <Philip`> | Okay - that one is currently invalid, but apparently there has been no convincing reason why it should be invalid, and it causes problems for people migrating from HTML and provides no benefits |
| 12:07 | <Hemebond> | Boohoo. Their code is shit. |
| 12:07 | <Philip`> | Their code is valid HTML4 |
| 12:07 | <Hemebond> | Yeah. |
| 12:07 | <Hemebond> | So they can stay with HTML4. |
| 12:07 | <Hemebond> | Or clean it up. |
| 12:07 | <Hemebond> | HTML4 allows inline and block in the same div? |
| 12:07 | <OmegaJunior> | Yeah |
| 12:08 | <Hemebond> | Awesome. |
| 12:08 | <Hemebond> | Why not allow it here in HTML5 then? |
| 12:08 | <OmegaJunior> | Hemebond: because the rendering is undefined |
| 12:08 | <OmegaJunior> | Which leads to differences between browser |
| 12:08 | <Hemebond> | I see. |
| 12:09 | <Hemebond> | Hmmm |
| 12:09 | <Hemebond> | Render it inline, at the top of the DIV. |
| 12:09 | <Hemebond> | With block elements rendering below it. |
| 12:09 | <Hemebond> | Haha |
| 12:09 | <Philip`> | http://validator.w3.org/check?fragment=%3C!DOCTYPE%20HTML%20PUBLIC%20%22-//W3C//DTD%20HTML%204.0//EN%22%3E%20%3Ctitle%3E%3C/title%3E%20%3Cdiv%3E%3Cp%3Efoo%3C/p%3E%20bar%20%3Cp%3Ebaz%3C/p%3E%3C/div%3E |
| 12:09 | <Hemebond> | That'd mess with people. |
| 12:09 | <Philip`> | This Page Is Valid HTML 4.0 Strict! |
| 12:09 | <Hemebond> | w3.org validator means nothing. |
| 12:10 | <Hemebond> | I mentally slap anyone who claims spec conformance by using that validator. |
| 12:10 | <OmegaJunior> | o.O. |
| 12:10 | <Hemebond> | In this case of course... |
| 12:10 | <Hemebond> | it does match. |
| 12:10 | <Camaban> | and the one you use is..... |
| 12:11 | <Hemebond> | Got a link somewhere.... |
| 12:11 | <Philip`> | http://htmlhelp.com/cgi-bin/validate.cgi?url=http%3A%2F%2Fphilip.html5.org%2Fmisc%2Fdivblockinline.html&warnings=yes |
| 12:11 | <OmegaJunior> | To my knowledge the w3 validator is authoritive? |
| 12:11 | <Hemebond> | It's no longer developed as far as I know. |
| 12:11 | <Hemebond> | And not complete. |
| 12:12 | <Hemebond> | According to ex-w3 members. |
| 12:12 | <Hemebond> | Philip`: Yes, I think that's the one. |
| 12:12 | <Philip`> | "Congratulations, no errors!" |
| 12:12 | <Hemebond> | Yeah... I know. |
| 12:12 | <Hemebond> | Because it is valid HTML4. |
| 12:12 | <Hemebond> | My comment was just slightly OT. |
| 12:13 | <Hemebond> | Just an aside. |
| 12:14 | <Philip`> | Hmm, Validome doesn't work at all - it says the doctype is missing |
| 12:15 | <Philip`> | Oh, right, it's just broken in Opera |
| 12:16 | <Philip`> | Hemebond: The W3C validator is still actively developed |
| 12:16 | <Camaban> | http://validator.w3.org/whatsnew.html#t2007-10-11 no longer developed? |
| 12:16 | <Hemebond> | *shrug* |
| 12:16 | <Hemebond> | Just repeating what I read. |
| 12:16 | <Camaban> | and that actually the validator at w3.org and htmlhelp are identical |
| 12:18 | <Hemebond> | 1:30am |
| 12:18 | <Hemebond> | Night all. |
| 12:20 | <Philip`> | Good night |
| 12:20 | <OmegaJunior> | Night! |
| 13:22 | hdh | thought of tagging white-space node with irrelevant |
| 13:40 | <Philip`> | hdh: Adding the 'irrelevant' attribute to white-space text nodes in the DOM? I thought only Element nodes could have attributes |
| 13:42 | <hdh> | hm, okay |
| 20:04 | nikola_tesla | changes topic to '' |
| 20:16 | gsnedders | wonders what the point of \paragraph and \subparagraph is in LaTeX |
| 20:21 | <hsivonen> | isn't \paragraph a bit like \theorem or somesuch--not a generic paragraph? |
| 20:27 | <zcorpan> | is it possible to throw proper DOMExceptions with javascript? e.g. INVALID_STATE_ERR ? |
| 20:28 | <zcorpan> | throw new Error('INVALID_STATE_ERR') isn't it |
| 20:28 | <gsnedders> | hsivonen: \theorem? :P |
| 20:32 | <Philip`> | He stole our topic :-( |
| 20:33 | gsnedders | blames him |
| 20:33 | Philip` | wonders if anyone has a backup copy |
| 20:34 | <hdh> | WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks! |
| 20:34 | gsnedders | changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!' |
| 20:34 | <Philip`> | Ah, thanks :-) |
| 20:34 | <hdh> | :) pidgin powered |
| 20:41 | <hsivonen> | gsnedders: isn't there a \theorem in LaTeX? |
| 20:41 | <gsnedders> | hsivonen: no idea. I've only started properly learning LaTeX tonight :P |
| 21:20 | <jgraham_> | Er, well LaTeX can have \anything-you-like with the right style file :) |
| 21:21 | <jgraham_> | But I think \theorem is pretty standard |
| 21:23 | <jgraham_> | see http://www.math.uiuc.edu/~hildebr/tex/theorems.html - it seems to be included in amslatex |
| 21:25 | <jgraham_> | actually I think I'm wrong about that \begin{theorem} seems to be in ordinary LaTeX |
| 22:15 | gsnedders | wonders whether the following will confuse his computing teacher: |
| 22:15 | <gsnedders> | "Reliability is the consistency that the program creates the correct output |
| 22:15 | <gsnedders> | for any given input (to the extent that output can be found given |
| 22:15 | <gsnedders> | the halting problem)." |
| 22:17 | <Philip`> | I don't see why the halting problem is at all relevant |
| 22:17 | <gsnedders> | actually, it shouldn't create any output, should it, therefore meaning it is irrelevant |
| 22:17 | gsnedders | headdesks |
| 22:17 | <Philip`> | Uh, I'm not sure what you mean |
| 22:18 | <gsnedders> | Philip`: don't worry, just how I ended up with the halting problem being relevant in my head (which is stupid) |
| 22:19 | <Philip`> | It might be relevant that something which doesn't give an incorrect answer because it doesn't give any answer (i.e. it doesn't terminate) is incorrect, but that's not the halting problem |
| 22:19 | <gsnedders> | Philip`: mainly down to whether it should be creating any output for a certain input that makes the algorithm fall into the halting problem |
| 22:20 | gsnedders | has already forgotten half his reasoning for it anyway |
| 22:20 | <gsnedders> | and trying to re-create it is failing |
| 22:21 | <Philip`> | It's only a problem if you want to prove whether the program does or does not produce output, and I'm not sure why you'd want to prove that :-) |
| 22:22 | <gsnedders> | Philip`: I did, indirectly, without explaining myself anywhere near enough :) |
| 22:22 | <gsnedders> | And it's so vaguely relevant and the halting problem isn't even taught so you couldn't really rely on my teacher having a clue what it is :\ |
| 22:22 | <Philip`> | The halting problem is largely irrelevant in reality anyway, because a tool which decides "this program does terminate" or "I'm not sure this program terminates" is possible and useful (and e.g. implemented by Microsoft) |
| 22:24 | <Philip`> | Also, computers are finite |
| 22:24 | jgraham_ | can suddenly access whatwg.org again :) |
| 22:24 | <Philip`> | So I don't understand why people use the halting problem as an excuse so often :-) |
| 22:26 | <gsnedders> | Philip`: "… we're only immortal for a limited time." |
| 22:29 | <Philip`> | (I also don't understand http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-02.txt talking about Turing completeness, because XML DTDs are not Turing complete and you can do things like the billion laughs attack in non-Turing-complete languages easily since a billion is finite) |
| 22:32 | gsnedders | doesn't really under turning completeness |
| 22:33 | <jgraham_> | Philip`: Do you have any data on how many pages use <form method=foo> with foo not in the set (get, post, put, delete)? |
| 22:34 | <Philip`> | If a language is Turing complete, it kind of means you can emulate a Turing machine in the language and you can emulate that language on a Turing machine, and hence the language is equivalent in expressiveness to every other Turing complete language, except the details are a bit more complex and that's probably inaccurate :-) |
| 22:35 | <jgraham_> | (Turing machines are kinda hard to come by. Specifically the infinite rolls of tape aren't stocked by Tesco) |
| 22:36 | <Philip`> | (That's not a problem - you can predict how fast the tape will be used up, and just buy new rolls and sellotape them onto the end of the previous one when it's about to be used up) |
| 22:36 | <gsnedders> | (What's a turning machine?) |
| 22:36 | <hsivonen> | jgraham_: the tape only needs to be long enough for whatever you are computing if the program terminates :-) |
| 22:36 | <hsivonen> | of course, figuring out if it terminates so you can go buy tape is hard |
| 22:37 | <Philip`> | http://c2.com/cgi/wiki?BloopFloopAndGloop - you can do vaguely useful things without being Turing complete |
| 22:37 | <Philip`> | gsnedders: (Do you mean "Turing" rather than "turning"?) |
| 22:37 | <gsnedders> | Philip`: (yes) |
| 22:37 | <gsnedders> | (I always do that) |
| 22:37 | <Philip`> | (http://en.wikipedia.org/wiki/Turing_machine is the obvious place to look :-) ) |
| 22:37 | <Philip`> | (but, er, it looks quite a long page) |
| 22:39 | <gsnedders> | yeah |
| 22:39 | <gsnedders> | it is, and confusing. |
| 22:39 | gsnedders | wonders what \relax is in LaTeX |
| 22:40 | <Philip`> | http://www.abelard.org/turpap2/tp2-ie.asp is more confusing |
| 22:40 | <jgraham_> | gsnedders: if you ever have quite a lot of time to spare you might enjoy something like The Emperor's New Mind by Roger Penrose. It touches on Turing machines, Godel's theorem and lots of other interesting things in a mostly-comprehensible way |
| 22:41 | gsnedders | wishes he had more spare time |
| 22:41 | jgraham_ | wishes he made better use of his time |
| 22:41 | gsnedders | finishes computing homework for today |
| 22:42 | <gsnedders> | I better do the homework for the Friday before last tomorrow, then. |
| 22:43 | <hdh> | last tomorrow? end of the world ?-) |
| 22:43 | <Philip`> | jgraham_: http://www.cl.cam.ac.uk/~pjt47/misc/method.txt is total number of occurrences |
| 22:43 | <Philip`> | (out of ~15K pages) |
| 22:44 | <Philip`> | (with XML escaping that shouldn't be there) |
| 22:44 | Philip` | fixes the escaping |
| 22:45 | <jgraham_> | Philip`: Thanks |
| 22:45 | <Philip`> | http://www.showroomnavi.com/ - <form name="area01" method=post" action="cgi-bin/awsearch.cgi" accept-charset="x-euc-jp"> - that is all the post" ones |
| 22:50 | <hdh> | 410 fits better, no? |
| 22:51 | zcorpan | made a new http://simon.html5.org/tools/js/innerhtml-viewer/ |
| 22:52 | <zcorpan> | with features that are not in the spec (yet)! (see the js file) |
| 23:20 | <zcorpan> | Hixie: try this in firefox: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Caddress%3E%3Ctable%3E%3C%2Ftable%3E%3C%2Faddress%3E%3Caddress%3E%3Col%3E%3C%2Fol%3E%3C%2Faddress%3E%3Caddress%3E%3Cul%3E%3C%2Ful%3E%3C%2Faddress%3E%3Caddress%3E%3Caddress%3E%3C%2Faddress%3E%3C%2Faddress%3E%3Caddress%3E%3Ch1%3E%3C%2Fh1%3E%3C%2Faddress%3E (re why <address><ol> can't be allowed, although i guess we could allow it despite |
| 23:22 | <Hixie> | aw man |
| 23:22 | <Hixie> | firefox screws us again |
| 23:27 | <Hixie> | hey anyone got any publicly visible java implementations of the tree construction phase? |
| 23:31 | <jgraham_> | Hixie: Doesn't hsivonen's imp. do what you want (I feel I'm missing something) |
| 23:31 | <Hixie> | is it online? |
| 23:31 | <Hixie> | i guess it must be |
| 23:31 | <jgraham_> | Do you want it to print the tree online or just to download it? |
| 23:32 | <Hixie> | oh i just meant the source |
| 23:32 | <jgraham_> | http://about.validator.nu/htmlparser/ |
| 23:32 | <Hixie> | sweet |
| 23:33 | <jgraham_> | Hmm. I wonder why gecko adds random attributes to heading elements in misnested formatting elements |
| 23:33 | <Hixie> | which attributes? |
| 23:34 | <hdh> | _moz_something |
| 23:34 | <Hixie> | yeah it's the "something" part i was wondering about |
| 23:35 | <jgraham_> | actually to the formatting elements themselves |
| 23:35 | <jgraham_> | _moz-rs-heading="" |
| 23:35 | <Hixie> | odd |
| 23:35 | <Hixie> | dunno |
| 23:36 | <jgraham_> | It seems to be so that they can set font-size:inherit |
| 23:59 | <Hixie> | wohayhay, an actual deadline for publication of html5 fpwd |