00:17
<Hixie>
what does "#...#" mean in php?
00:19
<TabAtkins>
Nothing.
00:19
<Hixie>
http://webreflection.blogspot.com/2010/06/websocket-handshake-76-simplified.html
00:19
<Hixie>
preg_match('#GET (.*?) HTTP#', $buffer, $match)
00:19
<Hixie>
why the "#"s?
00:19
<TabAtkins>
Oh, that's preg_match.
00:19
<TabAtkins>
Custom regex delimiters.
00:20
<Hixie>
aah
00:21
<gsnedders>
Whatever the first character is becomes the delimiter
00:21
<Hixie>
why isn't the " the delimiter?
00:21
<gsnedders>
(well, byte without the u flag)
00:21
<gsnedders>
Hixie: It's a string.
00:22
<Hixie>
i'm confused
00:22
<TabAtkins>
Because PHP is stupid.
00:22
<TabAtkins>
Obviously.
00:22
<gsnedders>
Hixie: preg_match is a function whose first argument is a string
00:22
<Hixie>
that's a given, i'm just trying to understand it :-)
00:22
<Hixie>
gsnedders: k
00:22
<gsnedders>
the string's value in that case is #GET (.*?) HTTP#
00:22
<Hixie>
right
00:23
<gsnedders>
Regexps don't exist at a syntaxual level in PHP
00:23
<Hixie>
sure
00:23
<gsnedders>
(That string is just passed to PCRE)
00:23
<Hixie>
but why isn't it just "GET (.*?) HTTP"
00:23
<Hixie>
oh does the PCRE expect its strings to be delimited or something?
00:23
<gsnedders>
Because that's what PCRE does :)
00:23
<Hixie>
that's lame
00:24
<gsnedders>
(you can have flags on the regexp after the ending delimiter)
00:24
<Hixie>
PCRE--
00:24
<AryehGregor>
The sane way to do it would be to have the flags as a separate argument.
00:24
<AryehGregor>
But PHP is not even slightly sane.
00:25
<gsnedders>
Well, this is just a side-effect of what PCRE does in this case
00:25
<AryehGregor>
PHP could put a wrapper around the PCRE call.
00:25
<AryehGregor>
Python uses PCRE too, doesn't it?
00:25
<gsnedders>
Nope
00:25
<gsnedders>
Python has its own regexp impl
00:25
<AryehGregor>
Okay, well, PHP could use Python's syntax, with an extra argument for flags.
00:25
<gsnedders>
AryehGregor: That would mean parsing the regexp itself
00:25
<hober>
I miss CL-PPCRE
00:26
<AryehGregor>
Then it could translate the flags to PCRE flags, sticking delimiters around it, and putting the flags at the end.
00:26
<AryehGregor>
gsnedders, why?
00:26
<AryehGregor>
Just have the wrapper add delimiters.
00:26
<gsnedders>
Oh, yeah, it could do that
00:26
<gsnedders>
But does [\/] work, for example?
00:29
<AryehGregor>
What do you mean?
00:30
<gsnedders>
Does the backscape actually escape there?
00:30
<AryehGregor>
Sure.
00:30
<gsnedders>
I had some memory of it not doing so, but it must
00:31
gsnedders
is too tired
00:34
<AryehGregor>
Argh, getting 500 ms ping to my ISP. >:(
00:48
<AryehGregor>
If el is an element with an id attribute set, is "delete el['id'];" supposed to work the same as "el.removeAttribute('id');"?
00:49
<AryehGregor>
The spec doesn't appear to say what that's expected to do, but maybe I'm crazy for even suggesting it.
00:52
<AryehGregor>
data:text/html,<!doctype html><script>var el = document.createElement("a"); var type = typeof el.id; delete el.id; alert(type + " " + typeof el.id);</script>
00:52
<AryehGregor>
That gives "string string" on Firefox and Opera, "string undefined" on WebKit.
00:57
AryehGregor
files a bug
00:58
<AryehGregor>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10267
01:05
<Hixie>
that's a WebIDL question
01:05
<othermaciej>
Hixie: that security paper on postMessage is fascinating
01:06
<Hixie>
it's depressing is what it is
01:06
<AryehGregor>
Hmm, okay.
01:06
<othermaciej>
I am going to have to spend some time reading that, as well as abarth et al's recent paper on applying a formal model to find security vulnerabilities in Origin checking, Referer checking, CORS, etc
01:06
<Hixie>
othermaciej: there's something to be said about academics writing papers about how I suck, but I don't know what it is :-P
01:07
<othermaciej>
Hixie: well, it's much better if the papers come soon enough to fix the suckage
01:07
<Hixie>
yeah i wish this kind of thing was sent to the mailing list while we were designing them rather than too late to fix the bugs
01:07
<Hixie>
but oh well
01:09
<othermaciej>
I wonder if it's possible to at least add interfaces that would allow for less error-prone postMessage use
01:09
<othermaciej>
like a version that doesn't take *, and on the receiving side forces you to check the sender origin (e.g. by providing a list of expected senders) to even get the message payload
01:11
<Hixie>
people could easily enough write that in a JS library if they wanted
01:11
<othermaciej>
they have some suggestions along similar lines
01:12
<othermaciej>
I guess the one suggestion from the paper that you can't implement in JS is wildcard-based multicast
01:12
<othermaciej>
(so you could send with a target origin of '*.facebook.com' instead of '*')
01:12
<AryehGregor>
I think this is the relevant spec, but I can't figure out what it actually means: http://dev.w3.org/2006/webapi/WebIDL/#delete
01:13
<othermaciej>
(or a list)
01:13
<AryehGregor>
Is "delete element.id" supposed to set the id JavaScript attribute to undefined, or just remove the content attribute?
01:13
<othermaciej>
neither
01:14
<Hixie>
certainly not the latter
01:14
<othermaciej>
hmm I see a bug in the algorithm there
01:14
<othermaciej>
"If O has the DontDelete attribute, return false."
01:14
<AryehGregor>
What's the expected output of this test case? Chrome outputs "undefined", Firefox and Opera output "string": data:text/html,<!doctype html><script>var el = document.createElement("a"); delete el.id; alert(typeof el.id);</script>
01:14
<othermaciej>
it should be "If property P of O has the DontDelete attribute, return false."
01:15
<othermaciej>
and host object properties are DontDelete
01:15
<Hixie>
othermaciej: file a bug
01:15
<othermaciej>
(or in ES5 terms, not Configurable)
01:15
<Hixie>
othermaciej: otherwise that'll be lost
01:15
<othermaciej>
does Web IDL use bugzilla?
01:16
<Hixie>
i hope so
01:16
<Hixie>
otherwise we're not able to track bugs anywhere
01:16
<jamesr>
Hixie: http://www.whatwg.org/specs/web-apps/current-work/complete.html links to http://www.whatwg.org/specs/web-apps/current-work/complete/
01:16
<jamesr>
Hixie: http://www.whatwg.org/specs/web-apps/current-work/complete/ 404's
01:16
<othermaciej>
there is a component
01:16
<Hixie>
jamesr: again? wtf
01:16
<Hixie>
something is broken with my update code it seems
01:17
<Hixie>
jamesr: fixed
01:17
<jamesr>
yup, works now. thanks
01:17
<jamesr>
but wait
01:18
<jamesr>
is that really the multi page version?
01:18
<Hixie>
of?
01:18
<jamesr>
ah yes it is
01:18
<othermaciej>
weinig: if you have any interest in doing Web IDL edits any more, here is a trivial bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10269
01:19
<othermaciej>
weinig: I would Cc you but I'm not sure if you have a w3c bugzilla account
01:24
<weinig>
othermaciej: I have made the change
01:24
<weinig>
othermaciej: I will commit it shortly
01:34
<dandaman>
http://imgur.com/vqIcL
01:34
<dandaman>
see how the scrollbar messes up the <select> box
01:34
<dandaman>
anyone know how to fix that?
01:37
<AryehGregor>
So does no one know what the expected behavior in my test case is, or are you just not telling me? :/
01:37
<Hixie>
AryehGregor: i'd have to read webidl to know the answer :-)
01:38
<Hixie>
i suspect the answer is either return false or throw an exception, and in either case don't touch the object
01:38
<Hixie>
but i could be wrong
01:38
<Hixie>
webidl should say
01:40
<AryehGregor>
It looks like it will run deletion steps if they're defined for the particular type, but I'd have to track down the meaning of a lot of jargon to figure out for sure.
01:41
<AryehGregor>
No, maybe not.
01:41
AryehGregor
has no idea
01:43
<AryehGregor>
Chrome actually unsets the attribute. That's surely wrong, isn't it?
01:45
<Hixie>
yes
01:46
<Hixie>
wait, no it doesn't
01:46
<Hixie>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/578
01:46
<Hixie>
oh you mean the IDL attribute
01:46
<Hixie>
that's probably wrong too, yes
01:48
<AryehGregor>
Okay, I'll file a bug against WebKit . . . or is this Chrome and not WebKit?
01:48
<TabAtkins>
That sounds like webkit.
01:49
<jamesr>
the bug is in the webkit repo even if it is chrome specific (the bindings live in the webkit svn repo)
01:49
<jamesr>
so file in bugs.webkit.org
01:54
<AryehGregor>
https://bugs.webkit.org/show_bug.cgi?id=43224
01:56
<othermaciej>
AryehGregor: most DOM properties are DontDelete
01:56
<othermaciej>
AryehGregor: per Web IDL
01:56
<othermaciej>
AryehGregor: so according to the Web IDL spec, the delete algorithm should stop short
01:56
<jamesr>
AryehGregor: what's safari do?
01:56
<AryehGregor>
jamesr, I dunno, I'm on Linux.
01:56
<jamesr>
wondering if it's a v8 vs jsc bindings issue
01:58
<othermaciej>
AryehGregor: if you make a "live dom viewer" version of your test case I can try it in Safari
01:58
<AryehGregor>
A data URL won't work?
01:58
<Hixie>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/578
01:58
<othermaciej>
I guess I can just copy it
01:58
<othermaciej>
this alerts "string" in Safari: <!doctype html><script>var el = document.createElement("a"); delete el.id; alert(typeof el.id);</script>
01:59
<othermaciej>
which I believe is correct per spec
01:59
<AryehGregor>
It's what Opera and Firefox do too.
01:59
<othermaciej>
if Chrome does not match, it is very likely a bug in the v8 DOM bindings
01:59
AryehGregor
doesn't see a component for that
02:00
<othermaciej>
just put [V8] in the bug title
02:00
<AryehGregor>
Okay, now I'm off to bed.
05:30
<WilliamC>
So, how is the debate of Theora v. h.256, or whatever the number is, going?
06:02
<Hixie>
WilliamC: it's now Theora vs h.264 vs WebM
06:06
<WilliamC>
WebM?
06:07
<Hixie>
the format google released a few weeks ago
06:08
<WilliamC>
Wonder which one is better
07:15
<Hixie>
i really don't understand the vision people on hybi have for websockets
07:16
<Hixie>
in what world does it make sense to talk about websockets messages being "dispatched using the platform's mime mechanism"?
07:28
<micheil>
I haven't followed along on that conversation, Hixie
07:28
<micheil>
although, some of the things proposed do sound a little bit more complicated then what's needed
07:47
<Hixie>
micheil: it's not so much that they're complicated so much as as far as i can tell, they make no sense at all
07:47
<Hixie>
it'd be like if someone was talking about how HTTP should allow you to change nick
07:47
<micheil>
okay, similar idea
07:47
<Hixie>
or if someone was talking about how IRC didn't let you select the printer driver
07:48
<micheil>
well of course irc should let you choose your printer driver, isn't that what your irc server does?
07:48
<micheil>
my included the kitchen sink.
07:51
<hsivonen>
less than 24 hours left on the current HTML WG polls
08:02
<jgraham>
Hixie: The MIME stuff confuses the hell out of me
08:02
<jgraham>
I have no idea why you would want that
08:07
<annevk>
well, it's pretty clear Greg still wants his bidirectional HTTP rather than TCP for browsers
08:07
<annevk>
but I don't get why he argues for mime for the whole stream
08:07
<annevk>
that makes no sense at all
08:12
<hsivonen>
do those who want bidi HTTP want it to be implemented in browsers?
08:13
<jgraham>
hsivonen: I guess so
08:13
<jgraham>
But it's not clear what they rally envision
08:13
<jgraham>
*really
08:13
<jgraham>
e.g. there was lots of stuff about doing dispatch based on content-type
08:14
<jgraham>
But in most websockets cases I can think of, that makes no sense
08:14
<jgraham>
Anyway, my conclusion is that the whole thing is just a bad idea because it is additional complexity
08:14
<jgraham>
and makes the protocol less generic
08:15
<jgraham>
I am more worried by real issues like framing / the handshake
08:16
<hsivonen>
what's the real problem with those?
08:20
<jgraham>
For the handshake there is some question about the security properties
08:20
<jgraham>
Although it looks like wss will change
08:21
<jgraham>
For the framing there is a tenion between the belief that sentinal markers are more secure when sending, and that it is harder to write the recieving code
08:22
<Hixie>
the only change i'm aware of for wss: is the minor addition of the hook into the nextprotoneg feature
08:23
<jgraham>
Hixie: That was what I meant, I think
08:24
<Hixie>
k
08:24
<Hixie>
that's not much of a change :-)
08:24
<hsivonen>
this stuff really needs to be wrapped up and shipped
08:29
<hsivonen>
have there been any positive effects from taking the protocol to the IETF?
08:42
<Hixie>
hsivonen: no
08:56
kennyluck
waves to MikeSmith
08:56
<MikeSmith>
kennyluck: hey
08:57
<kennyluck>
Hey, Mike, I want to introduce you my friend, pg30123.
08:57
<pg30123>
Hi
08:57
<kennyluck>
He is my high school classmate and very interested in HTML5.
08:57
<kennyluck>
Most importantly, he's going to be a google employee next year :)
08:57
<MikeSmith>
pg30123: hi there
08:57
<MikeSmith>
excellent
08:58
<kennyluck>
Of course I want him to help promote W3C-related work in Taiwan. Hehe.
08:58
<pg30123>
lol
08:58
<kennyluck>
There's little information about HTML5 in Taiwan, honestly.
08:59
<pg30123>
But to begin with, I should mention that I am interested in it but not familiar with it..
08:59
<MikeSmith>
http://diveintohtml5.org/ is a good place to start learning
08:59
<MikeSmith>
and http://html5doctor.com/
09:00
<kennyluck>
MikeSmith: Also he is interested in (using) P2P technology. :)
09:00
<pg30123>
=.=
09:00
<MikeSmith>
and for a quick overview of the differences from HTML4, http://dev.w3.org/html5/html4-differences/
09:00
<kennyluck>
I noticed that recently there's some discussion about possible P2P with HTML5?
09:00
<MikeSmith>
yeah
09:01
<MikeSmith>
Hixie has a draft spec of an idea
09:01
<kennyluck>
pointer?
09:01
<MikeSmith>
http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#peer-to-peer-connections
09:01
<kennyluck>
Ah, thanks. How new is this, I wonder.
09:01
<Hixie>
in particular, http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027129.html
09:02
<kennyluck>
Thanks!
09:03
<Hixie>
nn
09:03
<pg30123>
Speaking of P2P, is there some kind of real-time video streaming of sharing methods available now?
09:31
<hsivonen>
pg30123: we only have server to browser streaming at the moment. no p2p
09:33
<pg30123>
hsivonen: thx!
09:35
<kennyluck>
pg30123 was thinking about implementing PPS with HTML5. :p
10:05
<jgraham>
What is supposed to happen if I set some_element.spellcheck = true;
10:05
<jgraham>
Note: not "true"
10:05
<jgraham>
Or equally some_element.spellcheck = 0;
10:06
<payman_s>
From spartan log: "Child is a zombie; attempting to reap him..."
10:06
<jgraham>
payman_s: Wrong window?
10:06
<jgraham>
Anyway spellcheck...
10:07
<jgraham>
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#attr-spellcheck
10:07
<jgraham>
talks about setting the IRL attribute to "true", "false" and "default" or otherwise raising an error
10:07
<jgraham>
*IDL
10:08
<jgraham>
But then says
10:08
<Workshiva>
To the specmobile
10:08
<jgraham>
"""On setting, if the new value is true, then the element's spellcheck content attribute must be set to the literal string "true", otherwise it must be set to the literal string "false"."""
10:10
<Workshiva>
That second part probably predates the tristate version?
10:10
<payman_s>
jgraham: yes, sorry.
10:10
<jgraham>
payman_s: :)
10:10
<jgraham>
Workshiva: Coud be
10:11
jgraham
wonders WDG(&W)D
10:11
<Philip`>
Why would spellcheck = true differ from spellcheck = "true"?
10:11
<Philip`>
WebIDL should convert true to "true" before HTML5 looks at it
10:11
<Workshiva>
Philip`: Because I haven't confirmed that WebIDL transforms boolean true into 'true' yet
10:11
<jgraham>
true isn't an ascii case insenitive match for "true"
10:11
<jgraham>
is it?
10:12
<Workshiva>
I was looking for the IDL definition of spellcheck to make sure it was DOMString
10:12
<Philip`>
http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString
10:12
<Philip`>
It basically just does ToString
10:12
<Philip`>
Workshiva: It is
10:12
<Workshiva>
You're so quick!
10:12
<Philip`>
(Defined on HTMLElement)
10:13
<jgraham>
But 0 shouldn't work, right
10:14
<jgraham>
or 1
10:14
<Workshiva>
Correct
10:14
<Philip`>
That'll become "0" which isn't "true" or "false" or "default"
10:14
<Philip`>
so no
10:14
<Workshiva>
But the paragraph still needs correction
10:14
<Workshiva>
There's also a false" without the leading "
10:14
<jgraham>
The paragraph makes no sense
10:15
<jgraham>
Or at least the trailing sentence should go
10:15
<Workshiva>
Yeah
10:15
<jgraham>
Also it seems that throwing a syntax_err is not web compatible
10:42
<jgraham>
"""With length-prefixed frames, if one endpoint *does* miscalculate the size of a UTF-8 string, the protocol will detect it.""" - can someone explain this to me?
10:50
<Philip`>
jgraham: No
10:51
<Philip`>
Well, I suppose you could make the frames length-prefixed *and* null-terminated
10:51
<Philip`>
so that the protocol has a reliable way to detect framing errors
10:52
<Philip`>
s/null/0xff/
10:53
<jgraham>
Philip`: I was wondering about that
10:54
<Philip`>
Otherwise it doesn't seem like the protocol will have any reliable sync points
10:54
<jgraham>
I wonder if it is a bad idea for some obvious reason
10:54
<Philip`>
It's bad because people will implement the length-prefix and ignore the terminator, or ignore the length-prefix and implement the terminator
10:54
<Philip`>
and it will still work most of the time
10:54
<jgraham>
Yeah :(
10:55
<Philip`>
until they get UTF-8 or until they get attacked
10:58
<Philip`>
Has anyone written a WebSockets server validator yet, which tests its handling of edge cases? If that was sufficiently good and sufficiently well known then I expect pretty much everybody would use it, and it'd help avoid a lot of bugs
10:58
<jgraham>
No, but it does seem like a good idea
10:58
<Philip`>
Is anyone planning to write one?
10:58
<jgraham>
I asked if anyone planned to write tests, but didn;t get any replies
10:59
<Philip`>
(with a more detailed plan than "someone should write on")
10:59
<jgraham>
I guess it could go on my "list of things that would be quite a good idea to do but I would much prefer if someone else did"
11:02
<othermaciej>
jgraham, Philip`: I think what he's saying is that frames are prefixed with a byte identifying the frame type, then the length
11:03
<othermaciej>
if you don't see the frame type byte after reading the length, you know you have missed your boundary
11:03
<othermaciej>
however, I don't think the protocol can safely resync, because you have no guarantee that your frame type byte won't be present in another message (if you read too far)
11:18
<hsivonen>
what's Hixie's plan for binary? length or sentinel+stuffing?
11:18
<hsivonen>
(length makes sense for binary, because data stuffing is annoying)
11:19
<jgraham>
hsivonen: I assume length
11:20
<Workshiva>
It was going to be length in the past, I haven't followed it to know if that has changed
11:24
<Philip`>
If by "plan" you mean "what's already described in the spec for binary frames (which are non-conforming to send or to process)", then they're length-prefixed
11:24
<Philip`>
(with an arbitrary-length integer)
11:27
<annevk5>
so far I have not recognized a single person here
11:27
<annevk5>
except for Yngve, who spotted me
11:38
<Philip`>
"the server has to take the digits from the value to obtain a number [...], then divide that number by the number of spaces" - how many servers are going to crash when you send a string with zero spaces?
11:40
<jgraham>
Philip`: All the ones that didn't follow step 5 closely?
11:40
<jgraham>
(and abort in that case)
11:41
<jgraham>
Or step 6
11:45
<Philip`>
jgraham: I see some implementations that appear to forget that
11:46
<jgraham>
Philip`: Hmm, that seems unfortunate
11:47
<Workshiva>
You should add an ellipsis before "unfortunate"
11:47
<MikeSmith>
annevk: where?
11:47
<MikeSmith>
ah
11:47
<MikeSmith>
IETF78
11:50
<Philip`>
It also looks like server implementations tend to reject frame types != 0
11:50
<Philip`>
which kind of breaks the whole extensibility model
11:52
<jgraham>
Philip`: I thought that was expected
11:53
<jgraham>
If a client tries to send binary to a server taht can't deal with it, the server disconnects
11:53
<jgraham>
The extensibility model is not purely about having different frame types
11:54
<jgraham>
Also about being able to do feature negotiation in headers and so on
11:57
<Philip`>
Hmm, I don't immediately see a bit in the spec saying the server should disconnect
11:58
<Philip`>
It looks like it should discard the bytes, then set /error/ to true, in which case *a WebSocket error has been detected*, and that's all
12:01
<jgraham>
If /type/ is not a 0x00 byte, then the server may abort these steps and either immediately disconnect from the client or set the /client terminated/ flag.
12:01
<annevk5>
someone from Microsoft is here
12:01
<annevk5>
he's going to edit the requirements document
12:01
<annevk5>
he says he's new in apps
12:01
<jgraham>
Philip`: Isn't that the relevant bit?
12:03
<Philip`>
jgraham: Oh, looks like I was looking at the UA framing algorithm instead
12:03
<jgraham>
Philip`: Yeah
12:03
<Philip`>
which is helpfully titled just "Data framing"
12:35
<annevk5>
we went through requirements
12:35
<annevk5>
nothing really controversial
12:35
<annevk5>
friendly group
12:35
<jgraham>
annevk5: Did the whole "amateur" thing come up?
12:36
<hsivonen>
annevk5: what's the deal with the mailing list looking like it's full of controversy?
12:37
<annevk5>
jgraham, nope
12:37
<jgraham>
annevk5: OK
12:37
<annevk5>
hsivonen, we haven't gotten to the bad parts yet I think
12:41
<Lachy>
whatwg.org seems to be running really slowly today.
12:41
<Lachy>
even hixie.ch is takes forever to respond.
12:48
<annevk5>
nobody here in favor of sentinel framing
12:48
<jgraham>
Not that surprsing
12:49
<annevk5>
I don't really feel strongly so I didn't comment
12:49
<jgraham>
Have they discussed the actual arguments that Hixie put forward?
12:49
<annevk5>
not really
12:49
<annevk5>
"learn to count" was the argument
12:49
<jgraham>
Fuck
12:49
<annevk5>
maybe I should have spoken up
12:49
<annevk5>
hmm
12:50
<jgraham>
If they don't have a better argument than that we will reach an impass
12:50
<jgraham>
e
12:50
<hsivonen>
"learn to count" isn't compelling at this stage of implementations getting shipped
12:51
<jgraham>
It's not compelling full stop
12:52
<jgraham>
A trivial amount of time with google and the string UnicodeDecodeError will show you how common it is to not get encoding/decoding strings right
12:52
<jgraham>
"learn to count" is denial
12:55
<reschke>
Can you *please* raise your concerns in the IETF chat room?
12:56
jgraham
doesn't have a jabber client that does group stuff
12:56
<Ms2ger>
Did someone say "denial"?
12:57
<hsivonen>
I guess it would be easier to ask annevk5 to channel jgraham than to join the not-IRC chat room...
12:58
<annevk5>
I raised the concern about impasse
12:58
<annevk5>
but that was dismissed
12:58
<annevk5>
although it seems relevant
12:59
<Ms2ger>
How very surprising
12:59
<annevk5>
as someone later told me, but he was not the chair or the AD
12:59
<jgraham>
If we dismiss concerns of an impasse we are sure to reach one
12:59
<annevk5>
hsivonen, I channelled jgraham but that was not acceptable
13:00
<hsivonen>
annevk5: not acceptable in the sense that to be heard, one must be present or have an IETF-meeting-compatible Jabber setup?
13:01
<annevk5>
I think so
13:01
<hsivonen>
:-(
13:01
<annevk5>
it seemed rather weird to me as the concern about an impasse should concern all
13:01
<annevk5>
if you have a google account it's pretty easy
13:05
<hsivonen>
http://lists.xml.org/archives/xml-dev/201007/msg00089.html
13:06
<annevk5>
people are now discussing all the ways you can do length encoding
13:07
<jgraham>
Hmm, well I managed to join the room
13:08
<jgraham>
Note to any empathy developers: your UI is crap
13:08
<annevk5>
pidgin is ok
13:08
<jgraham>
Or I am grumpy today
13:08
<jgraham>
or both
13:08
<annevk5>
i'm using Adium for mac atm
13:08
<gsnedders>
jgraham: You're always grumpy.
13:08
<annevk5>
worse than Opera IRC
13:08
<jgraham>
I am unusually grumpy today :(
13:10
<annevk5>
ping me here if you say anything; I'll relay in case it falls through
13:17
<jgraham>
annevk5: It is not really possible to follow much of what is going on from the jabber
13:26
<annevk5>
jgraham, there should be an audio channel
13:32
<Workshiva>
So what kind of magic must I do to chrome to get an actual stacktrace in the console?
13:35
<jgraham>
annevk5: You just said what I was thinking
13:36
<annevk5>
the queue here just gets longer
13:52
<annevk5>
now it's about if a message (event) has the potential to consist of multiple frames
13:52
<annevk5>
i think it was clear long ago this was not controversial
18:58
<dandaman>
swiping gestures are something that can be done in html5 right?
19:08
<henrikbjorn>
dandaman: what do you mean ?
19:09
<dandaman>
henrikbjorn: http://www.youtube.com/watch?v=NrXif_Q6QmY
19:09
<dandaman>
stuff like that
19:09
<dandaman>
where you move your finger accross a certain amount of pixels
19:09
<dandaman>
and it brings a message up
19:09
<henrikbjorn>
dont think it should be or is in the spec
19:10
<henrikbjorn>
its jquery touch
19:10
<henrikbjorn>
a mix of mouse hold and move mose events i think
19:10
<dandaman>
so there is nothing in html5 for this?
19:10
<henrikbjorn>
nope
19:10
<dandaman>
its all going to be plug-ins?
19:10
<henrikbjorn>
why should there be
19:10
<dandaman>
because someone in the #android channel lied to me
19:10
<henrikbjorn>
http://jqtouch.com/
19:10
<dandaman>
and told me its html5
19:11
<henrikbjorn>
thats what you are looking for it
19:11
<dandaman>
or rather could be done in html5
19:11
<dandaman>
hopefully this will work in android
19:11
<dandaman>
because i cant just have it working for iphone only
19:13
<Hixie>
dandaman: HTML is just the markup language, touch would be user interaction events, that's a whole different spec. I recommend asking shepazu in #webapps on irc.w3.org, he's the one working on the DOM Events spec
19:14
<dandaman>
k, thanks for the direction!
19:14
<Hixie>
np
19:16
<Hixie>
othermaciej: it seems, based on http://www.ietf.org/mail-archive/web/hybi/current/msg02634.html, that the "change control" fields in IANA registrations have no effect
19:16
<Hixie>
othermaciej: so we can probably just pass on ISSUE-110
19:18
<dandaman>
remote host closed connection
19:18
<dandaman>
cant connect :(
19:18
<dandaman>
to irc.w3.org
19:18
<dandaman>
weak
19:18
<TabAtkins>
connect to port 6665
19:18
<TabAtkins>
iirc
19:22
<dandaman>
k ty
19:33
<Hixie>
so was anyone at the hybi meeting who can give a meeting report?
19:33
<TabAtkins>
anne's there.
19:46
<jgraham>
Hixie: I listened to some of the audio and saw some of the Jabber
19:46
<jgraham>
But you might be better off waiting for Anne
19:46
<jgraham>
I think I missed most of the intersting bits
20:30
<jgraham>
"""in most languages, you have some sort of
20:30
<jgraham>
write() function call that takes a number of bytes to be written, as opposed to passing in a string, and so most implementers of
20:30
<jgraham>
the protocol would have to know the length of the data anyways."""
20:30
<jgraham>
Is that true?
20:30
<jgraham>
I mean obviously "most languages" is hard to quantify
20:31
<jgraham>
But I don't remember ever having to specify the number of bytes I wanted to output
20:31
<TabAtkins>
Yeah, that seems... completely false.
20:31
<TabAtkins>
You sometimes have to say how many bytes you want to *read*, but that's it.
20:38
<Philip`>
It's true if "most languages" is C/C++/Java
20:39
<Philip`>
Scripting languages tend to mix up byte-arrays and strings so it seems much more common for them to just dump a whole string onto the socket
20:44
<TabAtkins>
Indeed, but the popular languages on servers these days are all "scripting languages".
20:44
<TabAtkins>
PHP's socket_write, frex, *accepts* an optional length parameter, but if you don't specify it it just writes the string into the socket.
20:45
<mikekelly>
hi I have a question about <device>
20:52
<othermaciej>
Hixie: I'd certainly like to duck that issue if possible
22:19
Hixie
wonders where he put his getContext() notes
22:19
<jamesr>
canvas getContext()?
22:21
<Hixie>
yeah
22:24
<jamesr>
it should be async yaknow
22:24
<jamesr>
sucks to have to block script while you create the context
22:24
<jamesr>
especially for 3d where you might have to spin up graphics card drivers, etc, before you know if you can actually create the context
22:27
<Hixie>
jamesr: yeah well it's too late to change that
22:29
<Philip`>
It's not too late to make breaking changes to WebGL
22:29
<Philip`>
and a new getAsyncContext could be added for that
22:29
<Philip`>
if people really care
22:29
<Hixie>
or we could just get the context returned for webgl be something that stores calls until such time as it's ready
22:30
<jamesr>
you'd still have to block on anything that queries state
22:31
<jamesr>
actually that still doesn't work
22:31
<jamesr>
if context initialization fails you have no way to indicate that if you return a buffering context
22:32
<Hixie>
why would context initialization fail?
22:33
<TabAtkins>
getContext("doesNotExist")?
22:33
<Hixie>
that doesn't need to be async
22:33
<jamesr>
getContext("webgl") when the underlying system doesn't support webgl
22:34
<Hixie>
why would the underlying system not support webgl?
22:34
<jamesr>
for example if the system's graphics card drivers fail to initialize, what's the UA supposed to do?
22:34
<Hixie>
fake it?
22:36
<jamesr>
seems nicer to tell the page that it can't have a webgl context than to return a seemingly-valid context that actually does nothing
22:36
<othermaciej>
GL can be done with software rendering
22:36
<othermaciej>
so in some sense there is no such thing as "hardware that doesn't support it"
22:36
<othermaciej>
though software rendering could be unusably slow
22:36
<Hixie>
i mean fake it as in implement webgl slowly
22:37
<Hixie>
just not providing it seems like a useless failure condition
22:37
<Hixie>
no site is ever going to check for that
22:37
<Hixie>
so they'll just crash
22:37
<jamesr>
every webgl site i've ever visited checks for context creation
22:37
<othermaciej>
sites will only check for it if it occurs commonly enough for them to run into it
22:37
<jamesr>
since it commonly fails
22:38
<Hixie>
sure but it fails because browsers don't implement it, not because they don't have driver support
22:38
<TabAtkins>
It commonly fails *now*. In the future it shoudln't.
22:38
<othermaciej>
right now sites have to test because no shipping browser supports WebGL on by default yet