00:06
<Dashiva>
Whoa, this XML thread is such a trainwreck
00:06
<Dashiva>
"You only have to follow the XML spec if you claim to follow the XML spec"
00:06
<Dashiva>
I realize I'm 3 days late
00:11
<roc>
they seem to be giving browsers permission to destroy any value in XML
00:11
<roc>
maybe we should just go ahead
00:18
<Dashiva>
Pretty much
00:18
<Dashiva>
Then again, what else would you expect from the One True Scotsman standard
00:53
<Dashiva>
So now Twitter parses RT...
06:56
<MikeSmith>
othermaciej: seems like the iframe sandbox patch will land soon
06:57
<othermaciej>
MikeSmith: cool
06:58
<MikeSmith>
cool to see rel=noreferrer got into nightlies recently too
07:00
<MikeSmith>
which reminds me, I think we need to re-start discussion of publishing an Origin header spec through IETF
07:00
<MikeSmith>
I guess on the http wg mailing list
08:13
<zcorpan>
hsivonen: it seems v.nu has two bugs with datalist
08:14
<zcorpan>
hsivonen: one parser bug where "any other end tag" doesn't imply </option>
08:14
<zcorpan>
hsivonen: and list=foo doesn't work
08:14
<hsivonen>
zcorpan: is that a spec bug also or is the parser out of sync with the spec here?
08:15
<hsivonen>
zcorpan: thanks
08:15
<zcorpan>
hsivonen: afaict from the spec </option> should be implied
08:16
<zcorpan>
there's no entry for "datalist" end tag, so it gets handled by "any other end tag"
08:16
<zcorpan>
whose steps run through once without doing anything but changing "node" to the next in the stack
08:17
<zcorpan>
and then returns to step 2 which generates implied end tags
08:17
<hsivonen>
If things go well, I intend to update the parser to spec next week
08:18
<zcorpan>
cool
08:20
<zcorpan>
feel free to curse me for the double escape dash dash stuff :)
08:23
<hsivonen>
zcorpan: I intend to implement that last after the other spec changes...
08:24
<zcorpan>
ok
08:35
<MikeSmith>
hsivonen: I hope the datatype-warning patch I e-mailed you isn't too buffoonish
08:36
<hsivonen>
MikeSmith: I'll try to get to it soonish
08:36
<hsivonen>
(today)
08:36
<zcorpan>
bugzilla.validator.nu doesn't load for me
08:37
<hsivonen>
zcorpan: weird. it loads for me
08:37
<MikeSmith>
wmf too
08:38
<hsivonen>
web-sniffer reaches it, too
08:38
<zcorpan>
hmm now it works
08:40
<MikeSmith>
hsivonen: about the patch, no rush.. from testing in the messageEmitterAdapter part, I can already see that the patch isn't making isWarning() available (though I don't know why).. and in the mean time, I'm working my way through the messageEmitterAdapter part
08:41
<zcorpan>
filed a bug
08:43
<MikeSmith>
ah wait, yeah, I did at least manage to get isWarning() set correctly
08:44
<MikeSmith>
baby steps
08:47
<MikeSmith>
someday I will write a book: How to hack Java code even while having serious lack of cluefulness
08:49
<MikeSmith>
my strategy is basically to turn a bunch of knobs at random until the picture clears up
08:49
<othermaciej>
MikeSmith: I raised the idea with the IETF of making a working group for HTTP Extensions for the Browsable Web, which could include Cookies, Origin, Strict Transport Security, sniffing, and other things along those lines
08:49
<MikeSmith>
ah yeah
08:49
<othermaciej>
MikeSmith: in lieu of a WG for just HTTP State
08:49
<othermaciej>
MikeSmith: I think I should pursue that further
08:49
<MikeSmith>
yeah, please to
08:49
<MikeSmith>
othermaciej: you talked about this with Lisa?
08:50
<othermaciej>
a little bit, yes
08:50
<othermaciej>
or rather, I talked to people who talked to her and she sent me mail
08:50
<zcorpan>
it seems like liam's first goal is already possible and that he's suggesting a purely editorial change to html5
08:50
<hsivonen>
is there yet any indication about how Google intends to proceed with SPDY as far as standardization goes?
08:50
<othermaciej>
I gave higher priority to the getting the Decision Policy done shortly after suggesting the idea
08:51
<MikeSmith>
othermaciej: yeah, understood
08:51
<othermaciej>
hsivonen: I think they are interested in having it be a standard once it is fully baked
08:51
<othermaciej>
hsivonen: some of us from Apple are meeting with the Google folks who worked on it in two weeks
08:51
<othermaciej>
hsivonen: I sent them some preliminary questions, one was about whether they intended it to be used via https: or a new protocol
08:51
<othermaciej>
hsivonen: they said https: but I don't think they have worked out how the upgrade would go yet
08:52
<zcorpan>
as for his second point... it seems like namespace mashups and user-defined namespaces would require writing a namespace definition file, which seems like at least as much overhead as using namespace syntax
08:52
<hsivonen>
othermaciej: OK. (I expect the IETF WG for it to be "fun".)
08:52
<othermaciej>
I don't understand what a "namespace mashup" is
08:52
<othermaciej>
hsivonen: for whatever reason, IETF people seem to respond more positively to SPDY than things like WebSocket protocol...
08:53
<othermaciej>
hsivonen: I'm a little uncertain about the upgrade story btw because it seems like there's no way to make it work right without losing at least a bit of the performance benefit of using SPDY in the first place...
08:54
<MikeSmith>
othermaciej: if you follow up with Lisa directly, you maybe also ask/remind her if Alexey Melinkov (the other IETF area director that some of this stuff relates to) should be brought into the loop on the discussion (if he's not been already). and feel free to Cc me too if you want (I talked with Lisa and Alexey both in Hiroshima and have had some e-mail discussion about other stuff after)
08:54
<othermaciej>
MikeSmith: ok
08:54
<hsivonen>
othermaciej: odd (about SPDY vs. Web Socket)
09:33
<krijnh>
MikeSmith: I am now
09:35
<MikeSmith>
krijnh: can you consider setting up logging for #html-a11y on irc.w3.org? there's no activity there so far, but we will be using it going forward
09:35
<krijnh>
Sure :)
09:40
<zcorpan>
Philip`: you forgot about <input type=color value=#c0ee0e>
09:40
<krijnh>
MikeSmith: logging now, I'll set everything else up later
09:41
<MikeSmith>
krijnh: cheers -- much appreciated
09:41
<krijnh>
Np
09:42
<Philip`>
zcorpan: Oh, I kind of ignored that since it wasn't using colour keywords at all
09:42
<Philip`>
and also because I forgot :-(
10:25
<zcorpan>
have microsoft said what from html5 ie9 will support? afaict they didn't mention one thing but still everyone says it'll "support html5"
10:42
<Philip`>
http://lists.w3.org/Archives/Public/public-html-testsuite/2009Nov/0009.html - hmm, when I first saw that big gap my immediate assumption was that it was an embedded YouTube video and I didn't have Flash enabled
10:42
<Philip`>
which is probably not a good assumption :-(
10:43
<zcorpan>
maybe jgraham fell asleep on the enter key
10:49
<jgraham>
Actually I had something stuck in my spacebar key which is had to hold down space to remove. But thunderbird was "helpfully" in html-compose mode and so collapsed all the spaces into one displayed space
10:49
<jgraham>
so I didn't realise that all the space characters were there :(
10:51
<jgraham>
Did the email make any sense apart from the huge gap?
10:53
<Philip`>
Is the idea to work out which bits of the spec don't have tests yet? Or to work out which tests are made invalid when the spec changes? Or both?
10:54
<jgraham>
Philip`: Both seem useful
10:56
<Philip`>
For the latter case, is it not sufficient just to update implementations and see what tests start failing? (and have multiple independent implementations to be more sure neither introduced a bug)
10:56
<Philip`>
That's basically a way of automating the determination of what tests are affected by spec changes
10:57
<Philip`>
and seems more practical than automatically determining which tests *might* be affected, and then having a human check every single one of them to see if they really are affected
10:57
<zcorpan>
if the spec changes and no tests start failing after fixing impl, it's an indication of lack of tests
10:58
<Philip`>
Indeed
10:59
<Philip`>
or a bug in the test harness :-)
11:01
<jgraham>
Right, that is basically what we have done so far
11:02
<jgraham>
But it is quite hard to be confident that one has updated the implementation correctly if you have a "fix the implementations then fix the test" approach
11:03
<Philip`>
That's why you have more than one implementation
11:03
<jgraham>
(and hence hard to be sure that you updated all the relevant tests)
11:04
<Philip`>
I don't think it's an ideal solution, though
11:04
<jgraham>
Philip`: Taking it to an extreme, why bother writing tests at all? Why not just fuzz input to different implementations and panic when they disagree
11:04
<Philip`>
but I'm not sure how it could be made better, and requiring more human effort per test case doesn't seem better
11:05
<jgraham>
Philip`: Agreed.
11:05
<Philip`>
jgraham: That's basically what I did with the automatically-generated tokeniser tests - generate a load of inputs, and if html5lib disagreed then I checked its implementation and my implementation to work out which was wrong
11:08
<Philip`>
(Random inputs would be unlikely to get good coverage of the spec, but I had a systematic way of doing it which seemed to work okay)
11:08
<zcorpan>
the problem is making sure the coverage of the fuzzer is good enough
11:09
<jgraham>
I don't think fuzzing HTML is particularly difficult
11:09
<jgraham>
At least for the tree construction part
11:10
<jgraham>
Because there are basically a finite number of possible tokens at each point
11:10
<jgraham>
(that shopuld have observable differences in behaviour)
11:10
<jgraham>
The only problem is that some states would be quite rare
11:11
<jgraham>
Like getting exactly <table><colgroup>x
11:12
<jgraham>
(You could of course base your fuzzer on the spec somewhat so that it picked things that were "more likely" to be interesting given the previous n tokens
11:12
<jgraham>
i.e. an order n Markov-chain)
11:14
<Philip`>
My tokeniser thing was based on looking at the spec's transitions for the current state, and then picking a few representative characters for that transition
11:14
<Philip`>
and then occasionally pruning inputs that lead to the same state
11:14
<Philip`>
or something like that
11:14
<Philip`>
so I guess the same idea could work for tree construction, except with tags instead of characters
11:38
<roc>
zcorpan: I don't recall anything specific so far
11:39
<hsivonen>
people developing fuzzers for HTML5 parsing may want to coordinate with Jesse Ruderman
11:41
<gsnedders>
Philip`: But it didn't check stuff like whether all characters in Unicode class White_Space acted as whitespace in tokensization, for example, which is worth checking
11:44
<jgraham>
hsivonen: Is he doing that in particular
11:44
<jgraham>
?
11:44
<Philip`>
gsnedders: It could be relatively easily extended to do that, I think
11:45
<Philip`>
It has a function to return interesting strings given a tokeniser transition condition, so it does stuff like "IsConsumedCharacter c -> [ [c]; [c-1]; [c+1] ]"
11:45
<Philip`>
and it could say if c=0x20 then try some other whitespacey characters too
11:45
<Philip`>
but that would require a human to think to test that
11:46
<Philip`>
so it's going to be far from perfect coverage of all possible bugs
11:46
<hsivonen>
jgraham: I'm not sure if he is doing it actively right now, but at least he was planning to
11:47
<gsnedders>
Philip`: Equally attribute values starting with other quote chars, etc.
11:48
<gsnedders>
Philip`: I think given a model of the tokenizer and some human specified things about interesting stuff we can probably get quite a long way
11:49
gsnedders
started work on DOCTYPE quirks mode tests, but then I realized doubling the number of parser tests just for that might not be overly loved
11:53
<zcorpan>
roc: hmm? about what?
11:53
<zcorpan>
oh he disconnected
11:53
<hsivonen>
zcorpan: about IE9 maybe?
11:56
<zcorpan>
ah
12:59
<gsnedders>
heh. apparently W3C is at fault according to one comment on the IE9 blog post for never removing obsolete features.
12:59
<gsnedders>
HTML 4.01 doesn't contain NEXTID or PLAINTEXT! :P
13:02
<Lachy>
wow, several commenters there think MS should adopt webkit for IE
13:03
<jcranmer>
I vote no to that opinion
13:03
<Lachy>
don't they get that reducing competition in the browser market would suck?
13:03
<gsnedders>
That's not news
13:03
<gsnedders>
That's been going on since work on IE resumed
13:03
<Lachy>
I've heard many comments over the years suggesting that they should adopt Gecko. It's interesting that it's now swung over to WebKi
13:03
<Lachy>
*WebKit
13:04
<jcranmer>
they would switch, but they need to port webkit to Visual Basic first :-)
13:04
<Philip`>
Yeah, Microsoft should adopt WebKit and then compete with Apple and Google purely on user interface design
13:04
<Lachy>
haha
13:04
<jgraham>
Don't they get that the Microsoft board would sooner eat faeces than let their company adopt ${third party layout engine}
13:05
<gsnedders>
http://tech.slashdot.org/comments.pl?threshold=2&mode=nested&commentsort=0&op=Change&sid=1450088
13:05
<jcranmer>
no, they can beat Chrome on stability
13:44
<hsivonen>
how many factual errors can you spot in this article? http://www.peachpit.com/articles/article.aspx?p=1409807&seqNum=2
13:46
<hsivonen>
"This chapter is from the book
13:46
<hsivonen>
Designing with Web Standards, 3rd Edition"
13:46
<hsivonen>
says the page
13:48
<Dashiva>
"RDF controls, menus, and toolbars"
13:48
<Dashiva>
What?
13:48
<jgraham>
wtf is HTML<sub>5</sub> and why did they steal our name?
13:54
<hsivonen>
jgraham: our name?
13:54
<Dashiva>
Hixie's name, surely
13:54
<Philip`>
That could really do with some technical review from someone who actually understands this stuff
13:54
<gsnedders>
WTF is an RDF control?
13:54
<gsnedders>
A method of editing triples?
13:55
<hsivonen>
Philip`: indeed
13:55
<Dashiva>
Are there any major errors, though? Technicalities aren't so important in a text meant for the uninitiated
13:55
<Dashiva>
(I didn't read it closely)
13:55
<jgraham>
hsivonen: Well clearly whatever they are describing there isn't HTML5
13:55
<jgraham>
It is this weird HTML<sub>5</sub> thing
13:57
<jgraham>
Dashiva: Pretty much every verifyable statement in the article seems to be wrong
13:58
<jgraham>
e.g. Hixie doesn't chair WHATWG or HTMLWG
13:59
<jgraham>
Some things just make no sense "HTML and XHTML are document languages that contain outline structure but no hint of page structure"
13:59
<gsnedders>
We have a chair?
14:00
<Dashiva>
gsnedders: Surely Hixie doesn't sit on the floor when he edits the spec
14:00
<hsivonen>
Dashiva: my vague recollection is that I've seen Hixie edit the spec sitting on the floor
14:01
<gsnedders>
Dashiva: I'm of the understanding he normally edits the spec sitting on a sofa
14:01
<gsnedders>
But yes, I too think I have seen Hixie editing the spec on a floor.
14:02
<Philip`>
Dashiva: It seems to basically be "Brief history with loads of technical errors. HTML5 has some new structural elements so you don't have to use div. Some comedy based on a technical error. Some more history. IE8's standards mode toggle was controversial but I'm not going to say what the outcome was. Advertisement for WSP and Dreamweaver and Expression. Validation is good." and that's about it
14:03
<Philip`>
so it doesn't have major errors because it does really make any major points or arguments
14:03
<Philip`>
s/does/doesn't/
14:04
<Philip`>
s/error/misunderstanding/ maybe
14:06
<Philip`>
I suppose Apple people might be unhappy that it only mentions Mozilla and Opera as the members of WHAT (sic)
14:06
<Philip`>
and mentions Apple only in the context of being more secretive than Microsoft
14:06
<gsnedders>
image/svg+xml is never sniffed?
14:07
<gsnedders>
Yeah, that's true
14:07
<Philip`>
(So secretive that they hide most of their browser development in plain sight in a public SVN repository)
14:18
<Philip`>
Also, now that I think about it (which is probably an unwise move), the comedy reference doesn't even make any sense at all
14:18
<Philip`>
and has no relevance to what it's attempting to have relevance to
14:21
<Philip`>
http://www.zeldman.com/2009/11/13/mission-of-promo/#comment-49680 - maybe he could get all the other errors fixed too
14:22
jgraham
wonders if he is the only one who is annoyed by attension-seeking "follow me" links
14:23
<jgraham>
*attention
14:24
<TabAtkins>
I sort of hope that's not really an excerpt from Zeldman's book.
14:24
<hsivonen>
jgraham: formatted for print maybe?
14:24
<TabAtkins>
But it is. Sigh.
14:24
<hsivonen>
TabAtkins: me, too, mut the link Philip gave seems to indicate it's genuine
14:26
<zcorpan>
maybe he should have used mpilgrim's approach and write the book online, so people could point out errors before printing the book
14:26
Philip`
wonders if anyone is going to bother telling Zeldman
14:26
<mpilgrim>
i don't think that would have helped
14:27
<hsivonen>
which reminds me I should report a minor factual error to mpilgrim
14:27
<hsivonen>
oh. he is here
14:27
mpilgrim
is listening
14:27
<hsivonen>
mpilgrim: IIRC, you stated a number for standards-mode doctypes
14:27
<TabAtkins>
Your book's out, right, mpilgrim?
14:27
<hsivonen>
mpilgrim: they are infinite
14:28
<mpilgrim>
tabatkins: it's still a work-in-progress at http://diveintohtml5.org/
14:28
<jgraham>
Philip`: You should
14:28
<mpilgrim>
brought to you by carls jr.
14:28
<mpilgrim>
hsivonen: really? why?
14:28
<TabAtkins>
Darn, I wanted to buy it for my sister for Xmas.
14:28
<zcorpan>
(quirky and almost-quirky doctypes are also infinite)
14:28
<hsivonen>
zcorpan: true
14:28
<mpilgrim>
no, won't be out on dead trees until feb. at the earliest
14:28
<TabAtkins>
;_;
14:28
<Philip`>
html5.org is a pretty boring page, why should I bother diving into it?
14:28
<mpilgrim>
i'm told there will be a kindle edition too
14:29
<mpilgrim>
for maximum irony
14:29
<hsivonen>
mpilgrim: if the doctype doesn't match the quirky rule or the almost standards rule, the 'anything else' case is standards
14:29
<mpilgrim>
hey, at least it's not "Dive Into HTML<sub>5</sub>"
14:29
<Philip`>
(html5.org has awesome subdomains though)
14:29
<zcorpan>
mpilgrim: <!doctype html public "a"> is standards mode, and you can append anything and any number of characters after "a" and it'll still be standards mode
14:29
<hsivonen>
and has been even when the quirky list wasn't infinite
14:29
<mpilgrim>
i did not know that
14:29
<zcorpan>
except "
14:30
<mpilgrim>
i'll try to find a clever way of phrasing that
14:30
<hsivonen>
mpilgrim: of course, authors shoudn't rely on this knowledge
14:30
<zcorpan>
for quirks mode it's similar; any doctype with a name other than "html" triggers quirks mode
14:30
<hsivonen>
so it's better to state it so that it isn't factually incorrect but it might be a good idea not to highlight the state of affairs
14:31
<zcorpan>
and almost standards doctypes can use trailing garbage or any system identifier
14:31
<mpilgrim>
looks like the point i was trying to make with the numbers was that quirks mode expanded over time
14:31
<mpilgrim>
so i'll just remove the bit about how many standards mode doctypes there are
14:31
<mpilgrim>
and call it a day
14:32
<hsivonen>
sounds like a good fix
14:32
<TabAtkins>
Tangent: I love stackoverflow and want to have its babies.
14:32
<mpilgrim>
we need a random doctype generator
14:33
<zcorpan>
print "<!doctype" + random() + ">"
14:33
<jgraham>
TabAtkins: If you do that try to keep the children away from the obnoxius advertising that has been the downfall of their father
14:34
<TabAtkins>
I will endeavor to this end, jgraham.
14:34
<TabAtkins>
zcorpan: Your random doctypes are dull and boring.
14:35
<zcorpan>
TabAtkins: why?
14:35
<TabAtkins>
Who wants a random number in the doctype? They need adventure and excitement!
14:36
<zcorpan>
maybe random() doesn't return a number but adventure and excitement?
14:37
<TabAtkins>
I doubt this, unless you have a truly surprising implementation of random().
14:37
<Philip`>
print "<!doctype ", (pack L => rand 2**32), ">"
14:38
<Philip`>
That'll rarely give you numbers
14:39
<jgraham>
Personally I implement random() as a call to a webservice that buys me a ticket to vegas, whereon I roll a fair die, fly home and enter the result. It has bto be async to keep the UI responsive though
14:39
<jgraham>
*wherein
14:39
<TabAtkins>
I'm glad the webservice does the buying. Could get pricey otherwise.
14:40
<zcorpan>
it sends the bill to TabAtkins
14:40
<TabAtkins>
DAMMIT
14:40
<jgraham>
Sure, I use your account details
14:40
<Philip`>
It's lucky that the ticket is the only possible expense that could conceivably occur while you're in Vegas, otherwise it could indeed get pricey
14:41
<TabAtkins>
zcorpan: Do you need the "a" in the standards-mode doctype, or will any starting letter suffice?
14:41
<jgraham>
Huh? I don't gamble, I just think the dice in vegas are more fair
14:41
<zcorpan>
TabAtkins: could be anything so long as you don't end up with something that triggers quirks mode
14:42
mpilgrim
finally finished reading that atrocious zeldman/marcotte article
14:42
<Philip`>
TabAtkins: Make sure you don't put DOCTYPE NETSC inside the aaaaa... string, else IE will go into quirks mode
14:44
<mpilgrim>
i think zeldman has a different definition of "dead end" than i do
14:44
<TabAtkins>
http://www.xanthir.com/etc/doctype.php
14:45
<Philip`>
TabAtkins: Should be "PUBLIC" for XML compatibility, I think
14:45
<hsivonen>
Philip`: XML compat also requires a system id
14:46
<Philip`>
Oh, actually it should be "SYSTEM"
14:46
<TabAtkins>
That'll keep standards?
14:46
<Philip`>
or what hsivonen said
14:46
TabAtkins
knows nothing about doctypes.
14:46
<hsivonen>
TabAtkins: unless your random generator collides with the one magic IBM doctype
14:46
<hsivonen>
IBM intranet FTW!
14:46
<TabAtkins>
So <!DOCTYPE html SYSTEM "foo">?
14:46
<Philip`>
TabAtkins: I think so, since that's what the about:legacy-compat doctype uses
14:47
<TabAtkins>
kk
14:47
<TabAtkins>
Done.
14:48
<zcorpan>
who cares about xml compat
14:48
<zcorpan>
<!doctype html system "" LOL>
14:48
<hsivonen>
Philip`, apparently
14:48
<gsnedders>
zcorpan: That's quirks, no?
14:48
<zcorpan>
no
14:48
<gsnedders>
zcorpan: because the correctness flag is false from parser?
14:48
<TabAtkins>
It's just a good thing I already had a big list of colors and animals. I'm not sure why.
14:49
<zcorpan>
gsnedders: garbage after system identifier is ignored
14:49
<gsnedders>
zcorpan: So it seems. Odd.
14:49
<zcorpan>
firefox compat
14:49
<Philip`>
zcorpan: Maybe Wikipedia would switch to the PUBLIC "lightgreen-hedgehog" doctype without realising it'll break XML consumers
14:50
<zcorpan>
(pages have doctypes that end with /> and expect standards mode)
14:50
<TabAtkins>
I like my "snow-crow" doctype.
14:50
<zcorpan>
Philip`: indeed, the xhtml 1.0 strict fpi is needed for entities
14:50
<TabAtkins>
I want to use it from now on.
14:51
<TabAtkins>
Though, to be consistent, I should probably just grab whatever the doctype of the moment is whenever i create a new page.
14:51
<zcorpan>
TabAtkins: you might get random 404s from validating xml parsers
14:52
<TabAtkins>
Good thing I don't care.
14:52
<TabAtkins>
I already get random 404s from some spider that can't read unicode in urls anyway.
14:52
<TabAtkins>
And just tosses the characters.
14:52
<mpilgrim>
also, different definitions of "parent organization," "RDF," "page structure," "tolerance," "clean," "structured," "semantic," "chair," and "comedy"
14:54
<Philip`>
TabAtkins: You should limit it to combinations that mostly rhyme, like snow-crow and purple-turtle and peru-gnu and, um, salmon-salmon and teal-teal
14:55
<TabAtkins>
That would be far more work than is worth it. The five minutes I spent assembling it is too much work already.
14:56
<mpilgrim>
surely there's an RDF-enabled rhyming dictionary somewhere?
14:56
<hsivonen>
zcorpan: /> on doctypes is sad
14:56
<Philip`>
Finding rhymes is hard :-(
14:56
<TabAtkins>
mpilgrim: That would also require me to care about RDF.
14:56
<Philip`>
I'm glad I'm not a poet
14:58
<Philip`>
magenta-centaur?
14:59
<TabAtkins>
Are you trying to rhyme, or did you just get that?
15:00
<TabAtkins>
Because they don't rhyme unless you *really* rhoticize the magenta into magentar.
15:00
<Philip`>
I'm trying
15:00
<Philip`>
but it's hard :-(
15:06
<hsivonen>
it seems a bit sad that there doesn't seem to be all-round agreement that two browsers using sqlite don't constitute two independent interoperable implementations
15:06
TabAtkins
likes the <small> tag, and is glad it made it in.
15:06
<TabAtkins>
Are they implementing sqlite interoperably?
15:06
<hsivonen>
TabAtkins: I don't know. It fails at the "independent" step.
15:06
<TabAtkins>
… What?
15:07
<hsivonen>
TabAtkins: If browser S and browser O both use sqlite, the sqlite part is not independently implemented twice. it's implemented only once.
15:07
<TabAtkins>
That... that doesn't make any sense.
15:08
<hsivonen>
TabAtkins: how so?
15:08
<hsivonen>
if the same code is used, it's not independent code
15:08
<hsivonen>
it's the same code
15:08
<Philip`>
Presumably two independent browsers running on the same platform would be okay
15:08
<TabAtkins>
Sure, if you're talking about the sqlite spec. But not if you're talking about some spec that happens to use sqlite (which I assume you were).
15:09
<Philip`>
even though the platform code is shared
15:09
<Philip`>
so where is the distinction between platform features and browser features?
15:09
<hsivonen>
TabAtkins: I'm not talking about a spec called sqlite. I'm talking about a piece of software called sqlite.
15:09
<Philip`>
s/features/code/g
15:09
<TabAtkins>
Okay, yes. Two browsers both implementing the same sqlite code do not count as independent implements of sqlite.
15:10
<TabAtkins>
s/implements/implementations/
15:10
<Philip`>
If everyone uses libpng, ddoes that mean there aren't two independent implementations of e.g. toDataURL('image/png')?
15:10
<hsivonen>
Philip`: yes
15:10
<Philip`>
s/dd/
15:10
<Philip`>
s/$/d\//
15:11
<hsivonen>
Philip`: are all Web-compatible browsers using libpng and the IJG libjpeg?
15:11
<Philip`>
Don't know, but it doesn't seem unlikely
15:11
<hsivonen>
Philip`: at least I don't have data showing that either PNG or JPEG decoding has two independent Web-compatible implementations
15:12
<Philip`>
hsivonen: Do you consider that to be a problem?
15:12
<hsivonen>
Philip`: not a severe one
15:13
<Philip`>
It doesn't stop people writing new browsers, because they can just use libpng
15:13
<hsivonen>
Philip`: as long as they are willing to call into code written in C
15:13
<hsivonen>
Philip`: it would suck if one day someone wrote a browser in a memory-safe language and found that there's secret sauce to decoding PNG that isn't in the PNG spec
15:14
<Philip`>
Should that block specs that depend on PNG from fulfilling their two-interoperable-implementation Rec criteria?
15:14
<hsivonen>
Philip`: probably not
15:15
<Philip`>
Should a similar situation with SQLite?
15:16
<hsivonen>
Philip`: yes, given that sqlite is different from libpng in the sense that it doesn't have a Web-compatible maintenance story
15:16
Philip`
doesn't think the SQLite thing is good, but isn't sure how to clearly define why it's a problem
15:17
<hsivonen>
Philip`: also, I tend to see PNG and JPEG more as grandfathered parts of the platform than as something that you can use to reason about independent impls.
15:18
<hsivonen>
(and maybe MS has independent impls or PNG and JPEG and I'm just unaware)
15:18
<hsivonen>
(and maybe the pure Java impls of PNG are actually truly interoperable)
15:19
Philip`
notes that the two APNG implementations are not interoperable
15:19
<hsivonen>
(also, having read the PNG spec, it seems credible that it actually describes the libpng impl)
15:19
<hsivonen>
I have more doubts about the spec quality of JFIF
15:20
<mpilgrim>
Philip`: it's OK to raise our standards over time
15:21
<mpilgrim>
lots of stuff in the first 20 years of the web was hackish and underdocumented
15:21
<mpilgrim>
doesn't mean we can't demand more from future standards
15:22
<mpilgrim>
(for the record, i agree with mozilla's concerns about an underspecified SQL language, but i don't think it'll make a difference in the long run)
15:22
<hsivonen>
mpilgrim: why no difference in the long run?
15:23
<mpilgrim>
apple isn't just going to remove their implementation
15:23
<mpilgrim>
google has publicly committed to implementing it in chrome in 2010
15:23
<mpilgrim>
i think market pressure will eventually force mozilla to implement it too
15:24
<mpilgrim>
but that doesn't make it a good standard, that's just the reality of the marketplace
15:24
<Philip`>
Are the SQLite developers interested in helping web use?
15:25
<mpilgrim>
dunno
15:25
<hsivonen>
on the bright side, SQLite doesn't have a more restrictive license than libpng or libjpeg, so in that sense, they are in the same category
15:26
<webben>
Are the distinct requirements of use by web browsers - as opposed to other uses - written down somewhere?
15:27
<hsivonen>
webben: the main difference the Web brings are stricter security requirements and stricter backwards compat requirements
15:28
<hsivonen>
(assuming that we aren't even talking about whether SQL in general is a bad choice for browsers and CouchDBesque solutions would be better)
15:30
<webben>
i see
15:33
<Philip`>
By "SQL in general" do you mean the syntax, or the relational model?
15:34
<hsivonen>
Philip`: both the relational model and a query language vaguely like the vagueness that is SQL
15:35
<hsivonen>
at this point, for all practical purposes, the relational model and SQL go hand-in-hand
15:35
<hsivonen>
doesn't really make sense to have one without the other
15:38
<hsivonen>
Wow. the P part of DAP is worse than I thought
15:39
hsivonen
just read http://www.w3.org/mid/7789133a0911191522y510c0e5cubbfa43f7a148943e⊙mgc
15:40
<Philip`>
hsivonen: Lots of libraries provide the relational model (with selects and joins and columns and keys and indexes and constraints and query optimisers and whatever) without any SQL syntax, hiding it behind things that look like normal programming
15:40
<Philip`>
e.g. LINQ
15:41
<hsivonen>
Philip`: good point
15:43
<Philip`>
A different syntax would likely be more usable and prevent stupid SQL injection bugs and would isolate web content from some of the details of SQL (since every SQL database has quite different syntax for the same concepts)
15:43
<Philip`>
but would also take effort to design and be harder to learn for people who already know SQL
15:43
Dashiva
waves to auto_increment
15:44
<Philip`>
but it seems like it should be part of any discussions about SQLite vs alternatives
15:54
Philip`
likes streaming HD TV programmes but wishes they didn't turn into awful mush when showing forests or swarms of insects
15:56
<zcorpan>
http://diveintomark.org/archives/2009/11/18/expense-reports#comments makes me think of http://xkcd.com/386/
16:17
<TabAtkins>
Heh. We have amusing quotes so regularly on the whatwg stats page.
16:17
<gsnedders>
From the wonders of JS in the real world: 'try{ // this is needed for now since the above regexp parsing needs more test verification'
17:02
<gsnedders>
If there are any masochists who take pleasure from HTML regexps: http://www.mkyong.com/regular-expressions/10-java-regular-expression-examples-you-should-know/
17:05
<Dashiva>
Oh joy, yet another broken email regexp
17:06
<Dashiva>
And a file filter that doesn't support .jpeg files...
20:03
<incluye>
Which of the new tags are inline by default?
20:03
<incluye>
Like, <aside> for instancew.
20:03
<incluye>
*instance.
20:06
<annevk>
see section 11.2.2
20:06
<annevk>
<aside> is block
23:32
<Philip`>
"Opera [...] keeping the modified testsuite in our local VCS" - I thought your local VCS was CVS, so you couldn't get away from it and save your sanity that easily :-)
23:32
<jgraham>
Philip`: Not for tests
23:33
<Philip`>
Oh, okay
23:34
<jgraham>
Mainly I am just wildly opposed to anything that makes me use CVS ever again
23:34
<jgraham>
But I think there is also a legitimate reason to prefer hg
23:34
<Philip`>
I wonder how insane it would be to try to use Hg for dealing with review status
23:35
<jgraham>
How?
23:35
jgraham
is much less worried about reviewing tests than merely having tests in the first place
23:36
<Philip`>
e.g. people submit random tests by publishing a repository, people review and accept tests by pulling them into their own reviewed repository, then someone pulls them into the main official repository at some point
23:36
<Philip`>
That might be not possible and/or far more effort than is necessary
23:36
<jgraham>
That sounds quite insane, yes :)
23:37
<jgraham>
Assuming each tests has a unique id we can have a simple flat file database (or text file or XML document or JSON file or whatever) that adds any metadata to tests
23:37
<Philip`>
(RDF!)
23:38
<jgraham>
Sure as long as I don't have to produce or consume it :)
23:39
<Philip`>
What do you think should be done with tests that are generated (by a possibly complex process) from some source data? Should the source get checked in, or the runnable output, or both, or neither?
23:39
<jgraham>
Both
23:40
<jgraham>
like Canvas/testsuite_name/src and Canvas/testsuite_name/tests
23:40
<Philip`>
I suppose I'm mainly thinking of canvas tests where people should use the YAML/Python to edit tests but don't want to bother if they're just running tests
23:40
<Philip`>
so that's probably sensible
23:41
<jgraham>
Yeah I've done similar things
23:41
<Philip`>
There are bugs in the tests that I haven't fixed for ages because I'm too lazy to run the script and upload the new files again :-(
23:41
jgraham
should go to sleep now
23:43
<Philip`>
You should, but will you?