00:10
<JonathanNeal>
Domenic_: min assumes a zero-like value?
00:11
<JonathanNeal>
Whoops, very delayed response to your question.
00:28
<JonathanNeal>
The really tragic part about all of this is that JAWS 15 removed support for <hgroup> where it had previously supported it.
00:28
<JonathanNeal>
So, we actually took a step back.
00:29
<JonathanNeal>
I'm sorry, I meant to say that it supported the outline algorithm (sectioning elements). Not sure about <hgroup> though I imagine they were all bundled together.
00:33
<zcorpan>
annevk: including .float is actually intended. but there's a use counter for dashed properties and for float, so we'll see what that gives
00:33
<Domenic_>
JonathanNeal: why do care what the W3C spec says?
00:33
<jamesr__>
semantically correct website: http://motherfuckingwebsite.com/
00:33
<jamesr__>
actually, can someone check if his use of <strong> is appropriate?
00:34
<jamesr__>
i think it's right
00:34
<Domenic_>
Haha speaking of subheadings he uses <aside> for that
00:35
<jamesr__>
Note: It's not appropriate to use the aside element just for parentheticals, since those are part of the main flow of the document.
00:35
<jamesr__>
is that a parenthetical, or is it separable from the main flow of the document?
00:35
<Domenic_>
It seems parenthetical. Certainly not separable.
00:35
<jamesr__>
i think it's sufficiently separable to use an <aside>
00:36
<Domenic_>
ok i just realized by uttering those words i made myself into a monster and so am leaving this conversation now.
00:36
<jamesr__>
i think we have to fight now
00:37
<jamesr__>
or at least file formal objections against each other
00:38
<JonathanNeal>
I think Domenic_ is suggesting a <PAREN> tag.
00:38
<JonathanNeal>
</SARCASM>
00:39
<zcorpan>
Domenic_: the blockquote usage is wrong (per whatwg spec at least)
00:39
<JonathanNeal>
That's true, plus you should use <footer> for cites.
00:40
<zcorpan>
not according to the spec
00:40
<Domenic_>
zcorpan: cuz he's missing <p>s?
00:40
<Domenic_>
http://developers.whatwg.org/grouping-content.html#the-blockquote-element
00:40
<zcorpan>
Domenic_: no
00:41
<Domenic_>
oh because the person's name is inside the quote
00:41
<zcorpan>
yes
00:41
<zcorpan>
and the quote marks should probably be omitted also
00:41
<zcorpan>
of course some people like hsivonen think that that usage is correct and the spec is wrong
00:42
<JonathanNeal>
I care because I write websites with subheadings all the time, and it frustrates me when a bunch of us create websites and guides to writing websites that rely on some new feature, and then it gets removed, nullifying a bunch of advice, offering no equivalent solution, and later noting a lack of adoption.
00:42
<JonathanNeal>
To respond to your initial question, Domenic_.
00:43
<Domenic_>
JonathanNeal: no, that doesn't really answer the question. My question was more, "why do you think the W3C spec is any more relevant than King Lear is?"
00:44
<JonathanNeal>
Hey, no need to randomly insult the works of Shakespeare.
00:44
<JonathanNeal>
I think it's relevant because it obviously has an impact on implementation and adoption.
00:45
<Domenic_>
Really?
00:46
<JonathanNeal>
Yes. To quote from earlier "the problem with <hgroup> is that the FUD that the w3c spec has added to the mix means that it'll be even longer than normal for this to get implemented widely, unfortunately".
00:46
<Domenic_>
Heh, fair.
00:47
<Domenic_>
I guess, my approach is to not let the W3C spec affect how I author or teach. I can see having to deal with the fallout from its existence though.
00:48
<JonathanNeal>
Interesting to see the difference in the solutions, <figure><blockquote/><figcaption/></figure> BS <blockquote><p>[...]<footer/></blockquote>.
00:49
<JonathanNeal>
In regards to what you just shared earlier. I never knew there was alignment issue with blockquote recommendations too.
00:50
<Domenic_>
the number of alignment issues is numerous and growing
00:52
<JonathanNeal>
And scrolling down http://html5doctor.com/blockquote-q-cite/#comment-23768 reveals that the post may be inaccurate.
00:53
<Domenic_>
the thing i love about the html5doctor comments section is the number of hidden tags from people who forgot they had to type &lt; and &gt;
00:54
<JonathanNeal>
I still agree with http://www.w3.org/html/wg/wiki/ChangeProposals/hgroup which is why I rally this subject every so often.
00:55
<JonathanNeal>
But <hgroup> is closer to what is needed, way better than nothing.
00:55
zcorpan
finds http://lists.w3.org/Archives/Public/public-html/2011Nov/0031.html
01:35
<SteveF>
JonathanNeal: "<JonathanNeal> The really tragic part about all of this is that JAWS 15 removed support for <hgroup> where it had previously supported it. " JAWS never supported hgroup or proper outline nesting
01:36
<SteveF>
Domenic_:"<Domenic_> JonathanNeal: why do care what the W3C spec says? you may not care but lost of dev's do...
01:37
<JonathanNeal>
SteveF: I made a correction to that quote.
01:38
<JonathanNeal>
And they did support outline nesting, moreso then than now.
01:39
<SteveF>
Jonatahan:Neal: yeah saw that after, unfortunately it was borked, we tried to work with them to fix it but they were not interested
01:39
<SteveF>
thier implementation of the oultine was borked that is
01:42
<JonathanNeal>
Help me understand what I perceive to be a dichotomy. You're contributing to a spec that you're also telling people is dangerous fiction to follow, in regards to sectioning elements.
01:45
<JonathanNeal>
And then, why not remove the sectioning part of elements from the w3 draft if they're dangerous, as <hgroup> was removed since it relied so heavily on them.
01:45
<SteveF>
JonathaNeal: no dichotomy, I have modified the advice/requirements in the HTML spec to provide guidance on the use of hx, the outline algorithm is still there sure maybe one day it will become useful and then the advice heading use can be changed, either way.
01:47
<JonathanNeal>
What is the difference between removing a feature and "sure maybe one day"-keeping it?
01:48
<SteveF>
JonathonNeal: there are no implementation requirements on browsers for the outline algorithm
01:50
<SteveF>
JonathanNeal: but sure if the WG decide that the outline algorithm is a waste of space then it will get dropped, we haven't reached that point yet
01:54
<SteveF>
JonathanNeal: if you think there needs to be clearer advice re fiction of outline then please file a bug or email the html list or me or whatever.
01:55
<JonathanNeal>
It was my hope that dropping <hgroup> meant getting something better. Your <subline/subhead> draft did that, but it never made it into a spec. Now there's a hole (an acknowledged hole) in the mutually agreed upon outlining algorithm. I've followed http://www.w3.org/html/wg/wiki/ChangeProposals/hgroup for years now. I'm sad to see it stale.
01:55
<SteveF>
JonathanNeal: then unstale it
01:56
<SteveF>
JonathanNeal: things change if people do stuff
01:58
<JonathanNeal>
Yea, I'm working on the great barrier of logging into the system.
02:00
<JonathanNeal>
I'd like to harmonize the current git work with the w3 wiki, which might ultimately help get the w3 spec and the whatwg spec in more harmony, but I can't use my w3.org creds on the w3 wiki.
02:01
<SteveF>
Domenic_: also note that the differences in the 2 specs are almost all about author conformance requirements, so browser implementer folk need not care if they don't wish to, conformance checker implementers do (in the case of main for example, which was developed at w3c and rewritten differently by hixie) and that is reflected in implementations.
02:02
<Domenic_>
As an author, I pay attention to the source material, not a fork.
02:03
<SteveF>
Domenic_: fair play to you, many devs don't take your view
02:03
<Domenic_>
I think most devs listen to w3schools :P
02:04
<SteveF>
Domenic_:yeah and they dropped hgroup a while back...
02:04
<Domenic_>
haha
04:42
<MikeSmith>
gsnedders: that validator message you saw isn't because of that server not resolving. It's expected that it doesn't resolve. The validator uses an internal resolver to map those URLs to locally cached copies of the schemas.
09:00
<hsivonen>
annevk-cloud: https://bugzilla.mozilla.org/show_bug.cgi?id=910187#c2 surprises me considering that we stopped recognizing the Armscii-8 label in Firefox 19 and no other browser engine support it
09:01
<Ms2ger>
Hmm, Armscii-8
09:01
<Ms2ger>
I think I still have a patch lying around to remove the decoder
09:23
Ms2ger
wonders where MikeSmith is on http://www.w3.org/2013/11/w3cteam
09:25
<jgraham>
Ms2ger: Pretty sure I would deny knowing MikeSmith too ;)
09:25
<SteveF>
Ms2ger: front far right
09:26
<SteveF>
he looks photoshopped
09:26
<Ms2ger>
Heh
09:27
<jgraham>
The whole photo looks very strange
09:27
<jgraham>
I think it had a lot of noise reduction applied to it or something
09:30
<darobin>
jgraham: I don't think that much noise reduction was applied to it
09:30
<darobin>
I mean I saw the original, it wasn't very noisy
09:34
<Ms2ger>
Oh, darobin is on there too?
09:34
<darobin>
damn right
09:35
<Ms2ger>
"Nothing precludes the author from using custom elements in HEAD."
09:35
<darobin>
Ms2ger: I'm roughly in the middle, grey tee with sunglasses hanging from it
09:35
<darobin>
yeah, that made my day too
09:36
<Ms2ger>
With the weird grin?
09:36
<jgraham>
darobin: Well there must be some reason everything looks so smudgy, except at areas of high contrast where there is a kind of halo effect
09:37
<darobin>
jgraham: I think that's because it may have been compressed a bit too much
09:37
<jgraham>
Ms2ger: Which message is that from?
09:38
<darobin>
Ms2ger: possibly :)
09:38
<Ms2ger>
jgraham, http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0610.html
09:38
<darobin>
jgraham: webapps
09:38
<jgraham>
darobin: Hmm, I guess that might well have a similar effect
09:38
<jgraham>
darobin: Right, webapps isn't a message :p
09:38
<Ms2ger>
darobin, also, is that a burrito you're holding?
09:38
<darobin>
yeah yeah, there were like five messages overnight
09:39
<darobin>
Ms2ger: well spotted! but no
09:39
<jgraham>
Ah. Well good to know that the people in charge of our glorious future understand how the platform works
09:39
<darobin>
it's a pinny as they say over the Channel
09:40
<darobin>
we made dumpings
09:40
<Ms2ger>
jgraham, it does open body, right?
09:41
<darobin>
yes
09:42
<darobin>
but hey, nothing indeed prevents you from putting whatever you want between <head> and </head> :)
09:42
<jgraham>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2665
09:43
<jgraham>
I mean nothing does strop you putting stuff in <head>
09:43
<jgraham>
As long as you don't actually use the HTML parser
09:43
<darobin>
right
09:43
<jgraham>
For example you could send your document in JSON and insert all the content using the DOM
09:43
<jgraham>
Actually
09:44
<jgraham>
Pretend I didn't say that
09:44
<jgraham>
Otherwise someone will think it's a great idea
09:44
darobin
trots off to make a spec for it
09:44
<darobin>
I'll put it in the same document in which I define a z attribute on every SVG element so that we have declarative 3D
09:50
<Ms2ger>
jgraham, surely it would be more readable to use the html5lib tests tree format
10:11
<Ms2ger>
Hixie, thanks for the acid3 update
10:43
<MikeSmith>
I photoshopped myself into that photo, as SteveF correctly surmised. I photoshopped in darobin too, which is why he's grinning.
10:43
<MikeSmith>
At the the time that photo was taken I was away for a bit helping the Shenzhen Internet Police refine some of their man-in-the-middle systems.
10:45
<Ms2ger>
I see
10:45
<Ms2ger>
That explains why you aren't listed in the description
10:53
<darobin>
and I had fled the country to escape the slashback for w3cmemes
10:54
<MikeSmith>
heh
11:01
<MikeSmith>
I heard w3cmemes barely made it out of China alive.
11:01
<MikeSmith>
Alternatively I heard that w3cmemes was seen crossing the border back to HK in the back seat of a PRC limousine, smoking a cigar.
11:03
<MikeSmith>
Ms2ger: I'm listed as "Bert Bos", which is an anagram for "Michael[tm] Smith"
11:03
MikeSmith
wonders what update Hixie made to Acid3
11:05
<hsivonen>
annevk-cloud: check out the source on http://main.am/armenianchurch/Program/General/FS2-1.htm
11:06
<hsivonen>
that site is a fascinating combination of pre-Unicode and post-Acid3 Web tech
11:07
<hsivonen>
anyway, the report about armscii-8 support being needed lost its credibility, since that site doesn't actually use armscii-8 support
11:16
<Ms2ger>
MikeSmith, http://lists.w3.org/Archives/Public/www-archive/2013Nov/0013.html
11:16
<Ms2ger>
MikeSmith, and I've seen Bert Bos, sorry :)
11:18
MikeSmith
notes that Ms2ger says he's sorry that he's seen Bert Bos
11:19
<MikeSmith>
Ms2ger: thanks for the link
11:19
<annevk>
hsivonen: charset=x-user-defined o_O
11:20
<annevk>
oh lol, character references all the way down
11:20
<hsivonen>
annevk: right. it doesn't actually use the x-user-defined range
11:20
<hsivonen>
annevk: instead, it assigns the Armenian glyphs to the Latin-1 Supplement range
11:20
<hsivonen>
and it supplies a font via @font-face
11:21
<hsivonen>
so x-user-defined only has an effect if you have that same font installed locally in a pre-@font-face Firefox
11:21
<annevk>
wow, I thought that was an India only thing
11:21
<hsivonen>
annevk: me, too
11:22
<hsivonen>
anyway, not evidence of armscii-8 use
11:22
<hsivonen>
and explains how Chrome can succeed in Armenia
11:25
<MikeSmith>
hsivonen: you mean you think that there are a lot of sites doing that?
11:25
<MikeSmith>
(doing what that page is doing I mean)
11:28
<hsivonen>
MikeSmith: not sure what I should think. the author of that page claims there are more like that, but he/she already made a untrue claim, so I'm not sure what to believe
11:29
<MikeSmith>
I guess it's more likely that hack is probably not something he dreamed up himself
11:30
<MikeSmith>
but instead just copied from some other more widely used site
11:31
<hsivonen>
MikeSmith: that sort of commandeering Latin 1 characters for non-Latin glyphs is not an isolated incident
11:31
<hsivonen>
MikeSmith: used to be a thing in India
11:32
<hsivonen>
MikeSmith: dunno how common the exact combination of x-user-defined with entities is, though
11:32
<MikeSmith>
ah OK
11:32
<gsnedders>
MikeSmith: Then it shouldn't cause an exception trying to start!
11:32
<MikeSmith>
gsnedders: indeed
11:33
<hsivonen>
MikeSmith: anyway, what that site does today is interoperably supported
11:33
<hsivonen>
(armscii-8 isn't and wasn't)
11:34
<MikeSmith>
hsivonen: yeah the guy who posted that bug just seemed to not even understand what he was doing himself, or what was actually needed and being used in practice for Armenian
11:35
<MikeSmith>
(or the guy who commented there in the recent comment -- I guess he's not the one who raised the bug)
11:35
<MikeSmith>
gsnedders: did you make any changes the validator sources locally?
11:35
<gsnedders>
MikeSmith: No.
11:36
<gsnedders>
MikeSmith: I literally just followed the published instructions, checked out build than ran the Python script twice
11:36
<MikeSmith>
ok
11:36
<MikeSmith>
can you please try running it one more time?
11:36
<gsnedders>
Sure.
11:37
<hsivonen>
how come Emoji landed in Unicode before https://en.wikipedia.org/wiki/Arevakhach ?
11:37
<gsnedders>
(I don't actually care. I just want a small bit of the Validator.nu source. :P)
11:37
<gsnedders>
MikeSmith: Third time lucky, seems to be working
11:37
<MikeSmith>
gsnedders: I care if I broke something :)
11:37
<MikeSmith>
gsnedders: yeah I guess we need to modify the build instructions then
11:38
<MikeSmith>
"Re-run the build script until it doesn't fail any more."
11:38
<annevk>
in response to last night, seems markup mu has not yet been achieved
11:38
<hsivonen>
gsnedders: it's possible that I broke the appearance of something that was broken not being broken, if this is about it actually trying to fetch something from s.validator.nu
11:38
<gsnedders>
MikeSmith: :)
11:38
<gsnedders>
gsnedders: Yes
11:38
<gsnedders>
gsnedders: Why are you talking to yourself?
11:38
<gsnedders>
hsivonen: Yes.
11:39
<hsivonen>
gsnedders: that suggests our mapping of magic bogo URLs to local data is broken
11:39
<gsnedders>
hsivonen: But only on second run of build
11:39
<hsivonen>
weird
11:54
<MikeSmith>
hsivonen, gsnedders I think it's most likely something I messed up in the last few months. I'll try to look at it when I can make the time
12:02
<annevk>
Custom elements made it to CR?
12:06
<MikeSmith>
annevk: I thought it just went to LC recenlty
12:06
<annevk>
MikeSmith: I think the way it works is that nobody has even noticed that happened
12:06
<MikeSmith>
heh
12:07
<annevk>
MikeSmith: apart from rniwa from Apple it seems, but his alternative proposal was not seen as a comment
12:09
<MikeSmith>
annevk: I'm glad at least there's a plan in place to clear up the confusion in the future http://w3cmemes.tumblr.com/post/66838310443/disappointed-in-the-guardians-of-the-process
12:11
<MikeSmith>
annevk: if they missed an alternative proposal I doubt it was intentional
12:11
<MikeSmith>
I'll ask Yves
12:12
<annevk>
MikeSmith: it seems to be mentioned in http://www.w3.org/wiki/Webapps/LCWD-custom-elements-20131024/ so I guess I was missing something
12:12
<annevk>
MikeSmith: still not convinced that with four comments, all of the monkey patching going on, this is actually ready
12:15
<MikeSmith>
annevk: I think if Apple's saying they're not planning on implementing as specified it's not ready
12:16
<MikeSmith>
especially if they are saying they'll implement it if changes are made
12:20
<MikeSmith>
http://www.w3.org/wiki/Webapps/LCWD-custom-elements-20131024/#LC-2 seems to be dglazkov saying he plans to resolve the comment without making any changes
14:07
<annevk>
hsivonen: it seems Chrome does not respect x-user-defined as a label
14:07
<annevk>
hsivonen: at least not in HTML context
14:50
<darobin>
jgraham or Ms2ger: am I guessing correctly that all the WPT tests starting with html5lib_ in html/syntax/parsing are generated automatically from the html5lib test suite?
14:51
<darobin>
and if so, I guess that if I wanted to modify them it'd be best to patch upstream? which in turns begs the question of finding the converter and all
14:51
<Ms2ger>
Yes
14:51
<jgraham>
darobin: Yes
14:51
<Ms2ger>
The converter should be in wpt
14:52
<Ms2ger>
Under tools/?
14:52
<jgraham>
The converter is in tools
14:52
<darobin>
ah
14:52
darobin
digs
14:52
<Ms2ger>
And https://github.com/html5lib/html5lib-tests
14:52
<darobin>
found it, thanks a lot!
16:48
<zcorpan>
jgraham: if i want to test that ping=... got resolved correctly in the POST request, how should i do that? a naive way would be to stash the result and then do an XHR, but i think that has some problems like what if the XHR happens before the ping happens, what if ping isn't supported...
16:50
<zcorpan>
i guess i could feature-check for ping and fail early. if the feature check passes but the ping isn't sent anyway, the test can time out
16:50
<jgraham>
zcorpan: I guess you need to do the ping-causing action and then have a timeout to do the XHR
16:50
<jgraham>
If it can be delayed for an arbitary amount of time it seems impossible to tell for sure whether if succeeded or not
16:51
<zcorpan>
can't i do the XHR immediately and have the server script wait with returning anything until the stash is there?
16:51
<jgraham>
Well sure, I guess
16:51
<jgraham>
But that still needs some kind of timeout
16:52
<zcorpan>
isn't the harness timeout enough?
16:53
<jgraham>
On the server side I mean
16:53
<jgraham>
You can't juet let the script run forever
16:54
<zcorpan>
the script isn't killed if the test is navigated?
16:54
<jgraham>
No, how would that work?
16:55
<zcorpan>
the browser closes the XHR connection on navigation, i thought. but maybe it doesn't?
16:55
<jgraham>
Right, but the server won't notice that
16:56
<zcorpan>
ok. is that intentional?
16:56
<jgraham>
Well intentional in the sense that I don't know how to do it another way
16:56
<jgraham>
You would need to know whether the remote end had closed the socket. But I don't know how to tell without trying to send something over it
16:57
<zcorpan>
i was imagining some magic where the server would notice that the connection was closed and kill the script
16:57
<jgraham>
There isn't any such magic
16:57
<zcorpan>
k
16:57
<jgraham>
If someone knows how to add such magic, it might be a good idea
16:58
<zcorpan>
i don't know what the socket api is like. but it seems a bit weird to not be notified about the socket closing. but i recall pywebsocket also not knowing about it
16:59
<zcorpan>
maybe my mental model of how sockets work is just wrong
17:11
<zewt>
not completely following the conversation, but you can definitely tell if the other side has closed a TCP connection
17:12
<jgraham>
zewt: Using getsockopt? Or something else?
17:13
<zewt>
just by trying to read it; you'll get an EOF (and a read signal from select)
17:20
<jgraham>
Can I actually use that in this situation though?
17:22
<zewt>
not familiar with what you're doing ... are you testing against a dummy server to see what the browser is doing?
17:23
<jgraham>
I don't know what the difference between a dummy server and a real server
17:23
<jgraham>
is
17:23
<Ms2ger>
The words "dummy" and "real"
17:23
<jgraham>
But yeah, I have a server
17:23
<jgraham>
and it does some work
17:24
<jgraham>
and maybe, by the time the work is done, the client has closed the connection
17:24
<zewt>
a real server being apache or nginx or something that you're just making requests against, as opposed to something designed to inspect some particular behavior
17:24
<Ms2ger>
dglazkov, :)
17:24
<jgraham>
It's a real server in the sense that you don't directly access the inner state of the server
17:24
<jgraham>
when running tests
17:29
<zewt>
well, the server can tell if the client has closed the connection; whether you can make use of that in whatever it is you're doing with whatever server you're using I couldn't tell you :)
18:32
<SimonSapin>
annevk: https://code.google.com/p/chromium/issues/detail?id=324251#c2 says data: URLs have no fragment (it’s part of the "content") because rfc2397 doesn’t talk about it. I disagree. What do you think?
18:33
<Ms2ger>
What does the fo^Wspec say?
18:33
<annevk>
SimonSapin: you're correct, that's been proven long ago
18:33
<annevk>
SimonSapin: fragment identifiers are part of all URLs
18:34
<annevk>
SimonSapin: the way the IETF defines URIs with ABNF on a per-scheme basis makes this confusing admittedly; but the URL Standard solves that
18:36
<annevk>
SimonSapin: pretty sure that bug is a duplicate btw
18:46
<zcorpan>
jgraham: another thing i want to do is get the raw characters for a part of the request url. what i came up with was re.match(r'q=([^&]+)', request.url_parts.query).groups()[0]
18:47
<jgraham>
zcorpan: That seems like it would work
18:49
<jgraham>
I admit it isn't super-pretty, but in most cases request.GET will be good enough
18:49
<zcorpan>
yeah it seems to do the trick. at least when the url only has ascii-range bytes, iirc (old?) IE can request urls without percent-escaping and i don't know what would happen
18:50
<jgraham>
So making cases where it isn't good enough pretty seems like a lower priority
18:50
<zcorpan>
yeah i don't disagree
18:52
<jgraham>
You can go even lower level if something on the python side isn't playing well with non-ascii there e.g. request.url or request.request_line
18:52
<jgraham>
I think the regexp should work even if there is non-ascii, but you can easily test that in (i)python
18:55
<zcorpan>
>>> re.search(r'q=([^&]+)', b'q=\xE5').groups()
18:55
<zcorpan>
('\xe5',)
18:56
<zcorpan>
hmm i guess that wasn't what i wanted to test
18:56
jgraham
-> away for a bit
19:15
<hsivonen>
annevk-cloud: a quick looks at an Armenian legacy site suggests that IE doesn't do what Gecko does with x-user-defined, either
19:16
<hsivonen>
this sort of knowing Unicode-avoidance legacy is sad
19:16
<hsivonen>
for those following along at home, I'm looking at http://archive.aravot.am/2005/aravot_arm/February/25/aravot_index.htm
19:18
<hsivonen>
in any case, we should probably re-evaluate x-user-defined
19:18
<hsivonen>
and see if making it a label of windows-1252 would lead to better interop
19:22
<zcorpan>
jgraham: urllib.urlopen(b'...\xE5').read() sends %E5 in the request
19:22
<zcorpan>
hsivonen: do webkit/ie support x-user-defined in XHR?
19:23
<hsivonen>
zcorpan: dunno. finding out would be part of re-evaluating
19:24
<SimonSapin>
hsivonen: x-user-defined is a documented trick to get binary data through XHR without arraybuffer support: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest#Handling_binary_data
19:25
zcorpan
finds https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest
19:25
<zcorpan>
SimonSapin beat me to it
19:53
<zcorpan>
jgraham: writing \xe5 to a socket directly worked. it round-tripped OK
20:13
<BenoitRen>
Hi everyone. I'm still trying to mark up video game scripts, and I've hit another snag.
20:13
<BenoitRen>
Suppose I have an NPC you can talk to. I'd mark it up like this: <h2>NPC name</h2><ol><li>something</li><li>something else</li></ol>
20:14
<BenoitRen>
Where the list items are the different lines you get.
20:14
<BenoitRen>
Now, what do I do if an action occurs during or after one of those lines?
20:15
<zewt>
... what
20:15
<BenoitRen>
For example, there's a dog NPC you have to catch. You can interact with it twice before it runs off to another town.
20:15
<zewt>
html isn't a script markup language. heh
20:16
<BenoitRen>
@zewt: I know that. But if I'm going to present it on a web page, I have to mark it up somehow.
21:48
<zcorpan>
does firefox support ping=""?
21:48
<zcorpan>
i can't see it making a request
21:50
<zcorpan>
but the IDL attribute is present :-(
21:52
<smaug____>
zcorpan: IIRC it doesn't
21:53
<smaug____>
there is still some code for the old proposal, but it is disabled by default
21:53
<smaug____>
(IMHO ping isn't too useful thing to add to the web platform)
21:53
<zcorpan>
it's sad that the .ping property is there but the feature doesn't work. feature detection fail
21:54
<zcorpan>
(also non-conforming)
21:55
<smaug____>
it sounds like a good thing. Some tracking company thinks it works, and doesn't even try to use more heavy weight solutions :)
21:55
<smaug____>
but I don't know why ping is there
21:55
<smaug____>
looking
21:56
<zcorpan>
more likely tracking companies will notice that it doesn't work and UA sniff for firefox, so when you do implement it you'll still have as bad user experience as without it :-)
21:57
zcorpan
poof
21:57
<smaug____>
anyhow, you can blame Google about this implementation
21:58
<smaug____>
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/public/idl/html/nsIDOMNSHTMLAnchorElement2.idl&rev=1.1
22:20
<zcorpan>
smaug____: ok
22:21
<zcorpan>
smaug____: did you file a bug to remove it?
22:21
<smaug____>
nope
22:22
<smaug____>
I wonder what all will break if it is removed
22:28
<zcorpan>
might be worth checking how google mobile search detects ping support, if it's just UA sniffing
22:28
<zcorpan>
good night