| 00:00 | <Hixie> | what reasons? |
| 00:00 | <Dashiva> | Well, with non-xml you have to test for interop on the format parser itself as well, don't you? |
| 00:00 | <aa> | Gears already has a JSON format |
| 00:00 | <aa> | and we don't really want to include an xml parser |
| 00:00 | <othermaciej> | if json doesn't have a way to add comments I think that's a big problem |
| 00:00 | <aa> | true, it is lame |
| 00:00 | <Hixie> | Dashiva: yeah but that becomes much easier, you don't have to test at the level of things like "what happens when you have a dictionary and are expecting a string" or "what happens when you have an element in the wrong namespace" |
| 00:01 | <aa> | othermaciej: that 'true' went to you |
| 00:01 | <othermaciej> | aa: roger that |
| 00:01 | <Dashiva> | JSON is just a format, we could define a comment property |
| 00:01 | <aa> | Dashiva: Not as convenient as being able to put it anywhere |
| 00:02 | <aa> | like above an individual array entry or something |
| 00:02 | <othermaciej> | does JSON not allow /* ... */ comments? |
| 00:02 | <aa> | I think json should just allow js comments, but I don't think it currently does, technically |
| 00:02 | Dashiva | wonders how long until someone suggests JSON5 |
| 00:04 | <aa> | othermaciej: json.org doesn't define any comment grammar at all |
| 00:04 | <aa> | obviously we could just spec it in :) |
| 00:04 | <aa> | by we, I mean hixie |
| 00:05 | <Hixie> | oh yeah that'll go down REAL well |
| 00:05 | <othermaciej> | I think changing the basic JSON serialization should be avoided |
| 00:05 | <othermaciej> | I don't think JSON is really that much better than XML |
| 00:05 | <Hixie> | not for this, no |
| 00:06 | <Hixie> | it has all the same problems of needing all kinds of edge case definitions |
| 00:09 | <Dashiva> | What about SML? |
| 00:09 | <Hixie> | uri? |
| 00:10 | <Dashiva> | Wait, sdf |
| 00:11 | <Dashiva> | The one zcorpan was working on, http://simon.html5.org/specs/sdf |
| 00:11 | <Hixie> | same problem as xml and json |
| 00:11 | <Hixie> | the whole point is that we _don't_ want a syntax with arbitrary structure |
| 00:11 | <Hixie> | since then you have to define and implement and test how to handle every single possible unexpected structure |
| 00:13 | <Dashiva> | That kinda limits the options quite a bit |
| 00:15 | <Hixie> | bbiab, mtg |
| 11:41 | <hsivonen> | is there any way to inform HTTP clients that the server accepts *inbound* gzip-compressed POST data? |
| 11:42 | <hsivonen> | will clients go crazy if I use Accept-Encoding as a *response* header and write support for Content-Encoding as a *request* header? |
| 11:46 | <gsnedders> | hsivonen: clients will ignore the accept-encoding header |
| 11:46 | <Dashiva> | The form element has various attributes, but I'm not sure if any of them are able to do on-the-fly gzip |
| 11:47 | <hsivonen> | Dashiva: I'm mainly considering restful Web service clients |
| 11:48 | <hsivonen> | it appears that RFC 2616 allows Content-Encoding on Entities |
| 11:48 | <hsivonen> | i.e. both on response and request entities |
| 11:49 | hsivonen | goes implement incoming gzip |
| 11:49 | Dashiva | wonders why people make html versions of rfcs without hyperlinks |
| 11:52 | <Dashiva> | "If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type)." |
| 11:52 | <Dashiva> | Seems like you're expected to just try gzip and retry without if it fails on 415 |
| 11:53 | <hsivonen> | I want to get compression right in both directions before I start advertising the Web service facet of validator.nu |
| 11:53 | <hsivonen> | so I can tell people from get-go that they can (should?) compress incoming stuff |
| 11:53 | <hsivonen> | incoming from my POV |
| 11:54 | <Dashiva> | Do you want to disallow identity entirely? |
| 11:54 | <hsivonen> | that would be extreme |
| 11:55 | <hsivonen> | I think I'll cross the bridge of banning uncompressed stuff if the bandwidth bill actually grows to be unmanageable |
| 11:56 | <hsivonen> | of course, the joke will be on me if the service ends up being CPU-bound instead of bandwidth/IO-bound |
| 11:56 | <Dashiva> | Because if identity is allowed, and you mention gzip is encouraged in the docs, shouldn't that be enough to get people who are willing to do gzip to do it? |
| 11:56 | <hsivonen> | Dashiva: hopefully |
| 11:57 | <Dashiva> | Can't really imagine a http client which supports automatic switching to gzip based on a non-documented header :) |
| 11:57 | <hsivonen> | I need to post some sample code, too |
| 12:01 | gsnedders | has Xbox 360 fail |
| 12:01 | gsnedders | watches his productivity rise massively |
| 12:21 | <hsivonen> | hmm. hmm. the RFC is not too clear about the relationship of content-length and content-encoding |
| 12:27 | <Philip`> | Does inbound compression make DOS attacks easier? Someone could send a low-bandwidth compressed stream that expands into a huger amount of data on the server and uses up lots of CPU time |
| 12:28 | <hsivonen> | Philip`: do you mean a specially-crafted Gzip-stream designed to just expand? |
| 12:28 | <hsivonen> | Philip`: it seems to me the same risk exists with compressed streams read using GET |
| 12:29 | <hsivonen> | how do browsers cope with that case? |
| 12:29 | <Philip`> | Not necessarily specially-crafted - someone could just compress a gigabyte of space characters, transmit that (which is cheap for them), and your server would decompress and process it all (which is expensive for you) |
| 12:30 | <Philip`> | Browsers have observant users and a 'stop' button, whereas servers tend to blindly process whatever you send them |
| 12:31 | <hsivonen> | hmm. can a single read() from a GzipInputStream be worse that decompressing 32 KB of data? |
| 12:32 | <hsivonen> | that is, if I put a watchdog stream wrapper between the decompression and the parser, am I safe? |
| 12:33 | <hsivonen> | 32 KB is the default gzip window, isn't it? |
| 12:34 | <hsivonen> | am I right that Content-Length is the length of the compressed stream--not the length of the decompressed stream? |
| 12:34 | Philip` | is unsure of how it works |
| 12:36 | gsnedders | has reverse-engineered that yet |
| 12:36 | <gsnedders> | I can say it is not what is defined in RFC2616, though |
| 12:36 | <Dashiva> | It says "transfer-length", seems clear to me |
| 12:37 | <gsnedders> | But there again, a lot of RFC2616 isn't actually what things are done |
| 12:39 | <Dashiva> | hmm, no... tricky stuff this |
| 12:44 | <Dashiva> | content-length is the entity-length if there is no transfer-encoding. The entity-length is the length of the entity-body. The entity-body includes content-encoding. |
| 12:45 | <hsivonen> | moreover, transfer-encoding and content-encoding are different beast with potentially same values |
| 12:46 | <hsivonen> | I think I sort of grok content-encoding where there are no byte ranges involved |
| 12:46 | <Dashiva> | Well, if you use transfer-encoding it says to not use content-length at all. Not sure if that's how it works in practice, but still |
| 12:46 | <gsnedders> | is Opera the only browser to not download <img style="display:none" src="test.gif">? |
| 12:47 | <krijnh> | No |
| 12:47 | <Dashiva> | Let's find out |
| 12:48 | <hsivonen> | is non-chunked transfer-encoding used in the real world? |
| 12:53 | <Dashiva> | Both FF2 and IE7 downloaded the image |
| 12:56 | <Philip`> | If you do <object data="test.svg"><img src="test.png"></object> then FF2 downloads both files and Opera only downloads the .svg, if I remember correctly |
| 12:58 | <hsivonen> | http://www.aerasec.de/security/advisories/decompression-bomb-vulnerability.html |
| 12:58 | <krijnh> | Dashiva: you sure? |
| 12:59 | <Dashiva> | Apache logs do not lie (I hope) |
| 12:59 | <krijnh> | They do! :) |
| 12:59 | <krijnh> | Hmm |
| 12:59 | <krijnh> | I tested it with background images |
| 12:59 | <krijnh> | Those aren't downloaded for elements with display: none |
| 12:59 | <krijnh> | Or for :hover states |
| 13:00 | <Dashiva> | I could venture a guess, the img tag is recognized and starts downloading before the inline style is applied |
| 13:00 | <Dashiva> | Background image is not recognized as such until styling is applied |
| 13:00 | <krijnh> | That's probably it |
| 13:00 | <krijnh> | Background images with visibility: hidden are downloaded though |
| 13:04 | <zcorpan> | hsivonen: http://simon.html5.org/temp/validator.nu/Validator.nu.htm |
| 13:07 | <krijnh> | hsivonen: why am I getting an IO Error: Circular redirect to .. |
| 13:08 | <krijnh> | For a page that can be viewed in a browser |
| 13:08 | <zcorpan> | hsivonen: although the file upload label doesn't seem to focus the "file" field in firefox :| |
| 13:12 | <hsivonen> | zcorpan: thank you |
| 13:12 | <hsivonen> | krijnh: URL? |
| 13:12 | <krijnh> | http://www.toernooi.nl/sport/teammatches.aspx?id=17064&tid=191 |
| 13:12 | <krijnh> | It's a weird site |
| 13:14 | <hsivonen> | krijnh: might have something to do with their cookie behavior |
| 13:16 | <krijnh> | If you disable cookies, you get back a really weird URL |
| 13:17 | <hsivonen> | yes, but still not circular |
| 13:17 | <hsivonen> | I wonder if Commons HttpClient is so aggressive with circularity that it ignores the query string |
| 13:18 | <krijnh> | Damnit, we really want to parse this site :) |
| 13:20 | <zcorpan> | hmm, doesn't tabindex on <label> work in ie/firefox? |
| 13:21 | <hsivonen> | I'm experiencing the jar version of dll hell when trying to debug :-( |
| 13:23 | <zcorpan> | i can't get keyboard nav work in ie or firefox |
| 13:23 | <zcorpan> | s/work/to work/ |
| 13:24 | <zcorpan> | perhaps it's better to add radio buttons after all |
| 13:39 | <zcorpan> | hsivonen: there, that works better, although it doesn't boot correctly in ie for some reason |
| 13:47 | <zcorpan> | hsivonen: ie barks at "n.disabled = false" in toggleParsers() |
| 13:53 | <hsivonen> | krijnh: I suspect this is the problem: http://jakarta.apache.org/httpcomponents/httpclient-3.x//xref/org/apache/commons/httpclient/HttpMethodDirector.html#630 |
| 13:55 | <zcorpan> | hsivonen: also, ie doesn't seem to uncheck the other radio buttons for some reason |
| 13:55 | <krijnh> | hsivonen: is that a bug? |
| 13:56 | <krijnh> | Or just bad behavior of that site? |
| 13:57 | <hsivonen> | krijnh: bad behavior of site coupled with over-eager counter-measures |
| 13:59 | <krijnh> | Bah |
| 13:59 | hsivonen | tries to loosen the counter-measures |
| 13:59 | <krijnh> | Too bad that's the only site where results are posted :/ |
| 14:13 | <hsivonen> | krijnh: fixed |
| 14:14 | <krijnh> | hsivonen: Cool, thanks :) |
| 14:15 | <hsivonen> | it took me like 3 tries to stick the params in the right place. Commons HttpClient has a zilloin places you can stick params into |
| 14:21 | <krijnh> | hsivonen: What's a good entry point if you're not into HTML5, but you just want to use your parser in a Java project? |
| 14:26 | <krijnh> | http://about.validator.nu/htmlparser/ I guess :) |
| 14:28 | <Philip`> | With that parser, I found it pretty straightforward to set up the libraries and get it to parse a document into a DOM, so it seems to work fine :-) |
| 14:31 | <hsivonen> | krijnh: I suggest you check out how I instantiate the parser in XSLT4HTML5 (bundled sample) |
| 14:31 | <krijnh> | I'm not into Java |
| 14:31 | <krijnh> | Somebody else is going to try it out |
| 14:32 | <krijnh> | I hope :) |
| 14:32 | <hsivonen> | krijnh: do you want DOM, XOM or SAX? |
| 14:32 | <krijnh> | I really have no idea |
| 14:32 | <hsivonen> | krijnh: streaming or tree? |
| 14:32 | <krijnh> | We were talking about fetching results from a website, and now I'm pointing him to your library |
| 14:33 | <hsivonen> | krijnh: well, if the wants DOM, he should do new HtmlDocumentBuilder(XmlViolationPolicy.ALTER_INFOSET); |
| 14:33 | <hsivonen> | and then proceed the same way as with an XML DocumentBuilder instance |
| 14:34 | <hsivonen> | if he wants SAX, he should do new HtmlParser(XmlViolationPolicy.ALTER_INFOSET); and proceed as with a usual XMLReader instance |
| 14:35 | <hsivonen> | if he wants XOM, he should do new HtmlBuilder(XmlViolationPolicy.ALTER_INFOSET); and proceed as with a usual XOM Builder instance |
| 14:35 | <hsivonen> | familiarity with one of DOM, XOM or SAX in a prerequisite |
| 14:36 | Philip` | was unfamiliar with all of those but just made it up as he went along and it kind of worked |
| 14:38 | <Philip`> | (Well, I suppose I had some familiarity with the JS DOM, and the Java version is basically the same except it takes four method calls to set an attribute (as far as I can see)) |
| 14:39 | <hsivonen> | Philip`: elem.setAttribute("foo", "bar"); |
| 14:41 | <Philip`> | hsivonen: Hmm |
| 14:41 | <Philip`> | Oh, it's because I was using Node instead of Element, and Node doesn't have setAttribute |
| 14:42 | <Philip`> | ... and I was using Node because stuff like getElementsByTagName returns a NodeList |
| 14:43 | <Dashiva> | Yeah, that one's a bit silly, there is no ElementList |
| 14:43 | <hsivonen> | Philip`: the interface hierarchy of DOM sucks big time with strongly-typed languages |
| 14:43 | <Philip`> | I guess I can cast things to Element, but casting always feels a little dirty and unsafe |
| 14:43 | <Dashiva> | Just check nodeType (or instanceof) and you're safe enough |
| 14:45 | <Philip`> | Sounds reasonable |
| 14:46 | <Philip`> | Too lazy to fix my code now, though :-p |
| 14:46 | <hsivonen> | it would be interesting to know if which one is faster: instanceof followed by cast or nodeType followed by cast |
| 14:47 | <hsivonen> | I'd expect instanceof to be slower than nodeType, but then I'd expect HotSpot to perform less expensive cast operations if it can prove that instanceof was just tested |
| 14:52 | <hsivonen> | when I wrote my own XML tree API, I hoisted all methods to the top of the hierarchy to avoid casts when traversing |
| 17:17 | <hsivonen> | does IE parse and apply the contents of <style> elements inserted to the DOM via script after onload has long since been fired? |
| 17:19 | <hsivonen> | more to the point: what's the best practice for introducing and later removing a class selector-based style rule? |
| 17:19 | <hsivonen> | or changing the class selector on a single rule_ |
| 17:19 | <hsivonen> | ? |
| 17:34 | <hsivonen> | http://developer.mozilla.org/en/docs/DOM:style Do Opera and WebKit support that stuff? |
| 17:38 | <hsivonen> | is there some perf badness if I modify the first rule? should I make sure to modify the last rule to avoid recascade? |
| 17:56 | <hsivonen> | zcorpan: whole-line messages now highlight the associated line as a whole |
| 18:17 | <zcorpan> | hsivonen: cool |
| 18:17 | <zcorpan> | hsivonen: in the case of direct input, i guess you could default to using the html parser if the user didn't choose |
| 18:18 | <hsivonen> | zcorpan: ok |
| 18:19 | <zcorpan> | hsivonen: is the whole-line highlighting deployed? i don't see it |
| 18:20 | <hsivonen> | zcorpan: http://validator.nu/?doc=http%3A%2F%2Fwww.accessifyforum.com%2F&showsource=yes#l151 |
| 18:20 | <hsivonen> | zcorpan: please reload css |
| 18:20 | <zcorpan> | hsivonen: ah |
| 18:20 | <zcorpan> | sorry :) |
| 18:24 | jgraham | grumbles that different people are on #what-wg and #html-wg |
| 18:24 | <jgraham> | Does anyone have a good use case for tables with no headers? |
| 18:27 | <hsivonen> | jgraham: sidebars |
| 18:27 | hsivonen | hides |
| 18:28 | <hsivonen> | jgraham: form grid layout |
| 18:28 | <zcorpan> | jgraham: genealogical table |
| 18:36 | <zcorpan> | hsivonen: http://www.quirksmode.org/dom/changess.html |
| 18:42 | <zcorpan> | hsivonen: an idea: have the error message as title="" in the show source. would that be possible? |
| 18:43 | <hsivonen> | zcorpan: thanks |
| 18:43 | <hsivonen> | zcorpan: possible but hard |
| 18:44 | <hsivonen> | zcorpan: there can be more than one message per position. |
| 18:45 | <zcorpan> | hsivonen: true |
| 18:45 | <hsivonen> | zcorpan: I wonder if doing some fancy JS backlinking would be smarter than putting a lot of content in attributes |
| 18:45 | <zcorpan> | perhaps |
| 18:46 | <Dashiva> | Make an error attribute as a comma-separated list of errors, and put all the errors in an array somewhere. Use JS to build tooltips or whatnot from it. |
| 18:46 | <Dashiva> | ^ Something like that? |
| 18:47 | <hsivonen> | Dashiva: I was thinking of augmenting the highlight element DOM nodes with an array or references to the list item DOM nodes in the message list and doing fake tooltips as divs |
| 19:03 | <jgraham> | hsivonen: Ignoring the tables for layout cases (which we'll temporarily pretend are obviously bad) what does a genealogical table look like? |
| 19:05 | <jgraham> | ah, sorry, that was zcorpan |
| 19:09 | <hsivonen> | jgraham: http://www.pointerklubben.se/stamtavla.asp?Id=S35236/97 |
| 19:11 | <jgraham> | hmm. I think that's not really a table but I'm not sure how one could do better |