00:07
<Hixie>
what's UCT if it's not UTC?
00:12
<jacobolus>
wikipedia has no ideas other than university of cape town
08:08
<Hixie>
well crap
08:08
<Hixie>
good api design includes keeping arguments in consistent positions
08:08
<Hixie>
but i have a case where i can't do that
08:10
<Hixie>
A(x), B(y), C(x, z)... do I do D(y, x), or D(x, y) ?
08:11
<Hixie>
y is the more useful argument...
08:48
<jruderman>
for a long time i had to look up the argument order for insertBefore every time i used it
08:49
<jruderman>
Hixie: make all the functions take all three arguments. problem solved!
08:50
<Hixie>
actually no, i considered that, and making B() take x makes my like even more complicated
08:55
<Hixie>
hmm
08:55
<Hixie>
so if i have statement-level error reporting and transaction-level error reporting
08:55
<Hixie>
if the statement-level error callback is omitted, clearly i should call the transaction-level error reporting callback instead
08:56
<Hixie>
but what if both are provided, and the statement-level error callback function doesn't throw an exception, but doesn't indicate that it handled the error?
08:56
<Hixie>
(the statement-level error callback can indicate that the transaction isn't to be rolled back -- i.e. that it handled the error -- by returning false)
09:03
<othermaciej>
insertBefore is hella confusing
09:11
<jruderman>
sometimes i wish it was prev.insertBefore(n) rather than parent.insertBefore(n, prev)
09:12
<Hixie>
ok i have revamped the database api
09:21
<Hixie>
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sql.html#sql
15:08
<hsivonen>
I want to extract spec URIs for each HTML5 element and attribute. should I do pattern matching against the TOC or is there a better way?
15:09
<hsivonen>
did someone already do this? zcorpan perhaps?
15:09
<hsivonen>
or was it Philip`?
15:12
<Dashiva>
I think Philip`
15:13
<zcorpan>
for http://canvex.lazyilluminati.com/misc/ref.html
15:15
<hsivonen>
zcorpan: thanks
15:15
<hsivonen>
Philip`: is the doc manually authored or is the data extracted from the spec programmatically?
15:17
<zcorpan>
iirc, the elements, attributes and dom interfaces, and content models are extracted from the spec, and the text is written manually... see http://canvex.lazyilluminati.com/misc/ref/
15:19
<Philip`>
All the data comes from a YAML file, and that file is written manually, except I copied-and-pasted an automatically-extracted not-quite-complete list of elements/attributes from the spec into that file
15:20
<hsivonen>
Philip`: ok. thanks
15:20
<hsivonen>
I think I'm going to try to extract what I want programmatically
15:22
<Philip`>
I can't find the program I used to automatically extract the spec definitions, but it was basically just some regexps
15:22
<hsivonen>
hmm. I think I'm going to use the Validator.nu HTML parser plus a SAX handler
15:22
<Philip`>
(hence being not-quite-complete, since the spec has a few attributes described in an unusual format)
15:24
<Philip`>
(I also only wanted the names, not ids for linking to the spec)
15:25
<hsivonen>
I want to have mapping so that
15:25
<Philip`>
(Incidentally, linking sounds somewhat dangerous when the ids are unstable (which they are))
15:25
<hsivonen>
1) when I have a ns,localName pair, I can get
15:25
<hsivonen>
a) Spec URI with fragment id
15:26
<hsivonen>
b) SAX Tree fragment with English description of allowed context
15:26
<hsivonen>
c) SAX Tree fragment with English description of allowed content model
15:26
<hsivonen>
d) SAX Tree fragment listing element-specific attributes
15:27
<hsivonen>
2) when I have ns,localName pair for element and another for attribute,
15:27
<hsivonen>
a) a SAX Tree fragment with English description of the attribute
15:28
<hsivonen>
hmm. the last one seems hard to extract programmatically
15:30
<Philip`>
For http://canvex.lazyilluminati.com/misc/ref/ref.html I was just writing descriptions and allowed-content-model manually, since it doesn't seem feasible to get human-readable output any other way
15:31
<hsivonen>
Philip`: why not? Hixie has written the allowed content model in a uniform <dl> on each element definition?
15:34
<Philip`>
Hmm, I suppose it wouldn't be too bad for content models
15:35
<Philip`>
although something like "Content model: When used in an element whose content model is only strictly inline-level content: only significant strictly inline-level content, but there must be no interactive descendants. Otherwise: any significant inline-level content, but there must be no interactive descendants." doesn't seem particularly reader-friendly and my brain turns off after the first sentence :-)
15:36
<hsivonen>
Philip`: if it is reader-unfriendly, it is better to fix it upstream in the spec than only in a validator UI
15:39
<Philip`>
The spec has a very different audience to a validator, and different again to a reference guide, so optimising for readers in one audience is likely to involve tradeoffs against others
15:42
<hsivonen>
hmm. sometimes the following the fragment id link for an attribute gives useful text
15:42
<hsivonen>
and other times the linked-to paragraph makes no sense on its own
15:42
<hsivonen>
:-(
21:21
<Hixie>
i wonder why people are generally pushing for 'role' and 'aria-disabled' instead of having all the attributes be 'aria' attributes
21:21
<Hixie>
i.e. why is one small part of the api intended to reuse 'role' when the rest doesn't?