| 05:33 | <Lachy_> | I added some more features to the content sniffing page. It will now load data from the query string (like the live dom viewer) and shows the browser output in an iframe |
| 05:34 | <Lachy_> | http://html5.lachy.id.au/content-sniffing/?%3Cfeed%3Etest2%3C/feed%3E |
| 09:18 | <hsivonen> | Philip`: running a copy of the validator.nu software is not hard if your host allows permanantly memory-resident processess and has mod_jk |
| 09:19 | <hsivonen> | what happened with the validator.nu outage was that the shared host was taken down for scheduled maintenance one day |
| 09:19 | <hsivonen> | then something went wrong and the outage took 2 days instead of planned 5 hours |
| 09:20 | <hsivonen> | since the maintenance went long, I couldn't make sure validator.nu was back up before I flew out to Budapest |
| 09:21 | <hsivonen> | and then mod_jk was missing |
| 09:22 | <hsivonen> | and then giving my password to a random internet cafe computer was unacceptable security-wise and GPRS roaming didn't work in Romania, so it took a while to find working wifi connectivity to get everything back up |
| 09:22 | <hsivonen> | I'm going to investigate moving away from the shared host to avoid maintenance breaks when I happen to be traveling |
| 09:23 | <hsivonen> | my apoligies to everyone who tried to use the service during the outage |
| 09:23 | <hsivonen> | apologies even |
| 10:07 | <hsivonen> | Re: accesskey UI: BBEdit/TextWrangler show shortcut keys on dialog buttons when the command key is held down. |
| 10:38 | <hsivonen> | I'm going to implement POSTing documents to validator.nu. Is Content-Location on POST a good way to indicate the base URI of the POSTed document? (the RFC leaves Content-Location on POST undefined) |
| 11:44 | <zcorpan> | hsivonen: are there any alternatives? :) |
| 11:44 | <zcorpan> | why do you need the base uri? |
| 11:51 | <hsivonen> | zcorpan: the alternative would be along the lines of X-Content-Location |
| 11:51 | <hsivonen> | zcorpan: the base URI is needed for the DTD-loading mode |
| 11:52 | <hsivonen> | zcorpan: also, if Hixie really goes down the road of requiring conformance checkers to load images, then the base URI will be needed for HTML5 as well |
| 11:52 | <hsivonen> | (although I'm kinda hoping Hixie won't go there :-) |
| 12:04 | <zcorpan> | hsivonen: you could opt to not support loading DTDs in such cases |
| 12:08 | <hsivonen> | zcorpan: I could. but picking a HTTP header name and sticking its value in a SAX InputSource is so embarrassingly easy that I feel I should do it for completeness |
| 12:11 | <hsivonen> | the harder part is checking that the pre-existing code that expects to see sane URIs doesn't break too much when a URI is missing |
| 12:32 | <Lachy> | hi hsivonen, how was your holiday? |
| 12:45 | <hsivonen> | Lachy: the holiday was fine |
| 12:45 | <Lachy> | cool :-) |
| 12:47 | <Lachy> | re POST and Content-Location header, I don't understand how you intend it to be used. Are you expecting clients to send the Content-Location header with their POST request? |
| 12:49 | <Lachy> | and is the HTML file supposed to be posted in the body of the request? |
| 12:49 | <hsivonen> | Lachy: yes and yes |
| 12:50 | <Lachy> | ok, but regular web browsers wouldn't send that header. Which clients would you expect to do so? |
| 12:50 | <hsivonen> | Lachy: blogging systems, command line tools and such non-browser Web service clients |
| 12:51 | <Lachy> | ok |
| 12:51 | <hsivonen> | Lachy: I intend to implement back end support for form POST, too |
| 12:52 | <hsivonen> | (but I don't have a satisfactory design for form POST front end UI yet) |
| 13:25 | <annevk_zeist> | the omit-alt comments are fun |
| 13:25 | <zcorpan> | hey annevk_zeist |
| 13:26 | <zcorpan> | alles goed? |
| 13:28 | <annevk_zeist> | ja, op zich wel |
| 13:28 | <annevk_zeist> | beetje dingen opruimen van vakantie enzo |
| 13:28 | <zcorpan> | oke |
| 13:29 | <annevk_zeist> | en nog steeds geen baggage uit Madrid... |
| 13:29 | <gsnedders> | still? (or have I misunderstood) |
| 13:29 | <annevk_zeist> | yeah, still no luggage |
| 13:30 | <gsnedders> | just not been there to get it, or…? |
| 13:30 | <annevk_zeist> | neh, they're messing it up |
| 13:30 | gsnedders | sighs |
| 13:30 | <gsnedders> | it's been too long since I've read such languages |
| 13:30 | <annevk_zeist> | supposedly it would go to my parents, but they haven't received anything yet and trying to reach KLM luggage service on the phone is not really possible |
| 13:31 | <gsnedders> | ergh. |
| 13:36 | <annevk_zeist> | anything interesting happened? |
| 13:37 | <gsnedders> | annevk_zeist: oh, just one or two flamewars on public-html. not really interesting by WG standards, though |
| 13:38 | <annevk_zeist> | Lachy, yt? |
| 13:38 | <annevk_zeist> | gsnedders, heh |
| 13:38 | <Lachy> | yo |
| 13:38 | <gsnedders> | annevk_zeist: mainly on the subject of making @alt optional |
| 13:38 | <annevk_zeist> | Lachy, I think it would be nice if the FAQ became a wiki page |
| 13:39 | <Lachy> | ok. If you make the page, I can set up redirection |
| 13:40 | <annevk_zeist> | k, I'll look into it when I have my laptop again |
| 13:40 | <annevk_zeist> | (it's in Utrecht, not lost with the luggage) |
| 13:45 | gsnedders | really needs some sort of hosting on a stable domain for all the browser tests I'm going to write |
| 13:47 | <annevk_zeist> | you can get firstname.html5.org |
| 13:47 | <gsnedders> | meh. geoffrey is a horrible name :) |
| 13:48 | <gsnedders> | annevk_zeist: gsnedders would be preferable, but I wouldn't complain with geoffrey |
| 13:48 | <annevk_zeist> | I suppose I could break the convention... |
| 13:48 | annevk_zeist | ponders |
| 13:51 | gsnedders | has got annevk_zeist pondering. is that safe? :P |
| 13:53 | <annevk_zeist> | as long as you're not here :p |
| 13:58 | <annevk_zeist> | I'll get you gsnedders.html5.org later; need my laptop first |
| 13:58 | <gsnedders> | annevk_zeist: yeah, having your own computer would be useful; thanks, though :) |
| 14:11 | <hsivonen> | Hixie: Re: offline: Isn't if more Web-like for each app view to have its own URI instead of having one top-level URI and a lot of Ajaxy dynamism on the one "page"? |
| 14:49 | <annevk> | ah, 2033 new e-mails |
| 15:31 | <brianherman> | hello |
| 15:31 | <brianherman> | everyone having a good labor day? |
| 17:22 | <gsnedders> | labour day> |
| 17:23 | <gsnedders> | s/>/?/ |
| 17:24 | <Lachy> | gsnedders, apparently it's labor day in the US. I think it's a public holiday |
| 19:30 | <annevk> | hmm, one angry e-mail to KLM and I suddenly get a call from Spain |
| 19:30 | annevk | wonders if they're connected |
| 19:43 | <Lachy> | annevk, what's KLM? |
| 19:43 | <Lachy> | btw, this article seems to be nothing more than FUD http://www.gnucitizen.org/blog/i-dont-think-that-you-understand-firefox3-vulnerable-by-design |
| 19:46 | <Lachy> | the port scanning script is the only one that seems reasonable, but it depends on whether or not readystate ever fires for 3 LOADING when the request hasn't been allowed |
| 19:46 | <annevk> | airline company |
| 19:47 | <annevk> | it doesn't go to readyState 3 obviously (that would also allow more than just port scanning) |
| 19:47 | <Lachy> | yeah, I didn't think it would |
| 19:48 | <virtuelv_> | but restricting browsers from setting the Content-Access-Control header in the request seems reasonable, if over the top |
| 19:49 | <Lachy> | virtuelv_, why would it matter if it was sent as a request header? |
| 19:52 | <virtuelv_> | Lachy: You're right. It shouldn't |
| 19:52 | <virtuelv_> | The TRACE method is used to invoke a remote, application-layer loop- |
| 19:52 | <virtuelv_> | back of the request message. The final recipient of the request |
| 19:52 | <virtuelv_> | SHOULD reflect the message received back to the client as the |
| 19:52 | <virtuelv_> | entity-body of a 200 (OK) response. |
| 19:53 | <virtuelv_> | but, understanding that correctly, offsite TRACE would mostly be impossible anyway |
| 19:53 | <virtuelv_> | or rather, not |
| 19:53 | <virtuelv_> | the point being: |
| 19:54 | <virtuelv_> | (You can theoretically get content back, but the only thing you could possibly steal were the cookies sent to the server in the first place) |
| 19:55 | <Lachy> | IIRC, cookies aren't sent with XHR requests to other domains, are they? |
| 19:58 | <virtuelv_> | There is exactly one mention: "User agents which implement this specification should take care not to expose other trusted data (cookies, HTTP header data) inappropriately." |
| 19:58 | <virtuelv_> | whatever that means |
| 19:59 | <virtuelv_> | if the meaning is that cookies are not to be sent, then I'd say the spec ought to state this explicitly |
| 19:59 | <Lachy> | hmm. I'm not sure, but it would seem crazy if browsers did, since it would open up a huge security risk |
| 19:59 | <annevk> | headers and content body and such is still a big vague atm I'm afraid |
| 20:05 | <annevk> | now everyone can fix bugs: http://wiki.whatwg.org/wiki/FAQ |
| 20:06 | <annevk> | Lachy, you were ok with this, right? |
| 20:07 | <Lachy> | yeah |
| 20:09 | <Lachy> | I'll set up redirection from /faq/ on the blog later |
| 20:10 | <annevk> | k |
| 20:41 | <annevk> | jgraham_, found a bug in your tool: http://wordsandpictures.dyndns.org/cgi-bin/tables/table_inspector.py?uri=http%3A%2F%2Fannevankesteren.nl%2F2007%2F09%2Ftmb-overview&algorithm=html4&scope=1&headers=1 |
| 20:41 | <annevk> | jgraham_, it doesn't respect <tbody> |
| 20:41 | <annevk> | jgraham_, or maybe a bug in scope="rowgroup", dunno |
| 20:42 | <annevk> | jgraham_, it also has encoding issues |
| 20:50 | <annevk> | It's fascinating how RB claims <input usemap> to be implemented in WebKit and Trident |
| 20:50 | <annevk> | to see* |
| 21:09 | <annevk> | I think the <img> section should give some advice on smileys |
| 21:12 | <zcorpan> | <img alt=:-) title=Smile src=smile.gif> ? |
| 21:12 | <annevk> | for instance |
| 21:12 | annevk | always wonders whether ASCII art is appropriate there |
| 21:13 | <jgraham_> | annevk: What do you expect the behaviour to be? |
| 21:13 | jgraham_ | doesn't want to fix the "wrong" problem |
| 21:14 | <annevk> | jgraham_, I expect stuff like "Day 1" not be repeated until the end of the table, it solely applies to the <tbody> it's in |
| 21:14 | <zcorpan> | annevk: i think it's appropriate. it's what you would use if you didn't use an image, and it's quite common in "plain text" |
| 21:17 | <jgraham_> | Oh, I see what you mean |
| 21:25 | <annevk> | good :) |
| 21:25 | <annevk> | I was actually wondering if the algorithm could be made even more nice for the lazy author so I could omit scope= there too |
| 21:26 | <annevk> | scope=rowgroup is implicit if the first row of a rowgroup contains a single header cell |
| 21:28 | <annevk> | zcorpan, well, there are Unicode smileys... |
| 21:29 | <gsnedders> | do homework, or write test cases? hmmm… |
| 21:29 | <annevk> | ☹☺☻ |
| 21:36 | <zcorpan> | annevk: yeah, but they aren't very common in "plain text", probably wasn't what the author typed in, and there are only 3 of them |
| 21:37 | <zcorpan> | forums often have dozens of smileys |
| 21:38 | <zcorpan> | using exactly what was typed in as alt has the advantage that it round trips copy-and-paste |
| 21:48 | <annevk> | hmm, specialcasing <input type=hidden> is ugly |
| 21:48 | <annevk> | doable, but ugly |
| 21:48 | <zcorpan> | indeed |
| 21:48 | <zcorpan> | ie already specialcases it, it allows hidden inputs in head |
| 21:48 | <annevk> | oh |
| 21:49 | <zcorpan> | doesn't make it less ugly but proves that it is doable :) |
| 21:49 | <annevk> | I was thinking that maybe form.elements could be filled up during parsing |
| 21:49 | <zcorpan> | yeah, i was pondering about alternative approaches too |
| 23:04 | <jgraham_> | annevk: I think the heading information for your table is almost right now |
| 23:05 | <jgraham_> | The finalk thing is that the <th>Day 2</th> has "Day 1" as one of its headings (and so on down the page) |
| 23:05 | <jgraham_> | This is because these headers aren't assigned any heading information from the scope algorithm |
| 23:06 | <jgraham_> | and HTML 4 says "In the absence of header information from either the scope or headers attribute, user agents may construct header information according to the following algorithm" |
| 23:06 | <annevk> | how would Day 2 get Day 1? Day 1 has an explicit scope... |
| 23:07 | <jgraham_> | From the implicit algorithm. |
| 23:07 | <annevk> | I do get how Day x gets Location, estimated time, etc. although that's not desired |
| 23:07 | <jgraham_> | I think it's an incorrect reading of the HTML 4 spec, but I don't know what the right reading is. |
| 23:08 | <annevk> | I'm not sure why you think there's absense of scope or headers attribute |
| 23:09 | <annevk> | I suppose I need something like <th scope=rowgroup colspan=4 headers>Day x</th> to override the Location, Height, ... headings |
| 23:09 | <jgraham_> | Because, at the moment, my implementation assumes that ""In the absence of header information from either the scope or headers attribute" applies to the cell we are trying to assign a heading to |
| 23:09 | <annevk> | assuming <th headers> works like that |
| 23:10 | <annevk> | jgraham_, yeah, so you look up and find a <th>, but that <th> can't be the header of the header because it has a different scope... |
| 23:10 | <jgraham_> | in the case of the <th> cell containing "Day 2" there is no information from any scope or headers attribute that assigns heading information to that cell |
| 23:11 | <jgraham_> | annevk: But does HTML 4 actually say that? |
| 23:11 | <annevk> | not sure |
| 23:11 | <annevk> | it also seems that the headers given in <thead> are not applied to the four columns... |
| 23:12 | <jgraham_> | My reading is that if a cell has no heading information supplied from headers or scope you then do the row/column search ignoring scope or headers attributes |
| 23:12 | <annevk> | this is the case in the HTML5 algorithm though |
| 23:12 | <jgraham_> | annevk: agreed |
| 23:12 | <annevk> | HTML5 actually has exactly how I want it |
| 23:12 | <jgraham_> | My imp. of the HTML 5 algorithm seems to get that right |
| 23:12 | <annevk> | including the scope=rowgroup headers not getting the <thead> headers |
| 23:13 | annevk | wonders if that always makes sense |
| 23:13 | <webben> | Probably not. |
| 23:13 | <jgraham_> | My conclusion from playing with a few tables on the net is that nothing always makes sense |
| 23:14 | <webben> | You could have a header cell for a rowgroup in a row that contained summary information/totals for the rowgroup |
| 23:14 | <webben> | I think I've seen tables like that in print. |
| 23:14 | <annevk> | I'm not sure if that's correct usage though |
| 23:15 | <webben> | correct usage of what? |
| 23:15 | <annevk> | of HTML tables |
| 23:15 | <webben> | Why aren't you? |
| 23:16 | <annevk> | because it doesn't make much sense to me to put summaries in headers |
| 23:16 | <webben> | annevk: I don't see why not. A good example would be demographics. |
| 23:16 | <webben> | say you have area then pop in the thead |
| 23:17 | <webben> | then you have each rowgroup as a continent with total pop |
| 23:17 | <webben> | then you have countries in each rowgroup row |
| 23:17 | <webben> | with their respective pop |
| 23:18 | <webben> | Don't forget that a td can be a header simultaneously with being a data cell. |
| 23:20 | <annevk> | that's not actually clear from HTML4 |
| 23:20 | <webben> | annevk: yes it is. it's stated in the DTD |
| 23:20 | <webben> | is there anything that contradicts that? |
| 23:21 | <annevk> | the prose doesn't really support that comment |
| 23:22 | <webben> | annevk: I think trying to read the comments against the prose doesn't make much sense. Specifications aren't meant to be read to be self-contradicting. :) (They might be self-contradicting by accident, but you don't seem to be arguing that's the case here.) |
| 23:24 | <annevk> | I'm not sure why it doesn't make sense. Comments, notes, examples, etc. are all non-normative. (Although in this specific case nothing much is normative and the whole thing is rather vague.) |
| 23:26 | <webben> | annevk: Actually the prose does say: "Note that it's not always possible to make a clean division of cells into headers or data. You should use the TD element for such cells together with the id or scope attributes as appropriate." Which seems a relatively clear restatement of the principle. |
| 23:26 | <webben> | annevk: Yes. But they are all intended to help explain the spec, not contradict it. |
| 23:27 | <webben> | therefore trying to read them as a source of contradictions, like two alternative sources for the same thing, is strange |
| 23:27 | <webben> | (that quote is from 11.4.1) |
| 23:28 | <webben> | annevk: also note the example intended to illustrate the scope attribute which features td with the scope="row" |
| 23:28 | <webben> | followed by the text in the prose: "Although the first cell in each row contains data, not header information, the scope attribute makes the data cell behave like a row header cell." |
| 23:29 | zcorpan | is unsure what the benefit is of trying to figure out what the intent of html4 is |
| 23:29 | <zcorpan> | isn't it better to focus on figuring out an algorithm for html5 that works with existing tables on the web? |
| 23:29 | annevk | is not going to add scope="row" to all his <tr>s |
| 23:29 | <annevk> | euh, <td>s |
| 23:29 | <jgraham_> | zcorpan: I'm interested insofar as it it necessary to show people that vauge = bad + probably illogical |
| 23:30 | <jgraham_> | (illogical in non-trivial cases, that is) |
| 23:30 | <zcorpan> | jgraham_: ok |
| 23:31 | <annevk> | it's also good to know what use cases HTML4 catered for |
| 23:31 | <webben> | annevk: Actually looking through the prose throughout supports that comment. |
| 23:31 | <webben> | I hadn't realised just how supported it was. |
| 23:32 | <annevk> | ? |
| 23:33 | <webben> | I can't see how one could construct anything contradicting the comment. |
| 23:33 | <annevk> | oh |
| 23:34 | <webben> | zcorpan: Depends on whether "figuring out an algorithm ... that works with existing tables" without consulting the spec that data table creators used is a realistic task. I suspect it isn't. |
| 23:36 | <webben> | (Although I'd certainly say it would be also worth looking at representations of the spec in major unlearning resources like w3schools.) |
| 23:37 | <annevk> | I'm not sure why it's unrealistic to study actual tables out there |
| 23:39 | <webben> | annevk: I didn't say it was. I think that's a very important part of the process too. |
| 23:40 | <webben> | annevk: What I am saying is it's unrealistic to /only/ do that. |
| 23:42 | <webben> | (because the spec is a guide to well-authored tables that aren't sampled and unlearning resources are a guide to badly authored ones) |
| 23:43 | annevk | shrugs and goes to bed |
| 23:43 | <tndH> | speaking of w3schools... http://w3schools.invisionzone.com/index.php?showtopic=15018 *grin* |
| 23:50 | <Philip`> | I'm hoping that doesn't count as a legitimate use case for <input usemap> |
| 23:50 | <Philip`> | (It's good to see the author has stopped using <font> - now they just need to go a little further and stop using </font> too...) |
| 23:57 | <annevk> | Given the way how HTML5 defines that browsers should present an image (inside an HTML document) you can theoretically style that page using the Link: HTTP header... |
| 23:57 | annevk | adds it to a list of silly things to test |