00:00
<Hixie>
the paper mentioned in the e-mail is here: http://sdch.googlegroups.com/web/Shared_Dictionary_Compression_over_HTTP.pdf
00:02
<roc>
ok, I've read it
00:03
<roc>
with this design, you can't actually share dictionaries across domains, because that would open an DoS attack against other sites
00:03
<roc>
well, at least a reduction in performance
00:04
<roc>
so how do I give feedback?
00:04
<Hixie>
reply on the list
00:04
<Hixie>
(the http list, that is)
00:06
<Hixie>
i don't really know where the right place to standardise this would be if y'all are interested in taking this further
00:06
<Hixie>
probably a new w3c or ietf wg
00:06
<Hixie>
(no idea how the ietf works)
00:07
<Hixie>
oh, he also attached the PDF, i totally didn't notice
00:12
<Hixie>
http://trac.webkit.org/changeset/36097 is funny
00:20
Hixie
finds a part of wf2 that requires browsers to implement time travel
00:20
<Hixie>
paradox-avoiding time travel, even
00:28
<Dashiva>
Hixie: I hope you didn't remove it, I was depending on that feature in my new awesome framework
00:29
<Hixie>
:-P
00:31
<Hixie>
ok i need a word for what we do to check the validity of a form that isn't "validity"
00:32
<Hixie>
since we use that for conformance
00:32
<Hixie>
constraint cecking maybe
00:32
<Hixie>
checking
00:33
<Dashiva>
Constraint is good.
00:33
<Philip`>
Filled-inedness
00:34
Hixie
takes Philip`'s merit badge back
00:34
<Hixie>
you now have -1 merit badges. :-P
00:34
<Dashiva>
User cooperation ensurance
00:34
<Hixie>
hah
00:34
<Dashiva>
Is ensurance a word?
00:35
<Hixie>
you guys realise i now have to use both of these ideas in the spec somehow right
00:35
<Dashiva>
I will deny everything
00:35
<Hixie>
i have logs!
00:36
<Dashiva>
I could claim impersonation
00:36
<Hixie>
mmm.
00:36
<Hixie>
bummer.
00:37
<Dashiva>
This is where you're supposed to vaguely hint to some kind of vast google conspiracy to control and monitor all traffic on the net
00:37
<Hixie>
oh right
00:37
<Hixie>
"google doesn't comment on future products and services"
00:39
<Dashiva>
I suppose I should try to at least pretend I sleep at sane times, as I'm not being paid to stay awake at night.
00:41
<Hixie>
if you get paid for your work instead of your ass-in-a-chair-ness, then you can just work at night
00:45
<Dashiva>
Yeah, but even if I did go to the university at midnight, I doubt any students would show up to get help :)
00:45
<Hixie>
ah well
00:46
<Hixie>
that i can't help you with
00:46
<Hixie>
i recommend getting students to ask for help by e-mail
00:46
<Hixie>
:-D
00:46
<Dashiva>
Not like they show up in daytime either...
00:46
<Dashiva>
Yeah, tried that too. Maybe it'll pick up when the exercises get harder.
00:47
<Dashiva>
When I took the course myself, I did email my predecessor quite a bit
00:54
<Philip`>
If the exercises are easy, they can do them without any help; if the exercises are hard, they won't do them at all and will instead play frisbee or whatever
00:56
Philip`
isn't quite sure what lazy students do nowadays
09:08
<zcorpan_>
Hixie: what's wrong with "Form validation"?
09:08
<zcorpan_>
hsivonen: why the difference between <!DOCTYPE html><title></title><table><tr><td></tbody><table></table> and <!DOCTYPE html><title></title><table><tr><td></tr><table></table> ?
09:10
<zcorpan_>
Hixie: i think it's good to stick with terminology that people actually use, otherwise we end up with the same problem that wcag2 had
09:11
<hsivonen>
zcorpan_: I guess the tree builder goes through one mode mode in the latter case
09:14
<zcorpan_>
hsivonen: i guess html5 parser + relaxng doesn't make it easy to reach the "one message per mistake" optimum
09:14
<hsivonen>
zcorpan_: they sure don't
09:15
<hsivonen>
for about three reasons
09:15
<hsivonen>
1) HTML5 prescribes errors and sometimes jumps through more than one error-emitting state
09:16
<hsivonen>
2) tree builder error correction introduces implied stuff that can react with RELAX NG
09:16
<hsivonen>
3) RELAX NG element position errors suck after the first element position error
09:18
<zcorpan_>
hsivonen: perhaps you could make it slightly better by having a "validator friendly" mode in the parser that omits "duplicate" errors and makes the tree more useful
09:18
<hsivonen>
zcorpan_: would one ever want to have the duplicate errors for anything except unit tests?
09:19
<zcorpan_>
hsivonen: no :)
09:19
<hsivonen>
I guess it would be feasible to make an "at most one tree builder error per token" rule
09:20
<hsivonen>
however, maintaining a different tree builder mode for validation would be painful
09:20
<hsivonen>
originally, I wanted the tree builder to have 3 modes
09:21
<hsivonen>
1) tree building and conforming
09:21
<hsivonen>
2) streaming and conforming (i.e. fatal error on non-streamable cases)
09:21
<hsivonen>
3) streaming and non-conforming streamable recovery
09:21
<annevk>
(It would be nice if </br/> also generated just one error.)
09:21
<hsivonen>
I never got around to #3 and recently removed the code that anticipated such a mode
09:22
<hsivonen>
annevk: wouldn't an ""at most one tree builder error per token" rule
09:22
<hsivonen>
do that
09:22
<hsivonen>
?
09:24
<zcorpan_>
hsivonen: forgetting an </ol> end tag is an example where v.w.o has more useful behavior
09:26
<hsivonen>
are the assumptions of the html5lib serializer tests documented somewhere?
09:26
<hsivonen>
http://wiki.whatwg.org/wiki/Serializer_tests is empty
09:27
<annevk>
hsivonen, the second / is a tokenization error
09:27
<hsivonen>
oh right.
09:28
<hsivonen>
however, it's an error that could be trivially moved to the tree builder phase
09:28
<hsivonen>
if the spec and implementors agree, so that the unit tests agree with it being a tree builder error
09:29
<hsivonen>
annevk: anyway, I think </br/> isn't a case worth optimizing
09:30
<hsivonen>
so we probably should leave it as is
09:31
<annevk>
true
09:37
<annevk>
wow
09:37
<annevk>
with IE8 in standards mode people have to prefix overflow-x and overflow-y
09:37
<annevk>
http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor-extensions.aspx
09:37
<roc>
wah?
09:37
<annevk>
I wonder who comes up that
09:38
<roc>
We support it without prefix, and Opera and Webkit do too, right?
09:39
<othermaciej>
wow they prefixed filter
09:39
<othermaciej>
and changed the syntax
09:39
<othermaciej>
bold
09:40
<hsivonen>
perhaps it's like making getAttribute not return null
09:40
<roc>
hmm
09:40
<othermaciej>
wait I though they reverted that
09:40
<othermaciej>
or rather
09:40
<othermaciej>
matched other browsers instead of spec
09:40
<roc>
text-overflow, background-position and word-wrap are also interoperably implemented without prefix
09:41
<roc>
although, what's this background-position-x/-y?
09:42
<roc>
"However, in order to ease the transition, the non-prefixed versions of properties that existed in Internet Explorer 7, though considered deprecated, will continue to function in Internet Explorer 8."
09:42
<hsivonen>
othermaciej: right, so perhaps the overflow stuff go the same route
09:43
<annevk>
I'm going to comment that prefixing overflow-x/y is silly
09:43
<annevk>
(though in a friendly way)
09:43
<othermaciej>
adding a prefixed version doesn't seem that harmful
09:43
<roc>
it's not harmless, just pointless
09:43
<roc>
er, not harmful
09:43
<roc>
hum, still no support for 'opacity'
09:44
<Hixie>
zcorpan_: people call it constraint checking too. but we have had confusion around the term "validation" in the past.
09:44
<Hixie>
hsivonen: the spec does allow you to do whatever you like after you report the first error, iirc, so you could have your parser do non-compliant fixup in order to give more useful error messages
09:45
<roc>
hmm, I shouldn't have said text-overflow was "interoperably implemented" ... it's just "implemented" :-)
09:46
<annevk>
roc, Opera actually has text-overflow prefixed
09:46
<annevk>
though we are considering removing the prefix
09:46
<roc>
ok
09:47
<roc>
but still, once one major browser has polluted the Web with a non-prefixed property, there doesn't seem much point in holding out
09:47
<annevk>
yeah, don't really recall why we kept it prefixed
10:05
<zcorpan_>
Hixie: will willValidate be renamed?
10:05
<Hixie>
unlikely
10:05
<Hixie>
i might call it "constrain validation"
10:10
<Philip`>
Hmm, IE8 adds __defineGetter__ (and Setter and lookup)
10:14
<hsivonen>
so does that mean from IE8 onwards, the top 4 engines all support prototypes for DOM nodes and defining getters and setters for them?
10:14
<hsivonen>
or am I missing something?
10:29
<annevk>
hsivonen, I think you're right
10:30
<Dashiva>
Now we just have to wait a decade or two for IE6 and IE7 to fade away
10:30
<annevk>
or for other browsers to get more market share
10:36
<hsivonen>
I wonder what the upgrade rate from IE6 to IE7 is when people install XP (instead of Vista) today
10:36
<hsivonen>
IE6 will start getting reaped by the end of computer retention times
10:37
annevk
hopes they'll become obsolete due to other browsers
10:38
<hsivonen>
I hope so, too, but realistically, if someone hasn't upgraded from IE6 by now, chances aren't that they won't until they buy a new computer
10:40
<Hixie>
anyone here got livejournal accounts btw?
10:40
<annevk>
nope
10:41
<hsivonen>
it publicly visible stats mean anything, it seems that most of the IE6 block are running it on XP as opposed to Windows 2000
10:41
<hsivonen>
s/it publicly/if publicly/
10:42
<hsivonen>
and Vista will probably never surpass XP in market share
10:42
<hsivonen>
(that is, the next version of Windows probably comes before Vista goes ahead of XP)
10:47
<aaronlev_>
i created a mailing list for people working on free tools/resources to advance WAI-ARIA
10:47
<aaronlev_>
http://groups.google.com/group/free-aria
10:47
<aaronlev_>
i probably should have included HTML a11y in the scope but, i guess this will be a focused group
10:49
<Philip`>
hsivonen: Only about 2-3% of all people seem to be using Windows 2000, so that can't account for much of IE6's usage
10:49
<Philip`>
(Are those the numbers you were going on, or do you have OS-browser-combination stats?)
10:50
<Lachy>
hsivonen, that depends if the versions of XP people are installing still only come with IE6. Since they would have been shipping with Sevice Pack 3 since April or May, and IE7 has been out longer than that, they could be shipping with IE7 by default
10:50
<annevk>
I read this article yesterday that Google kept Google Chrome security update specifics secret but http://groups.google.com/group/chromium-announce/browse_thread/thread/886cd07cbbc1b4cf seems to simply list them
10:50
<hsivonen>
does Google Analytics have a public display of aggregate browser stats?
10:51
<hsivonen>
Lachy: my understanding is that there have been XP discs with IE6 on the market long after IE7 came out
10:52
<hsivonen>
Lachy: does MS remaster XP install discs at all?
10:52
<Philip`>
They make new discs to roll in Service Packs, as far as I'm aware
10:52
<Lachy>
hsivonen, yes
10:53
<hsivonen>
ok
10:53
<Lachy>
I have an XP SP2 disc at home that I use
10:53
<annevk>
but even SP3 does not come with IE7
10:53
<annevk>
per http://en.wikipedia.org/wiki/Windows_XP#Service_Pack_3 anyways
10:53
<Lachy>
no, but IE7 has started being distributed as a critical update, and the service pack should have meant new discs were produced
10:57
<hsivonen>
SP3 does not update IE to 7
10:57
<annevk>
yeah, see above
10:58
Philip`
would notice if XP started automatically upgrading to IE7, since his mum would complain that it looked all funny
10:58
<hsivonen>
Philip`: you don't take care of your parents running an up-to-date browser?
10:58
<Lachy>
hsivonen, yes, I'm aware of that. But AIUI, I believe they include all critical updates at the same time as they release new service pack discs
10:59
<Lachy>
Philip`, it has, but it still requires the user to manually perform the installation, which can be cancelled.
11:00
<Lachy>
last time I installed XP in my virtual machine, I let it do all critical updates and came back and noticed the IE7 installation dialog waiting for me
11:00
<Philip`>
hsivonen: It's an up-to-date copy of IE6 :-p
11:01
<Philip`>
(and my dad has now switched to Firefox)
11:02
Philip`
doesn't see that the benefits outweigh the switching costs, if all you do is look at Hotmail and online banking
11:02
<hsivonen>
Philip`: think about the externalities of online banking with IE6
11:03
<hsivonen>
banks see IE6 in their logs and continue to support it
11:03
<Philip`>
A single person will be lost in the noise and won't make any real difference to their logs
11:05
<Philip`>
IE6 should be easy to support if the banking websites weren't huge JS monstosities that claim to work only in Internet Explorer and Netscape and that sometimes hobble along in Opera too, so it's their own fault :-)
11:06
<annevk>
my bank works fine in Opera
11:06
<annevk>
it's just looks a bit fugly now I have standards mode override in effect
11:07
<annevk>
still perfectly usable though
11:27
<hsivonen>
hmm. sudo easy_install simplejson complains about not finding eggs
11:32
<hsivonen>
ah. I used the wrong copy of easy_install
11:39
<BenMillard>
I just saw the SDCH thing. In the PDF, I read "For example, retrieving a set of HTML pages with the same header, footer, inlined JavaScript and CSS requires the retransmission of the same data multiple times."
11:39
<BenMillard>
but often the header will differ slightly, since the current section will be highlighted (such as via class) or de-linked (by removing <a href>) or both
11:40
<BenMillard>
and inline CSS is rather an edge case, given how well supported and cachable external CSS is
11:41
<Dashiva>
You don't have to make the whole header be one word, though?
11:42
<BenMillard>
Dashiva, the point is there's less which can be shared between requests on well-designed sites than the document seems to think.
11:47
<BenMillard>
simply writing better, lightweight markup would make Google result listings significantly more efficient without all this complexity
12:04
<BenMillard>
How does a dictionary file get created? For it to be automated, a system would need to know every permutation of markup it can produce in the areas targeted for inclusion in a dictionary, such as the header, afaict.
12:04
<BenMillard>
if has to be done manually, I don't see it catching on
12:06
<Philip`>
That's easy - you just tell your team of PhDs to work it out for you
12:07
<Philip`>
Or, I guess, you use a tool written by Google, which scans your logs and looks at the most commonly requested files and works out how to optimise for that
12:12
gsnedders
is far too tired
12:14
<BenMillard>
Philip`, just writing better markup seems like a better idea to me...especially given how much scope there is for improving the markup of mainstream websites. :)
12:18
<Philip`>
Maybe they could solve the problem of retransmission of inline CSS and JS by not making it inline
12:29
<hsivonen>
launching a new compression scheme in order to deal with inline CSS and JS indeed seems weird
12:32
<BenMillard>
the footer stays the same until you visit a page linked to by the footer, then you delink that entry
12:32
<jgraham>
Presumably the theory is that CPU cycles are cheap compared to both bandwidth and authoring time
12:32
<BenMillard>
navigation changes all the time as you highlight the current section, delinking an entry when you're at the index for that section
12:33
<BenMillard>
search box stays the same
12:33
<hsivonen>
however, a new compression scheme will like be more deployable than a new HTML client side include mechanism
12:33
<BenMillard>
hsivonen, my impression is few people even use the compression schemes which exist today, despite them being effective.
12:35
<BenMillard>
having briefly done a manual review of several websites I've developed professionally in recent times, it's surprising how little markup is shared between pages
12:35
<BenMillard>
the decorative graphics + CSS + JS massively outweigh the markup in terms of filesize, and they're already cached by conventional means
12:37
<hsivonen>
BenMillard: few people perhaps, but significant traffic generators do
12:37
<hsivonen>
BenMillard: like wikipedia
12:40
<BenMillard>
hsivonen, looks like myspace.com and google.com use gzip, too
12:41
<BenMillard>
hsivonen, if it were commonplace and commonly inadequate, I could see space for a new technology to improve it.
12:42
<BenMillard>
but neither of those conditions are true, afaict
12:42
<Lachy>
http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor-extensions.aspx
12:42
<Lachy>
it's about time they did that!
12:43
<BenMillard>
Lachy, http://krijnhoetmer.nl/irc-logs/whatwg/20080909#l-279
12:45
<Lachy>
oh, ignore me then.
12:47
<hsivonen>
zcorpan: telling the DOM to coalesce adjacent text nodes may have an effect on passing the tree to XSLT in Gecko
12:48
<BenMillard>
jgraham, it also seems to assume people's markup cannot be improved...yet here's a typical example of markup currently authored on the web: http://groups.google.com/group/free-aria
12:51
<hsivonen>
Hixie: is this thread on your radar: http://www.w3.org/mid/OFE3B13C49.D2CF8357-ONC12574BE.00686AE6-C12574BE.00692ED8⊙uic
13:02
<annevk>
Hixie, http://www.hixie.ch/tests/adhoc/html/canvas/007.html and http://www.hixie.ch/tests/adhoc/html/canvas/008.html need to be updated
13:06
hsivonen
wonders what tighter Web integration for Ubuntu Jaunty desktop means
13:06
<Dashiva>
They install it on google appengine, and you run an x server that connects there
13:07
<hsivonen>
shouldn't the X protocol be implemented on top of Web Socket and <canvas> for that to be Web integration?
14:16
<annevk>
'There SHOULD be a @version attribute on the html element with the value "XHTML+RDFa 1.0"'
14:16
<annevk>
can anyone enlighten me how that helps?
14:19
<Lachy>
annevk, what spec is that from?
14:20
<annevk>
http://www.w3.org/TR/rdfa-syntax/#docconf
14:21
<Lachy>
Hixie, in in the "in head" insertion mode http://www.whatwg.org/specs/web-apps/current-work/#parsing-main-inhead when a meta element is inserted, the spec states:
14:21
<Lachy>
"Otherwise, if the element has a content attribute, and applying the algorithm for extracting an encoding from a Content-Type to its value returns a supported encoding encoding, and the confidence is currently tentative, then change the encoding to the encoding encoding."
14:21
<Lachy>
That doesn't seem to check for http-equiv="Content-Type". Is that intentional?
14:21
<annevk>
yes
14:22
<Lachy>
ok, so <meta content="text/html;charset=UTF-8"> is enough?
14:22
<Lachy>
or even if it had http-equiv="Whatever"
14:22
<Philip`>
Yes
14:23
<Lachy>
ok
14:23
Philip`
remembers some past discussion of this
14:23
<hsivonen>
Lachy: Validator.nu whines though
14:24
<Philip`>
http://www.w3.org/mid/47CEDDF5.6090100⊙cau
14:24
<Lachy>
oh, ok. I was just wondering cause I need to write TCs for this part of the spec today, and trying to work out all the conditions that can trigger a reparse
14:24
<Philip`>
(See comment about content-style-type)
14:25
<Philip`>
Hmm, not really "discussion", just a comment, but anyway it's a known (mis)feature
14:35
<zcorpan>
annevk: i thought version='' was supposed to be the same as the FPI
14:37
<zcorpan>
euc-jp reminds me
14:37
<zcorpan>
i think URLs aren't utf-8 if the page encoding is euc-jp
14:40
hsivonen
checks if there are replies to zcorpan's comments
14:40
<hsivonen>
no replies
14:41
<zcorpan>
hsivonen: which comments?
14:42
<hsivonen>
zcorpan: the comments about the XHTML2 WG draft that used EUC-JP in examples that people will copy and paste
14:43
<zcorpan>
hsivonen: ah
14:43
<hsivonen>
zcorpan: what you mention of euc-jp related to something else?
14:43
<zcorpan>
http://www.w3.org/mid/47CEDDF5.6090100⊙cau
14:44
<hsivonen>
ah
15:33
<hsivonen>
zcorpan: http://wiki.whatwg.org/wiki/Validator.nu_Full-Stack_Tests
15:34
<zcorpan>
hsivonen: thanks
15:36
<hsivonen>
zcorpan: also, http://wiki.whatwg.org/wiki/Validator.nu_Unit_Tests
15:38
<zcorpan>
hsivonen: hmm i like omitting tags in test cases :P
15:39
<hsivonen>
zcorpan: it caused me grief when annevk omitted tags in the WF2 test suite...
15:40
<zcorpan>
hsivonen: ok
15:40
<hsivonen>
albeit in XHTML5
15:40
<zcorpan>
hsivonen: should tests be XHTML-compatible?
15:40
<zcorpan>
or why did it cause grief?
15:41
<zcorpan>
oh he omitted tags in XHTML?
15:41
<hsivonen>
HTML5 tests don't need to be XHTML compatible
15:41
<hsivonen>
zcorpan: he omitted, IIRC, <head> and </head> in XHTML, so the cases that should have had no errors related to WF2 had this other error
15:42
<zcorpan>
hsivonen: ok
15:42
<zcorpan>
hsivonen: but can i omit optional tags in text/html?
15:42
<hsivonen>
zcorpan: if you are certain that Hixie won't change the omissibility of those tags in random ways, yeah
15:42
<annevk>
fwiw, I did that when I still believed having different requirements for HTML and XHTML was ok
15:45
<zcorpan>
hsivonen: i take it that the test harness won't complain if i leave out "message"
15:47
<hsivonen>
zcorpan: it won't
15:47
<hsivonen>
oops
15:47
<hsivonen>
I take that back
15:47
<hsivonen>
It will probably throw
15:47
<hsivonen>
but I can change that
15:48
<hsivonen>
hmm. looks like it'll just say None in place of the message
15:49
<hsivonen>
so omitting the message works
15:49
<zcorpan>
ok
15:51
<zcorpan>
hsivonen: Writing a Test Eliciting No Errors is assuming that Validator.nu doesn't have a bug related to what is being tested :)
15:52
<hsivonen>
right :-)
15:53
<zcorpan>
hsivonen: i'll try writing a test tonight
15:54
<hsivonen>
zcorpan: great. thanks
15:58
<hsivonen>
I wonder when gandi.net is going to start taking customers without invitations...
16:03
<Philip`>
For virtual hosting?
16:05
Philip`
wonders how you're meant to work out whether particular hosting services are any good or not
16:05
<webben>
annevk: it only helps if you have different behaviors defined for the same elements/attributes in the same namespaces, which I guess is the risk XHTML2 is potentially taking. So: protection misunderstanding by theoretical future XHTML2 UAs?
16:05
<webben>
(re version)
16:06
<webben>
*protection from misunderstanding
16:06
<webben>
perhaps
16:06
<Philip`>
(At least Gandi doesn't have a blue-on-white website with stock photos of smiling people like pretty much every other internet service company, so that's a good sign)
16:07
<Philip`>
webben: If it was necessary to prevent documents being processed incorrectly, shouldn't it be a MUST rather than a SHOULD?
16:07
<webben>
Philip`: hmm, very good point!
16:07
<hsivonen>
Philip`: yes, for more flexible virtual hosting than what I have now
16:09
<annevk>
webben, without processing model and MUST requirement that's kind of moot
16:10
<annevk>
webben, hence my question
16:10
<webben>
yep
16:11
<annevk>
but that group is known for failing on proper specs
16:12
<webben>
i wonder if they're just following http://www.w3.org/TR/webarch/#ext-version
16:29
<Philip`>
hsivonen: Sounds like it might not be strict invitation-only, if I interpret http://www.gandibar.net/post/2008/09/02/Hosting-maintenance#comments saying "you can always request some shares now and we try to accommodate people where possible" as meaning they can make exceptions if you ask nicely
18:00
gsnedders
finds bug in RFC3987
18:10
<Dashiva>
"Note that the XML/HTML DOM consistency issue is not real, so it's worth focusing on the prefix issue."
18:10
<annevk>
I wasn't sure what he meant by that
18:11
<annevk>
One explanation suggests browser vendors are delusional, which I think is not true (but then I'm biased)
18:21
<MikeSmith>
I think Ben wrote that with the intent of somebody replying to ask what he meant by it
18:26
annevk
isn't really interested in asking :)
18:27
annevk
has seen too much RDFa e-mails lately all duplicating lots of info
18:28
<MikeSmith>
I guess statements like "You want monolithic, top-down, one solution-fits-all. I want the Web." don't make me inclined to be interested in asking for more details either
18:29
<Dashiva>
The irony in RDF being "The Web" is overwhelming
20:12
<Philip`>
I wish I could tell Google never to return results from www.faqs.org when I search for RFCs, because they have a giant font and are impossible to read and I'd much prefer the IETF's copies
20:14
<hsivonen>
Philip`: you need to link to tools.ietf.org more
20:15
<Philip`>
That's a horribly indirect inefficient way to get the desired result
20:16
<annevk>
-site:faqs.org
20:16
<annevk>
or site:tools.ietf.org
20:17
<Philip`>
That's far too much typing on every query
20:17
<annevk>
you can make a shortcut for it in Opera
20:17
<smedero>
inject it with your user-scripting plugin (greasemonkey, etc) of choice
20:18
<smedero>
or, yes that's probably easier
20:18
<Philip`>
I don't like using shortcuts, it feels like cheating :-(
20:18
<annevk>
Philip`, fail
20:20
<annevk>
something like http://www.google.com/search?q=rfc%s+site:tools.ietf.org&btnI=on as bookmark shortcut should work
20:20
annevk
makes one now as it seems useful
20:23
<gsnedders>
I need to learn to type
20:23
<annevk>
Philip`, thanks for the idea
20:24
<annevk>
"rfc 3987" now takes me to http://tools.ietf.org/html/rfc3987
20:25
<Philip`>
gsnedders: Try http://www.amazon.co.uk/dp/B001AZ7Q10/
20:25
<gsnedders>
Philip`: :P
20:26
<Philip`>
'"Mavis Beacon" is not a real person' - Wikipedia's destroying my world-view again :-(
20:49
<Dashiva>
Philip`: Next they'll claim Hixie is just the alias of two dozen Google engineers
20:52
<annevk>
http://thebjoernhoehrmannproject.org/
20:56
<Philip`>
Dashiva: That would make sense - they could all pool their 20% time together, and arrange it to look like a single real person
21:08
<gsnedders>
Dashiva: IT is.
21:08
<gsnedders>
*It
21:08
<gsnedders>
Dashiva: How else does it barely sleep?
21:09
<Dashiva>
Adrenaline IV
21:14
<gsnedders>
WHY DO YOU HAVE TO GIVE ME A BLOODY USERNAME?
21:14
<gsnedders>
sorry.
21:14
<gsnedders>
But ARGH.
21:15
<Dashiva>
I wonder if we'll ever stop calling people 'users'
21:15
<Dashiva>
Only two businesses, etc
21:16
<annevk>
that's why Hixie always talks about "we" and "us"
21:16
<annevk>
makes sense now
21:18
<gsnedders>
I would never use "gmsneddon1" as a username.
21:19
<Dashiva>
Putting numbers in usernames is an abomination
21:25
<hober>
I only put the 0 in hober0 because gmail had a 6-char minimum username length requirement.
21:27
<gsnedders>
http://lists.w3.org/Archives/Public/public-iri/2008Sep/0000.html
21:31
<gsnedders>
Anyone got any ideas?
21:44
<Lachy>
Hixie, do not upgrade to iTunes 8. Requiem 1.7.4 no longer works with it
21:46
<Lachy>
http://yadayada.org/wordpress/?p=26
21:47
<Hixie>
oh right i forgot today was new ipod day
21:47
Hixie
goes to see if the video is available yet
21:49
gsnedders
just buys CDs
21:49
<Hixie>
hsivonen: that thread was not on my radar but i don't know what i would have done differently if it was
21:50
<Hixie>
gsnedders: for audio i just buy unencrypted audio
21:50
<Hixie>
but there's no way to buy unencrypted video
21:52
<Lachy>
the new iPod nanos look cool
21:53
<Lachy>
I'm waiting for the keynote though, it says it's coming soon
21:54
<sicking>
Lachy, got a good link to read about the new ipods?
21:54
<Lachy>
http://www.apple.com/itunes/
21:54
<sicking>
:)
21:54
<Lachy>
video here http://www.apple.com/ipodnano/
21:55
<gsnedders>
brb
21:55
<sicking>
wow, perdy colors
21:56
<sicking>
wow, i guess accelerometers must be cheap these days
22:02
<Hixie>
doesn't look like today's annoncements were all that
22:03
<annevk>
nothing interesting
22:05
<Hixie>
i wonder why the quicktime plugin doesn't work in my safari
22:05
<Hixie>
works fine in mozilla
22:05
<sicking>
the new nano looks pretty sweet, but no, nothing revolutionary
22:11
<sicking>
still new iphone nano with a roll-out digital-paper screen :(
22:11
<sicking>
s/new/no/
22:13
<sicking>
annevk, so i think we might need to bring back the header blacklist in AC :(
22:13
<sicking>
annevk, and blacklist 'cookie' and 'authorization'
22:19
<Hixie>
how can ou set cookie and authorization cross-site? that seems bad
22:19
<Hixie>
surely that's not possible
22:19
<Hixie>
can you set host?
22:20
<sicking>
Hixie, xhr.setRequestHeader("cookie", "hello world")
22:20
<sicking>
currently no spec forbids that if the site opts in
22:20
<Dashiva>
Geez, Ben is already appealing to process
22:20
<annevk>
sicking, XHR forbids that
22:20
<sicking>
annevk, really?
22:20
<Hixie>
i highly doubt that anne intentionally made that possible
22:21
<annevk>
sicking, well, it should
22:21
<annevk>
and does
22:21
<annevk>
see http://dev.w3.org/2006/webapi/XMLHttpRequest/#setrequestheader
22:21
<sicking>
annevk, doesn't currently. Are you proposing that for same-site as well?
22:21
<sicking>
oh
22:22
<sicking>
when was that list updated?
22:22
<annevk>
long time ago
22:22
<annevk>
seems XHR2 has some <dfn> problem for setRequestHeader :/
22:23
<annevk>
though I did add Access-Control-Request-Headers/Method a few days ago
22:23
<sicking>
hrm
22:23
<annevk>
(in XHR2)
22:23
<sicking>
we recently updated our blacklist, but apparently didn't get those
22:23
<annevk>
sicking, same-site too, yes
22:23
<sicking>
wonder why
22:23
<annevk>
sicking, there was some discussion around this with abarth and collinjackson
22:24
<sicking>
annevk, ah, adam did the updating of our list
22:24
<sicking>
annevk, what was the argument against?
22:25
<sicking>
annevk, and is there currently agreement?
22:27
<annevk>
I don't think there was an argument against, although I believe IE either only blocks Cookie or just Cookie2
22:27
<annevk>
(for same site)
22:27
<sicking>
so what was the discussion about?
22:27
<annevk>
there's no real agreement on any of the specifics of XHR as browsers seem reluctant to fix bugs :/
22:27
sicking
wonders why adam didn't add the full list in his patch
22:28
<annevk>
sicking, well, abarth and collinjackson proposing to block it and me agreeing and nobody else complaining :)
22:28
<sicking>
ah :)
22:28
<sicking>
bummer, i guess we'll have to patch the branch again :(
22:29
<sicking>
annevk, i don't think there has been reluctance, just uncertainty how stable the spec is
22:29
<sicking>
annevk, at least from us
22:29
<annevk>
fair enough, it does change now and then based on feedback
22:29
<annevk>
quite a lot based on feedback from ap (WebKit) a year ago or so
22:29
<sicking>
annevk, yup, makes sense, but we need to get it to last call and then to candidate
22:30
<sicking>
also, has there been any plan devised to get MS on board?
22:31
<annevk>
hmm, same plan as for <canvas>? get devs to cry for it
22:33
<sicking>
ideal would be if we could find a faster way
22:33
Philip`
isn't sure that really counts as a plan
22:34
<annevk>
Acid4? *blink*
22:35
<Hixie>
?
22:35
<annevk>
getting IE to support XHR2
22:35
<Hixie>
oh
22:35
<Hixie>
yeah well i'd rather they supported DOM2 Core before we started talking about new features
22:35
<Hixie>
and DOM2 Events
22:35
<sicking>
XHR1 rather
22:36
<Hixie>
and HTML4
22:36
<Hixie>
and XML
22:36
<Hixie>
you know
22:36
<Hixie>
stuff from the late 90s
22:36
<annevk>
boring
22:36
<annevk>
:p
22:37
<sicking>
annevk, btw, did you see my two feature requests for XHR2?
22:37
<sicking>
annevk, it's very likely that we'll add some of that in FF3.1
22:37
<gsnedders>
Applying for uni is annoying
22:37
<annevk>
sicking, I asked about use cases
22:38
<sicking>
as far as MS goes, i'd rather find a better way than drag them against their will
22:38
<jcranmer>
gsnedders: tell me about it... yuck
22:38
<Dashiva>
Hixie: "Naturally though, we shouldn't "
22:38
<annevk>
sicking, http://www.w3.org/mid/op.ugz0bk2k64w2qv⊙aooc
22:38
<sicking>
annevk, you did? where?
22:38
<Hixie>
oops
22:38
jcranmer
reiterates his opinion on browsers supporting WF2
22:39
<jcranmer>
s/on browsers supporting/that browsers should support/
22:39
<sicking>
hmm.. why didn't i get that mail
22:39
<annevk>
JSON is sort of scary as although it is a standard I believe there are quite a few differences between implementations... Also, it doesn't handle that many types...
22:40
<sicking>
hmm.. i blame gmail
22:40
<annevk>
(eg, allowing comments versus not allowing comments)
22:40
<Hixie>
JSON is a very loose "standard"
22:40
<sicking>
i don't have that mail at all
22:40
<annevk>
:/
22:40
<Dashiva>
annevk: There's the full spectrum from RFC-JSON to whatever-js-eval-supports-ON
22:40
<annevk>
I wonder if Gmail classifies my e-mail as spam sometimes
22:41
<sicking>
i have a bunch of other mails from that day
22:41
<sicking>
doesn't look like it's in the spam folder either
22:41
<annevk>
weird
22:43
<sicking>
annevk, can you resend to me personally so i can reply?
22:44
<annevk>
done
22:46
<sicking>
hmm.. now i see it
22:46
<sicking>
dunno if it's your newly sent one
22:46
<sicking>
and i got the test mail
22:47
<annevk>
that was a mistake
22:47
<sicking>
heh
22:53
<annevk>
sicking, long ago timeout came up as well and people proposed send(data, timeout) as syntax
22:55
<sicking>
annevk, I don't really care I guess, but it seems like .timeout makes a little more sense since the timeout isn't really related to the send() call any more than the open() call
22:55
<sicking>
annevk, sent reply
22:55
<annevk>
hmm, sync
22:55
<annevk>
don't use sync!
22:55
annevk
wonders if workers have timeouts
22:56
<smedero>
I think Dashiva and I already had the "JSON implementations are crazy" discussion with DanC... see: http://deron.meranda.us/python/comparing_json_modules/
22:58
<annevk>
smedero, interesting
22:59
<smedero>
I know support is just as mixed with PHP...
22:59
<Hixie>
Lachy: any idea what the story is with reqium and itunes "8"?
22:59
<Hixie>
requiem
22:59
<Hixie>
as in, when it'll be fixed?
23:00
<Hixie>
btw xhr should really be updated to integrate with the event queue stuff
23:00
<sicking>
annevk, indeed, found another mail from you that got into spam
23:00
<Hixie>
that would e.g. define whether timers fire during the sync wait
23:00
<Lachy>
Hixie, no. But I can email the developer and see if he'll tell me
23:01
<annevk>
Hixie, I guess it should
23:01
<annevk>
(and timers should not fire during sync)
23:01
<sicking>
bah, wish i didn't have to use gmails spam filter :(
23:02
<sicking>
ironport had much lower false-positive and false-negative rates
23:02
<Hixie>
annevk: that's easy to define then, in fact it's the default, so you just need to say "Note: No tasks from the _task queue_ are processed during this method" or something
23:02
<Hixie>
btw for workers right now we don't have a good api set, so we don't have sync database apis or timeouts on any of the apis, btu that will likely change eventually
23:03
<sicking>
annevk, timers would be relatively easy to block during sync. Not sure if we could block UI events in gecko though
23:03
<Hixie>
you can kind of fake it today by spawning a second worker and killing it on a timeout
23:03
<Hixie>
"ui events"?
23:03
<Hixie>
you mean like onclick in the page aea?
23:03
<sicking>
mouseover
23:03
<Hixie>
or in the chrome?
23:03
<sicking>
well, chrome isn't web, so i don't care what spec says
23:04
<sicking>
i mean page area
23:04
<Hixie>
right the spec won't say anything about the chrome area
23:04
<Hixie>
the page area events is basically defined as a bunch of event queues, right now each one can be pumped independently
23:04
<Hixie>
so xhr _could_ define that some task queues are pumped and some aren't
23:05
<Hixie>
though right now no spec defines that 'mouseover' et al are ever actually fired
23:05
<sicking>
most events don't come from an event queue though
23:05
<Hixie>
i guess that's either dom events or cssom
23:05
<Hixie>
sicking: ?
23:05
<Hixie>
sicking: per html5, all non-synchronous event dispatch goes through the task queue.
23:06
<sicking>
or rather, they originate there, but by the time they are mouse events we're not on the event queue any more
23:06
<sicking>
implementation wise
23:06
<Hixie>
not sure what you mean
23:06
<sicking>
i'm not saying it's impossible to stall/block/whatever, it's software, anything is possible, but it might be very hard with our impl
23:07
<sicking>
there's also the question of what to do with other tabs
23:07
<Hixie>
oh right because you're not pumping your ui thread at all while running script
23:07
<sicking>
do you still fire events on those
23:07
<Hixie>
so you get a lot of the blocking for free
23:07
<Hixie>
i keep forgetting that
23:07
<sicking>
yup
23:07
<sicking>
no process separation a'la chrome
23:08
<Hixie>
well chrome has the same thing actually
23:08
<Hixie>
i was thinking more opera
23:08
<sicking>
ah, yes
23:08
<sicking>
and then there is the issue of separate tabs in the same domain getting UI events
23:09
<annevk>
I guess I should look at the task queue tomorrow or maybe later this week
23:10
<annevk>
I still need to prepare my presentation for Thursday
23:10
<Hixie>
sicking: yeah well i still need to define exactly how it works but fundamentally pages on the same domain that can talk to each other share an event loop, so that's not a problem (if the loop is paused, it's paused for all the tabs that could talk to each other synchronously)
23:10
<Hixie>
anyway
23:10
<Hixie>
bbiab
23:11
<sicking>
not a problem in the sense that all other pages from the same domain lock up?
23:11
<sicking>
seems suboptimal
23:11
<Hixie>
there's really no other way to do it given that they both have access to the same dom, unless you want to make your dom thread-safe
23:12
<Hixie>
and even that wouldn't be web compatible