| 00:00 | <Hixie> | Philip`: how's this?: |
| 00:00 | <Hixie> | <p>Unless otherwise stated, any method call with a numeric argument |
| 00:00 | <Hixie> | whose value is an infinite or NaN value must be ignored. Similarly, |
| 00:00 | <Hixie> | any numeric property setter called with a value that is infinite or |
| 00:00 | <Hixie> | a NaN value must be ignored.</p> |
| 00:00 | <Philip`> | Is that applying just to canvas, or the whole of HTML5? |
| 00:01 | <Hixie> | canvas |
| 00:01 | <Hixie> | 2D context specifically |
| 00:02 | <Philip`> | I don't see anything objectionable there |
| 00:02 | <Hixie> | k |
| 00:02 | <jgraham_> | aseem: It is something ruby specific so, given Sam wrote those tests and he has offered to port your code to ruby I wouldn't worry too much about it :) |
| 00:03 | <Philip`> | (create{Linear,Radial}Gradient and isPointInPath and getImageData seem to be the places that would need some otherwise statements) |
| 00:03 | <Hixie> | =oh? |
| 00:04 | <Hixie> | why? |
| 00:04 | <Philip`> | Because they have to return something of the correct type |
| 00:04 | <Hixie> | oh right |
| 00:04 | <Philip`> | so they'd have to return null or false or whatever |
| 00:04 | <Philip`> | s/or whatever// |
| 00:05 | <annevk> | i can't find the toDataURL() + drawImage(data: ) issue in the issue tracker |
| 00:07 | <Philip`> | annevk: That was resolved ages ago since the spec said it was permitted |
| 00:07 | <Philip`> | (but maybe things have changed since then) |
| 00:08 | <annevk> | it did? |
| 00:09 | <Philip`> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011308.html |
| 00:10 | <annevk> | i see, that's not what browsers do |
| 00:11 | <Philip`> | Browsers are bad and wrong :-) |
| 00:11 | <annevk> | and doesn't cover <img src=evil.com> that redirects to a data: URI |
| 00:11 | <annevk> | as far as I can tell |
| 00:11 | <annevk> | the origin section is pretty vague about what "image" means in this case too |
| 00:12 | <Hixie> | that presumably wouldn't be evil.com |
| 00:12 | <Hixie> | it would be victim.com |
| 00:13 | <aseem> | jgraham: so I guess I will leave them empty. thanks |
| 00:14 | <annevk> | Hixie, i guess so, yeah |
| 00:14 | <jgraham_> | aseem: Are you copying the whole file? |
| 00:14 | <Hixie> | brb |
| 00:14 | <aseem> | jgraham: yes that was my intent, and then I was planning to remove anything that did not need to be there |
| 00:16 | <jgraham_> | Hmm. You might want to think about adding the stripped behavior as an extra field in the current file. That way we're less likely o get tests for the two parts out of sync |
| 00:18 | <aseem> | I did think abou that. The reason I thought about forking the data file and the test too is because there are in line tests in the test_sanitizer.py. I could of course modify the addtest method to also accept a stripped output param, but was hesitant to change that |
| 00:19 | <aseem> | mainly because the change would require quite a few more things to be added to SanitizeTest class |
| 00:20 | <aseem> | that is something I might need to do even if I added the extra field in the data file also |
| 00:24 | <Hixie> | right, checked in the changes |
| 00:24 | <Hixie> | for infinities |
| 00:24 | <Hixie> | this changes how transformations handle inf, btw |
| 00:24 | <jgraham_> | aseem: I suggest you make sanitize_html take a kwarg strip=False |
| 00:25 | <jgraham_> | Then modify buildTestSuite to add the tests from the same data file but your new field being read for the expected value |
| 00:25 | <jgraham_> | Then modify all the inline tests to also have a strip=True version |
| 00:26 | <jgraham_> | (of course you need to actually implement strip=True in sanitize_html) |
| 00:26 | <jgraham_> | Does that make sense? |
| 00:26 | <aseem> | sure... that was the original plan, I just balked at the amount of change that would require :) |
| 00:27 | <aseem> | and chose to take the lazier route |
| 00:28 | <aseem> | also I think there might be a problem with the toxml method for tokens. |
| 00:28 | <jgraham_> | ? |
| 00:28 | <aseem> | ie the original _base.Node.toxml accepts and encoding= param which none of the base class implementations do which may cause it to barf |
| 00:28 | <Hixie> | so for createLinearyGradient i support we just sayt that the two points are subjected to the CTM and that's that |
| 00:28 | <Hixie> | but for createRadialGradient... |
| 00:29 | <aseem> | sorry I meant derived class implementations |
| 00:29 | <aseem> | We ran into that recently and I had to go back to the example that I had originally posted on the mailing list because there I can pass in an encoding parameter |
| 00:29 | Hixie | cheats his way out and moves on |
| 00:33 | <aseem> | oops! I misspoke, its the Document.toxml() that has the encoding parameter, which is not available for others Node derived classes |
| 00:35 | <jgraham_> | That makes more sense :) |
| 00:35 | <jgraham_> | I'm not quite sure we want to be using .toxml() at all at this point; the proper serializer seems like a better option |
| 00:36 | <aseem> | In any case I will try out the original approach (the one you outlined) and get it to work, before tackling the encoding related issue |
| 00:36 | <aseem> | which is what is in the example that I posted in the mailing list :) |
| 00:37 | jgraham_ | wonders if people are using toxml |
| 00:38 | <aseem> | the using html5lib wiki page provides the serializer oriented example, however the code in the test suite looks quite compact and attractive :) |
| 00:40 | <aseem> | one good thing about the toxml approach is that the element attribute ordering is not messed up in the output. I have not been able to figure out how to do that with the serializer (yet). |
| 01:16 | <Hixie> | how can Referer: possibly be relative |
| 01:16 | <Hixie> | i don't understand wha that would mean |
| 01:16 | <Hixie> | oh we can just make it "#PING" |
| 01:17 | <Hixie> | since that's non-conforming today |
| 01:25 | <Hixie> | bbl |
| 06:36 | <takkaria> | Prince really is pretty fantastic |
| 08:55 | gsnedders | is reminded by that to report a bug with his print styles in WebKit :P |
| 10:54 | <annevk> | Hixie, data:,ping |
| 10:58 | gsnedders | treats the above as application/octet+stream as it has no defined MIME type |
| 11:00 | <annevk> | that'd be a bug |
| 11:00 | gsnedders | needs http://bugs.gsnedders.com/ |
| 11:02 | <hsivonen> | Lachy: there are articles pending review in the blog queue |
| 11:03 | <gsnedders> | hmm, if I declare a public entity, does it exist in a system entity? |
| 11:39 | <jgraham_> | hsivonen: I think all three of those articles are spam (I only deleted the English one) |
| 11:39 | <hsivonen> | jgraham_: ok |
| 11:51 | <Lachy> | the other two are spam as well. I was just about to delete the english one too |
| 11:55 | <annevk> | should we transition the WHATWG blog to HTML 5? |
| 12:01 | <Lachy> | we could do that. |
| 12:02 | <Lachy> | we had done that once before |
| 12:04 | <Lachy> | actually, it could be good to develop an HTML5 WordPress template |
| 12:10 | <annevk> | yep |
| 14:16 | <gsnedders> | annevk: if you allow DOCTYPEs in XML5, can you _please_ allow parsed entities to have them |
| 15:00 | <annevk> | http://lists.w3.org/Archives/Public/public-html/2008Feb/0021.html |
| 15:00 | <annevk> | hmm |
| 15:03 | <Philip`> | The HTML-to-plain-text email conversion there is really broken |
| 15:04 | <annevk> | oh, that's how i see it too |
| 15:06 | <Philip`> | The plain-text <HYPERLINK "http://www.htmlhelp.com/reference/html40/tables/td.html"TD nowrap> is meant to be <TD nowrap> where the "TD" is a link |
| 15:08 | <Philip`> | (I don't know what validator it is that links to htmlhelp.com...) |
| 15:09 | <annevk> | http://htmlhelp.com/tools/validator/ ? |
| 15:09 | <Philip`> | Oh, could be |
| 20:11 | <Hixie> | people really should stop appealing to webarch to defend their arguments |
| 20:12 | <Hixie> | it's a little like referring to a religious text |
| 20:12 | <Hixie> | it only works when the other person is converted |
| 20:14 | <Dashiva> | So Hixie, did zcorpan mention the issue with acid3 test 48? |
| 20:17 | <Hixie> | i don't think so |
| 20:18 | <Hixie> | what's the problem? |
| 20:18 | Philip` | tries not to wonder what happens when you use arcTo to draw an infinitely long line while the CTM has a scale factor of zero |
| 20:18 | <Dashiva> | If the iframe onload to remove the class fails, the test will pass automatically |
| 20:18 | <Hixie> | Philip`: how can you draw an infinitely long line? |
| 20:19 | <Philip`> | Hixie: By using arcTo so that it draws a line to (x_{inf}, y_{inf}) |
| 20:19 | <Hixie> | Philip`: calls to arcTo() with Infinity as an argument would get ignored per the latest tet |
| 20:19 | <Hixie> | Dashiva: hm |
| 20:20 | <Philip`> | Hixie: arcTo with finite arguments is explicitly defined to draw an infinite line in certain cases |
| 20:20 | <Hixie> | Philip`: oh |
| 20:20 | <Philip`> | Anyway, I'd be happiest to ignore it and have it implicitly undefined behaviour because it's not really going to matter for real-world interoperability |
| 20:21 | <Hixie> | Philip`: ignore the infinite cases or ignore the CTM 0 case? |
| 20:22 | <Philip`> | Hixie: The cases with both infinite lines and CTM 0 |
| 20:23 | <Philip`> | (Each by itself is alright and is useful to define) |
| 20:23 | <Hixie> | ah |
| 20:23 | <Hixie> | send mail :-) |
| 20:23 | <Hixie> | Dashiva: any suggestions? |
| 20:25 | <Dashiva> | Well, the error I'm seeing is gEBI failing, which could be solved by using a closure instead. |
| 20:26 | <Dashiva> | I thought there was a test for gEBI updating, but I can't seem to find it. |
| 20:27 | <Philip`> | Hixie: By "ignore it", I mean "not send mail", because sending mail would be the opposite of ignoring the problem, and the mail would just suggest doing nothing at all and ignoring the problem since it's a worthless edge case :-) |
| 20:36 | <Hixie> | Dashiva: ok, it'll make test 80 fail if it doesn't work now |
| 20:36 | <Hixie> | Philip`: oh, i just meant we should make the spec say to draw nothing in that case |
| 20:37 | <Hixie> | Dashiva: what browser was this for? |
| 20:37 | <Dashiva> | Opera |
| 20:38 | <Dashiva> | It does pass the actual thing test 48 is for, funny enough |
| 20:38 | <Hixie> | yep, opera now says "linktest didn't fire onload" |
| 20:39 | <Dashiva> | Well, what happens is that onload does fire, but the onload handler errors because it can't find the linktest element |
| 20:39 | <Philip`> | Hixie: I think that would be unpleasantly complex (hence not worthwhile) to define, since it depends on the direction of the infinite line and whether the CTM is zero in that direction (e.g. scale(0,1) would cause problems for infinite horizontal lines, but would be perfectly sensible for infinite vertical lines) |
| 20:40 | <Philip`> | But I've failed at ignoring the problem since I've started discussing here, so I'll just send mail instead :-) |
| 20:40 | <Dashiva> | Maybe it could set a variable in the onload, then attempt to remove the class attr |
| 20:40 | <Dashiva> | That way you could see if onload never fired, or just failed to succeed |
| 20:44 | <Hixie> | Dashiva: i'll leave that to the people debugging the test |
| 20:44 | <annevk> | Hixie, where is webarch used? |
| 20:46 | <Hixie> | in the religious acts of the ivory tower's inhabitants, i presume |
| 20:49 | <Hixie> | i'd like to thank you all, especially hsivonen and Philip`, for moving the focus of the discussion on public-html to studying actual data |
| 20:49 | <Hixie> | it is so refreshing to see "expert opinions" be replaced by actual data |
| 20:51 | <Philip`> | (Aha! I don't actually need to send mail about the infinite arcTo thing, since a zero scale will make points coincident in the only case that would have been a problem, and so it's no longer an issue, so please feel free to ignore me) |
| 20:53 | <Hixie> | works for me! |
| 20:53 | <Hixie> | what does chris mean when he says: |
| 20:53 | <Hixie> | The rounding arc should be chosen |
| 20:53 | <Hixie> | so that it is not contained in the convex hull of the stroke path segments |
| 20:53 | <Hixie> | terminated at the points where the arc begins. |
| 20:54 | <Philip`> | About the "it used to say "another" point": it did say that, but I think it's acceptable to think of a point P and 'another' point Q regardless of whether P=Q, so it's better to be explicit :-) |
| 20:56 | <Philip`> | Hixie: I'm not exactly sure about the "stroke path segments terminated at the points where the arc begins", but the idea sounds correct |
| 20:57 | <Philip`> | If you start with just the end edges of the stroke that are perpendicular to their lines, then the convex hull will be the smallest triangle or quadrilateral that surrounds those edges |
| 20:58 | <Philip`> | and then the arc will be not inside that convex hull |
| 20:58 | <Philip`> | Oh, but actually that's not right |
| 20:59 | <Philip`> | since both possible arcs would be outside that shape |
| 21:01 | Philip` | tries to reply to that email |
| 21:08 | <Philip`> | Oh, actually, I think it is right, as long as you include a non-zero part of the stroke when calculating the convex hull (which is always possible since lines never have zero length) |
| 21:08 | Philip` | throws away his ASCII art pictures of circles :-( |
| 21:41 | <Hixie> | i have no idea what that e-mail means |
| 21:41 | <Hixie> | i don't know how to change the spec to address that e-mail |
| 21:45 | <hsivonen> | hmm. I'm not getting mail from W3C lists. |
| 21:46 | <hsivonen> | are others getting W3C list mail normally? |
| 21:48 | <Hixie> | hsivonen: yes |
| 21:48 | <jgraham_> | hsivonen: I'm getting public-html ok |
| 21:48 | <hsivonen> | ok. thanks |
| 21:48 | <Hixie> | hsivonen: including from you :-) |
| 21:49 | <Hixie> | btw, for the spaces-in-URIs thing... do we really want to define URI5? |
| 21:49 | <Hixie> | or IRI5 i guess |
| 21:49 | <Hixie> | we could fix other problems at the same time, like the encoding issue |
| 21:49 | <gsnedders> | Hixie: I'd just do what XML does for system identifiers |
| 21:50 | <hsivonen> | I don't know, but I think it is worth spending a thought or two on |
| 21:50 | <gsnedders> | (non-fatal error handling in XML!) |
| 21:50 | <Hixie> | what's that? |
| 21:50 | <Hixie> | gsnedders: well we're talking about making this a non-error |
| 21:50 | <gsnedders> | ah |
| 21:50 | <gsnedders> | I'd keep it as an error |
| 21:50 | <hsivonen> | gsnedders: the IRI lib I'm using can even be configured to check for XML system ID conformance separately from IRI conformance! |
| 21:50 | jgraham_ | wonders if the "All software expands until it can read mail" thing will apply to html5, so eventually we'll end up doing IMAP5 |
| 21:51 | <Dashiva> | jgraham: We already have sockets, what more do we need? :) |
| 21:51 | <hsivonen> | gsnedders: Is the XML thing really error handling or just a processing step? |
| 21:51 | <gsnedders> | woah. |
| 21:51 | <gsnedders> | I misremembered what XML said. |
| 21:52 | <gsnedders> | "System identifiers (and other XML strings meant to be used as URI references) may contain characters that, according to [IETF RFC 3986], must be escaped before a URI can be used to retrieve the referenced resource. The characters to be escaped are the control characters #x0 to #x1F and #x7F (most of which cannot appear in XML), space #x20, the delimiters '<' #x3C, '>' #x3E and '"' #x22, the unwise characters '{' #x7B, |
| 21:52 | <gsnedders> | That means that XML System IDs can contain spaces! |
| 21:53 | <gsnedders> | hsivonen: just a processing step, looking it up |
| 21:54 | <gsnedders> | http://www.w3.org/TR/xml/#dt-sysid |
| 21:56 | <hsivonen> | fwiw, Validator.nu converts the IRIs entered in the UI to URIs with the lib in the IRI mode but converts XML system ids to URIs in the XML system ID mode. |
| 21:58 | <hsivonen> | craziness. the lib supports 6 different conformance modes for URI-like strings: |
| 21:58 | <hsivonen> | URI |
| 21:58 | <hsivonen> | IRI |
| 21:58 | <hsivonen> | RDF |
| 21:58 | <hsivonen> | XML Schema |
| 21:58 | <hsivonen> | XML system ID |
| 21:58 | <hsivonen> | XLink |
| 21:59 | <gsnedders> | Standards Suck. |
| 21:59 | <gsnedders> | Standards Suck 5 anyone? |
| 22:17 | <Philip`> | Hixie: Kristof's email? For his first paragraph, I'm guessing he was not disagreeing with what I said, so there's nothing to do. For the second paragraph, you could change the spec's definition of 'round' to require the drawn arc to be the one satisfying the condition he suggested |
| 22:18 | <Philip`> | (though I currently think the condition he suggested is not correct) |
| 22:22 | <hsivonen> | what validator back end is http://inursite.com/ running? |
| 22:27 | <jgraham_> | hsivonen: It appears to be using the w3c validator |
| 22:27 | <Philip`> | hsivonen: On the results page its "live validation" links to validator.w3.org |
| 22:28 | <Philip`> | (and it gives exactly the same validation messages as validator.w3.org) |
| 22:28 | <hsivonen> | jgraham_, Philip`: thanks |
| 22:54 | <Hixie> | Philip`: what is wrong with the current text? (or did you send mail already :-) ) |
| 23:04 | <Philip`> | Hixie: About round, I did send mail (as a direct reply to you in "Canvas line styles comments"), saying "there's two possible arcs connecting those two corners (one clockwise, one anticlockwise), so it should specify which one is meant." |
| 23:24 | <Hixie> | k |
| 23:24 | <Hixie> | bbl |