00:00
<zewt>
man, gmail is totally broken right now
00:00
<zewt>
every time i click a reply box, it scrolls up to the top of the mail i'm replying to
00:31
<zewt>
heh StreamBuilder: If there is enough data available to satisfy the amount requested in the read, return the amount specified. The data should be returned in the order the data was appended.
00:31
<zewt>
should :(
00:56
<Garbee>
zewt, gmail is working fine for me.
01:00
<zewt>
(fyi, not everyone sees the same gmail at the same time)
01:01
<Garbee>
Yea, but are you sure it isn't a plugin messing with it?
01:01
<zewt>
i was seeing it at work in chrome, and now at home in firefox; just smells like i've been stuck in a crappy bucket and I just have to wait for it to wear off
01:06
<Garbee_>
yea, hopefully it will go away in a little bit.
01:06
<Garbee_>
I'm stuck in Freenode hell right now myself. Maybe when I get online in the morning it will be fixed.
01:22
<jamesr>
is the CSS 'display' property defined as animatible currently? where is it defined (or at least its animatibility)? and how the heck do you spell that word?
01:24
<zewt>
no idea about the answer, except that it wouldn't seem to make sense (animate from inline to block?)
01:25
<jamesr>
well presumably it'd animate like any other discrete thing
01:25
<jamesr>
jump from one value to the other at some point
01:26
<zewt>
but it'd have to reflow, which means in theory every block on the page might have to animate somehow
01:27
<jamesr>
that's true of almost any property that can be targetted by an animation
01:28
<zewt>
not most properties i've animated, at least (topp/left in pos: absolute, opacity, transforms, etc)
01:28
<jamesr>
if you animate something to the side such that it causes a vertical scrollbar it'll reflow the world
01:28
<jamesr>
and that just happens suddenly at some point in the animation
01:28
<zewt>
sure, but that just reflows when you cross the boundary
01:29
<jamesr>
and this would reflow whenever the 'display' value changes to a new thing
01:29
<zewt>
if you're animating from block to inline, there's some kind of continuous change happening to everything affected by it
01:29
<jamesr>
no there isn't. look, if you don't know the answer feel free to just say you don't know
01:29
<zewt>
i guess i can't picture what "50% block 50% inline" would mean, visually
01:29
<zewt>
wow, no need to be a dick
01:30
<jamesr>
nothing wrong with that. i don't know where it is either
01:30
<zewt>
in case you didn't read, the very first thing I said is that I don't know the answer
01:30
<zewt>
ending conversation, too irritated
01:34
<zewt>
(sorry, overreacted a bit, but conversing about a question is an ordinary thing on irc)
01:36
<astearns>
jamesr: I think I can say that the animatability of 'display' is not currently defined anywhere. It's not defined in any of the places I'd expect the definition to be, anyway
01:36
<jamesr>
astearns, do you know where the 'display' property itself is defined?
01:36
<tantek>
CSS 2.1
01:37
<jamesr>
ah, appendix F
01:37
<astearns>
jamesr: in CSS2.1 and the new level 3 Display module http://dev.w3.org/csswg/css-display-3/
01:38
<astearns>
but (TabAtkins) the new module says to look to the "individual properties" to see what's animatable, then those properties don't say if they are
01:38
<jamesr>
css transitions has an 'Animatable' section on each property, for instance
01:38
<jamesr>
so looks like the answer is css-display-3 needs to add this row to its tables of property definitions
01:38
<astearns>
yep
01:39
<jamesr>
it has "Animatable: see individual properties" for the "display" shorthand itself
01:39
<jamesr>
it'll get there, i suppose
01:39
<astearns>
I expect display-box would not be animatable. Not sure about the rest
01:45
<JonathanNeal>
Where is the part of the spec that talks about how to validate an element name or a classname?
02:20
<esprehn>
zewt: I thought we weren't doing StreamBuilder yet
02:20
<esprehn>
or rather, that we were going to replace it with new Stream() like BlobBuilder I'd hope
02:21
<zewt>
esprehn: no idea; all I know about Streams is reading the spec
02:22
<esprehn>
ah
02:22
<zewt>
BlobBuilder is dead (or legacy), right? replace by new Blob()
02:22
<zewt>
replaced
02:22
<zewt>
(however it's constructed I wouldn't expect it to affect those issues, though)
02:23
<zewt>
Steam, I mean
02:24
<zewt>
... Stream (accursed laptop)
02:28
<moo-_->
zewt: yes
02:29
<moo-_->
dead like a doornail
02:32
<zewt>
doing "new Stream" would want to be a subclass of Stream, since you wouldn't want system-provided Streams to also have the StreamBuilder API, but other than that, makes sense
02:32
<zewt>
(though less of a win, since you still end up with two classes)
03:14
<esprehn>
zewt: new WhateverSystemStream I guess, or Stream.create(...) might be okay. The builder stuff is full of sadness
03:30
<zewt>
esprehn: more concerned about the brittle interop smell of script-sourced streams as a concept
03:30
<zewt>
sounds like something that's tempting and sounds useful but might bite everyone in the ass badly long-term
06:01
<nessy>
Hixie: yt?
06:54
<JonathanNeal>
TabAtkins: did you write your js css parser using a tool, or just straight up in js?
09:58
<JonathanNeal>
any string parsers up?
10:14
<SimonSapin>
JonathanNeal: not sure what you mean by string parser, but I’m pretty sure this one https://github.com/tabatkins/css-parser is written manually based on the algorithms in the spec
10:14
<SimonSapin>
IIRC it’s even a goal to be very close to the spec
10:15
<JonathanNeal>
Trying to parse "{0 {1 {2 {3} 2} 1} 0} {0 {1 {2 {3} 2} 1} 0}" into a hierarchy.
10:17
<SimonSapin>
JonathanNeal: if you’re okay with CSS tokens I suppose you could use css-parser and repeatedly call consumeAPrimitive()
10:18
<jgraham>
JonathanNeal: Hmm, are you actually trying to parse CSS or some custom thing?
10:19
<SimonSapin>
but writing recursive decent parsers for simple languages is not too hard
10:19
<JonathanNeal>
some custom thing :) plus i've always wanted to better understand parsers.
10:21
<jgraham>
Well that specific thing doesn't look too hard
10:23
<jgraham>
I mean there are only 3 tokens and no need for lookahead
10:26
<zcorpan>
i don't understand why this fails. :-( http://w3c-test.org/webapps/WebSockets/tests/submissions/Opera/interfaces/WebSocket/close/005.html i don't spot any difference from the old test which passes
10:28
<jgraham>
zcorpan: Which assert fails?
10:28
<zcorpan>
the first in the onclose hanlder
10:29
<JonathanNeal>
jgraham: like this? http://codepen.io/jonneal/pen/hHIzF
10:30
<Ms2ger>
zcorpan, the readyState one?
10:31
<zcorpan>
Ms2ger: yes
10:31
<Ms2ger>
Passes on Fx, it seems
10:31
<zcorpan>
huh, fails for me in firefox
10:31
<Ms2ger>
But I get assert_equals: expected 3 but got 0
10:32
<Ms2ger>
So, passes is a big word :)
10:32
<Ms2ger>
And, uh, timeouts :/
10:33
<zcorpan>
yeah, i guess the timeout can be reduced a lot
10:38
<zcorpan>
ah! s/step/step_func/ makes it pass
10:38
<zcorpan>
so subtle
10:39
<jgraham>
Horray for weak typing?
10:41
<jgraham>
(if you can think of any way I can make it easier to avoid that error please say)
10:46
<zcorpan>
i guess i would have noticed it sooner if i stepped through the script in a debugger
10:48
<zcorpan>
or make step() return a function that gives a warning somewhere
10:56
<zcorpan>
jgraham: i'll implement the warning thing
10:59
<annevk>
http://www.w3.org/TR/2013/WD-html-longdesc-20130312/
10:59
<annevk>
I always thought it was McCathieNeville
11:00
<annevk>
one l
11:02
<SteveF>
annevk: I am now retiring my accessibility work is done!
11:02
<annevk>
no man, need longdesc for <main>
11:03
<SteveF>
oops yeah back to work...
11:04
<SteveF>
am secretly working on longdesc for longdesc but its a secret
11:04
<annevk>
I heard rumors about <img extralongdesc=""> for people that are beyond blind
11:06
<SteveF>
am no longdesc lover, but am pleased the draft has been published so I don't have to think about it anymore
11:07
<SteveF>
though I am a lover and do have a long desk
11:08
<zcorpan>
jgraham: hmm. step() can throw, which makes it a bit hard to make it return a warning function
11:10
<SteveF>
photo of my long desk https://twitter.com/stevefaulkner/status/309984608001343488
11:10
<zcorpan>
that is kinda a showstopper. can't think of a way around it
11:10
zcorpan
drop it
11:11
<zcorpan>
+s
11:12
<marcosc>
annevk: in XHR, when an event is fired on "onerror", it passes a ProgressEvent. I'm not clear how one gets at the actual "error"? I was expecting some kind of error object to be available.
11:13
<annevk>
marcosc: there's no such thing
11:14
<marcosc>
annevk: sure, but I was kinda hoping for a http://dom.spec.whatwg.org/#dom-domexception-network_err
11:14
<annevk>
marcosc: it's equivalent
11:14
<annevk>
error event is the async version of that
11:15
<marcosc>
ok, what I was after was the details of why it failed. I wanted to display those details or try to do something with them.
11:16
<annevk>
right, there's no such thing
11:17
<marcosc>
Maybe something for XHR level 3? :)
11:17
<zcorpan>
marcosc: exposing to web content why a network request failed is generally considered a security issue
11:17
<annevk>
Fetch exposes 1) end-user abort, 2) network error, 3) redirect (sometimes), 4) everything else
11:17
<annevk>
marcosc: there's no levels anymore
11:17
<annevk>
marcosc: and what zcorpan said
11:17
<marcosc>
ok, makes sense. Just wanted to check the rationale
11:24
<zcorpan>
marcosc: related: hybi tried to expose error reason but that just led to the API spec overriding it http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#closeWebSocket
11:25
<marcosc>
zcorpan: thanks!
11:25
<zcorpan>
which happened instead of just fixing the protocol spec because people who understand web security had got fed up and stopped paying attention to hybi
11:28
<marcosc>
ok, one more dumb question: when I try to fetch the following URL (http://www.w3.org/TR/2003/NOTE-acdi-20030901), it returns a 301, which causes XHR to throw the error. My understanding is that XHR should do the redirect. What am I missing?
11:28
<darobin>
did you set any specific headers?
11:29
<marcosc>
darobin: no
11:30
<marcosc>
it craps out with http://marcoscaceres.github.com/bib_entry_maker/
11:30
<annevk>
marcosc: does the redirect have CORS headers supplied?
11:30
marcosc
looks at darobin :)
11:30
<annevk>
marcosc: I think you're hitting that
11:31
<darobin>
hey you can use curl just as well as I!
11:31
<darobin>
indeed, that's the bug
11:31
<darobin>
I'll alert systeam
11:31
<marcosc>
thanks darobin :)
11:33
<marcosc>
darobin: fwiw, I think some of the really really old specs (pre 2000) also have some CORS issues.
11:34
<Ms2ger>
I think that's the least of their issues
11:34
<marcosc>
heh
11:35
<darobin>
marcosc: that might be possible
11:35
<darobin>
I don't know when the current system was set up — there's weird stuff in the oldies
11:36
<marcosc>
yeah, they must be on another server or something
11:36
<darobin>
like this http://www.w3.org/TR/1998/REC-xml-19980210
11:36
<marcosc>
oh man! I'm so gonna start using that BG!
11:36
<darobin>
that one's under CORS alright
11:36
<darobin>
it was all the rage back then
11:37
<darobin>
it makes the specs so readable
11:37
<marcosc>
it's like I'm reading paper
11:37
<Ms2ger>
The PNG spec has it too
11:37
<darobin>
http://www.w3.org/TR/REC-CSS1-961217
11:37
<marcosc>
I even reached out to my screen only to realise that it was not a real thing
11:38
<darobin>
I have fond memories of spending a lot of time with http://www.w3.org/TR/REC-CSS1-961217#appendix-b as my first serious computer hacking project :)
11:38
<marcosc>
and red links FTW!
11:38
<darobin>
I think I still have that background imprinted in my retina
11:38
<marcosc>
heh
11:38
<darobin>
gotta love statements like "The grammar below is LL(1) (but note that most UA's should not use it directly, since it doesn't express the parsing conventions, only the CSS1 syntax)."
11:39
<marcosc>
:)
11:39
<Ms2ger>
"Spec? What spec?"
11:41
<annevk>
"We drank too much to figure out the details, but you know, we had a good time and we think this'll improve the web quite a bit."
11:41
<darobin_>
"If you want to know the parsing conventions we're talking about, no problem, just drop by for a beer" is how I read it
11:42
<annevk>
Which they did, which is why we ended up reverse engineering IE, which was a lot less fun.
11:43
<Ms2ger>
darobin, btw, still waiting for you to move the tests repo
11:44
<darobin>
ah yes, I could do that :)
11:44
<darobin>
annevk: we should've accepted that beeer
11:44
<marcosc>
Ok... now I need to somehow convince the IETF to enable CORS
11:45
<annevk>
hahaha
11:45
<annevk>
too early for jokes man
11:47
<darobin>
marcosc: you might mention something about using HTML while you're there
11:47
<darobin>
oh, and UTF8
11:47
<marcosc>
lets not go crazy
11:47
<darobin>
marcosc: see Twitter
11:48
<darobin>
IMHO your best shot at it
11:48
<marcosc>
heh
11:48
<darobin>
marcosc: I'll let you reply to Mark
11:49
<marcosc>
ok, thanks
11:49
<marcosc>
Once he sees the awesome biblio entry maker, he will make it happen
12:02
<annevk>
so Stream
12:03
<annevk>
what was the reason to have a separate reader object for file?
12:07
<annevk>
I hope somebody knows
12:09
<hsivonen>
lovely charset stuff: https://mxr.mozilla.org/mozilla-central/source/content/base/src/nsXMLHttpRequest.cpp#2661
12:11
<annevk>
hmm
12:11
<annevk>
so the spec asks for lowercasing at the moment I Think
12:11
<annevk>
man
12:27
<jgraham>
darobin: You know that thing about "don't use this grammar" is still in 2.1, right?
12:31
<darobin>
jgraham: yeah but I prefer the original source, it has more style
12:39
<zcorpan>
jgraham: OK i've gone through all the websocket tests now and fixed things i noticed were wrong
12:39
<zcorpan>
jgraham: should i let someone know?
12:41
<jgraham>
zcorpan: public-webapps-testsuite
12:41
<jgraham>
Reply to the last mail I sent there, I guess
12:41
<zcorpan>
i found an old thread, yeah
12:42
<zcorpan>
it's kinda funny that people complained about the proposed timeline
12:42
<jgraham>
http://www.w3.org/mid/512F18DB.3010503⊙oc is the message to reply to infact
12:43
<zcorpan>
hmm, i guess i'm not subscribed, can't find that in my inbox
12:44
<jgraham>
Subscribe and download the archive files?
12:44
<zcorpan>
seems like bad use of my time :-) i'll just reply to another message and link to the above
12:45
<zcorpan>
and subscribe
12:45
<jgraham>
Fair enough :)
12:47
<jgraham>
Would be kind of useful if mail clients let you set the In-Reply-To header
12:47
<jgraham>
(well I guess some do)
12:47
<darobin>
some clients allow you to show arbitrary headers
12:47
<darobin>
even Mail.app supports that
12:47
<darobin>
the problem is usually getting them to show it in a useful way
12:51
<jgraham>
I mean set when you compose.
12:51
<zcorpan>
jgraham: what's next? postMessage?
12:52
<jgraham>
Possibly register*Handler since that seemed to be almost good to go. But certainly postMessage is the other option
12:53
<zcorpan>
i don't see postMessage in my critic dashboard. but register*Handler is there
12:53
<jgraham>
Right, there isn't a review for postMessage
12:53
<jgraham>
I could create one I guess
12:54
<zcorpan>
ah, ok
12:55
<hsivonen>
annevk: so the File API allows the caller to pass an encoding
12:55
<hsivonen>
annevk: and currently, Firefox throws if the encoding is bogus
12:56
<hsivonen>
annevk: if the BOM overrides, what should happen when there is a BOM and bogus encoding argument?
12:56
<hsivonen>
should the BOM just take precedence
12:56
<hsivonen>
or should the bogosity of the argument be checked first?
12:57
hsivonen
is quite unhappy that Firefox's File API impl asks the magic 8-ball for charset instead of doing what the spec says and just falling back to UTF-8
12:58
<jgraham>
zcorpan: Created a review for those tests
13:00
<annevk>
hsivonen: see my email to public-webapps
13:02
<hsivonen>
annevk: File API review?
13:02
<annevk>
hsivonen: yeah, I told sicking that would be a BAD IDEA®
13:03
<annevk>
hsivonen: yeah, end of http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0707.html
13:04
<hsivonen>
annevk: ok, so throw first
13:04
<hsivonen>
annevk: afaict, WebKit does not throw
13:04
<hsivonen>
and doesn't sniff for BOM, either
13:04
<annevk>
hsivonen: yeah, the current spec does not say to throw
13:05
<annevk>
hsivonen: not looking for the BOM seems like a bug per current spec
13:06
<annevk>
hsivonen: I don't care strongly about the throwing I suppose, although it would be consistent with TextDecoder as I noted in my email
13:08
<hsivonen>
annevk: OK. I'll keep throwing in my patch
13:31
<annevk>
Btw, http://www.w3.org/TR/2013/WD-html-longdesc-20130312/#widl-Element-longdesc is bogus, but I'm not sure if anyone cares...
13:31
<hsivonen>
annevk: wait, when did you tell sicking that using chardet was a bad idea?
13:32
<SteveF>
annevk: have pinged chaals
13:33
<annevk>
hsivonen: dunno, seems it might have been four years ago now?
13:33
<hsivonen>
annevk: whoa. so before review and that stuff still landed?
13:35
<jgraham>
If only the spec had a testsuite and people felt bad about failing it
13:37
<annevk>
hsivonen: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1105.html is my earliest feedback
13:38
<annevk>
hsivonen: can't actually find where I said that "doing detection" would be bad because it's not interoperable
13:53
<annevk>
darobin: seems your b-day coincides with red nose day
13:54
<darobin>
annevk: that's, errm
13:54
<annevk>
apt?
13:54
<darobin>
I guess!
13:55
<darobin>
I think it'll be at the Royal Oak in Bethnal Green
13:55
<darobin>
(to be confirmed though)
13:57
<annevk>
that's a bit out of the way, but should be okay
14:03
<darobin>
Bethnal Green rocks :)
14:03
<hsivonen>
not only does File API use the detector, but it uses the detector through the wrong API...
14:04
<jgraham>
darobin comes all the way from France, and you think that going < 10 tube stops is "a bit out of the way"?
14:04
<annevk>
it's like 40min according to Google Maps, though I might be able to avoid the tube by taking a bus
14:05
<jgraham>
(that probably needed a smilie)
14:05
<darobin>
jgraham: in .nl, ten tube stops takes you to Belgium, give him some time to adapt
14:05
<annevk>
I could also walk, which it estimates at 1:07 which is not all bad
14:05
<SimonSapin>
annevk: do you dislike the tube that much?
14:06
<annevk>
SimonSapin: no, the tube connection to there is just bad
14:06
<jgraham>
(seems like bethnal green tube station is <20 minutes by tube from Leicester Square, which is near Moz. at least, iirc)
14:07
<annevk>
(the pub is not next to that station)
14:09
<jgraham>
No
14:09
<jgraham>
It's not next to *any* station
14:15
<annevk>
but it is next to a bus stop :)
14:16
<annevk>
We should maybe put something here about architecture otherwise management might think we're slacking off, solely discussing London's public transport for a b-day party next Friday (not even today!)...
14:20
<jgraham>
I hate MySQL
14:21
<jgraham>
I think that has me covered
14:22
<annevk>
<css/>
14:22
<zewt>
heh
14:23
<zewt>
mysql pretty much seems like what novices pick because nobody told them about postgres
14:23
<jgraham>
In this case that might well be true
14:23
<jgraham>
(actually it might well be Hixie that picked MySQL back in the dawn of time)
14:24
<jgraham>
(I'm not sure)
14:25
<zewt>
"lamp" is probably the single worst open-source quasi-marketing fad there was
14:26
<zewt>
"hey everyone! you should use these three bad technologies so you fit the acronym"
14:26
<jgraham>
Is apache "bad"
14:26
<jgraham>
?
14:27
<jgraham>
(ngix might be better, but it didn't exist at the time)
14:27
<zewt>
well, it's not so good that it should be used without evaluation, at least
14:28
<zewt>
i think it's more the "stop thinking and just use this set of things"-ishness of it all that i found unpleasant
14:28
<jgraham>
So, if anyone does know why MySQL allows you to override the charset and the collation on a per-connection basis, and how I fix the collation to be utf8_bin, that would be helpful
14:29
<zewt>
dear gmail: stop logging me out while i'm writing mail. thanks
14:29
<jgraham>
(Well I can do SET NAMES ...) but I don't know how that interacts with sqlalchemy, exactly
14:29
<annevk>
jgraham: maybe matjas?
14:29
<annevk>
dunno if he's online
14:37
<darobin>
fwiw when LAMP was minted it was descriptive of a practice, not an attempt to prescribe or sell it
14:39
<jgraham>
"The description in the following sections may appear complex, but it has been found in practice that multiple-level defaulting leads to natural and obvious results."
14:39
<zewt>
giggle
14:40
<jgraham>
I believe that is the "I'm high as a kite" moment
14:41
<zewt>
tip to anyone running a business: if the user email thing you use calls itself "constant contact", you're a spammer
14:43
<matjas>
jgraham: check the mysql.conf settings in this post http://mathiasbynens.be/notes/mysql-utf8mb4
14:43
<matjas>
err, /etc/my.cnf
14:43
<matjas>
jgraham: also, why utf8_bin and not utf8mb4_bin?
14:44
<jgraham>
matjas: Don't tell me, I can guess this one, utf8 doesn't actually let you store all of unicode?
14:44
<matjas>
jgraham: you guessed it.
14:44
<matjas>
MySQL’s `utf8` is a lie
14:45
<jgraham>
OK, I was wrong
14:45
<jgraham>
The "high as a kite" moment came long before they got to the documentation
14:48
<gavinc>
yeah, but utf8mb4 means that all the things you think about how big indexs are and how long the built in types are, are wrong :(
14:49
<gavinc>
a number of places that say "characters" mean, sets of bytes / 3, not bytes / 4
14:50
jgraham
would be happy if all the things he thought about how equality works were right
14:50
<annevk>
Oh yes, we have a NES at the office!
14:52
<zewt>
sad when I make a big list of what seem to me like horrifying complex interop nightmares, and the reply ignores them all and just goes "but it's easier to implement"
14:56
<zcorpan>
{if(themALL.code = DOMException.SECURITY_ERR)
14:56
<zcorpan>
{e++}
14:57
<zcorpan>
jgraham: it seems safe to assume that the above was meant to be ==, right?
14:58
<jgraham>
zcorpan: Yeah
15:18
<jgraham>
zcorpan: (I'm sure it meant to be === :)
15:18
<zcorpan>
jgraham: i made it == :-P
15:19
<zcorpan>
ok i'll call it a day now. will finish my batch of converting URLs to be server-agnostic and commit that on monday
15:20
<zcorpan>
have a nice weekend
15:20
<jgraham>
You too
15:21
<zcorpan>
it doesn't start all too well. i blame brucel for that...
15:22
<zcorpan>
i hope i have recovered on monday at least
15:22
<zcorpan>
anyway
16:07
<annevk>
zewt: fwiw, I agree with sicking et al that passing of Stream from XHR is weird
16:08
<annevk>
zewt: and counter to the model
16:08
<zewt>
i think the "xhr keeps running" thing is completely batshit insane
16:08
<zewt>
and that returning the stream fits the model--start request, something happens, onload fires when the result is available--quite well
16:09
<annevk>
no, the model is that you wait for the complete response, including its entity body, or just wait forever if that happens to load forever
16:09
<zewt>
nothing about the xhr api implies that
16:09
<annevk>
stream is just another way to expose the resonse entity body
16:10
<annevk>
response*
16:10
<annevk>
XHR controls the entire request/response, everything implies that
16:11
<zewt>
nothing i can see :)
16:11
<zewt>
and i think that's a minute concern anyway, compared to all the issues with doing it that way
16:12
<zewt>
every time i think about it, whole new issues come to mind
16:12
<jgraham>
It does seem pretty odd to have an XHR that will never fire onload
16:13
<jgraham>
But doesn't have an error
16:13
<annevk>
zewt: I don't think there's that many issues to be honest
16:14
<annevk>
jgraham: it will fire onload once the connection closes
16:14
<jgraham>
"yay"
16:14
<jgraham>
I mean, that seems rather useless
16:14
<zewt>
i've listed quite a number, so by all means reply to a few :)
16:14
<zewt>
(on the list, can't get into that much detail right now)
16:15
<annevk>
zewt: the event ordering thing is just getting all the task sources right, sync xhr and streams seems pointless, ...
16:15
<jgraham>
It is pretty clear in general that people want a way to hook into "this data is usable now"
16:15
<zewt>
sync xhr and streams isn't useless at all; let me open a synchronous request in a worker and parse the result as it comes in
16:15
<annevk>
jgraham: ah yeah, we should maybe have an event for when the headers are in / first bit of entity body is in
16:17
<jgraham>
Why wouldn't we call that event "load"?
16:17
<annevk>
zewt: since the parsing is async anyway it doesn't have to be loaded sync
16:17
<annevk>
jgraham: because load means the entity body is in
16:17
<zewt>
sorry, don't understand that
16:17
<annevk>
k
16:17
<jgraham>
annevk: That's a very low-level view
16:17
<zewt>
for example, if you wanted to implement something EventSource-like in a worker
16:18
<jgraham>
To put it differently, what's the use case for load being after the stream is closed?
16:19
<zewt>
given a synchronous version of StreamReader (there isn't one yet, but that's a separate problem), you'd just run a sync XHR to create the Stream, then use StreamReader to synchronously read data as it comes in--this seems very useful
16:25
<annevk>
jgraham: tick the progress bar
16:25
<Ms2ger>
jgraham, yt?
16:26
<jgraham>
Ms2ger: For a few seconds
16:26
<jgraham>
annevk: Don't really see how that's a use case for load-after-close
16:26
<jgraham>
Could be a use case for a close event on the stream
16:26
<Ms2ger>
jgraham, do you know what the has_assertions() is for in the testharness.js results table code?
16:27
<zewt>
jgraham: well, i wouldn't necessarily say that we need use cases for side-effects of design
16:27
<annevk>
jgraham: euhm, the stream is somewhat distinct from network transfer
16:27
<annevk>
jgraham: you wouldn't want your progress bar implementation to have to hook into different objects
16:29
<jgraham>
Ms2ger: Not obviously. I am thinking that git blame will point at Aryeh. I will look more at home in a bit
16:29
<Ms2ger>
Mm
16:29
Ms2ger
looks
16:30
<Ms2ger>
Huh, no, to Peter
16:30
<jgraham>
Right, I was just thinking
16:31
<jgraham>
This is probably to do with the stuff for extracting metadata from the test file
16:31
<Ms2ger>
Oh, that kind of assertions
16:31
<Ms2ger>
Meh
16:31
<jgraham>
You can do something like test(function(){}, name, {assert:"Somethihng from a spec"})
16:31
<jgraham>
Yeah, quite confusing
16:32
<jgraham>
Shouldn't have let that through code review I think, but oh well
16:41
<Ms2ger>
jgraham, btw, is the result table the only user of the templating code?
17:08
<dglazkov>
good morning, Whatwg!
17:09
<annevk>
good afternoon dglazkov
17:11
<annevk>
pushed an update to http://html5.org/temp/fetch.html btw; now maps Hixie-stuff to annevk-stuff
17:13
<annevk>
Hixie: fwiw, I can probably change it back completely, but I think that once we unravel the various request/response things for offline we're going to end up with the kind of request/response model this thing outlines so I'd rather just go there...
17:13
<slightlyoff>
annevk: I owe you a read-through of that
17:13
<slightlyoff>
annevk: would love seeing it in pseudo-code instead of prose, though = (
17:14
<annevk>
slightlyoff: there's http://wiki.whatwg.org/wiki/Fetch#Pseudo-code though it's not entirely accurate anymore
17:14
<annevk>
slightlyoff: but it gives a high-level overview that's somewhat accurate and illustrates some of the weirdness
17:14
<slightlyoff>
aha! thanks.
17:15
<slightlyoff>
I enjoy that this is Python...the language of the web! ;-)
17:16
<annevk>
I find Python more writable and readable than JavaScript and since I don't have to run it anywhere...
17:17
<Ms2ger>
We all hate JS here
17:17
<Ms2ger>
That's why we work on the DOM :)
17:18
<dglazkov>
I don't hate JS
17:18
<annevk>
Right, the DOM will supplant JavaScript eventually :p
17:18
<dglazkov>
I try not to hate anything
17:19
<annevk>
dglazkov: you're not following the channel rules
17:20
<annevk>
(there are none, but you also do and do not have to leave your sense of logic at the door)
17:21
<slightlyoff>
Ms2ger: it shows? ;-)
17:22
<tobie>
slightlyoff: :(
17:23
<annevk>
I usually don't design APIs, but when I do, it shows.
17:23
<slightlyoff>
hah
17:23
<slightlyoff>
= )
17:23
<annevk>
Seriously though, I'm mostly documenting a mess created ten years ago, plus CORS, which is only partly my fault.
17:28
<MikeSmith>
vindication http://lists.w3.org/Archives/Public/public-webapps-testsuite/2013Mar/0015.html Indeed something wonky in MS Redmond network that was causing websocket test failures
17:29
<MikeSmith>
advantage jgraham
17:30
<karlcow>
Oh pseudo-code I can read! http://wiki.whatwg.org/wiki/Fetch#Pseudo-code ♥ annevk
17:31
<annevk>
Maybe we should just write specs in Python/JavaScript rather than English
17:31
<karlcow>
\o/
17:31
<annevk>
<- not serious
17:31
<Ms2ger>
Why not brainfuck?
17:32
karlcow
proposes pseudo-Haiku for minimalism
17:33
<annevk>
Why not Zoidberg?
17:33
<Ms2ger>
Because he's not a programming language
17:38
<MikeSmith>
in programming languages were people, INTERCAL would be me
17:39
<jgraham>
Ms2ger: Yes
17:43
<jgraham>
MikeSmith: So what to do about the websockets thing? Do you actually see the websockets requests for the Microsoft IPs?
17:45
<jgraham>
Ms2ger: Well actually
17:45
<jgraham>
I don't know about the testharnessreport.js that plinss wrote
17:46
<MikeSmith>
jgraham: didn't check yet. I am considering to not do any further troubleshooting of their effed up network for them until they pay me for the invoice I submitted to them for the time I already spent. Which to be fair was probably less than 1 hour total, but I bill at Oracle DBA rates.
17:46
<Ms2ger>
Doesn't look like it
17:47
<MikeSmith>
jgraham: seriously I plan to do nothing except to support moving them into approved
17:47
<jgraham>
MikeSmith: heh
17:48
<jgraham>
Anyway, my suspicion is that it is indeed something on the Microsoft network that's causing the problem
17:48
<MikeSmith>
yup
17:48
<jgraham>
But it looks like Ken believes that the W3C might be treating requests from Microsoft differently
17:49
<jgraham>
So it would be good to rule that out
18:06
<MikeSmith>
jgraham: if W3C is treating requests from MS differently it would be because our network defenses are doing it for a good reason
18:07
<MikeSmith>
e.g., them having some tools that end up making abusive amounts of DTD requests
18:07
<MikeSmith>
DTD DDoS
18:09
<jgraham>
Well yeah, it could be
18:09
<MikeSmith>
actually now that I say that I recall that have in fact already had some specific problems with MS and W3C network that I never heard any resolution about it
18:09
<jgraham>
I don't really see why rate limiting would cause this type of problem though
18:10
<MikeSmith>
yeah it was not a simple rate limiting problem
18:10
<MikeSmith>
I think it may not have even been the W3C network specifically but instead som MIT network defenses
18:11
<jgraham>
Interesting
18:12
<jgraham>
I wonder why it would affect websockets in particular
18:12
<jgraham>
(also, the irony of Microsoft not being able to access tests on a server that they paid for is not lost on me)
18:12
<MikeSmith>
heh
18:22
<Hixie>
christ, the w3c continues its "stable" nonsense
18:26
<marcosc>
:)
18:26
<marcosc>
speaking of which, we are remaking the famous red bar at the bottom of specs: https://github.com/ResponsiveImagesCG/picture-element/issues/21
18:30
<karlcow>
Well Microsoft doesn't always fix their product, even when told. :)
18:30
karlcow
has his own story with a lunar calendar
18:31
<Hixie>
hm, still no heycam
18:31
<Hixie>
is he on vacation?
18:31
<Ms2ger>
Yeah
18:32
<Hixie>
k
18:32
Ms2ger
checks the dates
18:32
<Hixie>
no worries
18:32
Hixie
punts the bug to Q2
18:32
<Ms2ger>
That's probably best
18:33
<Ms2ger>
I suspect he'll spend the rest of Q1 on email backlogs :)
18:34
<Ms2ger>
Looks like heycam is away until the 24th
18:36
<karlcow>
though it seems Apple is no better.
18:37
<jgraham>
karlcow: You were bitten by a Microsoft employee and now you can't go out at the full moon?
18:37
<karlcow>
grep MoonPhase.ics access.log.132* | grep "Feb/2012" | wc -l
18:37
<karlcow>
516354
18:37
<karlcow>
"GET /2002/09/13-MoonPhase.ics HTTP/1.1" 410 319
18:38
<karlcow>
half a million requests last February for a file which 410 Gone.
18:38
<karlcow>
which is
18:39
<karlcow>
These days it seems to be mostly coming from iOS and DataAccess
18:39
<karlcow>
I guess Microsoft Outlook finally removed it from distribution.
18:40
<karlcow>
the initial file (Gone now) had a cache information for years, but any kind of calendars are still checking everything 30 minutes or so.
18:41
<internaut_jack>
Looks like the "contenteditable" attribute doesn't allow <label> elements to be edited.
18:41
<karlcow>
Sometimes I wonder if instead I should put a calendar with a repeating event every day that would fill the calendar of people
18:41
<internaut_jack>
As in, they look like they should be able to be edited, and the text can be *deleted*
18:41
<internaut_jack>
But not typed
18:41
<internaut_jack>
Anyone seen this?
18:42
<Hixie>
internaut_jack: sounds like a browser-specific issue
18:42
<internaut_jack>
This is in Chrome 25.0.1364.155
18:42
<internaut_jack>
Would someone please validate? I'll file a bug if it can be replicated.
18:47
<Hixie>
seems to work fine for me
18:47
<Hixie>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2137
18:54
<internaut_jack>
Hixie, the div has the contenteditable attribute in your example, rather than the label
18:54
<internaut_jack>
Try putting it right on the label element itself
19:15
<garciawebdev>
can i use any values on the rel attribute? or just the ones listed on http://www.w3.org/TR/html5/links.html#linkTypes ?
19:17
<JonathanNeal>
garciawebdev: 4.12.5.14 Other link types Extensions to the predefined set of link types may be registered in the microformats wiki existing-rel-values page. http://microformats.org/wiki/index.php?title=existing-rel-values
19:18
<JonathanNeal>
Not sure if the validator reflects it, though.
19:20
<garciawebdev>
JonathanNeal, thanks, validator said my value was not valid
19:21
<garciawebdev>
but i've seen many use other values not specified there, so i just wanted to check
19:21
<JonathanNeal>
Hixie: what I just wrote above, ^ ,is that legit?
19:22
<JonathanNeal>
garciawebdev: I think it's right. It's what the spec says. I just wouldn't want to mislead you.
19:23
<garciawebdev>
JonathanNeal what's right? the validator complaining about my value?
19:24
<JonathanNeal>
Ah, sorry, that you can use those values. I thought it would give you a warning in the validator, but I see that it gives you an error.
19:24
<Hixie>
internaut_jack: i tried it on the <label> too, seemed to work fine
19:25
<Hixie>
internaut_jack: can you make a test case that shows the problem?
19:25
<internaut_jack>
Hixie, I have a fiddle, and it works fine there too. Debugging further to see if I can replicate elsewhere.
19:25
<Hixie>
JonathanNeal: if there's a spec that defines what the link type does, sure
19:46
<tantek>
garciawebdev - what rel value are you using that's giving you an error?
19:47
<garciawebdev>
tantek, it's rel="invite"
19:47
<garciawebdev>
designer put it...
19:47
<garciawebdev>
and use that to initialize a jQuery plugin
19:47
<garciawebdev>
you know...
20:04
<Hixie>
garciawebdev: what does it do?
20:05
<garciawebdev>
Hixie, sorry, not actually a plugin, it opens a modal
20:05
<garciawebdev>
when clicking on a button
20:06
<Hixie>
but what dos rel=invite mean?
20:44
<garciawebdev>
Hixie that's what i'm not sure
20:45
<garciawebdev>
Hixie, i don't know, maybe the designer thought he could put anything into rel. is it possible or not?
20:45
<garciawebdev>
(to put anything on it)
21:50
<tantek>
garciawebdev - it's possible if it's defined in a spec, and if it's not redundant with existing rel values.
21:50
<tantek>
I'm not sure rel="invite" makes sense for a modal
21:50
<tantek>
I'm not even sure what would make sense for a link to a modal
21:51
<tantek>
is it a dialog like one you would enter in friends's emails to invite them to use the site?
21:51
<garciawebdev>
tantek, i see, i didn't saw it in a spec, also, no, it doesn't. i think a valid href makes more sense
21:51
<tantek>
yeah
21:51
<garciawebdev>
tantek exactly, you seem to read minds
21:51
<garciawebdev>
hahhahah
21:51
<garciawebdev>
exactly that
21:52
tantek
tries not to abuse his powers.
22:11
<Hixie>
can anyone work out what anne is talking about in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20571 ?
22:39
<tantek>
garciawebdev - looks like there's some use of data-rel=dialog here: http://stackoverflow.com/questions/10949549/jquery-mobile-how-to-simulate-data-rel-dialog
22:39
<tantek>
I wonder if that use is related to your use
22:40
<tantek>
so we have the <dialog> element for marking up in-page dialog content, but we don't really have a way to markup external pages that are used as dialogs for the current page, do we?
22:40
<garciawebdev>
tantek i'm almost sure it's an arbitrary decision of the designer to use it for selecting that anchor from jQuery
22:58
<Hixie>
hsivonen: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=17869
23:22
<zewt>
do people get cool points for calling anything they don't like an "antipattern" now
23:24
<astearns>
calling out buzzwords is an antipattern
23:33
<zewt>
i guess. heh
23:36
<zewt>
hixie called things antipatterns before it was cool