| 00:07 | <webben> | zcorpan: something like http://pastebin.com/mc5b47f9 only longer |
| 00:13 | <Hixie> | kingryan: pure code |
| 00:14 | <Hixie> | kingryan: e.g. you have one class per element type, and you create a DOM tree using those classes, then you just interogate the root "are you valid", and the root asks its kids the same question, after having checked them for validity according to the rules for that type of node, etc |
| 00:14 | <kingryan> | so, instead of having a table that says "for element a, forbid these attributes", you'd have code that gets run when encountering element a that checks for the attribute? |
| 00:14 | <kingryan> | ah, ok |
| 00:58 | <Hixie> | gah, i replied again |
| 01:05 | <kingryan> | anything but a reply! |
| 03:04 | annevk | reads www-archive |
| 03:30 | <Hixie> | hm, john boyer left the htmlwg |
| 03:32 | <othermaciej> | Hixie: your new proposal is sounding better |
| 03:32 | <Hixie> | great! |
| 03:32 | <othermaciej> | Hixie: but it's hard to think through all of the implications |
| 03:33 | <othermaciej> | Hixie: will have to read it and send comments |
| 03:33 | <Hixie> | k |
| 03:34 | <othermaciej> | Hixie: Gears does handle a few details that aren't in this, like handling <input type="file"> when offline |
| 03:34 | <Hixie> | yeah the plan is to do that by just providing an API on HTMLInputFile that exposes the file data |
| 03:35 | <othermaciej> | that's definitely good for relatively small files |
| 03:35 | <othermaciej> | probably not as good for large uploads |
| 03:35 | <othermaciej> | in Safari at least, we stream the file straight from disk in the middle of the form data when uploading, which is pretty much necessary to handle large files sanely |
| 03:36 | <Hixie> | true |
| 03:36 | <othermaciej> | you'd also need some control to dump the data back into (maybe the file input API can also offer API to set data in the same format that it allows get) |
| 03:36 | <Hixie> | but the gears API isn't much better than HTMLInputElement being done, as far as i can tell |
| 03:37 | <othermaciej> | I don't remember how it works |
| 03:37 | <annevk> | othermaciej, you can just post using XHR |
| 03:37 | <othermaciej> | it might not be any better |
| 03:37 | <Hixie> | well you can send your data using any backend sync system you do |
| 03:37 | <Hixie> | doesn't have to be a real form |
| 03:37 | <othermaciej> | that's true |
| 03:39 | <othermaciej> | I guess this doesn't need to tie all that closely into the offline cache |
| 03:40 | <Hixie> | yeah, i feel better about keeping them orthogonal |
| 03:42 | <annevk> | Hixie, should template= and ref be "super" global? |
| 03:43 | <Hixie> | yeah they probably will be |
| 03:43 | <Hixie> | bbl afk |
| 04:13 | <MikeSmith> | Hixie - do you of any existing browser support for inputmode? |
| 08:41 | <zcorpan> | webben: that's an interesting table. so you want Country to apply to all cells in the column but EUROPE and ASIA? |
| 10:31 | <hsivonen> | if Opera has supported media queries since version 7, why isn't the query in validator.nu's style sheet applying in Opera 8.5 (S60r3.1)? (it is in 9.2 on desktop and in Mini 4 beta) |
| 10:43 | <peepo> | oops |
| 12:02 | <annevk> | zcorpan, isn't scope=col already implied? |
| 12:03 | <annevk> | it already works for my tables for instance... (which don't have scope=col) |
| 12:20 | <zcorpan> | annevk: not with the smart colspan algorithm if you have headers lower down with the same colspan as the one in thead |
| 12:23 | <annevk> | hmm, I thought leading spaces were not allowed currently for integer values (such as tabindex=)? |
| 12:24 | annevk | looks through the validator tests |
| 12:24 | <annevk> | is looking through*, even |
| 12:25 | <zcorpan> | "A string is a valid integer if it consists of one of more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), optionally prefixed with a U+002D HYPHEN-MINUS ("-") character." |
| 12:25 | <annevk> | indeed |
| 12:30 | <hsivonen> | can anyone suggest a collective term for errors that caused validation to end up in an indeterminate state due to problems outside the checked document (validator bugs, IO failures, unusable schemas)? |
| 12:31 | <zcorpan> | "internal error"? |
| 12:31 | <zcorpan> | or well, doesn't have to be internal |
| 12:31 | <hsivonen> | zcorpan: I considered that, but a bogus outside schema isn't exactly internal |
| 12:31 | <hsivonen> | zcorpan: neither is outside server failure |
| 12:32 | <zcorpan> | indeed |
| 12:32 | <annevk> | can't you distinguish between them? |
| 12:33 | <hsivonen> | annevk: I'm tring to come up with a forward-compatible format that has a two-level taxonomy of messages |
| 12:33 | <hsivonen> | annevk: with the assumption that the higher level doesn't need to change but the detailed level can change without breaking clients |
| 12:34 | <hsivonen> | so that I'd have "informative", "document error" and "not-document error" as the frozen high level |
| 12:35 | <hsivonen> | and I could introduce a new error type as a subtype with legacy clients still able to figure out the rough category of the new error |
| 12:36 | <hsivonen> | the semantics being: no document nor non-document errors: valid |
| 12:36 | <hsivonen> | no non-document errors but one or more document errors: invalid |
| 12:37 | <hsivonen> | one or more non-document errors: indeterminate |
| 12:38 | <hsivonen> | does that make sense or am on the side of astronautics? |
| 12:38 | <zcorpan> | makes sense |
| 12:39 | <zcorpan> | "non-document" seems like a good term also |
| 12:39 | <annevk> | it would be useful to know though if my schema is bogus for instance |
| 12:48 | <annevk> | is the person who did <event-source> for WebKit around? |
| 12:49 | <hsivonen> | annevk: that would be <non-document type='schema'> |
| 12:49 | <annevk> | there's http://tc.labs.opera.com/html/event-source/ and http://tc.labs.opera.com/html/parsing/event-source/ |
| 12:51 | <hsivonen> | basically, I want to do a native XML format and a native JSON format in a forward-compatible way and say that I reserve the right to break HTML/XHTML/text scraping at whim without notice |
| 13:19 | <Philip`> | annevk: That was G0k, I think |
| 13:21 | <annevk> | ah ok, I'll guess I'll ping him when he's around |
| 15:09 | <hsivonen> | in the XML output format, a message may have these optional subitems: short message (may contain XHTML <code> and <a>), long advice (may contain rich XHTML narrative) and extract from the source |
| 15:09 | <hsivonen> | what kind of markup would people on this channel prefer? |
| 15:11 | <hsivonen> | explicit: <error><message>Blah <h:code>div</h:code></message><elaboration><h:p>BlahBlah</h:p><h:p>BlahBlah</h:p></elaboration><source><div></source></error> |
| 15:11 | <hsivonen> | or something less verbose with implied relationships? |
| 15:12 | <hsivonen> | e.g. merging message and elaboration and stating that the first para is the main message |
| 15:12 | <zcorpan> | using a heading for the message, perhaps? |
| 15:12 | <hsivonen> | interesting |
| 15:13 | <zcorpan> | <error><h:h1>Blah <h:code>div</h:code></h:h1><h:p>Blah... |
| 15:13 | <hsivonen> | my initial though is that they'd be non-heading-like in content |
| 15:13 | <hsivonen> | basically, the message part is what you see now |
| 15:13 | <hsivonen> | and elaboration is going to be a new feature |
| 15:14 | <hsivonen> | I'm thinking of leveraging the liberal WHATWG copyright license and dumping extracts from the spec |
| 15:15 | <zcorpan> | <details>? :) |
| 15:15 | <hsivonen> | zcorpan: that could be a good idea for the (X)HTML output |
| 15:17 | <zcorpan> | having <message><elaboration><source> in the xml format seems good for me, i'm just brainstorming :) |
| 15:18 | <hsivonen> | zcorpan: ok. :-) |
| 15:19 | <hsivonen> | speaking of <details> |
| 15:19 | <hsivonen> | has safe is it in current browsers and are there forward-compatible open-source canned scripted emulation packages? |
| 15:19 | <hsivonen> | s/has/how/ |
| 15:26 | <hsivonen> | I wonder if I should add redundant data as a precomputed success/failure/indeterminate verdict even though the client could compute the verdict from the messages |
| 15:32 | <zcorpan> | iirc <legend> is dropped in some browsers |
| 15:33 | <zcorpan> | haven't seen any scripts to emulate <details> that uses <details> |
| 15:34 | <zcorpan> | thinking about it, reusing <fieldset> might have a better compat story |
| 15:34 | <zcorpan> | but might confuse some ATs |
| 16:53 | <annevk> | Lachy, you would set up a redirect for http://blog.whatwg.org/faq (try it again here as there's less traffic) |
| 16:54 | <Lachy> | annevk, remind me on Sunday |
| 18:59 | <kingryan> | has anyone seen markp around? |
| 19:16 | <gsnedders> | kingryan: you ever have any issues with standalone in the XML declaration with feeds? |
| 19:17 | <kingryan> | hi gsnedders |
| 19:17 | <kingryan> | I'm not sure what you're asking |
| 19:17 | <gsnedders> | like <?xml version="1.0" standalone='yes'?> |
| 19:17 | <gsnedders> | and the fact that standalone=yes |
| 19:17 | <kingryan> | no, not really |
| 19:17 | <kingryan> | not sure I've ever seen that in a feed |
| 19:18 | gsnedders | looks up the bug report he got |
| 19:18 | gsnedders | shrugs |
| 19:18 | <gsnedders> | seems to be fixed in the feed |
| 19:19 | <gsnedders> | probably no need to set standalone=no in everything |
| 19:19 | <gsnedders> | (I await for XMLists to go mad at me for even suggesting that) |
| 19:30 | kingryan | doesn't even know what standalone is for |
| 19:32 | <gsnedders> | kingryan: http://www.w3.org/TR/xml/#sec-rmd |
| 19:41 | <kingryan> | thanks gsnedders. I'm still not sure I understand it, but I think that might be ok |
| 19:42 | <gsnedders> | kingryan: read the validity constraint, that basically summarises it |
| 21:23 | <Hixie> | don't forget to fill out http://www.w3.org/2002/09/wbs/35125/TPAC2007/registrants#html if you're going to the f2f btw |
| 22:02 | <a-ja> | anyone familiar with current state of browser support for figure element? |
| 22:03 | <zcorpan> | no support anywhere yet afaik (although it degrades pretty well) |
| 22:04 | <a-ja> | fairly...with a bit of css lovin |
| 22:04 | <a-ja> | actually, looks like opera kestral gets it right,,,,,or mostly |
| 22:06 | <annevk> | the draconian answer is that if you use XHTML5 it will work quite good (given that you add stuff like display:block) |
| 22:07 | <a-ja> | isntf figure supposed to be block (like a <p>) ? and a legend within a figure should be inline? |
| 22:08 | <annevk> | yeah, but it's not natively supported yet and the initial value of the display property is inline |
| 22:09 | <annevk> | not sure about <legend> in <img>, I would expect the typical presentation to be block level I think, so that it appears under the image |
| 22:09 | <zcorpan> | seems <legend> creates an empty element in kestrel that is display:block... pretty much like <br> |
| 22:09 | <zcorpan> | (unless it's in a <fieldset> that is) |
| 22:10 | <annevk> | <legend> parsing is kind of buggy everywhere... |
| 22:10 | <zcorpan> | indeed |
| 22:11 | <a-ja> | certainly is in ff....legend content ends up as figure's content in dom (and no legend in dom) |
| 22:14 | <a-ja> | from you're comment re: <img>.....are you implying that <img></img> allowing fallback is in html5, rather than <img/> 's alt ? |
| 22:17 | <a-ja> | this is what i've been looking at, fwiw: <figure><img alt="fallback text"/><legend>caption text</legend></figure> |
| 22:18 | <annevk> | what comment regarding <img> are you referring to? |
| 22:19 | <a-ja> | <annevk> not sure about <legend> in <img> ..... |
| 22:19 | <annevk> | oh, meant <legend> in <figure> |
| 22:19 | <a-ja> | ah |
| 22:19 | <annevk> | my bad |
| 22:20 | <a-ja> | np...you just saved me some re-reading :) |
| 22:22 | <zcorpan> | hmm. opera doesn't support display:table-caption on <legend>s |
| 22:25 | <a-ja> | seeing some text-shadow and box-shadow oddities in kestrel, too, btw. |
| 22:26 | <a-ja> | haven't come up with a simplified test case yet though |
| 22:27 | a-ja | will when he gets some more free time |
| 22:27 | <annevk> | box-shadow? |
| 22:27 | <a-ja> | um....just text-shadow, actually |
| 22:27 | <annevk> | too bad :) |
| 22:28 | <zcorpan> | box-shadow would be nice :) |
| 22:29 | <a-ja> | kinda mostly works on safari beta (win).....a little shaky with border-radius |
| 22:34 | <zcorpan> | yeah, the new border stuff creates a lot of edge cases |
| 22:35 | <Philip`> | Was that meant to be a pun? :-p |
| 22:35 | <a-ja> | w/ border bg images, too, still? <haven't tried lately) |
| 22:35 | <a-ja> | heh |
| 22:36 | a-ja | groans |
| 22:38 | <a-ja> | well....tks for the info, folks.....later |
| 22:38 | <a-ja> | keep up the good work! |
| 22:39 | <zcorpan> | Philip`: it wasn't :) |