00:21
<MikeSmith>
/set activity_hide_targets #webkit #chromium
00:21
<MikeSmith>
/set activity_hide_targets #webkit #chromium
00:47
<karlcow>
http://www.w3.org/mid/m24nk01371.fsf⊙eac
00:47
<karlcow>
"We support Microdata proceeding on the REC track—just to name one reasno, WebKit and Gecko both have implementations."
00:48
<karlcow>
http://dev.opera.com/articles/view/microdata-and-the-microdata-dom-api/
00:48
<karlcow>
fwiw ;)
00:49
<karlcow>
Though I have been trying to use Microdata API and I found it confusing. I guess I didn't grasp yet how it should be working.
00:51
<hober>
OK, I really need to stop my brain for thinking of cards for Web Standards Cards For Humanity
00:52
<hober>
e.g. Given the black card "Life for American Indians was forever changed when the White Man introduced them to _____." Play the white card "the 5 February 2004 W3C Patent Policy."
01:30
<tantek>
karlcow - I like how everyone who writes a metadata article has to create a gratuitous reinvention of vCard / hCard etc. for their examples, thus immediately misleading authors into thinking they should all make up their own vocabularies. It's like XML hell all over again.
01:31
<tantek>
and I think the microdata API is only there in order to provide a spec-hook for the parsing algorithm, that is, some sort of developer accessible reason for existing. I don't know of anyone who actually makes any use of the microdata API in practice.
01:31
<karlcow>
tantek: not sure what it refers to. But I guess business card is a kind of "hello world" of metadata.
01:31
<tantek>
to me it (the *API* in particular) just as bad of a solution looking for a problem as many other kinds of things that get quickly derided.
01:32
<tantek>
a business card may be a kind of "hello world" of metadata, but then it should be used to promote vocabulary re-use first and foremost, not making up new vocabularies (and thus sending developers down an unproductive / non-interop path.
01:33
<tantek>
p.s. clever .ro spam comment at the end of that article
01:34
<karlcow>
tantek: aaaaaah you are talking about the article on dev.opera?
01:34
karlcow
was lost
01:36
<karlcow>
I was just mentioning to hober that microdata API was supported in Opera since Presto 2.9 http://www.opera.com/docs/specs/presto29/
01:37
<karlcow>
~2011
01:40
<karlcow>
For the MicroData API, I haven't really understood yet how the API helps to walk the graph of metadata to extract values.
01:42
<karlcow>
I must be doing something wrong
01:42
<karlcow>
https://gist.github.com/4221190
03:51
<Hixie>
man, i am absolutely amazed by the lack of professionalism being shown by people in public-webapps
03:57
<MikeSmith>
Hixie: I know what you mean but I'm amazed that you're amazed
03:57
<MikeSmith>
if in fact you're sincere about being amazed
03:58
<MikeSmith>
people can lead themselves to absurd conclusions once they have decided to not fix the real problems
03:58
<Hixie>
i actually am amazed
03:59
<MikeSmith>
ignore the core problems, pretend they're not problems at all, then start rationalizing from there
03:59
<Hixie>
i have seen all kinds of weird stuff at the w3c, but lack of professionalism towards others to this level i haven't seen before
03:59
<MikeSmith>
yeah
03:59
<MikeSmith>
it's dogmatic
03:59
<Hixie>
i mean, at first i kinda assumed people just didn't realise copying people was off
03:59
<MikeSmith>
of course they realize it's wrong
03:59
<Hixie>
but after that's been mentioned and pointed out, trying to justify it is crazy
04:00
<Hixie>
and the latest thing in www-archive saying that really the problem is just that ms2ger is pseudonymous is utter bs
04:00
<MikeSmith>
it's like any other kind of blind devotion to an instiution
04:00
<Hixie>
i mean, that brings it to a new level
04:01
<MikeSmith>
well that's not "people"
04:01
<MikeSmith>
that's one person
04:01
<MikeSmith>
who's at the most extreme end
04:01
<Hixie>
that specific issue, yes
04:01
<Hixie>
but the broader one isn't
04:01
<Hixie>
i mean, each of these specs has multiple "editors" listed
04:06
<zewt>
Hixie: i can honestly say that charles trying to censor ms2 is one of the most offensive things i've ever seen on a "professional" mailing list
04:06
<Hixie>
yeah that's a great example of what i mean
04:07
<zewt>
wonder if gmail lets me plonk people because i really don't want to read anything he has to say
05:00
<Hixie>
is this specced anywhere? http://code.google.com/p/chromium/issues/detail?id=3766
05:03
<Hixie>
anyone know anything about DOMFrameContentLoaded?
05:03
<MikeSmith>
Hixie: dunno but it looks like FF and Chrome both pass it now, right?
05:04
<Hixie>
yeah it's more the <font> behaviour i'm worried about
05:04
<MikeSmith>
oh
05:04
<Hixie>
the test, that is, the CSS stuff, is specced in the CSS and Unicode specs, i think
05:04
<MikeSmith>
ok
05:49
<MikeSmith>
tantek: has there been any decision yet about dropping the ime-mode property from CSS UI?
05:50
<MikeSmith>
I see it's still marked "at risk" in the latest ED
05:50
<MikeSmith>
http://dev.w3.org/csswg/css3-ui/
05:51
<tantek>
MikeSmith - do you have a preference?
05:52
<MikeSmith>
tantek: not really. I can ask the devs working on the IME API if they do
05:53
<MikeSmith>
I guess if we go forward with the IME API maybe we don't need the ime-mode property
05:53
<tantek>
basically, ime-mode is in IE5+ and FF3+
05:53
<tantek>
it is at risk because we don't know how interop those are
05:53
<tantek>
if they're interop, then it stays, if not, then it gets dropped during CR
05:54
<tantek>
make sense?
05:55
<MikeSmith>
tantek: makes sense
05:55
<MikeSmith>
thanks
05:56
<tantek>
np
06:49
<MikeSmith>
https://hg.mozilla.org/mozilla-central/rev/5593cd83590e is nice
06:49
<MikeSmith>
2.1 --- a/js/src/jsarray.cpp
06:49
<MikeSmith>
1.2 +++ b/js/src/builtin/array.js
06:50
<MikeSmith>
by way of David Bruant on twitter https://twitter.com/DavidBruant/status/276349760317829120
06:52
<MikeSmith>
and "Indeed, we took the basic concepts from V8."
06:52
<MikeSmith>
flashback to the summer of 2008
06:58
<MikeSmith>
http://www.iro.umontreal.ca/~dufour/pubs/dls2011.pdf
07:01
<MikeSmith>
https://github.com/Tachyon-Team/Tachyon/tree/master/source
08:37
<Smylers>
The sample rendering images in ‘HTML for Developers’ are wrong in a mildly amusing way: http://developers.whatwg.org/states-of-the-type-attribute.html#range-state-%28type=range%29
08:37
<Smylers>
(Also reported properly as an issue on GitHub.)
08:39
<Ms2ger>
Smylers, these come straight from the spec, no?
08:39
<Smylers>
They're displayed fine in the full spec.
08:39
<Smylers>
I'm presuming they're being distorted by CSS specific to the developers remix.
08:41
<Ms2ger>
Oh, hmm
08:41
<Ms2ger>
I don't see that
09:56
<zcorpan>
Smylers1: problem being that the images don't load? maybe they're not listed in the manifest?
09:59
<Smylers1>
Ms2ger: Hmmm, seems to be Firefox-specific.
09:59
<Ms2ger>
I use Firefox ;)
09:59
<Smylers1>
I just checked in Chromium and IE, and it's fine in those.
10:00
<Smylers1>
Ms2ger: Odd.
10:01
<Smylers1>
Ms2ger: I'm seeing the problem on both Firefox 17.0.1 on Linux and 16.0.2 on Windows.
10:01
<Ms2ger>
I'm on 20-something/Linux
10:02
<Smylers1>
zcorpan: The problem (which now seems only to affect me, albeit on two different computers with no shared accounts) is that the images are stretched to being the full width of the paragraph, but keep their intrinsic height. For tall thin images it's very distorting.
10:02
<zcorpan>
oh
10:03
<Smylers1>
Ah, using the Ctrl+Shift+I thingy and clicking on a stretched image I see
10:03
<zcorpan>
maybe the width is used from laying out the alt text?
10:04
<Smylers1>
section[role="main"] img { width: 100%; }
10:04
<Smylers1>
That's in the file handheld.css.
10:04
<darobin>
section[role="main"]? shouldn't you be using <main> instead?
10:04
darobin
crawls back under his bridge
10:04
<Smylers1>
Presumably handheld.css isn't supposed to be active in a desktop browser.
10:04
<Smylers1>
darobin: Tee-hee.
10:05
<zcorpan>
that style rule also seems a bit bogus
10:05
<zcorpan>
possibly max-width:100%; height:auto; makes sense
10:05
<darobin>
indeed
10:05
<Smylers1>
zcorpan: Indeed. That sounds better.
10:05
<Smylers1>
Has anybody got an actual handheld device to check it on?
10:06
<zcorpan>
what's your window width?
10:07
<zcorpan>
<link href="/css/handheld.css" rel="stylesheet" media="screen and (max-width: 959px)">
10:07
<Smylers1>
873px, it turns out
10:07
<Smylers1>
Ah.
10:08
<Smylers1>
873px doesn't seem small to me. It lets me fit an 80-character terminal window next to it on this widescreen laptop.
10:08
<zcorpan>
if you have a monitor, try holding it in your hand and see if the image appears more comfortable.
10:09
<Smylers1>
As expected, going full-screen fixes things.
10:09
<darobin>
Smylers1: the break point at which to switch to handheld is debatable, but the CSS for images is wrong anyway so fixing that would be the best bet IMHO
10:10
<Smylers1>
darobin: Yup.
10:10
<darobin>
also, if you're debugging you're probably much, much better off removing the manifest
10:11
<Smylers1>
I've just tried zcorpan's suggestion in the Ctrl+Shift+I thingy, and it seems to work.
10:11
<Smylers1>
darobin: manifest?
10:11
<darobin>
Smylers1: appcache manifest, on the root html
10:12
<darobin>
besides, it's a weird use of appcache given that the images are in a NETWORK block
10:12
<Smylers1>
darobin: What's that do?
10:12
<darobin>
it causes it to be cached for offline use
10:12
<darobin>
during development, it's a world of pain
10:13
<Smylers1>
darobin: When I first viewed the page Firefox asked me if I wanted to install the site for offline use. (I said ‘no’.) Is that what does it?
10:13
<darobin>
yup
10:14
<Smylers1>
darobin: Ta.
10:14
<darobin>
Smylers1: you want to read this before touching any content that relies on appcache: http://www.alistapart.com/articles/application-cache-is-a-douchebag/
10:14
<hsivonen>
Hixie: the spec for DOMFrameContentLoaded is http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#4128
10:14
<darobin>
none of what's in that article is an exaggeration, in fact he's rather mellow considering
10:37
<Smylers1>
Pull request sent: https://github.com/benschwarz/developers.whatwg.org/pull/73
10:37
<Smylers1>
Thank you everybody for the help.
10:56
<zcorpan>
SimonSapin: thanks (re www-style)
10:58
<SimonSapin>
zcorpan: sure
10:58
<SimonSapin>
so you’d favor making the whitespace really optional?
10:59
<SimonSapin>
the thing is, it’s a pain to express in the grammar: http://dev.w3.org/csswg/css3-conditional/#at-supports
10:59
<zcorpan>
yeah, that seems like it would result in fewer WTWTFs from authors
11:00
<zcorpan>
i understand that it's a pain for the spec
11:00
<zcorpan>
priorities...
11:02
<darobin>
SimonSapin: are there any plans to make at-rules acceptable in a @supports condition?
11:02
<darobin>
e.g. @support (@font-face) ...
11:02
<SimonSapin>
darobin: isn’t that the case already?
11:02
<darobin>
I thought it wasn't, maybe I'm wrong
11:02
<SimonSapin>
http://dev.w3.org/csswg/css3-conditional/#contents-of
11:04
<darobin>
SimonSapin: unless I'm reading the grammar wrong that's for the content of the @support's body
11:05
<darobin>
so @supports (foo: bar) { @allowed-here... }
11:05
<SimonSapin>
darobin: sorry I misread your question
11:05
<darobin>
I was thinking about @supports not (@page) { approximate page stuff somehow }
11:05
<SimonSapin>
In @support (…) the … must be a declaration
11:06
<darobin>
right
11:06
<SimonSapin>
but we changed the syntax to allow @support some_functional_notation(…)
11:06
<SimonSapin>
unknown functions are always false, but future levels can add functions
11:06
<darobin>
heh, if your initial reply had been correct then the grammar would accept @supports not (@supports) {…} :)
11:07
<darobin>
that makes sense
11:07
<SimonSapin>
so maybe @supports at-rule(@page) or something
11:08
<SimonSapin>
it’s not in level 1 because we’re not sure of the syntax, but didn’t want to block the rest of the functionality
11:11
<darobin>
sure, that's sensible
14:00
<Smylers1>
“The quality of a spec has little to do with its implementation or implementability. This is a process and IPR concern unrelated to quality.” — Interesting TAG manifesto line from Glenn Adams.
14:01
<Smylers1>
His nominator seems to've forgotten to mention it in his statement, but Glenn helpfully puts it on the public record here: http://lists.w3.org/Archives/Public/www-archive/2012Dec/0027.html
14:57
<zewt>
Smylers1: wow--that's pretty unusual subject matter for The Onion
15:07
<zewt>
Hixie: bleh, I should take that complex captioning example, track down a raw and transcribe the same scene with roll-ups
15:07
<zewt>
it'll be completely illegible and i don't think anyone comparing those two could make an honest argument for roll-up captions
15:55
<marcosc>
zewt: Eveyone knows Ms2ger` is a patent troll
15:55
<Ms2ger`>
And I tried so hard to hide it by not telling Glenn who I am
15:56
<marcosc>
Ms2ger`, oh! Glenn will find out when you drag his sorry ass into court for countless patent infringements
15:57
<Ms2ger`>
marcosc, that will be hard, he doesn't implement anything AFAIK
15:59
<marcosc>
heh, the irony :)
16:31
<foobler>
What's the best manner to use @async and @defer for a dynamically injected script that I want to be downloaded as soon as possible, but then executed on domready so as to not get in the way of the rest of the page?
16:44
<Ms2ger`>
defer
17:15
<GPHemsley>
Sometimes I wonder whether our embedded lists should use different numbering for different levels...
17:16
<GPHemsley>
It's all Pythony in here, relying only on indentation to determine which level we're at.
17:19
<annevk>
odinho: happy b-day!
17:48
<GPHemsley>
"Well, you see, in step 14.15.2.2, you..."
17:48
<GPHemsley>
-_-
17:49
<Ms2ger`>
In step 14.XV.b.ii?
17:51
<dglazkov>
good morning, Whatwg!
17:55
<GPHemsley>
Ms2ger`: No, silly. Step 14(o)(ii)(β). Duh.
18:11
<GPHemsley>
SimonSapin: This is what I have so far. Thoughts? http://pastebin.mozilla.org/1979746
18:13
<GPHemsley>
(it's not done)
18:13
<GPHemsley>
annevk: Feel free to chime in, too. ^^
18:16
<SimonSapin>
GPHemsley: first impression without reading: if it’s that much code-like, how about using an actual programming language?
18:16
<SimonSapin>
at university I used to write python and tell people it’s pseudo-code
18:16
Ms2ger`
did that
18:17
<Ms2ger`>
With a professor who wrote horrible formatted C as pseudo-code instead
18:18
<SimonSapin>
I don’t remember a spec using executable code as the normative description of an algorithm, but I don’t know why it would bad
18:19
<SimonSapin>
favoritism form one programming language aside
18:19
<Ms2ger`>
Depending on the definition of the programming language and all its bugs
18:19
<SimonSapin>
might still be better than an undefined pseudo-language
18:20
<SimonSapin>
Are "Enter loop L" and "Begin loop M" the same as "while True"?
18:21
<SimonSapin>
(sorry for going meta when I suspect you want feedback on the actual algorithm…)
18:44
<GPHemsley>
SimonSapin: All algorithms are code-like ;)
18:49
<GPHemsley>
SimonSapin: Any spec that uses pseudo-code instead of prose runs the risk of being unintelligible or misunderstood. With prose (at least, if done correctly), you can be clear about what you need to be done without necessarily forcing any particular way of doing it.
18:50
<GPHemsley>
So yes, you can translate "enter loop" as "while true", but really that's just an artifact of the programming language.
18:51
<GPHemsley>
It's a hack, really, if you think about it.
18:51
<GPHemsley>
You're taking advantage of a tautology to force the loop to run continuously, but there's no reason why a programming language couldn't implement that behavior natively.
18:52
<GPHemsley>
(As in, the prose is a sort of pseudo-code already.)
18:55
<SimonSapin>
yeah I was not suggesting you change it, just confirming I understood correctly
18:56
<GPHemsley>
k
18:57
<GPHemsley>
SimonSapin: I just wanted to make sure I sufficiently argued against using pseudo-code as a spec. :)
18:57
<SimonSapin>
so you plan to make prose out of http://pastebin.mozilla.org/1979746 ?
18:59
<GPHemsley>
SimonSapin: Oh, no, that's what I consider prose in this context. :)
19:01
<GPHemsley>
BTW, those are all supposed to be numbered. For some reason, the numbering didn't copy from the browser.
19:03
<SimonSapin>
GPHemsley: are you writing this in HTML? Could you paste the source? (Might be easier to read.)
19:06
<GPHemsley>
Doubt it, but OK.
19:07
<SimonSapin>
GPHemsley: define whitespace, preferably by a list of code points
19:07
<SimonSapin>
(easier to read once rendered by a browser!)
19:08
<SimonSapin>
GPHemsley: … or link to http://encoding.spec.whatwg.org/#ascii-whitespace , if that’s the definition you want
19:08
<GPHemsley>
Yes, yes. Assume all terms are define satisfactorily. (I think annevk defines whitespace characters in encoding or something.)
19:08
<GPHemsley>
SimonSapin: http://pastebin.mozilla.org/1979885
19:09
<GPHemsley>
Once I actually have an algorithm that completes, I'll commit it and put in online like normal. Then you can read it comfortably.
19:09
<GPHemsley>
I'm just looking for overview feedback right now.
19:09
<SimonSapin>
commit with mime(sniff)?
19:10
<GPHemsley>
Yeah
19:10
<GPHemsley>
Unless/until we find someplace else to live.
19:10
<GPHemsley>
+for it
19:11
<GPHemsley>
I define "whitespace byte", but I haven't decided whether I'm parsing this as bytes or characters.
19:11
<SimonSapin>
sequence[s] is undefined … when s >= length?
19:12
<GPHemsley>
those are functionally equivalent, are they not?
19:12
<SimonSapin>
yeah of course
19:12
<GPHemsley>
(but this is still too low level of feedback :P)
19:13
<SimonSapin>
again, making sure I understand
19:13
<GPHemsley>
ah, ok
19:13
GPHemsley
notes that pastebin HTML syntax highlighting is rather terrible.
19:13
<SimonSapin>
I’m used to python were out of bounds indexing raises an error instead of returning undefined/None
19:14
<GPHemsley>
ah, well, I could change it
19:14
<GPHemsley>
but it's used elsewhere in mimesniff, too
19:14
<SimonSapin>
I’m reading here http://dabblet.com/gist/4227355
19:14
<GPHemsley>
ah, that's one way to do it
19:18
<SimonSapin>
re seq[i] is undefined: if that behavior is defined or mentioned somewhere, it’s fine
19:19
<benbro>
how can I track the progress of the PointerEvents draft?
19:19
<benbro>
is there a way to estimate when it will be stable and when will browsers start to implement it?
19:19
<Ms2ger`>
Look at xhr.spec.whatwg.org
19:19
<SimonSapin>
Encoding uses a theoretical "EOF code point" or "EOF byte"
19:19
<Ms2ger`>
Browsers have implemented it for years
19:19
<hober>
benbro: http://lists.w3.org/Archives/Public/public-pointer-events/
19:19
<Ms2ger`>
Oh
19:19
<Ms2ger`>
I can't read
19:20
<Ms2ger`>
Nothing to see here, move along
19:20
<benbro>
hober: thanks. seems very active
19:20
<GPHemsley>
SimonSapin: Yeah, I saw that, but I didn't look deep enough into it to understand its function. Is that what it does? Avoid this undefined issue?
19:20
<SimonSapin>
it just means you reached the end of a sequence
19:20
<jsbell>
yes (re: EOF byte)
19:21
<benbro>
hober: does implementation depends only on browser vendors or on devices too?
19:21
<benbro>
hober: for example FF only or android/galaxy note. who should change stuff to support it?
19:21
<hober>
benbro: i don't think i understand the question, and i'm not in the wg
19:22
<benbro>
hober: ok. I mean who need to implement the spec
19:23
<benbro>
if it's just FireFox the browser or also samsung who creates the galaxy note with the s-pen or maybe google which creates the android
19:23
<GPHemsley>
SimonSapin: Oh, I forgot, it's because the algorithm processes a byte sequence as an array, of sorts. So seq[i] is undefined when it goes out of bounds. But >= length would work, too. Not sure about EOF, though.
19:24
<GPHemsley>
(it doesn't use pointers or whatever)
19:25
<SimonSapin>
GPHemsley: I wonder if a grammar would be more suited in this particular case. One without implicit whitespace or implicit anything. Error handling is simple: doesn’t match the grammar ⇒ return undefined
19:26
<GPHemsley>
Yeah, I was kinda thinking that myself.
19:26
<GPHemsley>
I just wish I'd thought harder about before I did all this work. >_>
19:26
<SimonSapin>
It’s quite verbose just to say: ws* token ws* "/" ws* token ws*
19:27
<GPHemsley>
indeed
19:27
<GPHemsley>
though I think there are severability points beyond just not matching = undefined
19:28
<jsbell>
Although I'm not really paying attention, have no useful input, and I have no reason to care and should be worrying about other things, the comment "I haven't decided whether I'm parsing this as bytes or characters" is causing encoding-paranoia angst. Pls decide soon kthxbai :)
19:28
<SimonSapin>
but what exactly is a token? In your algo anything but whitespace or / for type and subtype, anything but whitespace or = for name, …
19:29
<GPHemsley>
SimonSapin: Yeah, see, it's more complicated than it looks. (And that's even after simplifying what the RFCs say.) And don't forget the whole parameter issue with null vs. "" vs. actual content.
19:29
<SimonSapin>
the MIME rfcs probably have definition but I’m sure what it is
19:29
<GPHemsley>
jsbell: That's why I'm leaning towards characters in this case.
19:30
<SimonSapin>
yeah, I don’t think parameters without values (value is null) are actually a thing
19:30
<GPHemsley>
SimonSapin: Oh, they do. There are plenty of different RFCs with different definitions. That's why I've oversimplified at first pass.
19:30
<SimonSapin>
I think the only thing looking like this is base64 in data, but that can be special-cased
19:31
<GPHemsley>
I'd rather there weren't any special cases. Wouldn't it be nice to allow such extensibility?
19:31
<SimonSapin>
I don’t know
19:32
<SimonSapin>
I’d rather not base new stuff on MIME, this is only for defining existing protocols
19:32
<GPHemsley>
Especially if this evolves into some sort of API or something.
19:40
<SimonSapin>
GPHemsley: in data: you can omit type/subtype (defaults to text/plain) and only specify parameters like charset. It could either be a flag passed to your algorithm
19:40
<SimonSapin>
or data could have something like "if header starts with optional whitespace followed by ; then prepend text/plain" beforehand
19:46
<SimonSapin>
bbl
22:13
<jsbell>
In DOM3 the IDL for DOMException and DOMError define a |message| readonly DOMString attribute. In DOM4 the guts of DOMException logic are shuffled off to WebIDL which handwaves about "Exceptions have an associated message, a DOMString, which is exposed on an exception object in a language binding-specific manner."
22:16
<jsbell>
I'm assuming this means I can stuff a message on DOMError and everyone will be happy.
22:24
<jsbell>
annevk: ping?
22:34
<heycam>
jsbell, there is wording down later in the spec about what it means in terms of a message property on exceptions in JS
22:35
<heycam>
jsbell, see the second list of steps in http://dev.w3.org/2006/webapi/WebIDL/#es-throwing-exceptions
22:35
<heycam>
jsbell, (it passes the message to the constructor for the error)
22:35
<jsbell>
heycam: yeah - in this case I'm actually worrying about DOMError which as far as I can tell WebIDL doesn't touch at all
22:36
<heycam>
jsbell, ah ok, right. I am not really sure where DOMError is used currently, so no opinion on that. :)
22:36
<jsbell>
Sorry to cast aspersions on WebIDL. :)
22:37
<heycam>
heh np
22:42
<jsbell>
heycam: while I've got you though... did anything ever come of the "treat undefined parameters as missing like ES6" discussions http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0026.html ?
22:43
<jsbell>
I'm guessing that's on a TODO list somewhere.
22:44
<heycam>
jsbell, yeah, I need to make that change if ES6 has indeed changed its treatment of undefined passed to functions
22:44
<heycam>
but not done yet, you are right
22:44
<jsbell>
Cool, just making sure it hadn't been revisited and rejected.
22:45
<heycam>
it is in my folder of public-script-coord mail with ~400 unread emails ;)
23:42
<SimonSapin>
annevk: should decode() throw when given an invalid label but the string has a BOM? The label would be ignored anyway
23:46
<SimonSapin>
annevk: x-user-defined could also be implemented with an index, right?
23:50
<freedrull>
what can websockets do that you couldn't do with server sent events and a http connection with keep-alive?
23:50
<annevk>
SimonSapin: x-user-defined, can, yes
23:50
<annevk>
SimonSapin: yes, decode() should throw
23:51
<annevk>
nn
23:51
<Hixie>
freedrull: nothing
23:51
<freedrull>
:\
23:51
<Hixie>
then again, server sent events and a http connection with keep-alive can't do anything a carrier pigeon couldn't do :-)
23:51
<freedrull>
haha
23:51
<Hixie>
it's just way simpler with websockets
23:52
<freedrull>
i see