| 01:53 | <Hixie> | hsivonen: off hand i think we can allow name="" on <map> if we think it's worth it. i think people have requested it before. |
| 06:27 | <Hixie> | one of the 300 new features in leopard seems remarkably useless |
| 06:27 | <Hixie> | an on-screen braille display. |
| 06:28 | <othermaciej> | the VoiceOver team wants everything made available through assistive technologies to also be on screen, for the sake of collaboration |
| 06:32 | <Hixie> | i also like "support for open standards popular in the UNIX community such as the OASIS Open Document Format (ODF) or ECMA’s Office XML" |
| 06:32 | <Hixie> | whoever wrote this document has a highly tuned sense of humour |
| 06:32 | <othermaciej> | marketing? sense of humor? |
| 06:34 | <Hixie> | calling OOXML a standard "popular in the UNIX community" is funny :-P |
| 06:34 | <Hixie> | marketing or not :-P |
| 06:37 | <Hixie> | the tag is floating this idea of starting a subgroup to decide the semantics of http |
| 06:37 | Hixie | wonders why that isn't the httpwg's job |
| 06:41 | <othermaciej> | why does http need semantics? |
| 06:41 | <othermaciej> | I thought it was a network protocol |
| 06:41 | <Hixie> | i didn't ask |
| 06:41 | <othermaciej> | are they going to define the semantics of TCP next? |
| 06:41 | <Hixie> | it seemed unwise to step into that discussion |
| 06:42 | <othermaciej> | maybe we should replace TCP with RDF triples sent over IP |
| 06:42 | <hober> | ethernet-over-RDF-triples |
| 06:42 | <Hixie> | i'm guessing it is indeed related to the SEMANTIC WEB though |
| 06:42 | <Hixie> | oh wait, it's Semantic Web |
| 06:49 | <othermaciej> | I like the use of all caps |
| 06:52 | <hober> | We could call some kind of pragmatic compromise between the RDF folk and the real world "the title-cased Semantic Web" |
| 06:54 | <Hixie> | holy crap |
| 06:54 | <Hixie> | microsoft actually did something to support html5 |
| 06:54 | <Hixie> | http://www.consortiuminfo.org/standardsblog/article.php?story=20071016092352827 |
| 06:55 | <Hixie> | (see in particular the seventh paragraph) |
| 06:59 | <jruderman> | causing that group to "grind to a halt" helps html5? |
| 07:00 | <Hixie> | read the seventh paragraph |
| 07:01 | <jruderman> | the one that starts with |
| 07:01 | <jruderman> | The result is that a very important committee has, in the words of its Secretariat Manager in frequent pleas to the non-responsive members, "ground to a halt." |
| 07:01 | <jruderman> | ? |
| 07:01 | <Hixie> | yes |
| 07:01 | <Hixie> | second sentence |
| 07:01 | <Hixie> | specifically, the listed specs |
| 07:02 | <jruderman> | 'The impact is significant, since this is the committee that controls standards such as RELAX NG (ISO/IEC 19757 Part 2), Schematron (ISO/IEC 19757 Part 3) and Topic Maps (ISO/IEC 13250) – not to mention ODF and PDF (if will be interesting to see if participation increases when Microsoft's PDF-competing XML Paper Specification advances to SC 34 from Ecma, where it is currently in preparation).' |
| 07:02 | <Hixie> | yeah |
| 07:02 | <Hixie> | microsoft have managed to do what i've never been able to even work out how to do |
| 07:02 | <Hixie> | kill relaxng and schematron :-P |
| 07:02 | <Hixie> | not to mention odf and pdf :-P |
| 07:02 | <jruderman> | ahh |
| 07:02 | <jruderman> | hehe |
| 07:03 | <Hixie> | seriously though, it's amazing how microsoft can screw things up |
| 07:03 | <Hixie> | i'm really glad we have the html5 work structured in a way that they can't do that |
| 07:07 | <hsivonen> | Hixie: have you tried to work out how to kill RELAX NG and Schematron? :-) |
| 07:07 | <hsivonen> | occasionally, conformance requirements may look like an attempt :-) |
| 07:07 | <Hixie> | uh... no comment! |
| 07:07 | Hixie | hides |
| 07:08 | <karlUshi> | back |
| 07:08 | <karlUshi> | network trouble |
| 08:15 | <hsivonen> | html5.validator.nu now does ASCII case-insensitive comparisons for enumerated attribute values |
| 08:15 | <hsivonen> | Hixie: your blog front page uses size='' on <input> but you deprecated it in WF2 :-) |
| 08:16 | <hsivonen> | Hixie: isn't your blog a use case? |
| 08:22 | <Hixie> | hsivonen: it has to do so to validate, iirc |
| 08:22 | <Hixie> | or there was something along those lines |
| 08:23 | <Hixie> | or maybe that's the rows= on textarea |
| 08:23 | <Hixie> | i dunno, i wrote my blog software over half a decade ago :-P |
| 08:43 | <Hixie> | is Brady Eidson here? |
| 09:20 | <hsivonen> | I have to wonder if RFC 4646 precision in language tagging is actully useful on the Web... |
| 09:22 | <Hixie> | othermaciej: so the real question is what API do we do first -- because if we're ever going to have a non-transaction API, we should work out what we want the names to look like today |
| 09:22 | <Hixie> | so we don't paint ourselves into a corner |
| 09:23 | <othermaciej> | Hixie: what would be nice is if the no-transcation version could have the decorated name, so that we could be confident it could be added later without insanity |
| 09:30 | <othermaciej> | if you had both and wanted short names I'd suggest startTransaction and execute |
| 09:30 | <othermaciej> | or startSqlTransaction / executeSql |
| 09:30 | <othermaciej> | (well, relatively short names) |
| 09:37 | <othermaciej> | Hixie: I think the big remaining issue with changeVersion is that you really want a version change to be done atomically with the schema upgrade transaction |
| 09:38 | <othermaciej> | Hixie: I do not think there is a way to use the current API to do that |
| 09:39 | <othermaciej> | Hixie: if changeVersion opened a transaction and let you do the schema upgrade from the callback, with the version change rolled back if the transaction fails, that would work |
| 09:39 | <othermaciej> | I guess I should email that |
| 09:53 | <Hixie> | othermaciej: i just figured people would change the version from 1.0 to 2.0-updating, do the update, then change it to 2.0 |
| 09:53 | <othermaciej> | Hixie: yeah but it's unnecessary to expose the intermediate state, and I believe fixing the issue is not particularly difficult implementation-wise |
| 09:54 | <Hixie> | othermaciej: (i was trying to avoid making the changeVersion() stuff integrate too closely with the sql stuff to avoid making it hard to implement without changes to, e.g., sqlite) |
| 09:54 | <Hixie> | yeah |
| 09:55 | <othermaciej> | it's likely the version will be stored in a sqlite table anyway |
| 09:55 | <Hixie> | i guess |
| 09:56 | <othermaciej> | it just needs to not be exposed to user sql code |
| 09:56 | <Hixie> | the main reason i don't like startSqlTransaction() btw is that it looks unbalanced -- it does the same as executeSql() and has the same arguments but uses a different name |
| 09:56 | <othermaciej> | although honestly if it was, you could do things like atomic test-and-set on the version as part of your upgrade |
| 09:56 | <Hixie> | well the easiest from the author point of view is extending SQL to have version-related statements |
| 09:56 | <Hixie> | but i really don't want to do that |
| 09:57 | <Hixie> | we _could_ just define a table |
| 09:57 | <othermaciej> | it doesn't need that, just a reserved table name |
| 09:57 | <Hixie> | but that would get us into issues like schema descriptions and types |
| 09:57 | <Hixie> | which is an area i _really_ want to avoid for now |
| 09:57 | <Hixie> | at least until we have interop with two implementations |
| 09:57 | <othermaciej> | with a reserved column for the version |
| 09:57 | <othermaciej> | I will ask my co-workers tomorrow what they think |
| 09:57 | <Hixie> | k |
| 09:59 | <othermaciej> | startTransaction() or openTransaction() could be paired with executeSingleStatement(), but then you make that name annoyingly long |
| 09:59 | <othermaciej> | if the names get longer I'd suggest taking sql out and maybe renaming Database to SQLDatabase or something |
| 09:59 | <othermaciej> | I wouldn't expect non-SQL access to the same database to be a super likely prospect |
| 10:19 | <Hixie> | yeah |
| 10:19 | <Hixie> | i dunno, i like executeSql() as it is |
| 10:19 | <Hixie> | i'm not sure i'm convinced we want a non-transaction version |
| 10:19 | <Hixie> | but transactions do cause issues, especially the lock contention / rollback issue |
| 10:20 | <Hixie> | which i'm not sure authors will handle well |
| 10:25 | <Hixie> | if ES4 gets generators (and thus continuations) i wonder if people will (ab)use those to turn async APIs into sync APIs |
| 10:26 | <Hixie> | interesting. aaron says you actually get performance _boosts_ from implicit transactions in the real world |
| 10:33 | <hsivonen> | http://www1.ietf.org/mail-archive/web/ltru/current/msg05589.html |
| 10:34 | <hsivonen> | I imagine I can give better error messages, if I keep polishing my Java code instead of doing the one-stop "regexp didn't match" thing |
| 10:36 | <Hixie> | i expect you will end up spending as much time polishing error codes (and making changes to accommodate better reporting) as you do doing everything else put together, on the long term |
| 10:36 | <Hixie> | getting ui right is hard |
| 10:37 | <hsivonen> | Hixie: yeah. |
| 10:38 | <hsivonen> | Hixie: however, I think I can go for cases that casual authors care the most about |
| 10:39 | <hsivonen> | Hixie: for example, I think I'm going to let errors related to the content models of ins and del suck for the foreseeable future |
| 10:40 | <hsivonen> | anyway, I'm going to have to hack Jing soonish |
| 10:41 | <Hixie> | my recommendation once you get to the stage of worrying about error messages is just to instrument your code to log which error messages get reported the most |
| 10:41 | <Hixie> | and start at the top of that pile with the most reported message |
| 10:41 | <hsivonen> | RFC 4646 has all sort of weird internal dependencies: like so subtags are allowed or disallowed based on earlier subtags... |
| 10:41 | <hsivonen> | Hixie: makes sense |
| 10:42 | <Hixie> | for each message: split the message up to be more precise about the exact problem instead of using generic messages; if it's not a generic message, make the message more detailed, with examples and (most important!) instructions on the best way to fix the problem, ideally using the actual author code as a guide |
| 10:42 | <hsivonen> | Hixie: my wild guess is that errors related to old-style internal encoding declaration and to the content model of <div> end up at the top of the pile |
| 10:44 | <Hixie> | yeah |
| 10:44 | <hsivonen> | Hixie: to be honest, it seems to me that banning old-style internal encoding decls is theoretical purity and not solving a problem |
| 10:46 | <Hixie> | it's not theoretical, it's aesthetic |
| 10:46 | <Hixie> | but i agree entirely that it's not solving a problem |
| 10:48 | <Hixie> | changing the DOCTYPE from <!DOCTYPE ...html4...> to <!DOCTYPE HTML> doesn't "solve a problem" either |
| 10:53 | <hsivonen> | Hixie: only if you don't consider the need of obvious failure in old validators a problem that needs solving |
| 10:57 | <Hixie> | ok, refusing doctypes like <!DOCTYPE HTML "bogus"> |
| 10:58 | <Hixie> | there are a number of things that the spec requires that are basically just aethetic |
| 10:58 | <Hixie> | especially now that we have well-defined error handling |
| 10:58 | <Hixie> | anyway |
| 10:58 | <Hixie> | long past sleep time |
| 10:58 | <Hixie> | nn |
| 11:45 | <hsivonen> | "The script subtags 'Qaaa' through 'Qabx' are reserved for private use in language tags." |
| 11:45 | <hsivonen> | joy. RFC 4646 has magic values as well as x- for indicating private use |
| 20:42 | <hober> | "Which means the *last* thing one should use as a yardstick by which to determine inclusion in a standard, is whether it has been adopted by one or other browser vendor!" |
| 20:43 | <hober> | I feel like I'm stuck in an episode of Sliders, and am mixing up our world's htmlwg mailing list with some kind of parallel universe's list |
| 22:01 | <Dashiva> | hober: Which mailing list, which mail? |
| 22:03 | <hober> | http://lists.w3.org/Archives/Public/public-html/2007Oct/0203.html |
| 22:03 | <Dashiva> | ah |
| 22:56 | jgraham_ | nominates hober for QOTW |