| 03:38 | <Hixie> | aa: ping |
| 03:39 | <Hixie> | aa: the second example in http://code.google.com/p/google-gears/wiki/HigherLevelDatabaseAPI uses |row| without declaring it |
| 04:03 | <othermaciej> | Hixie: presumably the intent is var row = rows[i] inside the loop |
| 04:06 | <Hixie> | i assume so, yeah |
| 04:08 | <othermaciej> | Hixie: I think it would be better to use a pseudo-array for the rows instead of a literal JS array, and especially so for the object representing an individual result row |
| 04:08 | <Hixie> | but we want it to inherit whatever is on the Array prototype |
| 04:09 | <othermaciej> | most functions on the Array prototype are generic, so it's possible to require inheriting them without requiring being an array |
| 04:09 | <Hixie> | sounds complex |
| 04:10 | <othermaciej> | ("generic" in the sense that they are required to work on any JS object that has numeric properties and a property named "length") |
| 04:10 | <othermaciej> | (by ECMAScript) |
| 04:10 | <Hixie> | other than increasing the complexity of the spec, what is gained by making it not an object? |
| 04:10 | <Hixie> | er |
| 04:10 | <Hixie> | not an Array |
| 04:11 | <othermaciej> | it's harder to do lazy computation tricks while literally subclassing JS array, and it's not clear if the few non-generic Array methods are desired here |
| 04:11 | <othermaciej> | in any case, it's more obvious to me for the objects representing a row, since you want both named and indexed access |
| 04:11 | <Hixie> | the objects representing the row are just Object elements |
| 04:11 | <Hixie> | er |
| 04:11 | <Hixie> | Object objects |
| 04:11 | <Hixie> | as it were |
| 04:12 | <othermaciej> | yes, I know |
| 04:12 | <othermaciej> | that leaves out any way to do index-based operations |
| 04:12 | <Hixie> | just enumerate them |
| 04:12 | <othermaciej> | (thought if they chose to implementations could still do lazy computation for the properties) |
| 04:12 | <Hixie> | for (field in row) { ... } |
| 04:13 | <othermaciej> | for..in loops are somewhat inefficient in JS, and while you can do similar things to forEach, filter and map, being able to use functional programming style directly can be handy |
| 04:13 | <Hixie> | i guess we can make them custom objects implementing interfaces specific for this case, but that basically just makes the spec complicated without an obvious gain as far as i can tell |
| 04:14 | <Hixie> | i don't really see what the use case is for non-named access to the fields |
| 04:16 | <Hixie> | (debugging being the exception, but it's not like performance is a high priority there) |
| 04:27 | <othermaciej> | indexed access is likely to be higher-performance than named access, even in a non-looping context |
| 04:28 | <othermaciej> | though probably harder to read, if you just did that directly |
| 04:28 | <othermaciej> | FWIW in WebKit we'd probably implement it as a custom object subclass anyway, if only to make conversion from SQLite API data types to JS types lazy |
| 04:29 | <othermaciej> | at which point is seems gratuitous not to offer indexed as well as named access |
| 04:30 | <Hixie> | i'd expect it to be implemented as a subclass, yes |
| 04:30 | <Hixie> | i can make the object have non-enumerable numeric properties |
| 04:31 | <Hixie> | but i don't want to give it a "length" property |
| 04:31 | <Hixie> | or any other named properties for that matter (like namedItem()) |
| 04:31 | <Hixie> | since anything i add here is a column name you can't use |
| 04:33 | <othermaciej> | well, it would be a column name that it would be inconvenient to use, at the very least (since you could always use function accessors for such a column, if there were a complete set) |
| 04:34 | <Hixie> | that would be really confusing |
| 04:34 | <othermaciej> | non-enumerable numeric properties are somewhat less valuable without "length", since you can't use any array functions |
| 04:34 | <Hixie> | i agree |
| 04:34 | <Hixie> | but "length" seems like something you'd want to call a column relatively often |
| 04:34 | <othermaciej> | but it does seem like "length" might be a likely column name |
| 04:35 | <Hixie> | we could put the number of fields on SQLResultSet, though that doesn't help you use generic methods |
| 04:35 | <othermaciej> | I guess I'm sort of convinced that it's better not to have a special interface |
| 04:36 | <Hixie> | it's a weird set of constraints |
| 04:36 | <Hixie> | i don't really know how best to handle it |
| 04:36 | <othermaciej> | it looks like the only array methods that are not rebindable are toString and toLocaleString |
| 04:37 | <othermaciej> | so if you override those it's possible to inherit the array prototype without inheriting from the Array implementation is the "class" sense |
| 04:37 | <othermaciej> | (that's in reference to the rows array) |
| 04:38 | <Hixie> | is that preferable to just implementing an Array internally? |
| 04:38 | <Hixie> | it's distinguishable at the JS level, so it's not like the spec can punt on this |
| 04:39 | Hixie | notes that having a variadic set of arguments on sqlExecute in the _middle_ of the arguments list is probably going to cause issues in non-JS languages |
| 04:39 | <Hixie> | but you really want the callback at the end |
| 04:39 | <Hixie> | maybe we should always require the array syntax |
| 04:39 | <Hixie> | executeSql(['sql', arguments...], callback) |
| 04:39 | <Hixie> | no wait |
| 04:39 | <Hixie> | it would be |
| 04:39 | <Hixie> | executeSql([['sql', arguments...]], callback) |
| 04:39 | <Hixie> | boy is that ugly |
| 04:39 | <othermaciej> | yeah |
| 04:40 | <othermaciej> | non-JS languages could certainly implement only the array version |
| 04:40 | <othermaciej> | you can't really express the other version well in the type system of any statically typed language |
| 04:41 | <Hixie> | not without a buttload of overloads, no |
| 04:42 | <othermaciej> | how is it distinguishable at the JS level whether you subclass Array or just have its prototype in your prototype chain? |
| 04:42 | <Hixie> | well if it's not, it doesn't matter what the spec says |
| 04:43 | <Hixie> | but as far as I can tell, an Array doesn't have a prototype chain |
| 04:43 | <Hixie> | so you could distinguish by checking to see if it had one |
| 04:44 | <othermaciej> | an Array instance does have a prototype chain |
| 04:44 | <othermaciej> | however anything that was either a subclass of Array or for other reasons had a prototype chain that included Array's prototype would have a longer prototype chain |
| 04:45 | <othermaciej> | your spec, if read literally, would possibly rule out a custom subclass of Array |
| 04:45 | <Hixie> | why? |
| 04:45 | <othermaciej> | since it says "must return a native array of objects" |
| 04:45 | <othermaciej> | assuming you mean "native" in the sense of the ECMAScript spec |
| 04:46 | <Hixie> | you can implement a native array however you like |
| 04:46 | <Hixie> | it does disallow a different prototype chain length, though, yes |
| 04:46 | <Hixie> | (var x = new Array(); x.__prototype__; returns 'undefined' in mozilla.) |
| 04:47 | <othermaciej> | I think the property is named __proto__ |
| 04:47 | <Hixie> | ah |
| 04:47 | Hixie | checks that |
| 04:48 | <Hixie> | var x = new Array(); x.__proto__ == Array.prototype; returns true |
| 04:48 | <Hixie> | so yes |
| 04:48 | <othermaciej> | so anyway that constraint seems of marginal value to JS coders and would make it hard to implement as a custom Array subclass in at least Gecko and WebKit afaik |
| 04:49 | <othermaciej> | (probably not impossible, but shouldn't simplicity of implementation trump simplicity of the spec?) |
| 04:49 | <Hixie> | yes it should |
| 04:49 | <Hixie> | so what would you want it to say? |
| 04:50 | <othermaciej> | I'm not sure |
| 04:50 | <othermaciej> | another issue with Array is that it has to allow adding arbitrary array properties and those must be reflected in "length" and in behavior of the array methods |
| 04:50 | <othermaciej> | which would make a completely custom implementation that used a different backing store even harder |
| 04:51 | <Hixie> | yeah i'd be ok with making it immutable |
| 04:51 | <Hixie> | so you'd want something that had a length and an item() method? |
| 04:51 | <Hixie> | we really need a way to make these objects enumerable in JS |
| 04:51 | <Hixie> | same problem with NodeList, et al |
| 04:52 | <othermaciej> | yes, NodeList's non-arrayness is inconvenient |
| 04:53 | <othermaciej> | thinking... |
| 04:53 | <othermaciej> | I think giving the row list item(), a read-only length, indexed access via array syntax, and requiring that it have all normal methods of Array would make implementation not too hard and would give JS coders all they need |
| 04:54 | <othermaciej> | similar requirements could be placed on NodeList et al for convenience |
| 04:54 | <othermaciej> | the downside is you couldn't use any of the mutating array methods usefully since they all modify length |
| 04:54 | <othermaciej> | maybe it is better not to have them than to have non-working versions |
| 04:54 | <Hixie> | yeah i'm not sure how to require that though |
| 04:56 | <Hixie> | i'm really not sure how to handle errors with the array form of executeSql |
| 04:56 | Hixie | doesn't really want to add it |
| 04:56 | <othermaciej> | "all methods available on Array instances except those that may modify any property of the array |
| 04:56 | <othermaciej> | Hixie: the form that lets you pass an array of statements? |
| 04:56 | <Hixie> | yeah |
| 04:56 | <othermaciej> | it doesn't seem super essential |
| 04:57 | <othermaciej> | but you could say in case of error the callback is delivered after the first error, with only as the ResultSets for the successful statements up to the first failing one, plus the first failing one |
| 06:10 | <othermaciej> | Hixie: should I send my comments about the "native array" requirement to the list? (you've explained away my concerns about the row objects themselves) |
| 09:09 | <Lachy> | Hixie, yt? |
| 09:09 | <Lachy> | what's the point of the version parameter in the openDatabase() function? |
| 09:18 | <Hixie> | Lachy: lets you ensure the database is using the schema you expect |
| 09:21 | <Hixie> | othermaciej: yeah, send mail, in case i forget |
| 09:48 | <Lachy> | ok, so authors can check the version number and then, if necessary, run some ALTER TABLE queries or whatever to upgrade to the right schema |
| 09:49 | <Hixie> | yeah |
| 09:49 | <Hixie> | and if they do that while any other pages are using the db |
| 09:49 | <Hixie> | those pages will start raising exceptions instead of corrupting the database |
| 09:50 | <othermaciej> | Hixie: another possible coment I had was that maybe version should be an integer and only be allowed to go up, but I'm not really sure if that's better |
| 09:52 | <othermaciej> | actually I think it is good |
| 09:52 | <othermaciej> | since there is no atomic test-and-set of the version, there is no way right now to tell if you are overwriting a newer version with an older one |
| 09:52 | <Hixie> | seems to artificially impose a constrain on the developer |
| 09:53 | <Hixie> | we could add an atomic change |
| 09:54 | <othermaciej> | it would have to be atomic test-and-set and you'd need to pass all versions you know how to upgrade |
| 09:54 | <Hixie> | database.changeVersion(oldVersion, newVersion) -> bool (true if changed, false if old version didn't match) |
| 09:54 | <Hixie> | no just get the old version, check that you like it and can upgrade it, and if you can call db.changeVersion(oldVersion, '1.4'); |
| 09:55 | <Hixie> | it |
| 09:55 | <Hixie> | it's not like it's gonna change frequently |
| 09:55 | <othermaciej> | I guess you'd have to possibly loop in case of partial upgrade in between |
| 09:55 | <Hixie> | the only clash you're likely to get is that the update was done for you |
| 09:55 | <othermaciej> | true, it's kind of an edge case |
| 09:56 | <othermaciej> | but it is nice to have a design that at least can possibly work in the odd case that you end up running v1, v2 and v3 schema code all at once |
| 09:57 | <othermaciej> | another issue - should you bump the version before or after the upgrade transaction? |
| 09:57 | <othermaciej> | seems like it has to be done as part of an exclusive transaction |
| 09:58 | <Hixie> | i'd bump it twice |
| 09:58 | <othermaciej> | but the version itself is not subject to the exclusive access lock |
| 09:58 | <Hixie> | once to a temporary "upgrading" version, and once to the final version |
| 09:58 | <othermaciej> | makes sense |
| 09:58 | <Hixie> | and do all the changes in one transaction |
| 09:58 | <othermaciej> | you could bump to upgrading before the upgrade transaction, and to the final inside the transaction at the very end |
| 09:59 | <othermaciej> | (inside the transaction you'd have to retest that it's still the expected upgrading value) |
| 09:59 | <Hixie> | and if you find the version is in an "upgrading" stage, you could wait a few seconds and if it doesn't change offer the user to "fix the corruption" somehow |
| 10:00 | <Hixie> | i was originally considering just extending SQL to have a SET VERSION statement |
| 10:00 | <Hixie> | but that seemed more trouble than it's worth |
| 10:03 | <othermaciej> | it would certainly solve the atomic test and set problem (indeed, atomic test old version, perform upgrade and set new version) |
| 10:03 | <Hixie> | yeah |
| 10:03 | <Hixie> | it would also solve the problem of the db being in an inconsistent state |
| 10:04 | <Hixie> | as you'd be able to set the version in the same transaction as the changes |
| 10:04 | <Hixie> | and so a rollback would roll everything back |
| 10:04 | <othermaciej> | it's hard to do better than only being able to change version inside a transaction |
| 10:04 | <Hixie> | yeah |
| 10:04 | <Hixie> | but i fear it puts too much burden on the implementors |
| 10:04 | <Hixie> | they'd all have to hack sqlite to do it |
| 10:05 | <othermaciej> | or use a dedicated table with a reserved name |
| 10:07 | <Hixie> | that's rather heavy-weight |
| 10:07 | <Hixie> | and you have to do things like prevent it from being dropped, etc |
| 10:08 | <Lachy> | the biggest problem I see will be that different UAs will use different DBs on the backend. Mozilla and Safari will probably use SQLLite, but IE will probably use some MS database, and there will be differences in the supported SQL features |
| 10:10 | <Hixie> | we'll have to define the sql subset before the latter happens |
| 10:10 | <othermaciej> | at some point the query language has to be specced |
| 10:11 | <Lachy> | yeah, add SQL5 to your todo list :-) |
| 10:12 | <othermaciej> | some relatively easilly defined subset of SQL92 might be sufficient |
| 10:12 | <Hixie> | i'll have to get a copy of SQL9x |
| 10:13 | <Lachy> | why not SQL:2006 or at least 2003? |
| 10:13 | <Hixie> | i've updated the spec to have a locking changeVersion() |
| 10:13 | <Hixie> | Lachy: whichever is latest is fine by me. i haven't been able to find _any_ version of that spec. |
| 10:13 | <Lachy> | SQL 2006 is ISO/IEC 9075-14:2006 (according to wikipedia) |
| 10:14 | <Hixie> | yeah |
| 10:14 | <Hixie> | ISO specs aren't free |
| 10:14 | <hsivonen> | is SQL one of those standards that are kept secret in Geneva? |
| 10:14 | <Lachy> | http://en.wikipedia.org/wiki/SQL#Standardization |
| 10:14 | <Hixie> | othermaciej: the only issue really with changeVersion() now, afaict, is that if the script somehow dies without setting the version properly, the db can be left in a messy state |
| 10:14 | <Hixie> | othermaciej: but that could happen whatever do, really |
| 10:14 | <hsivonen> | whoa. they've added XML to SQL |
| 10:16 | <Lachy> | Do ISO specs require interop before becoming standards? |
| 10:16 | <othermaciej> | Hixie: well, atomic commit/rollback would reduce the likelihood if the version change were part of the transaction |
| 10:16 | <othermaciej> | Lachy: I do not believe so, as a general rule |
| 10:16 | <othermaciej> | I don't think they even require op, let alone interop |
| 10:17 | <othermaciej> | but I think individual technical committees can set their own rules |
| 10:17 | <othermaciej> | obviously SQL needs to be fully AJAX compliant |
| 10:21 | <Lachy> | Hixie, I think there may be a problem with the way .insertId is defined. |
| 10:21 | <othermaciej> | mapping from SQL types to JS types will also need defining at some point |
| 10:21 | <Lachy> | it says "If the statement inserted multiple rows, the ID of the last row must be the one returned" |
| 10:21 | <othermaciej> | not sure how many non-obvious cases there will be |
| 10:22 | <Lachy> | but I was reading in the MySQL docs that the LAST_INSERT_ID returns the id of the first row |
| 10:22 | <Lachy> | (I know it's unintuitive, but the MySQL docs said there was a reason for it) |
| 10:28 | <Hixie> | Lachy: what does sqlite do? |
| 10:29 | <Hixie> | othermaciej: yeah, a transaction would make it easier to do the right thing, but i doubt that would actually result in many more cases of the right thing. ;-) |
| 10:30 | <Lachy> | Hixie, I tried looking for that, but the sqllite docs were very unclear |
| 10:30 | <annevk> | see http://nl.php.net/manual/en/function.sqlite-last-insert-rowid.php |
| 10:30 | <annevk> | for some reason I'm on wanadoo and freenode, this can't last long |
| 10:30 | <othermaciej> | Hixie: I'll try to get you implementation feedback on the versioning thing |
| 10:30 | <Hixie> | othermaciej: k |
| 10:31 | <Hixie> | othermaciej: in the meantime, we have a readonly version and a method changeVersion(old, new) |
| 10:31 | <othermaciej> | (and the rest of it) |
| 11:08 | <hsivonen> | weird. when Gecko adds Zapfino ligature support, WebKit regresses it |
| 11:48 | <othermaciej> | did WebKit ever have it? |
| 11:48 | <othermaciej> | as far as I know, our fast code path never supported ligatures or other contextual forms |
| 11:48 | <othermaciej> | but the code paths that require shaping do |
| 12:54 | <hsivonen> | othermaciej: http://weblogs.mozillazine.org/roc/archives/2007/09/textalicious.html look different (better) in Safari 2.0.4 than it does in the latest WebKit nightly |
| 12:54 | <hsivonen> | s/look/looks/ |
| 12:57 | <hsivonen> | with a dualcore CPU, I'd like to get my share of the shaping eyecandy for English as well. |
| 13:15 | <Philip`> | executeSql('sql', arguments).addCallback(callback) |
| 13:17 | <Philip`> | (to avoid callback argument after varargs) |
| 13:17 | <Philip`> | or steal more from Twisted and have |
| 13:17 | <Philip`> | executeSql('sql', arguments).addCallback( function (res) { return executeSql('sql2', res.rows[0].id) } |
| 13:17 | <Philip`> | ).addCallback( function (res) { alert('Okay') } |
| 13:17 | <Philip`> | ).addErrback( function (err) { alert('Oops') } |
| 13:17 | <Philip`> | ) |
| 13:17 | Philip` | wonders why he keeps losing newlines when pasting into IRC |
| 16:48 | <Philip`> | Argh, it's harder doing APNG tests now that I've got one which segfaults Opera |
| 16:52 | <virtuelv> | Philip`: file a bug, please |
| 16:52 | <virtuelv> | (I know you will, but I'd be interested in knowing the bug number) |
| 16:55 | <Philip`> | virtuelv: 287173 |
| 16:56 | <virtuelv> | ty |
| 16:56 | Philip` | removes it from his test-case page for now |
| 17:03 | <virtuelv> | Philip`: out of curiosity: Which tools do you use for APNG? |
| 17:04 | <Philip`> | Perl :-) |
| 17:05 | <Philip`> | at least for creating APNG test cases |
| 17:06 | <Philip`> | I used the Firefox APNG Editor extension for http://philip.html5.org/demos/apng/sierpinski.png (with canvas code to draw each frame) |
| 17:24 | <othermaciej> | hsivonen: always using shaping APIs can cause overall page loading (not just text drawing) to be 20-25% slower |
| 17:26 | <othermaciej> | hsivonen: we haven't yet come up with a way to do contextual forms as fast as we do normal latin text, but we're certainly thinking about it |
| 17:49 | <Philip`> | http://philip.html5.org/tests/apng/ - now with more tests |
| 17:49 | <Philip`> | I think my use of the alt attribute is non-conforming, but I'm not terribly concerned about how this page works in non-graphical UAs |
| 18:18 | <zcorpan> | Philip`: things like alt="FAIL" is ok for test cases :) |
| 18:19 | <zcorpan> | test cases don't need to comply with document conformance criteria from the specs they are using or testing |
| 19:57 | <Hixie> | Philip`: your .addCallback() idea would i'm sure result in people taking a reference to that object and then doing really evil things with it |
| 19:59 | <Hixie> | <Hixie> Philip`: your .addCallback() idea would i'm sure result in people taking a reference to that object and then doing really evil things with it |
| 20:05 | <Philip`_> | In Twisted, the asynchronous methods return a Deferred (which indicates either a result or a soon-to-be-a-result), and you can keep it forever and do addCallback whenever, and the callback is either called immediately (if the Deferred has the result already) or later (when the result becomes available) |
| 20:05 | <Philip`_> | so there's not really anything evil you can do with the object |
| 20:06 | <Hixie> | you can keep the transaction open forever |
| 20:07 | <Hixie> | e.g. if you don't add a callback it'll never close |
| 20:07 | <Philip`_> | I guess it's harder in JavaScript since GC isn't immediate, so you'd have to keep all the result data just in case someone's still got a reference to the deferred result |
| 20:07 | <Philip`_> | Ah, transactions sound harder too :-) |
| 20:08 | <Hixie> | i like the api concept though |
| 22:27 | <Hixie> | any preference as to which object the app cache api is on? |
| 22:27 | <Hixie> | window? window.navigator? |
| 22:28 | <Hixie> | window.cache? |
| 22:30 | <virtuelv> | isn't the window.navigator object already overloaded with all kinds of crap? |
| 22:30 | <Hixie> | yup |
| 22:30 | <Hixie> | so's window |
| 22:30 | <virtuelv> | heh, yeah |
| 22:31 | <virtuelv> | window.cache sounds more descriptive |
| 22:31 | <Hixie> | but it adds yet another singleton |
| 22:31 | <Hixie> | which is expensive |
| 22:44 | <Hixie> | this is, in a nutshell, the misunderstanding that the pro-required-alt camp is stumbling upon, i think: |
| 22:44 | <Hixie> | "The issue is not to do so much with what the AT UA can do with an image |
| 22:44 | <Hixie> | without the alt attribute, it is about what the UA cannot do. |
| 22:44 | <Hixie> | -- http://html4all.org/pipermail/list_html4all.org/2007-September/000401.html |
| 22:45 | <Hixie> | It cannot reliably differentiate between an important image without an alt |
| 22:45 | <Hixie> | attribute and an unimportant image." |
| 22:45 | <Hixie> | (the problem being that _regardless_ of what the spec says, a UA cannot _reliably_ differentiate between an important image and an unimportant image) |
| 22:46 | <Hixie> | (as henri later points out in http://html4all.org/pipermail/list_html4all.org/2007-September/000409.html) |
| 22:50 | <Hixie> | wow that thread is sad |
| 22:50 | <Hixie> | henri explains the problem: http://html4all.org/pipermail/list_html4all.org/2007-September/000409.html |
| 22:50 | <Hixie> | steven completely blanks on understanding it: http://html4all.org/pipermail/list_html4all.org/2007-September/000410.html |
| 22:50 | <Hixie> | henri explains it again: http://html4all.org/pipermail/list_html4all.org/2007-September/000411.html |
| 22:51 | <Hixie> | steven doesn't even reply: http://html4all.org/pipermail/list_html4all.org/2007-September/000412.html |
| 22:51 | <Hixie> | good lord |
| 22:52 | <kingryan> | good lord indeed |
| 22:53 | kingryan | gave up awhile ago |
| 22:56 | <Hixie> | one reason to use window.navigator is that window.navigator.onLine is already there |
| 22:57 | <Philip`> | http://html4all.org/pipermail/list_html4all.org/2007-September/000416.html - "Moved to the public list" - aha, it does sound like they have a new private list for the cabal |
| 22:57 | <Hixie> | HAHAHAHAHA |
| 22:57 | <Hixie> | i totally missed that |
| 22:57 | <Hixie> | that's awesome |
| 23:04 | <gsnedders> | html4all? |
| 23:06 | <Philip`> | I guess they worked out how to turn on the non-public flag this time |
| 23:07 | <tndH> | i read that as "Moved [from private email]", but i guess i'm not paraniod enough... |
| 23:07 | <Philip`> | (Note to whoever's reading logs: I think the old public archives mentioned the list admin password at some point - you should probably make sure it's been changed) |
| 23:08 | <Philip`> | ((This is a much easier way of communicating than email)) |
| 23:10 | <gsnedders> | Philip`: especially as it allows us to be quoted without context while quoting a whole response |
| 23:10 | <Dashiva> | Hi mom! |
| 23:10 | Dashiva | waves |
| 23:10 | gsnedders | realises what Dashiva is on about |
| 23:12 | <Dashiva> | Hoo boy: "why not develop a validator that looks for and fails the page if it has bogus alt? using heauristics, that shouldn't be so hard should it?" |
| 23:13 | <Hixie> | it baffles me how much they can miss the point |
| 23:14 | <Philip`> | tndH: If it was, why would he explicitly say "the public list" instead of "the list"? |
| 23:15 | <tndH> | point. :) |
| 23:15 | <Philip`> | Paranoia is more fun anyway, even if it's wrong - they can always correct us easily by saying there's only that one list :-) |
| 23:16 | <Hixie> | i'm sure they'll cc us and their private list soon enough |
| 23:17 | <Dashiva> | Philip`: Paranoia would suggest it was a cover-up |
| 23:22 | <Philip`> | Like with our secret invite-only IRC channel? |
| 23:30 | <Hixie> | ok i still don't have a good answer as to what we do with <?xml-stylesheet?>s and offline app caches |
| 23:30 | <Hixie> | since they come before the application="" is seen |
| 23:36 | <Philip`> | If it ought to come before everything, there's <!DOCTYPE html PUBLIC "application" "foo"> |
| 23:36 | <Philip`> | (That is probably not a serious suggestion) |
| 23:37 | <Hixie> | heh |
| 23:37 | <Hixie> | that would be _hi_larious |
| 23:37 | <Dashiva> | You mean mlarious |
| 23:37 | <Hixie> | "hi everyone, we're co-opting the DOCTYPE tag, hope y'all are ok with that" |
| 23:38 | <Hixie> | it might even take attention away from the alt text stuff! |
| 23:38 | <Dashiva> | Look over there, a <div>ersion! |
| 23:44 | <Philip`> | http://html4all.org/pipermail/list_html4all.org/2007-September/000415.html - it doesn't even need to be handled by the browser - just create a font with ligatures for sequences of characters like "color" so it gets rendered as "colour" |
| 23:47 | <Hixie> | it needs markup-level support because you'd need to do context-sensitive substitution in all but the most trivial of cases |
| 23:59 | Philip` | wonders what "Content-Type: image/jpeg; charset=utf-8" means |
