2013-10-01
[17:20:18.0000] <rniwa>
Hixie_: I have IE10

[17:21:35.0000] <rniwa>
Hixie_: it errors saying "unable to get property 'document' of undefined or null reference" at line 4

[17:22:02.0000] <rniwa>
Hixie_: the test ends with "FAIL: DOM did not change"

[17:44:50.0000] <rafaelw>
Hixie: can you remind me what this was about: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22482

[17:45:23.0000] <rafaelw>
Hixie_: ^

[18:32:48.0000] <annevk>
thanks TabAtkins, will take a look in the morning

[19:41:18.0000] <GPHemsley>
Can we just rename CSS to TabAtkins and get it over with?

[21:13:02.0000] <MikeSmith>
Hixie_: cabanier: did you guys have a chance to chat about DrawCustomFocusRing?

[21:19:04.0000] <cabanier>
MikeSmith: yes

[21:19:17.0000] <cabanier>
MikeSmith: on irc and the mailing list

[21:19:28.0000] <MikeSmith>
cabanier: ah good

[21:19:28.0000] <cabanier>
MikeSmith: I think the APIs can stand

[21:19:35.0000] <MikeSmith>
I'm catching up on e-mail now

[21:19:43.0000] <MikeSmith>
cabanier: why?

[21:19:43.0000] <cabanier>
MikeSmith: but Dominic is still on the fence

[21:19:47.0000] <MikeSmith>
can you summarize?

[21:20:21.0000] <cabanier>
MikeSmith: it's the same as in the emails.

[21:20:34.0000] <MikeSmith>
I'll read then

[21:20:43.0000] <cabanier>
MikeSmith: he wanted something new but drawCustomFocusRing actually already does it

[21:20:51.0000] <MikeSmith>
OK

[21:22:53.0000] <MikeSmith>
you do realize that Dominic's implementation can't be considered conformant if it doesn't ship?

[21:37:59.0000] <cabanier1>
MikeSmith: experimental implementations count

[21:38:20.0000] <cabanier1>
MikeSmith: I can also ping Apple or the webkit community to land it

[21:49:57.0000] <Hixie_>
rniwa: wacked. thanks.

[21:51:40.0000] <Hixie_>
rafaelw: nested <button>s, probably? i dunno. i'm sure it's fixed on the whatwg side. ;-)

[21:52:11.0000] <Hixie_>
bbiab

[01:12:37.0000] <zcorpan>
heycam|away: http://lists.w3.org/Archives/Public/www-style/2013Oct/0003.html

[01:13:05.0000] <MikeSmith>
I like Roy's template proposal for the responsive images stuff

[01:13:51.0000] <MikeSmith>
http://lists.w3.org/Archives/Public/public-html/2013Sep/0302.html

[01:14:54.0000] <MikeSmith>
if the goals are to make the syntax more readable and to use attributes instead of elements

[01:34:48.0000] <zcorpan>
Hixie_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23002 (bumping this, seems like high priority)

[01:35:33.0000] <zcorpan>
MikeSmith: iirc a template was the first design of srcset but there was some problem with it

[01:35:57.0000] <MikeSmith>
zcorpan: ok

[01:36:06.0000] <zcorpan>
i don't recall exactly what the problem was

[01:36:32.0000] <MikeSmith>
well clearly there are problems with all of these proposals

[01:39:31.0000] <MikeSmith>
zcorpan: so btw is a window object not a representation of a browsing context?

[01:39:48.0000] <zcorpan>
MikeSmith: no

[01:39:54.0000] <MikeSmith>
oh

[01:39:58.0000] <MikeSmith>
so what is?

[01:40:13.0000] <zcorpan>
there's no JS-exposed object

[01:40:17.0000] <MikeSmith>
ah

[01:42:37.0000] <zcorpan>
window is the closest thing, but it's complicated. :-) see http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#windows

[01:42:38.0000] <MikeSmith>
so a window just "contains" a browsing context

[01:42:44.0000] <MikeSmith>
yeah, reading that now

[01:44:05.0000] <zcorpan>
so iirc the WindowProxy is always the same for a given browing context, but the underlying Window can be swapped out in navigation

[01:44:26.0000] <zcorpan>
but i might be making that up

[01:44:42.0000] <MikeSmith>
yeah from reading the spec just now it seems like that's what would be the case

[01:45:00.0000] <MikeSmith>
that it's one-to-one with its WindowProxy

[01:45:23.0000] <zcorpan>
yep

[01:46:36.0000] <zcorpan>
anyway, a window doesn't have an origin either

[01:46:43.0000] <zcorpan>
document does

[01:47:56.0000] <zcorpan>
so if you want "origin of a given browsing context", you'd probably say "origin of a given browsing context's active document"

[01:48:53.0000] <MikeSmith>
is that the origin that window.location provides?

[01:50:19.0000] <zcorpan>
no, i think location.origin gives the origin of the location.href URL

[01:51:05.0000] <MikeSmith>
ok

[01:55:09.0000] <zcorpan>
but maybe it should give the document's origin instead

[01:55:19.0000] <zcorpan>
/me files a bug

[02:04:41.0000] <zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23406

[02:11:24.0000] <MikeSmith>
I would Cc myself on that one..

[02:31:14.0000] <zcorpan>
/me finds http://cssdeck.com/ which uses cont.style.setProperty('display', 'block', '!important'); - the bang should be omitted

[02:34:43.0000] <jgraham>
MikeSmith: I think "you have to generate 128 images" is not going to fly with authors, even if photoshop does it automatically

[02:35:00.0000] <MikeSmith>
jgraham: yeah, agreed about that

[02:35:09.0000] <MikeSmith>
for sure

[02:35:49.0000] <MikeSmith>
and maybe that was the same problem with the template idea that came up back when it was first proposed

[03:42:00.0000] <gsnedders>
hsivonen: I sent you an email. A response would be nice this week. :)

[04:06:32.0000] <hsivonen>
gsnedders: ack

[06:51:45.0000] <zcorpan>
i don't know where to start with filling in the blanks in this section... http://dev.w3.org/csswg/cssom-view/#the-geometryutils-interface

[06:56:48.0000] <Ms2ger`>
zcorpan, leave it to the GeometryOM spec :)

[06:58:04.0000] <zcorpan>
Ms2ger`: that doesn't help because (a) that section isn't moving there and (b) i'll be editing that too

[07:02:29.0000] <zcorpan>
but i guess i can procrastinate by shuffling things between specs, switching to bikeshed, work on critic backlog, play flash games, eat beer sausages, etc

[07:03:14.0000] <jgraham>
"beer sasuages"

[07:03:25.0000] <jgraham>
That's a German thing, right?

[07:03:38.0000] <zcorpan>
yeah i think so

[07:04:11.0000] <zcorpan>
bought 10 of those at a market the other day

[07:05:08.0000] <MikeSmith>
I vote for critic backlog

[07:05:30.0000] <MikeSmith>
jgraham: btw please add a priority flag in critic

[07:06:37.0000] <jgraham>
MikeSmith: For what purpose?

[07:07:00.0000] <odinho>
what's your use case?

[07:07:33.0000] <MikeSmith>
for me to up-prioritize all things I submit for review

[07:07:37.0000] <MikeSmith>
jump the queue

[07:07:38.0000] <jgraham>
(the intention is that you don't have a 6 month+ review backlog, so we are clearly already doing it wrong. But if you need something urgently looked at, out of band communication/guilt tripping seems more likely to be effective)

[07:07:55.0000] <jgraham>
Sigh

[07:08:33.0000] <MikeSmith>
bubble up

[07:08:35.0000] <jgraham>
I have now got all my changes to wpt serve so intermingled that it will be more effort than I am willing to spend to reconstruct a reasonable history

[07:10:08.0000] <jgraham>
/me gives up

[07:11:27.0000] <MikeSmith>
jgraham: you mean the commits you already made?

[07:11:47.0000] <MikeSmith>
or otherwise, you can't do the git add -p thing?

[07:14:08.0000] <jgraham>
MikeSmith: Yeah, add -p sort of works, except I have "conflicts" i.e. multiple logically seperate changes touching the same line of code

[07:15:59.0000] <zcorpan>
MikeSmith: any reason to not use html5lib test format for the NCR tests?

[07:17:32.0000] <wilhelm_>
Boom?

[07:18:54.0000] <zcorpan>
MikeSmith: there's a button to ping a review, but in my case i'm as unlikely to read the ping email as the original new review email

[07:18:55.0000] <jgraham>
Is it some Google policy to use irccloud?

[07:19:07.0000] <jgraham>
That took out most of their employees

[07:19:32.0000] <zcorpan>
MikeSmith: "[cc]" is useful for me to find your reviews, though

[07:23:39.0000] <SimonSapin>
jgraham: maybe because chromebooks can not use local IRC clients?

[07:24:34.0000] <odinho>
Yea. But there's an irc extension tho, isn't there?

[07:24:41.0000] <SimonSapin>
dunno

[07:24:52.0000] <jgraham>
Surely they aren't all actually using ChromePooks

[07:24:56.0000] <jgraham>
*ChromeBooks

[07:26:00.0000] <SimonSapin>
not all, but enough to seem most of your biased sample? :)

[07:27:33.0000] <MikeSmith>
zcorpan: the NCR tests are meant to be used directly with the validator

[07:28:05.0000] <zcorpan>
https://critic.hoppipolla.co.uk/r/339 vs https://critic.hoppipolla.co.uk/r/340 confuses me a bit

[07:29:13.0000] <MikeSmith>
zcorpan: last time I looked at the html5lib tests, it seemed like there was some pre-processing step I needed to run to get actual HTML from them. Or that that HTML is just generated in memory or whatever and fed to the test runner

[07:30:16.0000] <MikeSmith>
I'm happy to use the html5lib format if it can be used directly with the validator

[07:30:57.0000] <MikeSmith>
like, as a static file that I can put a URL to point the validator to

[07:31:36.0000] <MikeSmith>
(though what the validator test runner actually does is to read the files locally)

[07:32:40.0000] <zcorpan>
MikeSmith: yeah, i guess you would need to generate HTML from them. are the existing html5lib tests not interesting for the validator to make it worthwhile to write that script and fix the #errors data?

[07:34:04.0000] <jgraham>
zcorpan: I think the PR you just merged is wrong

[07:34:18.0000] <jgraham>
It isn't *more* wrong than the existing code, so no real harm done

[07:34:22.0000] <jgraham>
But still

[07:34:37.0000] <zcorpan>
/me goes to play flash games

[07:34:47.0000] <MikeSmith>
zcorpan: no, I think they are actually intereesting for the validator. I was just being lazy in not wanting to bother to figure out how to generate static HTML from them

[07:34:58.0000] <jgraham>
/resources/WebIDLParser.js doesn't exist. Except in some places like w3c-test.org

[07:35:12.0000] <zcorpan>
MikeSmith: ok. fair enough, and i guess that doesn't need to block the PR

[07:35:31.0000] <zcorpan>
jgraham: so what's correct?

[07:35:41.0000] <jgraham>
zcorpan: Good question

[07:36:22.0000] <jgraham>
/resources/webidl2/lib/webidl2.js really exists

[07:36:27.0000] <jgraham>
And is the new code

[07:36:47.0000] <jgraham>
But a) the URL is horrible and b) it's not really clear to me if the tests need to be updated

[07:36:48.0000] <MikeSmith>
zcorpan: yeah I guess I could land those in the PR for now and deal with porting the html5lib ones later

[07:38:29.0000] <zcorpan>
jgraham: can you file a bug on web-platform-tests or something about this so it's less likely we forget about this?

[07:39:59.0000] <jgraham>
zcorpan: There is https://critic.hoppipolla.co.uk/7289dbaa?review=340 as well

[07:40:15.0000] <jgraham>
Uh, the review not that commit in particular

[07:40:32.0000] <jgraham>
Basically we should just decide if that URL is OK

[07:40:51.0000] <jgraham>
Or if we want to introduce some kind of static URL map to wptserve

[07:41:15.0000] <jgraham>
(which would block fixing this issue on me, although w3c-test.org could use a symlink in the meantime)

[08:21:34.0000] <MikeSmith>
I can make w3c-test.org symlinks as easily as making silver-dollar pancakes

[08:27:17.0000] <jgraham>
/me wonders how easily that is

[08:27:31.0000] <jgraham>
Anyway w3c-test.org-specific solutions are not OK

[10:33:05.0000] <annevk>
Hixie_: https://github.com/dslomov-chromium/ecmascript-structured-clone

[10:33:21.0000] <annevk>
zcorpan: ^^

[10:52:31.0000] <smaug____>
why is there PortCollection object?

[10:52:37.0000] <smaug____>
what exposes gc behavior to scripts

[10:52:48.0000] <Hixie_>
actually it's carefully designed not to expose gc behaviour

[10:52:50.0000] <Hixie_>
that's the whole point :-)

[10:52:58.0000] <jgraham>
Hixie_: Pretty sure you could argue that crashing might be allowed under the hardware limitations clause :) e.g. if the OS automatically kills processes that use too much memory

[10:53:07.0000] <Hixie_>
heh

[10:53:09.0000] <Hixie_>
i guess

[10:53:15.0000] <smaug____>
Hixie_: it does

[10:53:22.0000] <Hixie_>
jgraham: that's not the case bz is talking about, though, i'd guess :-)

[10:53:23.0000] <Hixie_>
smaug____: how?

[10:53:29.0000] <Hixie_>
smaug____: if it does, that's a bug

[10:54:10.0000] <smaug____>
Hixie_: you run it using a timer occasionally to detect when certain port has been collected

[10:54:43.0000] <jgraham>
Hixie_: It's hard to know what the actual use case is since no one has said yet

[10:56:07.0000] <smaug____>
s/run/iterate/

[10:56:08.0000] <Hixie_>
smaug____: the port won't be collected so long as the other port exists

[10:56:19.0000] <smaug____>
what other port

[10:56:38.0000] <Hixie_>
smaug____: a message port is entangled with another message port. so long as the other isn't GC'ed, the former won't be ethir.

[10:56:41.0000] <Hixie_>
either.

[10:56:47.0000] <Hixie_>
message ports keep each other alive.

[10:57:09.0000] <smaug____>
that doesn't matter

[10:57:58.0000] <Hixie_>
smaug____: hm, i guess you're right. you could send a message out and just wait for the message to no longer come out.

[10:58:02.0000] <Hixie_>
*shrug*

[10:58:17.0000] <smaug____>
var p = PortCollection(); var c = new MessageChannel(); p.add(c.port0); p.add(c.port);

[10:58:23.0000] <smaug____>
er, port1

[10:58:36.0000] <smaug____>
then iterate the ports in p

[10:58:40.0000] <smaug____>
using a timer

[10:58:52.0000] <smaug____>
at some point the ports disappear

[10:59:23.0000] <Hixie_>
sure

[10:59:35.0000] <Hixie_>
i'm happy to consider other ways to address this use case if you can think of one

[11:00:07.0000] <Hixie_>
this doesn't let you detect the exact moment GC happens, but it's true that it does let you tell a range between which GC happened.

[11:00:18.0000] <smaug____>
well, remove PortCollection

[11:00:41.0000] <Hixie_>
that doesn't exactly handle the use case well

[11:00:49.0000] <jgraham>
I thought the problem with GC was not "I can tell the exact moment", but more "pages might rely on the specifies of GC in one implemetation"

[11:00:59.0000] <smaug____>
exactly

[11:01:02.0000] <Hixie_>
specifics = exact, no?

[11:01:12.0000] <Hixie_>
again, i'm happy to consider alternatives.

[11:01:13.0000] <jgraham>
Not really

[11:01:56.0000] <jgraham>
It only has to be exact enough that the difference is observed some noticable fraction of the time

[11:02:06.0000] <smaug____>
/me doesn't understand the use cases for PortCollection

[11:02:56.0000] <Hixie_>
smaug____: you want to broadcast a message to many ports, but you don't want to prevent them from being GC'ed. For example, you're a shared worker and you want to keep all your clients up to date with what the server is telling you.

[11:03:58.0000] <jgraham>
It feels like there are two mutually exclusive goals there

[11:04:24.0000] <Hixie_>
yes, hence the current design being a compromise between them

[11:04:31.0000] <jgraham>
(hopefully not though, but I don't have a good idea)

[11:05:46.0000] <jgraham>
Anyway, I have to go, but the ability to improve GC behaviour transparently has been a big win in recent times. We should be super-careful about giving up that freedom

[11:05:47.0000] <smaug____>
shouldn't we have a PortCollection which doesn't expose iterate()

[11:06:06.0000] <smaug____>
basically PortCollection which just has postMessage or some such

[11:07:15.0000] <Hixie_>
smaug____: you can still detect the time range of GC that way

[11:07:25.0000] <Hixie_>
smaug____: just see if you receive the message

[11:07:42.0000] <smaug____>
indeed

[11:08:19.0000] <annevk>
Can people take a look at the HTML imports stuff please? And in particular https://www.w3.org/Bugs/Public/show_bug.cgi?id=21976

[11:08:35.0000] <annevk>
It seems like some of the Chrome guys are proposing some kind of hackish design.

[11:20:36.0000] <zcorpan>
what should i do about the identical members of these interfaces? http://dev.w3.org/csswg/cssom-view/#the-domrect-and-domrectreadonly-interfaces - move to a new interface like DOMRectBase and let them inherit from that? or [NoInterfaceObject] + implements?

[11:21:54.0000] <annevk>
the latter is what DOM uses

[11:22:45.0000] <zcorpan>
why?

[11:23:00.0000] <annevk>
seems close to what JavaScript does

[11:30:57.0000] <zcorpan>
like toString()?

[11:31:35.0000] <annevk>
zcorpan: having generic methods that operate on multiple objects

[11:31:46.0000] <annevk>
zcorpan: e.g. the way some ArrayBuffer stuff is copied from Array

[11:34:38.0000] <zcorpan>
any opinion on what to call the interface to hold the top/right/bottom/left members?

[11:36:01.0000] <annevk>
zcorpan: it's nointerface so... AbstractRect ?

[11:37:01.0000] <annevk>
zcorpan: having a distinct term for origin might be nice

[11:37:10.0000] <annevk>
zcorpan: nothing comes to mind :/

[11:37:37.0000] <zcorpan>
origin coordinates?

[11:38:02.0000] <zcorpan>
that seems not quite right

[11:39:14.0000] <annevk>
grounding? hmm

[11:39:21.0000] <annevk>
SVG uses origin for this too?

[11:40:09.0000] <annevk>
it does

[12:00:40.0000] <zcorpan>
[NoInterfaceObject] + implements is equivalent to repeating the members in both interfaces, at least in the JS binding, right?

[12:05:11.0000] <Ms2ger`>
Yes

[12:30:23.0000] <zcorpan>
there, now i've said on www-style that i don't know what i'm doing, i guess i can call it a day

[12:37:30.0000] <miketaylr>
zcorpan: careful, they might make you chair

[12:37:31.0000] <miketaylr>
/me ducks

[13:07:41.0000] <rektide>
CSSStyleDeclaration.hasProperty what in the haystack why are you NOT a thing

[13:09:12.0000] <rektide>
ok i guess the value i'm expecting it to return i'm expecting to be some kind of class list thing

[13:12:01.0000] <rektide>
wow the matrix transform between .transition and .transition-property is a living hell

[13:12:47.0000] <rektide>
got help anyone brave enough to meddle with individual tokens in the transition-{property,delay,duration} rowization, brave crazy soul

[13:20:21.0000] <Domenic_>
zcorpan: annevk: I tried to implement roc's suggestion in JS and it was not great: https://gist.github.com/domenic/6736258 I guess you could insert more branding checks in the setters.

[13:30:45.0000] <annevk>
Domenic_: doesn't look too bad?

[13:36:44.0000] <Domenic_>
annevk: yeah, except for the branding checks I guess. I suppose I should add those so it's clearer.

[13:41:19.0000] <Domenic_>
annevk: https://gist.github.com/domenic/6736258

[13:43:25.0000] <annevk>
zcorpan: could you check "!/" as sub-path separator?

[13:43:33.0000] <annevk>
wycats: ^^ zcorpan did checking

[13:44:38.0000] <annevk>
Domenic_: can't you define an anonymous function in DOMRectMutable2 that does a lot of the boilerplate?

[13:45:07.0000] <Domenic_>
annevk: what do you mean?

[13:48:27.0000] <annevk>
something you pass prop and value and that does function blah (prop, value) { assertBranded(this); privates.get(this)[prop] = +value }

[13:55:40.0000] <Domenic_>
sure, although i'd also make it pass `this` so that you avoid having an observable member function

[14:00:19.0000] <Hixie_>
bholley: you around to resume our talk about https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 ?

[14:00:53.0000] <bholley>
Hixie_: do you mind waiting a week? We've got a mozilla summit in brussels starting on thursday and I need to finish prepping my talk

[14:01:01.0000] <Hixie_>
sure, i'm in no rush

[14:01:10.0000] <bholley>
Hixie_: cool. I'll ping you next week :-)

[14:01:20.0000] <Hixie_>
unfortunately i forgot where we got to in our last discussion :-(

[14:01:28.0000] <Hixie_>
(i was going to update the bug accordingly)

[14:01:59.0000] <bholley>
Hixie_: it's ok. I think it'll be helpful to review it all next week anyway

[14:02:06.0000] <Hixie_>
k

[14:02:14.0000] <Hixie_>
(see also mail i just sent you)

[14:02:22.0000] <Hixie_>
(also no rush)

[14:05:02.0000] <Hixie_>
i wish there was a way to archive bug comments, or close them or something, so you could view the bug with only the "latest thinking"

[14:05:22.0000] <Hixie_>
some of these bugs are out of hand


2013-10-02
[18:31:18.0000] <zewt>
nothing discourages filing bugs quite as much as bugzilla 10-mile-long component lists

[00:53:59.0000] <zcorpan>
annevk: i see lots of !/ in href/src before #

[00:57:12.0000] <zcorpan>
e.g. <a class="tabmenulist2" href="http://www.famouswhy.com/Movie/The_Informant!/85308.html" >The Informant!</a>

[00:57:16.0000] <zcorpan>
<a href="/wps/portal/PN_CTR/Home/homepage/!ut/p/b1/04_Sj9S1tDQwMTc0MDPRj9CPykssy0xPLMnMz0vMAfGjzOJDjQxCHZ0MHQ0MTLxcDDxdvHwNQ8yNDb1NjfQjgQrMcSsw1w_RjzAwiQ_OqizwDgku8fZJNg_Mqiwv8M42DqsyDgsNcwx0jApPdCsoV1TUD9ePxG9YbpR7WaWjoiIAf90Lqg!!/?content=Homepage" class="nav_link_active">Homepage</a>

[00:57:47.0000] <zcorpan>
<img src="https://a1s.unicdn.net/polopoly_fs/1.300930.1351767812!/image/1987622790.jpg_gen/derivatives/265x210/1987622790.jpg" alt="Kitten" class="background" />

[01:38:58.0000] <zcorpan>
Domenic_: webidl takes care of the branding check aiui

[02:20:35.0000] <Domenic_>
zcorpan: WebIDL is not the language of the web. The trick is to consider whether your API is something intuitive to JS developers, fitting with common practices, or whether it's some crazy monstrosity generated by WebIDL bindings.

[02:22:59.0000] <zcorpan>
Domenic_: webidl came out of what was needed by html, more or less

[02:23:51.0000] <Domenic_>
sure, and it serves a purpose. but just because something can be done in webidl, doesn't mean it's a good api. for that, it's best to try implementing in JS, and seeing how natural it is.

[02:24:21.0000] <zcorpan>
yeah, fair enough

[02:25:48.0000] <zcorpan>
i'll outsource that to you :-)

[02:28:24.0000] <Domenic_>
yeah, it became clear nobody was going to try to do things in JS, so I just did it. Happy for that to be my way to contribute :)

[03:41:59.0000] <jgraham>
/me wonders how ES6 WeakMaps avoid exposing GC

[03:44:04.0000] <jgraham>
(also it seems to make the PortCollection thing unneeded)

[03:55:49.0000] <zcorpan>
jgraham: there's a convention for -manual in the file name, right?

[03:59:15.0000] <jgraham>
zcorpan: Right

[04:09:21.0000] <jgraham>
zcorpan: BTW if you are looking at critic reviews https://critic.hoppipolla.co.uk/r/343 would be nice and is not that time consuming, I think

[04:09:33.0000] <jgraham>
If you don't do it I will though

[04:09:40.0000] <jgraham>
So don't worry

[04:15:59.0000] <zcorpan>
what's the outlook for the microdata api?

[04:16:16.0000] <jgraham>
Bleak afaict

[04:17:06.0000] <jgraham>
But I think the tests changed because DOMTokenList changed

[04:17:20.0000] <jgraham>
So I'm not sure it's really Microdata-API specific

[04:17:36.0000] <zcorpan>
yeah, was mostly curius if something changed recently

[04:26:53.0000] <jgraham>
zcorpan: Thanks!

[04:27:04.0000] <zcorpan>
welcome

[04:28:55.0000] <Ms2ger>
zcorpan, and thanks from me too :)

[04:29:07.0000] <annevk>
zcorpan: can you try some other combinations that end with / ?

[04:29:20.0000] <annevk>
zcorpan: e.g. $/

[04:30:01.0000] <annevk>
zcorpan: maybe &/, ^/, */, @/

[04:35:38.0000] <zcorpan>
$ grep -rEio "<[a-z][^>]*\s(href|src)\s*=\s*[^>#? ]+[$&^*@]/[^>]*>" . > ~/Desktop/combinators-in-href-src.txt

[04:45:39.0000] <foolip>
nessy, did you already update the spec for "Redesign the positioning mechanism"?

[04:45:54.0000] <foolip>
your last comment on bug 20037 seems to say so

[04:57:16.0000] <zcorpan>
annevk: $ 15, & 11, ^ 0, * 1021, @ 1067

[04:59:55.0000] <zcorpan>
no wait, ^ 20

[05:01:12.0000] <annevk>
thanks

[05:01:25.0000] <zcorpan>
& might be higher if people use &amp;

[05:01:42.0000] <annevk>
good point

[05:01:47.0000] <annevk>
but they all suck basically

[05:02:49.0000] <annevk>
%/ would be unique I guess, but doesn't work in IE

[05:16:54.0000] <nessy>
foolip, yes, the update is in the editor's draft

[05:17:25.0000] <foolip>
nessy, so is 20037 resolved to your satisfaction, then?

[05:17:37.0000] <nessy>
see comment 47 on that bug

[05:17:56.0000] <foolip>
oh, I seem to have missed that

[05:18:01.0000] <nessy>
foolip, it was initially, but then David raised some additional issues, which is why we're now continuing

[05:18:15.0000] <foolip>
I have a bit of a hard time pinning down what exact problem 20037 is supposed to solve, which is why I keep suggesting random changes

[05:18:26.0000] <nessy>
ha, lol

[05:18:53.0000] <nessy>
that's why I wrote comment 51

[05:19:10.0000] <nessy>
it's trying to summarize the remaining issue

[05:20:48.0000] <nessy>
basically, what I have specified right now is the behaviour of background-position

[05:21:08.0000] <foolip>
is there a single easy-to-read commit that I could review?

[05:21:41.0000] <foolip>
and does this change alter the default rendering in a way that could break some content?

[05:21:55.0000] <nessy>
however, since we only use the percentage-part of background-position, specifying things like "have the top of the cue box be 30% from the top" becomes extremely difficult

[05:22:00.0000] <foolip>
I'm hoping that there isn't enough content to restrict us yet, but I have no idea

[05:22:56.0000] <foolip>
right, CSS's background-position only distributes the remaining space on either side, really, it has no concept of aligning a particular edge to a percentage, that I know of

[05:23:30.0000] <nessy>
if you look at https://dvcs.w3.org/hg/text-tracks/ , you can see the patches

[05:23:35.0000] <foolip>
so you mean to solve this by making align take two values as letting position refer to the offset to that alignment point?

[05:24:04.0000] <nessy>
The key change was https://dvcs.w3.org/hg/text-tracks/rev/f15d41b309e5 , but it's quite big

[05:24:40.0000] <foolip>
oh, look at that algorithm go, we had that implemented step-by-step in Presto :)

[05:24:45.0000] <nessy>
I agree that we don't want to break existing content, but I don't think we will - at least not those that were quite specific

[05:25:41.0000] <nessy>
blink and webkit do, too

[05:25:42.0000] <foolip>
if you plan more changes for 20037, maybe I should wait until you're done and then review the whole of it for sanity

[05:25:57.0000] <nessy>
I still have to make the change to my javascript experimental code, too

[05:26:15.0000] <nessy>
foolip: a review would absolutely be a good idea

[05:27:57.0000] <foolip>
nessy, when you think that you're done, a single comment that summarizes the intended new behavior of the modifies properties would help a lot, so that I have some idea what I should be looking for

[05:28:02.0000] <nessy>
as for the final change that I'm proposing is exactly what you say above, except I think it needs to be a new cue setting

[05:28:21.0000] <nessy>
because we want to leave "align" as is as the alignment within the cue box

[05:28:21.0000] <foolip>
s/modifies/modified/

[05:28:32.0000] <foolip>
because of compat?

[05:28:39.0000] <nessy>
indeed

[05:29:02.0000] <foolip>
if we need two properties then I think align+text-align had a nice ring to it, kind of matches <img align> and CSS text-align

[05:29:13.0000] <nessy>
foolip: when I add the changes to the cvs repo, they are all compressed into one commit, so you should get exactly what you're asking for

[05:29:18.0000] <foolip>
but you think that'll break too much stuff?

[05:29:41.0000] <nessy>
yeah, I hesitate to rename "align" to "text-align"

[05:29:54.0000] <nessy>
because of backwards compatibility

[05:30:03.0000] <foolip>
what if the default value of text-align were the value of align?

[05:30:18.0000] <foolip>
or won't that make sense with the new values?

[05:30:26.0000] <nessy>
hmm...

[05:30:42.0000] <nessy>
of the first dimension?

[05:31:44.0000] <foolip>
nessy, yeah, if the first value of align is always in the text direction (sloppy wording, but you see what I mean)

[05:32:00.0000] <nessy>
yup

[05:32:04.0000] <nessy>
I think it could work

[05:33:10.0000] <nessy>
default value of align would need to be "middle,middle" anyway

[05:33:11.0000] <foolip>
but I think that we should pick the names and behavior that make the most sense in the long term

[05:33:37.0000] <nessy>
ok, that's fair enough

[05:34:08.0000] <nessy>
sticking with some css-likeness is also sensible

[05:34:50.0000] <foolip>
I guess in CSS terms there's vertical-align and text-align

[05:35:49.0000] <nessy>
not really: vertical-align is with reference to a line whereas we are talking about the cue box

[05:36:11.0000] <foolip>
nessy, I'm just saying what properties actually exist in CSS, not that they map to what we want

[05:36:14.0000] <nessy>
but text-align is definitely appropriate for alignment withing the box

[05:36:23.0000] <nessy>
right

[05:36:25.0000] <foolip>
then there's the (obsolete) align and valign attributes...

[05:36:52.0000] <nessy>
I'd try to avoid making false friends

[05:38:01.0000] <foolip>
yeah, if they actually mean something completely different, I don't know in detail what these attributes do

[05:38:15.0000] <nessy>
we could have align and valign instead of a single align with two values, if you think that makes more sense

[05:39:05.0000] <foolip>
hmm, valign means vertical-align, which I guess makes it weird for vertical text

[05:39:16.0000] <nessy>
but the align attribute in HTML used to mean more what text-align in CSS does, so we shouldn't really do that

[05:39:45.0000] <foolip>
nessy, davve tells me that align used to be something like floats

[05:39:50.0000] <nessy>
that's why I suggested cue-align - it has no history and less confusion

[05:40:08.0000] <nessy>
oh!

[05:40:22.0000] <foolip>
yeah, but if we need to keep the existing align it needs to do *something*...

[05:40:36.0000] <foolip>
maybe a shorthand that sets both cue-align and text-align?

[05:40:51.0000] <zcorpan>
foolip: it depends on the element (html's align)

[05:41:33.0000] <nessy>
we have to set a cue alignment for the position direction and for the line direction, so we already need two values for that

[05:42:29.0000] <nessy>
foolip: are you suggesting to extend "align" to a triple value attribute, first the text-align within the cue, then the position direction cue align, then the line direction cue align?

[05:43:30.0000] <foolip>
no, I don't have a finished solution that I think is sane, yet

[05:43:58.0000] <foolip>
but we have an existing align that takes a single value, presumably we want to keep that and let it behave as close as possible to what it always has?

[05:44:15.0000] <nessy>
yes

[05:44:28.0000] <foolip>
so I guess the options are:

[05:45:06.0000] <foolip>
1. add new granular properties *-align and let their default values depend on the old align

[05:45:23.0000] <foolip>
2. let the old align take on a new meaning and add just a single new *-align

[05:45:46.0000] <foolip>
3. let the old align do everything, comma-separated

[05:45:53.0000] <annevk>
zcorpan: could you check %/ just in case?

[05:45:56.0000] <foolip>
is that about it?

[05:46:42.0000] <nessy>
I think so

[05:47:21.0000] <foolip>
I guess you're not about to do the spec edit, so maybe list the alternatives in a comment and see if other people have better ideas?

[05:47:30.0000] <nessy>
except, the default value thing of option 1 should be on option 2 with the default value of the new align depending on the next *-align properties

[05:48:08.0000] <nessy>
I'm definitely not editing tonight - edits after 11pm end up in disaster

[05:48:31.0000] <foolip>
right, it's late down under, I forget :)

[05:49:03.0000] <zcorpan>
annevk: i run out of disk space when greping :-(

[05:49:07.0000] <foolip>
well thanks for the hand-holding in any case, I feel like I have a bit more of a clue what the problems are now

[05:49:12.0000] <nessy>
If I write another comment on that huge bug, I wouldn't be surprised about attacks on my life ;-) so feel free to propose the three options

[05:49:31.0000] <foolip>
nessy, haha, ok, I'll try to keep it short

[05:49:35.0000] <zcorpan>
annevk: isn't % a non-option anyway?

[05:49:39.0000] <annevk>
zcorpan: is that a bad sign?

[05:49:48.0000] <annevk>
zcorpan: depends on what we decide to care about

[05:49:54.0000] <nessy>
foolip: thanks! also thanks for the patience - that bug is really hard to follow!

[05:51:27.0000] <nessy>
and that's me for today! nn

[06:17:57.0000] <zcorpan>
turns out grep -r is the sucker's method

[06:19:30.0000] <zcorpan>
annevk: there are at least 28 %/

[06:20:21.0000] <jgraham>
Hmm, why is -r a problem?

[06:20:38.0000] <zcorpan>
it consumes like 2G of memory

[06:21:16.0000] <jgraham>
Wait, is this OSX? Does -r do something different on BSD grep?

[06:22:30.0000] <zcorpan>
osx, yeah. no idea. now i use http://stackoverflow.com/questions/5200591/how-to-use-grep-efficiently which doens't have the memory problem

[06:22:44.0000] <zcorpan>
annevk: 34

[06:23:17.0000] <annevk>
that's weird

[06:25:11.0000] <zcorpan>
<a href="http://twitter.com/%user_screen_name%/status/%id_str%" target="_blank" rel="nofollow"> looks like a template

[06:25:37.0000] <zcorpan>
<a href="http://www.ar-wp.com/forums/users/%d8%a7%d9%84%d8%b9%d8%b1%d8%a8%d9%8a-%d8%b3%d9%85%/" title="العربي سمير" rel="nofollow">

[06:26:19.0000] <zcorpan>
<a href='http://modern-shop.ibuy.co.th/360977/ภาพวาดสีน้ำมัน+100%/' target='_blank'>

[06:39:20.0000] <zcorpan>
annevk: 0 instances of => and =&gt;

[06:39:36.0000] <annevk>
zcorpan: you mean like =>/ ?

[06:39:48.0000] <annevk>
zcorpan: has to end with a slash

[06:41:01.0000] <zcorpan>
yeah well there are presumably no instances with a slash after :-)

[06:41:58.0000] <zcorpan>
but maybe > is annoying in html

[06:43:15.0000] <annevk>
yeah, also with <URL>

[06:55:38.0000] <zcorpan>
lots of |/

[06:59:15.0000] <jgraham>
Why does it have to end in /?

[06:59:32.0000] <jgraham>
Also, this isn't going to work

[07:00:51.0000] <annevk>
Otherwise relative URLs don't work in the fallback case

[07:05:42.0000] <zcorpan>
any objections to interface DOMRect : DOMRectReadOnly {...} ?

[07:45:19.0000] <annevk>
zcorpan: does class X extends XX in JS enable that? I doubt it

[08:21:36.0000] <Domenic_>
annevk: it does per my gist...

[08:21:59.0000] <annevk>
Domenic_: oh yeah, doh

[08:24:49.0000] <Domenic_>
it's probably the best solution for avoiding code duplication. if i were writing from scratch in JS I might do mixins or similar though, not sure. seems fine though, not worth worrying about more than we have already.

[08:28:28.0000] <Domenic_>
What are the best ways for community members to meet standards writers face to face? I don't see a lot of standards people at the same conferences as me; do they have their own?

[08:34:10.0000] <jgraham>
Well in theory TPAC

[08:34:27.0000] <jgraham>
Except that's Pay-to-Play and you are supposed to be in a WG

[08:35:04.0000] <jgraham>
(better than TC39 I guess)

[08:35:35.0000] <jgraham>
Oh and it seems like no one is going this year

[08:36:01.0000] <Domenic_>
seems bad

[08:36:26.0000] <Domenic_>
need more things like tc39 and tag just did in boston i'd think... those were well-received from what i could tell.

[08:36:50.0000] <Domenic_>
although i guess esoteric-css-feature-working-group might not get a great turnout to their meetup, hmm.

[08:37:11.0000] <jgraham>
So there is also a problem that there aren't that many people like annevk who are professional standards wonks

[08:37:35.0000] <jgraham>
Even people that are editing specs are often really engineers

[08:38:15.0000] <jgraham>
(by which I mean that the bulk of their job is implementation)

[08:38:39.0000] <Domenic_>
Right. I guess I am just working from my experiences at conferences making open-source much more approachable because then I have faces and personalities for the people I see on GitHub. It would be cool if there were similar things for the people involved in web standards, so we have some empathy for the people on mailing lists.

[08:38:59.0000] <jgraham>
So those people are often super-busy

[08:39:28.0000] <jgraham>
Right, so I agree that there is a value to F2F meetings

[08:39:31.0000] <zewt>
(unlike the guys who just do specs? :)

[08:39:47.0000] <jgraham>
I'm just saying that they don't really happen at the moment

[08:39:55.0000] <jgraham>
Or don't happen for the "right" reasons

[08:40:16.0000] <Domenic_>
maybe i should pressure conference organizers to invite them more. They might be too busy to accept, but it could help in some cases.

[08:40:36.0000] <jgraham>
Sure

[08:41:09.0000] <jgraham>
If you are happy getting a lot of Anne / Alex / Tab, that will work OK

[08:41:18.0000] <jgraham>
If you want more people than that, less so

[08:41:24.0000] <slightlyoff>
what's my fault?

[08:41:26.0000] <jsbell>
That would be an entertaining keynote tag-team right there

[08:42:01.0000] <jgraham>
I guess there is also TestTWF. Which is occasionally a thing.

[08:42:47.0000] <jgraham>
But it usually isn't part of a larger conference

[08:43:48.0000] <jgraham>
(although perhaps it could be?)

[08:44:30.0000] <Domenic_>
it would be cool if it were, hmm. i've always wanted to go to them but can't justify travel; bundling it with a conference would work.

[08:44:52.0000] <Domenic_>
testtwf seems pretty successful and awesome from what i read on blog posts.

[08:45:10.0000] <jgraham>
So the problem with that is that TestTWF really needs at least a whole day

[08:45:25.0000] <jgraham>
And preferably a little longer

[08:46:38.0000] <Domenic_>
sure, but if it was just the day after the conference, that'd help me not have to book a separate flight.

[08:46:50.0000] <jgraham>
Yes that makes sense

[08:47:29.0000] <jgraham>
Historically they have been close to TPAC or other meetings where it is known that there will be a lot of people to act as "experts"

[08:47:44.0000] <jgraham>
Which returns us to the original problem

[08:47:49.0000] <Domenic_>
ah right that makes sense. hmm.

[08:48:06.0000] <jgraham>
Of course you could run a smaller event with fewer experts

[08:48:45.0000] <jgraham>
I'm pretty sure we could do one in London with just the ambient population of experts

[08:49:38.0000] <jgraham>
It could be possible to schedule that to fit with some bigger conference if there is one

[08:50:37.0000] <Domenic_>
great british nodeconf :trollface:

[08:51:17.0000] <jgraham>
(but by design that will only be a few spec authors)

[08:53:35.0000] <astearns>
some people have held small TestTWF meetups, and when that happens we try to help get nearby spec editors to attend

[08:54:11.0000] <astearns>
I think it would work to organize a medium-size TestTWF around a large non-W3C conference

[08:54:42.0000] <astearns>
we'll be talking about TestTWF at a booth at HTML5DevCon this month

[09:03:38.0000] <jgraham>
Well, as I almost said, I have a vauge idea to do TestTWF-London sometime early next year. But nothing at all definite.

[09:04:28.0000] <astearns>
I've never been to London - if it becomes definite I'll definitely argue for the travel budget

[09:23:22.0000] <annevk>
Domenic_: I want StandardsCamp or some such

[09:23:43.0000] <annevk>
Domenic_: or WebPlatformCamp / BrowserCamp, whatever we want to call it

[09:24:25.0000] <annevk>
Domenic_: for experienced developers, implementors, and editors

[09:28:12.0000] <jgraham>
annevk: I think you will have to organise that if you want it

[09:28:20.0000] <Ms2ger>
annevk, you'll be in Brussels, right?

[09:28:27.0000] <jgraham>
(I agree that it sounds like a nice idea)

[09:28:29.0000] <Ms2ger>
/me wonders if there's lists somewhere

[09:28:46.0000] <jgraham>
There is a spreadsheet I think, but I don't know where

[09:29:12.0000] <annevk>
jgraham: yeah, I think I might have to

[09:29:31.0000] <annevk>
Ms2ger: yeah, flying there tonight

[09:29:52.0000] <annevk>
Ms2ger: gonna try do some climbing during the day tomorrow, before the reception

[09:44:08.0000] <GPHemsley>
Anyone gonna be in Toronto?

[09:46:36.0000] <Ms2ger>
Presumably some people will be

[09:47:58.0000] <smaug____>
MikeSmith: don't tell me you broke Java->C++ conversion :)

[09:51:49.0000] <MikeSmith>
smaug____: heh :-) no, not me

[09:52:44.0000] <MikeSmith>
and if it's broke I think it's probably been broke for a long time it's just that nobody's tried it for a long time before you

[09:52:52.0000] <smaug____>
I'm trying to do some optimizations, and this java->c++ makes things a bit hard

[09:53:15.0000] <MikeSmith>
I can imagine

[10:00:23.0000] <MikeSmith>
Ms2ger, smaug____ : you know if there's a component for asm.js, or whatever place I shuold report a build failure for AsmJSModule.cpp ?

[10:00:52.0000] <Ms2ger>
MikeSmith, Core::JavaScript Engine

[10:01:04.0000] <MikeSmith>
thanks

[10:01:27.0000] <smaug____>
yeah, js stuff

[10:07:54.0000] <GPHemsley>
Ms2ger: I was wondering who was gonna say that. I should've known it'd've been you.

[11:14:10.0000] <gsnedders>
jgraham: If you do TestTWF-London early next year, avoid it being the end of March? :P

[11:20:03.0000] <Ms2ger>
GPHemsley, :)

[11:30:41.0000] <annevk>
Hixie_: "Thijs van der Vossen" provided that multiline placeholder use case, might want to acknowledge that

[12:49:43.0000] <Hixie_>
annevk: thanks!

[12:59:09.0000] <Hixie_>
who cares about form controls?

[13:00:06.0000] <Ms2ger>
Nobody!

[13:07:53.0000] <Hixie_>
https://www.webkit.org/team.html is sad

[13:09:03.0000] <Ms2ger>
Ha

[13:17:35.0000] <hober>
Hixie_: ?

[13:18:10.0000] <Ms2ger>
hober, its have you looked?

[13:18:23.0000] <Ms2ger>
Oh hey

[13:18:23.0000] <hober>
yes

[13:18:32.0000] <Ms2ger>
It's empty here

[13:18:57.0000] <Ms2ger>
[22:18:01.395] Blocked loading mixed active content "http://svn.webkit.org/repository/webkit/trunk/Tools/Scripts/webkitpy/common/config/contributors.json" @ https://www.webkit.org/team.html:267

[13:19:08.0000] <Ms2ger>
Yeah, http://www.webkit.org/team.html is fine

[13:19:29.0000] <Ms2ger>
Hixie_, ^

[13:19:34.0000] <hober>
works fine here

[13:19:49.0000] <Ms2ger>
You must use an insecure browser :)

[13:20:04.0000] <hober>
hah

[13:20:15.0000] <Ms2ger>
I'll guess Safari

[14:02:49.0000] <Hixie_>
ooh, works now

[14:02:59.0000] <Hixie_>
hober: either it was fixed or i just had a network issue

[14:03:21.0000] <Ms2ger>
Hixie_, it works without ssl

[14:03:53.0000] <Hixie_>
ohhh, i see

[14:04:05.0000] <Hixie_>
ah, yeah, i followed your link the second time

[14:09:33.0000] <Hixie_>
man, that page is quite out of date

[14:39:41.0000] <Hixie_>
there was some discussion recently about using code point lengths instead of code unit lengths for maxlength=""

[14:39:45.0000] <Hixie_>
anyone know where? i can't fidn it...

[14:40:45.0000] <Hixie_>
oh nm, found it

[14:40:45.0000] <Hixie_>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0322.html

[14:41:48.0000] <Hixie_>
hm, no reply yet

[14:42:55.0000] <Hixie_>
rniwa: ^

[14:43:52.0000] <Hixie_>
(at the bottom)

[14:47:56.0000] <Hixie_>
should <input minlength="100" value="My question is..."> be conforming HTML?

[14:48:17.0000] <Hixie_>
how about <textarea minlength="100">Dear Sir,</textarea> ?

[14:52:17.0000] <rniwa>
Hixie_: ?

[14:52:35.0000] <rniwa>
Hixie_: we have minlength?

[14:52:57.0000] <rniwa>
Hixie_: i'm somewhat confused here.

[14:53:01.0000] <rniwa>
Hixie_: what exactly is your question?

[14:53:18.0000] <Hixie_>
minlength is a new feature being considered. it's unrelated to my pinging of you above, which was about the e-mail cited above.

[14:53:28.0000] <Hixie_>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0322.html

[14:53:42.0000] <Hixie_>
it contains a reply to an e-mail you sent, wanted to make sure you'd seen it since nobody had since replied

[14:54:51.0000] <zewt>
given that maxlength prevents the user from entering text longer than its value, minlength seems weird--would it not let you backspace over text if it would go under? heh

[14:55:04.0000] <Hixie_>
it wouldn't be symmetric in behaviour

[15:10:26.0000] <rniwa>
Hixie_: sorry, I was distracted

[15:11:49.0000] <rniwa>
Hixie_: I don't have a strong opinion about conformance requirement


2013-10-03
[17:32:06.0000] <zewt>
hooray @ people trying to squelch discussions they don't like by pushing them to lists nobody reads

[19:34:01.0000] <MikeSmith>
cabanier: regarding http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0029.html it seems like it might be helpful if you actually responded to some of the specific questions Dominic has asked, and the specific proposals he's made

[19:34:59.0000] <cabanier>
I did't get that reply

[19:41:46.0000] <MikeSmith>
cabanier: what reply? you didn't reply to anything he wrote on his previous message to you in that thread

[19:42:27.0000] <cabanier>
MikeSmith: yes. I didn't get his reply

[19:42:28.0000] <MikeSmith>
" If we added a canvas fallback element as a parameter to scrollPathIntoView,

[19:42:28.0000] <MikeSmith>
I don't think we'd need drawCustomFocusRing."

[19:42:30.0000] <Hixie_>
the bottleneck here is me, anyway, not dominic

[19:42:53.0000] <cabanier>
MikeSmith: sent my reply

[19:43:37.0000] <cabanier>
Hixie_: I think we can all agree it's confusing either way. Dominic's proposal is just more confusing :-(

[19:45:22.0000] <cabanier>
Hixie_: I guess the spec doesn't say that the focus area should scroll into view but isn't that expected behavior?

[19:45:42.0000] <Hixie_>
no, that would be terrible

[19:45:46.0000] <MikeSmith>
Hixie_: from where I sit it seems to me we may have lost sight of the original problem that Rich was claiming needed to be solved, which this never seems to have been anything more than a workaround for to begin with

[19:46:16.0000] <Hixie_>
cabanier: imagine if you focus a control on an animated canvas and then scroll it out of view, it shouldn't keep scrolling back 60 times a second

[19:46:27.0000] <Hixie_>
MikeSmith: i'm not really sure what the original problem was, to be honest

[19:47:06.0000] <cabanier>
Hixie_: that would only happen if you focus to it. Once focused, you don't scroll back

[19:47:18.0000] <cabanier>
Hixie_: that's standard browser behavior

[19:47:44.0000] <Hixie_>
how could drawFocusRing() know if you have just focused it?

[19:47:53.0000] <MikeSmith>
also Dominic has made the point that there's nothing canvas-specific about the problem so there should be nothing canvas-specific about the proper solution

[19:48:20.0000] <cabanier>
Hixie_: the browser knows. by calling drawFocusRing, you associate a region of the canvas with a control

[19:49:03.0000] <Hixie_>
draw focus ring just draws and update the AT data, it doesn't associate regions. are confusing it with the hit region stuff?

[19:49:16.0000] <cabanier>
Hixie_: no

[19:50:11.0000] <cabanier>
Hixie_: by calling the focus ring method, you tell the browser that the underlying element has a certain path

[19:50:19.0000] <MikeSmith>
Hixie_: not you not knowing what the original problem was doesn't argue well for this being kept in the sited, or worse yet, shipped  :-)

[19:50:46.0000] <cabanier>
Hixie_: so the accessibity software can draw boxes around it. You don't have to continually call drawFocusRing to make that happen

[19:50:47.0000] <MikeSmith>
*in the spec

[19:51:02.0000] <Hixie_>
MikeSmith: you any idea how many problems i'm discussing at the same time? ain't no way i can remember this stuff :-)

[19:51:17.0000] <cabanier>
brb

[19:51:48.0000] <Hixie_>
cabanier: you continually call drawFocusRing to... draw the focus ring

[19:51:55.0000] <Hixie_>
cabanier: each frame of the animation

[19:53:22.0000] <MikeSmith>
Hixie_: not blaming you. just saying this has been kind of a mess from the beginning. but it's one thing to be talking about a mess, and another thing to actually be implementing it and shipping it

[19:53:43.0000] <Hixie_>
i don't really understand what the mess is here

[19:53:49.0000] <Hixie_>
this API seems to basically work fine

[19:54:02.0000] <Hixie_>
it's not pretty, but nobody has suggested anything prettier, so...

[19:54:43.0000] <MikeSmith>
Dominic has suggested just dropping it

[19:54:53.0000] <Hixie_>
that's not prettier

[19:54:56.0000] <Hixie_>
that's even worse

[19:55:09.0000] <Hixie_>
"sorry people with disabilities, guess you can't see what's focused"

[19:56:15.0000] <MikeSmith>
that's already the case with non-canvas content

[19:56:54.0000] <Hixie_>
how so?

[19:57:01.0000] <Hixie_>
non-canvas content is handled by the UA

[19:57:08.0000] <MikeSmith>
and clearly you're not describing Dominic's sentiment

[19:58:33.0000] <MikeSmith>
when I'm back at my PC I'll pull up copies of Dominic's message s in that thread

[19:59:11.0000] <Hixie_>
k...

[19:59:14.0000] <MikeSmith>
as far as the real problem not being specific to canvas

[19:59:52.0000] <cabanier>
Hixie_: back

[20:00:21.0000] <Hixie_>
MikeSmith: do you mean http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0268.html ?

[20:00:26.0000] <cabanier>
Hixie_: yes. the author draws the ring

[20:02:10.0000] <cabanier>
Hixie_: but also tell the UA where the bounds of the element are

[20:02:26.0000] <cabanier>
Hixie_: this allows the UA to scroll to that area of the canvas

[20:02:28.0000] <Hixie_>
cabanier: my point is just that you can't scroll 60 times a second.

[20:02:29.0000] <MikeSmith>
Hixie_: yeah, exactly that one. that message from Dominic

[20:02:50.0000] <cabanier>
Hixie_: and the a11y software to show where the area of the fallback content is

[20:03:24.0000] <Hixie_>
MikeSmith: i haven't yet replied to that one (as noted earlier, i'm the bottleneck here) but he's wrong that there's no settings to cause the default rendered focus ring to be different.

[20:03:35.0000] <Hixie_>
MikeSmith: e.g. on mac you can change its color, on windows you can change its width, etc.

[20:03:38.0000] <cabanier>
Hixie_: well, what happens if you have a focused HTML element and you animate it offscreen?

[20:03:46.0000] <Hixie_>
cabanier: what does that mean?

[20:03:51.0000] <MikeSmith>
ok

[20:06:08.0000] <cabanier>
Hixie_:  does the browser scroll to a focused element if you move it offscreen?

[20:06:22.0000] <cabanier>
Hixie_: I haven't tried it but likely not

[20:07:10.0000] <cabanier>
Hixie_: so, the browser won't scroll either to update the focus ring. it should be the same behavior

[20:08:09.0000] <Hixie_>
the reason it doesn't scroll when you animate a focused element off screen is that the browser is not scrolling to it when it draws the focus ring

[20:08:17.0000] <Hixie_>
just like drawFocusRing() doesn't scroll to it when you draw the focus ring

[20:08:29.0000] <cabanier>
Hixie_:  it does :-)

[20:08:56.0000] <cabanier>
Hixie_: well, it *should*

[20:09:07.0000] <Hixie_>
gotta go, bbiab

[20:09:26.0000] <cabanier>
Hixie_: I think that's what Dominic is saying too except he just wants the scrolling

[20:09:30.0000] <cabanier>
k

[20:11:32.0000] <cabanier>
Hixie_: ah. Dominic's code doesn't scroll!

[20:11:51.0000] <cabanier>
Hixie_: ok. we need to add that to the spec

[20:31:30.0000] <DiegoViane>
Zzz

[20:54:02.0000] <Hixie_>
cabanier: it makes no sense for _painting_ code which is called 60 times a second to scroll.

[20:54:21.0000] <cabanier>
Hixie_: no

[20:54:29.0000] <cabanier>
Hixie_: you only scroll if you're offscreen

[20:54:39.0000] <Hixie_>
cabanier: it makes no sense for _painting_ code which is called 60 times a second to scroll, whether or not you're off-screen

[20:54:44.0000] <cabanier>
Hixie_: once onscreen, you never scroll again

[20:54:53.0000] <Hixie_>
so the user scrolls it off screen and you scroll again?

[20:54:57.0000] <Hixie_>
that makes no sense

[20:55:02.0000] <Hixie_>
painting code shouldn't scroll

[20:55:13.0000] <cabanier>
Hixie_: only if you tab again

[20:55:35.0000] <Hixie_>
the method is called every 16ms, it doesn't know if the element was focused already or not

[20:55:53.0000] <Hixie_>
i just don't understand why this would even be something we'd consider

[20:56:15.0000] <Hixie_>
scrolling happens, if it happens, when the user focuses the control; there's other APIs for that

[20:56:16.0000] <cabanier>
the method doesn't know, but the browser does

[20:56:29.0000] <cabanier>
what API?

[20:56:30.0000] <Hixie_>
...the method is the browser.

[20:56:37.0000] <Hixie_>
scrollPathIntoView(), for instance

[20:57:02.0000] <cabanier>
there's no API when you tab into a control. the browser scrolls to it automatically

[20:57:03.0000] <Hixie_>
or just scrollIntoView(), depending on what needs to be scrolled

[20:57:26.0000] <Hixie_>
sure, just like there's no non-canvas API when you tab into a control to draw the control's focus ring.

[20:57:39.0000] <Hixie_>
if you're creating a control in canvas, you have to implement the control

[20:57:44.0000] <cabanier>
sure

[20:58:19.0000] <cabanier>
but drawfocusring lets you associate a path with a focused control

[20:58:29.0000] <cabanier>
so you should scroll towards that path

[20:58:40.0000] <cabanier>
otherwise the API is not good

[20:58:59.0000] <Hixie_>
drawFocusRing doesn't associate a path with a focused control. it just draws the focus ring and possibly adjusts AT parameters.

[20:59:40.0000] <cabanier>
but should a focus ring be scrolled so it's visible?

[20:59:55.0000] <cabanier>
it should follow the same convention as regular focus rings

[21:00:04.0000] <Hixie_>
depends on what the author wants. if the author wants that, then that's what the scroll*() APIs are for

[21:00:45.0000] <cabanier>
why would you ever not want that?

[21:01:52.0000] <cabanier>
if an element becomes focused, it should always be scrolled into view

[21:02:13.0000] <cabanier>
while focused, it's ok to scroll out of view

[21:03:27.0000] <cabanier>
too bad Rich is on vacation

[21:06:40.0000] <Hixie_>
suppose the user presses some hot key that brings in a control, sliding it in from the top of page. it needs the focus ring drawn on the whole time, but you only want to scroll the viewport to the final location.

[21:07:44.0000] <cabanier>
yes

[21:07:50.0000] <cabanier>
that would be problematic

[21:08:06.0000] <cabanier>
it would only scroll to where it comes in today

[21:08:30.0000] <cabanier>
doesn't that happen in HTML too?

[21:08:41.0000] <cabanier>
(I've never tried that)

[21:15:32.0000] <cabanier>
Hixie_: I just tried it. the HTML control disappears

[21:16:45.0000] <cabanier>
com'on jsfiddle

[21:18:35.0000] <cabanier>
http://codepen.io/anon/pen/ckshA

[21:19:12.0000] <cabanier>
tab to the controls. the second control will fly offscreen when focused

[21:19:31.0000] <cabanier>
if you turn off the transition, the browser will scroll

[22:12:23.0000] <zcorpan>
Hixie_: re parameter to scrollPathIntoView, note that scrollIntoView et al now has a parameter to hint about smooth scrolling

[22:31:28.0000] <zewt>
heh, i recall having major migraine-level headaches trying to deal with old android browser's scrollTo doing async smooth scrolling instead of immediate scrolling

[01:20:38.0000] <MikeSmith>
zcorpan: btw thanks for the review of the conformance-checker tests

[01:21:32.0000] <zcorpan>
np

[01:21:53.0000] <zcorpan>
ping me when you have more

[01:21:59.0000] <MikeSmith>
will do

[01:22:45.0000] <MikeSmith>
in the mean time as far a validator stuff I'm planning to add a build option for running the validator with the parser in non-streaming mode

[01:23:07.0000] <zcorpan>
why?

[01:23:57.0000] <MikeSmith>
for people who want to run a service that can process docs with non-streaming error recovery

[01:24:22.0000] <MikeSmith>
so that it doesn't stop with "Can't recover from last error" messages

[01:24:27.0000] <MikeSmith>
bad idea?

[01:24:37.0000] <zcorpan>
have people asked for that?

[01:25:00.0000] <MikeSmith>
http://lists.w3.org/Archives/Public/www-validator/2013Sep/0041.html

[01:25:25.0000] <MikeSmith>
"I have to pay extra money for each of these rechecks. As an end user, what I expect is being reported for all errors found at the document, and if I have to pay several times to get a full validation report of my document, I find that unfair."

[01:26:23.0000] <zcorpan>
v.nu also skips subtrees of misplaced elements

[01:26:50.0000] <MikeSmith>
you mean v.nu as compared to the W3C service?

[01:27:01.0000] <Ms2ger>
People pay to validate their stuff?

[01:27:07.0000] <MikeSmith>
heh

[01:27:12.0000] <MikeSmith>
Ms2ger: some people

[01:27:18.0000] <zcorpan>
no, both

[01:27:26.0000] <Ms2ger>
Fascinating

[01:28:24.0000] <Ms2ger>
On another note, I'll be intermittently available from this afternoon, like the rest of Mozilla

[01:28:25.0000] <MikeSmith>
zcorpan: that's the same case, right? it wouldn't skip them in non-streaming mode

[01:28:40.0000] <zcorpan>
MikeSmith: no

[01:28:46.0000] <zcorpan>
hold on

[01:29:10.0000] <MikeSmith>
Ms2ger: please do some magic in your remaining time today to up-priortize the build bug I reported

[01:29:51.0000] <zcorpan>
MikeSmith: consider <div><li><span invalid=""></span></li></div>

[01:29:57.0000] <Ms2ger>
MikeSmith, number?

[01:30:00.0000] <MikeSmith>
/me nods

[01:30:06.0000] <zcorpan>
Error: Element li not allowed as child of element div in this context. (Suppressing further errors from this subtree.)

[01:30:13.0000] <MikeSmith>
Ms2ger: hang on will get it

[01:30:31.0000] <Ms2ger>
MikeSmith, have you tried turning it off and on again? ;)

[01:30:45.0000] <MikeSmith>
Ms2ger: 923196

[01:31:20.0000] <MikeSmith>
Ms2ger: tried kicking it

[01:31:35.0000] <MikeSmith>
zcorpan: lemme try that right now in non-streaming mode

[01:31:54.0000] <zcorpan>
MikeSmith: i think it has nothing to do with streaming :-)

[01:32:25.0000] <zcorpan>
MikeSmith: hsivonen implemented the suppressing to make the validator more useful

[01:33:12.0000] <zcorpan>
because it's useless to give lots of errors of a subtree that might go away when the author fixes the first error

[01:33:32.0000] <MikeSmith>
ok

[01:33:57.0000] <MikeSmith>
yeah, same error in non-streaming mode

[01:34:11.0000] <MikeSmith>
and yeah I see your point

[01:34:23.0000] <zcorpan>
maybe people expect the validator to whine about the invalid="" attribute there, though, i dunno

[01:35:40.0000] <zcorpan>
i guess the guy who pays per validation wants as many errors as possible

[01:35:57.0000] <MikeSmith>
heh

[01:36:12.0000] <MikeSmith>
yeah, though it sounds funny to put it that way

[01:36:48.0000] <MikeSmith>
anyway I was not planning to spend a bunch of time on it

[01:37:30.0000] <MikeSmith>
implementing the switch to provide a non-streaming mode would probably take me 30 minutes

[01:38:38.0000] <zcorpan>
maybe you could suggest a different payment strategy, so instead of number of validations, you pay for actual processing time in the validator.

[01:39:02.0000] <MikeSmith>
interesting

[01:39:09.0000] <MikeSmith>
yeah that would make a lot more sense

[01:40:12.0000] <MikeSmith>
a person whose page has 900 errors on it will take more time to process than a person whose page has one or none

[01:40:33.0000] <MikeSmith>
and more machine resources

[01:42:02.0000] <zcorpan>
isn't it more about the size of the page? the same checks need to be made whether it gives an error or not

[01:42:43.0000] <MikeSmith>
not for the case of microsyntax checking

[01:42:51.0000] <MikeSmith>
and probably other cases too

[01:43:03.0000] <MikeSmith>
but yeah I guess it's much more about the size of the page

[01:43:07.0000] <MikeSmith>
in general

[01:43:20.0000] <MikeSmith>
ah I see what you're saying

[01:43:27.0000] <MikeSmith>
yeah even for microsyntax checking

[01:54:50.0000] <zcorpan>
MikeSmith: this is interesting: "The W3C errors jumped to 45 errors so I undo that action." http://wordpress.org/support/topic/w3c-validation-stray-end-tag-div-errors

[01:55:20.0000] <zcorpan>
MikeSmith: one fatal error is considered less bad than 45 non-fatal errors

[01:55:25.0000] <MikeSmith>
/me looks

[01:56:05.0000] <MikeSmith>
heh

[01:56:06.0000] <MikeSmith>
wow

[01:58:41.0000] <MikeSmith>
I can seriously imagine paying customers complaining about that actually

[01:59:32.0000] <MikeSmith>
"I paid you last month for validation of my page and it said I had only one error. This month I validate the same page and it says I have 45 errors!!"

[01:59:37.0000] <MikeSmith>
regression

[02:00:10.0000] <zcorpan>
so i guess that's a bad property of suppressing errors in general, it's moving the perceived goalposts which is probably very depressing

[02:00:19.0000] <MikeSmith>
very glad I'm not involved at all with trying to monetize validation

[02:00:27.0000] <MikeSmith>
zcorpan: yeah

[02:00:55.0000] <MikeSmith>
the bottom line is that many people are validating their pages for the wrong reasons to begin with

[02:01:42.0000] <zcorpan>
like "one error? sure lemme fix it. 45 errors!? GTFO if i fix one more will it be 900 errors?" :-)

[02:03:17.0000] <MikeSmith>
haha

[02:03:21.0000] <MikeSmith>
yeah, like that

[02:06:01.0000] <zcorpan>
i recall hsivonen talking about a parsing mode that is streaming but doesn't do the spec's recovery for non-streamable errors (a few years ago)

[02:07:34.0000] <MikeSmith>
huh? that sounds

[02:07:52.0000] <MikeSmith>
...just like the existing default behavior

[02:08:37.0000] <MikeSmith>
well not default in the parser, but default in the v.nu code

[02:08:40.0000] <zcorpan>
i mean doing different recovery than the spec. so e.g. <body><html class=foo> would not set the class attribute on the root element, </body> </html>x would drop the space and insert the x in body

[02:08:50.0000] <MikeSmith>
ah

[02:10:40.0000] <zcorpan>
it would not validate the attributes on the <html>, but it would be streaming and non-fatal

[02:11:28.0000] <MikeSmith>
yeah

[02:11:38.0000] <MikeSmith>
I don't remember that

[02:11:55.0000] <MikeSmith>
was it just a thought experiment or had he implemented something?

[02:12:58.0000] <zcorpan>
it was probably around the time the spec's parser was first specified

[02:13:24.0000] <zcorpan>
or i might be making it up

[02:23:23.0000] <zcorpan>
MikeSmith: there's also the opposite problem: a typoed formatting end tag can cause lots of errors because it gets reopened everywhere

[02:24:04.0000] <zcorpan>
that's also something that non-spec recovery could fix (never reopen formatting elements)

[02:29:31.0000] <MikeSmith>
zcorpan: yeah

[02:34:19.0000] <MikeSmith>
I think there are a number of cases where having non-spec handling would give more intuitive errors on the validator

[02:41:31.0000] <zcorpan>
<p><ul></ul></p> could have a better message too, e.g. by keeping track of whether the last <p> was implicitly closed and by what

[02:56:09.0000] <MikeSmith>
zcorpan: yeah

[03:00:52.0000] <MikeSmith>
that one seems tough if we also want to do the same for similar elements that can implicitly be closed

[03:01:35.0000] <MikeSmith>
potentially have to keep a lot of information around in the parser

[03:40:34.0000] <zcorpan>
there's a small set of elements that can be implicitly closed, and you only need one flag per element type

[03:41:01.0000] <zcorpan>
well, and a position for the last token that closed it

[03:41:15.0000] <zcorpan>
but still, not a lot of information

[03:42:55.0000] <zcorpan>
maybe you need to keep track of the <p>'s parent too so you can reset the flag when the parent is closed

[04:48:19.0000] <MikeSmith>
zcorpan: yeah

[04:53:52.0000] <MikeSmith>
zcorpan: btw about the "Suppressing further errors from this subtree." case that behavior's basically hard-coded into our branch of jing so I couldn't easily provide an option for overriding it even if I wanted to

[04:54:40.0000] <zcorpan>
why would you provide an option?

[04:56:31.0000] <MikeSmith>
I dunno, because that'd be the next thing that somebody would ask for after the recover-from-non-streaming-error option

[04:57:54.0000] <gsnedders>
zcorpan: Also consider the case where one mis-closed element causes a ton of parse errors because the stack of open elements isn't what is intended.

[04:58:04.0000] <zcorpan>
i wouldn't provide any options for either of those :-)

[04:58:49.0000] <gsnedders>
idk! I'm just trying to be useful!

[04:58:52.0000] <gsnedders>
/me curls up and cries

[04:59:56.0000] <zcorpan>
gsnedders: ? i was replying to MikeSmith

[05:00:24.0000] <zcorpan>
gsnedders: what case do you mean?

[05:00:58.0000] <gsnedders>
Oh, don't mind me. I'm not that deeply thinking about this. I could be totally wrong.

[05:04:56.0000] <MikeSmith>
/me curls up and cries while puffing on a blunt

[06:54:09.0000] <zcorpan>
MikeSmith: i've written some notes on how the parser could be modified to be streaming with different recovery

[06:54:33.0000] <zcorpan>
http://bugzilla.validator.nu/ says Gateway Time-out for me

[07:30:19.0000] <zcorpan>
http://lists.w3.org/Archives/Public/www-archive/2013Oct/0009.html

[09:56:49.0000] <dglazkov>
good morning, Whatwg!

[10:05:56.0000] <Roujo>
dglazkov: 'morning ^^

[11:41:34.0000] <Domenic_>
Hixie_: was there ever consideration for a way of linking buttons and dialogs? e.g. https://gist.github.com/rpflorence/6814517

[11:46:57.0000] <Hixie_>
not only was there consideration, it's in the spec.

[11:48:48.0000] <Domenic_>
lollll

[11:50:00.0000] <Domenic_>
can't find it in http://developers.whatwg.org/commands.html#the-dialog-element, hmm

[11:50:38.0000] <Hixie_>
looks like there's no example of it in the spec

[11:50:49.0000] <Hixie_>
<dialog> <form method=dialog> <input type=submit> </form> </dialog>

[11:51:04.0000] <Domenic_>
huh...

[11:52:03.0000] <Domenic_>
what about opening the dialog

[11:52:19.0000] <Domenic_>
oh nice dialog affects autofocus, that is awesome!

[12:00:05.0000] <Hixie_>
not sure what you're looking for when opening the dialog

[12:05:16.0000] <TabAtkins>
Click a button -> dialog opens, presumably.

[12:05:29.0000] <TabAtkins>
Like <details>, but with a popup.

[12:05:45.0000] <TabAtkins>
Actually, though, that's basically just <details>.  Style it when [open] to look like a popup.

[12:06:31.0000] <ryanflorence>
so why have both?

[12:08:20.0000] <TabAtkins>
ryanflorence: I was just now exploring my thoughts, not trying to justify anything.  It may be that <details> is enough for this case.

[12:09:02.0000] <Domenic_>
Feels related to contextmenu attribute on buttons.

[12:09:32.0000] <ryanflorence>
I missed the beginning of the conversation in here but I started it on twitter, is the feeling we don't need a declarative dialog?

[12:10:41.0000] <TabAtkins>
Nonono, unrelated.

[12:14:01.0000] <Domenic_>
Using details for this is no good

[12:14:12.0000] <Domenic_>
Or rather, very weird.

[12:15:14.0000] <Domenic_>
Augh I should not try to engage in discussions from iPad keyboard. Shutting up now until my laptop recharges.

[12:16:23.0000] <ryanflorence>
your command of capital letters on the ipad though is impressive

[12:38:45.0000] <rektide>
this is insane. the discrepancy between CSSStyleSheet and HTMLStyleSheet make up a vast flabbergasting chasm of WTF. https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleSheet.insertRule?redirectlocale=en-US&redirectslug=Web%2FAPI%2FCSSStyleSheet%2FinsertRule#Example_2

[12:39:14.0000] <rektide>
it is way way too hard to get to doing absolutely trivial things like adding a single rule to a document

[12:39:56.0000] <rektide>
in that it's extremely likely one will run face first into 12 different ways where you cannot quite get there from here- but nice try, that was close

[12:39:59.0000] <rektide>
awful

[12:40:07.0000] <rektide>
thanks #whatwg emotional support group

[12:40:35.0000] <TabAtkins>
There's no such thing as HTMLStyleSheet.  There's an HTMLStyleElement, which is a completely different thing from a stylesheet.  It *contains* a stylesheet.

[12:41:00.0000] <rektide>
ah but taht style sheet isn't read only, the property of the HTMLStyleElement is read only

[12:41:09.0000] <rektide>
ok that's not entirely useless then. my mistake on the name.

[12:41:27.0000] <TabAtkins>
The stylesheet on <style> is readonly?

[12:41:41.0000] <rektide>
yes, .style is read only according to mdn

[12:41:54.0000] <rektide>
errr i probably don't have that property name right do i.. one moment

[12:42:10.0000] <Jasper>
Hixie_, while we're working on Path for Canvas2D, can I recommend a way to get the current working path and clip path?

[12:42:14.0000] <Jasper>
Hixie_, if only for debugging

[12:42:24.0000] <rektide>
.sheet

[12:42:42.0000] <rektide>
i don't understand why the MDN code is ok

[12:43:00.0000] <zcorpan>
rektide: the .sheet attribute is readonly, but that just means you can't assign to it. the stylesheet is mutable

[12:43:18.0000] <rektide>
they appendChild onto the head element, and then look for the last style element. but wouldn't that appended child show up somewhere in the page?

[12:43:30.0000] <rektide>
with any style elements in the body following after it

[12:43:47.0000] <TabAtkins>
rektide: Yeah, a readonlya ttribute just means that the object itself can't be replaced.

[12:43:49.0000] <rektide>
zcorpan: right, somehow TabAtkins quick line made that click, and you said what i just said now

[12:43:53.0000] <TabAtkins>
It doesn't mean the object there is readonly.

[12:43:55.0000] <rektide>
ayup ayup

[12:44:38.0000] <TabAtkins>
Also, that example 2 is really terrible code.

[12:44:47.0000] <jgraham>
It is not like "mut" in Rust

[12:44:51.0000] <rektide>
i don't see alternatives!

[12:44:55.0000] <TabAtkins>
Seriously, detecting Safari for a bugfix by checking for window.createPopup?

[12:44:55.0000] <jgraham>
</unhelpful-comparison>

[12:44:57.0000] <rektide>
this is just ugly ugly stuff to do

[12:45:05.0000] <rektide>
line 27 though in particular

[12:45:10.0000] <rektide>
i think isn't ugly enough to actuall ywork

[12:45:31.0000] <rektide>
because the body hight have it's own style elements

[12:45:33.0000] <TabAtkins>
Why does line 27 exist?  You can do "style.sheet" instead.

[12:45:38.0000] <TabAtkins>
And yes, it's incorrect for that reason.

[12:45:52.0000] <rektide>
oh yay

[12:46:04.0000] <rektide>
i'll kill this for loop i added to their codebase

[12:46:22.0000] <TabAtkins>
It looks like most of the complication in this code is due to unnecessary workarounds caused by misunderstanding.

[12:46:23.0000] <rektide>
thank you TabAtkins &all

[12:48:16.0000] <rektide>
oh flip me, why is there no insertRule function on the style sheet

[12:48:23.0000] <TabAtkins>
There... is.

[12:48:42.0000] <TabAtkins>
styleEl.sheet.insertRule exists.

[12:50:01.0000] <TabAtkins>
Also, note that objects are iterated in insertion order.  That's specified, and I *think* browsers implement that.

[12:50:04.0000] <rektide>
once appended to the document

[12:50:11.0000] <rektide>
in Chrome-unstable

[12:50:29.0000] <rektide>
ahh interesting

[12:50:38.0000] <TabAtkins>
Well yeah. Before it's in the document, it doesn't have a stylesheet at all.

[12:51:00.0000] <TabAtkins>
It's not that the stylesheet lacks an insertRule function, it's the "el.sheet" returns null before el is inserted into the document.

[12:51:39.0000] <TabAtkins>
rektide: Is this your code in the wiki?  Or just code that you're trying to follow/maintain?

[12:55:03.0000] <Hixie_>
Jasper: you mean the one on the context?

[12:55:12.0000] <Hixie_>
Jasper: i looked into doing that, i don't recall why i didn't do it...

[12:55:19.0000] <Hixie_>
Jasper: what do you want to do with it exactly?

[12:55:26.0000] <Jasper>
Hixie_, just debug

[12:55:36.0000] <Hixie_>
how?

[12:55:51.0000] <Jasper>
Hixie_, visualize what my current clip state is, or dump what the current path is

[12:55:51.0000] <rektide>
these insertRules are firing now but not doing anything

[12:55:55.0000] <rektide>
TabAtkins: https://github.com/rektide/greyelershian/blob/master/greyelershian.user.js#L44

[12:56:07.0000] <Jasper>
Hixie_, perhaps I'd take the clip path and draw it to a separate canvas overlaid on top in transparent red

[12:56:25.0000] <Jasper>
Hixie_, so, have you seen the absolutely crazy thing I'm building?

[12:56:27.0000] <rektide>
it's a userscript to make Google notices appear in grey, not red.

[12:57:27.0000] <Hixie_>
Jasper: to visualise your lip state, just draw a huge rectangle.

[12:57:37.0000] <Hixie_>
clip, not lip.

[12:57:52.0000] <Hixie_>
Jasper: i have not

[12:58:12.0000] <Jasper>
Hixie_, the URL will probably scar you for life

[12:58:15.0000] <Jasper>
Hixie_, http://magcius.github.io/xserver.js/demo/

[12:59:07.0000] <rektide>
missing semicolon spotted. merciful merciful wetware errors.

[12:59:29.0000] <rektide>
wait no. .gb_jb { background-color: rgb(102, 102, 102); transition: background-color 1.2s } , what is wrong with you

[12:59:47.0000] <rektide>
oh spaces that's it isnt it

[13:00:59.0000] <Jasper>
Hixie_, I'm redoing X drawing semantics in canvas so that every window draws to the same front buffer, but clipped to their visible area.

[13:01:13.0000] <Hixie_>
Jasper: i wish i could tell you i'd never seen someone do this before

[13:01:13.0000] <rektide>
there's still no change to this style sheet after i insertRule. and nothing is being thrown.

[13:01:24.0000] <Hixie_>
Jasper: (not necessarily exactly the same, but same idea)

[13:01:53.0000] <Jasper>
Hixie_, this isn't just the "fake OS" thing with DOM or something. This accurately implements a front-buffer and how windows draw to it.

[13:02:08.0000] <Hixie_>
Jasper: fair enough

[13:02:45.0000] <Jasper>
Hixie_, so yeah, sometimes I'm clipped five levels deep and I can't really just draw a rectangle to see my current clip because another client might overwrite it.

[13:04:42.0000] <Jasper>
It's quite fun to write, too: https://github.com/magcius/xserver.js/blob/gh-pages/src/clients/xeyes.js

[13:04:43.0000] <Hixie_>
draw a rectangle, then call window.alert()

[13:04:54.0000] <Hixie_>
or debugger;

[13:05:07.0000] <Jasper>
Hixie_, I suppose that's an idea...

[13:06:43.0000] <rektide>
insertRule is not doing anything.... aaagggggggggg

[13:06:59.0000] <TabAtkins>
rektide: It works fine over here, so I have no idea what the problem is that you're seeing.

[13:10:04.0000] <rektide>
ah. so the style sheet updates when you insertRule but the HTMLStyleElement doesnt reflect that change

[13:10:12.0000] <rektide>
one bad assumption on my part

[13:10:27.0000] <TabAtkins>
Yeah, the text contents dont' change.

[13:10:28.0000] <rektide>
the rules exist, their priority is just being smashed by someone else i'm guessing

[13:10:39.0000] <TabAtkins>
Throw an !important on those things.

[13:16:53.0000] <rektide>
can i run queryselectors on computed styles?

[13:17:07.0000] <rektide>
or is querySelector truly only for actual attributes?

[13:17:22.0000] <TabAtkins>
I'm not sure what you mean.  querySelector selects elements in the tree that match a given selector.

[13:17:48.0000] <rektide>
[id="foo"] is an attribute selector for things id'ed as foo

[13:18:14.0000] <TabAtkins>
If you can do it in a selector in a stylesheet, you can do it in querySelector().  Nothing more, nothing less.

[13:18:49.0000] <rektide>
i figured the answer was no

[13:19:09.0000] <rektide>
my ask though, since it's still hazy

[13:19:36.0000] <TabAtkins>
I still don't know what you were actually asking about, so shrug.

[13:20:10.0000] <rektide>
was to be able to find all elements that have a style, whether it's directly on the element or whether the element only has that property because it has been cascaded onto it

[13:20:22.0000] <rektide>
i'm looking for red things

[13:20:22.0000] <TabAtkins>
You can't do that with a selector.

[13:20:30.0000] <rektide>
nope you cannot i concur

[13:21:23.0000] <rektide>
and alas there's nothing fixed i'm going to be able to select on the google homepage. the classes changed since yesterday.

[13:21:28.0000] <TabAtkins>
Note, for your use-case, that the classes used by Google stuff changes over time, as they're generated by a CSS compiler and have no guarantee of stability.

[13:21:46.0000] <rektide>
hence my ask for a search function to not have have to get all elements and loop through them myself

[13:22:06.0000] <rektide>
"find red" would've been handy here

[13:22:32.0000] <rektide>
i suppose i could search the style sheet for red to select the selector repsonsible

[13:22:35.0000] <rektide>
fine

[13:22:36.0000] <rektide>
this isn't ugly

[13:22:38.0000] <rektide>
twist my arm

[13:22:54.0000] <rektide>
stupid well indexed systems, showing me off

[13:23:07.0000] <TabAtkins>
Heh.

[13:23:22.0000] <TabAtkins>
But seriously, that mdn code needs to be thrown out.  It's terrible.

[13:23:51.0000] <rektide>
it brought me much closer to the end of my rope on this one

[13:24:31.0000] <rektide>
i'm glad you've identified the 'by order inserted' potential though, that makes me happier that it's probably not flagrantly outright wrong

[13:59:00.0000] <rektide>
"Object #<StyleSheetList> has no method 'find'"

[14:00:23.0000] <rektide>
is parity between Array and DOM list'y stuff an objective, or will we not see a .find, .some, &c ?

[14:15:39.0000] <TabAtkins>
rektide: Everything that looks kinda like an Array but isn't, is a terrible mistake and we're trying to fix them.

[14:16:12.0000] <rektide>
TabAtkins: godspeed sovereign warriors. thanks for the work, thanks for the reply.

[14:16:50.0000] <rektide>
glad to hear there's some concordance that the state now ought not be the way of it

[14:17:40.0000] <TabAtkins>
rektide: I've also revised the MDN function to make it less terrible.  It's possible that it's now less portable to old browsers, but that can be fixed by someone else I guess.

[15:14:51.0000] <dev11>
why when embeding video from youtube I see small black border below the video inside the iframe?

[15:17:34.0000] <rektide>
are there any structured representations of a CSS color?

[15:18:39.0000] <rektide>
i need to convert an rgb(r,g,b) into an rgb(r,g,b,a) property. i can do it manually sure but if there's something in the DOM that actually has a structure for what colors are I'd prefer to use that

[15:20:44.0000] <rektide>
i guess the latter is rgba(r,g,b,a)

[15:31:39.0000] <rniwa>
Hixie_: yt?

[15:39:05.0000] <Hixie_>
yo

[15:39:21.0000] <Hixie_>
(i pumpkinise in 20 minutes)

[16:39:01.0000] <TabAtkins>
rektide: No, CSS always returns colors as a string that you have to parse.  Browsers do this in different manners, unfortunately.

[16:39:18.0000] <TabAtkins>
rektide: We've been planning for a while to provide a more structured version of this shit.


2013-10-04
[17:34:38.0000] <rektide>
amusingly Chrome appears to report rgb(r, g, b) programmatically but the debugger gives a bunch of #rrggbb results

[17:36:03.0000] <rektide>
i'm not at all confident on the heuristics of what's up but different stuff, same browser: check

[18:17:32.0000] <wowaname>
ohai

[19:36:21.0000] <MikeSmith>
what are "forgeable" and "unforgeable" in the context of JavaScript?

[19:36:32.0000] <MikeSmith>
or is that some WebIDL thing?

[20:17:53.0000] <Domenic_>
MikeSmith: from what i understsand it has something to do with configurable, but also something else?

[20:27:33.0000] <MikeSmith>
Domenic_: that sounds likely

[20:28:27.0000] <MikeSmith>
because somebody who was asking me about forgeable and unforgeable also mentioned configurable

[22:46:42.0000] <paul_irish>
Domenic_: your LXJS talk is fantastic. :D

[23:01:15.0000] <MikeSmith>
paul_irish: is it online?

[23:01:34.0000] <MikeSmith>
or I guess you probably mean you're there at the event

[23:01:49.0000] <paul_irish>
http://www.youtube.com/watch?v=hneN6aW-d9w  "how to win friends and influence standards bodies"

[23:02:15.0000] <paul_irish>
the event was last week but the videos are already out. so good.

[23:03:48.0000] <MikeSmith>
great

[00:55:38.0000] <annevk>
zcorpan: https://bugzilla.mozilla.org/show_bug.cgi?id=850684

[00:56:35.0000] <zcorpan>
rektide: if cssom's api makes you jump through hoops, send an email or file a bug describing what you're trying to do (i.e. your use case, don't describe a proposed solution, at least not at first)

[00:57:23.0000] <zcorpan>
annevk: thanks

[01:02:27.0000] <rektide>
zcorpan: alas it all makes sense now

[01:09:32.0000] <zcorpan>
rektide: ok, good :-)

[01:24:02.0000] <MikeSmith>
TIL about [Unforgeable] http://dev.w3.org/2006/webapi/WebIDL/#Unforgeable

[01:24:27.0000] <MikeSmith>
Domenic_: ↑

[01:25:46.0000] <zcorpan>
heh, funny how my brain fills in words that my eyes apparently skip over while reading. i read "Let me try it blink before ..." as "Let me try to blink before ..."

[01:26:41.0000] <zcorpan>
of course it should have been "try it *in* blink", which my brain would probably fill in correctly

[01:27:35.0000] <MikeSmith>
so [Unforgeable] just maps to configurable=false?

[01:28:41.0000] <zcorpan>
not just, it also make the property on the instance instead of on the prototype

[01:28:58.0000] <MikeSmith>
ah

[01:28:59.0000] <MikeSmith>
OK

[01:37:05.0000] <zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2551 (looks like gecko doesn't follow the html spec there)

[01:38:52.0000] <annevk>
I don't understand http://blog.chromium.org/2013/10/chrome-31-beta-android-application.html given the exchange on blink-dev regarding requestAutocomplete()

[01:39:07.0000] <annevk>
Or does shipping and marketing a feature for Beta say nothing about final?

[01:44:20.0000] <MikeSmith>
annevk: afaik from chrome shipping is shipping

[01:45:35.0000] <MikeSmith>
there's no "let's try shipping this for beta only"

[01:45:37.0000] <zcorpan>
"You are FAILING HARD" LOL https://www.w3.org/Bugs/Public/show_bug.cgi?id=23436

[01:46:00.0000] <MikeSmith>
at least as far as I can glean from intent-to-ship messages on blink-dev

[01:46:32.0000] <MikeSmith>
zcorpan: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2551 looks same to me in gecko as in blink

[01:46:40.0000] <MikeSmith>
wondering what I should be seeing

[01:46:43.0000] <annevk>
MikeSmith: if that's true that'd be bad...

[01:46:56.0000] <annevk>
zcorpan: seems someone doesn't understand plugins

[01:48:45.0000] <zcorpan>
MikeSmith: you sure? do you have the latest?

[01:49:23.0000] <zcorpan>
MikeSmith: i get false,true in gecko and true,false in blink. spec agrees with blink

[01:59:45.0000] <MikeSmith>
zcorpan: stepped away from my PC. will look again when I get back

[02:36:15.0000] <zcorpan>
MikeSmith: what does v.nu do in <!DOCTYPE html><body></body><!--x--></html>x ? does it insert the comment to body, or drop it on the floor, or something else?

[02:38:40.0000] <zcorpan>
hmm, the spec requires non-streamable behavior for conforming markup too. (replace the x with a space)

[02:40:20.0000] <MikeSmith>
zcorpan: the x after the html end tag is conforming?

[02:40:31.0000] <zcorpan>
MikeSmith: no but a space is

[02:40:48.0000] <MikeSmith>
(btw still away from my PC)

[02:40:49.0000] <zcorpan>
MikeSmith: and it's inserted to body but the comment was inserted after body

[02:40:53.0000] <MikeSmith>
ok

[02:44:55.0000] <zcorpan>
maybe all comments are dropped?

[02:52:44.0000] <MikeSmith>
zcorpan: back at the sugar shack now

[02:53:02.0000] <MikeSmith>
zcorpan: you know (remember) about http://html5.validator.nu/parsetree/ ?

[02:53:12.0000] <MikeSmith>
http://html5.validator.nu/parsetree/?parser=html5&content=%3C%21DOCTYPE+html%3E%3Cbody%3E%3C%2Fbody%3E%3C%21--x--%3E%3C%2Fhtml%3Ex&submit=Print+Tree

[02:53:57.0000] <MikeSmith>
http://html5.validator.nu/parsetree/?parser=html5&content=%3C%21DOCTYPE+html%3E%3Cbody%3E%3C%2Fbody%3E%3C%21--x--%3E%3C%2Fhtml%3E+&submit=Print+Tree

[02:54:05.0000] <zcorpan>
MikeSmith: that doesn't seem to use the streaming mode

[02:54:11.0000] <MikeSmith>
oh

[02:54:14.0000] <MikeSmith>
hmm

[02:54:23.0000] <MikeSmith>
I thought it had to be

[02:54:29.0000] <MikeSmith>
but maybe not

[02:54:37.0000] <MikeSmith>
/me looks at the code

[02:55:11.0000] <zcorpan>
</head> <link> is fatal when validating but not in parsetree/

[02:57:08.0000] <MikeSmith>
yeah

[02:58:39.0000] <MikeSmith>
so says the code also

[02:58:43.0000] <MikeSmith>
https://bitbucket.org/validator/validator/src/ae0fad1a06291493117dcfe52f983710245f5441/src/nu/validator/servlet/ParseTreePrinter.java?at=default#cl-128

[02:58:58.0000] <MikeSmith>
OK I can check it locally

[03:15:29.0000] <MikeSmith>
zcorpan:

[03:15:33.0000] <MikeSmith>
#document

[03:15:33.0000] <MikeSmith>
| <!DOCTYPE html>

[03:15:33.0000] <MikeSmith>
| <html>

[03:15:34.0000] <MikeSmith>
|   <head>

[03:15:34.0000] <MikeSmith>
|   <body>

[03:15:36.0000] <MikeSmith>
|     <!-- x -->

[03:15:38.0000] <MikeSmith>
|     " "

[03:15:55.0000] <MikeSmith>
I can push it to qa-dev for you try yourself

[03:24:19.0000] <MikeSmith>
zcorpan: OK http://qa-dev.w3.org:8888/parsetree/ has the parser running in non-streaming mode, I think

[03:26:48.0000] <MikeSmith>
http://qa-dev.w3.org:8888/parsetree/?parser=html5&content=%3C%21DOCTYPE+html%3E%3C%2Fhead%3E+%3Clink%3E&submit=Print+Tree

[03:50:37.0000] <cortexA9>
hello

[04:07:01.0000] <zcorpan>
MikeSmith: ok, so it just inserts the comment in the wrong place.

[04:07:28.0000] <MikeSmith>
oh

[04:07:33.0000] <MikeSmith>
wrong per the spec you mean?

[04:07:37.0000] <zcorpan>
yeah

[04:07:42.0000] <MikeSmith>
hmm

[04:08:29.0000] <MikeSmith>
that seems like a bug then

[04:09:29.0000] <MikeSmith>
also I don't understand why it would be doing anything different from what gecko is doing

[04:09:39.0000] <MikeSmith>
in non-streaming mode I mean

[04:11:51.0000] <MikeSmith>
ah sorry you're talking about streaming mode

[04:11:52.0000] <MikeSmith>
nm

[04:12:06.0000] <zcorpan>
right

[04:14:35.0000] <zcorpan>
ok sent a new email

[04:42:57.0000] <MikeSmith>
zcorpan: I'm hacking on the parser coce now

[04:52:50.0000] <jgraham>
miketaylr: TIL that I should talk to you about testsuites and jQuery :)

[05:59:11.0000] <jgraham>
"HTML5 is mostly a joke" - Ian Hickson

[05:59:34.0000] <jgraham>
</quote type=out-of-context>

[06:00:02.0000] <jgraham>
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000422.html)

[06:11:33.0000] <MikeSmith>
when zcorpan gets back please tell him http://qa-dev.w3.org:8888/ is now running a hacked parser that attempts to include the changes he outlined in http://lists.w3.org/Archives/Public/www-archive/2013Oct/0015.html -- except for the forster-parenting change which in the parser code it's not clear to me yet how to handel

[06:15:11.0000] <MikeSmith>
hmm whoops maybe not yet .. ArrayIndexOutOfBoundsException

[06:16:18.0000] <jgraham>
VeryMuchTooLongExceptionNameException

[06:19:01.0000] <MikeSmith>
heh

[06:19:05.0000] <MikeSmith>
ah well

[06:19:27.0000] <MikeSmith>
I give up for now

[07:14:34.0000] <lrvick>
So, does whatwg have an official documented stance somewhere on DRM?

[07:44:41.0000] <zewt>
whatwg has stances?

[07:57:45.0000] <jgraham>
whatwg exists?

[07:58:35.0000] <annevk>
LIES

[07:58:51.0000] <barnabywalters>
actually I’ve been meaning to ask for a while — how is WHATWG pronounced?

[07:59:34.0000] <barnabywalters>
WHAT-wug? wuh-HAT-wug?

[08:00:45.0000] <zewt>
W:DWG

[08:05:24.0000] <darobin>
barnabywalters: most people say what-wee-gee — but there isn't really a standard on that

[08:05:56.0000] <zewt>
that's the worst thing i've heard today

[08:06:29.0000] <darobin>
that's only because you haven't heard it pronounced in French

[08:06:51.0000] <jgraham>
Coming from darobin it is like the soft kiss of a lover

[08:07:03.0000] <barnabywalters>
/me makes a WHATWG (wuh-HAT-wg) hat

[08:07:24.0000] <darobin>
jgraham: especially in French!

[08:22:50.0000] <annevk>
darobin is correct

[08:27:14.0000] <Domenic_>
I can't stop myself from saying "what-wug"

[08:28:02.0000] <Domenic_>
paul_irish: thanks :D

[10:05:32.0000] <miketaylr>
jgraham: ha, cool. let's chat mid next week, currently summitting (and being generally distracted)

[10:08:00.0000] <miketaylr>
(mozsummitting, not anything cool like a mountain)

[10:17:47.0000] <annevk>
miketaylr: which location?

[10:19:21.0000] <miketaylr>
annevk: Toronto

[10:19:40.0000] <miketaylr>
decided to take a break from crossing the Atlantic ocean for a while

[10:21:54.0000] <annevk>
fair

[10:22:20.0000] <miketaylr>
annevk: are you in brussels?

[10:22:23.0000] <annevk>
yeah

[10:22:38.0000] <miketaylr>
eat a waffle for me

[10:22:51.0000] <annevk>
hah, on it

[10:37:46.0000] <dglazkov>
HTML5 is not a joke

[10:37:50.0000] <dglazkov>
jokes have punchlines

[10:52:12.0000] <MikeSmith>
dglazkov: DRM it the punchline

[10:53:41.0000] <MikeSmith>
culmination of 8-9 years of work on trying to make the Web platform a contender that has feature parity with all the other feature-overladen platforms out thre

[10:53:54.0000] <MikeSmith>
mission accomplished

[10:58:29.0000] <umgrosscol>
How is it that the Encrypted Media Extensions are going to prevent browsers from downloading the video anyway?  I don't understand how anyone thinks it's going to protect content.

[11:00:12.0000] <rtc>
each webpage should have only one h1 element?

[11:00:34.0000] <rtc>
if this is true why then html5 specification has examples where each section has own h1 element?

[11:30:47.0000] <barnabywalters>
anyone know if there’s a canonical test suite for the URL/URI standards?

[11:30:54.0000] <barnabywalters>
e.g. for parsing, resolving relative references

[12:23:21.0000] <Hixie_>
jgraham: hey, i had quote marks in my quote! you need at worst to say something like '"HTML5 is a joke" -- Ian Hickson (internal quote marks elided)'

[12:25:08.0000] <Hixie_>
lrvick: looking at @WHATWG's recent retweets of the EFF's tweet and Anne's tweets should give a pretty accurate answer: https://twitter.com/WHATWG

[12:40:43.0000] <lrvick>
Hixie_: Yeah, that about sums it up. Well... I will hang around this side of the fence then.

[12:41:09.0000] <lrvick>
W3C, I am dissipoint.

[12:42:39.0000] <Hixie_>
dissipoint? do you need to be put in a jar or something? :-)

[12:49:58.0000] <zcorpan>
umgrosscol: https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2

[12:57:55.0000] <umgrosscol>
zcorpan: I understand the leverage against hardware manufacturers... especially with import laws and devices being manufactured within jursidictions... but it seems to make less sense for software.

[12:59:22.0000] <umgrosscol>
In the best case scenario for the rights holders, it means they get to liscence modules that browsers have to use and the unliscenced browsers get marginalized.

[13:00:18.0000] <umgrosscol>
I just can't imagine that there is going to be module that doesn't get cracked in short order.

[13:00:33.0000] <zewt>
re-read the post :) preventing it from being cracked isn't the point

[13:00:50.0000] <zcorpan>
MikeSmith: i can't reach http://qa-dev.w3.org:8888

[13:01:05.0000] <zewt>
giving companies something to sue people who use cracked encryption over is the point

[13:01:41.0000] <umgrosscol>
I understand trying to sue a manufacturer... they have a brick and mortar location.  How do you sue source code?

[13:02:01.0000] <zewt>
by suing Mozilla, or Google, or Microsoft, or Apple

[13:02:06.0000] <zewt>
they have offices too

[13:02:21.0000] <umgrosscol>
They do, but that doesn't help if they didn't write the source.

[13:02:43.0000] <umgrosscol>
Or even you know who did, and it's released at Public Domain.

[13:02:50.0000] <zewt>
none of that matters

[13:03:00.0000] <zewt>
it prevents Google from having a feature in Chrome to bypass DRM

[13:03:11.0000] <zewt>
and similar effects on other parties

[13:03:17.0000] <umgrosscol>
So I end up using a Swedish browser...

[13:03:41.0000] <zewt>
they don't care about that, people bypassing DRM themselves are 0.000001%

[13:04:01.0000] <umgrosscol>
That's the bet it seems.

[13:04:08.0000] <zewt>
not a bet, it's reality

[13:04:44.0000] <umgrosscol>
If you can only go after a subset of manufacturers, and you can't prevent imports, then you're making an edge for the manufacturers that don't comply and just circumvent.

[13:04:48.0000] <zewt>
(people don't pirate movies by downloading decss and copying their friend's DVD, they do it by going to the internet and downloading from someone else who already did all that)

[13:05:47.0000] <umgrosscol>
If this plays out where you need liscenced plugins to view certain content, I imagine that there will be some nice browsers that offer unliscenced plugins to view the same content.

[13:06:09.0000] <umgrosscol>
If I had the option to buy a dvd player that didn't have regional control crap, I would.

[13:06:30.0000] <umgrosscol>
Such DVD players can't be imported, so I can't get one.

[13:07:19.0000] <umgrosscol>
However, I can easily import a browser from wherever.  Locking down the manufacture of browser software seems like it's not going to go as planned.

[13:07:30.0000] <zewt>
... 0.000001%

[13:07:35.0000] <umgrosscol>
At worst it ends up like Netscape vs IE.

[13:09:03.0000] <umgrosscol>
zewt: Currently a small percentage.  If using the mainstream browsers becomes a hassle, wouldn't you expect that to push users towards some new open source thing without the hassles?

[13:09:17.0000] <zewt>
using it won't be a hassle

[13:09:22.0000] <zewt>
(which isn't an argument for it--I'm as against it as anybody)

[13:09:45.0000] <zewt>
nobody is actually for DRM, except for people being paid to be for DRM. heh

[13:10:24.0000] <umgrosscol>
zewt: I can't think of one DRM system that I've come across that isn't a hassle.

[13:10:48.0000] <zewt>
not to typical users

[13:11:03.0000] <zewt>
(other than in particular instances, like the introduction of HDCP)

[13:11:11.0000] <umgrosscol>
I imagine it's also going to be a nightmare for accessibility issues.

[13:12:46.0000] <zcorpan>
i wonder if the accessibility card can be used to regulate drm

[13:13:32.0000] <zewt>
any browser implementing DRM doesn't give a shit about things the web cares about, and I'd have to assume are being paid to do it, so there are probably no "cards"

[13:13:52.0000] <zewt>
(incompatible with open standards, security, all the rest)

[13:15:34.0000] <umgrosscol>
zcorpan: It usually makes website more difficult to develop well, and rarely gets to litigation.

[13:16:22.0000] <zcorpan>
i didn't mean a browser vendor would be pushing for regulation of drm for accessibility, probably more the people that need the accessibility stuff

[13:18:33.0000] <zcorpan>
i also don't think that e.g. chrome implementing DRM means that it doesn't give a shit about things the web cares about

[13:18:56.0000] <zewt>
it sure means that about some segment of people with influence; they're exactly at odds

[13:19:21.0000] <zcorpan>
yeah

[13:19:50.0000] <zewt>
(any guessing about the opinions of a browser vendor is really talking about some segment, of course, since the Borg doesn't make a browser, heh)

[13:19:54.0000] <zcorpan>
but it doesn't make chrome suddenly give a shit about e.g. security

[13:21:02.0000] <zewt>
it does mean they're putting other things above the goal of an open web

[13:23:23.0000] <umgrosscol>
zewt: I think that's probably going to end up as the biggest problem.

[13:23:39.0000] <umgrosscol>
zewt: Shifting focus away from interoperability.

[13:23:47.0000] <zewt>
not exactly what i mean

[13:24:23.0000] <zewt>
it would no longer be possible to implement a browser on a new platform (say, on set tops and consoles), unless the owners of the magic black boxes like you (and/or you pay them enough money) to port their black box to your thing

[13:28:37.0000] <umgrosscol>
So a black box free browser wouldn't be able to view most of the DRM video ?

[13:29:03.0000] <zewt>
i think that's the point :)

[13:31:12.0000] <zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23255 so custom elements allow uppercase in xhtml? is that a good idea?

[13:37:53.0000] <jgraham>
Hixie_: Yeah, I unfairly edited your quote :) I was actually looking for the first use of the term "HTML5"

[13:37:59.0000] <jgraham>
(with or without space)

[13:38:30.0000] <jgraham>
It's pretty funny that people still use it to mean "the open web stack"

[13:38:46.0000] <jgraham>
Although maybe these days that's more like the 'open' web stack

[13:51:25.0000] <scheib>
What's the specification-ish way to say "user gesture required"?

[13:52:37.0000] <Hixie_>
jgraham: first use of HTML5 that i know of was while i was having lunch with howcome after i interviewed for working at opera, in 2003. He suggested we should do an "HTML5". I thought he was nuts.

[13:58:21.0000] <Ms2ger>
Hixie_, clearly, you were right

[13:58:35.0000] <Ms2ger>
jgraham, gave up on the karaoke too? :)

[13:58:39.0000] <Hixie_>
clearly

[14:01:22.0000] <jsbell>
Shoulda called it "AJAX 2.0" instead

[14:04:45.0000] <zcorpan>
i recall sometime in 2004 i for some reason was reading the WF2 spec (don't remember how i got there). i was still new to web dev in general. then i tried some of the examples, realized that it wasn't implemented anywhere and concluded that i was wasting my time trying to learn something that didn't work, and closed the tab

[14:09:04.0000] <zcorpan>
around the same time, i was looking at the w3c home page looking at some list of names, and thinking for a moment what it would be like to be working with that stuff. then i snapped back to reality and thought that's not gonna happen

[14:09:12.0000] <Ms2ger>
Heh

[14:11:29.0000] <Hixie_>
hehe

[14:14:20.0000] <Hixie_>
mounir: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=11937 (bug is closed now, pending your feedback; please reopen if you have some)

[14:14:41.0000] <Hixie_>
annevk: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=20571 (same thing)

[14:17:16.0000] <Ms2ger>
Hixie_, this is for the *setter*, right?

[14:17:23.0000] <Hixie_>
which?

[14:18:20.0000] <Ms2ger>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20571

[14:19:14.0000] <Hixie_>
beats me

[14:19:18.0000] <Hixie_>
i've no idea what the bug is about

[14:21:08.0000] <Ms2ger>
WebIDL says " If the operation used to declare the indexed property setter did not have an identifier, then the interface definition must be accompanied by a description of how to **set the value of an existing indexed property** for a given property index and value."

[14:21:28.0000] <Ms2ger>
I guess he took that to mean that the exact words "set the value of an existing indexed property" need to be in HTML

[14:23:33.0000] <jgraham>
Ms2ger: I Funnily enough I did :)

[14:24:15.0000] <Hixie_>
Ms2ger: oh because i only mention "set the value of a new indexed property" not both?

[14:24:18.0000] <Hixie_>
hm

[14:24:32.0000] <Hixie_>
he didn't say that, but whether that's what the bug is about or not, it's probably a valid point in and of itself

[14:27:54.0000] <Hixie_>
Ms2ger: ok, see patch in bug... is that enough?

[14:28:02.0000] <Hixie_>
Ms2ger: anne mentioned other things too but i don't see how they apply

[14:41:14.0000] <Ms2ger>
Hixie_, I'll let annevk figure out if that's what he meant :)

[15:28:46.0000] <Hixie_>
lol, i hadn't seen the mess that the htmlwg spec's <blockquote> section has become until just now

[15:28:54.0000] <Hixie_>
they literally say you can't quote footers, you have to comment them out!

[15:28:58.0000] <Hixie_>
that's awesome

[15:31:12.0000] <Hixie_>
it's a self-parodying fork

[15:43:13.0000] <zewt>
is there somewhere I can mail a $100 bill to be able to turn off the horrible chrome address bar auto-typo mode

[15:43:25.0000] <zewt>
like really i've got a $100 bill and an envelope, where do I address it

[15:46:47.0000] <Hixie_>
Ian Hickson, c/o Google, 1600 Amphitheatre Parkway, Mountain View CA 94043, USA

[16:25:16.0000] <smaug____>
MikeSmith: hmm, lots of 408 from w3c bugzilla

[16:37:50.0000] <ori-l>
hrm. anyone familiar with the resource timing API? i have all-but-fully-confirmed that an XHR may have readyState == 4 before its timing entry is created

[16:38:01.0000] <ori-l>
and i'm just sort of hoping that it's not really true.


2013-10-05
[18:00:59.0000] <zewt>
heh, when I offer some responses and criticism to the guy posting on www-dom, he mails me directly and asks what my relationship with the spec is

[18:01:20.0000] <zewt>
reads like "I don't have answers to your criticisms, so I'd like to know if I can ignore you"

[20:30:22.0000] <Yuhong>
https://news.ycombinator.com/item?id=6491406 "I'm quite surprised to see Tim Berners-Lee approve this [HTML5 DRM] in fact, I wonder what made him say yes to this.

[20:31:27.0000] <wowaname>
.-.

[02:34:27.0000] <rtc>
can I place block element inside inline-block?

[03:16:28.0000] <rniwa>
rtc: yes.

[03:17:32.0000] <SteveF_>
Hixie: re <blockquote> we bozos in the HTML WG decided that the REALLY important and ultra common use case of footer in blockquote should be sacrificed in favour of the totally useless edge case of in block citations

[06:09:56.0000] <joelcox>
Domenic_: Interesting stuff regarding your upcoming talk about getting involved in web standards

[08:09:17.0000] <annevk>
hsivonen: IE does the same as Chrome: http://dump.testsuite.org/js/documentdomain.htm

[16:32:36.0000] <annevk>
gsnedders: Python has the same flaw though right?

[16:33:05.0000] <annevk>
gsnedders: you couldn't implement a web environment on top of Python and reuse their string implementation

[16:33:15.0000] <gsnedders>
annevk: Huh?

[16:33:22.0000] <annevk>
gsnedders: might be okay for Python though, seems unlikely you'd implement a browser in it

[16:33:32.0000] <gsnedders>
annevk: Oh, sure, because it's the full codepoint range.

[16:33:41.0000] <gsnedders>
annevk: Hey, SimonSapin did. Sort of.

[16:33:58.0000] <annevk>
gsnedders: full code point range even in 8-bit mode?

[16:34:20.0000] <gsnedders>
annevk: It's transparent.

[16:34:23.0000] <annevk>
gsnedders: does it use CESU-8?

[16:34:48.0000] <gsnedders>
annevk: You only have a abstract unicode type, supporting any codepoint, that changes its internal representation magically.

[16:35:30.0000] <annevk>
gsnedders: k, I guess that might be good enough


2013-10-06
[17:11:51.0000] <Domenic_>
is https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html worthwhile or has that all been rolled into WHATWG HTML?

[17:13:34.0000] <sweb>
W3c is dead with accept DRM

[17:14:51.0000] <annevk>
Domenic_: folded in

[23:27:19.0000] <crocket>
Does an iframe have its own javascript environment?

[23:27:33.0000] <crocket>
Or is its javascript environment integrated with the parent doc?

[01:08:32.0000] <SimonSapin>
annevk: what flaw?

[01:08:47.0000] <SimonSapin>
gsnedders: well WeasyPrint does not have JS at all, so doesn’t care about JS strings

[02:40:39.0000] <annevk>
Oh wow, Flash is already no longer being maintained for Linux: https://bugzilla.mozilla.org/show_bug.cgi?id=902630#c5

[02:41:01.0000] <annevk>
Correction, the NPAPI version of Flash

[04:00:32.0000] <MikeSmith>
is the current Promises feature in the DOM spec based on Promises/A+ ?

[04:01:51.0000] <MikeSmith>
Domenic_: ↑

[04:22:03.0000] <MikeSmith>
nm

[04:22:38.0000] <MikeSmith>
after taking time to actually read the current spec I see it's now just referencing https://github.com/domenic/promises-unwrapping/blob/master/README.md

[04:24:00.0000] <MikeSmith>
I guess I ought to try to keep up with es-discuss

[04:27:20.0000] <MikeSmith>
whah.. Promise.race

[04:41:42.0000] <MikeSmith>
so I wonder what exactly is being implemented now in blink

[04:41:52.0000] <MikeSmith>
what document they are implementing from

[05:59:40.0000] <annevk>
dglazkov: HTML Imports, scripts executing in the imported document, might find it weird what document refers to

[06:03:34.0000] <Ms2ger>
zcorpan: r? https://critic.hoppipolla.co.uk/r/34

[06:10:39.0000] <jeena_>
I would like to write to the appropriate W3C mailing list about it but there seems to be a really huge amount of them so I'm confused to which one I should write.

[06:11:30.0000] <jeena_>
I wanted to write and suggest to send forms if the user presses Cmd+Enter/Ctrl+Enter in a form, this especially should work in a textarea.

[06:11:59.0000] <annevk>
jeena_: that's UI and we can't really dictate UI in specifications

[06:12:01.0000] <jeena_>
Just like Gmail does it, but for every form in every browser (like Enter in a <input> works now)

[06:12:18.0000] <annevk>
jeena_: you can file bugs on browsers though where that does not work

[06:12:35.0000] <jeena_>
ah hm ok, I see

[06:12:43.0000] <jeena_>
Ok thanks then I will do that instead.

[06:13:43.0000] <jeena_>
so the Enter within a <input> isn't something the W3C "dictated" but it just is a coincidence that it works in all browsers?

[06:13:50.0000] <jeena_>
(to send the form)

[06:14:06.0000] <annevk>
jeena_: yeah

[06:14:39.0000] <annevk>
jeena_: prolly followed from UI conventions in operating systems

[06:15:10.0000] <jeena_>
ok, thanks, then I understand. It is kind of obvious that not every browser will have a keyboard with a Ctrl key.

[07:17:45.0000] <MikeSmith>
I see from https://code.google.com/p/chromium/issues/detail?id=295420 that blink implementation is tracking https://code.google.com/p/chromium/issues/detail?id=295420

[07:43:58.0000] <zcorpan>
MikeSmith: done (re review).

[07:44:19.0000] <zcorpan>
MikeSmith: btw any news on why http://qa-dev.w3.org:8888/ doesn't work (for me, at least)?

[07:44:29.0000] <MikeSmith>
review? which

[07:45:50.0000] <MikeSmith>
about http://qa-dev.w3.org:8888/ it doesn't work because the parser hacks I made cause it to crash with a index-out-of-bounds error

[07:46:07.0000] <MikeSmith>
and the reason for the index-out-of-bounds error is this:

[07:47:17.0000] <MikeSmith>
                case AFTER_HEAD:$

[07:47:48.0000] <MikeSmith>
...

[07:47:51.0000] <MikeSmith>
                        case BODY:

[07:47:52.0000] <MikeSmith>
                            pop();

[07:47:52.0000] <MikeSmith>
                            if (attributes.getLength() == 0) {

[07:47:52.0000] <MikeSmith>
                                appendToCurrentNodeAndPushBodyElement();

[07:47:52.0000] <MikeSmith>
                            } else {

[07:47:54.0000] <MikeSmith>
                                appendToCurrentNodeAndPushBodyElement(attributes);

[07:47:57.0000] <MikeSmith>
                            }

[07:48:17.0000] <MikeSmith>
the change I made was to add that pop()

[07:48:59.0000] <MikeSmith>
but then it now gets to that appendToCurrentNodeAndPushBodyElement() call and that's what leads to the index-out-of-bounds exception

[07:52:25.0000] <MikeSmith>
so it seems I need to do more than just simply add the "Pop the current node (which will be the head element) off the stack of open elements." step

[07:55:18.0000] <MikeSmith>
because it's not finding what it needs when it tries to actually push that body element onto the stack

[07:55:37.0000] <annevk>
So if @@create is taken from the function object on which new was invoked, it seems new Node() could be made to throw. By checking after @@create if the proper bits are set, as peterv suggested.

[12:39:17.0000] <heycam>
annevk, noted

[12:59:46.0000] <wilhelm>
I'll be giving a talk to some web developers tomorrow on how the specification sausage factory actually works. (Or how it doesn't work.) Revisiting archives and minutes from 2004-2007 is rather amusing.

[13:00:41.0000] <Ms2ger>
Oh dear

[13:04:22.0000] <wilhelm>
Indeed.

[13:13:30.0000] <odinho>
annevk: What's status on Fetch btw? Esp. the new non-implemented/finished parts. How's the vendor interest there?

[13:13:45.0000] <odinho>
wilhelm: What web devs where?

[13:15:40.0000] <annevk>
odinho: such as?

[13:15:57.0000] <annevk>
odinho: dunno really, it's architecture, nobody really cares about getting that a 100% right

[13:16:00.0000] <odinho>
annevk: Well, I was thikning of the ZipArchive part. Because it's easiest to see.

[13:16:05.0000] <annevk>
odinho: might have something to do with yak shaving

[13:16:15.0000] <annevk>
odinho: ooh, that's kinda dodgy

[13:16:27.0000] <annevk>
odinho: given recent discussion I should maybe take that out again

[13:16:27.0000] <odinho>
Yeah, -- that looked a bit dodgy what with all the red.

[13:44:05.0000] <wilhelm>
odinho: Internal training at a local development agency I'm doing some business with.

[14:11:21.0000] <Domenic_>
MikeSmith: looks like you figured it out?

[14:44:07.0000] <Ms2ger>
jgraham, r? https://critic.hoppipolla.co.uk/r/31 if you're tired of servo at some point :)

[14:50:17.0000] <jgraham>
I am generally just tired right now :)

[14:50:49.0000] <jgraham>
Will try to look in the morning


2013-10-07
[18:41:37.0000] <MikeSmith>
Domenic_: yeah got it figured out

[02:05:07.0000] <zcorpan>
MikeSmith: are your changes online?

[02:48:37.0000] <annevk>
jgraham: final paragraph of http://en.wikipedia.org/wiki/Quantum_computer#Developments

[02:56:05.0000] <jgraham>
annevk: I note that is all in the future tense, and slightly before that it says "In November 2011, researchers factorised 143"

[03:01:55.0000] <Ms2ger>
jgraham, r? https://critic.hoppipolla.co.uk/r/31 :)

[03:06:58.0000] <jgraham>
r+ :)

[03:07:24.0000] <Ms2ger>
Woo :)

[03:08:17.0000] <Ms2ger>
Almost managed to get it done in six months :)

[03:12:24.0000] <annevk>
jgraham: you said 15, so... but yeah

[03:13:07.0000] <Ms2ger>
(I have to admit that I found the sessions at the summit more interesting than this class)

[03:18:01.0000] <jgraham>
Ms2ger: UML? :)

[03:18:18.0000] <Ms2ger>
I managed to avoid that :)

[03:18:21.0000] <Ms2ger>
Machine learning

[08:14:28.0000] <rtc>
is it ok if I put div inside h2?

[08:30:33.0000] <annevk>
rtc: no

[08:31:24.0000] <rtc>
annevk, does it matter css properties of the elements with their position on html

[08:31:46.0000] <annevk>
I can't parse that question

[08:31:51.0000] <rtc>
so let's say if I make div inline element with css, can I put it in another inlin element then? is this ok?

[08:32:08.0000] <rtc>
sorry about my english, it's little bad :)

[08:33:45.0000] <annevk>
rtc: CSS doesn't affect semantics

[08:33:49.0000] <annevk>
rtc: so no

[08:34:04.0000] <rtc>
ok

[08:34:06.0000] <rtc>
it is strange

[08:34:10.0000] <rtc>
you guys need to work

[08:34:17.0000] <rtc>
on some thins, honestly

[08:34:29.0000] <annevk>
it's not strange at all, CSS is optional, HTML should make sense without CSS

[08:35:29.0000] <rtc>
annevk, this is me speaking because I have to change about 30 elements structure now -_-

[08:35:34.0000] <rtc>
coz I have put divs inside h2 :)

[08:35:39.0000] <rtc>
hehe good work so far

[08:35:46.0000] <rtc>
keep up the good work! and respect hixie

[08:36:21.0000] <rtc>
annevk,  I have put 30 divs inside h2 why you made html so divs can't go in h2 :S

[08:36:22.0000] <rtc>
:D

[08:50:31.0000] <rtc>
annevk, I truly admire Timothy and his team

[08:50:54.0000] <annevk>
rtc: not sure who that is

[08:50:58.0000] <rtc>
his mission/vision and all who work on the project keep up the good work guys!

[08:51:49.0000] <rtc>
he will go where nikola tesla einstein newton platon aristotle pitagora are

[08:53:43.0000] <rtc>
annevk, can I ask you question about your personal info?

[08:54:00.0000] <rtc>
mor exactly where you work besides whatwg

[08:55:36.0000] <annevk>
rtc: http://annevankesteren.nl/about

[08:57:23.0000] <rtc>
thanks!

[08:58:25.0000] <rtc>
annevk, lets start a company

[08:59:23.0000] <rtc>
annevk, you look like a nice guy from the image :) hehe

[08:59:24.0000] <rtc>
look

[08:59:34.0000] <rtc>
seriouslly please decrease the size of the fonts!

[08:59:37.0000] <rtc>
they are too big

[08:59:43.0000] <rtc>
and dcrease everything and finally!

[08:59:47.0000] <rtc>
please remove top bad please

[09:00:00.0000] <rtc>
so I don't think internet explorer is better than firefox :S

[09:00:14.0000] <rtc>
they finally starting to work on the things with ie11 adopting webgl

[09:00:19.0000] <rtc>
on my total surprise

[09:02:19.0000] <rtc>
annevk,  sorry but im honest :|

[09:02:36.0000] <rtc>
lately I feel firefox is left behind

[09:02:39.0000] <rtc>
please work on this

[09:02:44.0000] <rtc>
3d preview is awesome

[09:02:51.0000] <rtc>
I always show my students that :)

[09:03:07.0000] <rtc>
they are simply amazed asking me how I made it, well I should give credits to you hehe

[09:03:43.0000] <rtc>
mdn site is awesome too thanks for making that, just remove the top bar from firefox and decrease fonts pls

[09:04:01.0000] <rtc>
and do something with google guys to make browsers simialr

[09:05:09.0000] <rtc>
annevk,  yo udo 3d visualization?

[09:16:40.0000] <rtc>
annevk, should we change our html code in 2020 to html5?

[09:17:06.0000] <rtc>
because how things are going, people stil lsupporting ie6 it looks like 2020 will be target for html5 because people still will support ie 8

[10:27:37.0000] <dglazkov>
good morning, Whatwg!

[11:28:29.0000] <rtc>
can I put block element inside inline-block element?

[11:29:48.0000] <Ms2ger>
Sure

[11:35:41.0000] <rtc>
Ms2ger,  thanks

[13:00:50.0000] <annevk>
Does anyone happen to know if iOS carrier setting updates overwrite existing iOS carrier settings or whether it stores them all side by side?

[14:41:35.0000] <Domenic_>
Is ServiceWorker still the current name?

[14:44:53.0000] <annevk>
yws

[14:50:30.0000] <zcorpan>
maybe rename it at LC?

[14:51:20.0000] <Domenic_>
i too thought it meant prostitute but google says it just means waiter or similar. *shrug*

[15:32:45.0000] <TabAtkins>
What sort of verbage would be appropriate to refer to a trusted event which is appropriate for "activating"?  Things like clicks and keyboard presses, but not mousemove events.

[15:33:38.0000] <TabAtkins>
Is there already a term for that?

[15:35:19.0000] <Hixie_>
TabAtkins: 'click'? :-)

[15:35:40.0000] <Hixie_>
TabAtkins: keyboard presses fire a click event before they trigger activation behaviours

[15:36:14.0000] <zewt>
keyboard events can trigger only-during-click stuff, even if there's no associated click, right?

[15:36:29.0000] <zewt>
(seems like they should, at least)

[15:36:36.0000] <TabAtkins>
Hm, maybe.  Context is fullscreen and stuff - asking for Vincent.  He's currently referring to something wk specific called "user gesture" which means "the subset of events that represent the user actually doing something".

[15:36:42.0000] <TabAtkins>
It might just be "click".

[15:37:24.0000] <zewt>
eg. you should be able to listen for key events to fullscreen if the user presses alt-enter, even if there's nothing to activate (or if you cancel the keypress event so you don't activate something unintentionally)

[15:38:09.0000] <TabAtkins>
zewt: Exactly.

[15:38:27.0000] <scheib>
Thanks for asking TabAtkins, I'm back at desk.

[15:38:39.0000] <rektide>
q: is there a specification where i can ask a webserver for a non-minified version of a page, a human readable please version?

[15:38:58.0000] <scheib>
Yes, and for pointer lock. Other events could be voice actions, or taps on touch screens. So.... these are all 'click'?

[15:40:59.0000] <zewt>
right: click is not what you want, and I'm not sure if there's any spec for this stuff

[15:43:56.0000] <rektide>
for some reason i thought there was some incipent view-source movement that had proposed a hook asking for "human friendly" assets, but i haven't found any links to anything except the view-source:// uri,  http://tools.ietf.org/html/draft-yevstifeyev-view-source-uri-01#page-2

[15:44:23.0000] <rektide>
which will open up the unspeakable compiled horrors no human will be able to read

[15:45:07.0000] <TabAtkins>
rektide: To the best of my knowledge, no.  You may be thinking of humans.txt, which is unrelated.

[15:45:08.0000] <Hixie_>
rektide: http, but you have to know the URL of the non-minified version :-)

[15:45:40.0000] <Hixie_>
TabAtkins: sounds like you want something consistent with what is considered a gesture for the purposes of popup blocking

[15:45:49.0000] <TabAtkins>
Hixie_: Yes, exactly that.

[15:45:59.0000] <rektide>
righto, yeah. perhaps a misuse of Nottingham's alternative service might be permissible here

[15:46:04.0000] <rektide>
spdy-human

[15:46:07.0000] <rektide>
quick-human

[15:46:18.0000] <barnabywalters>
rektide: http://daneden.me/max-css/ comes to mind

[15:46:19.0000] <rektide>
quik-human even. alterantive transports, i need you

[15:46:40.0000] <rektide>
yes, your asset compiler is part of your transport

[15:46:53.0000] <rektide>
don't dare disagree with me, you mangling serializing toolchain

[15:47:06.0000] <rektide>
barnabywalters: yup, that's perfect.

[15:47:51.0000] <rektide>
i'm alas not well versed on source maps, what role they might play.

[15:51:34.0000] <Hixie_>
TabAtkins: http://www.whatwg.org/specs/web-apps/current-work/#allowed-to-show-a-popup may be helpful

[15:53:45.0000] <TabAtkins>
Hixie_: I'd have to chase definitions, so I'll just ask you instead - would that work to, say, allow fullscreening when the user presses alt+Enter?

[16:03:38.0000] <Hixie_>
TabAtkins: probably not, i don't see key events in that list

[16:03:51.0000] <Hixie_>
TabAtkins: (maybe it's not exactly the same as popup blocking)

[16:03:59.0000] <Hixie_>
TabAtkins: but it may give you a starting point for a list of events

[16:04:00.0000] <TabAtkins>
Hixie_: Okay, I was wondering if those were subsumed under that "click" entry.

[16:04:05.0000] <Hixie_>
i don't think so

[16:04:18.0000] <Hixie_>
that only happens when you e.g. click space on a button

[16:04:30.0000] <TabAtkins>
That's what I thought.

[16:04:40.0000] <TabAtkins>
scheib: ^^^ You can just copy that list and add the additional events you need.

[16:05:23.0000] <scheib>
Hixie_ Tab is asking on my behalf. I'm particularly asking about pointer lock -- but it should match fullscreen. My reading of allowed-to-show-a-popup shows it to be mostly right. I can see adding to a white list of events. I do notice that http://fullscreen.spec.whatwg.org/ seems to only refer to allow a popup.

[16:05:35.0000] <scheib>
Thanks, for looking, by the way.

[16:07:20.0000] <scheib>
A whitelist is unfortunate, it precludes future unknown but equivalently intended events. I'll try to capture that somehow.

[16:11:45.0000] <zewt>
doesn't prevent it, you just add to the list


2013-10-08
[18:05:59.0000] <Hixie_>
scheib: adding to the list later is cheap, in this brave new world of living standards

[19:59:01.0000] <Hixie_>
http://www.nngroup.com/articles/stagnating-expertise/

[19:59:26.0000] <Hixie_>
(i assume this applies to programming languages too, in which case, it's an argument against us adding features)

[21:16:52.0000] <pdr>
Hixie_, TabAtkins, I'd like to double-check my understanding of srcset wrt pixel densities. If I have a 100x100 png, what is the width and height of <img srcset="100x100.png 2x">? My reading is it would be 100x100 in css pixels, but it's being implemented in Blink differently.

[21:17:30.0000] <TabAtkins>
50x50. (I forgot to specify that in my spec, but it's specified thusly in whatwg.)

[21:19:59.0000] <pdr>
TabAtkins, got it. Would the intrinsic size be (100 x 100) and the natural size (50 x 50)?

[21:20:23.0000] <TabAtkins>
dunno what the difference is, but the intrinsic size (per CSS) would be 50x50

[21:22:18.0000] <pdr>
TabAtkins, http://www.w3.org/TR/css3-images/#intrinsic-dimensions says intrinsic dimensions are not a factor of the context the image is used in

[21:22:40.0000] <TabAtkins>
Correct.  But this isn't quite the same thing.

[21:26:56.0000] <pdr>
Can you expand a bit? I'm trying to nail down how srcset interacts with svg and the intrinsic size wording is tricky

[21:27:39.0000] <TabAtkins>
The intrinsic size is just the input for the CSS algorithms.  srcset/srcN happen at a level before that, and set the intrinsic size.

[21:28:15.0000] <TabAtkins>
This should be pretty natural if you don't run yourself in circles - an image with 100 pixels, at 2x density, naturally covers 50 CSS pixels.  That's its intrinsic size, given that density.

[21:31:27.0000] <pdr>
TabAtkins, what happens if this image is drawn into a canvas with drawImage(...), without specifying a width and height? Would it be drawn with size 50x50 or 100x100?

[21:32:49.0000] <pdr>
It sounds like 50x50, just want to verify

[21:33:53.0000] <TabAtkins>
yes

[21:34:24.0000] <pdr>
thanks for the clarification, off to make this real :)

[21:34:46.0000] <TabAtkins>
Dude, it's 9:30. Stop coding. ^_^

[21:35:10.0000] <pdr>
but.. cats.. the people demand images of cats

[21:36:04.0000] <TabAtkins>
Oh, I suppose your'e right.

[21:39:05.0000] <cabanier1>
pdr: does canvas know about any of this?

[21:42:26.0000] <cabanier1>
pdr: it seems that the canvasImageSource should always use the default

[21:43:15.0000] <pdr>
cabanier1, yeah the spec is pretty clear about using the intrinsic size

[21:43:38.0000] <pdr>
for drawImage

[21:45:03.0000] <cabanier1>
pdr: since the image doesn't need to be in the dom, you can't do the selection except maybe by pixel density

[21:45:13.0000] <cabanier1>
pdr: but that would be weird if it happens

[21:46:09.0000] <pdr>
cabanier1, do we even load the image if it isn't in the dom? /me checks

[21:47:06.0000] <TabAtkins>
For <img>s, we do (I think).

[21:47:31.0000] <pdr>
yeah, we do

[21:47:47.0000] <cabanier1>
http://www.html5canvastutorials.com/tutorials/html5-canvas-images/

[21:48:28.0000] <cabanier1>
that's not html image though

[21:49:31.0000] <pdr>
I guess you're right, we should only use the resolution for selection in that case. srcset already has to deal with dynamic srcset changes so it's not too difficult. I guess image.onload would fire twice?

[21:49:58.0000] <cabanier1>
pdr: but that would be weird

[21:50:30.0000] <cabanier1>
pdr: If you zoom in (not pinch zoom), the image might switch to having more pixels

[21:54:24.0000] <pdr>
cabanier1, actually, the width comes from the viewport. I think that's known w/o putting the image in the document

[21:55:27.0000] <pdr>
cabanier1, does the viewport change during pinch zoom? I don't think so (or, not the one srcset uses)

[21:55:53.0000] <cabanier1>
pdr: but dpr changes

[21:56:08.0000] <cabanier1>
pdr: no, not pinch zoom.

[21:56:19.0000] <cabanier1>
pdr: regular zoom (command + )

[21:57:55.0000] <pdr>
Does browser zoom change the viewport? I don't think it does

[22:01:30.0000] <TabAtkins>
Ctrl-+ style zoom does indeed change the viewport.

[22:05:01.0000] <pdr>
Hopefully nobody promises onload

[22:05:08.0000] <cabanier>
:-)

[22:05:50.0000] <cabanier>
does that mean "hopefully nobody turns onload into a promise?"

[22:06:24.0000] <pdr>
nm, I think promises can return twice

[22:07:16.0000] <TabAtkins>
wait, what?

[22:13:52.0000] <pdr>
I misread http://www.html5rocks.com/en/tutorials/async/deferred. I don't know how promises and onload would work

[22:17:51.0000] <cabanier>
what would be the problem?

[22:31:07.0000] <MikeSmith>
I'm looking for a word to describe benefits of Web Components

[22:31:24.0000] <MikeSmith>
what't the opposite of "bolt on"?

[22:32:07.0000] <MikeSmith>
in the sense that Web Components give you a way to create custom UI controls that aren't just bolted on

[22:32:43.0000] <MikeSmith>
but instead are.. whatever the opposite of bolted on is

[22:32:53.0000] <MikeSmith>
"baked in"?

[22:37:59.0000] <Hixie_>
intergrated

[22:38:37.0000] <Hixie_>
but i don't know if i'd agree that web components aren't bolt-on :-)

[22:38:48.0000] <Hixie_>
i thought that was the whole point, a way to give you bolt-on components :-)

[22:40:16.0000] <MikeSmith>
Hixie_: except that "bolt on" often has a pejorative connotations

[22:42:19.0000] <MikeSmith>
and you can already do "bolt on" components today without needing Web Components

[22:43:34.0000] <MikeSmith>
so it seems not unreasonable to say that compared to the current mechanisms we have, Web Components gives you a way to bake in components rather than just bolting them on

[22:44:26.0000] <MikeSmith>
(I'm trying to figure out how to word it for a reporter with a short attention span.)

[22:45:46.0000] <Hixie_>
well, they are bolt-on. i mean, as opposed to the built-in/baked-in ones like <select>.

[22:45:58.0000] <Hixie_>
the advantage of web components is more that they are self-contained

[22:46:00.0000] <Hixie_>
modular

[22:49:24.0000] <TabAtkins>
pdr: the page's onload event fires once.  It's appropriate for promises - you just have one promise for the page load, which fulfills when the page loads.

[22:50:13.0000] <TabAtkins>
pdr: Images can load multiple times, which suggests a different strategy - instead, return a new promise each time, which is either already fulfilled (if the image is currently loaded) or will be fulfilled when the image finishes loading (if it's currently loading something, or hasn't yet started loading).

[22:51:03.0000] <TabAtkins>
pdr: Both of these approaches are exemplified in the FontFace and FontFaceSet ready() promises: <http://dev.w3.org/csswg/css-font-load-events/>

[02:19:48.0000] <zcorpan>
JS doesn't have a WeakArray thing yet, right?

[02:20:12.0000] <zcorpan>
maybe that wouldn't make sense

[02:28:13.0000] <zcorpan>
doesn't WeakMap expose GC if you hold the keys in an array and check the values in an interval?

[02:32:59.0000] <jgraham>
It seems that way to me as well

[02:33:53.0000] <rtc>
how can I subscribe to whatwg mailing list?

[02:34:51.0000] <foolip>
rtc, http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org

[02:36:50.0000] <Ms2ger>
zcorpan, wasn't WeakMap weak in the keys?

[02:37:49.0000] <zcorpan>
Ms2ger: yes, but you can't enumerate the keys so if you want to check all the values you've set you need to maintain the keys out of band, afaict

[02:38:33.0000] <annevk>
zcorpan: if you hold the keys in an array they won't be GC'd

[02:38:37.0000] <Ms2ger>
Right

[02:38:47.0000] <zcorpan>
but the values can be GC'ed

[02:38:55.0000] <annevk>
zcorpan: no

[02:39:17.0000] <zcorpan>
no? how does that make sense?

[02:39:19.0000] <annevk>
zcorpan: they have a strong whatever that was called to the key

[02:40:26.0000] <zcorpan>
var keys = [0]; var wm = new WeakMap(); wm.set[0, {}];

[02:40:30.0000] <annevk>
zcorpan: e.g. you could associate some information about nodes in a WeakMap and you don't have to worry about removing that extra data when the node is removed

[02:40:40.0000] <Ms2ger>
Keys need to be objects, no?

[02:41:39.0000] <jgraham>
If the key is a node, then the weakmap will change when GC occurs

[02:41:47.0000] <jgraham>
If that node was deleted

[02:41:55.0000] <jgraham>
So you can tell whether GC occurred

[02:41:59.0000] <jgraham>
What am I missing?

[02:42:00.0000] <annevk>
Ms2ger: correct http://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.set

[02:42:11.0000] <Ms2ger>
How can you tell if the weakmap changed?

[02:42:12.0000] <annevk>
jgraham: how would you tell?

[02:42:32.0000] <annevk>
jgraham: you no longer have the node, so you no longer can look up its value

[02:42:49.0000] <zcorpan>
oh, ok. i thought they key could be anything

[02:44:25.0000] <Ms2ger>
It's basically improved expandos

[02:44:55.0000] <jgraham>
If there isn't any way to tell how big the set is

[02:45:02.0000] <jgraham>
I guess that is probably OK

[02:45:19.0000] <zcorpan>
what i'm pondering is if WeakMap + some API that sends a message to all ports in a WeakMap would be a plausible replacement for PortCollection

[02:45:36.0000] <jgraham>
zcorpan: I think I suggested the smae thing a few days ago

[02:45:42.0000] <jgraham>
It does seem better

[02:46:15.0000] <jgraham>
(of course you could try a timing attack ;)

[02:46:16.0000] <zcorpan>
would you use the port as the key and a dummy value as value?

[02:46:19.0000] <Ms2ger>
/me would need to think if that makes gc observable somehow

[02:46:34.0000] <annevk>
zcorpan: no that doesn't work

[02:46:55.0000] <jgraham>
Surely it's a WeakSet

[02:47:20.0000] <annevk>
zcorpan: e.g. you create this portcollection, set up listeners for the ports, keep sending to the portcollection, you can observe via timing when the ports get collected as the messages are no longer delivered

[02:48:11.0000] <jgraham>
Yeah, I think messaging + weak refs fundamentally make GC observable

[02:49:49.0000] <annevk>
smaug____ and I went through this exercise last weekend

[02:52:00.0000] <zcorpan>
jgraham: i didn't know WeakSet was a thing :-)

[02:53:34.0000] <Ms2ger>
Doesn't seem to be implemented in SM

[02:55:35.0000] <zcorpan>
i thought the use case was for sending messages, not for listening

[02:56:32.0000] <zcorpan>
you can't tell if a message was sent or not, unless that's communicated back in some way

[02:58:34.0000] <annevk>
zcorpan: you can do the whole setup in one global

[02:59:50.0000] <smaug____>
zcorpan: var c = new MessageChannel(); portCollection.add(c.port1); port2.addEventListener("message", function() {alert("boo")});  Then start iterating portCollection send messages

[02:59:57.0000] <smaug____>
at some point port1 won't be there

[03:01:48.0000] <zcorpan>
smaug____: yes, i know

[03:03:45.0000] <zcorpan>
smaug____: i was talking about WeakSet + API to send a message to all ports in the WeakSet

[03:03:56.0000] <smaug____>
and since PortCollection exposes GC this way, it could be used to implement "close" event in  hacky way

[03:04:01.0000] <smaug____>
ah

[03:04:50.0000] <zcorpan>
but that can still expose GC, but requires the other end to cooperate, at least for the only-sending case

[03:05:08.0000] <zcorpan>
afaict

[03:05:26.0000] <zcorpan>
/me -> lunch

[03:50:30.0000] <rtc>
why when I place h1 h2 h3 tags one after another the h1 has smaller font size than h2?

[03:53:52.0000] <rtc>
http://jsfiddle.net/HARj2/ this happens only when they are in section why?

[04:03:13.0000] <zcorpan>
rtc: the default styling shrinks h1 in sections, but doesn't affect h2-h6 (except in hgroup, per spec anyway)

[04:03:35.0000] <rtc>
wwhy?

[04:03:39.0000] <zcorpan>
rtc: if you only use h1 you get the right styling

[04:03:49.0000] <rtc>
but why this happens?

[04:04:13.0000] <rtc>
no h1 alone is with same font size as if there are h2 h3

[04:04:19.0000] <zcorpan>
because it should be possible to only use h1 + sections and get smaller headings for subheadings

[04:04:20.0000] <rtc>
http://jsfiddle.net/HARj2/1/

[04:04:30.0000] <rtc>
http://jsfiddle.net/HARj2/

[04:04:34.0000] <rtc>
compare, they are same

[04:05:36.0000] <zcorpan>
yes? that's the point. did you understand what i wrote?

[04:06:14.0000] <zcorpan>
<h1>foo</h1> <section><h1>bar</h1></section> should have the same rendering as <h1>foo</h1> <h2>bar</h2>

[04:06:55.0000] <rtc>
no

[04:06:56.0000] <rtc>
:S

[04:07:07.0000] <rtc>
but why

[04:07:13.0000] <rtc>
h1 has smaller font size than h2?

[04:08:20.0000] <zcorpan>
<h1>foo</h1> <section><h1>bar</h1></section> means the same thing as <h1>foo</h1> <h2>bar</h2>, and similarly a nested section makes h1 be a third-level heading

[04:08:48.0000] <rtc>
zcorpan,

[04:14:48.0000] <rtc>
zcorpan,  I am confused man :S

[04:15:54.0000] <rtc>
please explain thanks

[04:16:01.0000] <zcorpan>
rtc: ok. so let's back up. the purpose of headings is to give some structure to the document, which can be represented in a "table of contents"

[04:16:30.0000] <zcorpan>
rtc: the table of contents will have nested sections so that e.g. "bar" is a child of "foo"

[04:17:09.0000] <zcorpan>
rtc: in html, this can be marked up in two ways: the old way with only <h1>foo</h1> <h2>bar</h2> and the new way with <h1>foo</h1> <section><h1>bar</h1></section>

[04:17:29.0000] <zcorpan>
does that help?

[04:18:19.0000] <rtc>
sec

[04:18:25.0000] <rtc>
sorry some server problems :D

[04:18:29.0000] <rtc>
let me read thanks man!

[04:18:55.0000] <rtc>
hmmmmmmm

[04:18:56.0000] <rtc>
yess

[04:19:03.0000] <rtc>
so basically in section I should not use h1 and h2 ?

[04:19:05.0000] <rtc>
together?

[04:19:35.0000] <rtc>
headings h1 h2 h3 are not intended for titles - headings in separate parts of a document?

[04:19:38.0000] <rtc>
and subsections?

[04:19:42.0000] <rtc>
only for table of contents?

[04:21:52.0000] <zcorpan>
if you want correct default styling, only use h1 together with sections

[04:22:39.0000] <rtc>
ok

[04:22:55.0000] <rtc>
so withing one seciton I should avoid h1 together with h2 h3 right? :)

[04:23:46.0000] <zcorpan>
can you give an example? i don't follow

[04:27:04.0000] <zcorpan>
do one of these: http://jsfiddle.net/HARj2/

[04:27:40.0000] <zcorpan>
doing something else is allowed but gets more confusing and the default style will probably be wrong

[04:29:55.0000] <zcorpan>
note that the top-level heading should not be in a <section>

[04:30:04.0000] <zcorpan>
the <body> is the top-level section

[04:37:42.0000] <rtc>
zcorpan, sorry one server got problems

[04:37:48.0000] <rtc>
ok

[04:38:23.0000] <rtc>
h1 h2 h3 are intended for tables of contents or for headings too?

[04:41:08.0000] <jgraham>
rtc: They are only intended for headings

[04:41:31.0000] <jgraham>
Headings are loosely defined as "things that would appear in a table of contents"

[04:42:12.0000] <jgraham>
But aren't the actual text of the TOC itself (that would probably be a set of nested <ol>s and <li>s)

[04:45:29.0000] <zcorpan>
right, you would *generate* the table of contents by looking at the headings in the document

[04:45:44.0000] <zcorpan>
not mark up the ToC itself using headings

[04:52:38.0000] <rtc>
so how to make table of contents

[04:52:41.0000] <rtc>
using which elements?

[04:53:03.0000] <rtc>
ok so I guess ol li

[04:53:06.0000] <rtc>
ok

[04:53:10.0000] <rtc>
but stil I am confused

[04:53:12.0000] <rtc>
:S

[04:53:19.0000] <rtc>
why h1 is bigger than h2 in a section

[04:53:19.0000] <rtc>
ok

[04:53:32.0000] <rtc>
so I guess I should not use h1 together with h2 in same section right?

[04:53:45.0000] <rtc>
because I need to use h1 lonely or h2 h3 h4 withouth 1?

[04:53:47.0000] <rtc>
h1*

[04:55:08.0000] <smaug____>
hmm, which spec defines XML fragment serialization algorithm

[04:55:14.0000] <smaug____>
maybe Ms2ger's

[04:55:44.0000] <smaug____>
oh, silly me

[04:55:48.0000] <Ms2ger>
HTML?

[04:56:34.0000] <smaug____>
yes

[04:56:44.0000] <zcorpan>
rtc: no, you either use only h1+section or h1+h2+h3+h4+h5+h6 without section

[04:56:54.0000] <zcorpan>
rtc: not h2-h6 without h1, that doesn't make sense

[04:57:08.0000] <Ms2ger>
I should probably move those bits into my spec

[04:57:28.0000] <rtc>
hm ok

[04:57:34.0000] <rtc>
so no h2 h3 h4 with a section

[04:57:38.0000] <rtc>
well it makes sense

[04:57:46.0000] <rtc>
what if I need heading with subheadings in a section

[04:58:00.0000] <rtc>
oh well I guess I use section with h1 for subheading

[04:58:01.0000] <zcorpan>
you nest another <section>

[04:58:01.0000] <rtc>
:S

[04:58:15.0000] <rtc>
yeah then aanother sub sub heading will be another section in that one right?

[04:58:20.0000] <zcorpan>
yes

[04:59:17.0000] <rtc>
http://jsfiddle.net/HARj2/3/

[04:59:21.0000] <rtc>
HAHA I GOT IT I GOT IT

[04:59:26.0000] <rtc>
is this ok???? ^^

[04:59:28.0000] <rtc>
:D

[04:59:34.0000] <zcorpan>
yep

[04:59:35.0000] <rtc>
thanks man zcorpan  !!!!!!!! thanks

[04:59:42.0000] <zcorpan>
:-)

[04:59:43.0000] <rtc>
finally headings are solved :)

[04:59:50.0000] <rtc>
going webgl now :) hehe

[04:59:57.0000] <rtc>
that will not end up so easy though :))

[05:00:19.0000] <zcorpan>
maybe you can teach me webgl when you've figured it out :-)

[05:00:55.0000] <rtc>
zcorpan, sure !!!!

[05:01:36.0000] <rtc>
I had nice travel, html css javascript php mysql postregsql python c now webgl :D

[05:01:49.0000] <rtc>
I want opengl first than webgl because opengl is superset of webgl

[05:02:04.0000] <rtc>
I think right way for learning is to learn the superset first

[05:57:30.0000] <smaug____>
Ms2ger: so there are no tests for serialization?

[06:05:31.0000] <Ms2ger>
smaug____, there's some at https://github.com/whatwg/domparsing/tree/master/tests

[06:08:09.0000] <smaug____>
Ms2ger: nothing is testing failing serialization?

[06:08:20.0000] <smaug____>
(or how do I run those tests )

[06:09:22.0000] <Ms2ger>
Just https://github.com/whatwg/domparsing/blob/master/tests/innerhtml-01.xhtml

[06:09:48.0000] <smaug____>
that gives me the source code

[06:09:58.0000] <smaug____>
oh, that is such test

[06:10:03.0000] <Ms2ger>
Yeah, you need to clone to run them

[06:10:36.0000] <smaug____>
uh

[06:10:49.0000] <smaug____>
copy paste if faster

[06:10:52.0000] <smaug____>
s/if/is/

[06:11:09.0000] <smaug____>
except that I'd need few scripts too

[06:13:46.0000] <smaug____>
oh, it should have to be cloned to certain place where testharness is available :(

[06:14:19.0000] <Ms2ger>
Or add w3c-test.org/ before the URLs

[06:16:47.0000] <Ms2ger>
Maybe MikeSmith wants to also set up a clone there :)

[06:20:29.0000] <MikeSmith>
I can set up clones as easily as boy scouts setting up pup tents at a jamboree

[06:21:11.0000] <Ms2ger>
With a lot of things falling over?

[06:22:11.0000] <MikeSmith>
yeah, like that

[06:22:27.0000] <MikeSmith>
and taking smoke breaks

[06:35:22.0000] <smaug____>
anyone with a recent IE?

[06:36:17.0000] <wilhelm>
smaug____: I use this: http://browserstack.com

[06:37:18.0000] <smaug____>
ugh, yet another thing which requires registration

[06:38:31.0000] <smaug____>
and it needs Flash :(

[06:38:35.0000] <wilhelm>
And monies. But you get a browser in a browser.

[06:44:57.0000] <annevk>
"I have read the other emails." hmm, mid-aired with darobin!

[06:45:20.0000] <darobin>
/me triggers emergency landing

[06:46:16.0000] <darobin>
annevk: I don't see your side of the mid-air

[06:46:45.0000] <annevk>
I think the way I have my email address set up at the moment is suboptimal and causes random delays :/

[06:46:58.0000] <darobin>
ah, I'll wait then

[06:47:03.0000] <annevk>
It basically routes through my @gmail.com account

[06:47:32.0000] <darobin>
ah, yeah, hops tend to really pile up for email latency

[06:48:05.0000] <annevk>
I'd give Google direct access to the domain, but only if they keep the damn accounts merged

[06:49:01.0000] <annevk>
darobin: if you want RF, why don't you publish a REC?

[06:49:16.0000] <annevk>
darobin: also, are the relevant parties member of the i18n WG?

[06:49:16.0000] <darobin>
annevk: you mean of Encoding?

[06:50:03.0000] <darobin>
the point is certainly to get to Rec; if you're asking me why it can't be done faster that's another question

[06:50:23.0000] <darobin>
my point is about hypocrisy or not — and having reviewed the various moving parts I find none

[06:50:50.0000] <darobin>
can *other* parts be fixed, like shipping Recs faster to get RF faster, then yeah, you're preaching to the choir bro

[06:51:30.0000] <marcosc_>
/me sings like an angel in latin about living standards... 

[06:52:09.0000] <annevk>
darobin: oh also, my email went to a different list

[06:52:18.0000] <annevk>
darobin: because the chairs forked the thread

[06:52:29.0000] <darobin>
marcosc_: it's pretty hard to get IP commitments on living standards; but it would certainly be sweet if we could have LS and then just get commitments on snapshots say once a year

[06:52:42.0000] <darobin>
annevk: that's mid-airing at a distance

[06:52:54.0000] <annevk>
darobin: well, Gmail didn't care :)

[06:53:00.0000] <darobin>
ah, the many, many lists of I18N

[06:53:19.0000] <annevk>
one for each language, oh wait, that's not i18n

[06:53:36.0000] <darobin>
you have to use a different encoding for each

[06:54:33.0000] <darobin>
which group was yours to annevk?

[06:54:59.0000] <annevk>
darobin: public-i18n-core

[06:55:03.0000] <annevk>
http://lists.w3.org/Archives/Public/public-i18n-core/2013OctDec/0005.html

[06:55:53.0000] <darobin>
found it, ta

[06:55:56.0000] <annevk>
(the context is that nobody brought up RF thus far)

[06:56:13.0000] <darobin>
so it doesn't change anything, my response is still right and the final sane word on the topic :)

[06:56:14.0000] <annevk>
so I didn't reply to that, and I kinda gotta go now, so maybe tonight

[06:56:32.0000] <annevk>
darobin: it depends if what you said is the motivation

[06:56:51.0000] <darobin>
the motivation for what?

[06:57:14.0000] <annevk>
for forking

[06:57:23.0000] <darobin>
well what other reason would there be?

[06:57:43.0000] <annevk>
it seems for HTML it's about more

[06:58:02.0000] <annevk>
because the text is actually different in quite a few cases

[06:58:06.0000] <darobin>
I think we both know that the HTML situation is overall way more complicated

[06:58:31.0000] <darobin>
but you may have noted that I've strained as hard as can be to keep things in line and remove the complications there

[06:58:45.0000] <darobin>
for Encoding however (and a lot of other specs) the situation is a lot simpler

[06:59:41.0000] <annevk>
given how Art deals with me there doesn't seem to be much respect for people doing the actual editing

[06:59:49.0000] <annevk>
so for me it's not quite that simple

[06:59:57.0000] <darobin>
well, take your problem up with Art (or with Nokia)

[07:00:18.0000] <darobin>
I would be surprised if Richard and Addison gave you anything other than respect

[07:00:23.0000] <annevk>
Art hasn't replied to my latest email about that

[07:00:35.0000] <darobin>
is that related to Encoding?

[07:00:47.0000] <annevk>
no, about XHR, Fullscreen, etc.

[07:01:22.0000] <darobin>
well, if there is a way in which we could make things work better in good faith, but you're having problems with Art, don't hesitate to ask for intercession

[07:05:11.0000] <MikeSmith>
zcorpan: about the parser hacks, I've not committed the changes and don't have them online anywhere. But I can post the TreeBuilder.java file and diff somewhere

[07:05:30.0000] <zcorpan>
MikeSmith: ok

[07:05:48.0000] <MikeSmith>
all right I'll ping you when I've got it posted

[07:05:56.0000] <zcorpan>
thanks

[07:10:10.0000] <annevk>
darobin: noted

[07:10:48.0000] <annevk>
darobin: happy to have a in-person discussion with a few people at TPAC

[07:20:16.0000] <zcorpan>
smaug____: what does [Pure] mean?

[07:28:41.0000] <Ms2ger>
zcorpan, "doesn't change as long as you don't do anything side-effecty"

[07:38:53.0000] <zcorpan>
i don't understand how making the innerHTML getter not throw makes it [Pure], then

[07:40:06.0000] <Ms2ger>
Well

[07:40:15.0000] <Ms2ger>
If it can throw, it can't be pure

[07:40:36.0000] <zewt>
(why not? doesn't follow any meaning of a pure function that I know of)

[07:41:02.0000] <Ms2ger>
Maybe pure is a bad name... It's used to move the getter call out of loops

[07:41:23.0000] <Ms2ger>
And you don't want to throw before the loop when the access is inside the loop

[07:42:10.0000] <zewt>
i guess that does follow gcc's definition ("no effects except the return value"--changing code flow is an effect)

[07:42:27.0000] <jgraham>
Isn't that "referentially transparent"?

[07:42:54.0000] <zcorpan>
so the motivation is better perf?

[07:43:51.0000] <zcorpan>
is it common to call innerHTML in a loop in XML?

[07:43:57.0000] <zcorpan>
s/call/get/

[07:46:34.0000] <jgraham>
Actually it seems to be "pure" per wikipedia

[07:47:43.0000] <Ms2ger>
zcorpan, can't make it pure in html and not in xml

[07:48:17.0000] <Ms2ger>
And yes, the goal is perf

[07:48:54.0000] <zcorpan>
Ms2ger: yeah i figured that could be problematic

[07:49:21.0000] <zcorpan>
so is it common to get innerHTML in a loop in HTML?

[07:50:32.0000] <darobin>
zcorpan: you mean as in for (...getElementsByTagName...) if (el.innerHTML.indexOf(foo))... ?

[07:50:47.0000] <darobin>
if so, not uncommon yeah

[07:50:52.0000] <darobin>
IME at least

[08:00:37.0000] <zcorpan>
/me greps for "].innerHTML."

[08:07:10.0000] <zcorpan>
some matches are like document.getElementsByTagName("TITLE")[0].innerHTML.substring(0,100)) but others are indeed in a loop like if(tags[x].innerHTML.indexOf("href")> -1)

[08:09:09.0000] <zewt>
(sadface to both)

[08:09:33.0000] <jgraham>
Not sure why that's a sadface

[08:09:49.0000] <jgraham>
Well the first one is a bit silly

[08:10:23.0000] <zcorpan>
175 matches

[08:10:27.0000] <jgraham>
And the second one is probably not super-fast, but pulling the innerHTML out of the loop in that case might be a microoptimisation

[08:10:35.0000] <jgraham>
That isn't worth it

[08:10:52.0000] <zewt>
indexOf("href") seems pretty sadface

[08:11:03.0000] <jgraham>
Oh, that part

[08:11:06.0000] <jgraham>
Well yeah

[08:11:13.0000] <jgraham>
I'll agree with that

[08:11:17.0000] <zewt>
if that's a loop over [x] then it's calling it on a separate thing on each call, so it wouldn't be able to pull it out anyway

[08:11:25.0000] <jgraham>
I was about to say

[08:11:40.0000] <jgraham>
I should apparently stop talking because I keep being wrong

[08:11:42.0000] <zcorpan>
this is the june data set (53,000 pages)

[08:13:17.0000] <zcorpan>
zewt: good point

[08:21:48.0000] <bholley>
Hixie_: ping

[08:33:03.0000] <zcorpan>
so just "\.innerHTML\." is 291 matches. looking through them i don't see anything that is calling innerHTML on a single element in a loop

[08:34:27.0000] <zcorpan>
so it's not clear to me that it's actually common

[08:35:50.0000] <zcorpan>
that said, i don't really object to changing innerHTML to not throw, if the argument is shorter path to interop and better perf in an uncommon case

[08:36:21.0000] <zcorpan>
next stop: örebro

[08:36:35.0000] <jgraham>
Not sure if it is true in this case, but it could be in a benchmark

[08:36:44.0000] <jgraham>
and oh, he got off the train

[08:37:25.0000] <jgraham>
(the point being that if there is a dumb benchmark there is significant pressure to keep the fast behaviour even if it is not a common case in the real world)

[08:39:02.0000] <annevk>
Utrecht here

[08:40:37.0000] <annevk>
what would you do in XML though?

[08:40:37.0000] <annevk>
return null?

[08:40:37.0000] <annevk>
should we start annotating exceptions in IDL?

[08:40:37.0000] <annevk>
I need to ask bz again what the benefit is

[08:40:44.0000] <annevk>
also, we should prolly first sort out exceptions

[08:40:44.0000] <annevk>
:/

[09:04:45.0000] <zcorpan>
returning null seems like it makes it harder to debug the error

[09:07:23.0000] <MikeSmith>
zcorpan: https://github.com/validator/htmlparser/commit/888fba3fe33c9b0fb0df76189b9d549eae176833

[09:07:40.0000] <MikeSmith>
zcorpan: full Treebuilder.java source is at https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java

[09:07:54.0000] <zcorpan>
MikeSmith: thanks!

[09:09:21.0000] <zcorpan>
MikeSmith: after after body already did the "right" thing

[09:09:30.0000] <MikeSmith>
oh

[09:09:44.0000] <zcorpan>
not in the spec but in the impl

[09:09:49.0000] <MikeSmith>
ah

[09:12:00.0000] <zcorpan>
i don't know how but the /parsetree/ result obviously put the comment in body

[09:16:06.0000] <MikeSmith>
must be some other magic in there

[09:20:56.0000] <zcorpan>
MikeSmith: do you need to flush before pop?

[09:21:16.0000] <darobin>
zcorpan: traditionally it's done in the other order

[09:21:18.0000] <zcorpan>
MikeSmith: or do them together

[09:21:20.0000] <darobin>
/me really, really sorry

[09:21:49.0000] <zcorpan>
darobin: ?

[09:21:59.0000] <darobin>
really, nevermind

[09:22:16.0000] <zcorpan>
k :-)

[09:22:52.0000] <zcorpan>
MikeSmith: https://github.com/validator/htmlparser/commit/888fba3fe33c9b0fb0df76189b9d549eae176833#diff-82f1ed4c3b29018e8cae550a4c376b5eR1165

[09:22:58.0000] <MikeSmith>
zcorpan: I can try and see if it makes any different

[09:28:36.0000] <MikeSmith>
zcorpan: so yeah it makes no difference as far as the runtime failure

[09:28:49.0000] <zcorpan>
ok

[09:28:52.0000] <MikeSmith>
it's still failing at https://github.com/validator/htmlparser/commit/888fba3fe33c9b0fb0df76189b9d549eae176833#diff-82f1ed4c3b29018e8cae550a4c376b5eR1165

[09:29:52.0000] <MikeSmith>
um no not there

[09:31:46.0000] <MikeSmith>
https://github.com/validator/htmlparser/commit/888fba3fe33c9b0fb0df76189b9d549eae176833#diff-82f1ed4c3b29018e8cae550a4c376b5eL2889

[09:44:20.0000] <dglazkov>
good morning, Whatwg!

[09:44:50.0000] <smaug____>
How could we make sure that people don't look at a TR/ spec when there is a newer editor's draft

[09:45:18.0000] <smaug____>
asking w3c to change TR/ to Trash/ might not be quite nice

[09:50:43.0000] <TabAtkins>
zcorpan, Ms2ger: I don't think WeakSet exists in ES yet, but it's one of those things that everyone assumes will happen soon, since it's just a nice convenience API over WeakMap with dummy values.

[09:51:07.0000] <smaug____>
hmm, what is the usecase for WeakSet?

[09:51:15.0000] <Ms2ger>
TabAtkins, http://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakset-objects

[09:53:46.0000] <zewt>
"An implementation may impose an arbitrarily determined latency" ... very strangely written text

[09:55:34.0000] <zewt>
making me squint reading it to figure out that they're talking about GC, instead of just saying so

[09:56:13.0000] <zewt>
smaug____: not sure that there are ever strictly use cases for sets in addition to maps, typically it's just convenience

[09:57:27.0000] <TabAtkins>
Ms2ger: Welp, I'm wrong. They're totally specced.

[09:57:28.0000] <smaug____>
well, there are plenty of use cases for normal sets, but weakset is very different beast

[09:57:45.0000] <TabAtkins>
smaug____: Same use-case as Set over Map.  A Set is nothing more than a Map with a dummy value and a more convenient API.

[09:58:14.0000] <TabAtkins>
It's for "I want to make a set of things for some reason, but don't want this to cause memory-leaks".

[09:58:15.0000] <smaug____>
sure, but WeakSet is very different from a Set

[09:58:34.0000] <smaug____>
you need to still keep reference to the key

[09:58:41.0000] <TabAtkins>
WeakSet is basically a branding mechanism.

[09:58:48.0000] <smaug____>
no iteration or anything

[09:59:06.0000] <TabAtkins>
You can throw things into a WeakSet to indicate that they have some hidden, unforgeable property.

[10:00:00.0000] <TabAtkins>
Doing so with a Set, obviously, would leak like a sieve.

[10:00:06.0000] <smaug____>
sure

[10:00:28.0000] <TabAtkins>
But yeah, the only thing you can do with a WeakSet is put things in it, and check if something is in it.

[10:00:33.0000] <TabAtkins>
Those are still useful operations.

[10:02:42.0000] <smaug____>
WeakMap is just so close...

[10:02:50.0000] <smaug____>
but ok, that is a use case

[10:04:24.0000] <smaug____>
Ms2ger: so, what do you think of W3C Bug 23460

[10:05:32.0000] <Ms2ger>
smaug____, I'm fine either way

[10:05:49.0000] <TabAtkins>
smaug____: And Map is so close to Set. ^_^  But having the ability to union/intersect/etc is worth the pain of essentially just having syntax sugar over a Map.

[10:07:31.0000] <Ms2ger>
TabAtkins, oh, and here I thought you always wore ties to csswg meetings

[10:07:53.0000] <TabAtkins>
Ms2ger: Nope, just on Fridays.

[10:08:02.0000] <smaug____>
Ms2ger: well, the question is should we spec the reality, or something that we hope browsers to do

[10:08:15.0000] <TabAtkins>
By the way, still disappointed I only got to see you through a window in a door. :/

[10:08:43.0000] <Ms2ger>
TabAtkins, not like I was hiding during the break...

[10:08:56.0000] <Ms2ger>
smaug____, has anyone tested IE already?

[10:09:07.0000] <TabAtkins>
Sure you were! By the time I was done talking about colors, you'd run away.

[10:09:40.0000] <smaug____>
Ms2ger: I did, using that browserstack thing

[10:10:06.0000] <smaug____>
hmm, but, we need to define the algorithm somewhere

[10:10:11.0000] <Ms2ger>
smaug____, I'll go with not throwing, then

[10:10:19.0000] <Ms2ger>
Hixie_, ping

[10:10:30.0000] <smaug____>
HTML spec's XML serialization is used elsewhere too, I think

[10:13:19.0000] <Ms2ger>
I think xhr used to use it directly?

[10:16:34.0000] <smaug____>
Ms2ger: http://domparsing.spec.whatwg.org/#innerhtml points to HTML spec's XML serialization, http://xhr.spec.whatwg.org/#dom-xmlhttprequest-send points to http://domparsing.spec.whatwg.org/#concept-serialize which points to http://domparsing.spec.whatwg.org/#concept-serialize-xml

[10:17:01.0000] <Ms2ger>
Right

[10:17:39.0000] <smaug____>
which is somewhat odd

[10:18:05.0000] <smaug____>
but anyhow, this change could all be done in the domparsing spec

[10:19:18.0000] <Ms2ger>
But then we should remove the bit from HTML, if nobody else uses it

[10:20:29.0000] <smaug____>
Ms2ger: we use it for Document, I think

[10:20:39.0000] <Ms2ger>
Hmm?

[10:20:53.0000] <smaug____>
http://domparsing.spec.whatwg.org/#concept-serialize-xml Document part links to HTML spec

[12:22:19.0000] <zcorpan>
MikeSmith: https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2534

[12:27:09.0000] <zcorpan>
also https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2478

[12:28:27.0000] <zcorpan>
https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2886

[12:30:12.0000] <zcorpan>
MikeSmith: the spec has "act as if in body" language for e.g. <html> in head that v.nu parser has inline

[12:34:53.0000] <zcorpan>
MikeSmith: https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L4019 also looks wrong (for </head><style></style>...)

[12:35:46.0000] <zcorpan>
or rather https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L4021

[12:39:49.0000] <zcorpan>
need pop() here? https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2981

[13:04:21.0000] <jgraham>
function add2(a, b) {

[13:04:21.0000] <jgraham>
  return Task.spawn(function () {

[13:04:22.0000] <jgraham>
    let sum = yield a + b;

[13:04:22.0000] <jgraham>
    throw new Task.Result(sum);

[13:04:22.0000] <jgraham>
  });

[13:04:38.0000] <jgraham>
} I for one welcome our new ES6 overlords

[13:05:24.0000] <jgraham>
(hopefully that's just some perversion in that library)

[13:05:33.0000] <jgraham>
(but oh boy is it ugly)

[13:09:12.0000] <jsbell>
Never look at the implementation details of coroutines. *shudder*

[13:10:27.0000] <jgraham>
But this is supposed to be user-level code!

[13:13:26.0000] <jsbell>
I think it's proof that while generators enable you to implement such things, without syntax to support it no mere mortal should be expected to do it.

[13:30:33.0000] <annevk>
http://www.ietf.org/mail-archive/web/json/current/msg01783.html lol, also :/

[13:31:36.0000] <annevk>
jgraham: only yield is in ES6

[13:43:52.0000] <zcorpan>
jgraham: throw? that looks weird...

[13:49:22.0000] <TabAtkins>
jgraham: Where's that example from? "yield a+b" in Task is completely worthless, because "a+b" doesn't return a Task.

[13:49:29.0000] <TabAtkins>
That's just inserting useless asynchrony.

[13:50:18.0000] <TabAtkins>
But yeah, I suspect in ES7 we'll get sugar for this stuff, since fully async functions are just generators + a CPS transform.

[13:51:10.0000] <TabAtkins>
function^ add2(a,b) { let sum = await a+b; return sum; }, or something like that.  Automatically returns a promise for the return value.

[13:52:50.0000] <smaug____>
slightlyoff: is there any API for https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md stuff?

[13:53:03.0000] <smaug____>
really hard to understand that all without seeing interfaces

[13:53:55.0000] <jgraham>
TabAtkins: It's from mozilla.dev.platform

[13:54:00.0000] <Domenic_>
jgraham: I think that is Mozilla generator stuff, that is the only way it makes sense

[13:54:04.0000] <Domenic_>
not ES6 generators

[13:54:14.0000] <jsbell>
smaug____ (give or take a _): look at https://github.com/slightlyoff/ServiceWorker/blob/master/service_worker.ts

[13:54:38.0000] <jsbell>
Per the guy sitting next to me who's implementing ServiceWorker that's the closest thing to an API doc at the moment

[13:54:58.0000] <smaug____>
ahaa

[13:55:24.0000] <smaug____>
using some odd form of idl

[13:55:36.0000] <jsbell>
ts = TypeScript apparently

[13:55:38.0000] <smaug____>
or perhaps that is some es thing

[13:55:43.0000] <smaug____>
ah, hm, right

[14:14:19.0000] <miketaylr>
zcorpan: http://simon.html5.org/specs/quirks-mode -> https://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.html -> "error: Overview.html@936eae1aa829: not found in manifest"

[14:15:07.0000] <zcorpan>
miketaylr: http://quirks.spec.whatwg.org

[14:15:36.0000] <miketaylr>
zcorpan: thanks. possible to update the link on the "This document has been superseded. See http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.html. " message?

[14:15:38.0000] <jgraham>
Domenic_: Ah, I assumed they were compatible

[14:16:43.0000] <Domenic_>
generally Mozilla's stuff is pretty far off from ES6... :-/

[14:17:02.0000] <zcorpan>
miketaylr: maybe

[14:17:33.0000] <matjas>
or just 301 to quirks.spec.whatwg.org

[14:17:44.0000] <miketaylr>
yeah or meta refresh :P

[14:18:02.0000] <zcorpan>
i'll just <marquee> the message

[14:18:46.0000] <miketaylr>
wfm.

[14:18:53.0000] <matjas>
ah, the good ol’ special miketaylr treatment

[14:20:55.0000] <yoav>
TabAtkins: You around?

[14:21:01.0000] <TabAtkins>
yoav: pong

[14:21:35.0000] <pdr>
TabAtkins, more srcset questions :)

[14:21:41.0000] <yoav>
Hey! I've got a question regarding srcset/srcN, intrinsic size and natural dimensions.

[14:22:14.0000] <yoav>
Do naturalWidth/naturalHeight return the real natural dimensions, or the corrected intrinsic dimensions?

[14:22:40.0000] <TabAtkins>
Where are those defined?  I know those properties exist, but I'm not familiar with them.

[14:22:41.0000] <pdr>
(See: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#dom-img-naturalwidth)

[14:22:47.0000] <TabAtkins>
Thanks, pdr. ^_^

[14:23:23.0000] <TabAtkins>
The intrinsic width and height of <img>s are corrected by the chosen resolution multiplier.  Pretty sure this is specified for srcset in HTML, and it's an oversight I haven't yet corrected in srcN.

[14:24:37.0000] <pdr>
Just to be extra concrete, <img srcset="100x100.png 2x"> would have an intrinsic size of 50x50, a natural size of 50x50, and an actual size of 50x50. There is no way to access the original 100x100 dimensions via javascript

[14:25:05.0000] <Hixie_>
bholley: poing

[14:25:14.0000] <pdr>
Is that correct?

[14:25:17.0000] <TabAtkins>
Yes.

[14:25:20.0000] <bholley>
Hixie_: too late at this point in the French evening ;-)

[14:25:27.0000] <bholley>
Hixie_: but tomorrow, if that works for you

[14:25:27.0000] <zcorpan>
pdr: what do you mean by natural and actual?

[14:25:31.0000] <Hixie_>
bholley: sure thing

[14:25:38.0000] <bholley>
Hixie_: cool

[14:25:50.0000] <pdr>
zcorpan, nautral is defined in the link above. Actual is the dimensions that the image gets in the dom

[14:27:28.0000] <zcorpan>
pdr: naturalWidth returns the intrinsic width, so yeah

[14:27:40.0000] <zcorpan>
pdr: i don't follow "gets in the dom"

[14:28:09.0000] <pdr>
yeah, we were just making extra sure as we implement this in Blink. By "gets in the dom" I just mean what image.width returns

[14:28:17.0000] <TabAtkins>
yoav: Okay, it's now specified in the spec.

[14:28:38.0000] <yoav>
TabAtkins: Awesome!

[14:28:41.0000] <TabAtkins>
pdr: ...assuming that the author doesn't specify width='', etc.

[14:28:56.0000] <zcorpan>
pdf: ok. then img.width can return something else, because it returns the rendered width, which can be set by CSS

[14:29:13.0000] <TabAtkins>
zcorpan: No, img.width doesn't care about CSS, iirc.

[14:29:18.0000] <zcorpan>
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#dom-img-width

[14:29:29.0000] <zcorpan>
yes it does :-P

[14:29:32.0000] <TabAtkins>
Whoops, never mind.

[14:29:42.0000] <TabAtkins>
Yeah, that's right, that's why .naturalWidth/Height exist.

[14:30:01.0000] <pdr>
Lets walk through that example. <img srcset="100x100.png 2x" width="5" height="5">. This will have an intrinsic size of 50x50, a natural size of 50x50, and an image size of 5x5, if I understand correctly

[14:30:11.0000] <TabAtkins>
Yup.

[14:30:35.0000] <TabAtkins>
naturalWidth/Height is just the name of the properties.  It's defined as returning the intrinsic width/height.

[14:30:35.0000] <zcorpan>
well, it would be reasonable for width/height to reflect the width/height attributes, like all other HTML elements with width/height attributes, but <img> is special

[14:30:42.0000] <TabAtkins>
There's no separate notion of "natural width/height".

[14:31:16.0000] <yoav>
TabAtkins: OK. So intrinsic==natural.

[14:32:09.0000] <zcorpan>
naturalWidth just has a stupid name because it was implemented before it was specced :-)

[14:32:47.0000] <zcorpan>
(<video> has videoWidth, btw)

[14:33:25.0000] <zcorpan>
(which might also be a stupid name, but for a different reason. iirc videoWidth predated naturalWidth in the spec.)

[14:34:46.0000] <zcorpan>
pdr: also, for completeness, <img srcset="100x100.png 2x" width="5" height="5" style="width:10px; height:10px"> would have an image size of 10x10

[14:35:24.0000] <pdr>
zcorpan, that's a great point, thank you

[14:35:49.0000] <zcorpan>
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#dom-img-width also has different rules for when the image isn't actually rendered

[14:46:12.0000] <zcorpan>
miketaylr: fixed

[14:46:36.0000] <miketaylr>
zcorpan: gracias

[15:13:11.0000] <zcorpan>
so speaking of json, i recall when we implemented json support in carakan, everyone did their own thing and we tried to follow the spec to the letter but had to derivate for some things because of web compat

[15:13:22.0000] <zcorpan>
i wonder what the situation is today

[15:13:36.0000] <zcorpan>
i guess the spec hasn't changed because it MUST NOT CHANGE

[15:15:27.0000] <annevk_>
All this fuss about JSON and it still doesn't support comments.

[15:15:56.0000] <zcorpan>
(or maybe it was before carakan)

[15:16:10.0000] <annevk>
zcorpan: yeah, that argument seems to be repeated a lot.

[15:33:27.0000] <zcorpan>
"JSON can't change since it's not versioned.", no, it can't change because people believe that it can't change

[15:43:03.0000] <Hixie_>
that's a pretty funny thing to say since we stopped versioning HTML precisely to make it easier to change :-P


2013-10-09
[17:02:07.0000] <jamesr__>
does ECMA-262 provide a web-compatible definition of JSON?

[17:02:43.0000] <jamesr__>
it defers *mostly* to http://www.ietf.org/rfc/rfc4627.txt

[17:09:57.0000] <zewt>
seems like a spec that's published in PDF is inherently incompatible with the web

[17:10:09.0000] <jamesr__>
there's an html version of ECMA262

[17:11:12.0000] <zewt>
oh, they have PDF in a big bold table, then html quietly in prose underneath it; strange

[17:15:37.0000] <zewt>
http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.3 it's nice that they're defining it algorithmically, but ouch

[17:22:30.0000] <zewt>
rfc4627 says to \u1234-escape UTF-16; looks like ecma-262 says to just return the surrogate, which appears to be what Chrome does

[17:23:14.0000] <zewt>
... which is strange, actually, since it means to get "conforming" utf-16 you need to do postprocessing to escape non-bmp characters, you can't just dump the result into a utf-8 encoder

[17:24:02.0000] <zewt>
(i wonder how much of the web actually depends on JSON escaping non-BMP characters, which is pretty nasty)

[17:24:38.0000] <zewt>
i guess I should say how much software, given that JSON.stringify *doesn't* escape them

[18:13:49.0000] <aleray>
hi, I'm having an error with this code: http://dpaste.com/1410324/

[18:14:37.0000] <aleray>
All strings must be XML compatible: Unicode or ASCII, no NULL bytes or control characters

[18:15:01.0000] <aleray>
problem is I have no control over the input, so this character pops up from time to time, I don't know why

[18:16:19.0000] <MikeSmith>
aleray: sounds like you need to preprocess the input

[18:17:17.0000] <aleray>
MikeSmith, I found the error. Stupid me

[18:18:44.0000] <aleray>
not sure actually, but good thinking

[18:41:02.0000] <aleray>
MikeSmith, yes it was this: "SPACE_REGEX.sub(u'\u2026 \1', text) to "SPACE_REGEX.sub(ur'\u2026 \1', text)"

[18:41:17.0000] <MikeSmith>
ok

[18:41:18.0000] <aleray>
it was introducing the \x01 control character

[18:44:06.0000] <MikeSmith>
I see

[21:21:09.0000] <Hixie_>
is there no way to position a background image's right edge 1em from the right edge of the background-origin ?

[00:35:34.0000] <zcorpan>
"ECMAScript 3 has literals (or at least initializers) for every type but timestamps. Having timestamp literals would probably help dissuade developers from the current practice of passing some (often) random string to Date.parse and ask it to figure out what it means. Since the input syntax to that function is not defined in the spec, this practice is is evil." http://wiki.ecmascript.org/doku.php?id=proposals:date_literal_

[00:35:34.0000] <zcorpan>
syntax

[00:35:53.0000] <zcorpan>
...why not define the input syntax for Date()?

[00:36:42.0000] <Ms2ger>
That's Work

[01:52:54.0000] <annevk>
matjas: should prolly list that as an open issue in http://javascript.spec.whatwg.org/#date

[01:53:57.0000] <zcorpan>
jgraham: https://critic.hoppipolla.co.uk/r/348 y no tracking?

[02:46:18.0000] <SimonSapin>
Hixie_: 'right 1em top 14px'

[02:47:33.0000] <SimonSapin>
full grammar: http://www.w3.org/TR/css3-background/#ltpositiongt

[02:51:51.0000] <Ms2ger>
odinho, good to hear that you like wptserve :)

[03:06:24.0000] <smaug____>
 drawCustomFocusRing is oddly named. It may not draw anything

[03:07:51.0000] <zcorpan>
maybeDrawCustomFocusRing?

[03:08:58.0000] <smaug____>
I guess it should be split to two methods

[03:09:09.0000] <smaug____>
canDraw...

[03:09:19.0000] <smaug____>
hmm

[03:09:31.0000] <smaug____>
perhaps there should be just canDraw...

[03:09:39.0000] <smaug____>
and drawSystemFocus..

[03:12:44.0000] <jgraham>
smaug____: Re: ServiceWorker and .ts, I read that as "we won't write a spec or use WebIDL because fuck you"

[03:13:38.0000] <smaug____>
ha

[03:14:18.0000] <jgraham>
zcorpan: Not tracking because the author did a rebase

[03:14:19.0000] <smaug____>
I thought more like: we use this hard to read way so than no one can comment on the API design

[03:14:41.0000] <jgraham>
smaug____: I think that amounts to the same thing

[03:15:36.0000] <jgraham>
zcorpan: (or, more precisely, I think they did an in-place history rewrite)

[03:17:24.0000] <Ms2ger>
What's this ServiceWorker thing?

[03:18:29.0000] <annevk>
Ms2ger: new NavigationController

[03:18:45.0000] <Ms2ger>
Oh, new new new appcache?

[03:19:34.0000] <smaug____>
yeah. and it is being implemented even though the proposal doesn't even have webidl for the interfaces :/

[03:19:44.0000] <smaug____>
(makes it hard to help the on who is implementing it)

[03:19:50.0000] <smaug____>
s/on/one/

[03:20:08.0000] <jgraham>
Ms2ger: Think of it as Google Gears for the 2010s

[03:20:09.0000] <annevk-cloud>
could contribute some IDL to the repo

[03:20:23.0000] <annevk-cloud>
I can do that next week somewhere

[03:20:30.0000] <annevk-cloud>
would that help, smaug____ ?

[03:20:41.0000] <smaug____>
webidl would help, yes

[03:20:45.0000] <jgraham>
Only if it was the canonical version

[03:20:52.0000] <jgraham>
Otherwise it will drift out of date

[03:21:01.0000] <smaug____>
now I have basically no idea what kind of odd event interface the thing has

[03:21:09.0000] <smaug____>
I know they are something very unusual

[03:21:12.0000] <Ms2ger>
Futures

[03:21:32.0000] <smaug____>
it has some odd mix of events and promises

[03:23:09.0000] <smaug____>
/me is too negative

[03:24:16.0000] <Ms2ger>
You'd never

[03:24:27.0000] <odinho>
Ms2ger #)

[03:25:08.0000] <Ms2ger>
(I don't see you around a lot anymore)

[03:26:00.0000] <smaug____>
all I want is little consistency, also in API design :)

[03:36:44.0000] <annevk-cloud>
smaug____: I think that goes for the people involved in designing that too

[03:37:38.0000] <MikeSmith>
krijnh: http://krijnhoetmer.nl/irc-logs/whatwg don't seem to be responding

[03:38:50.0000] <smaug____>
annevk-cloud: sorry, I shouldn't be so negative, but it was just surprising to see an "API proposal" which didn't define the API in any common way

[03:39:23.0000] <annevk-cloud>
it coming from the people that don't like IDL, that kinda makes sense

[03:40:18.0000] <smaug____>
but even then it is missing lots of the API

[03:40:39.0000] <Ms2ger>
So if that's the kind of spec they want to see...

[03:40:47.0000] <smaug____>
and the definition of various things is just still wrong, but I guess that is expected when the spec is so early draft

[03:40:49.0000] <jgraham>
annevk-cloud: "I don't like WebIDL so I am going to be purposefully obstructive and use my own invented format" is kind of childish

[03:40:58.0000] <smaug____>
indeed

[03:41:39.0000] <annevk-cloud>
jgraham: I'm not sure why you'd interpret the motivation like that

[03:41:55.0000] <jgraham>
annevk-cloud: You just *said* that was the motivation

[03:42:00.0000] <annevk-cloud>
jgraham: from comments given thus far it seems pretty clear they want to figure out the API in terms of JavaScript first, and IDL second

[03:42:32.0000] <annevk-cloud>
jgraham: no, I was just describing a group of people

[03:44:06.0000] <jgraham>
I don't understand what distinction you are trying to make. But this approach increases the barrier to entry for giving feedback and makes implementation very challenging and likely to suffer from interop problems

[03:44:30.0000] <smaug____>
yeah, the current spec isn't anything for implementors

[03:44:57.0000] <smaug____>
you'll get random interfaces added to implementations

[03:45:03.0000] <jgraham>
Which perhaps wouldn't matter if this was really an early stage and no one was trying to implement

[03:45:08.0000] <jgraham>
But it isn't and they are

[03:45:58.0000] <annevk>
*shrug*

[03:50:16.0000] <MikeSmith>
if anybody has some time to help me with idlharness.js tests for the Notifications spec, https://critic.hoppipolla.co.uk/r/349

[04:19:42.0000] <MikeSmith>
got to admire the honesty in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23260#c12

[04:44:11.0000] <zcorpan>
where does the svg spec say which elements implement SVGElement?

[04:47:11.0000] <MikeSmith>
zcorpan: "All of the SVG DOM interfaces that correspond directly to elements in the SVG language (such as the SVGPathElement interface for the ‘path’ element) derive from the SVGElement interface."

[04:47:26.0000] <MikeSmith>
so does that mean.. All of the elements?

[04:47:51.0000] <MikeSmith>
all of the elements which have SVG DOM interfaces

[04:47:51.0000] <zcorpan>
MikeSmith: no, that just says that SVGFooElement inherits from SVGElement

[04:48:03.0000] <zcorpan>
MikeSmith: it doesn't say anything about which elements implement SVGElement

[04:48:15.0000] <zcorpan>
other than <path>, i guess

[04:48:32.0000] <zcorpan>
and the elements that have an interface that inherits from SVGElement

[04:49:33.0000] <MikeSmith>
yeah. You want the ones that actually just use SVGElement? instead of some other interface that inherits from it?

[04:50:13.0000] <zcorpan>
i want to know what interface this element is supposed to use: <foobarbaz xmlns='http://www.w3.org/2000/svg'/>

[04:51:10.0000] <zcorpan>
all elements that are defined in svg say what interface they use, but i don't find any statement covering unknown elements in the svg namespace

[04:51:38.0000] <MikeSmith>
ah

[04:53:48.0000] <zcorpan>
html says "The HTMLUnknownElement interface must be used for HTML elements that are not defined by this specification (or other applicable specifications)."

[04:54:06.0000] <zcorpan>
blink and gecko appear to use SVGElement for unknown elements in the svg namespace

[04:54:21.0000] <zcorpan>
i'll file a bug on svg

[04:56:35.0000] <MikeSmith>
zcorpan: well I tried reading

[04:56:59.0000] <MikeSmith>
enough to know that http://www.w3.org/TR/SVG/single-page.html#svgdom-ElementsInTheSVGDOM doesn't help answer

[04:59:09.0000] <zcorpan>
well if it doesn't say anything, then i guess it means that it must use the Element interface. but that doesn't match reality

[05:56:44.0000] <Ms2ger>
krijn, down again?

[05:58:56.0000] <MikeSmith>
Ms2ger: seems so

[05:59:32.0000] <MikeSmith>
speaking of which I was trying to read the logs for when zcorpan pinged me yesterday about the parser

[05:59:53.0000] <MikeSmith>
zcorpan: I wasn't sure what you wanted me to try changing

[06:00:02.0000] <MikeSmith>
/me re-read local logs

[06:00:24.0000] <zcorpan>
http://logbot.glob.com.au/?c=freenode%23whatwg has logs

[06:00:39.0000] <krijnh>
Ms2ger: hm, no, but my hdd is full :D

[06:01:35.0000] <zcorpan>
MikeSmith: so i found bugs, you hadn't properly implemented my proposal because the v.nu parser's structure isn't a 1:1 mapping to the spec

[06:02:46.0000] <krijnh>
Ms2ger, MikeSmith: should be up again

[06:02:54.0000] <MikeSmith>
zcorpan: right that's what makes it harder to just quickly hack in changes

[06:03:22.0000] <Ms2ger>
Ta

[06:03:24.0000] <MikeSmith>
krijnh: thanks

[06:03:34.0000] <zcorpan>
(1) https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2534 should be commented out

[06:03:58.0000] <MikeSmith>
/me commenting out now

[06:04:46.0000] <zcorpan>
(2) https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2478 should be commented out

[06:05:08.0000] <zcorpan>
(3) https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2886 should be commented out

[06:05:34.0000] <zcorpan>
(4) https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L4021 should be commented out

[06:06:17.0000] <zcorpan>
(5) https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2981 add pop() before this line

[06:06:43.0000] <zcorpan>
that's all i found by looking at the code

[06:08:10.0000] <zcorpan>
well, and the changes to after after foo could be reverted since the it wasn't broken

[06:10:32.0000] <MikeSmith>
zcorpan: all the after after changes?

[06:12:20.0000] <zcorpan>
MikeSmith: the stuff up to line 930 in https://github.com/validator/htmlparser/commit/888fba3fe33c9b0fb0df76189b9d549eae176833 i think

[06:12:36.0000] <MikeSmith>
ok

[06:21:24.0000] <MikeSmith>
zcorpan: pushed to https://github.com/validator/htmlparser/commit/4924b651bc023ae080e99501eda473e5de510d3b but still fails at runtime due the same problem I mentioned

[06:21:44.0000] <MikeSmith>
I hope Henri will take an interest at some point

[06:22:19.0000] <MikeSmith>
in the mean time I'll make time later to try to figure out if I can make it work

[06:22:26.0000] <zcorpan>
MikeSmith: ok. what markup are you running to test?

[06:22:36.0000] <MikeSmith>
the HTML spec

[06:22:58.0000] <zcorpan>
single-page?

[06:23:02.0000] <MikeSmith>
yeah

[06:23:30.0000] <MikeSmith>
the validator tries to parse that at startup to extract the attribute information

[06:24:38.0000] <zcorpan>
ok so that sees <body> IN_HEAD

[06:26:11.0000] <MikeSmith>
right

[06:27:50.0000] <zcorpan>
so goes through https://github.com/validator/htmlparser/blob/4924b651bc023ae080e99501eda473e5de510d3b/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2531

[06:27:52.0000] <zcorpan>
and then https://github.com/validator/htmlparser/blob/4924b651bc023ae080e99501eda473e5de510d3b/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2888

[06:28:15.0000] <zcorpan>
at least now it doesn't pop() twice

[06:28:25.0000] <MikeSmith>
yeah

[06:28:38.0000] <zcorpan>
but i don't know why it fails

[06:30:49.0000] <MikeSmith>
zcorpan: relevant part of the stack trace is https://gist.github.com/sideshowbarker/6901293

[06:31:18.0000] <zcorpan>
hmm, might have missed flush/pop here https://github.com/validator/htmlparser/blob/4924b651bc023ae080e99501eda473e5de510d3b/src/nu/validator/htmlparser/impl/TreeBuilder.java#L4004

[06:31:51.0000] <MikeSmith>
ok will add that

[06:36:43.0000] <zcorpan>
but that's for end tags so won't change the case at hand

[06:41:38.0000] <zcorpan>
MikeSmith: hmm, the trace is weird, it goes through https://github.com/validator/htmlparser/blob/4924b651bc023ae080e99501eda473e5de510d3b/src/nu/validator/htmlparser/impl/TreeBuilder.java#L5067 but the html spec has attributes on the <body>

[06:43:40.0000] <MikeSmith>
hmm yeah hang on

[06:44:01.0000] <MikeSmith>
I've actually been running it with the W3C version of the spec

[06:44:37.0000] <MikeSmith>
(build switch)

[06:44:45.0000] <zcorpan>
url?

[06:46:12.0000] <niloy>
hey guys, is this the right place to talk about "for" attribute?

[06:46:29.0000] <jgraham>
Potentially

[06:47:23.0000] <niloy>
well I am facing this problem, I am creating a label and checkbox from javascript, I want to tie them up with "for", but "for" requires string only

[06:47:42.0000] <zcorpan>
MikeSmith: (url to the w3c version of the spec, that is)

[06:48:07.0000] <MikeSmith>
zcorpan: trace with non-W3C version says

[06:48:08.0000] <MikeSmith>
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1 at nu.validator.htmlparser.impl.TreeBuilder.appendToCurrentNodeAndPushElement(TreeBuilder.java:5129) at nu.validator.htmlparser.impl.TreeBuilder.appendToCurrentNodeAndPushBodyElement(TreeBuilder.java:5064) at nu.validator.htmlparser.impl.TreeBuilder.appendToCurrentNodeAndPushBodyElement(TreeBuilder.java:5069)

[06:48:16.0000] <niloy>
if "for" accepted direct reference to HTMLNode, that would be cool

[06:48:20.0000] <MikeSmith>
zcorpan: hang one I'll get the URL

[06:49:20.0000] <MikeSmith>
zcorpan: https://raw.github.com/validator/validator/master/spec/w3c-html5.html

[06:49:55.0000] <MikeSmith>
and https://raw.github.com/validator/validator/master/spec/html5.html

[06:50:00.0000] <zcorpan>
niloy: so for is optimized for the declarative case, and the association doesn't work outside the document anyway, currently (per spec)

[06:51:17.0000] <zcorpan>
MikeSmith: thx. so w3c-html5.html sees <body> AFTER_HEAD

[06:51:25.0000] <niloy>
zcorpan, so it is worth it to make "for" work with HTMLNode directly, so that I dont have to think about generating unique strings?

[06:51:46.0000] <MikeSmith>
zcorpan: yeah seems so

[06:51:58.0000] <zcorpan>
niloy: can't you put the control inside the label?

[06:52:49.0000] <niloy>
zcorpan, yeh I can do that, thx

[06:54:13.0000] <zcorpan>
MikeSmith: ok then the trace makes sense

[06:55:03.0000] <zcorpan>
MikeSmith: what's on the stack at that point?

[06:55:11.0000] <zcorpan>
the stack of open elements

[07:02:53.0000] <MikeSmith>
zcorpan: dunno but I suppose I can hack in something to dump it out

[07:29:45.0000] <Domenic_>
Am I right that requestAutocomplete is screaming for a promise return type?

[07:30:45.0000] <zcorpan>
does this look right?

[07:30:50.0000] <zcorpan>
<p>The <dfn title=dom-Window-devicePixelRatio><code>devicePixelRatio</code></dfn> attribute must return the result of dividing the size of a CSS pixel at 100%

[07:30:51.0000] <zcorpan>
zoom by the size of a device pixel of the output device, in one dimension. If the device pixel is not square, then the smaller size must be used.

[07:32:34.0000] <zcorpan>
i guess "smaller size" is ambiguous if the device pixel isn't rectangular, either

[07:35:20.0000] <Domenic_>
ah I see that's already in the wiki spec

[07:35:52.0000] <zcorpan>
If the device pixel is not square, then the smaller of the vertical or horizontal size of the smallest bounding box of the device pixel must be used.

[07:36:38.0000] <MikeSmith>
zcorpan: in that case of both the WHATWG and W3C copies of the spec at the point where the parser fails, the stack of open elements shows html head script

[07:36:53.0000] <MikeSmith>
hmm but why does it still have the script element open

[07:37:17.0000] <MikeSmith>
zcorpan: anyway I'll be afk for a bit

[07:37:20.0000] <zcorpan>
ah interesting

[07:37:27.0000] <MikeSmith>
yeah

[07:37:37.0000] <MikeSmith>
something wrong there

[07:49:13.0000] <zcorpan>
i wonder what cssom-view should do when there are several screens

[07:49:55.0000] <zcorpan>
or when switching screens

[09:10:48.0000] <webchick>
Hi there, folks!

[09:11:17.0000] <webchick>
I'm Angie from the Drupal project. We have incorporated a Dialog API that attempts to conform as closely as possible to WhatWG's dialog spec at http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#the-dialog-element

[09:11:34.0000] <webchick>
I'm not fluent in RFC-ese so I had a question.

[09:12:16.0000] <webchick>
When a dialog has its close() method called, is it intended that the element stays in, or is removed from, the DOM?

[09:12:54.0000] <webchick>
Since it doesn't specify one way or the other explicitly, one of our developers is making the assumption it should stay there. But I think the *logical* assumption is that if it's no longer in your face, it's removed.

[09:13:20.0000] <nod_>
Hi there, I'm one of our developers :)

[09:13:45.0000] <webchick>
And I'm trying to figure out if the fact that both "When a http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#the-dialog-element element subject is to be closed, optionally with a return value result, the user agent must run the following steps:" and "If subject is in its http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document's http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.htm

[09:13:49.0000] <webchick>
nod_: Oh hai. :)

[09:14:23.0000] <webchick>
And/or if there is a better forum through which to get this question answered, please let me know. :)

[09:22:03.0000] <jgraham>
webchick: Since it doesn't way to remove it from the DOM, you don't remove it from the DOM

[09:22:13.0000] <jgraham>
Whatever is not explicitly allowed is forbidden

[09:22:32.0000] <webchick>
Dang.

[09:26:07.0000] <jgraham>
Basically the dialog exists in the DOM always, but the display is controlled by CSS

[09:26:48.0000] <jgraham>
(well, that skips quite a few details)

[09:27:17.0000] <webchick>
jgraham: Can I ask why that is?

[09:27:24.0000] <webchick>
I mean, I would expect that if it were hide()/show()

[09:27:30.0000] <webchick>
but it's open()/close()

[09:27:55.0000] <jgraham>
So Hixie_ was trying to work out what the right verbs should be the other day

[09:28:04.0000] <jgraham>
This seems like an interesting data point :)

[09:28:25.0000] <webchick>
Ha. :)

[09:28:44.0000] <webchick>
I'm always happy to walk into things totally clueless of the backstory and give opinions about what makes sense to me. ;)

[09:29:06.0000] <jgraham>
(I'm not sure how it would work if it was removed from the DOM, really. Where would it go? IF you wanted to re-open it later would you have to keep a js ref to the dialog around?)

[09:29:20.0000] <webchick>
Ok, well thanks for clearing that up, jgraham! Do you mind if I copy/paste this conversation into our issue tracker? else, I can just paraprhase it.

[09:29:37.0000] <jgraham>
Sure, feel free to do whatever you like :)

[09:29:59.0000] <webchick>
jgraham: Well, presumably it would remove it from the stack and if you wanted to re-open it, you'd start again from the "this doesn't exist in the stack yet, so make it new"

[09:32:49.0000] <Hixie_>
SimonSapin: ooh, interesting

[09:34:24.0000] <SimonSapin>
yeah, that seems to be one of the lesser known of the "new" (few years old) features

[09:34:40.0000] <jgraham>
Anyone know anything about pywebsockets?

[09:35:13.0000] <barnabywalters>
jgraham: I had a brief look at it before deciding to use a node.js package instead

[09:36:03.0000] <jgraham>
This is more of an internal-API question :)

[09:36:27.0000] <barnabywalters>
jgraham: can’t help then, sorry :)

[09:39:46.0000] <jgraham>
barnabywalters: Thanks anyway :)

[09:39:56.0000] <jgraham>
/me has enough of a hack to fix his problem now

[09:45:38.0000] <Hixie_>
bholley: should be online soon

[09:51:23.0000] <zcorpan>
jgraham: what about pywebsocket?

[09:51:53.0000] <jgraham>
zcorpan: I was going to ask about the API differences between standalone mode and mod_python mode

[09:52:23.0000] <jgraham>
Seems that your tests depended on request.args which is only there when running under apache

[09:52:52.0000] <jgraham>
In the end I just used urlparse on request.uri to get the query string out

[09:53:22.0000] <jgraham>
Seems kind of annoying to have two different APIs depending on the context you are running in

[09:53:41.0000] <zcorpan>
yeah i recall problems with the query string. we used standalone on t

[09:54:27.0000] <zcorpan>
but it was hacky either way

[09:55:58.0000] <zcorpan>
https://code.google.com/p/pywebsocket/issues/detail?id=68

[09:57:24.0000] <SimonSapin>
jgraham: mod_python has been abandoned for years

[09:57:34.0000] <SimonSapin>
and pre-dates WSGI

[09:58:22.0000] <jgraham>
SimonSapin: I know

[09:58:33.0000] <jgraham>
That isn't very relevant though :)

[09:59:02.0000] <SimonSapin>
sorry then, carry on

[09:59:17.0000] <jgraham>
For whatever reason pywebsocket uses mod_python to run under apache and BaseHTTPRequestHandler to run standalone

[09:59:35.0000] <jgraham>
and then exposes the native "request" object, lightly modified, in each case

[09:59:43.0000] <jgraham>
And they don't have the same API

[09:59:58.0000] <jgraham>
Which is a problem because that's the API you code against

[10:00:18.0000] <webchick>
Thanks for the help, jgraham! I'll leave you folks to it. :)

[10:25:29.0000] <TabAtkins>
Hixie_: background-position: right 1em;

[10:28:16.0000] <TabAtkins>
Ah, never mind, SimonSapin already answered.

[10:48:50.0000] <gsnedders>
Random off-topic question: is there any central discussion anywhere about the long-term goal to replace SpiderMonkey in Servo?

[10:55:37.0000] <jgraham>
There is no long term goal to replace SpiderMonkey in Servo

[11:23:16.0000] <Hixie_>
MikeSmith: since i'm a pedant, i'll just point out (re your comment in bug 23145) that in XML the string <html/> is not necessarily a start tag... it can be the text of a comment or CDATA block, too. :-)

[11:27:56.0000] <jgraham>
Or an attribute?

[11:28:04.0000] <jgraham>
/me hasn't seen the context

[11:28:37.0000] <Hixie_>
no, "<" isn't valid in XML attributes

[11:31:02.0000] <jgraham>
Oh, XML

[11:31:16.0000] <jgraham>
I missed that critical point :)

[11:31:20.0000] <Hixie_>
hehe

[11:31:28.0000] <Hixie_>
yeah in HTML there's a ton of things it could be

[11:31:32.0000] <Hixie_>
e.g. contents of <script> or <textarea>

[11:31:36.0000] <Hixie_>
attribute value

[11:31:51.0000] <Hixie_>
something in the doctype...

[11:31:52.0000] <Hixie_>
etc

[11:35:17.0000] <Ms2ger>
Ah, Hixie_

[11:35:41.0000] <Ms2ger>
A question about the xml serialization algorithm

[11:35:46.0000] <Hixie_>
yes sir

[11:36:20.0000] <Ms2ger>
It throws for input that can't be serialized as xml

[11:36:25.0000] <Ms2ger>
People want to stop doing that

[11:36:29.0000] <Ms2ger>
Any objection? :)

[11:37:13.0000] <Hixie_>
what do they want to do instead? silent data loss?

[11:38:04.0000] <Ms2ger>
Serializing as something that's not actually xml

[11:38:07.0000] <Ms2ger>
Like browsers do

[11:38:34.0000] <TabAtkins>
That seems bad in general, if the next thing in your pipeline is expecting XML.

[11:38:42.0000] <TabAtkins>
Silent data loss seems better than malforming XML.

[11:39:10.0000] <Ms2ger>
Want to try changing that in blink?

[11:39:25.0000] <TabAtkins>
Me? No.

[11:39:29.0000] <Hixie_>
wait, what? you want the xml serialiser to output non-xml-conforming content?

[11:39:39.0000] <Hixie_>
wouldn't that be... utterly pointless?

[11:39:40.0000] <Ms2ger>
I want the spec to match browsers

[11:39:48.0000] <TabAtkins>
But reporting a bug on Blink and pinging abarth with it would probably help.

[11:39:51.0000] <Hixie_>
ok but if the browsers are violating the xml spec, that means changing both HTML and XML

[11:40:19.0000] <Ms2ger>
They're not violating the xml spec

[11:40:29.0000] <Ms2ger>
They're just returning a string that isn't xml

[11:40:33.0000] <Hixie_>
...

[11:40:38.0000] <TabAtkins>
Only because the XML spec says "here there be dragons".

[11:40:48.0000] <TabAtkins>
Calling that "not violating" is pedantry.

[11:41:02.0000] <Ms2ger>
*shrug*

[11:41:33.0000] <Hixie_>
having an XML serialiser not output XML, or output non-conforming XML that literally cannot be parsed by an XML processor, seems Very Bad for such an API

[11:41:43.0000] <Ms2ger>
Sure

[11:41:45.0000] <Hixie_>
it would, indeed, call into question the very existential purpose of this API

[11:41:54.0000] <Ms2ger>
Sure

[11:42:00.0000] <Hixie_>
i don't like giving APIs existential crises

[11:42:14.0000] <Ms2ger>
Sure, and I don't like my spec being dry science fiction :)

[11:42:18.0000] <Hixie_>
i recommend fixing the browsers.

[11:42:27.0000] <Ms2ger>
The browsers don't want to fix

[11:42:30.0000] <Hixie_>
i don't see how this could be a compat issue, since the output is pointless.

[11:42:35.0000] <Hixie_>
bug #s?

[11:42:56.0000] <Ms2ger>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23460

[11:44:22.0000] <Hixie_>
where is the "don't want to fix"?

[11:45:05.0000] <Ms2ger>
smaug____, want to say that? ^

[11:45:22.0000] <Hixie_>
are we sure it's not you who wants this changed? :-P

[11:47:58.0000] <smaug____>
oh, note, there is that question mark. All the browsers do something, and spec says something else

[11:48:27.0000] <smaug____>
so following the reality kind of makes sense :)

[11:49:00.0000] <Hixie_>
the reality here is bogus, unless we can't change it we really should change it.

[11:49:05.0000] <smaug____>
(and the reality let's browsers to do some heavy optimizations, like https://bugzilla.mozilla.org/show_bug.cgi?id=923913 )

[11:49:25.0000] <smaug____>
I'm not ready to try to change it

[11:49:51.0000] <TabAtkins>
smaug____: That's just a matter of changing from "throws on invalid" to "silently loses data on invalid".

[11:49:54.0000] <smaug____>
if some other browser vendor wants to, and there are no problems, I think Gecko would follow

[11:49:59.0000] <Hixie_>
i don't mind us returning the empty string or something instead of throwing an exception, but returning invalid data is bogus.

[11:50:27.0000] <Hixie_>
i mean, specifically here, if we return invalid data, it is unusable.

[11:50:34.0000] <smaug____>
ah, empty string would be find too

[11:50:38.0000] <Hixie_>
it's not like in HTML mode, where the parser will muddle through.

[11:50:46.0000] <smaug____>
s/find/fine/

[11:51:07.0000] <smaug____>
I definitely could accept empty string easier

[11:51:32.0000] <Hixie_>
Ms2ger: empty string?

[11:51:53.0000] <Ms2ger>
Could live with that if people want to implement

[11:55:32.0000] <jsbell>
Chrome requires the new operator when constructing XMLHttpRequest(), Firefox & IE allow it to be called as a function (e.g. xhr = XMLHttpRequest()). Anyone know the story? (context: pinged about how TextDecoder should behave)

[11:55:57.0000] <Ms2ger>
annevk wants to break the no-new form

[11:56:04.0000] <Ms2ger>
I think that's silly

[11:58:33.0000] <zcorpan>
jgraham: so long story short, request.unparsed_uri should be consistent in both modes.

[12:04:24.0000] <zcorpan>
Hixie_: Ms2ger: isn't empty string ambiguous for Element.innerHTML? surely that's supposed to mean that the element is empty?

[12:04:37.0000] <zcorpan>
null?

[12:04:57.0000] <Hixie_>
null might be even better, yeah

[12:05:28.0000] <Hixie_>
TabAtkins: i figured out why you were able to come up with a sanish solution for 'display' in CSS3 Display! You just ignore the two hard bits ('run-in' and 'compact')! :-P

[12:06:05.0000] <TabAtkins>
Hixie_: Nah, both of those are easy to put *into* the display-* framework.  Their insanity is localized to their actual behavior, not their interaction with the other longhands.

[12:06:17.0000] <Hixie_>
i'll believe that when i see it :-P

[12:06:18.0000] <zcorpan>
what does compact do?

[12:06:25.0000] <TabAtkins>
But also, fantasai came up with a sane definition of run-in that I'm planning to put in.  'compact' is terrible and nobody will mention it.

[12:06:37.0000] <TabAtkins>
zcorpan: Go look at CSS2 and see if you can figure it out.  If you can, write a spec plz.

[12:06:50.0000] <zcorpan>
does anyone implement compact?

[12:06:53.0000] <Hixie_>
'compact' might be dead now, yeah. back when i tried doing this, i was trying to include 'compact' which is what made it so hard to do.

[12:06:57.0000] <TabAtkins>
Not really, no.

[12:07:32.0000] <Hixie_>
('compact' would be really useful in a lot of cases i run into in <dl>-like scenarios in UIs and documents)

[12:09:24.0000] <TabAtkins>
It's basically magic abspos, fitting into the margin of the following block if possible.

[12:09:43.0000] <TabAtkins>
If not possible, it's a normal block box.

[12:15:01.0000] <zcorpan>
foolip: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23469

[12:18:55.0000] <Hixie_>
a surprisingly large part of my life over the past decade and a half has been taken up just reading bugzilla e-mails.

[12:18:58.0000] <Hixie_>
i don't know what i feel about that.

[12:21:16.0000] <Ms2ger>
Surprisingly?

[12:29:40.0000] <Hixie_>
given that i've moved between employers and changed from QA to spec writing and so forth, yes.

[12:44:10.0000] <zcorpan>
MikeSmith: what does "untested" do?

[13:03:23.0000] <Hixie_>
MikeSmith: re https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 - should we leave bugs in Unwelcome open, so they come up in searches more?

[13:12:25.0000] <abarth>
Hixie_, TabAtkins: There's a CL under review to fix some of those cases

[13:12:34.0000] <abarth>
I just need to some whiskey before studying it

[13:12:53.0000] <TabAtkins>
abarth: Come on down to the mtv office and we'll hook you up.

[13:15:34.0000] <Hixie_>
some of which cases?

[13:16:21.0000] <TabAtkins>
outputting malformed xml

[13:16:24.0000] <abarth>
 < inside <script>

[13:16:30.0000] <abarth>
i can find the bug

[13:16:48.0000] <abarth>
https://codereview.chromium.org/26193002/

[13:17:03.0000] <abarth>
its from someone named pwnall

[13:17:09.0000] <abarth>
which makes me think I should read it carefully :)

[13:26:12.0000] <Hixie_>
ah, cool

[13:26:27.0000] <Hixie_>
well, consider returning null instead of firing an exception :-)

[13:26:34.0000] <Hixie_>
hopefully someone who cares about this filed a bug... :-)

[13:26:37.0000] <Hixie_>
bbiab, lunch

[14:05:07.0000] <Hixie_>
smaug____: really? the key is the weak part? woah. what's the point of it then?

[14:05:14.0000] <Hixie_>
smaug____: like, how do you use it?

[14:05:18.0000] <smaug____>
that is the whole point

[14:05:23.0000] <Hixie_>
or why would you use it?

[14:05:30.0000] <smaug____>
you can add weak object->value references

[14:06:01.0000] <Hixie_>
so it's basically only useful as a way to annotate objects?

[14:07:16.0000] <smaug____>
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap#Why_WeakMap.3F

[14:08:12.0000] <Hixie_>
sure, once you said it was keys all that was obvious

[14:08:19.0000] <Hixie_>
it doesn't answer the question of why you would use it though...

[14:08:30.0000] <Hixie_>
why not just hang your annotation off the object directly?

[14:08:45.0000] <Hixie_>
like, if it's an HTMLElement, you could just use ._mydata or whatever

[14:08:52.0000] <Hixie_>
set a custom property on the object

[14:09:01.0000] <Hixie_>
wouldn't that do exactly what WeakMap does?

[14:10:26.0000] <smaug____>
so you can do thing like does something belong to a set

[14:10:40.0000] <smaug____>
though, you could indeed just add foo._myState

[14:19:52.0000] <jsbell>
Hixie: if you can hang a property off something, then yes it's equivalent.

[14:20:56.0000] <jsbell>
In the cases where you can't - the object is frozen, or the thing you're setting on the object is secret, or two instances need to set properties, etc then it's necessary.

[14:21:17.0000] <jsbell>
It could be implemented in the VM by setting hidden properties.

[14:27:37.0000] <Hixie_>
what's a frozen object? another new ES6 thing?

[14:27:56.0000] <Hixie_>
i don't understand what you mean by "secret". it's just code. and two instances can just use two properties.

[14:37:51.0000] <jsbell>
Hixie: Object.freeze in ES5, e.g. var o = {}; Object.freeze(o); o.p = 1; alert(o.p); ==> undefined

[14:38:09.0000] <Hixie_>
what's the use case?

[14:38:58.0000] <jsbell>
Most of this (including WeakXXX) came out of the Caja/SES work

[14:39:05.0000] <Hixie_>
smaug____: the e-mail i posted when i added this was http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0013.html

[14:39:37.0000] <smaug____>
ok, thanks

[14:39:46.0000] <smaug____>
I was just looking for PortCollection in the messages

[14:39:57.0000] <jsbell>
Short version: you're trying to implement a sandbox

[14:40:01.0000] <Hixie_>
(for the record, i really don't care what the solution is here. i just think we should have a solution that doesn't involve essentially requiring a memory leak.)

[14:40:38.0000] <Hixie_>
jsbell: that sounds like a wackamole exercise in frustration...

[14:47:01.0000] <smaug____>
we just can't expose gc behavior

[14:47:45.0000] <smaug____>
once we do that explicitly, it will creep into other APIs too

[14:56:40.0000] <zewt>
Object.freeze seems pretty horrible if it doesn't throw

[15:27:37.0000] <Domenic_>
WeakMap => truly private state

[15:27:45.0000] <Domenic_>
Object.freeze throws in strict mode (which everyone should be using)

[15:28:06.0000] <Domenic_>
Without WeakMap it is impossible to have high-integrity objects in JS, like e.g. platform objects

[15:31:14.0000] <Hixie_>
what's the use case for high-integrity objects in JS?

[15:31:31.0000] <Hixie_>
i mean it sounds good and all, but it's not clear what the point is

[15:31:38.0000] <Hixie_>
to me at least

[15:31:50.0000] <TabAtkins>
Explaining the platform, and introducing new things similar to the current platform.

[15:32:19.0000] <Hixie_>
you can explain the platform without it, and you can introduce new things similar to the platform with it it too

[15:32:27.0000] <Hixie_>
we've been doing both for decades

[15:33:28.0000] <TabAtkins>
Different definition of "explaining", and no you can't, at least with sufficient fidelity.

[15:34:10.0000] <Domenic_>
saying "you must use C++ if you want private state" is kind of O_o

[15:36:02.0000] <Hixie_>
TabAtkins: ok, let me put it another way then: i disagree that those use cases are valuable :-)

[15:36:08.0000] <Hixie_>
TabAtkins: what's an end-user use case?

[15:36:16.0000] <TabAtkins>
We know you do. You've said that over and over again in the past.

[15:36:25.0000] <TabAtkins>
And we've just ignored you and worked around it. ^_^

[15:36:57.0000] <Hixie_>
yeah... not helpful

[15:37:14.0000] <Hixie_>
why not just explain why it's useful?

[15:37:19.0000] <TabAtkins>
Sorry, but you've repeatedly stated your disdain for "make APIs that look and act the same as native ones" as a use-case.

[15:37:27.0000] <Hixie_>
that's because it's not a use case...

[15:37:52.0000] <TabAtkins>
And that's why it's not worth explaining to you, because your suggestion of "just make the API not look like the platform" isn't useful.

[15:37:53.0000] <Hixie_>
it is often brought up as a use case as if it is obvious on its face why it's valid, but it's not obvious at all, and no attempt seems to have been made to explain it

[15:38:09.0000] <Hixie_>
it's like something you have on faith or something

[15:38:15.0000] <Hixie_>
faith-based API design considered harmful :-P

[15:38:45.0000] <TabAtkins>
I'm sorry you don't understand why it's useful for users of a library to have the library act like the rest of the platform.

[15:39:14.0000] <Hixie_>
that isn't helpful or constructive

[15:39:28.0000] <Hixie_>
seriously, if you can't articulate why something is helpful, maybe it's not. that's all i'm saying.

[15:39:46.0000] <Domenic_>
i think it's been articulated, but not to your satisfaction, just to many other peoples'...

[15:39:52.0000] <Hixie_>
where?

[15:39:56.0000] <TabAtkins>
I did articulate it.  I, and others, have done so many times.  You just don't accept it.  Shrug.

[15:41:23.0000] <Hixie_>
it just seems crazy to me that ES is getting a ton of APIs that i see as essentially pointless, and the only argument in favour is "we said it's important, but you won't believe us"

[15:41:26.0000] <TabAtkins>
"Because a consistent platform is good" is the basic reason for lots of things, including stuff you've found very valuable, like specifying the parser.

[15:41:55.0000] <Hixie_>
the parser spec is useful to get interop and that's good to avoid concrete security bugs.

[15:42:14.0000] <Hixie_>
consistency is not, and has never been, a compelling use case. there's tons of stuff we haven't added to HTML because consistency was the only argument.

[15:42:21.0000] <TabAtkins>
It's also helpful for authors, because it means a lower cognitive overhead.

[15:42:34.0000] <Hixie_>
more APIs doesn't mean a lower cognitive overhead.

[15:43:42.0000] <Hixie_>
i mean, it really doesn't. it's easier to understand classical mechanics (which isn't internally consistent) than quantum mechanics (which is), as a simple example of that.

[15:44:18.0000] <TabAtkins>
Le sigh.  No, but having libraries do things in a way similar to the platform *does* mean a lower cognitive overhead, as opposed to library users having to learn to do things in 2+ different ways because some things are "native" and some are "JS".

[15:45:06.0000] <Hixie_>
but again, authors don't have to do that. it's quite possible to write libraries that work close enough to the platform that authors have no troubles, without any of this stuff.

[15:45:13.0000] <TabAtkins>
And some patterns, like private state, which are extremely useful, currently require either giving up on real privacy (using naming conventions, for example), or costing a bunch of memory (using closures for private state on objects). WeakMaps address the problem easily and properly.

[15:45:13.0000] <Hixie_>
unless you have a concrete counter-example?

[15:45:26.0000] <TabAtkins>
Not off the top of my head, because I just stumbled into this argument.

[15:45:37.0000] <TabAtkins>
And I'm trying to code some Python right now. ^_^

[15:45:59.0000] <smaug____>
poor you :)

[15:46:01.0000] <Hixie_>
it's not "real" privacy. all this code is running in the same security context.

[15:46:15.0000] <Hixie_>
user privacy isn't in the slightest bit affected.

[15:46:43.0000] <TabAtkins>
"Privacy" clearly has different definitions, and I'm not using that one.

[15:47:29.0000] <Hixie_>
what definition are you using?

[15:48:19.0000] <Hixie_>
i'm just baffled by this. It seems like a clear case of user>author>spec>theory being turned on its head.

[15:48:21.0000] <TabAtkins>
...the one that means private state on an object?

[15:48:47.0000] <Hixie_>
what's the use case for that on the web?

[15:49:00.0000] <TabAtkins>
The same as its use-case in any other programming language, ever.

[15:49:03.0000] <zewt>
the idea of putting state on an object in a different object seems pretty seriously nasty, at least from a code style standpoint (granted that it may be the same under the hood)

[15:49:13.0000] <TabAtkins>
I refuse to explain the concept of private state to you.

[15:49:32.0000] <TabAtkins>
zewt: It's a little funky at first, but not bad once you've seen it once or twice.

[15:50:07.0000] <Hixie_>
TabAtkins: ok, but then don't complain that it's "not worth explaining to you" when you won't explain it

[15:50:13.0000] <Hixie_>
just admit you don't want to and move on

[15:50:21.0000] <Hixie_>
/me continues to be baffled

[15:50:26.0000] <TabAtkins>
It's... not worth explaining a basic computer science concept to you. You can use Wikipedia for that.

[15:51:03.0000] <Hixie_>
(note that i can't think of any other language that has a way to add private state to an object the way that WeakMap does.)

[15:51:19.0000] <Hixie_>
are we talking about local private state?

[15:51:25.0000] <Hixie_>
because that doesn't seem to be what WeakMap gives you

[15:51:28.0000] <Hixie_>
or freeze

[15:51:57.0000] <zewt>
i think WeakMap does give that, if we mean the same thing by "local private state"

[15:52:12.0000] <Hixie_>
i mean, i am an object, and i have state i don't want public.

[15:52:21.0000] <TabAtkins>
Yes, the actual code you write to assign private state via WeakMap is slightly different.  Rather than obj[key] = val, you write map[obj] = val.  That's not a material difference.

[15:52:23.0000] <Hixie_>
WeakMap seems to be a way to secretely annotate other objects.

[15:52:51.0000] <zewt>
hixie: right

[15:53:08.0000] <zewt>
if you want private state in the object itself you still need to stash it in a closure

[15:53:23.0000] <Domenic_>
that's... not in the object itself, that's in an external data structure called "scope"

[15:53:37.0000] <Hixie_>
i'm all for JS having classes with private blocks and all

[15:53:43.0000] <Hixie_>
but that seems completely orthogonal to this

[15:53:48.0000] <zewt>
Domenic_: no difference as far as API structure is concerned

[15:53:54.0000] <Hixie_>
this being WeakMap and the frozen object thing

[15:54:12.0000] <Domenic_>
zewt: big difference... but maybe i'm not understanding...?

[15:54:53.0000] <zewt>
fwiw I don't have a strong opinion on whether it's worth it or not, but I agree with hixie that this is not analogous to private state inside an object, this is external to the object

[15:55:26.0000] <Domenic_>
right, it is strictly more powerful than other languages' private state abstraction, which is tied to e.g. classical models

[15:55:35.0000] <Domenic_>
but it is in the end a private state abstraction

[15:55:38.0000] <Hixie_>
my opinion is not "strong", it just the default opinion of "there's no use case -> no need to have it"

[15:56:02.0000] <zewt>
it doesn't seem to support the private data model of other languages at all, so I'm not sure that it's more powerful

[15:56:04.0000] <Hixie_>
it doesn't seem more powerful at all... it seems entirely orthogonal

[15:56:12.0000] <Domenic_>
es7 will probably have syntax so that e.g. obj@key = val <-> map[obj].key = val

[15:56:32.0000] <Domenic_>
zewt: it definitely does support that model, let me dig up some example code...

[15:56:38.0000] <TabAtkins>
A better term for what WeakMaps give you is "uncollidable" state.

[15:56:46.0000] <Domenic_>
zewt: here you go https://gist.github.com/domenic/6736258

[15:56:51.0000] <TabAtkins>
Which you can use to implement cheaper private state than just using closures.

[15:56:59.0000] <zewt>
Domenic: to do that you'd need to stash your WeakMap in some place that itself can't be accessed--which means you're back to closures

[15:57:25.0000] <Domenic_>
sure, of course, or modules.

[15:57:47.0000] <zewt>
so it's a class that essentially exists so you don't have to use closures, which you have to put in a closure :)

[15:57:54.0000] <zewt>
(yeah, I know there's a difference in performance, depending on how you do it)

[15:57:55.0000] <TabAtkins>
zewt: Yup, closing over just a WeakMap around the constructor function is better than having to close over every bit of state.

[15:58:07.0000] <Domenic_>
the big difference is you can control who has access. they don't have to share a scope. so e.g. prototype methods can access the private state.

[15:59:55.0000] <TabAtkins>
And the even smaller WeakSet object is *solely* for branding - no chance of collision, secret if the set is secret, and doesn't accidentally leak.

[16:02:47.0000] <zcorpan>
man, i didn't realize css stack wasn't supported in background-image in blink

[16:02:57.0000] <zcorpan>
er, svg stack

[16:03:07.0000] <TabAtkins>
zewt: If you're familiar with Crockford's method of doing instance-private state, it requires defining fresh copies of the prototype methods directly onto each instance, so they'll be defined in the correct context. That's a big memory hit.

[16:03:30.0000] <zewt>
seems clumsy, if the main use case is basically in-object private state, compared to traditional private member mechanisms

[16:03:57.0000] <zewt>
(not to claim I know how any of those could be applied to JS in a web-compatible way)

[16:03:58.0000] <TabAtkins>
With WeakMap, you can just define things as normal, with a closure wrapping the class definition to contain the weakmap definitions.  Then each prototype function can just use the weakmaps to attach and access private state on instances.

[16:04:25.0000] <TabAtkins>
Yeah, exposing privacy in the same way as other type systems is really difficult, because JS's type system is so light.

[16:04:32.0000] <Domenic_>
i think it fits pretty well with JS, given JS is all about object literals and prototypes and not classes. but yes, slightly clumsy for the classical case, just like classes in JS generally are.

[16:05:02.0000] <Domenic_>
but, just like ES6 gives us class sugar to make it less clumsy, ES7 will probably give private state sugar

[16:08:14.0000] <zewt>
not sure that "it's clumsy, but that's normal for JS and we'll pave over it later" is a very good sales point :)

[16:09:20.0000] <TabAtkins>
Heh. The issue is that the non-clumsy way doesn't decompose to real JS.

[16:09:27.0000] <TabAtkins>
It requires more structure than actually exists.

[16:09:37.0000] <TabAtkins>
So you have to start with the low-level one and add sugar for it after.

[16:09:50.0000] <zewt>
python's __name mechanism could probably work conceptually, but wouldn't be web-compatible (also it's painfully ugly)

[16:10:17.0000] <zewt>
(makes me feel like I'm reading a C++ STL header, and that's ... bad)

[16:10:34.0000] <TabAtkins>
Right, nobody wants that.

[16:10:51.0000] <TabAtkins>
(Had a near-miss with people trying to make Symbols work that way.)

[16:45:04.0000] <Hixie_>
TabAtkins: i think it's worth noting that the use case that the discussion ended up describing has nothing to do with simulating host objects

[16:45:30.0000] <Hixie_>
TabAtkins: (and if the use case is instance-private data, i really don't think it's a particularly good mechanism compared to other languages')

[16:45:33.0000] <TabAtkins>
No, it most certainly did.  It was all about private state, which host objects can have.

[16:47:46.0000] <Hixie_>
it lets you get private state (in a weird way) with a slightly better memory story than you could do with closures. it doesn't give you private state that you couldn't get before, and it doesn't get you anything like the memory story that C++ native code has.

[16:47:57.0000] <Hixie_>
i don't understand how it can be described as something needed to simulate host objects.

[16:48:02.0000] <Hixie_>
or "explain the platform"

[16:48:09.0000] <Hixie_>
you can "explain the platform" with closures too

[16:48:20.0000] <TabAtkins>
"slightly better" is a misnomer. It goes from "too much memory wasted to consider for production systems" to "perfectly fine".

[16:48:38.0000] <Hixie_>
both of those are exaggerations.

[16:48:59.0000] <Hixie_>
but "lower memory usage" is a fine use case in and of its self

[16:49:02.0000] <TabAtkins>
Per-instance methods are completely unacceptable when you'll be creating thousands of instances.

[16:49:24.0000] <Hixie_>
why would you do per-instance methods?

[16:50:09.0000] <TabAtkins>
Because that's what you need to do if you want the methods to be able to *access* the per-instance private state.

[16:50:30.0000] <TabAtkins>
You can't just attach the methods to the prototype like normal, because then they're not in the instance's closure that captured the private variables.

[16:51:30.0000] <Hixie_>
isn't that going to be solved by a real class system?

[16:52:08.0000] <TabAtkins>
No, JS is not introduce "a real class system".  Producing two completely different ways of having a class would be ridiculous and bad.  JS is producing a class *syntax*, which desugars into the existing prototype-based stuff.

[16:53:09.0000] <TabAtkins>
(Or to put it another way, JS already has a real class system. It's different from some other class systems, but has its own benefits.  It's not going to introduce a second one.)

[16:54:19.0000] <Hixie_>
ugh

[16:54:53.0000] <Hixie_>
see, this is what drives me crazy. we're introducing crazy things like WeakMap and freezing objects and so on, and not fixing the real pain points with JS, with are amongst others that authors just hate prototypes.

[16:55:20.0000] <TabAtkins>
Coming from the dude who's maintaining one of the largest piles of legacy hacks in existence. ^_^

[16:55:43.0000] <Hixie_>
and you can't "explain the platform" when you're desugaring into an entirely different model than the platform is built on, either

[16:55:44.0000] <Domenic_>
who hates prototypes?

[16:55:48.0000] <TabAtkins>
And no, prototypes work just fine. Most people don't give a shit about the specifics of the class system, because almost no one does anything complicated with classes, ever.

[16:55:52.0000] <Hixie_>
Domenic_: who doesn't

[16:55:54.0000] <TabAtkins>
What they hate is the syntax, for good reason, and we're fixing.

[16:55:59.0000] <Domenic_>
Hixie_: web developers?

[16:56:04.0000] <Hixie_>
yeah, web developers

[16:56:12.0000] <TabAtkins>
And if you do care about the class system, prototype-based systems have some nice qualities.

[16:56:14.0000] <Domenic_>
vm writers hate prototypes (so they go off and build dart)

[16:56:19.0000] <Domenic_>
but web devs like them

[16:56:24.0000] <Hixie_>
it's by far the #1 issue i hear about when it comes to web devs complaining to me about JS-related topics

[16:56:31.0000] <Domenic_>
O_o

[16:57:15.0000] <zewt>
(as a web developer, i've never found a single thing to like about JS's class model compared to, say, Python)

[16:57:31.0000] <Hixie_>
^ that's what it looks like when phrased politely

[16:57:39.0000] <Hixie_>
usually i don't hear it phrased so politely

[16:57:41.0000] <TabAtkins>
Every prototype-related complaint I've heard has been about the way you do classes in the current syntax.

[16:58:01.0000] <TabAtkins>
I've never heard anyone complain about the actual mechanics, except for people who geek over class systems and are just discussing relative merits.

[16:58:25.0000] <TabAtkins>
"class Foo extends Bar { ... }" is in ES6, and it fixes the syntax complaints entirely.

[16:58:57.0000] <Hixie_>
TabAtkins: what i find is that the people who are complaining about the syntax often don't understand the mechanics, and when you try to explain the mechanics to have them understand the syntax, they switch to complaining about the mechanics, usually with looks of contempt and disbelief.

[16:59:42.0000] <TabAtkins>
Hixie_: Most people don't have any clue how class systems work at all in the first place, and have only a surface understanding of what OO even means, particularly that it's just a loosely-connected set of primitives that are all separable.


2013-10-10
[17:00:02.0000] <TabAtkins>
Alternately: Most people were taught OO in Java or C++, so of *course* they dislike anything with a different system.

[17:00:20.0000] <zewt>
(that isn't how I've ever thought of OO)

[17:00:23.0000] <Hixie_>
that's true of some people, but other people i've talked to are people with a decade+ of experience with C++ and Java and other languages

[17:00:42.0000] <Hixie_>
just because you learnt one model doesn't mean you don't prefer others.

[17:00:54.0000] <Hixie_>
i originally learnt without OO and i prefer OO, for instance. :-)

[17:01:05.0000] <Hixie_>
(for many purposes; obviously, not all.)

[17:01:08.0000] <TabAtkins>
Sure, it's cool to prefer whatever. I like CLOS best out of every one I've found, for example.

[17:01:24.0000] <TabAtkins>
Which is definitely not prototype-based.  It's "generic function-based", if anything.

[17:01:26.0000] <Hixie_>
and what i'm saying is that it's an active _dislike_ for js' model that i see

[17:01:31.0000] <zewt>
i learned in basic on an apple II, but i try not to let that hold me back

[17:01:34.0000] <TabAtkins>
I've never seen that.  Shrug.

[17:01:43.0000] <Hixie_>
you just saw it from zewt :-)

[17:02:04.0000] <Hixie_>
anyway. all this is skipping past the point that i thought was particularly interesting, which is that the JS model isn't the model browsers use, so so long as we have it, you can't "explain the platform" with it

[17:02:04.0000] <jsbell>
zewt: Do you also read $ as "string" ?

[17:02:20.0000] <Hixie_>
so "explain the model" is both not a good argument, and not one that actually applies

[17:02:35.0000] <Domenic_>
it's definitely the model browsers use

[17:02:45.0000] <Domenic_>
they just have access to one extra primitive, namely actual private state

[17:02:53.0000] <Domenic_>
there are direct APIs for this in V8 and SpiderMonkey

[17:02:59.0000] <Domenic_>
SetHiddenValue/GetHiddenValue in V8

[17:03:23.0000] <zewt>
not really, it's probably been 20 years since I've touched "classic" basic, heh

[17:03:50.0000] <TabAtkins>
Hixie_: Huh?  Browsers use JS+magic.  We're just trying to explain the magic so we can do things that look the same in pure JS.

[17:03:55.0000] <zewt>
much more time learning to hate $ thanks to perl and php

[17:04:07.0000] <Hixie_>
...browsers use C++...

[17:04:57.0000] <TabAtkins>
Hixie_: I'm talking about what authors see.

[17:05:05.0000] <TabAtkins>
Browsers talk to the author with JS+magic.

[17:05:08.0000] <Domenic_>
some use rust. some use self-hosted stuff (i.e. JS). that's all unobservable to authors. authors see JS APIs.

[17:05:30.0000] <Hixie_>
so clearly i don't even know what you mean by "Explain the platform" then

[17:06:43.0000] <TabAtkins>
It means reducing the size of that "magic" bit.

[17:06:47.0000] <TabAtkins>
So that it's all just "JS".

[17:07:20.0000] <Hixie_>
i don't understand. what kind of magic are we talking about?

[17:07:39.0000] <Hixie_>
i mean, we're not talking about implementing Event or Node or Document or Window in JS, right?

[17:07:48.0000] <Hixie_>
or WebSocket, or XMLHttpRequest, or Location, or History

[17:07:52.0000] <TabAtkins>
Everything that can't be reproduced in pure JS (or can't be reproduced in a remotely similar way; for example, if it requires substantially more memory or processing time to do in JS over what native gets).

[17:08:06.0000] <zewt>
(incidentally, i've completely lost the discussion, heh)

[17:08:19.0000] <Hixie_>
surely anything that can be reproduced in JS should just be a library

[17:08:25.0000] <TabAtkins>
Or at least minimizing that "magic" to the small set of things that really are impossible to provide securely, or just far too difficult.

[17:08:29.0000] <Hixie_>
the whole point of having a platform is to provide things you can't do in a library

[17:08:50.0000] <Domenic_>
That should be about access to capabilities, not about basic expressive semantics

[17:08:51.0000] <TabAtkins>
No, it's also to provide common idioms so we're all talking the same language for common things.

[17:08:51.0000] <Hixie_>
i think that hits my problem with this

[17:08:55.0000] <zewt>
err, what?

[17:09:03.0000] <Domenic_>
(the former being access to a web socket, the latter being 'having private state'

[17:09:06.0000] <TabAtkins>
I am *super* not getting into the "never provide anything in the platform that can be done in JS" argument.

[17:09:24.0000] <Hixie_>
i guess that argument is the crux of the matter

[17:09:47.0000] <TabAtkins>
That argument is decided. The people who say "never" are wrong, and nobody listens to them.

[17:09:55.0000] <Hixie_>
...

[17:10:12.0000] <Hixie_>
i think the opposite is clearly true

[17:10:21.0000] <Hixie_>
we almost never add features that can just be done in libraries

[17:10:23.0000] <TabAtkins>
Writing some code a few times in browsers is better than having it written by millions of authors and sent down over millions of page connections.

[17:10:23.0000] <Hixie_>
there's no point

[17:10:46.0000] <TabAtkins>
You can reproduce basically the entire platform with a socket library and WebGL.

[17:10:51.0000] <TabAtkins>
Your argument is invalid. ^_^

[17:10:54.0000] <Hixie_>
that is true for things that browsers can do better, but by definition, if browsers can do it better, then it's not something that can be done in JS

[17:11:11.0000] <Hixie_>
if your argument was what we applied to the platform, there'd be almost no JS out there

[17:11:21.0000] <Hixie_>
and browsers would be terabytes in size

[17:11:50.0000] <zewt>
(i'm confused and surprised; I thought it was, at least among most people here, universally agreed that things should go in the platform even if they can be done in libraries if they're common enough, since developers shouldn't need to load a bunch of libraries to do basic stuff)

[17:12:52.0000] <zewt>
(with the meaning of "common enough" being more debated)

[17:14:09.0000] <Hixie_>
i don't think we've ever added anything that can be done in JS as well as natively. What did you have in mind?

[17:14:28.0000] <Hixie_>
we add things that people do as well as they can, but that native could do far better, to the platform, for sure

[17:14:50.0000] <zewt>
for example, the whole URL API that anne's been working on--i'm definitely tired of having to copy around query parameter parsing code everywhere I go, as well as that everyone reading my code has to learn the particular API I'm using, instead of seeing a common, standard API and knowing it already

[17:15:53.0000] <TabAtkins>
zewt: Yes, exactly.

[17:16:24.0000] <Hixie_>
the bulk of that API is Location and HTMLAnchorElement, which can't be done with JS

[17:16:43.0000] <zewt>
i'm talking about the API to parse out a URL into components

[17:17:15.0000] <Hixie_>
that's just the Location/HTMLAnchorElement API split out into a separate independent component

[17:17:20.0000] <zewt>
which people do all the time in JS, and there's no performance issue there, it's just a pain in the ass, and ridiculously commonly needed

[17:18:19.0000] <TabAtkins>
Hixie's argument would, for example, kill Set, since it's just a library over Map.  (Map is needed, since you can't do Map in Map-less JS without severe performance penalties - lookup is O(n).)

[17:18:36.0000] <Hixie_>
yeah i really don't understand why we have many of the new JS features, Set included.

[17:18:56.0000] <TabAtkins>
And I don't understand why you don't understand, thus the difficulty in explaining more advanced things.

[17:19:00.0000] <zewt>
exaggeration aside i don't think browsers would be "terabytes in size" even if this was taken too far; Python has a very broad standard library (much more than I'd ever argue for browsers), and it's maybe 60 megs

[17:19:07.0000] <Hixie_>
(but it's clear that JS isn't being build with the same principles in mind as we're using e.g. for HTML)

[17:19:18.0000] <TabAtkins>
It seems very self-evident to me, as someone who does web programming regularly.

[17:19:43.0000] <Hixie_>
TabAtkins: ditto, but the opposite is what seems self-evident. :-)

[17:19:52.0000] <TabAtkins>
zewt: Yeah, but loading an extra 60megs into each tab is somewhat less good.

[17:20:02.0000] <Hixie_>
zewt: if it was taken to its logical extension, no web authors would write any code.

[17:20:12.0000] <Hixie_>
zewt: so browsers would have the code of every app in the world :-)

[17:20:16.0000] <TabAtkins>
Hixie_: That's not the logical extensions, that's ad absurdum.

[17:20:25.0000] <zewt>
well, that can be alleviated (you don't load things until they're used, shared memory for precompiled bytecode, etc)

[17:20:40.0000] <zewt>
Hixie_: like I said before, "common enough"

[17:20:58.0000] <zewt>
a tetris API is clearly not common enough, so people will still have to implement tetris themselves :)

[17:21:01.0000] <TabAtkins>
zewt: Yeah, maybe.  I suspect we'll end up moving into the "broad standard library" world eventually, anyway.

[17:21:18.0000] <Hixie_>
i guess the logical extension would be anything that's implemented at least 5 times, so not everything.

[17:21:55.0000] <TabAtkins>
A realistic cutoff is quite a bit higher, but something like that.

[17:21:56.0000] <zewt>
TabAtkins: a similar trick in Python for server-based worker pools is to load everything you need before you fork workers, for example

[17:22:22.0000] <zewt>
Hixie_: my guess is tetris has been implemented more than 5 times, but I'd still say it's not common enough :)

[17:22:38.0000] <zewt>
("been implemented" = in javascript)

[17:23:27.0000] <TabAtkins>
Right now the criteria seems to be "implemented at least thousands of times, or implemented in a few popular libraries used by millions", roughly.

[17:23:37.0000] <Hixie_>
anyway, i don't think that's the right criteria

[17:23:57.0000] <Hixie_>
i think we should add things to the platform when doing so provides something that you can't do from the authoring side.

[17:24:16.0000] <zewt>
it seems like you're arguing that there are only two possibilities, implementing only what can't be done in libraries at all, or implementing everything ever; there are a lot of places in-between

[17:24:22.0000] <TabAtkins>
Shrug, it's a reasonable calculus, when you consider author time vs browser dev time, and user page-load time.

[17:24:26.0000] <Hixie_>
now, that might be just consistency across a lot of authors, the way URL is (it can be cheaply added since it's just the existing API made independent)

[17:24:51.0000] <Hixie_>
but my point is that if that's your criteria, then it doesn't make any sense to talk about making the platform into something you can do in JS

[17:25:02.0000] <Hixie_>
since the whole _point_, under this design philosophy, is to provide things that can't be done

[17:25:07.0000] <Hixie_>
and so it's a futile goal

[17:25:19.0000] <TabAtkins>
Most of us don't operate under your particularly strict criteria, so that's irrelevant.

[17:25:43.0000] <Hixie_>
TabAtkins: you know, it's incredibly frustrating and insulting when you just dismiss other people's concerns repeatedly.

[17:25:55.0000] <TabAtkins>
Hixie_: You know that I can say the exact same thing back, right?

[17:25:56.0000] <Hixie_>
"i disagree with you, so i'll ignore you"

[17:26:01.0000] <Hixie_>
i'm not ignoring you

[17:26:11.0000] <Hixie_>
i've been trying to understand your point of view for a few hours now

[17:26:12.0000] <TabAtkins>
"I disagree with you, so I'll just repeatedly ask for use-cases and not accept anything you say."

[17:26:15.0000] <Hixie_>
while you keep saying you're giving up

[17:26:16.0000] <TabAtkins>
^_^

[17:26:31.0000] <Hixie_>
there's a qualitiative difference here

[17:26:45.0000] <Hixie_>
qualitative even

[17:26:58.0000] <TabAtkins>
If your definition of use-case explicitly excludes the kinds of things we're trying to do, there's not really a difference.

[17:27:25.0000] <TabAtkins>
(Which in many of these cases is "make author's lives easier by having better consistency in the platform and across independent libraries".)

[17:27:42.0000] <TabAtkins>
I mean, I've explained it. You didn't accept the explanation.  I can't do a lot about that.

[17:28:29.0000] <TabAtkins>
I've already learned from talking to you for years that you have certain opinions about programming languages that are very different from mine, and different from those of many involved in JS and DOM standards.

[17:28:51.0000] <TabAtkins>
And they aren't the kind of differences that can generally be bridged just by explaining.  You've learned things differently, and prefer different patterns.  Shrug.

[17:29:46.0000] <zewt>
Hixie_: ... he's not dismissing anything, I typed the exact same thing he did (and ^U'd it since he said it first)

[17:30:40.0000] <zewt>
you're saying "if this is your criteria, then this doesn't make sense"; that's *not* his criteria, so that's irrelevant

[17:35:58.0000] <Hixie_>
zewt: i'm specifically referring to e.g. "we've just ignored you and worked around it", "it's not worth explaining to you", "I'm sorry you don't understand", "You just don't accept it.  Shrug.", "I refuse to explain the concept of private state to you", "It's... not worth explaining a basic computer science concept to you", "That argument is decided. The people who say "never" are wrong, and nobody listens to them", "Your argument is invalid", etc

[17:37:49.0000] <Hixie_>
on another note, i'm still curious about the use case for "frozen". nothing in the platform acts like that, does it? what is it for?

[17:38:04.0000] <TabAtkins>
Hixie_: Several of those are seriously basic concepts which I shouldn't have to explain. Wikipedia is an easier reference than asking me.

[17:39:05.0000] <TabAtkins>
I am indeed sometimes sorry you don't understand.  Like I just said, you prefer different patterns, and sometimes seem to have a hard time accepting that patterns you personally dislike are still liked by others, and so things using those patterns are okay to develop.

[17:39:54.0000] <TabAtkins>
The "Your argument is invalid." was a joke, referencing the meme.

[17:41:37.0000] <zewt>
i've thought about using "frozen" in the past; if I remember correctly, it would only throw in strict mode? or was that something else similar to it

[17:41:44.0000] <TabAtkins>
zewt: Yeah.

[17:41:55.0000] <TabAtkins>
It no-ops in sloppy mode.

[17:42:08.0000] <zewt>
(having properties just silently not change seems horribly confusing, so I didn't use it, and strict is useless until every browser supports it)

[17:42:29.0000] <TabAtkins>
zewt: Every modern browser does, no?

[17:42:41.0000] <zewt>
don't know--they didn't when I looked at that feature

[17:43:42.0000] <TabAtkins>
Pretty sure they do now, but I can't name when each got it.

[17:44:44.0000] <zewt>
(i also don't recall why I wanted it, or if I was just looking at it randomly)

[17:52:51.0000] <zewt>
i know I've wanted things like that in Python even recently, eg. where I return an array or a dictionary by reference and I want to make sure the caller doesn't accidentally modify it

[17:53:08.0000] <zewt>
(usually I end up making a deep copy instead, which is usually okay)

[17:54:43.0000] <TabAtkins>
Yeah, but it's silly to have to defensively eat the cost of a copy, when most of the time the caller won't even modify anything. Forcing the cost on the rare modifying cases is better.

[17:56:41.0000] <zewt>
well, as long as the cost is only when you try to modify something frozen, not on everything

[17:58:54.0000] <TabAtkins>
Yeah.

[17:59:29.0000] <TabAtkins>
Otherwise, you're looking at a functional data structure.  Those are pretty interesting, but definitely harder to use. ^_^

[17:59:37.0000] <zewt>
okay, this "es6 template string" thing that somebody randomly linked on the list definitely looks like pointless language bloat

[18:00:54.0000] <TabAtkins>
It's "how do I embed DSLs in JS".

[18:00:59.0000] <TabAtkins>
The answer is "it's complicated", apparently.

[18:01:00.0000] <zewt>
python's formatting model seems simpler and better

[18:01:39.0000] <TabAtkins>
You can process things more powerfully than Python's simply str.format

[18:02:15.0000] <zewt>
don't know about str.format, i mean the '%(x)s' % {'x': foo} thing

[18:02:22.0000] <zewt>
maybe format is the same thing

[18:03:10.0000] <zewt>
that avoids putting code in the string itself

[18:03:33.0000] <TabAtkins>
Yeah, .format is the same thing.

[18:03:36.0000] <TabAtkins>
Preferred now.

[18:03:45.0000] <zewt>
not by me, heh

[18:04:01.0000] <TabAtkins>
Has the nice benefit that you can pass it to map()!

[18:04:21.0000] <zewt>
i've never seen map() used in python except by people who haven't learned comprehensions

[18:04:37.0000] <TabAtkins>
Hah, I've used both.

[18:04:50.0000] <zewt>
in my experience map is 100% always harder to read

[18:07:18.0000] <zewt>
(and I use traditional format strings wherever I can, unless the format string is from an external source or too complex; they're just much more concise and easier to author)

[18:08:24.0000] <zewt>
no comparison between '%ix%i' % (x, y) and '%(x)ix%(y)i' % { 'x': x, 'y': y }

[18:08:47.0000] <zewt>
which is about the level of most inline formatting

[18:13:31.0000] <Hixie_>
so what _is_ the point of freezing?

[18:14:51.0000] <zewt>
well, the Python case I had applies to any language (making sure that people don't modify things accidentally, without having to make a deep copy all the time)

[18:15:34.0000] <zewt>
whether that's a practical issue in JS code I couldn't say, but I've wanted it in other places

[18:16:02.0000] <Hixie_>
can't you just do that with getters and setters?

[18:16:07.0000] <TabAtkins>
zewt: Using .format, it's just "{0}x{1}".format(x,y).  You can use named placeholders instead, passing them as named arguments.  You can also do formatting, but I haven't needed to, so whatever.

[18:16:18.0000] <TabAtkins>
Hixie_: No, because those can be overridden.

[18:16:34.0000] <zewt>
TabAtkins: i don't want to learn a completely different placeholder system; I've been using C-style ones for two decades and I don't have to think about it

[18:17:01.0000] <zewt>
TabAtkins: well, in the "making sure people don't write to this by accident" case, it doesn't matter if there's a back door, it's just to prevent accidents

[18:17:06.0000] <TabAtkins>
zewt: Sure. I haven't ever had to, so I don't care, and I appreciate the visual separation that the {} provides.

[18:17:33.0000] <TabAtkins>
zewt: Sure, but there are some use-cases where you really dont' want a back door, like running untrusted code (what Caja does).

[18:18:17.0000] <zewt>
(most of the cases of trying to protect code from other code in the same context seems unconvincing to me, but I won't claim I've looked at it thoroughly)

[18:18:24.0000] <Hixie_>
TabAtkins: well sure but if people want to screw around...

[18:18:52.0000] <TabAtkins>
zewt: Many are ill-founded, granted, but there are reasonable cases for sandboxing code.

[18:19:32.0000] <zewt>
i know we're not nearly there yet (and may never be, but who knows), but kicking untrusted code into a worker (a completely different context) seems like such a better direction

[18:22:42.0000] <TabAtkins>
Yeah, I'm not familiar enough with the stuff that Caja is used for to know how well that would work.

[18:23:28.0000] <Hixie_>
the caja stuff seems like such a case of wack-a-mole

[18:23:42.0000] <Hixie_>
it's basically retrofitting a security model into something that was never designed with it in mind

[18:26:40.0000] <TabAtkins>
Welcome to the web.

[18:27:23.0000] <Jasper>
I am not reading that scrollback.

[18:27:25.0000] <Hixie_>
which part?

[18:27:30.0000] <Hixie_>
TabAtkins: which part?

[18:27:53.0000] <TabAtkins>
Hixie_: Which part of what?

[18:28:01.0000] <Hixie_>
TabAtkins: if you mean, the web is like that too, then yeah, that's why i don't think doing caja in it is a good idea :-)

[18:28:53.0000] <TabAtkins>
Yeah, I just meant that *everything* on the web is retrofitting onto a system that wasn't designed for whatever it is you're doing. ^_^

[18:29:26.0000] <Hixie_>
well yeah, but security is a case where if you get it slightly wrong, you've lost

[18:29:38.0000] <Hixie_>
unlike most things, where if you get it slightly wrong, you've still mostly won

[19:38:56.0000] <TabAtkins>
Another theoretical benefit of freezing is that it allows harder optimizations - you're guaranteed that the shape of the object won't change after the freeze.

[19:39:42.0000] <TabAtkins>
That's "theoretical" because, afaik, V8 still actually uses the slow path for frozen objects, so freezing gives you *worse* performance.  That's just because of them not going to the effort to fix it yet, not anything intrinsic; there's a bug against them to actually optimize frozen objects.

[19:46:53.0000] <Hixie_>
TabAtkins: are host objects "frozen" in any sense?

[19:47:11.0000] <TabAtkins>
That depends on the object, I guess.

[19:47:19.0000] <TabAtkins>
You can usually put expandos on them, so no.

[19:47:39.0000] <Hixie_>
so freezing isn't for "explaining the platform"?

[20:10:04.0000] <TabAtkins>
I dunno.  I forget exactly what freezing disallows, so it might be needed to explain some things.

[20:13:56.0000] <cabanier>
TabAtkins: it seems that freezing just makes things harder and slower for the v8 compiler

[20:18:04.0000] <TabAtkins>
cabanier: That's for now. It *should* make several optimizations easier and more certain, with no need to reserve the ability to de-optimize.

[20:22:15.0000] <cabanier>
TabAtkins: not sure why that would be. It might make it easier to write code that can be optimized well

[20:22:52.0000] <cabanier>
TabAtkins: from what I understand from v8, it generates code as if the classes are frozen

[20:31:34.0000] <TabAtkins>
Yeah, but it has to de-optimize when you do change things.

[20:32:21.0000] <cabanier>
TabAtkins: it depends, right? In general, it just assumes a new frozen class and generates assembly for that

[20:32:37.0000] <cabanier>
Hixie_: I have to agree with Tab about "dismissing other people's concerns"

[20:33:06.0000] <cabanier>
Hixie_: we've going round and round about how the current path syntax and the stroking algorithm don't work

[20:33:37.0000] <cabanier>
Hixie_: but it seems our concerns are constantly dismissed (with no proof)

[20:43:14.0000] <Hixie_>
cabanier: i thought you'd sent mail that was still in the queue, is it not?

[20:43:34.0000] <cabanier>
Hixie_: queue?

[20:43:45.0000] <Hixie_>
have you sent a mail i haven't replied to yet?

[20:44:13.0000] <cabanier>
Hixie_: yes although it seems like we're stuck in a loop

[20:45:07.0000] <Hixie_>
i am not aware of any loop

[20:45:08.0000] <cabanier>
Hixie_: for instance, I never got a reply on dashing

[20:45:14.0000] <Hixie_>
there's e-mail that i still have to reply to, sure

[20:45:26.0000] <Hixie_>
there's currently 492 e-mails in my queue and 184 e-mails

[20:45:31.0000] <Hixie_>
er, 184 bugs

[20:45:31.0000] <cabanier>
:-)

[20:45:52.0000] <Hixie_>
that's not a loop and it's definitely not dismissing concerns, it's just being slow

[20:45:55.0000] <Hixie_>
i'll happily cop to that

[20:46:02.0000] <Hixie_>
well, not happily

[20:46:07.0000] <Hixie_>
but without reservation

[20:47:01.0000] <Hixie_>
i'm about 2 months lagged right now

[20:47:13.0000] <Hixie_>
on e-mail i haven't intentionally delayed

[20:47:32.0000] <Hixie_>
and about 30 months lagged on e-mail that's blocked on other things

[20:47:41.0000] <cabanier>
Hixie_: yeah, I can believe that you're overloaded :-)

[20:47:55.0000] <Hixie_>
anyway, gotta ga, tv :-)

[20:47:57.0000] <cabanier>
Hixie_: for me, it's hard to make progress

[20:48:27.0000] <cabanier>
Hixie_: since implementors think the issues aren't resolved

[20:48:32.0000] <cabanier>
Hixie_: enjoy!

[21:53:04.0000] <Hixie_>
cabanier: i replied to those e-mails for you

[21:54:34.0000] <cabanier>
Hixie_: thanks!

[22:16:27.0000] <Hixie_>
cabanier: also replied to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23386

[22:23:23.0000] <cabanier>
Hixie_: thanks! replied

[00:17:49.0000] <Ms2ger>
Hixie_, usually when people start with "This is a suggestion to fix major problems relating to developing a more modern application as related to browser history issues.", I give up :)

[00:52:35.0000] <annevk>
Hixie_: FWIW, I don't think everyone in TC39 is convinced Object.freeze() at all should exist. Mark Miller got them through in some compromise decision... Same goes for "use strict" as far as I can tell.

[00:52:49.0000] <annevk>
Hixie_: it's not quite as like-minded as TabAtkins makes it out to be

[00:54:02.0000] <annevk>
Object.freeze() in particular is quite badly designed as it doesn't actually "freeze" objects. It just freezes some of its properties, but not e.g. internal state.

[01:20:45.0000] <annevk>
jsbell: not throwing for non-new makes subclassing harder to support

[01:21:46.0000] <annevk>
jsbell: once IDL is updated to support ES6-style classes that'll be clearer

[01:28:10.0000] <zcorpan>
"Having moved into open standards, DRM is easy to turn off later" http://www.w3.org/2013/04/drm/debate_outline.html

[01:30:29.0000] <Ms2ger>
/me blinks

[01:42:52.0000] <annevk>
o_O

[02:12:44.0000] <nicoo>
Bullshit overflow.

[02:16:16.0000] <MikeSmith>
in Gecko IDLs what does [Throws] mean?

[02:16:27.0000] <annevk>
MikeSmith: it means it can throw an exception

[02:16:45.0000] <annevk>
Still need to talk about bz about that. Might be good for IDL too...

[02:16:51.0000] <MikeSmith>
ok

[02:17:06.0000] <Ms2ger>
/me is skeptical about specs getting it right

[02:17:47.0000] <MikeSmith>
and [GetterThrows] means it can throw on getting?

[02:22:23.0000] <Ms2ger>
Yep

[02:24:00.0000] <MikeSmith>
I see [Constant] in there too, which seems useful

[02:24:21.0000] <MikeSmith>
sorta

[02:24:33.0000] <annevk>
Ms2ger: pretty much everything can throw in theory I guess

[02:24:47.0000] <annevk>
Ms2ger: maybe Gecko could be smarter about it...

[02:24:59.0000] <annevk>
Ms2ger: e.g. if something has DOMString as argument, it can throw...

[02:25:41.0000] <Ms2ger>
Well, the Throws bit doesn't include webidl exceptions

[02:38:02.0000] <annevk>
Ms2ger: ah, see, this is why I should talk to bz

[03:01:26.0000] <smaug____>
MikeSmith: yeah, [Constant] is useful, though often it should be [SameObject] I guess

[03:01:51.0000] <smaug____>
[Pure] is more implementation detail, probably not anything for specs

[03:03:50.0000] <MikeSmith>
what is [Pure]?

[03:04:55.0000] <smaug____>
the getter returns the same value as long as any setters or methods (which might change the underlying data) haven't been called

[03:05:09.0000] <MikeSmith>
ah

[03:07:04.0000] <smaug____>
I wonder if document.images should be [SameObject]

[03:07:26.0000] <smaug____>
and other similar .foos on document

[03:31:22.0000] <jgraham>
zcorpan: You don't happen to remember what features of range-request.php are actually required by the preload tests, so you?

[03:31:26.0000] <jgraham>
*do

[03:32:16.0000] <jgraham>
I am wondering if it is possible to just bake-in support for range requests and then use the pipe features of wptserve to recreate the whole required featureset

[03:32:54.0000] <jgraham>
(the pipe features would give you support for trickling the requests)

[03:33:33.0000] <jgraham>
(the thing that seems most problematic is support for caching)

[03:54:54.0000] <zcorpan>
jgraham: i remember that there are tests that check that e.g. off is fetched by first making a 0-inf range request, then a request at the end, then a request at the beginning again

[03:56:34.0000] <zcorpan>
jgraham: but i don't remember what the whole required feature set is.

[03:58:18.0000] <zcorpan>
jgraham: but i guess stuff was implemented in range-request on a it's-necessary basis rather than it's-possible basis

[04:03:19.0000] <jgraham>
Yeah, I could just do a straight port of course

[04:03:35.0000] <MikeSmith>
dumb question: in WebIDL is there a way to define a property as a direct property of an object rather than a property of its prototype?

[04:04:19.0000] <jgraham>
MikeSmith: I don't remember such a feature (but might be wrong). What's the use case?

[04:08:14.0000] <MikeSmith>
jgraham: No use case. What I'm wondering about very specifically is, in implementations of the Notification API, the "permission" property and "requestPermission" property/function are direct properties of the Notification object, not properties of its prototype.

[04:08:24.0000] <MikeSmith>
so first I wonder why that is

[04:08:57.0000] <MikeSmith>
and second I wonder if there's some reason why the implementations do that, how it could even be expressed in WebIDL

[04:09:18.0000] <jgraham>
Does "implementations" in this case mean blink?

[04:09:28.0000] <MikeSmith>
no gecko as well

[04:09:31.0000] <jgraham>
Hmm

[04:09:45.0000] <jgraham>
I thought Gecko did the prototype thing for IDL properties

[04:09:46.0000] <MikeSmith>
/me doublechecks

[04:10:20.0000] <MikeSmith>
Notification.hasOwnProperty("permission") returns true in gecko too

[04:12:07.0000] <MikeSmith>
while, e.g., Notification.hasOwnProperty("icon") returns false

[04:13:56.0000] <MikeSmith>
so some members of the IDL in the spec become properties of the prototype and others ("permission" and "requestPermission") become direct properties of the object

[04:16:02.0000] <jgraham>
They are properties of the interface object afaict

[04:16:17.0000] <jgraham>
Because they are declared as "static"

[04:16:40.0000] <jgraham>
http://dev.w3.org/2006/webapi/WebIDL/#es-operations

[04:16:50.0000] <jgraham>
"If the operation is static, then the property exists on the interface object."

[04:18:25.0000] <MikeSmith>
ah

[04:19:52.0000] <MikeSmith>
So then I think maybe idlharness.js might not yet have support for recognizing them as such

[04:20:16.0000] <MikeSmith>
it seems to be expecting them in the prototype

[04:20:25.0000] <jgraham>
Since idlharness.js hasn't been updated in several years, that seems quite likely

[04:20:36.0000] <jgraham>
But you didn't have anything else to do today, right? ;)

[04:21:10.0000] <MikeSmith>
haha

[04:21:45.0000] <MikeSmith>
the other thing this makes me wonder about then is, why is the Notification spec defining them as static

[04:22:19.0000] <MikeSmith>
no other specs seem to have IDLs with similar static attributes

[04:22:50.0000] <MikeSmith>
and until recently I think V8 didn't even support them

[04:24:01.0000] <MikeSmith>
hmm actually I guess I can understand why in this specific case

[04:24:21.0000] <MikeSmith>
given the way that the perms mechanism works in Notifications

[04:24:38.0000] <MikeSmith>
I guess the difference is that no other specs are using that kind of mechanism

[04:26:03.0000] <jgraham>
/me wonders how multiple byte ranges are actually supposed to work e.g. what does bytes=1-10,20-30 return? Why does bytes=1-15,10-20 return the same as bytes=1-20?

[04:33:06.0000] <jgraham>
Oh, maybe you just use a funky response type

[04:33:15.0000] <jgraham>
the spec could make that clearer

[05:34:58.0000] <annevk>
MikeSmith: URL.createObjectURL(...) works the same way

[05:35:23.0000] <MikeSmith>
annevk: ah OK

[05:35:58.0000] <MikeSmith>
so fwiw I'm hacking static attribute/operation support into idlharness.js now

[05:36:11.0000] <MikeSmith>
/me looks at URL IDL

[05:36:29.0000] <annevk>
MikeSmith: it's defined in the File API, somewhat confusingly

[05:37:00.0000] <MikeSmith>
ok

[05:37:04.0000] <MikeSmith>
/me looks there

[05:37:14.0000] <zcorpan>
the "don't nest dfn elements" rule helped me find a mistake (i used dfn when i meant var)

[05:37:42.0000] <MikeSmith>
yay

[07:07:07.0000] <zcorpan>
Domenic_: nice presentation

[07:08:06.0000] <zcorpan>
MikeSmith: i added another static method today

[07:08:21.0000] <MikeSmith>
zcorpan: CSSOM?

[07:08:26.0000] <zcorpan>
yeah

[07:10:52.0000] <MikeSmith>
well I got the idlharness support working locally

[07:11:16.0000] <MikeSmith>
so I'll submit a patch for it

[09:39:29.0000] <Hixie_>
annevk-cloud: huh, ok. thanks for the update.

[09:49:13.0000] <bholley>
Hixie_: hey

[09:49:21.0000] <bholley>
Hixie_: now a good time?

[10:17:09.0000] <dglazkov>
good morning, Whatwg!

[10:29:15.0000] <Hixie_>
bholley: hey

[10:29:19.0000] <Hixie_>
bholley: sure!

[10:56:58.0000] <barnabywalters>
where is the best place to ask about potential implications of HTML DRM?

[10:57:33.0000] <TabAtkins>
Depends on what you want. HTMLWG is good if you want frustrating non-answers to any concerns.  Here is okay if you want people venting their spleen.

[10:57:57.0000] <jgraham>
It depends what you mean "implications"

[10:59:04.0000] <barnabywalters>
okay, so the question is: will DRM-protected HTML mean browser extensions can no longer make changes to web UIs, i.e. access+modify the DOM?

[10:59:36.0000] <TabAtkins>
The current DRM efforts are purely about <video>.

[11:00:00.0000] <TabAtkins>
But if we ever do have DRM for HTML itself, then yes, that's almost certainly what it means, or at least it will be severely restricted.

[11:00:04.0000] <barnabywalters>
okay, so all the “DRM will kill view-source” stuff is inaccurate?

[11:00:30.0000] <TabAtkins>
No, eventual DRM will.  The only spec so far (EME) won't, though it's still horrible.

[11:02:25.0000] <barnabywalters>
boooo :(

[11:02:32.0000] <barnabywalters>
okay, thanks

[11:03:20.0000] <barnabywalters>
Can I cite these logs as a source for “DRM will prevent users from being able to take control of their web UIs”, or is there a better source?

[11:05:01.0000] <jgraham>
You could, but that isn't what anyone said, really

[11:05:12.0000] <jgraham>
DRM *for HTML* would do that

[11:05:21.0000] <jgraham>
So far there is no concrete proposal for that

[11:05:25.0000] <barnabywalters>
ah, sorry — noted

[11:05:42.0000] <jgraham>
Although Jeffe Jaffe at W3C has hinted it is something he would like

[11:06:03.0000] <jgraham>
*Jeff

[11:09:00.0000] <jgraham>
(I think. Although I can't find the source for thinking that right now)

[11:11:15.0000] <jgraham>
(hm, it is possible that I was thinking of someone else's characterisation of his position. So probably best ignore me)

[11:15:31.0000] <Ms2ger>
/me submits a /. article about jgraham's claim

[11:17:13.0000] <jgraham>
Ms2ger: It's OK, no one has read /. for about 10 years

[11:18:55.0000] <jgraham>
Ms2ger: More usefully, do Mozilla have anything like .headers files that can match more than one file?

[11:19:10.0000] <Ms2ger>
Not that I know of

[11:19:16.0000] <jgraham>
e.g. if I want to add some header to all html files in a directory

[11:19:21.0000] <jgraham>
Hmm

[11:19:41.0000] <jgraham>
That would seriously improve some of these ported-from-apache cases

[11:22:36.0000] <Ms2ger>
Seems like something useful to add

[11:22:43.0000] <Ms2ger>
Maybe

[11:23:01.0000] <Ms2ger>
I dunno if everything-in-this-dir would be the right granularity

[11:23:24.0000] <jgraham>
No, well apache has a whole load of ad-hoc microsyntaxes for this stuff

[11:23:38.0000] <jgraham>
<FilesMatch "\.(vtt|json)$"> for example

[11:34:03.0000] <niloy>
can someone tell me if transition events are suppose to bubble up?

[11:36:17.0000] <TabAtkins>
niloy: http://dev.w3.org/csswg/css-transitions/#transitionend

[11:37:35.0000] <niloy>
so the problem is, I have 'transitionend' on a parent element which I am interesed in, but a third party component is also using transition inside it

[11:37:46.0000] <niloy>
its bubbling up and messing up my code

[11:38:16.0000] <niloy>
the third party component is simply having transition effects

[11:38:34.0000] <niloy>
how should I handle this case?

[11:39:50.0000] <TabAtkins>
You've gotta figure out some way to distinguish the component's events from the ones you're interested in.

[11:40:59.0000] <niloy>
TabAtkins, okay... thanks, I would assume there are valid use cases for having the event bubble up

[11:41:33.0000] <TabAtkins>
Yeah, it's so you can put a listener on a parent element and listen to events from a bunch of children, rather than having to register individual listeners on everything.

[11:42:24.0000] <niloy>
but that can be said about 'load' & 'focus' too

[11:43:51.0000] <TabAtkins>
Sure.  A lot of events bubble.  Some don't.  The reasoning is often historical.

[11:44:04.0000] <niloy>
okay!

[11:48:31.0000] <bholley>
Hixie_: back again

[11:48:38.0000] <Hixie_>
hey!

[11:48:59.0000] <bholley>
Hixie_: \o/

[11:49:04.0000] <bholley>
oh happy evening

[11:49:22.0000] <bholley>
Hixie_: so, shall we jump in?

[11:49:29.0000] <bholley>
Hixie_: do you prefer PM or here?

[12:02:03.0000] <bholley>
/me pokes Hixie_ 

[12:11:03.0000] <Hixie_>
bholley: here's good

[12:11:08.0000] <Hixie_>
bholley: sorry, got distracted by some bug

[12:11:10.0000] <bholley>
Hixie_: cool

[12:11:12.0000] <bholley>
Hixie_: so

[12:11:23.0000] <Hixie_>
and for some reason had my volume low so didn't hear the beeps

[12:11:23.0000] <bholley>
Hixie_: per my last email, I think we should just do null prototypes for cross-origin objects

[12:11:33.0000] <Hixie_>
that makes things simpler, certainly

[12:11:43.0000] <Hixie_>
though doesn't that mean we need to move everything to the obejcts?

[12:11:56.0000] <bholley>
Hixie_: as in, making things |own|?

[12:12:12.0000] <bholley>
Hixie_: that's a good question. We wouldn't need to in Gecko, but I don't know how to spec that magic

[12:12:13.0000] <Hixie_>
as in, if the prototypes aren't there, then the methods better be somewhere that exists

[12:12:24.0000] <bholley>
Hixie_: I wonder how Blink deals with this

[12:12:30.0000] <bholley>
/me tries to remember if Blink returns null or throws

[12:12:33.0000] <bholley>
/me looks up the bug

[12:13:10.0000] <bholley>
ok, yeah. Webkit/Blink throw

[12:13:19.0000] <Hixie_>
well either way, if you can't look up the prototype...

[12:13:33.0000] <Hixie_>
i guess the automatic lookup could be exempt

[12:13:40.0000] <bholley>
Hixie_: but yeah, anyway. Making them all |own| should be fine, I'd think

[12:13:48.0000] <Hixie_>
(but then we'd still need to talk about the prototype being unique per origin)

[12:13:59.0000] <bholley>
Hixie_: I'm happy to experiment with this in Gecko if you like

[12:14:03.0000] <Hixie_>
making them |own| means putting them on the object directly?

[12:14:03.0000] <bholley>
Hixie_: (making them own)

[12:14:06.0000] <bholley>
Hixie_: right

[12:14:09.0000] <Hixie_>
lgtm

[12:14:19.0000] <bholley>
Hixie_: which isn't visible, given that enumeration is forbidden

[12:14:25.0000] <Hixie_>
instanceof Location would stop working too, i guess

[12:14:30.0000] <bholley>
Hixie_: except for Object.getOwnPropertyDescriptor

[12:14:31.0000] <Hixie_>
if that even works now

[12:14:33.0000] <bholley>
Hixie_: no, it would work

[12:14:39.0000] <bholley>
Hixie_: per heycam's webIDL trick

[12:14:41.0000] <Hixie_>
oh right, webidl does magic for instanceof

[12:14:43.0000] <Hixie_>
forgot about that

[12:14:45.0000] <bholley>
Hixie_: it's not about the prototype, it's the branding

[12:14:45.0000] <Hixie_>
k

[12:14:50.0000] <bholley>
Hixie_: ok, cool. Sorted

[12:14:53.0000] <bholley>
/me adds that to his list

[12:15:04.0000] <Hixie_>
and that affects Location and Window, right?

[12:15:08.0000] <bholley>
Hixie_: correct

[12:15:17.0000] <Hixie_>
ok

[12:15:24.0000] <bholley>
Hixie_: assuming we've since removed Document from the list of XO-available properties

[12:15:31.0000] <Hixie_>
yeah, that's on my list

[12:15:41.0000] <Hixie_>
making contentDocument and other ways of getting Documents throw

[12:15:47.0000] <bholley>
Hixie_: I think the Gecko patch I landed has made it to release

[12:15:48.0000] <bholley>
/me checks

[12:16:19.0000] <bholley>
Hixie_: yes. So proven to be web-compatible

[12:16:26.0000] <bholley>
Mozilla23

[12:16:52.0000] <bholley>
Hixie_: so, moving onto Location

[12:18:06.0000] <bholley>
Hixie_: My proposal has been for both (a) security checks against the BC-principal at the time of invoke/get/set, and (b) security checks against the Document principal at the time of property lookup

[12:18:55.0000] <Hixie_>
let's be very explicit when we talk about origins, rather than using terms like "BC-principal", because that got us into trouble last time we discussed this

[12:19:14.0000] <bholley>
Hixie_: well, my beef is that the expansion of "BC-principal" is super long

[12:19:39.0000] <Hixie_>
well sure

[12:19:46.0000] <Hixie_>
just copy-and-paste :-)

[12:19:58.0000] <Hixie_>
alternatively, we can define them once

[12:20:11.0000] <Hixie_>
and then refer to them by letter or whatever

[12:20:24.0000] <bholley>
Hixie_: "The principal of the document whose Window is the target of the WindowProxy of the same browsing context containing the Window whose Document is associated with the Location object we're discussing"

[12:20:51.0000] <Hixie_>
by "principal" you mean "origin"?

[12:20:55.0000] <bholley>
Hixie_: yes, sorry

[12:21:02.0000] <bholley>
Hixie_: that is my definition of BC origin

[12:21:09.0000] <bholley>
Hixie_: which is a mutable value

[12:21:42.0000] <Hixie_>
so the origin of the active document of the browsing context of the Window of the Document of the Location object being accessed?

[12:22:19.0000] <Hixie_>
what teh spec calls the "relevant Document"? http://www.whatwg.org/specs/web-apps/current-work/#location

[12:22:24.0000] <bholley>
Hixie_: correct

[12:22:51.0000] <bholley>
Hixie_: great

[12:22:55.0000] <Hixie_>
ok

[12:22:56.0000] <bholley>
Hixie_: "relevant document's origin"

[12:23:00.0000] <bholley>
Hixie_: that's a fine term to use

[12:23:08.0000] <bholley>
Hixie_: contrasted with the "owner document's origin"

[12:23:23.0000] <Hixie_>
owner document here being the one Location is associated with

[12:23:28.0000] <bholley>
/me isn't sure if something else should be used in lieu of the word "owner"

[12:23:33.0000] <bholley>
Hixie_: ok

[12:23:40.0000] <Hixie_>
("Each Document object in a browsing context's session history is associated with a unique instance of a Location object")

[12:23:43.0000] <bholley>
"associated document's origin" and "relevant document's origin"

[12:23:49.0000] <Hixie_>
ok

[12:23:51.0000] <bholley>
those terms good?

[12:23:59.0000] <Hixie_>
"good" is relative, but they'll do :-)

[12:24:03.0000] <bholley>
\o/

[12:24:06.0000] <bholley>
so

[12:24:08.0000] <bholley>
reframing

[12:24:35.0000] <bholley>
My proposal has been for both (a) security checks against the relevant document origin at the time of invoke/get/set, and (b) security checks against the associated document origin at the time of property lookup

[12:24:52.0000] <bholley>
Hixie_: IIRC, we at some point agreed on (a), but then the fog may have reappeared

[12:26:20.0000] <Hixie_>
and we're comparing this origin to what, the script's incumbent origin?

[12:26:24.0000] <Hixie_>
incumbent script's origin, rather

[12:26:36.0000] <bholley>
/me pauses to make sure he gets this right

[12:27:00.0000] <bholley>
yes

[12:27:57.0000] <Hixie_>
please hold, verifing...

[12:28:41.0000] <bholley>
/me stirs his split-pea soup

[12:29:14.0000] <Hixie_>
hmm

[12:29:30.0000] <Hixie_>
i disagree with (b), i think

[12:29:47.0000] <bholley>
Hixie_: do you agree with (a)?

[12:29:52.0000] <Hixie_>
i think so

[12:30:04.0000] <bholley>
Hixie_: ok

[12:30:05.0000] <bholley>
so

[12:30:06.0000] <bholley>
b

[12:30:20.0000] <Hixie_>
i think (a) is what i wrote at https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c32 in the four items in the dashed bulleted list

[12:30:55.0000] <Hixie_>
(b) i disagree with because parent.siblingIframeInDifferentOrigin.location.replace(newurl) should work

[12:31:04.0000] <Hixie_>
iirc

[12:31:39.0000] <Hixie_>
but i think this gets to the first paragraph prefixed with # in that same comment

[12:31:49.0000] <bholley>
Hixie_: right - my beef with c32, which is what started this whole discussion, is that you switched _all_ security checks to use the "relevant document origin", when I believe we should only move half of them

[12:31:52.0000] <Hixie_>
if we have that paragraph, we don't need (b) because you can't see any changes the owner document's origin does

[12:32:15.0000] <Hixie_>
the #-paragraphs don't use the relevant origin

[12:32:21.0000] <Hixie_>
they use the owner origin

[12:32:47.0000] <bholley>
Hixie_: in c32?

[12:32:51.0000] <Hixie_>
yeah

[12:32:56.0000] <bholley>
"that's not the same as Location object's associated Document's

[12:32:57.0000] <bholley>
  browsing context's active document's effective script origin."

[12:33:06.0000] <bholley>
Hixie_: that sounds like "relevant document origin" to me

[12:33:25.0000] <bholley>
Hixie_: oh, I misunderstood "#'

[12:34:13.0000] <Hixie_>
basically your (a) is trying to deal with the same attack vector as my 4 "-" paragraphs, and your (b) is trying to deal with the same attack vector s my 2 "#" paragraphs

[12:34:22.0000] <Hixie_>
i think we agree on (a) entirely at this point

[12:34:25.0000] <bholley>
Hixie_: I believe so, yes

[12:34:25.0000] <Hixie_>
and (b) is where we disagree

[12:34:29.0000] <bholley>
roger

[12:34:34.0000] <bholley>
let me mull this for a second

[12:34:35.0000] <Hixie_>
and when i say disagree, i mean you have a proposal, and i don't know shit

[12:34:54.0000] <Hixie_>
because this stuff confuses me a lot :-)

[12:38:48.0000] <bholley>
well, Hixie has a proposal too

[12:39:01.0000] <bholley>
which I believe does indeed solve the same attack vector

[12:39:05.0000] <bholley>
since they're "different objects"

[12:39:22.0000] <bholley>
though

[12:39:54.0000] <Hixie_>
i'm happy, eager even, to consider other ways to solve it

[12:40:19.0000] <Hixie_>
i don't think your (b) really works though, because it prevents parent.siblingIframeInDifferentOrigin.location.replace(newurl) which i'm pretty sure (off the top of my head) should work

[12:40:33.0000] <Hixie_>
i really should develop some console that makes cross-origin testing easier

[12:40:55.0000] <bholley>
Hixie_: why would it prevent replace? replace is allowed cross-origin

[12:41:12.0000] <bholley>
Hixie_: oh, sorry. I guess I'm baking in some assumptions here

[12:41:19.0000] <Hixie_>
heh

[12:41:49.0000] <bholley>
Hixie_: for the security checks I propose in (b), I'm proposing that the cross-origin-accessible properties remain accessible even if the security check fails

[12:42:17.0000] <Hixie_>
the attack i'm worried about is something like origin A does "self.location.replace.secret = document" and origin B tries to get to "thatOtherWindow.location.replace.secret"

[12:42:51.0000] <bholley>
Hixie_: well, per spec, each has a different version of |replace|, right?

[12:43:12.0000] <Hixie_>
well, i'm assuming that's not an assumption i should be making :-)

[12:43:36.0000] <Hixie_>
if we're good with the #-paragraphs (which are what the spec says now), then i think we don't have any need for anything extra to handle (b)

[12:43:47.0000] <Hixie_>
but do we want those paragraphs?

[12:43:55.0000] <Hixie_>
i do not know

[12:44:34.0000] <bholley>
Hixie_: well, those paragraphs aptly describe the Blink/WebKit architecture

[12:44:46.0000] <bholley>
Hixie_: and less-so Gecko's Xray architecture

[12:45:17.0000] <bholley>
Hixie_: I'm happy to keep the spec mostly the way it is, but I'd like to keep the door open spec-wise for Xrays

[12:45:39.0000] <bholley>
since we may do that in Servo too (remains to be seen)

[12:46:24.0000] <Hixie_>
well so long as there's no user-detectable difference, i am happy to open it as wide as a barn door can open

[12:46:39.0000] <Hixie_>
author-detectable, i should say

[12:46:55.0000] <Hixie_>
what would it mean to leave it open for Xrays?

[12:47:08.0000] <bholley>
Hixie_: basically, I'm fine with continuing to orient the security bits of the spec as they are, so long as we're willing to occasionally tweak things one way or another so that they're implementable for us without pulling an Opera ;-)

[12:47:28.0000] <Hixie_>
i certainly wish to do anything possible to ensure the continued existence of gecko

[12:47:38.0000] <Ms2ger>
Heh

[12:47:43.0000] <Ms2ger>
How about Servo?

[12:47:46.0000] <bholley>
Hixie_: and, ideally, implementable for someone else who wants to do the Xray thing with less complexity than Mozilla's baggage requires

[12:47:49.0000] <bholley>
(cough Servo)

[12:48:04.0000] <Hixie_>
Ms2ger: i just want multiple entirely independent browser implementations. the more the better.

[12:48:19.0000] <bholley>
amen

[12:48:23.0000] <Hixie_>
bholley: what would that mean in concrete spec terms?

[12:49:02.0000] <bholley>
Hixie_: so, in a nutshell - the spec describes a world in which we create a separate JS reflection of a given cross-origin object for each origin that observes it

[12:49:26.0000] <Hixie_>
sounds right

[12:49:56.0000] <bholley>
Hixie_: in this world, it doesn't really matter if each origin defines orthogonal sets of properties on the object, because they never interfere with each other

[12:50:18.0000] <Hixie_>
right, though to make it easier to implement, you don't want to allow that, right?

[12:51:06.0000] <bholley>
Hixie_: correct. With Xrays, all the origins look at the same object, but with a special set of glasses that filter out all the crap

[12:51:28.0000] <bholley>
Hixie_: which works well until we start allowing those origins to put their own junk on the object as well

[12:51:47.0000] <bholley>
Hixie_: we do, in fact, have the machinery to do that in Gecko, but I'd like to avoid exposing that to the web

[12:52:03.0000] <Hixie_>
yeah

[12:52:11.0000] <Hixie_>
sounds like what the spec says, right?

[12:52:21.0000] <Hixie_>
or does it need to be even tighter

[12:52:39.0000] <Hixie_>
these glasses apply to everything including function objects like location.replace, right

[12:52:54.0000] <bholley>
Hixie_: correct

[12:53:20.0000] <bholley>
Hixie_: so currently, I don't see what in the spec would prevent each origin from defining funny properties on a cross-origin Location object

[12:53:23.0000] <Hixie_>
and "These objects must have the prototype chain appropriate..." should be changed to say they're null prototypes?

[12:53:28.0000] <bholley>
Hixie_: right

[12:53:30.0000] <Hixie_>
yeah, i was coming to that conclusion too

[12:55:04.0000] <Hixie_>
ok let me try to write some text, one sec

[12:58:43.0000] <cabanier>
Hixie_: "dismissing other people's concerns"

[12:58:43.0000] <Hixie_>
bholley: ok what do you think of https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c50 ?

[13:02:12.0000] <annevk>
bholley: so I was thinking... If ECMAScript were to define the multiple global story, it'd have to tackle some kind of abstract origin concept too, as realms could suddenly become connected or disconnected due to document.domain

[13:02:36.0000] <bholley>
Hixie_: reading

[13:03:16.0000] <annevk>
bholley: and if it does that, it'd have to define how objects referenced across globals were to behave once disconnected, which means we could argue for Gecko's arguably better design to be standardized

[13:04:03.0000] <bholley>
annevk: yeah. I think it's the right approach, but it's a royal PITA for Webkit/Blink to implement

[13:04:34.0000] <annevk>
prolly also Trident

[13:04:58.0000] <annevk>
I wonder what Allen's plan with respect to this is at the moment

[13:05:09.0000] <annevk>
Multiple globals is definitely on the table, but maybe it's not ES6 material

[13:05:26.0000] <Hixie_>
annevk: btw while you're here... what's the story with application/x-www-form-urlencoded? seems URL has some version of it, but not quite the same as HTML?

[13:05:43.0000] <annevk>
Hixie_: my idea was for it to move to URL

[13:05:54.0000] <annevk>
Hixie_: differences might be bugs

[13:06:05.0000] <annevk>
Hixie_: sorry :/

[13:06:57.0000] <Hixie_>
wouldn't that lead to dependencies from URL to HTML?

[13:07:00.0000] <Hixie_>
e.g. for <isindex>?

[13:07:22.0000] <Hixie_>
and accept-charset and so on?

[13:08:18.0000] <annevk>
Hixie_: I figured those would just be parameters to the algorithm

[13:08:36.0000] <Hixie_>
oh so we'd split the algorithm in half?

[13:08:50.0000] <annevk>
Hixie_: e.g. part of the application/x-www-form-urlencoded format

[13:08:59.0000] <annevk>
s/e.g./as in/

[13:11:12.0000] <bholley>
Hixie_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c51

[13:12:19.0000] <bholley>
Hixie_: the only big question there is whether we're willing to disallow property modifications on alien objects

[13:12:24.0000] <bholley>
Hixie_: if we are, I think the rest will work

[13:12:39.0000] <Hixie_>
i am. dunno if others are. :-)

[13:12:42.0000] <Hixie_>
abarth: ping

[13:12:44.0000] <bholley>
Hixie_: it'll involve some hackery on the Gecko end, but stuff I'm totally willing to do to settle the spec stuff on this

[13:13:26.0000] <Hixie_>
bholley: what do you mean by "not be able to define or modify", btw? Throw? No-op? Do whatever freezing does?

[13:14:17.0000] <Hixie_>
annevk: i dunno, it seems like it'd make the algorithms much harder to follow and i don't see the real gain to be had

[13:14:35.0000] <abarth>
Hixie_: hi

[13:14:36.0000] <bholley>
Hixie_: it's up for debate. We currently throw for the cross-origin objects themselves, and don't do any checks on the functions pulled off of them. If we made the functions alien objects, it's probably simplest to do it by Freezing them

[13:14:52.0000] <Hixie_>
abarth: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c50 and 51 and 52

[13:15:09.0000] <bholley>
Hixie_: at which point it probably makes the most sense to cause Location and Window to implement frozen semantics

[13:15:20.0000] <bholley>
Hixie_: which we can probably do

[13:15:24.0000] <Hixie_>
bholley: on the alien versions? makes sense to me.

[13:15:31.0000] <Hixie_>
bholley: what exactly are freezing semantics?

[13:15:38.0000] <bholley>
Hixie_: I don't know - presumably they're defined in ES?

[13:15:49.0000] <annevk>
Hixie_: URL needs the serialization algorithm for URLQuery

[13:16:06.0000] <annevk>
Hixie_: XMLHttpRequest needs it for sending URLQuery to a server

[13:16:15.0000] <Hixie_>
annevk: hm, interesting

[13:16:37.0000] <Hixie_>
annevk: ok, will look more later. might just end up having two versions one for forms and one for the cleaner stuff.

[13:16:48.0000] <abarth>
Hixie_: I don't think we're going to implement that

[13:16:50.0000] <annevk>
Hixie_: for similar reasons I'm afraid I might end up defining multipart/form-data

[13:17:03.0000] <Hixie_>
annevk: larry said he's respeccing that; see the bug

[13:17:08.0000] <Hixie_>
annevk: send him feedback

[13:17:08.0000] <abarth>
Hixie_: that requires JS engine magic

[13:17:19.0000] <annevk>
Hixie_: yeah, I have some private email I need to go through

[13:17:33.0000] <Hixie_>
i have to go to lunch, any change abarth and bholley you can discuss this amongst yourselves while i forage? :-)

[13:17:34.0000] <annevk>
Hixie_: lets avoid multiple algorithms that are essentially the same though

[13:17:45.0000] <abarth>
bholley: hi

[13:17:51.0000] <Ms2ger>
/me finds it pretty funny that Servo has new Comment(), but not document.createComment()

[13:18:08.0000] <abarth>
bholley: I don't really understand the problem you're trying to solve

[13:18:15.0000] <abarth>
bholley: can you help me understand?

[13:18:22.0000] <bholley>
abarth, Hixie_: I actually have to eat dinner

[13:18:29.0000] <abarth>
ok

[13:18:36.0000] <bholley>
abarth: can I ping you back in a little bit?

[13:18:45.0000] <abarth>
sure

[13:18:55.0000] <bholley>
abarth: cool

[13:59:59.0000] <Hixie_>
bholley: (back)

[14:48:59.0000] <Hixie_>
cabanier: you say you're not proposing anything, but aren't you in fact proposing that the spec change?

[14:49:10.0000] <Hixie_>
or did i misunderstand the conversation?

[14:50:09.0000] <cabanier>
Hixie_: I want the spec to reflect reality

[14:50:35.0000] <Hixie_>
reality is there's one browser whose feature that nobody yet uses, no?

[14:50:45.0000] <Hixie_>
s/that//

[14:51:05.0000] <Hixie_>
i mean, i want the spec to reflect reality too, but generally there's two ways to do that.

[14:51:26.0000] <Hixie_>
and if we're not constrained by legacy content, we should pick the better solution.

[14:51:51.0000] <cabanier>
I think we're already constrained

[14:52:07.0000] <cabanier>
ie http://paperjs.org/reference/style/

[14:52:47.0000] <Hixie_>
i don't see what about that page constrains us

[14:52:49.0000] <cabanier>
not sure how paper.js works under the hood but they must already rely

[14:53:03.0000] <cabanier>
on existing dashing behavior

[14:53:29.0000] <cabanier>
pdf.js is shipping too in firefox

[14:53:43.0000] <Hixie_>
paper.js alone wouldn't constrain us, it'd have to be some software built on paper.js that relies on a particular dashing behaviour

[14:53:56.0000] <cabanier>
well, yes :-)

[14:53:57.0000] <Hixie_>
firefox doesn't yet implement the spec's API, so it doesn't constrain us either as far as I can tell

[14:54:26.0000] <cabanier>
they use a prefixed API that's basically the same

[14:54:26.0000] <Hixie_>
the example on http://paperjs.org/reference/style/ really supports justin's proposal, i have to say

[14:54:41.0000] <cabanier>
yeah. it does look nicer

[14:55:33.0000] <cabanier>
but again, if we want to help authors that have existing content, we should follow what the graphics libraries do

[14:55:56.0000] <Hixie_>
if there's existing content, but is there?

[14:56:00.0000] <cabanier>
svg?

[14:56:03.0000] <cabanier>
flash?

[14:56:04.0000] <cabanier>
pdf?

[14:56:09.0000] <cabanier>
gdi?

[14:56:10.0000] <Hixie_>
neither of those are canvas.

[14:56:21.0000] <cabanier>
but people are porting their assets to canvas

[14:56:27.0000] <Hixie_>
and all of those could work with justin's proposal trivially

[14:56:49.0000] <cabanier>
nono, Justin's proposal is actually quite hard

[14:57:08.0000] <cabanier>
and wouldn't match existing SVG assets

[14:57:41.0000] <Hixie_>
because...?

[14:57:53.0000] <cabanier>
?

[14:58:05.0000] <cabanier>
because it would render dashes differently

[14:58:08.0000] <Hixie_>
(i feel our conversations would go much quicker if when you made an assertion, you immediately explained it, rather than waiting for me to prompt you to tell me why you made it)

[14:58:33.0000] <Hixie_>
justin's proposal is to not stop the dashes, unless there's an annotation that says to reset the dash offset, yes?

[14:58:49.0000] <cabanier>
Justin's proposal rearranges dashes so they don't fall on joins or endcaps

[14:58:53.0000] <Hixie_>
so it would be trivial to port any path from svg to canvas, you'd just have to reset the dash offset when you do a moveTo or whichever

[14:59:19.0000] <Hixie_>
oh i just meant his simpler proposal

[14:59:36.0000] <Hixie_>
sure, his more elaborate one would need more in-depth changes.

[14:59:46.0000] <cabanier>
let me look that one up.

[15:00:58.0000] <cabanier>
Justin and I are saying the same thing

[15:02:00.0000] <Hixie_>
that's not how i interpreted his statements but ok, s/justin's proposal/the annotation proposal/

[15:02:27.0000] <cabanier>
annotation proposal?

[15:03:07.0000] <Hixie_>
to not stop the dashes, unless there's an annotation that says to reset the dash offset

[15:03:48.0000] <cabanier>
that's my proposal. right?

[15:04:03.0000] <cabanier>
dashes are reset when you do a moveTo or when you start a new path

[15:04:18.0000] <cabanier>
(new path does a moveTo as well)

[15:06:07.0000] <Hixie_>
in this proposal, moveTo()s would not necessarily be so annotated

[15:06:32.0000] <bholley>
Hixie_, abarth - shall we talk?

[15:06:38.0000] <Hixie_>
cabanier: there'd be an API whereby you can change the moveTo() to reset or not reset.

[15:06:41.0000] <Hixie_>
bholley: sure

[15:06:48.0000] <bholley>
/me looks for abarth 

[15:07:02.0000] <Hixie_>
cabanier: (the default ideally being not to reset)

[15:07:16.0000] <Hixie_>
cabanier: same for anything else that creates a new subpath.

[15:07:17.0000] <bholley>
Hixie_: bz pointed out that freezing won't work spec-wise on Window, given that named properties are dynamic and visible cross-origin

[15:07:34.0000] <Hixie_>
cabanier: you'd presumably also be able to reset anywhere else

[15:07:49.0000] <bholley>
Hixie_: so we could either approximate it, or say that the objects themselves are governed by security exceptions, and (optionally) freeze the methods pulled off of them

[15:07:50.0000] <Hixie_>
bholley: that's one reason i was asking what "freezing" meant

[15:07:51.0000] <cabanier>
I don't think anyone is asking for this behavior.

[15:07:57.0000] <cabanier>
it's super confusing

[15:08:01.0000] <Hixie_>
cabanier: ...

[15:08:38.0000] <Hixie_>
cabanier: i'm asking for the ability to not reset the offset. I'm trying to find a way to make you happy while still preserving the ability to do this. work with me here.

[15:08:49.0000] <cabanier>
ok :-)

[15:09:07.0000] <Hixie_>
bholley: i don't mind how we freeze it, though.

[15:09:16.0000] <cabanier>
I'm pretty sure that apple will object

[15:09:18.0000] <bholley>
Hixie_: what do you think about the Functions?

[15:09:25.0000] <bholley>
Hixie_: null prototypes? Frozen?

[15:09:33.0000] <Hixie_>
bholley: or even if it's different for Window/Location and Functions

[15:09:37.0000] <Hixie_>
bholley: both?

[15:09:44.0000] <cabanier>
they can't implement this since it would rely on measuring the length of the paths which is expensive

[15:09:54.0000] <bholley>
Hixie_: I'm ok with that. The null prototype is necessary to solve the general problem we've been having with prototypes

[15:09:58.0000] <Hixie_>
cabanier: you said that about everyone and then justin disagreed with you, so i'd much rather take their word for it than guess.

[15:10:00.0000] <bholley>
Hixie_: the freezing would just be for consistency

[15:10:34.0000] <Hixie_>
bholley: the freezing would be to allow UAs to not actually have unique objects per origin

[15:10:55.0000] <bholley>
Hixie_: right, that's a very fair point

[15:11:16.0000] <cabanier>
Justin was not disagreeing with me. He wants something in addition to align the dashes

[15:11:23.0000] <bholley>
Hixie_: thanks for thinking of it :-)

[15:11:43.0000] <Hixie_>
cabanier: in the e-mail he just sent, he said he "could easily be convinced otherwise"

[15:12:00.0000] <cabanier>
Hixie_: he sent another one

[15:12:43.0000] <bholley>
Hixie_: in Gecko, we've gotten away with just creating different function objects for each global, but that's not tenable spec-wise

[15:12:52.0000] <Hixie_>
afterwards?

[15:12:53.0000] <bholley>
Hixie_: so yeah, I'm for it :-)

[15:13:15.0000] <Hixie_>
bholley: ok. i think you and i are on the same page (finally! heh, sorry it took so long). but sounds like abarth isn't...

[15:13:24.0000] <bholley>
Hixie_: did you talk to him?

[15:13:34.0000] <Hixie_>
not since you did

[15:13:51.0000] <Hixie_>
i asked him to comment on the bug

[15:14:09.0000] <bholley>
ok. I don't _think_ it should require magic on their end

[15:14:12.0000] <Hixie_>
bholley: i'll rewrite the proposal we came up with in one place so it's easier to comment on

[15:14:18.0000] <bholley>
given what I understand about their engine

[15:14:25.0000] <bholley>
it may be that abarth misunderstood the proposal

[15:14:34.0000] <bholley>
or that I misunderstand the intricacies of their engine

[15:16:03.0000] <TabAtkins>
Regarding "Not covered by traditional media".

[15:16:05.0000] <TabAtkins>
Wut

[15:16:22.0000] <cabanier>
Hixie_: I think the default should be that every moveTo restarts the dash pattern. It's not unreasonable to have a flag that doesn't do so, but I have to think about that

[15:17:08.0000] <Hixie_>
cabanier: again... why? why do you think that should be the default? just because it's the default in other systems?

[15:17:11.0000] <TabAtkins>
Since that matches <path> behavior (I think), that sounds reasonable to me.

[15:17:12.0000] <cabanier>
Hixie_: I've talked to a couple of people here and they think it wouldn't be stable

[15:17:33.0000] <Hixie_>
cabanier: because...?

[15:17:42.0000] <Hixie_>
TabAtkins: that would be a reasonable argument, yeah

[15:18:06.0000] <Hixie_>
TabAtkins: (if there's no other argument and it can be overridden)

[15:18:11.0000] <TabAtkins>
Pretty sure <path> resets the stroke only on new subpaths, which are generated by movetos.

[15:18:12.0000] <cabanier>
Hixie_: I see stephan replied

[15:18:28.0000] <TabAtkins>
But yeah, having some flag for it doesn't sound unreasonable.

[15:18:41.0000] <Hixie_>
cabanier: is he not on the list? i don't see his e-mail

[15:19:08.0000] <Hixie_>
bholley: so we're saying on Window and Location objects cross-origin, and any attempt to set or configure a property should throw?

[15:22:51.0000] <Hixie_>
bholley: probably simpler if we're doing that to just have all the objects behave like that, rather than have Function objects behave differently than Location, no?

[15:25:12.0000] <cabanier>
Hixie_: I got Stephan's mail. did it not go through for you?

[15:25:25.0000] <Hixie_>
i don't see it on http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/

[15:29:02.0000] <cabanier>
Hixie_: he's going to subscribe

[15:29:30.0000] <cabanier>
Hixie_: let me go ask some more people to see what they think.

[15:29:37.0000] <cabanier>
(internally)

[15:29:59.0000] <Hixie_>
cabanier: what would be useful is why they think what they think, not just what they think

[15:38:48.0000] <cabanier>
Hixie_: talked to someone else who gave me a reason why your approach doesn't work.

[15:39:09.0000] <cabanier>
Hixie_: end caps contribute to the length of the path

[15:39:36.0000] <cabanier>
Hixie_: so, if you  cut the path, you add 2 caps which are also dashed

[15:40:09.0000] <cabanier>
Hixie_: so the dashes will no longer line up in your approach

[15:40:20.0000] <cabanier>
Hixie_: I will send an email to make this clearer

[15:41:02.0000] <Hixie_>
the caps aren't dashed, per the spec

[15:41:06.0000] <Hixie_>
they're just caps

[15:41:27.0000] <Hixie_>
TabAtkins: (he's on a week break now)

[15:43:35.0000] <Hixie_>
bholley: you still there? does this look ok? http://junkyard.damowmow.com/523

[15:45:34.0000] <Hixie_>
heycam: your input on http://junkyard.damowmow.com/523 would be good too

[15:45:40.0000] <cabanier>
Hixie_: sorry. talk to Stephan. He said it doesn't matter

[15:45:53.0000] <cabanier>
s/talk/talked

[15:46:16.0000] <bholley>
Hixie_: reading

[15:46:52.0000] <Hixie_>
pretty sure i screwed up Window, specifically the supported property names stuff

[15:47:33.0000] <bholley>
Hixie_: - All the members, including supported property indices and supported property

[15:47:34.0000] <bholley>
  names, must be "own" properties, not on the prototype.

[15:47:43.0000] <bholley>
Hixie_: is that because of other parts of the spec? Or because of this discussion?

[15:47:49.0000] <Hixie_>
because of this discussion.

[15:47:59.0000] <bholley>
Hixie_: oh

[15:48:01.0000] <Hixie_>
specifically, us making prototype=null

[15:48:02.0000] <TabAtkins>
Hixie_: Huh?

[15:48:07.0000] <Hixie_>
bholley: but i'm not tied to it

[15:48:09.0000] <bholley>
Hixie_: but only in the cross-origin case, right?

[15:48:20.0000] <Hixie_>
TabAtkins: the traditional media thing

[15:48:37.0000] <TabAtkins>
Oh, now I can parse your sentence.  A week-long ban.

[15:48:37.0000] <bholley>
Hixie_: I can't tell if this proposal is general or implicitly referring to the cross-origin caser

[15:49:08.0000] <Hixie_>
bholley: oh you want the properties to only be own properties in the Alien Object case?

[15:49:16.0000] <Hixie_>
bholley: general.

[15:49:24.0000] <Hixie_>
bholley: the cross-origin stuff is mentioned explicitly lower.

[15:49:28.0000] <bholley>
Hixie_: oh yeah, I was definitely thinking that this only applied to the cross-origin case

[15:49:32.0000] <Hixie_>
k

[15:50:37.0000] <Hixie_>
bholley: ok, i removed the first item in Location and Window and added the following to the Alien Object definition:

[15:50:40.0000] <Hixie_>
   * promote all the members found on its prototypes, including supported

[15:50:42.0000] <Hixie_>
     property indices and supported property names if any, to "own" properties

[15:50:45.0000] <Hixie_>
     on the object itself.

[15:51:04.0000] <bholley>
Hixie_: link me to a refreshed version?

[15:51:10.0000] <Hixie_>
one sec

[15:51:24.0000] <Hixie_>
reload

[15:51:35.0000] <Hixie_>
(i am actually editing this in a bugzilla textarea, heh)

[15:52:43.0000] <heycam>
what is the reason for making these changes for cross origin objects? I think I overheard bholley mentioning this at the summit but don't remember hearing the reason

[15:53:00.0000] <bholley>
heycam: define "these changes"

[15:53:21.0000] <bholley>
heycam: we're trying to write a spec for cross-origin access that is both secure and implementable

[15:53:21.0000] <Hixie_>
bholley: the reason is "the spec is in looney town right now"

[15:53:25.0000] <heycam>
bholley, the removal of the prototype, making properties not enumerable, moving indexed/named properties to the instance

[15:53:36.0000] <Hixie_>
er, s/bholley/heycam/

[15:53:48.0000] <bholley>
heycam: it's a long story

[15:53:49.0000] <Hixie_>
bholley: (reload again)

[15:53:52.0000] <gsnedders>
How much of the basic DOM stuff comes from NN? Most of it?

[15:53:53.0000] <bholley>
heycam: but for the prototype

[15:54:03.0000] <bholley>
heycam: consider - what do the prototypes look like, cross-origin?

[15:54:11.0000] <Hixie_>
gsnedders: NN and its contemporaneous IE

[15:54:12.0000] <bholley>
heycam: it's a tricky question

[15:54:27.0000] <bholley>
heycam: and in particular, every UA but Gecko currently cops out on that question and either throws or returns null

[15:54:43.0000] <bholley>
heycam: and it's probably easier to make gecko return null than the get the other UAs to implement whatever we cook up

[15:54:47.0000] <heycam>
bholley, can you normally access say window.Object from a cross origin window?

[15:54:53.0000] <Hixie_>
bholley: ok, i think it now also handles the supported property names

[15:54:54.0000] <bholley>
heycam: no

[15:54:58.0000] <heycam>
bholley, ok

[15:55:01.0000] <gsnedders>
Hixie_: Surely a fair bit is NN purely from it shipping with scripting first?

[15:55:03.0000] <heycam>
bholley, makes sense to do something then

[15:55:20.0000] <Hixie_>
gsnedders: "first" back then didn't mean much. it was probably only a matter of months.

[15:56:02.0000] <heycam>
bholley, still, it might be odd to describe the cross origin Window object to have a null [[Prototype]] when the same object, from its own window, does have a prototype

[15:56:12.0000] <Hixie_>
gsnedders: (less than 12 months)

[15:56:22.0000] <bholley>
heycam: trust me, it's going to be odd no matter what we do

[15:56:23.0000] <Hixie_>
gsnedders: (sept 1995 to aug 1996)

[15:56:24.0000] <heycam>
maybe they aren't "the same" object for some definition of same?

[15:56:29.0000] <bholley>
heycam: exactly

[15:56:40.0000] <bholley>
heycam: each origin gets its own view on the object

[15:56:53.0000] <bholley>
heycam: exactly how distinguishable those views are depends on how we spec it and how you implement it

[15:56:54.0000] <heycam>
bholley, aha, so some sort of forwarding proxy object?

[15:56:55.0000] <Hixie_>
"trust me, it's going to be odd no matter what we do" <-- preach it, brother.

[15:57:16.0000] <bholley>
heycam: in Gecko, yes. in Webkit/Blink, it's a separate reflector per origin

[15:57:43.0000] <heycam>
bholley, ok. as long as the spec describes it that way. otherwise describing how [[Prototype]] looks different on the same object is going to be hard to understand. :)

[15:58:04.0000] <gsnedders>
Hixie_: Any idea where I might find any documentation of what's in NN2.03?

[15:58:15.0000] <Hixie_>
gsnedders: not off-hand. try wikipedia's references?

[15:58:39.0000] <Hixie_>
bholley: unless you see anything you think should change, i'm gonna post this to the bug. i need to bail momentarily.

[15:58:43.0000] <gsnedders>
Mostly dead-trees, sadly

[15:58:45.0000] <bholley>
Hixie_: this looks good

[15:58:48.0000] <bholley>
Hixie_: two small nits

[15:58:59.0000] <Hixie_>
gsnedders: yeah

[15:59:18.0000] <bholley>
Hixie_: (1) Given that we'll probably handle functions by freezing them, it will be hard to throw a SecurityError proper

[15:59:36.0000] <gsnedders>
Hixie_: And the university library doesn't happen to have them. Somewhat unsurprisingly. :)

[15:59:49.0000] <Hixie_>
bholley: yeah i was asking about that earlier. you prefer to have two kinds of frozen than just one type of Alien Object?

[16:00:24.0000] <bholley>
Hixie_: I don't know. We could mimic the frozen-ness exceptions on Window and Location, modulo the named property thing

[16:00:39.0000] <Hixie_>
so change the last bullet point to from "were themselves Alien Objects" to "were themselves frozen"? but I don't know what that means w.r.t. their prototype, etc.

[16:00:47.0000] <bholley>
Hixie_: yeah

[16:00:57.0000] <bholley>
Hixie_: it's a tricky detail

[16:01:06.0000] <bholley>
Hixie_: I don't know how best to spec it

[16:01:24.0000] <bholley>
Hixie_: it's just a question of the SecurityError

[16:01:46.0000] <bholley>
Hixie_: like, we could have Window throw the same error that frozen objects throw

[16:01:59.0000] <bholley>
Hixie_: and just swallow the fact that it won't totally behave like a frozen object due to the named properties thing

[16:02:00.0000] <Hixie_>
i know nothing about frozen objects, so i don't know the implications of this

[16:02:26.0000] <bholley>
Hixie_: we can't have Object.isFrozen(xoWin) == true

[16:02:33.0000] <bholley>
because that would imply it never changes properties

[16:02:36.0000] <Hixie_>
my concern is that you not be able to do  "otherWindow.postMessage.prototype.toString = ..."

[16:02:45.0000] <Hixie_>
or whatever hte syntax for that is

[16:03:02.0000] <Hixie_>
beyond that, i don't really care either way

[16:03:08.0000] <bholley>
Hixie_: .prototype? or .__proto__?

[16:03:15.0000] <Hixie_>
whichever is the scary one :-)

[16:03:28.0000] <Hixie_>
i can never remember how all this works

[16:03:48.0000] <bholley>
Hixie_: you need to go and I need to sleep - let's leave this as a (?) now in the spec, and see what abarth thinks about the big picture

[16:03:56.0000] <Hixie_>
k

[16:04:05.0000] <bholley>
Hixie_: we can sort out this detail afterwards

[16:04:16.0000] <bholley>
Hixie_: just wrote "Some sort of error (?)" instead of SecurityError

[16:04:33.0000] <bholley>
Hixie_: feedback+ modulo that

[16:04:37.0000] <bholley>
/me sleeps

[16:07:27.0000] <gsnedders>
Oh dear god. Netscape 2.0 opens up a modal window *for every single JS syntax error*.

[16:08:51.0000] <Hixie_>
abarth: when you have a chance, https://www.w3.org/Bugs/Public/show_bug.cgi?id=13154

[16:18:14.0000] <Domenic_>
gsnedders: I remember that! Back in the days when browsers didn't let you get away with crappy code...

[16:19:49.0000] <gsnedders>
Domenic_: I just tried loading Google.com. I may have invoked kill to get out of Modal Hell.


2013-10-11
[17:11:06.0000] <abarth>
Hixie_: that's a long bug!

[17:11:27.0000] <abarth>
Hixie_: you're asking about what URL pattern to use?

[17:11:36.0000] <abarth>
I think ismap does the comma thing

[17:11:40.0000] <abarth>
or usemap

[17:11:45.0000] <abarth>
whichever it is

[17:23:12.0000] <raj>
the empty value option of a select should have color:#999 just as placeholders do in inputs

[18:13:31.0000] <Hixie_>
abarth: oops, sorry man. i meant the security bug from earlier.

[18:14:03.0000] <Hixie_>
abarth: i meant https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701

[18:14:18.0000] <Hixie_>
abarth: last comment is all you need to look at, really

[18:35:15.0000] <Sympa>
Anyone remember someone called 'aspireonescs'?

[18:49:42.0000] <abarth>
Hixie_: the "Alien Object" thing is problematic

[18:49:52.0000] <abarth>
at least the definition I read earlier

[18:49:59.0000] <abarth>
it seems to require magic on the JS side

[18:53:24.0000] <abarth>
"We're not sure if the last bullet point in particular is enough" <--- it's not

[19:04:00.0000] <abarth>
Hixie_: I left a more extensive comment on the bug

[19:10:42.0000] <Hixie_>
abarth: thanks

[19:21:01.0000] <Hixie_>
abarth: responded

[19:40:43.0000] <abarth>
Hixie_: I replied on the bug :)

[20:43:00.0000] <Jasper>
Hixie_, whoops, I swore I removed whatwg@ from the To: field in gmail.

[20:43:09.0000] <Hixie_>
heh

[20:43:11.0000] <Hixie_>
no worries :-)

[20:43:28.0000] <Jasper>
just to see if I could get him to reply back with more crazy

[20:45:21.0000] <Jasper>
he replied back with "Is hypertext immaterial/imaginary?"

[20:45:28.0000] <Jasper>
which i guess is as good as i ca nget

[21:28:13.0000] <niloy>
I am making a webapp, I want to prefetch font and then make the entire page visible, how can I do that?

[21:32:09.0000] <Hixie_>
don't browsers do that automatically?

[21:32:19.0000] <Hixie_>
oh you don't want to show _anything_ until you have the font?

[21:32:25.0000] <niloy>
yes

[21:32:29.0000] <niloy>
coz it causes that jank

[21:33:09.0000] <niloy>
with Images, it is possible

[21:33:56.0000] <Hixie_>
hm, there's some sort of FontLoader API being developed, maybe that would do it

[21:33:58.0000] <Hixie_>
dunno, sorry

[21:34:23.0000] <Hixie_>
do fonts delay the main 'load' event?

[21:34:36.0000] <Hixie_>
i usually have the opposite problem, i want the text to show before the font is there, and then to swap in the font later when it's here...

[21:34:50.0000] <niloy>
that is good for websites

[21:35:04.0000] <niloy>
but for webapps, I am happy to show a loader

[21:35:43.0000] <niloy>
load all the resources, loading the other pages makes no request to server again

[21:36:21.0000] <niloy>
Example would be a HTML5 game, u dont want to font to load later

[21:36:46.0000] <Hixie_>
mine our games too :-)

[21:36:50.0000] <Hixie_>
are, even

[21:37:23.0000] <niloy>
Oh... that nice, but I hope you agree there is some validity in what am saying

[21:37:55.0000] <Hixie_>
absolutely

[21:38:32.0000] <niloy>
About the FontLoader API, why is a specific api being developed, this can be handled just as Images are handled

[21:38:58.0000] <niloy>
just expose a constructor to JS like Font(), and let us attach a 'load' event to it

[21:39:15.0000] <niloy>
thats how Images are prefetched

[21:40:01.0000] <Hixie_>
yeah i dunno, not my area

[21:40:07.0000] <Hixie_>
annevk-cloud: ping ^

[21:40:13.0000] <Hixie_>
or TabAtkins ^

[21:40:16.0000] <niloy>
oh okay thanks

[00:15:02.0000] <MikeSmith>
jdaggett: ↑

[00:20:20.0000] <MikeSmith>
jgraham: FYI about HTML imports https://code.google.com/p/chromium/issues/detail?id=306292 and https://code.google.com/p/chromium/issues/detail?id=234509

[00:22:13.0000] <MikeSmith>
specific to blink implementation but note Dominic's comment "Custom Elements is blocked on HTML Imports. In general the upgrade ordering problem is quite tricky. Currently it is infeasible", etc.

[00:24:15.0000] <MikeSmith>
actually maybe not necessarily so implementation-specific but perhaps a problem any implementor is going to run into with the current spec. Or maybe even with any spec for this mechanism at all

[00:25:21.0000] <MikeSmith>
because I don't see any suggestion in any of the comments about considering a spec change to address the issue

[01:02:15.0000] <jdaggett>
niloy: fonts are *not* like images

[01:02:26.0000] <MikeSmith>
Ms2ger: when you've got time can you let me know why the first test at http://w3c-test.org/web-platform-tests/submissions/366/notifications/interfaces.html is failing, and what would need to be fixed to make it pass? (e.g., some fix needed to idlharness.js?)

[01:03:12.0000] <jdaggett>
niloy: individual fonts are formed into families, each with weight/slope/width properties

[01:03:38.0000] <Ms2ger>
MikeSmith, in Gecko?

[01:03:46.0000] <jdaggett>
niloy: layout chooses a particular font based on the style of a given run of text

[01:04:12.0000] <Ms2ger>
MikeSmith, https://www.w3.org/Bugs/Public/show_bug.cgi?id=23133

[01:04:14.0000] <jdaggett>
niloy: that's why loading doesn't follow the paradigm of image loading

[01:05:04.0000] <jdaggett>
niloy: as for font loads in current browsers, firefox waits for fonts to load, webkit doesn't

[01:06:01.0000] <jdaggett>
niloy: so for drawing text in canvas you need to use the font loader hacks (e.g. test a given character on timeouts to determine when the font load has completed)

[01:06:47.0000] <MikeSmith>
Ms2ger: yeah in Gecko. (btw in my workspace I now have all the tests there passing in Gecko except that one)

[01:07:00.0000] <MikeSmith>
/me checks Ms2ger url

[01:07:20.0000] <Ms2ger>
heycam|away, so that time you'd spend on IDL... :)

[01:08:53.0000] <MikeSmith>
/me finds https://github.com/w3c/testharness.js/issues/26

[01:09:06.0000] <MikeSmith>
Ms2ger: so there's been no spec change for this yet?

[01:09:23.0000] <Ms2ger>
Nope

[01:10:22.0000] <MikeSmith>
k

[01:11:49.0000] <MikeSmith>
Ms2ger: thanks

[01:12:16.0000] <Ms2ger>
Np

[01:13:42.0000] <MikeSmith>
something for bz to work on before he goes on vacation..

[01:14:27.0000] <Ms2ger>
More like time for heycam to start fixing all the stuff we made him promise to fix last weekend :)

[01:15:48.0000] <Ms2ger>
/me wonders why gsnedders is using NN2

[01:17:51.0000] <Ms2ger>
MikeSmith, and I'll try to look at your PRs later

[01:47:29.0000] <annevk>
Where is bholley?

[01:47:54.0000] <annevk>
When he "cornered" me past weekend about re-parenting we didn't discuss the window.open() case!

[01:48:05.0000] <annevk>
But maybe doing something else for window.open() is okay?

[01:58:46.0000] <annevk>
*crickets*

[02:02:02.0000] <annevk>
http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0173.html is the relevant email

[02:02:12.0000] <MikeSmith>
annevk: looking at Peter Occil's URL parser I see it's not actually doing any error reporting. It might not be too hard to add error reporting to it. I assume the error=true cases in his code are places that the spec defines as errors. So we could throw an exception there with a message instead of just setting that flag.

[02:02:42.0000] <annevk>
MikeSmith: or log a message to an error logger

[02:02:49.0000] <MikeSmith>
or we could just write a URL parser from scratch which maybe also wouldn't be hard to do

[02:02:52.0000] <annevk>
MikeSmith: so you can log multiple errors

[02:03:01.0000] <MikeSmith>
yeah

[02:09:05.0000] <MikeSmith>
though currently the way the microsyntax/datatype checking in the validator is designed, we don't normally emit multiple errors for the same check. i.e., if we're checking an attribute value and find an error at some point we throw and the checking of the rest of value stops. But if we wanted for some case we could buffer the messages and just throw on exception with them at the end of the parsing. I think I may already be doing that in at least one ot

[02:09:24.0000] <MikeSmith>
anyway

[02:22:38.0000] <annevk>
MikeSmith: ah okay

[02:22:54.0000] <annevk>
MikeSmith: you might want to I suppose, makes some sense for style="" too

[02:23:02.0000] <MikeSmith>
yeah

[02:26:35.0000] <MikeSmith>
btw the design of the validator is such that we actually need to work from exceptions. We don't really have an eror logger. Or rather the error-logger type of thing that we do have consumes exceptions. We have errors coming from different places -- some internal code, some third-party code -- and we basically package those up as exceptions and feed them to the eror handler.

[04:06:35.0000] <hellyeah>
hey

[04:07:28.0000] <hellyeah>
do i need to close non-self ending tag in html like <input>

[04:15:20.0000] <jgraham>
What do you mean non-self-ending?

[04:16:56.0000] <hellyeah>
just a sec

[04:17:49.0000] <hellyeah>
there is a disucssion on the web

[04:18:01.0000] <hellyeah>
about <input> tag didnt need to be closed in html5

[04:18:09.0000] <hellyeah>
but it needs to be closed in html4

[04:18:38.0000] <hellyeah>
there is some special tag i believe in html

[04:19:10.0000] <hellyeah>
original question <xqo> do you need to close input tags? [13:57:12] <xqo> <input /> or just <input>?

[04:26:46.0000] <jgraham>
The answer is "either is fine, but one is two characters longer for no reason"

[04:34:55.0000] <odinho>
So, is there some event that has a default action, but it will only run if there is no other handler registered to that event?

[04:35:15.0000] <odinho>
(e.g., you don't have to do event.preventDefault(), it just automatically prevents when you add a new handler)

[04:35:46.0000] <odinho>
(yeah, surprising/no-good, but do we have any legacy like that?)

[04:42:43.0000] <lllllllll>
how can I make video object to show controls?

[04:48:05.0000] <odinho>
<video controls>

[05:39:27.0000] <gsnedders>
Ms2ger: Writing about the history of HTML parsers, and wondering how much of the DOM is in NN2.

[05:39:40.0000] <Ms2ger>
I see

[05:39:53.0000] <gsnedders>
Ms2ger: NN2 is basically only documented in dead-tree form, and I cannot find the correct dead-trees.

[05:41:44.0000] <Ms2ger>
Which dead-trees?

[05:42:41.0000] <Ms2ger>
"Touch Events is a W3C Recommendation"

[05:42:45.0000] <Ms2ger>
Ehehehehe

[05:44:50.0000] <gsnedders>
Ms2ger: Those with NN2 manuals on.

[05:59:22.0000] <jgraham>
gsnedders: Why would you believe the documentation?

[06:11:49.0000] <Ms2ger>
I don't think I've ever seen someone call ArtB "Bart" before

[06:26:57.0000] <annevk>
bholley: so what happens in the window.open() case with old Array objects and such?

[06:27:08.0000] <annevk>
bholley: it seems they too would not change, correct?

[06:27:25.0000] <bholley>
annevk: correct. non-DOM objects have never moved

[06:36:49.0000] <Ms2ger>
Promises?

[06:57:20.0000] <annevk>
bholley: so HTML says a bunch more objects change

[06:57:30.0000] <bholley>
annevk: hm?

[06:57:57.0000] <annevk>
bholley: http://www.whatwg.org/C#dom-document-open step 15

[06:58:33.0000] <bholley>
/me reads

[06:58:36.0000] <Ms2ger>
annevk, that's such a terrible clause

[06:58:54.0000] <bholley>
annevk: "new instances"

[06:59:05.0000] <bholley>
annevk: that doesn't sound like "moving" to me

[06:59:16.0000] <bholley>
annevk: or maybe I misunderstood

[06:59:40.0000] <bholley>
annevk: can you elaborate on your concern?

[07:01:41.0000] <annevk>
bholley: I guess that's different from changing prototype indeed

[07:01:45.0000] <annevk>
bholley: but it's so vague...

[07:02:03.0000] <bholley>
annevk: we just create new ones

[07:02:09.0000] <bholley>
annevk: identity isn't preserved

[07:02:12.0000] <bholley>
annevk: that's the key point

[07:02:23.0000] <bholley>
annevk: the thing that makes document.open() special is that the identity of |document| is preserved

[07:02:25.0000] <bholley>
annevk: but nothing else

[07:02:40.0000] <annevk>
and if you have a reference to the old one things are weird?

[07:02:46.0000] <annevk>
do they represent the same underlying object?

[07:02:52.0000] <bholley>
annevk: there's no old one. They're the same reference. Same object

[07:03:06.0000] <annevk>
sorry, like the old Navigator object

[07:03:43.0000] <bholley>
annevk: oh. yeah

[07:03:47.0000] <bholley>
annevk: I don't know what happens in Gecko

[07:04:20.0000] <bholley>
annevk: my _guess_ would be that it would continue to operate in the old scope

[07:04:36.0000] <bholley>
annevk: or wait

[07:04:40.0000] <bholley>
annevk: navigator doesn't live on the document

[07:04:47.0000] <bholley>
annevk: yeah, so it's just like anything else

[07:04:51.0000] <bholley>
annevk: it operates in the old scope

[07:04:52.0000] <bholley>
annevk: easy

[07:05:03.0000] <bholley>
though the lack of a document is a bit tricky

[07:05:06.0000] <annevk>
is it?

[07:05:14.0000] <bholley>
annevk: is it easy or is it tricky? :-)

[07:05:20.0000] <annevk>
easy :)

[07:05:26.0000] <annevk>
doesn't seem so easy to me

[07:05:47.0000] <bholley>
annevk: yeah, from a spec perspective we should probably just neuter those objects

[07:05:48.0000] <annevk>
basically a huge special case here that changes all kinds of assumed invariants

[07:06:12.0000] <bholley>
annevk: right, for example Navigator sharing a Window with a Document

[07:07:09.0000] <annevk>
getting agreement on concept-node-adopt seems like a good start, document.open() can wait

[07:07:15.0000] <annevk>
that requires a bunch more testing

[07:07:25.0000] <bholley>
annevk: yeah

[07:07:34.0000] <bholley>
annevk: I think neutering is probably the way to go

[07:07:39.0000] <bholley>
annevk: we just need a list of objects to neuter

[07:07:54.0000] <annevk>
and define what neutering means for them

[07:08:30.0000] <annevk>
I wonder how this shit happened

[07:08:37.0000] <annevk>
nobody could ever have thought this to be a good idea

[07:14:55.0000] <MikeSmith>
./topic Welcome to Web platform aka "I wonder how this shit happened. Nobody could ever have thought this to be a good idea."

[07:15:23.0000] <zewt>
i actually googled for a count on the exact phrase "who the fuck thought this was a good idea" a couple days ago (though not in a web context)

[07:15:37.0000] <zewt>
~200k, modulo total meaninglessness of google search result counts

[07:19:53.0000] <MikeSmith>
hah

[07:22:38.0000] <MikeSmith>
what's great is if you google for something like that and you were to find some specific bad idea you're familiar with but then you notice that, way back when, you were one of the people who originally thought it was a good idea

[07:22:49.0000] <MikeSmith>
(just speaking hypothetically)

[07:23:47.0000] <Ms2ger>
Of course

[07:27:43.0000] <MikeSmith>
heh

[07:53:11.0000] <MikeSmith>
Ms2ger: so I'm wondering how much work it would be to add support for callback functions to idlharness.js

[07:53:29.0000] <Ms2ger>
MikeSmith, I have no idea

[07:53:55.0000] <jgraham>
MikeSmith: You don't mean to say you thought the web was a good idea once? Man, egg and your face are in alignment.

[07:54:47.0000] <MikeSmith>
heh

[07:58:48.0000] <zewt>
MikeSmith: what's odd is when you read halfway through a list post, go "wait, I've read this before", then find your name at the top of it from half a decade ago

[08:03:26.0000] <MikeSmith>
zewt: :) yup done that (or something close at least)

[08:04:08.0000] <zewt>
how about when you hit a weird problem, search for it, and the first hit is yourself asking about it on a list years earlier

[08:04:21.0000] <zewt>
that tends to kill any hope of finding a solution

[08:05:41.0000] <Ms2ger>
zewt, how about if there's also a reply from you that's just "I figured it out"?

[08:06:01.0000] <zewt>
i haven't screwed myself over in that particular fashion

[08:13:49.0000] <jgraham>
Hurrah for code commented as "not enabled, not needed at this time" that is actually needed

[08:14:03.0000] <zewt>
someone thought "this time" was a constant value

[08:55:42.0000] <zewt>
the heck? chrome alerts are window-modal?

[08:56:59.0000] <zewt>
seriously, wtf?

[08:57:09.0000] <zewt>
going back to 1998

[10:10:40.0000] <gsnedders>
jgraham: Because it's effort to reverse engineer it, and it more easily gives me something to cite.

[10:37:08.0000] <hober>
so, hey, w3c-css-wg is interesting today.

[10:43:26.0000] <Ms2ger>
██████████████████████████████

[10:43:50.0000] <astearns>
yep

[10:44:48.0000] <MikeSmith>
/me reads to find what the names of the new CSS WG chairs are

[10:44:51.0000] <jgraham>
hober: I think the word you are looking for is "ironic"

[10:44:53.0000] <gsnedders>
hober: Tease. >_>

[10:45:02.0000] <gsnedders>
/me misses having MO access

[10:46:33.0000] <astearns>
given what's in the email, you might expect someone in WHATWG to know about it. But I'm betting that's not the case

[10:49:20.0000] <MikeSmith>
gsnedders: I probably shouldn't say this in non-member space but the news is that we're making Hixie_ the new co-chair of the CSS WG along wih the "is hypertext energy?" guy from the whatwg mailing list

[10:49:42.0000] <MikeSmith>
which I guess is what astearns meant to allude to

[10:50:06.0000] <astearns>
yep yep - the new guy is an amazing catch. Kudos on bringing him in

[10:50:22.0000] <MikeSmith>
/me pats himself on the back

[10:51:20.0000] <MikeSmith>
btw the current chairs of the CSS WG have been promoted to chairing the Tracking Protection WG

[10:55:20.0000] <jgraham>
Word has it that Obama is personally lining up a change to the constitution so that they can run for president

[10:58:01.0000] <MikeSmith>
jgraham: hmm, if you know about that, it seems you have accidentally revealed that you've got Platinum member access to the W3C transit lounge. Either or you're sitting outside the door stealing wifi access.

[11:05:58.0000] <MikeSmith>
in other news I will be talking to a tech report about Web Components in the next few days and am seriously attempting to figure out what claim I can reasonably make about how Web Components can make user experience better for actual end users

[11:06:23.0000] <Ms2ger>
"Not"

[11:07:02.0000] <jgraham>
"dglazkov will love you just a little bit more"

[11:07:20.0000] <jgraham>
Although eperts disagree on whether that is "better"

[11:07:32.0000] <astearns>
jgraham: that's negligible - he already loves everyone so much

[11:08:26.0000] <MikeSmith>
Ms2ger: in my experience reporters tend not to like "not". Instead they like to try to get you to say what they have already decided is the thing they're going to say. And if you don't say it, they paraphrase you in such a way as it sounds like you did.

[11:08:52.0000] <Ms2ger>
Sounds about right :)

[11:09:00.0000] <jgraham>
MikeSmith: I guess you have to make up something vauge about how it will allow more sophisticated web sites

[11:09:21.0000] <jgraham>
Since "sophisticated" is basically a weasle word in this context

[11:09:21.0000] <MikeSmith>
anyway my current plan is to mumble something about "improved UI responsiveness". The rest of time I plan to spend blowing sunshine up the chimney, as the English like to say.

[11:09:31.0000] <astearns>
MikeSmith: making more complex sites easier to create and maintain means less buggy experiences for end users

[11:09:54.0000] <Ms2ger>
MikeSmith, more FOUCs!

[11:10:02.0000] <Ms2ger>
Longer loading times!

[11:10:10.0000] <MikeSmith>
jgraham: it sounds like you have some practice already at blowing sunshine up the chimney. They must teach you guys that in school over there.

[11:10:57.0000] <MikeSmith>
Ms2ger: good brainstorming, we're making progress

[11:11:53.0000] <hober>
make it an environmental issue. FOUCs are becoming more endangered; the components work is an attempt to repopulate the species

[11:14:22.0000] <MikeSmith>
astearns: with my report hat on I find that you're not saying what I want to say. But what I heard you saying is "making more complex sites... buggy experiences for end users"

[11:14:31.0000] <MikeSmith>
so I'll quote you on that

[11:14:47.0000] <MikeSmith>
(didn't even have to paraphrase this time)

[11:15:02.0000] <astearns>
man I'm good at soundbites

[11:15:28.0000] <astearns>
"All of CSS is unnecessary"

[11:15:53.0000] <astearns>
(that's also a direct quote from a W3C presentation of mine)

[11:16:00.0000] <MikeSmith>
headline for the piece: "Web Components Brings Complex, Buggy Experiences for Users"

[11:16:21.0000] <MikeSmith>
astearns: hey I remember that one

[11:16:46.0000] <MikeSmith>
I think I actually requoted that one from you in some slides I used

[11:17:00.0000] <astearns>
heh

[11:20:29.0000] <MikeSmith>
/me prepares "Honk if you love FOUCs" bumper stickers for hober to distribute at the CSS drift-car rallies where he hangs out on the weekends

[11:22:45.0000] <hober>
shit, how did you know?

[11:46:00.0000] <sicking>
Hixie_: ping

[13:18:28.0000] <WesleyMcClane_>
hello, has someone ever considered to standardize the behavior of jquery's .closest() method? something like element.queryAncestor("div.foo[data-test]");

[13:47:25.0000] <Hixie_>
sicking: pong

[13:48:48.0000] <sicking>
Hixie_: what's the proper procedure for giving something priority to get added in spec due to us being about to implement?

[13:49:11.0000] <Hixie_>
just poke me here

[13:49:29.0000] <sicking>
Hixie_: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0142.html

[13:49:36.0000] <Hixie_>
though to be honest right now i've so many things that fall into that bucket that that's basically all i'm working on, so the real question is "how do i get things higher in the list of important things" :-P

[13:49:41.0000] <Hixie_>
/me looks

[13:51:35.0000] <Hixie_>
sicking: are there any other vendors on board?

[13:51:49.0000] <sicking>
Hixie_: so far no one else said anything, good nor bad

[13:52:02.0000] <Hixie_>
so, like requestAutocomplete(), then

[13:52:12.0000] <sicking>
Hixie_: i think there might be others that are interested in the second use-case, i'll try to poke them

[13:52:29.0000] <sicking>
Hixie_: yeah. We're going to have feedback on rAC soon

[13:53:15.0000] <Hixie_>
is "MessagePortAsyncSide" just a "MessagePort"?

[13:53:30.0000] <Hixie_>
i don't really understand this proposal

[13:53:41.0000] <Hixie_>
what problem is it solving? just being able to use message ports synchronously in workers?

[13:53:51.0000] <sicking>
Hixie_: use cases at the bottom

[13:54:18.0000] <Hixie_>
i don't really understand the relationship between synchronous APIs and those use cases

[13:54:22.0000] <sicking>
Hixie_: and answer to the first question is "yes-ish", see the email i'm replying to

[13:54:41.0000] <sicking>
Hixie_: using this API you can use libraries to implement synchronous APIs

[13:55:13.0000] <Hixie_>
the e-mail you were replying to is helpful, thanks

[13:55:30.0000] <Hixie_>
isn't this just going to end up in deadlocks though?

[13:55:50.0000] <sicking>
no, no risk of deadlocks in the traditional sense

[13:56:03.0000] <sicking>
async deadlocks are always possible of course, but that's true with setTimeout too

[13:56:42.0000] <zewt>
most of that fairly long thread was about ways to prevent deadlocks

[13:57:31.0000] <sicking>
preventing deadlocks are actually quite easy

[13:57:55.0000] <sicking>
we can even add more powerful locking mechanisms without risking that. But it's something we can do later if needed

[13:58:02.0000] <Hixie_>
when you post one of these to someone else, does it just turn into a MessagePort?

[13:58:07.0000] <zewt>
it's harder when you want to do it without limiting the API too much

[13:58:36.0000] <zewt>
which I suspect the proposal you quoted does, though it's been a long time and I haven't refreshed yet

[13:58:39.0000] <sicking>
Hixie_: no, the clone stays as whatever type the original object was

[13:58:49.0000] <Hixie_>
what happens when you send a sync one of these to a Window then?

[13:59:30.0000] <sicking>
Hixie_: you can't. See quoted restrictions at the bottom

[14:00:14.0000] <Hixie_>
hm, i see

[14:00:50.0000] <sicking>
Hixie_: i lost one restriction somewhere

[14:01:22.0000] <Hixie_>
note that in the spec now, DedicatedWorkerGlobalScope.postMessage and Worker.postMessage are really the same as MessagePort.postMessage, but I guess we can add some special magic there...

[14:01:25.0000] <sicking>
Hixie_: you also can't call waitForMessage() until one side has been transferred to another context

[14:01:35.0000] <Hixie_>
what if it gets transfered back?

[14:01:48.0000] <sicking>
Hixie_: you can't

[14:02:08.0000] <sicking>
Hixie_: see first quoted restrictions

[14:03:16.0000] <Hixie_>
so if you want to use this, you really have to bear in mind the hierarchy in which you created the workers...

[14:03:53.0000] <zewt>
so in this model, to have a worker block on a lower-level worker, you'd have to create the port in the parent worker (the one that blocks) and hand it down, not create the channel in the lower-level worker and pass it upwards

[14:03:56.0000] <Hixie_>
i have to be honest, if it was up to me, i'd tell people to suck it up and use the async API, especially with Promises and so on on the horizon. But if you get another vendor on board, I shall spec it, as usual.

[14:04:17.0000] <zewt>
(no amount of syntax sugar replaces synchronous programming)

[14:04:22.0000] <sicking>
Hixie_: not sure what you mean by "bear in mind". There are two very precise functions where you can send each type of port. You don't have to bear anything else in mind

[14:05:17.0000] <Hixie_>
sicking: well, generally when you're using MessagePort, especially when you're using it in a capabilities mindset, you'll have zillions of these flying around all over the place and you won't generally want to know what kind of port you're being handed

[14:05:17.0000] <sicking>
Hixie_: asking people to rewrite hundreds-of-thousands-of-lines codebases from sync APIs to async APIs is not really feasible

[14:05:28.0000] <Hixie_>
sicking: but here, you do have to bear in mind what kind of port it is

[14:05:34.0000] <Hixie_>
sicking: e.g. it matters who creates your channel

[14:05:54.0000] <sicking>
Hixie_: that's why you can always check the type

[14:06:07.0000] <Hixie_>
/me wasn't particularly planning on asking anyone to rewrite their codebase

[14:06:18.0000] <Hixie_>
sicking: right, you have to bear it in mind. that's all i'm saying.

[14:06:53.0000] <Hixie_>
anyway, like i said, i'm not the one you have to convince. if you get another vendor on board, file a bug, i'll spec it

[14:07:08.0000] <sicking>
Hixie_: sure. Not hugely different from bearing in mind whether you are holding on to a Worker or a MessagePort

[14:07:21.0000] <Hixie_>
sicking: i would never hold on to a worker, personally.

[14:08:19.0000] <Hixie_>
you don't have to when you can use ports, the great thing about ports is you don't need to know who's implementing the other side.

[14:08:43.0000] <jsbell>
sicking: re: compiling sync codebases down to JS: is task.js-style use of ES6 generators infeasible?

[14:09:38.0000] <sicking>
Hixie_: sure, but the use cases demand a different type of port here. That neccesitates bearing that difference in mind. I don't think we can get around that.

[14:09:55.0000] <Hixie_>
sicking: agreed, if we address this use case, this seems like a well-designed solution.

[14:09:59.0000] <sicking>
Hixie_: but sure, the system is more complicated with two types of channels than one

[14:10:14.0000] <jsbell>
Hrm, now I'm remembering that you have to make everything async-with-generators all the way down, so probably impractical.

[14:10:22.0000] <sicking>
jsbell: that's a good question

[14:10:53.0000] <sicking>
jsbell: i suspect the overhead of making each function call a generator call is too high, but I don't actually know

[14:11:19.0000] <zewt>
the use case of being able to implement blocking APIs for workers in other workers seems more interesting, to me at least

[14:11:36.0000] <sicking>
jsbell: right, the fact that you have to do it everywhere is what makes it hard/slow

[14:11:42.0000] <Hixie_>
jsbell: yeah, i don't think 'yield' really works for this. in part because you can't make the original call from the browser be an invokation of a generator.

[14:12:55.0000] <zewt>
afk, home

[14:12:56.0000] <sicking>
jsbell: do you know if google can comment on compile-to-js strategies? So far my impression is that compile-to-nacl is the strategy?

[14:16:13.0000] <jsbell>
sicking: I have no idea re: strategy, but I'd ping dslomov

[14:18:33.0000] <sicking>
Hixie_: as far as I can tell the four choises we have is to say "please rewrite your code", "please target something like NaCl", "use sync API" or "sorry, the web doesn't support your software". The sync API is the least bad option IMHO. The first and last options are basically equivalent in many cases.

[14:22:22.0000] <Hixie_>
sicking: well, that's a simplification. they have to rewrite it anyway, typically, since the language is different. right? so really the question is, "when porting our software to a vendor-neutral platform, what do we have to do?" and the answers are "a lot of work (you can use this sync API if it helps)" or "a huge amount of work (you'll have to rethink some of your architecture to use async APIs)"

[14:22:40.0000] <sicking>
Hixie_: at some point in the future the "compile existing codebase to web" won't be an important use case. But I think that's only going to be true if we give people an on-ramp to migrate to the web. And the sync-api seems like the least invasive onramp. The alternative is to add a lot of other sync APIs to the platform (sync filesystem, sync IDB, sync websocket etc).

[14:23:13.0000] <sicking>
Hixie_: no, there are tools to complie C++ to JS. So no rewrite is needed

[14:23:28.0000] <Hixie_>
sicking: i think it's already true, personally. but i agree that this api, if we care about that use case, is a reasonable solution. i'm not sure what you're trying to convince me of.

[14:23:47.0000] <sicking>
Hixie_: trying to convince you to add it to the spec :)

[14:24:11.0000] <Hixie_>
sicking: me thinking it's a good idea isn't going to add it to the spec. If that was all it took, requestAutocomplete() would be in already.

[14:24:27.0000] <Hixie_>
sicking: what it takes is two (or ideally, four or five) vendors implementing.

[14:24:45.0000] <Hixie_>
or at least commenting positively.

[14:25:23.0000] <sicking>
ok, i'll see what i can dig up

[14:56:00.0000] <jsbell>
sicking: Hah, my attempt to make a demo using FF + task.js + Workers ran into https://bugzilla.mozilla.org/show_bug.cgi?id=487070

[14:56:25.0000] <sicking>
jsbell: ha!

[14:56:38.0000] <sicking>
jsbell: that bug will be WONTFIX soon

[14:57:01.0000] <sicking>
jsbell: we're working on implementing the new generator syntax, which doesn't need js-version hacks

[14:58:42.0000] <sicking>
jsbell: oh, wait, they already landed!

[14:58:58.0000] <sicking>
jsbell: if you use an aurora or nightly build you should be able to use generators there

[14:59:32.0000] <jsbell>
sicking: nifty

[15:05:27.0000] <jsbell>
sicking: I'm not going to try now, and I bet task.js needs updates, but in theory https://gist.github.com/inexorabletash/6942721 would show what a demo using "yield post" would look like

[15:20:18.0000] <sicking>
jsbell: you might need to use strict mode

[15:20:54.0000] <jsbell>
sicking: I'll also need to toss in function*

[15:39:05.0000] <sicking>
jsbell: doesn't seem like 'let' is working in non-versioned JS in gecko yet :(


2013-10-12
[18:36:20.0000] <Domenic_>
task.js needs major updates i believe, but Q should work well

[18:36:31.0000] <Domenic_>
I think we tested it in workers...

[19:21:53.0000] <MikeSmith>
is the WebGL test suite actually sane and useful or is it still a joke?

[00:37:37.0000] <MikeSmith>
astearns: doubt you're awake but btw I finally got https://www.w3.org/Bugs/Public/xmlrpc.cgi enabled

[00:37:49.0000] <MikeSmith>
I'd been meaning to e-mail you about it

[00:39:22.0000] <Ms2ger>
Yay, xplrpc

[00:39:26.0000] <Ms2ger>
m, even

[00:41:12.0000] <MikeSmith>
yeah not my first technology choice

[00:41:50.0000] <MikeSmith>
but that seems to be the only practically useful interface that bugzilla provieds


2013-10-13
[22:06:15.0000] <tomreyn>
hi there, i'm just looking at http://notifications.spec.whatwg.org/ which is a "living standard". Does this mean it is finalized or that it's in progress work?

[22:06:25.0000] <Hixie_>
both.

[22:06:44.0000] <Hixie_>
that is, it means that it is a standard, but that we maintain it and add to it as needed, so that it remains accurate.

[22:07:04.0000] <Hixie_>
you can think of it as a spec to which errata are applied directly rather than hiding the errata in a separate file.

[22:07:05.0000] <tomreyn>
but that would increase the version number supposedly?

[22:07:10.0000] <Hixie_>
there's no version number.

[22:07:19.0000] <Hixie_>
well, there's a version number in the version repository i guess.

[22:07:21.0000] <tomreyn>
oh right

[22:07:40.0000] <Hixie_>
so like the current version number appears to be 6896a25a22cc7b84b70fd1854e33e0a5874376f9

[22:07:44.0000] <Hixie_>
:-)

[22:07:46.0000] <tomreyn>
i guess that makes it harder to conform with standards

[22:07:53.0000] <Hixie_>
makes it easier, actually.

[22:08:17.0000] <Hixie_>
with a frozen standard, when you find the standard is wrong, you have a choice: conform to the standards and be useless, or break the standards and be useful but don't conform.

[22:08:25.0000] <Hixie_>
with a living standard, the standard changes when you find it's in error

[22:08:30.0000] <Hixie_>
so you conform, and you're useful.

[22:08:51.0000] <tomreyn>
i see

[22:09:13.0000] <tomreyn>
so was it in a draft stage before it became a living standard?

[22:09:25.0000] <tomreyn>
or did it start as a living standard right away

[22:09:41.0000] <Hixie_>
it was in draft stage, but it wasn't ever a whatwg spec back then

[22:10:00.0000] <tomreyn>
you mena like when it was implemented in webkt only

[22:10:05.0000] <Hixie_>
http://books.spec.whatwg.org/ is an example of a spec that's not actually a living standard quite yet but soon will be

[22:10:17.0000] <Hixie_>
hakon labeled it as "[soon to become a] living standard"

[22:10:45.0000] <Hixie_>
and the html spec is a living standard but it has some subparts that aren't quite ready, as documented either by the little boxes on the left or sometimes inline in the text

[22:11:17.0000] <tomreyn>
i see, well thanks for taking the time to explain. :)

[22:12:08.0000] <Hixie_>
np

[06:32:06.0000] <mdik>
?

[07:16:15.0000] <matjas>
is it possible to intercept `innerHTML` calls? `innerHTML` doesn’t seem to be exposed on e.g. `Element.prototype`, or is it?

[07:39:20.0000] <gsnedders>
matjas: Per WebIDL it should be a getter/setter pair. Dunno if anyone impls that?

[07:39:30.0000] <gsnedders>
matjas: Maybe on HTMLElement.prototype?

[07:41:52.0000] <gsnedders>
matjas: In Firefox it's on Element.prototype, at least

[07:43:01.0000] <gsnedders>
matjas: Can't find it in Blink quickly

[08:09:53.0000] <zewt>
holy shit

[08:10:03.0000] <zewt>
gmail just logged me out while I was editing an email and didn't save changes

[08:20:38.0000] <Ms2ger>
matjas, yeah, at least in Gecko that should work

[09:21:41.0000] <niloy>
hey, is this a good place for a feature request related to `addEventListener`?

[09:47:45.0000] <annevk>
https://lists.w3.org/Archives/Member/w3c-css-wg/2013OctDec/0075.html is somewhat surprising to me

[09:55:46.0000] <MikeSmith>
annevk: the last paragraph doesn't really seem coherent but that doesn't seem surprising, considering the source

[09:56:20.0000] <annevk>
uhuh

[09:56:28.0000] <MikeSmith>
seems like it's saying one thing and then saying the opposite

[09:57:17.0000] <MikeSmith>
is that the part that you found surprising, or instead the part about plans to discuss the documents?

[10:05:12.0000] <annevk>
the affiliation part mostly

[10:07:55.0000] <MikeSmith>
yeah

[11:03:02.0000] <Ms2ger>
https://github.com/ianvollick/animation-proxy/blob/master/Explainer.md

[12:55:24.0000] <annevk>
Ms2ger: not mentioned on www-style? ...

[12:56:08.0000] <Ms2ger>
annevk, mentioned what?

[12:56:33.0000] <annevk>
Ms2ger: layout kernel idea you pointed to

[12:57:01.0000] <Ms2ger>
Oh, someone mentioned it in #servo, and I thought people here might be interested too

[12:57:57.0000] <Ms2ger>
Or in the newsgroup, actually

[14:29:11.0000] <Ms2ger>
annevk, bah, I was confused by the fact that the multipage spec wasn't updated

[15:19:12.0000] <Domenic_>
oh no, the multipage spec lags the singlepage one?

[15:23:00.0000] <jgraham>
Only by accident

[15:24:08.0000] <jgraham>
pcwalton has a nice followup post to that article suggesting it is the wrong kind of approach


2013-10-14
[20:38:46.0000] <Hixie_>
Domenic_: it should only lag by about 10 minutes once i commit the changes.

[20:38:53.0000] <Hixie_>
Domenic_: which i usually do straight away.

[20:38:59.0000] <Hixie_>
Domenic_: (though with bigger changes sometimes it takes longer)

[20:39:05.0000] <Hixie_>
Domenic_: but sometimes the script braks.

[20:39:07.0000] <Hixie_>
breaks.

[20:39:31.0000] <Hixie_>
in other news, http://books.spec.whatwg.org/ and http://figures.spec.whatwg.org/

[22:01:08.0000] <tantek>
thanks Hixie. Added: https://wiki.mozilla.org/Standards/license#Example_Specifications

[22:53:55.0000] <Domenic_>
OWFa looks pretty nice.

[23:14:40.0000] <tantek>
Domenic_ OWFa is a decent non-org-specific RF patent declaration.

[02:45:07.0000] <matjas>
tantek: any reason http://javascript.spec.whatwg.org/ is missing from that list?

[04:01:57.0000] <tantek>
matjas - yes. That list is of examples of specs that are licensed with CC0+OWFa.

[04:02:12.0000] <tantek>
http://javascript.spec.whatwg.org/ has no license

[04:04:04.0000] <tantek>
If you can add license text to it like http://fullscreen.spec.whatwg.org/ has (copy the paragraph with <p class="copyright"> ) then we can add it to the list.

[04:04:58.0000] <matjas>
tantek: done

[04:08:49.0000] <tantek>
matjas: and done.

[04:10:23.0000] <matjas>
\o/

[04:12:01.0000] <annevk>
teehee

[05:47:37.0000] <GPHemsley>
/me wonders if it might be time to add the User-Agent string to the HTML spec

[06:49:11.0000] <matjas>
Hixie_: would you mind disabling XSS protection on http://software.hixie.ch/utilities/js/live-dom-viewer/?

[06:50:18.0000] <matjas>
Hixie_: i.e. add a `X-XSS-Protection: 0` HTTP header

[07:59:45.0000] <crocket>
hi

[07:59:53.0000] <crocket>
Is selenium the way to go for web UI testing?

[08:00:13.0000] <crocket>
There are GUI test frameworks that wrap around selenium, which probably means selenium is difficult.

[08:00:31.0000] <crocket>
Robot framework and guitar framework use selenium for web tests.

[08:04:44.0000] <jgraham>
I'm not sure that means selenium is difficult

[08:05:10.0000] <jgraham>
I would have designed it differently, but it seems to be the most widely used solution and is being standardised at W3C

[08:05:41.0000] <crocket>
jgraham, people complain that selenium is difficult.

[08:05:49.0000] <crocket>
Plus, I attended a conference today.

[08:06:07.0000] <crocket>
A speaker said guitar automated lots of tests that couldn't be automated with selenium.

[08:06:18.0000] <crocket>
guitar framework uses selenium.

[08:06:41.0000] <jgraham>
That sounds like there is missing information

[08:06:48.0000] <crocket>
jgraham, like?

[08:07:11.0000] <jgraham>
If guitar (which I have never heard of) was purely selenium based, it would by definition have the capabilities of selenium

[08:07:26.0000] <crocket>
jgraham, Actually, guitar uses selenium IDE.

[08:07:35.0000] <crocket>
It doesn't entirely depend on selenium.

[08:08:10.0000] <crocket>
http://sourceforge.net/apps/mediawiki/guitar/index.php?title=File:Overview.jpg

[08:08:30.0000] <crocket>
If guitar is so good as the speaker said, why is it unpopular?

[08:08:45.0000] <darobin>
if it's good, WTF is it doing on SourceForge?

[08:09:30.0000] <crocket>
The fact that it's written in bash and java sends me a bad signal.

[08:09:32.0000] <crocket>
bash?

[08:09:33.0000] <crocket>
seriously?

[08:10:03.0000] <darobin>
nothing wrong with bash

[08:10:07.0000] <crocket>
Probably bash scripts are just wrapper scripts around java classes.

[08:10:07.0000] <darobin>
but java, seriously?

[08:10:20.0000] <crocket>
darobin, java is ok.

[08:10:31.0000] <crocket>
It is just not as good as other JVM languages.

[08:10:38.0000] <Ms2ger>
Heh, java

[08:10:43.0000] <crocket>
Even PHP has good softwares.

[08:10:53.0000] <crocket>
It's possible to write good softwares in java.

[08:12:34.0000] <crocket>
The development on guitar is slow, too.

[08:13:08.0000] <crocket>
It's ok to have a project on sourceforge still.

[08:15:53.0000] <crocket>
Evidences indicate that selenium might be a better bet.

[08:40:20.0000] <astearns>
MikeSmith: thanks for the bugzilla connection - I'll see about re-enabling my spec script

[09:34:36.0000] <Ms2ger>
marcosc, servo implements DocumentFragment now, beat that ;)

[09:38:10.0000] <annevk>
MikeSmith: for the Encoding component in WHATWG, could you make Bugzilla email www-international for each new and each resolved bug?

[09:38:16.0000] <annevk>
MikeSmith: similar to what we do for DOM

[09:39:23.0000] <annevk>
MikeSmith: FWIW, I discussed this with Richard and Addison

[09:46:05.0000] <MikeSmith>
annevk: yup will do right now

[09:46:20.0000] <annevk>
thanks!

[09:54:04.0000] <jgraham>
odinho: Is there any point to the tests under /IndexedDB/submissions/Microsoft/ or are they entirely covered by the /Opera/ tests?

[09:57:03.0000] <odinho>
Ouch. That question. I have repeatedly looked through the update they did, to see if I could find any new tidbits there. But I have not ever finished, and I seem to forget what I learned every time I don't finish.

[09:57:33.0000] <annevk>
Hixie_: you might want to read http://lists.w3.org/Archives/Public/public-i18n-core/2013OctDec/

[09:58:00.0000] <odinho>
But it's about finding a potential very few assertions not covered in the Opera tests.

[09:59:21.0000] <marcosc>
Ms2ger: I still can't land my patch because of the whitespace issue :(

[09:59:43.0000] <jgraham>
odinho: Hmm

[10:00:05.0000] <jgraham>
It seems like no one has any time to work on IndexedDB tests these days. It's a problem :(

[10:00:14.0000] <marcosc>
Ms2ger: am I really the only person developing on a Mac?

[10:00:42.0000] <odinho>
jgraham: Yeah, -- but there's lots of tests there :P

[10:00:46.0000] <jgraham>
In the short term I just want to know if I can delete http://web-platform.test:8000/IndexedDB/submissions/Microsoft/idbfactory_open.htm

[10:00:46.0000] <Ms2ger>
marcosc, maybe the only one who allows git to mess with their newlines

[10:01:27.0000] <jgraham>
/me always felt that the whole "my VC changes my files" feature was misguided

[10:01:55.0000] <marcosc>
Ms2ger, it's very weird and a little sad :(

[10:02:09.0000] <odinho>
jgraham: Why that file in particular?

[10:02:14.0000] <Ms2ger>
jgraham, that's why it is :)

[10:02:15.0000] <odinho>
I can check.

[10:02:20.0000] <Ms2ger>
odinho, I bet it times out

[10:02:47.0000] <odinho>
jgraham: Yes, I have that assertion.

[10:02:59.0000] <jgraham>
odinho: Does that file actually work for you?

[10:03:09.0000] <jgraham>
It just does nothing here

[10:03:14.0000] <odinho>
jgraham: I didn't test. I just checked if I had the assertion.  https://github.com/w3c/web-platform-tests/blob/master/IndexedDB/submissions/Microsoft/idbfactory_open.htm

[10:03:26.0000] <odinho>
I have another test that tests the exact same.

[10:03:29.0000] <jgraham>
http://w3c-test.org/web-platform-tests/master/IndexedDB/submissions/Microsoft/idbfactory_open.htm

[10:03:51.0000] <odinho>
jgraham: It passes here.

[10:04:11.0000] <odinho>
this is the same test: http://w3c-test.org/web-platform-tests/master/IndexedDB/submissions/Opera/Microsoft-port/idbfactory_open.htm

[10:04:15.0000] <odinho>
Written in another way.

[10:04:24.0000] <jgraham>
Oh. I was sure that was failing on w3c-test.org for me

[10:05:01.0000] <jgraham>
Oooh

[10:05:06.0000] <jgraham>
I disabled output locally

[10:05:23.0000] <jgraham>
Hmm, so it passes for me

[10:05:30.0000] <jgraham>
When I run it by hand

[10:05:50.0000] <jgraham>
So, moving on…

[10:05:57.0000] <jgraham>
odinho: Thanks for your help

[10:22:47.0000] <annevk>
I guess this is kinda new http://tools.ietf.org/html/rfc7034

[10:23:18.0000] <annevk>
IETF standardizing something that exists rather than getting all upset over the prefix and trying to create a new thing that doesn't have it

[10:23:57.0000] <Ms2ger>
Informational, of course

[10:29:04.0000] <annevk>
Well yeah, there's that... I think everyone basically ignores that distinction, unless it happens to be in their advantage not to ignore it.

[10:59:19.0000] <Hixie_>
annevk-cloud: nothing new there, looks like

[11:34:41.0000] <mvujovic>
annevk-cloud: ping

[11:42:34.0000] <smaug____>
annevk-cloud: ping

[11:51:54.0000] <smaug____>
annevk-cloud: nm

[12:25:06.0000] <zewt>
seriously, can anyone give any plausible explanation for chrome suddenly reverting to window-modal alerts, it's maddening and insane

[12:25:33.0000] <zewt>
they did do it (like every other browser since 2009) and i'm not just going crazy, right?

[12:28:22.0000] <odinho>
Hmm. Don't remember the reason, but there was one.

[12:29:03.0000] <odinho>
Of javascript needing to block the entire js execution, -- and chromium is using one process per many tabs now, so it would have to actually stop running of all the tabs.

[12:29:10.0000] <odinho>
that was in the same process.

[12:29:32.0000] <odinho>
So it was better to rather block the whole window, because that is easier for users to understand.

[12:46:19.0000] <zewt>
it's completely batshit insane; tab-modal alerts are one of the single biggest UX improvements in browsers since I've been using browsers

[12:49:39.0000] <zewt>
(meanwhile, Firefox does it in a single-process browser)

[12:56:09.0000] <Domenic_>
complaining about alerts feels like complaining about <marquee>... why are you still using it?

[12:57:15.0000] <miketaylr>
alert() is all over the web, sadly


2013-10-15
[18:07:28.0000] <zewt>
apparently "SIGN UP FOR OUR NEWSLETTER" overlay popups 10 seconds after you start reading a site is making a resurgence

[20:29:43.0000] <kochi1>
MikeSmith: ping?

[20:48:39.0000] <MikeSmith>
kochi1: away from my PC but will be back in 40 minutes or so

[20:55:39.0000] <kochi1>
MikeSmith: ok, talk to you then.

[21:41:32.0000] <Domenic_>
annevk-cloud: or anyone else at Mozilla: I need implementer feedback on an aspect of the ES6 promises spec, along the lines of "is it OK to require your engine to do this kind of optimization?". Who to ask?

[21:51:44.0000] <kochi1>
MikeSmithZ: ping?

[21:51:52.0000] <kochi1>
MikeSmith: ^

[21:52:31.0000] <MikeSmith>
hey kochi1

[21:52:32.0000] <MikeSmith>
back now

[21:52:36.0000] <kochi1>
hi

[21:52:43.0000] <kochi1>
I finalized TPAC plan

[21:52:52.0000] <kochi1>
Will attend Mon and Tue.

[21:52:57.0000] <MikeSmith>
great

[21:53:24.0000] <MikeSmith>
I still need to get my visa

[21:53:43.0000] <kochi1>
As far as I heard from people who attended last year, Mon and Tue will be good enough,

[21:53:52.0000] <kochi1>
What do you think?

[21:54:22.0000] <MikeSmith>
yeah that should be fine

[21:54:35.0000] <kochi1>
As a Japanese, I don't need visa as the trip is short (less than 15 days)

[21:55:09.0000] <kochi1>
okay, and I secured the Wenzhou hotel for that period.

[21:55:48.0000] <MikeSmith>
that's where I'm staying too

[21:56:04.0000] <MikeSmith>
kochi1: do you know who else from your team is going?

[21:56:15.0000] <kochi1>
Kinuko will, definitely

[21:56:52.0000] <kochi1>
and Gary Kacmarcik will.

[21:57:39.0000] <MikeSmith>
ok cool

[21:58:10.0000] <kochi1>
Probably others in Mountain View who I don't know will...

[21:58:14.0000] <MikeSmith>
Kinuko is going to talk about the Quota API mostly? or file-systems stuff too? or something else?

[21:59:00.0000] <kochi1>
I need to ask her :)  to be honest, I don't know...

[21:59:06.0000] <MikeSmith>
ok

[22:00:33.0000] <kochi1>
She replied to ArtB's mail about Quota API, so at least Quota API, I guess.

[22:00:51.0000] <MikeSmith>
OK. about you, I know we want to have you there to talk about the IME API, but you're also involved with some of the DOM events work or something?

[22:01:35.0000] <kochi1>
Definitely for IME API, but optional for DOM L3 events.

[22:01:48.0000] <MikeSmith>
ok

[22:02:45.0000] <kochi1>
I'm attending DOM L3 calls for events like composition events and before input, as it relates to IME API, so I will be there for the DOM events session.

[22:03:11.0000] <rniwa>
is there a place where we can see the list of use cases for web components?

[22:03:24.0000] <rniwa>
I can't find any wiki, etc... that lists all the use cases being discussed

[22:03:30.0000] <kochi1>
but I don't have much to pro-actively present there.

[22:04:00.0000] <rniwa>
maybe http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases ?

[22:06:00.0000] <MikeSmith>
rniwa: yeah, that

[22:07:05.0000] <MikeSmith>
I think also whatever the use cases are, they're the same as whatever the use cases are for AngularJS or Backbone or Ember

[22:11:11.0000] <MikeSmith>
what I still have yet to see any description of is, How will web components make user experience any better

[22:11:56.0000] <MikeSmith>
rniwa: anyway I thought you guys were removing all traces of the web components stuff

[22:12:16.0000] <zewt>
not really the point of a lot of the web, other than as a side-effect of making authoring easier

[22:21:01.0000] <MikeSmith>
a lot of the features that've been added to the platform over the last several years do make user experience better and and it's not hard at all to explain how they make user experience better

[22:22:49.0000] <MikeSmith>
lack of being able to explain how something can make user experience better is the hallmark of stuff like XHTML modularization

[22:23:44.0000] <MikeSmith>
and making authoring easier is no more of a guarantee of better user experience than making programming easier is

[22:23:55.0000] <zewt>
lots of stuff is completely irrelevant to users, except as a side effect (of course, the side-effect of better websites is the ultimate point, but not being directly user-facing is pretty irrelevant)

[22:24:52.0000] <MikeSmith>
I didn't say user-facing

[22:25:35.0000] <zewt>
(that isn't an argument for web components, which I don't know much about, just against the idea that "how does this make UX better" is such a critical factor)

[22:25:58.0000] <zewt>
you said UX, that means user-facing to me :)

[22:26:12.0000] <MikeSmith>
OK, how about the question "hows does this not make UX worse"?

[22:27:22.0000] <MikeSmith>
what I mean is, everything we add can potentially make performance worse

[22:28:22.0000] <MikeSmith>
and it can add implementation complexity that makes it a vector for bugs that users are going to run into

[22:28:43.0000] <zewt>
sure

[22:29:01.0000] <zewt>
"how is this worth the implementation cost" is definitely a fair question for any feature

[22:29:19.0000] <MikeSmith>
for the sake of comparison, consider the implementor argument against <picture><source>

[22:29:23.0000] <MikeSmith>
which is a valid argument

[22:29:51.0000] <MikeSmith>
in terms of the implementation expense, and potential for bugs

[22:30:16.0000] <MikeSmith>
but Web Components is a couple order of magnitude more complex than that

[22:31:23.0000] <MikeSmith>
yet there's not a lot of debate about, Hey, this is going to add a lot of implementation complexity and bug risks, but it's worth it all because it's getting us the really giant win of ... what?

[22:32:34.0000] <MikeSmith>
anyway

[22:34:20.0000] <MikeSmith>
there are other cases where I see a ton of work going  into something but don't seem to understanding by what path it all eventually lead to anything being better for users

[22:34:46.0000] <MikeSmith>
like, the whole idea of browser-engine-based OSes

[22:35:17.0000] <zewt>
well, no disagreement there; those are toys

[22:35:54.0000] <zewt>
(which I have no objection to people playing around with, but it's annoying when we have to fend off the occasional "you should add this to the web so we can have it in our not-web thing" from people who don't understand the ground rules)

[22:39:10.0000] <MikeSmith>
yeah

[02:00:57.0000] <zcorpan>
do we need tests to have unique <title>s?

[02:01:40.0000] <zcorpan>
i guess the answer should be "no"

[02:22:56.0000] <MikeSmith>
zcorpan: I'd say I'd we wanted to require then to be unique, we'd want to provide some mechanism for test writers to check if their test files have unique ones

[02:23:34.0000] <MikeSmith>
*if we wanted

[02:24:25.0000] <zcorpan>
yeah but why would we want to?

[02:26:32.0000] <zcorpan>
i can understand that we want unique titles of test() within a file, so that it's clear what result belongs to which test and so that it doesn't get confusing if one test happens to finish before another, etc

[02:27:34.0000] <zcorpan>
but for different files there's no ambiguity and it's not useful to spend time beating test writers over their <title>s if the test runner can figure it out anyway

[02:27:51.0000] <jgraham>
For different files there is no requirement of global uniqueness

[02:28:16.0000] <zcorpan>
ok, good :-)

[02:28:17.0000] <jgraham>
(test_url, title) needs to be unique for th.js tests and (test_url, ref_url) for reftests

[02:28:40.0000] <jgraham>
Did anyone suggest otherwise?

[02:29:16.0000] <zcorpan>
no i was just looking at a review with dup <title>s and wondered whether to raise an issue

[02:29:23.0000] <jgraham>
OK

[02:29:51.0000] <jgraham>
Just wondering if someone was wrong on the internet :)

[02:30:44.0000] <zcorpan>
i've already spent my 386 time of the day on other stuff

[02:43:12.0000] <annevk>
smaug____: "But the spec should be more clear." I'm not sure what you want me to do

[02:43:19.0000] <annevk>
re: https://bugzilla.mozilla.org/show_bug.cgi?id=926208

[02:46:32.0000] <smaug____>
annevk: let me find the right place in the spec...

[02:47:20.0000] <annevk>
So that part of the specification will likely change... Once I integrate XMLHttpRequest with Fetch which I've been saying I'll get to since forever...

[02:47:33.0000] <smaug____>
"When the time has passed, if the synchronous flag is unset, a timeout event will then be dispatched"

[02:47:37.0000] <smaug____>
that is non-normative

[02:47:45.0000] <smaug____>
but still hints that the event will be there

[02:47:51.0000] <jgraham>
MikeSmith: FWIW one of the points of FirefoxOS is that it forces us to work out what extra web APIs are needed so that web-based apps an have all the same features as android or iOS specific apps. And having cross-platform apps (possibly just "installed" by navigating to a url) is a win for users in much the same way that having websites rather than native apps has been

[02:47:55.0000] <smaug____>
even if the request has succeeded

[02:48:52.0000] <smaug____>
hmm, when was TimeoutError added

[02:49:30.0000] <smaug____>
ah, it is for workers only. that is ok

[02:51:14.0000] <smaug____>
annevk: so I guess that non-normative text should indicate that timeout event or exception will be there only if the fetch hasn't ended or something

[02:55:42.0000] <annevk>
So the specification is clear, it's just non-normative descriptions biting us...

[02:55:55.0000] <annevk>
I'm getting ever closer to just doing away with them

[02:57:48.0000] <smaug____>
yeah, I think the bug reporter just read the non-normative part and expected timeout to work the way non-normative text defines it to work

[02:58:55.0000] <smaug____>
ah, is blink improving their webidl support too

[02:59:45.0000] <annevk>
Yeah they've been doing that for a while

[03:00:16.0000] <annevk>
It's one of the things pilgrim was working on when Blink was still called WebKit

[03:00:20.0000] <annevk>
Not sure if he is still

[03:02:06.0000] <smaug____>
I guess they've seen the awesomeness of Gecko's webidl stuff :)

[03:03:54.0000] <annevk>
That must've been it

[03:04:05.0000] <annevk>
smaug____: added a sentence to that unclear XHR sentence

[03:04:34.0000] <annevk>
smaug____: I note you didn't close the bug as INVALID though

[03:04:53.0000] <smaug____>
annevk: well, there isn't a testcase

[03:05:02.0000] <annevk>
fair

[03:05:02.0000] <smaug____>
so I was hoping to see that before closing

[03:05:34.0000] <smaug____>
I guess I should close it and ask reopening if needed

[03:15:14.0000] <annevk>
Man, multiple globals are a bitch

[03:22:19.0000] <jgraham>
Just as well they were invented in the past, really

[03:22:32.0000] <jgraham>
Otherwise we wouldn't be allowed nice things for theoretical reasons

[05:13:58.0000] <annevk>
Hixie_: I decided to reply to Jeff: http://lists.w3.org/Archives/Public/public-i18n-core/2013OctDec/0013.html

[05:14:08.0000] <annevk>
Hixie_: I added you in the cc, if you want to add something

[05:16:26.0000] <annevk>
Domenic_: try Jason Orendorff maybe?

[05:17:06.0000] <annevk>
Domenic_: Andrea Marchesini implemented promises atm, but not in SM

[05:17:41.0000] <annevk>
mvujovic: pong

[05:43:59.0000] <Domenic_>
annevk: ok cool. and is http://wiki.whatwg.org/wiki/Who_to_ask_about_stuff correct that travis leithead is the appropriate MS contact?

[05:44:20.0000] <annevk>
Domenic_: yeah, he'll know who to ask internally anyway

[05:52:06.0000] <annevk>
Domenic_: instead of http://url.spec.whatwg.org/#dom-url "SyntaxError", a JS TypeError would be appropriate, right?

[06:07:12.0000] <zcorpan>
people sure like to bikeshed about naming

[06:09:13.0000] <darobin>
I don't think that bikeshed is the right name for it

[06:09:28.0000] <Ms2ger>
darobin++

[06:09:55.0000] <gsnedders>
To quote someone, "Does Opera support the `bikeshed` CSS property?"

[06:10:06.0000] <gsnedders>
From when there was a bikeshed CSS property defined.

[06:10:11.0000] <Ms2ger>
Opera had it first

[06:10:22.0000] <zcorpan>
that's right

[06:13:52.0000] <zcorpan>
matjas: https://github.com/mathiasbynens/cssesc maybe the default for isIdentifier should be true, given http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0075.html ?

[06:25:03.0000] <zcorpan>
matjas: also, i think ascii-only usually isn't necessary

[06:33:03.0000] <matjas>
zcorpan: cssesc mirrors https://github.com/mathiasbynens/jsesc in that it has options to enable more aggressive escaping. making this change would change that

[06:33:23.0000] <zcorpan>
matjas: ah

[06:33:30.0000] <matjas>
that said, thanks for the info — I’ll happily create a `CSS.escape` polyfill

[06:33:52.0000] <zcorpan>
cool

[07:04:15.0000] <zewt>
zcorpan: my favorite is the "i don't want to bikeshed, but how about [list of names]"

[07:04:30.0000] <zcorpan>
zewt: heh

[07:09:55.0000] <jgraham>
In the future I plan to say "I love nothing more than a good bikeshed! I brought 17 different suggestions for paint^Wnames!". That should convince everyone else to agree on one sensible one very quickly

[07:10:13.0000] <annevk>
That's how we ended up with querySelector()

[07:10:15.0000] <annevk>
Don't do that again

[07:14:31.0000] <m4nu>
annevk: What spec should we reference for Promises? We have JSON-LD going to PR soon, we need to non-normatively reference something.

[07:14:42.0000] <darobin>
there's always the Voting Off the Island process, it takes time but at least it makes bikeshedding names fun

[07:14:46.0000] <annevk>
m4nu: https://github.com/domenic/promises-unwrapping/blob/master/README.md

[07:14:56.0000] <m4nu>
ok thanks

[07:14:59.0000] <darobin>
we need a way of running that as a service

[07:15:56.0000] <zcorpan>
annevk: it's not in es6 yet?

[07:16:16.0000] <annevk>
zcorpan: no, subclassing woes

[07:21:25.0000] <m4nu>
annevk: Is there any copyright concern over that document? Can we make a static copy of it at W3C? Sandro is saying that ECMA had an issue w/ the public domain assertion on the document (Dom's employer has a copyright assertion on it?)

[07:21:47.0000] <m4nu>
annevk: we're trying to figure out if we can archive the document at W3C to refer to it non-normatively.

[07:24:53.0000] <annevk>
m4nu: why can't you just refer to the repo?

[07:25:19.0000] <annevk>
m4nu: ECMA's concern is not about copyright, but about non-Member contributions

[07:25:47.0000] <annevk>
m4nu: euhm, Ecma's*

[07:28:16.0000] <Domenic_>
m4nu: it's CC0

[07:28:33.0000] <Domenic_>
m4nu: I got employer approval for that on Sunday, legal document signed and all.

[07:29:51.0000] <Domenic_>
annevk: SyntaxError seems OK to me, it's used for e.g. bad JSON, but I think Allen doesn't like using SyntaxError for non-JS-syntax errors, so in that case TypeError is probably best.

[07:30:01.0000] <annevk>
Domenic_: right

[07:30:27.0000] <annevk>
Domenic_: it wasn't using SyntaxError, it was using DOMException whose name is SyntaxError

[07:34:25.0000] <Domenic_>
what about URIError?

[07:36:18.0000] <annevk>
heh

[07:36:32.0000] <annevk>
that whole API is kinda flawed

[07:36:39.0000] <annevk>
I rather not build on top of it

[07:39:50.0000] <zcorpan>
annevk: <http://www.w3.org/mid/52570E9C.2040606⊙nc>

[07:40:39.0000] <annevk>
zcorpan: he seems confused

[07:41:09.0000] <zcorpan>
i'll let you deal with it :-)

[07:41:48.0000] <annevk>
zcorpan: doesn't seem like something I want to step into

[07:42:32.0000] <annevk>
oh look

[07:42:38.0000] <annevk>
http://lists.w3.org/Archives/Public/public-webrtc/2013Oct/0019.html W3C bullshit strikes again

[07:42:47.0000] <annevk>
I don't even...

[07:43:10.0000] <annevk>
zcorpan: I'm having this problem: https://twitter.com/gsnedders/status/390101791389413376

[07:43:12.0000] <matjas>
zcorpan: what should `CSS.escape()` do when called without any parameters?

[07:43:55.0000] <annevk>
I addressed one issue that needed fixing today, the rest was all email explaining stuff :/

[07:44:50.0000] <zcorpan>
matjas: what do you think it should do, from a webdev perspective?

[07:45:11.0000] <matjas>
zcorpan: return the empty string

[07:45:49.0000] <zcorpan>
currently it throws TypeError per webidl i think. also if you pass `undefined`

[07:46:09.0000] <zcorpan>
but i can make it empty string instead

[07:46:39.0000] <zcorpan>
matjas: any rationale for empty string?

[07:49:28.0000] <matjas>
just seemed more useful than throwing

[07:50:00.0000] <matjas>
but either way it should probably match passing `undefined`, so maybe letting it throw is better

[07:51:08.0000] <annevk>
you can make omitting the same as passing ""

[07:51:14.0000] <annevk>
which means undefined is the same as passing ""

[07:51:33.0000] <matjas>
in that case the return value would have to be the empty string

[07:52:11.0000] <annevk>
escape(optional DOMString foo = "") seems reasonable

[07:53:45.0000] <Domenic_>
agree, that matches doing a ToString on the argument. `String(undefined) === ""`.

[07:53:52.0000] <Domenic_>
Note that `String(null) === "null"`

[07:55:04.0000] <annevk>
Domenic_: no...

[07:55:10.0000] <annevk>
Domenic_: String(undefined) === "undefined"

[07:55:27.0000] <Ms2ger`>
^

[07:55:29.0000] <Domenic_>
Oh drr

[07:56:10.0000] <Domenic_>
Well then I think CSS.escape(undefined) === "undefined" is best, but CSS.escape(undefined) === "" is OK, you would do `CSS.escape = (s = "") => { do escaping... }

[07:56:25.0000] <Domenic_>
But CSS.escape(null) definitely should be "null"

[07:57:00.0000] <matjas>
Domenic_: so you’re saying ES ToString() should be applied to the argument values?

[07:57:11.0000] <matjas>
/me reads up

[07:57:22.0000] <matjas>
uhm, yeah, you literally did just that, ignore me

[07:57:47.0000] <annevk>
well that's already the case for DOMString

[07:58:07.0000] <annevk>
Domenic_: I think treating undefined as omitted is better; otherwise you get different results for CSS.escape()

[07:58:29.0000] <Domenic_>
CSS.escape(undefined) === CSS.escape() === "undefined" is my proposal

[07:58:48.0000] <annevk>
ew

[07:58:51.0000] <matjas>
that doesn’t seem very useful

[07:59:01.0000] <matjas>
(although it does align with ES ToString)

[07:59:06.0000] <Domenic_>
it's most idiomatic I think

[07:59:27.0000] <Domenic_>
It's what happens to most ES spec functions when you pass them undefined/omit the value and they expect a string

[08:00:24.0000] <matjas>
that is true, but given how CSS.escape is supposed to be used empty seems more useful

[08:00:24.0000] <Domenic_>
"undefinedX".startsWith() === true

[08:00:56.0000] <matjas>
CSS.escape(element.somePropertyThatIsUndefinedByAccident)

[08:01:23.0000] <Domenic_>
Wouldn't you want to see the "undefined" so that the accident becomes apparent?

[08:01:37.0000] <jgraham>
You would want it to throw :p

[08:01:40.0000] <matjas>
hmm, maybe

[08:01:53.0000] <Domenic_>
"undefinedX".replace(undefined, "foo") === "fooX"

[08:02:02.0000] <zcorpan>
TabAtkins: what's the webidl support in bikeshed like?

[08:02:18.0000] <Domenic_>
"xundefined".indexOf() === 1

[08:03:10.0000] <jgraham>
Domenic_: I don't think it's controversial that it's what the builtins typically do

[08:03:34.0000] <jgraham>
I think the only controversy is whether those mistakes therefore have to be propogated to all APIs

[08:03:43.0000] <zcorpan>
please file a bug when you've figured out what should happen (if it's different from what the spec has now) :-)

[08:04:13.0000] <matjas>
I’ll just write the tests based on the current behavior (i.e. throwing as per WebIDL) and we’ll go from there

[08:04:29.0000] <Domenic_>
Don't throw :(

[08:05:47.0000] <jgraham>
Is there a reason not to throw except the (in this case rather weak, I think) consistency argument?

[08:07:23.0000] <Domenic_>
throwing is unexpected... very unlike the rest of the platform or any user-space libraries. nobody does argument validation, they just use the values they're given.

[08:07:45.0000] <matjas>
i argued for "" not because of consistency with ES built-ins that use ToString but rather because it seemed more useful

[08:08:37.0000] <matjas>
handles the edge case of `undefined` / no params more gracefully

[08:09:10.0000] <jgraham>
Since passing invalid values is by definition an edge case and typically a mistake that kind of consistency seems rather misguided. Instead you should focus on how to make the best API possible given the constraints and the infrastructure

[08:09:13.0000] <matjas>
but as Domenic_ said, “Wouldn't you want to see the "undefined" so that the accident becomes apparent?” → the way to really make that apparent is to throw an error

[08:09:54.0000] <Domenic_>
jgraham: I think the definition of best API as defined by ES programmers is to not throw and to coerce instead. This is standard practice and I am unsure why it is getting pushback.

[08:10:19.0000] <jgraham>
Saying "well typical js authors are too lazy / don't have a convenient way to validate arguments so no one else should either" seems like a race to the bottom

[08:10:47.0000] <jgraham>
Domenic_: You haven't made the argument for that being the "best" API

[08:11:12.0000] <jgraham>
It is closest to the stdlib (which is rather tiny), but that has unfortunate compat constraints

[08:11:14.0000] <Domenic_>
I guess I don't really see the need to, this is just common JS API design knowledge. See e.g. Effective JavaScript.

[08:11:42.0000] <jgraham>
It might be what js authors do, but that reflects the lack of effective tools for doing other things

[08:12:02.0000] <Domenic_>
right, if we were using another language, we would do something differently. but JS is our tool so we do things the JS way.

[08:12:23.0000] <jgraham>
Even if, per your own criteria, it is not actually best for authors?

[08:12:24.0000] <Ms2ger`>
Badly?

[08:12:26.0000] <Domenic_>
maybe talk to the dart folks to make sure they establish your preferred throwing idiom as the darty way

[08:12:41.0000] <jgraham>
I have exactly no interest in dart

[08:12:58.0000] <Domenic_>
you clearly have an interest in doing JS "better" (according to you...)

[08:13:18.0000] <jgraham>
I have an interest in making the APIs as good as possible for authors

[08:13:29.0000] <jgraham>
Consistency is only one facet of goodness

[08:13:56.0000] <jgraham>
If this were a common case I would agree that consistency on its own would obviously be a winning argument

[08:14:06.0000] <jgraham>
But it is, by definition an edge case

[08:15:02.0000] <jgraham>
Also, I think it is more consistent with other DOM functions

[08:27:37.0000] <TabAtkins>
zcorpan: Bikeshed parses the webidl (it throws errors for invalid stuff, but should gracefully handle unknown stuff that doesn't otherwise invalidate the basic structure of the grammar.

[08:28:06.0000] <TabAtkins>
zcorpan: Then it spits out marked-up text with either <a> or <dfn> around all the relevant things, based on whether it can find a definition for each term somewhere else or not.

[08:28:22.0000] <TabAtkins>
zcorpan: And that's it.  It does this for everything with <pre class=idl>.

[08:51:43.0000] <zewt>
Domenic_: it has nothing to do with what I'm doing; web pages use it, and I use web pages

[08:51:55.0000] <zewt>
(re: window-modal alerts)

[09:05:21.0000] <annevk>
jamesr__: that guy on blink-dev...

[09:09:39.0000] <jgraham>
marcosc_: I don't see why it matters if some other files you are not committing are marked as modified?

[09:09:47.0000] <jgraham>
What's the actual problem?

[09:10:21.0000] <marcosc_>
jgraham: the problem is that when I clone the repo, git rewrites all the files that have a LFCR

[09:11:12.0000] <jgraham>
You mean a CRLF?

[09:11:13.0000] <matjas>
Domenic_, jgraham, zcorpan, annevk: `CSS.escape(number)` might be a good reason to coerce the arguments to strings after all

[09:11:39.0000] <marcosc_>
jgraham: yeah, sorry

[09:11:41.0000] <annevk>
matjas: coercing to string is not really contested I think

[09:11:49.0000] <marcosc_>
/me having too many conversations at the same time

[09:12:23.0000] <jgraham>
marcosc_: Pretty sure you should be able to disable that, but what, concretely, is the problem? You can't build?

[09:12:40.0000] <marcosc_>
jgraham: I can't commit

[09:12:44.0000] <matjas>
annevk: but coercing to string implies that `CSS.escape(undefined) === CSS.escape("undefined")` which is what the entire discussion was about

[09:12:48.0000] <Domenic_>
annevk: matjas: agreed, coercion to string is not contested. The question is whether to add `= ""` so that CSS.escape() or CSS.escape(undefined) give "" instead of "undefined". I think it's unnecessary but it's a pretty minor part.

[09:13:09.0000] <annevk>
matjas: no, the discussion was about whether an omitted argument should be special-cased

[09:13:21.0000] <Domenic_>
s/omitted argument/omitted or undefined argument/

[09:13:23.0000] <matjas>
alright

[09:13:26.0000] <marcosc_>
jgraham: see https://github.com/mozilla/servo/pull/1015#issuecomment-26127647

[09:13:30.0000] <matjas>
thanks for clarifying

[09:13:31.0000] <marcosc_>
that's what I get

[09:13:47.0000] <marcosc_>
jgraham: all the files look like they've changed

[09:14:09.0000] <marcosc_>
jgraham: even though I didn't change them :(

[09:14:10.0000] <jgraham>
marcosc_: That is messy, but I don't know why it's a problem

[09:14:19.0000] <jgraham>
Does it stop you building?

[09:14:26.0000] <annevk>
jgraham: I think throwing for undefined but not e.g. [] is rather weird fwiw

[09:14:28.0000] <marcosc_>
jgraham: no, builds fine

[09:14:29.0000] <Domenic_>
annevk: jason's tweet is interesting, it's fun to think of es6 as built from lots of cc0 specs.

[09:14:39.0000] <jgraham>
You can just not commit the things that you don't want to

[09:14:56.0000] <annevk>
Domenic_: yeah, he should totally license it like that, although once integrated it might get lost

[09:15:13.0000] <annevk>
until we get Ecma to fix things

[09:15:33.0000] <marcosc_>
jgraham: true, but it makes management very annoying ... as I need to distinguish between stuff I changed and stuff that Git changed

[09:15:37.0000] <jgraham>
But did you try git config --global core.autocrlf=false

[09:15:51.0000] <marcosc_>
jgraham: will try that

[09:16:19.0000] <jgraham>
That's the "old" mechanism aiui, but if it's set to true then it could cause problems

[09:16:33.0000] <marcosc_>
jgraham: it's currently set to nothing

[09:16:41.0000] <marcosc_>
when I try to set it, I get "error: invalid key: core.autocrlf=false"

[09:17:03.0000] <jgraham>
s/=/ /

[09:17:38.0000] <marcosc_>
ah

[09:18:11.0000] <marcosc_>
might have done the trick

[09:18:37.0000] <marcosc_>
jgraham: at least it's not complaining anymore

[09:18:48.0000] <jgraham>
Sounds like an improvement

[09:18:54.0000] <marcosc_>
jgraham: argh..

[09:19:57.0000] <marcosc_>
jgraham: now I get - "fatal: bad config value for 'core.autocrlf' in /Users/marcosc/.gitconfig"

[09:19:59.0000] <marcosc_>
heh

[09:20:10.0000] <jgraham>
Huh?

[09:20:35.0000] <jgraham>
Which version of git is this? And what's in that file?

[09:20:50.0000] <Ms2ger>
The next best solution is throwing your computer out of the window, I think

[09:20:58.0000] <marcosc_>
heh

[09:21:09.0000] <marcosc_>
ok, fixed

[09:22:10.0000] <marcosc_>
fatal: bad object HEAD

[09:22:15.0000] <marcosc_>
fatal: 'git status --porcelain' failed in submodule src/support/skia/skia

[09:22:25.0000] <marcosc_>
yay:)

[09:22:33.0000] <marcosc_>
Ms2ger is probably right

[09:22:44.0000] <marcosc_>
will try a hard reset ... cause that's how we fix things

[09:24:31.0000] <marcosc_>
trashing and cloning again...

[09:24:55.0000] <marcosc_>
/me still blames the Windows users 

[09:27:29.0000] <marcosc>
wait... I should be blaming Ms2ger

[09:28:06.0000] <Ms2ger>
Blame git

[09:34:09.0000] <marcosc>
Ms2ger, shut up Mr Mercurial :)

[09:34:35.0000] <Ms2ger>
marcosc, it never messes with your line endings...

[09:34:42.0000] <marcosc>
jgraham: I think what you suggested may have worked... don't seem to be having the problems anymore

[09:35:38.0000] <jgraham>
marcosc: Good, good

[09:35:47.0000] <jgraham>
Ms2ger: It can, but doesn't by default

[09:36:09.0000] <jgraham>
I tend to think the git default behaviour is broken here, but then I'm not a windows user

[09:38:48.0000] <marcosc>
jgraham: still borked :( "fatal: Not a git repository: src/support/skia/skia/../../../../.git/modules/src/support/skia/skia"

[09:39:19.0000] <jgraham>
That sounds like a different problem

[09:39:23.0000] <marcosc>
yeah

[09:39:30.0000] <Ms2ger>
Reclone

[09:39:36.0000] <Ms2ger>
That's what I always do

[09:39:43.0000] <marcosc>
Ms2ger: I literally just recloned it

[09:39:52.0000] <Ms2ger>
Heh

[09:39:54.0000] <Ms2ger>
Build?

[09:40:02.0000] <jgraham>
marcosc: Did you try to submodule update?

[09:40:14.0000] <marcosc>
jgraham: no, will try that

[09:40:17.0000] <jgraham>
I have never done that with servo, only used the build script

[09:40:31.0000] <jgraham>
Oh, well I was going to say it might not be a good idea)

[09:42:56.0000] <marcosc>
jgraham: yeah, that might cause more stuff to fall out of sync

[09:43:16.0000] <marcosc>
going to try to re-fork

[09:43:20.0000] <annevk>
Domenic_: hah, in https://www.youtube.com/watch?v=hneN6aW-d9w it's still "WHAT-WUG"

[09:43:36.0000] <marcosc>
yeah... been meaning to talk to Domenic_ about that

[09:43:37.0000] <marcosc>
:)

[09:43:57.0000] <annevk>
WHAT-WII-GEE

[09:44:28.0000] <Domenic_>
Hey I'm just glad I managed to say "opera" instead of "oprah" like I do inside my head all the time... baby steps.

[09:44:35.0000] <annevk>
hahaha

[09:46:02.0000] <jgraham>
But ironically when Swedes (and therefore quite possibly also Norwegians) say it, it sounds more like Oprah.

[09:46:18.0000] <annevk>
Domenic_: it's very good though; nice summary of all the lessons learned along the way

[09:47:16.0000] <Domenic_>
jgraham: vindicated at last!! kind of.

[09:47:18.0000] <Domenic_>
annevk: thanks! :D

[09:47:55.0000] <jgraham>
odinho: (is that actually true?)

[10:02:06.0000] <TabAtkins>
Domenic_: Oh man, the way you pronounced that grated on my ears so hard. ^_^

[10:20:10.0000] <MikeSmith>
TabAtkins: about srcN have you considered simply having a discrete number of attribute names? e.g., just src1-src9?

[10:20:33.0000] <TabAtkins>
MikeSmith: Other than making validators slightly easier to write, I don't see what benefit that has.

[10:21:35.0000] <MikeSmith>
the benefit of optimizing for the sane case instead of the pathological ones

[10:22:29.0000] <MikeSmith>
in practice how many image alternatives do people actually normally want to use these kinds of mechanisms to specify?

[10:22:33.0000] <MikeSmith>
5? 6?

[10:22:57.0000] <TabAtkins>
I don't see how this particularly optimizes for a sane case.  The difference between 9 and N attributes is pretty irrelevant implementation-wise.

[10:23:10.0000] <MikeSmith>
it's not markup-wise

[10:23:14.0000] <MikeSmith>
or authoring-wise

[10:23:27.0000] <MikeSmith>
or documentation-wise

[10:24:01.0000] <jgraham>
To be fair documentation wise it's easier to have an unbouded set and a pattern

[10:24:44.0000] <TabAtkins>
Yes it is, for all of those.

[10:25:19.0000] <TabAtkins>
I don't see how saying "src10 is illegal" makes anything easier markup-wise or authoring-wise.

[10:26:14.0000] <annevk>
srcN, so ugly :/

[10:26:24.0000] <annevk>
I was kinda hoping <h1-6> was the last of that

[10:26:37.0000] <TabAtkins>
annevk: Come up with something better. :/

[10:27:09.0000] <TabAtkins>
It's identical to having multiple elements for sources, but with better implementation shape apparently.

[10:27:50.0000] <aho>
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element states: "The src attribute must be present [...]". however, the steps below are written in a way which implies that src is optional. also, if width and height are set, browsers will happily render the element.

[10:28:16.0000] <Hixie_>
aho: the steps are written in a way that acknowledges that pages might be invalid.

[10:28:29.0000] <annevk>
TabAtkins: I think my current stance on this while thing is that we should try to figure out how to outsource this whole problem to custom elements

[10:28:36.0000] <annevk>
whole thing*

[10:28:38.0000] <aho>
ah, right

[10:28:42.0000] <Hixie_>
aho: see http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-to-read-this-specification

[10:28:52.0000] <TabAtkins>
annevk: I see no way in which that is remotely possible.

[10:28:55.0000] <Hixie_>
second paragraph in particular

[10:29:03.0000] <TabAtkins>
Like, it's not a path toward a solution in any way.

[10:29:30.0000] <TabAtkins>
annevk: Because interaction with the preload scanner is a base requirement.

[10:29:45.0000] <TabAtkins>
And virtually by definition, that means it has to be a native language feature.

[10:29:51.0000] <annevk>
TabAtkins: the preload scanner will need to be standardized and exposed, of course

[10:30:06.0000] <aho>
i currently use "data:," as no-op image src for generated documentation, but that looks and feels kinda awkward

[10:30:08.0000] <TabAtkins>
Ugh, that doesn't sound fun.

[10:30:14.0000] <annevk>
TabAtkins: it will have to interact with service workers' fetch feature too

[10:30:47.0000] <annevk>
TabAtkins: (architecture) standards are no fun

[10:30:59.0000] <annevk>
(unless you're into that kind of thing)

[10:31:18.0000] <Hixie_>
aho: it's what i do :-)

[10:31:23.0000] <Hixie_>
aho: that, or not have the image at all...

[10:31:27.0000] <jgraham>
architecture standards can quickly turn into architecture astronautics

[10:31:38.0000] <annevk>
jgraham: example?

[10:32:25.0000] <aho>
Hixie_, it's documentation for CSS "bricks" which sometimes do include an image (like, say, a thumbnail for some product)

[10:32:36.0000] <jgraham>
Well you seem to be proposing a feature with stated no use case just because that's what the architecture you envision requires

[10:32:44.0000] <aho>
so, i kinda need some no-op image there

[10:32:48.0000] <jgraham>
*no stated

[10:33:00.0000] <annevk>
jgraham: you lost me

[10:33:35.0000] <jgraham>
You are proposing spending engineering effort exposing the preload scanner, but it isn't at all clear if that has a real use case

[10:34:16.0000] <jgraham>
Other than "maybe implement responsive images on top of other primitives that don't exist yet"

[10:34:45.0000] <jgraham>
Which might all turn out to be fine and sensible and a good idea

[10:34:48.0000] <annevk>
jgraham: oh the preload scanner needs to be exposed for offline

[10:35:15.0000] <annevk>
jgraham: that's part of exposing most of network so apps can decide whether to do network rather than the browser

[10:35:24.0000] <jgraham>
But right now it feels like the atmosphere's getting thin

[10:35:35.0000] <jgraham>
Why does that require the preload scanner?

[10:35:48.0000] <annevk>
jgraham: well the preload scanner will have to be exposed

[10:36:03.0000] <annevk>
jgraham: because network roundtrips through JavaScript

[10:36:44.0000] <TabAtkins>
Yeah, that part's true - if you're trying to intercept network loads with a service worker, and the preload scanner fires off network loads, then obviously there's an observable interaction there.

[10:37:25.0000] <jgraham>
Sure. But that doesn't mean that you can customise the behaviour

[10:38:23.0000] <TabAtkins>
Yeah it does - at minimum, it means you can block a preload.

[10:38:51.0000] <TabAtkins>
But given that you can actually intercept every other network request and provide custom data, it would be very weird if you couldn't do that for preload requests.

[10:39:14.0000] <jgraham>
Well in particular it doesn't mean that you can make the scanner scan for different elements

[10:39:25.0000] <jgraham>
Or attributes

[10:39:44.0000] <jgraham>
So you can change the effects of the scanner

[10:39:51.0000] <jgraham>
But not the scanner itself

[10:45:56.0000] <annevk>
jgraham: that's a good point

[10:46:44.0000] <annevk>
jgraham: I guess if we want custom elements to be successful we might need that at some point, although there's some pretty daunting dependency problems there :/

[10:48:51.0000] <TabAtkins>
Ah, yeah, indeed.

[10:49:04.0000] <TabAtkins>
(That was to jgraham.)

[10:50:03.0000] <TabAtkins>
annevk: Yeah, dealing with the dependency problems is almost impossible, without something like a declarative DSL that specifies which element/attrs are looked at and provides a grammar for extracting the urls.

[10:50:12.0000] <TabAtkins>
Which sounds terrible.

[10:51:29.0000] <annevk>
Well, you also need to have the semantics of the custom element known at runtime. That's the harder part...

[10:51:43.0000] <annevk>
Well, the encompassing part I suppose.

[10:52:14.0000] <annevk>
There's a lot of ways in which custom elements will still be second-class citizens.

[10:52:19.0000] <annevk>
Which is rather sad...

[11:00:42.0000] <Ms2ger>
Hrm

[11:00:53.0000] <Ms2ger>
Didn't I see a change to fix http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/formdata.htm?

[11:07:49.0000] <annevk>
smaug____: you around? The way timeout is defined now means that you might be able to access responseText for a bit and then once the timeout happens responseText is cleared because the error flag is set.

[11:08:05.0000] <annevk>
smaug____: which is similar to what we do for end-user abort

[11:08:18.0000] <annevk>
smaug____: and abort(), so maybe that's all fine

[11:09:02.0000] <annevk>
smaug____: I'm trying to figure out what the async interface is that Fetch should expose

[11:09:13.0000] <smaug____>
hmm

[11:10:08.0000] <annevk>
In the simple case you either have a network error, or a response which is subdivided into getting the headers, getting data, getting data EOF

[11:10:41.0000] <annevk>
In this more complicated case where we also have end-user abort and timeout the response you're already receiving is replaced somehow...

[11:11:33.0000] <annevk>
Maybe as far as Fetch is concerned is that you simply killed the network and you get an erroneous "getting data EOF". And then at the API level it does the thing where it doesn't care about the response and such anymore.

[11:11:54.0000] <smaug____>
well, timeout and abort are kind of error cases, so clearing responseText sounds reasonable

[11:12:33.0000] <annevk>
Sure, for XMLHttpRequest, but is it sensible for <img>?

[11:13:13.0000] <annevk>
Or should <img> keep showing the part of the image it was already displaying? I'm thinking the latter is what I typically see happen (and what I'd like as a user if my connection suddenly dropped)

[11:13:25.0000] <smaug____>
right

[11:13:39.0000] <annevk>
Oh sorry, connection dropping is different. Aah. What I see happen if I hit the cancel button.

[11:14:41.0000] <Hixie_>
Domenic_: that's a great talk. (just watched it)

[11:16:44.0000] <smaug____>
annevk: well, that is about the consumer of the data read from the request, isn't it. in case of XHR one could have copied the data to elsewhere and use it even after timeout or abort

[11:16:48.0000] <smaug____>
isn't img similar

[11:17:05.0000] <smaug____>
the data is copied to some img library

[11:18:02.0000] <annevk>
smaug____: I think the one thing we don't detect however is the connection dropping halfway through

[11:18:30.0000] <annevk>
smaug____: "network error" can only happen before you receive a byte of the entity body

[11:19:29.0000] <annevk>
smaug____: so "network error" and "response" are orthogonal, but I suppose "response" could have an additional "error" hook for end-user abort and timeout and such which would be up to the consumer to do something useful with

[11:20:01.0000] <dglazkov>
good morning, Whatwg!

[11:22:06.0000] <annevk>
That's still wrong. Hah. If you haven't gotten a response yet and you do have an end-user abort. It's not an upgrade of a response in that case.

[11:27:55.0000] <annevk>
smaug____: wrote down description in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22387#c3

[11:31:56.0000] <annevk>
Also filed https://github.com/slightlyoff/ServiceWorker/issues/101 to ensure models stay in sync.

[11:34:55.0000] <madcorp>
hello

[11:36:44.0000] <madcorp>
I've a question about one meta extension. :)

[11:36:52.0000] <madcorp>
Who can help me?

[11:52:51.0000] <TabAtkins>
Don't ask if you can ask, just ask.

[11:56:14.0000] <ronaldmansveld>
TabAtkins: is the current status of color-correction indeed ED? Cause that´s all I can find. It´s mentioned in both the css-color-correction module and the css-color module level 4.

[11:56:30.0000] <ronaldmansveld>
(Just so we can assign it the correct priority for documenting it on webplatform)

[11:56:37.0000] <TabAtkins>
Yes.

[11:56:51.0000] <ronaldmansveld>
OK, thanks!

[11:58:43.0000] <Domenic_>
Hixie_: thank you, that means a lot!

[12:14:53.0000] <zcorpan>
TabAtkins: does it correctly mark up partial interfaces?

[12:15:08.0000] <TabAtkins>
Maybe!  I dunno.

[12:15:46.0000] <TabAtkins>
By that I mean: it probably just does the simple thing that I just described, which'll link to the primary definition if it exists in Shepherd's db, and otherwise <dfn> it.

[12:31:36.0000] <odinho>
< jgraham> But ironically when Swedes (and therefore quite possibly also Norwegians) say it, it sounds more like Oprah.

[12:33:37.0000] <odinho>
Yeah. We normally drop the extra "e". But if you're very correct you say opEra. But most often it's jjust "opra".

[12:34:48.0000] <odinho>
And our "o" is very different.

[14:17:18.0000] <zcorpan>
was there a conclusion about CSS.supports(undefined) ?

[14:26:23.0000] <TabAtkins>
Don't think so, no.

[14:33:32.0000] <zcorpan>
i have a feeling this has been discussed before and resulted in webidl defaulting to throwing...

[14:36:44.0000] <Domenic_>
I think the semi-conclusion was that it should either be "undefined" or "", depending on whether you give it a default value of "" or not.

[15:02:32.0000] <zcorpan>
i don't see rebuttals of pro-throwing: consistency with other DOM functions and ease of debugging

[15:04:26.0000] <zcorpan>
note that empty string can result in an exception anyway if you do document.querySelector('#' + CSS.escape())

[15:04:49.0000] <zcorpan>
since '#' isn't a valid selector, you get a TypeError

[15:05:09.0000] <zcorpan>
so if you don't like exceptions, empty string is out...

[15:09:33.0000] <zcorpan>
JS escape() and encodeURIComponent() result in "undefined", maybe it's reasonable for CSS.escape() to be consistent with those

[15:48:44.0000] <zewt>
in case zcorpan reads logs, I'd much rather have an exception above than have it search for the id (or class, or who knows what) "undefined"

[16:11:33.0000] <SimonSapin>
+1 zewt

[16:47:05.0000] <slightlyoff>
annevk-cloud: good call about staying in sync. I'm mostly trying to avoid extra events beyond completion/failure at the moment. We can plumb them into the response object later. The overall operation's constituent parts can be dealt with independently of the promise that describes the overall completion

[16:47:27.0000] <slightlyoff>
annevk-cloud: so I'm doing my bit by not defining any of that API ATM ;-)

[16:47:55.0000] <slightlyoff>
annevk-cloud: happy to work with you to flesh it out


2013-10-16
[00:49:33.0000] <zcorpan>
zewt: please give rationale

[00:51:30.0000] <Ms2ger>
marcosc, squash, not squish ;)

[00:51:54.0000] <marcosc>
Ms2ger: should be "squished"

[00:52:07.0000] <marcosc>
it's much cutter and sounds less mean

[01:05:28.0000] <SimonSapin>
zcorpan: Errors should not pass silently

[01:06:05.0000] <zcorpan>
SimonSapin: ...because?

[01:06:38.0000] <SimonSapin>
zcorpan: Code that "works" and eg. looks for id="undefined" will be harder to debug than one that just throws with an explicit error

[01:07:11.0000] <zcorpan>
ok, so what do you think should happen for CSS.escape(window) ?

[01:07:28.0000] <SimonSapin>
This brings the symptom of the error closer to the source

[01:07:41.0000] <SimonSapin>
does window have .toString?

[01:07:52.0000] <zcorpan>
yes

[01:08:02.0000] <zcorpan>
it usually stringifies to [object Window]

[01:09:16.0000] <SimonSapin>
I don’t know, this case is less clear-cut

[01:09:45.0000] <SimonSapin>
is the convention to strictly only accept strings, or anything that can be converted to a string?

[01:10:05.0000] <zcorpan>
the latter

[01:10:36.0000] <zcorpan>
except for undefined, which is different for different APIs

[01:11:04.0000] <SimonSapin>
In that case I suppose CSS.escape(window) would be "\\[object\\ Window\\]"

[01:11:05.0000] <annevk>
zcorpan: seems like it should be undefined

[01:11:12.0000] <annevk>
SimonSapin: and it is

[01:11:21.0000] <annevk>
SimonSapin: that's how ToString works

[01:11:49.0000] <annevk>
JavaScript doesn't do type checking, it just does type coercions all over

[01:11:54.0000] <zcorpan>
SimonSapin: so how is it different from undefined from the being-in-error and debug-ability point of view?

[01:12:05.0000] <SimonSapin>
but undefined may be a common enough source of errors that it’s worth a special case

[01:12:12.0000] <annevk>
o_O

[01:12:22.0000] <SimonSapin>
IMO

[01:12:54.0000] <SimonSapin>
you’re less likely to accidentally end up with window instead of a string than undefined

[01:14:49.0000] <zcorpan>
is it less likely to accidentally end up with anything other than a string and undefined compared to undefined?

[01:15:55.0000] <SimonSapin>
I think so, but I may be wrong

[01:15:59.0000] <SimonSapin>
I don’t write that much JS

[02:40:19.0000] <annevk>
bholley: we'd have to narrow the case where the adopt would throw as otherwise many operations that route through adopt would not work, which would suck

[02:40:51.0000] <bholley>
annevk: can you explain a bit more?

[02:41:05.0000] <annevk>
bholley: e.g. whenever you appendChild, adopt is used

[02:41:13.0000] <bholley>
annevk: yes, I'm aware - that's the whole issue, really

[02:41:22.0000] <bholley>
annevk: people rarely adopt just to adopt

[02:41:25.0000] <annevk>
bholley: if the glabal object is the same, there doesn't seem to be an issue

[02:41:36.0000] <bholley>
annevk: oh, adopt happens even for same-global?

[02:41:40.0000] <annevk>
bholley: so we should limit throwing for custom elements only if the global object changes

[02:41:44.0000] <bholley>
annevk: right

[02:41:51.0000] <bholley>
annevk: that was my intention, sorry

[02:42:01.0000] <bholley>
annevk: I thought that the adopt was only triggered in the cross-global case

[02:42:08.0000] <bholley>
annevk: well, technically cross-document

[02:42:17.0000] <bholley>
annevk: are there significant ways in which those cases differ?

[02:42:19.0000] <annevk>
bholley: no, adopt does things like changing the document and removing from parent

[02:42:28.0000] <bholley>
annevk: ie document fragment?

[02:42:30.0000] <annevk>
bholley: yeah, createDocument

[02:42:37.0000] <annevk>
bholley: and HTML imports

[02:42:53.0000] <annevk>
bholley: and new Document() once we have that

[02:43:06.0000] <bholley>
annevk: ok, sure

[02:43:10.0000] <bholley>
annevk: that's fine with me

[02:43:18.0000] <bholley>
annevk: assuming we do that, do you think throwing would be ok?

[02:44:53.0000] <annevk>
have to think about that some more

[02:45:03.0000] <annevk>
kinda depends on where we want to steer the whole thing I think

[02:45:21.0000] <annevk>
treat sync access between multiple globals as a bug, or embrace it and make it work

[02:45:52.0000] <annevk>
should prolly be discussed on es-discuss

[02:46:00.0000] <annevk>
or public-script-coord

[02:46:17.0000] <bholley>
annevk: ugh, I feel like that's not going to really go anywhere

[02:46:37.0000] <bholley>
annevk: because if we abstract this into a more vague discussion of values, it will devolve again into the specific considerations

[02:46:42.0000] <bholley>
annevk: and then we're back at this bug

[02:47:23.0000] <bholley>
annevk: moreover, we can always spec that something throws and then change it later

[02:47:33.0000] <bholley>
annevk: whereas we can't unsupport something we decide to support

[02:48:41.0000] <annevk>
bholley: sure, throwing seems safe for now, but I also think we should have the larger discussion

[02:49:05.0000] <annevk>
bholley: as it'll impact other APIs to come

[02:49:57.0000] <bholley>
annevk: I'm also not totally clear which high-level outcome results in which course of action here - can you elaborate on your thinking?

[02:53:59.0000] <annevk>
bholley: the main goal of involving more people would be to create better shared understanding and push towards a common goal; be that reducing memory leaks at all costs or making multiple globals work in the best way possible somehow

[02:54:44.0000] <annevk>
bholley: I'm pretty sure we'll keep revisiting this if we don't reach out to the wider community around JavaScript

[02:55:12.0000] <bholley>
annevk: FWIW, I kind of feel that fixing up the prototypes _is_ "making multiple globals work in the best way possible somehow"

[02:55:28.0000] <bholley>
annevk: it's not just about memory leaks

[02:55:34.0000] <bholley>
annevk: though that's my primary concern

[02:55:34.0000] <jgraham>
To the extent that they differ, it's not clear that either of those is the correct goal

[02:55:47.0000] <bholley>
annevk: it's also about the API making sense

[02:55:55.0000] <annevk>
I think it makes a lot of sense for trees, though Brendan didn't like that bug much, though he may not have studied the details

[02:56:09.0000] <bholley>
annevk: trees?

[02:56:10.0000] <jgraham>
I mean, if there is an option that makes it reasonably easy to avoid memory leaks but also provides the features that people want that's better than either

[02:56:39.0000] <annevk>
bholley: that nodes share the same global

[02:57:32.0000] <bholley>
annevk: I still don't follow

[02:58:06.0000] <bholley>
annevk, jgraham: in my mind, the fundamental issues is that bindings are per-document. It's kind of non-sensical to pull a binding out of a document in that context

[02:58:19.0000] <bholley>
the only options are to (a) strip the binding, or (b) not allow them to leave the document

[02:58:19.0000] <annevk>
bholley: I think it makes sense to prototypes. People in TC39 seemed to have reservations about that bug which is why I'd like to discuss it with them

[02:58:35.0000] <annevk>
to change prototypes*

[02:58:39.0000] <bholley>
annevk: ok

[02:58:50.0000] <bholley>
(a) is apparently tricky due to the reasons that Dominic described

[02:59:16.0000] <annevk>
I think it's important to have TC39 on board, as they'll be diving into the multiple global territory and we don't want to revisit this each year.

[03:00:12.0000] <annevk>
Anyway, back in a bit, need to get some yoghurt from the office...

[03:00:19.0000] <bholley>
annevk: but

[03:00:26.0000] <bholley>
annevk: will JS ever have a concept of adopt?

[03:00:35.0000] <bholley>
annevk: if it doesn't, then the issue is moot

[03:03:20.0000] <annevk>
I don't know, anyway, biab

[03:04:14.0000] <jgraham>
zcorpan: Since someobject.propertyThatDoesntExist is undefined in js foo(undefined) is a way easier bug to have than foo(window)

[03:04:49.0000] <jgraham>
And throwing tells you what the error is right away rather than getting a nonsense result much later in the code

[03:05:17.0000] <bholley>
annevk-cloud: ok

[03:06:52.0000] <zcorpan>
jgraham: yeah, it seems plausible that undefined is a more common error

[03:08:02.0000] <zcorpan>
jgraham: still, encodeURIComponent(undefined) doesn't throw and seems to be in the same position as CSS.escape(undefined)

[03:13:10.0000] <jgraham>
zcorpan: It depends how important you think it is to be consistent with poor design decisions in the stdlib vs how important you think it is to be consistent with the DOM and provide a useful API

[03:19:09.0000] <annevk>
Treating undefined as "undefined" is what we do everywhere for DOMString.

[03:19:27.0000] <annevk>
The only case you could make is making the argument optional, but there doesn't seem to be much of a reason for that.

[03:20:02.0000] <Ms2ger>
And when you make it optional, then you have the question of the default

[03:20:24.0000] <annevk>
Simple test: .<script>document.body.innerHTML = undefined</script>

[03:22:08.0000] <zcorpan>
annevk: innerHTML isn't a method, and CSS.escape() doesn't have its argument optional (currently)

[03:22:09.0000] <jgraham>
Well if it's consistent with everything on the platform I guess we have to do that. But oh boy is that a sucky design

[03:22:39.0000] <annevk>
zcorpan: innerHTML is a getter and setter, same thing

[03:22:50.0000] <annevk>
zcorpan: but find a method that takes a DOMString and you'll find out how IDL works

[03:23:19.0000] <zcorpan>
it's not consistent with everything else. document.getElementById(undefined) throws (per spec, at least)

[03:23:48.0000] <Ms2ger>
Eh?

[03:24:00.0000] <Ms2ger>
Doesn't seem to

[03:24:37.0000] <jgraham>
I think the IDL spec changed at some point

[03:24:49.0000] <Ms2ger>
Only for optional arguments

[03:25:41.0000] <zcorpan>
ah, i thought it made undefined mean omitted even for non-optional argument

[03:26:01.0000] <Ms2ger>
I'm pretty sure it didn't

[03:27:23.0000] <zcorpan>
ok so CSS.escape() throws TypeError but CSS.escape(undefined) gives "undefined" (per current spec)

[03:27:35.0000] <Ms2ger>
sgtm

[03:31:03.0000] <jgraham>
For those following at home, that is *also* inconsistent with escape() and encodeURIComponent()

[03:32:22.0000] <zcorpan>
yep

[05:50:12.0000] <Domenic_>
CSS.escape(undefined) MUST be the same as CSS.escape()

[05:50:37.0000] <Ms2ger>
Nah

[05:51:32.0000] <Ms2ger>
WebKit used to do that, it's stupid

[05:51:39.0000] <Domenic_>
O_o

[05:51:48.0000] <Domenic_>
That is just ... how JS works... when you don't pass an argument, it's undefined ...

[05:51:57.0000] <Domenic_>
Anything else is MEGA surprising.

[05:59:45.0000] <jgraham>
Domenic_: Is this something that causes you lots of problems with every other DOM function?

[06:00:51.0000] <Domenic_>
jgraham: yes!!

[06:01:00.0000] <Domenic_>
it breaks transparent composability

[06:01:26.0000] <Domenic_>
you need to do function (x, y) { if (y === undefined) { domFunc(x); } else { domFunc(x, y); } }

[06:02:31.0000] <jgraham>
I am failing to understand the problem

[06:02:49.0000] <Domenic_>
it creates a combinatorial explosion every time you want to forward arguments to a DOM function

[06:02:57.0000] <jgraham>
You can't use undefined like a None type here anyway

[06:03:05.0000] <jgraham>
Since it is stringified

[06:03:45.0000] <Domenic_>
We're talking about the general case right now

[06:03:49.0000] <jgraham>
Sure

[06:04:02.0000] <Domenic_>
Forwarding arguments should be as simple as function (x, y, z, w) { domFunc(x, y, z, w); }

[06:04:06.0000] <jgraham>
But in general you can't use undefined like a None type

[06:04:15.0000] <Domenic_>
Sure you can, with normal JS functions

[06:04:25.0000] <jgraham>
How?

[06:04:25.0000] <Domenic_>
With the rules that make undefined and omitted different, you need ifs

[06:04:30.0000] <Ms2ger>
Nah, it should be function(...arguments) { domFunc(...arguments) }

[06:04:44.0000] <jgraham>
If there is magic type conversion

[06:04:53.0000] <Domenic_>
Ms2ger: OK, please extend my example to be slightly more complicated, e.g. transforming y to y + 1

[06:05:07.0000] <Domenic_>
jgraham: there's nothing magic about it. If undefined goes into my function, it should go into the DOM function

[06:05:50.0000] <Domenic_>
gtg commute to work... be back later

[06:06:04.0000] <jgraham>
If undefined goes into your function and it is going to call the DOM function with the wrong number of arguments, there is a bug in your code

[06:06:12.0000] <Domenic_>
this combinatorial explosion avoidance is the main reason default parameters in ES use undefined as the default value trigger, BTW.

[06:06:23.0000] <jgraham>
I don't understand why you want to make that hard to notice

[06:06:23.0000] <Domenic_>
there is no such thing as "wrong number of arguments"

[06:06:30.0000] <Domenic_>
the number of arguments is not actually something functions care about

[06:06:35.0000] <zcorpan>
Domenic_: your example doesn't invoke domFunc without arguments, so i don't see the problem

[06:06:41.0000] <Domenic_>
there are some arguments that have values, and the rest of them have undefined, out to infinity

[06:06:49.0000] <Domenic_>
aggh really got to go ttyl

[06:07:07.0000] <jgraham>
That's an ironic point of view given Function.length

[06:07:41.0000] <annevk>
I think Domenic_'s point is better discussed at the IDL-level and not for this individual method

[06:07:56.0000] <annevk>
And therefore public-script-coord⊙wo is prolly a better fora than here

[06:08:09.0000] <gsnedders>
annevk: public-script-coord is a single forum.

[06:08:16.0000] <jgraham>
annevk: The discussion is already happening on public-script-coord

[06:08:26.0000] <jgraham>
But I don't see why you are trying to shut down discussion here

[06:08:55.0000] <annevk>
Shut down? Relax man, I just said prolly ;-)

[06:09:53.0000] <gsnedders>
Is the problem not deeper than this? Is this not caused by the fact that WebIDL (and the DOM generally) relies on overloads, and hence different numbers of arguments must have different meanings, and somehow the callee must recognize the number of arguments given?

[06:10:21.0000] <gsnedders>
/me doesn't know if he's even subscribed to public-script-coord now

[06:10:22.0000] <jgraham>
gsnedders: Script libraries do that too of course

[06:10:47.0000] <jgraham>
There's nothing to stop a js library from throwing with no argument but not throwing with undefined

[06:11:22.0000] <jgraham>
Or doing something totally different for the two cases

[06:12:37.0000] <zcorpan>
i guess webidl does what Domenic_ wants when there are optional arguments.

[06:13:01.0000] <annevk>
Treating () and (undefined) the same seems feasible given that WebKit has done it for a long time. Just need more eyeballs to measure to impact.

[06:14:41.0000] <zcorpan>
feasible, sure. desired? not so clear. this has been discussed and resolved to what webidl has now, some time ago (although i can't find the relevant thread now)

[06:17:20.0000] <annevk>
Well yeah, "some time ago" we also decided undefined and omitted arguments would be different. I think it's pretty clear what the answer would be now.

[06:18:36.0000] <zcorpan>
annevk: you mean for optional arguments?

[06:19:42.0000] <annevk>
Right, we already fixed optional arguments.

[07:04:36.0000] <zewt>
<Domenic_> That is just ... how JS works... when you don't pass an argument, it's undefined ... <- that's irrelevant; the function *itself* can do whatever it wants with the argument (such as throwing a TypeError if an argument that's supposed to be one thing isn't)

[07:05:13.0000] <zewt>
for example, new Event() throws, it doesn't create an event with a name of "undefined", which would be useless and make what is definitely a programming error harder to notice

[07:06:41.0000] <annevk>
though new Event(undefined) doesn't throw and also makes what's likely an error hard to notice

[07:06:48.0000] <annevk>
dunno if that carries much weight

[07:07:35.0000] <annevk>
Having types in general would make debugging much better, but it seems unlikely JS will get them.

[07:07:56.0000] <annevk>
Having required arguments be part of the language might be feasible however.

[07:08:06.0000] <Domenic_>
if the argument is required, both undefined and missing should give a TypeError

[07:08:14.0000] <Domenic_>
if it is optional, both undefined and missing should trigger the default

[07:08:46.0000] <annevk>
That seems reasonable

[07:09:14.0000] <zewt>
no objections there

[07:09:17.0000] <jgraham>
I would totally support that

[07:09:18.0000] <Domenic_>
I would rather more arguments be optional than are currently, but am willing to delay that battle indefinitely in favor of fixing the mega-WTF of separate undefined/missing behavior.

[07:09:25.0000] <Domenic_>
OK cool, sudden agreement :D

[07:09:42.0000] <annevk>
Nah, you made a better proposal :-)

[07:09:45.0000] <jgraham>
Well not really, because WebIDL says that explicit undefined is coerced

[07:10:05.0000] <Domenic_>
jgraham: so, agreement between everyone excepting WebIDL? :P

[07:10:14.0000] <jgraham>
Something like that :)

[07:10:46.0000] <annevk>
Shall I file a bug?

[07:11:13.0000] <annevk>
/me files a bug

[07:11:18.0000] <zewt>
xhr open() seems to be another one

[07:11:48.0000] <zewt>
(throws TypeError if there's no argument)

[07:11:56.0000] <zewt>
afk, work

[07:13:00.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23532

[08:00:05.0000] <zewt>
hmm, webidl does seem to throw TypeError for missing (not undefined) arguments (4.5.1.1), but that doesn't seem like what most APIs do (unless I'm missing something in WebIDL, which is likely)

[08:01:03.0000] <jgraham>
I don't know about "most", but at the least "many" do

[08:01:28.0000] <zewt>
yeah it seems to vary

[08:01:28.0000] <jgraham>
At least in Gecko. And in presto (although it was some weird custom error)

[08:01:30.0000] <zewt>
webgl does

[08:01:51.0000] <zewt>
or maybe I'm just confused by the earlier conversation

[08:02:01.0000] <jgraham>
getElement[s]By*() do

[08:02:21.0000] <zewt>
(which was "what? you can't make CSS.escape() throw instead of returning "undefined", that's crazy!")

[08:05:09.0000] <jgraham>
So I think the tension arises from the fact that the javascript stdlib doesn't throw for missing arguments

[08:06:40.0000] <jgraham>
(or, depending on your point of view, that javascript doesn't have a concept of missing arguments, even though it clearly exposes information about which arguments were passed and which weren't)

[08:12:24.0000] <Domenic_>
it only does that through the arguments object, which is being slowly killed

[08:12:45.0000] <Domenic_>
e.g. if you use any ES6 features in your function parameters, like defaults or spread or destructuring, you get no arguments object.

[08:16:50.0000] <annevk>
Domenic_: do those also nullify arguments.length?

[08:17:02.0000] <annevk>
Domenic_: sorry, Function.length

[08:17:36.0000] <annevk>
Domenic_: see e.g. http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0724.html

[08:17:38.0000] <Domenic_>
no, function.length is still defined, and still as useless as ever.

[08:18:11.0000] <Domenic_>
but there's no way inside a function that uses ES6 features to determine whether undefined was passed or that argument was omitted

[08:21:26.0000] <TabAtkins>
Yeah, Function.length is static for the function - it doesn't depend on the number of arguments passed.

[08:21:46.0000] <Domenic_>
(why do people keep capitalizing Function.length, it's not a property of the Function constructor...)

[08:21:54.0000] <TabAtkins>
Function#length

[08:22:04.0000] <TabAtkins>
Because typing out Function.prototype.length is annoying. ^_^

[08:22:13.0000] <Domenic_>
Well it's not on the prototype either

[08:22:24.0000] <TabAtkins>
Close enough.

[08:22:44.0000] <annevk>
What's the way to refer to instances?

[08:22:47.0000] <TabAtkins>
Point being, "Foo" is sometimes used informally as a stand-in for "an arbitrary instance of Foo".

[08:22:52.0000] <Domenic_>
function.length or functionInstance.length

[08:23:07.0000] <Domenic_>
myFunction.length

[08:23:09.0000] <annevk>
that's kinda sad notation-wise but okay

[08:23:41.0000] <Domenic_>
I mean you wouldn't say Document.createElement

[08:23:43.0000] <annevk>
yeah, what TabAtkins says, though I'm not very consistent about it

[08:24:07.0000] <annevk>
Domenic_: I guess I try to go with Document.prototype.createElement these days

[08:24:09.0000] <jgraham>
document is a singleton (ish), so that's easier

[08:24:32.0000] <Domenic_>
true

[08:24:53.0000] <Domenic_>
anyway this is silly, didn't mean to spawn extended discussion on capitalization of a single character :P

[08:25:57.0000] <TabAtkins>
Domenic_: To be fair, it might be two or three characters, if the class name is multi-word.

[08:26:13.0000] <Domenic_>
hahaha

[08:30:49.0000] <bholley>
annevk: ping

[08:30:54.0000] <annevk>
bholley: hey

[08:31:13.0000] <bholley>
annevk: as noted in the thread, I believe that we should disallow freezing dom objects

[08:31:20.0000] <annevk>
bholley: I think that's already the case per IDL

[08:31:27.0000] <bholley>
annevk: ok, great

[08:31:36.0000] <bholley>
annevk: WebIDL specs this?

[08:32:05.0000] <annevk>
bholley: "Platform array objects cannot be fixed; if Object.freeze, Object.seal or Object.preventExtensions is called on one, the function MUST throw a TypeError."

[08:32:13.0000] <bholley>
annevk: great!

[08:32:16.0000] <annevk>
oh wait, that's array

[08:32:35.0000] <annevk>
hmm

[08:32:53.0000] <annevk>
also goes for "Platform objects implementing an interface that supports indexed or named properties cannot be fixed"

[08:33:03.0000] <annevk>
doesn't say anything that would apply to Node

[08:33:16.0000] <annevk>
bholley: so no...

[08:33:50.0000] <bholley>
annevk: ok

[08:34:11.0000] <bholley>
annevk: I'll file a bug on WebIDL

[08:34:16.0000] <bholley>
annevk: which tracker is it? w3?

[08:34:26.0000] <annevk>
bholley: there's a link at the top of the spec

[08:34:34.0000] <bholley>
annevk: ok, cool

[08:34:35.0000] <annevk>
bholley: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG&component=WebIDL

[08:34:39.0000] <bholley>
annevk: do you agree, btw?

[08:34:55.0000] <annevk>
bholley: don't really care about those ES5 features

[08:35:22.0000] <bholley>
annevk: so you don't mind just rejecting them for the DOM to give us more flexibility?

[08:35:22.0000] <annevk>
bholley: they have strange names and don't really do what you expect them to be doing and half of TC39 seems to shrug at them

[08:35:45.0000] <annevk>
bholley: right, I don't mind

[08:35:51.0000] <bholley>
annevk: k

[08:42:14.0000] <Domenic_>
you can't stop Object.seal

[08:42:26.0000] <Domenic_>
You can stop preventExtensions

[08:42:35.0000] <Domenic_>
and thus stop that part of the freezing process

[08:42:55.0000] <Domenic_>
but you can always make a property non-configurable/non-writable, even proxies can't prevent that

[08:43:02.0000] <Domenic_>
annevk: ^

[08:43:42.0000] <annevk>
Domenic_: seems false in implementations

[08:43:59.0000] <Domenic_>
as in, DOM objects are not implementable with proxies?

[08:44:06.0000] <annevk>
In Gecko Object.seal(window) throws

[08:44:16.0000] <annevk>
Does not seem to throw in Chrome though

[08:47:33.0000] <Domenic_>
no i lied, you could make a proxy with a throwing defineOwnProperty trap

[08:47:48.0000] <Domenic_>
A bit unfortunate all platform objects would have to become proxies with overriden defineOwnProperty traps though

[08:48:19.0000] <annevk>
bholley: maybe you should request a hook for it, so we'd only use it on Node

[08:49:06.0000] <annevk>
well, and all the objects Node can hold, such as DOMTokenList

[08:49:37.0000] <annevk>
bholley: seems like this would be problematic once <input type=file>.files becomes an actual JS Array

[08:50:22.0000] <annevk>
/me shakes fist at multiple globals

[08:52:12.0000] <Domenic_>
from what i'm reading you just want Node to be a proxy with a throwing preventExtensions trap?

[08:52:19.0000] <Domenic_>
that would allow its proto to be changed later

[08:52:34.0000] <annevk>
Domenic_: not just Node, but everything attached to Node too

[08:52:41.0000] <Domenic_>
right :(

[08:52:44.0000] <annevk>
Domenic_: so there's no references to the other global

[08:56:16.0000] <annevk>
Yeah, browser engineering is pretty much sad times all the time. Fortunately the web is full of cats tripping themselves.

[08:57:51.0000] <zewt>
hard to take anyone seriously when they say "we talked about this before, read the notes from the f2f"

[09:00:48.0000] <annevk>
Well you can't really expect past stuff to be explained over and over again

[09:01:20.0000] <jgraham>
No, but saying "we discussed this in a meeting and you weren't invited" is pretty much like saying "fuck you"

[09:01:31.0000] <jgraham>
Even if there are notes

[09:01:42.0000] <Domenic_>
arv ^

[09:02:20.0000] <annevk>
jgraham: every JS decision I've seen is backed by plenty of mailing list debate which is open to all

[09:02:49.0000] <annevk>
jgraham: they should just move to async-decisions entirely, but the way the thing works it's pretty much async

[09:03:45.0000] <jgraham>
I agree that anyone can join in on the mailing list. But I stand by my point

[09:04:12.0000] <annevk>
jgraham: e.g. decision on promises was just reiterating what was already said async and then we moved on

[09:05:11.0000] <gsnedders>
annevk: Plenty of things around TC 39 are effectively finalized in F2F meetings, often with some arguments going totally unaddressed.

[09:05:50.0000] <zewt>
should I really be surprised that it's 2013 and browsers still apparently don't support resuming downloads?

[09:06:28.0000] <annevk>
gsnedders: if you notice that happening please raise it

[09:06:34.0000] <annevk>
gsnedders: that seems suboptimal

[09:06:49.0000] <gsnedders>
zewt: I thought they did? Just many servers don't support partial requests.

[09:06:52.0000] <jgraham>
"ReferenceError: undefined_variable is not defined"

[09:07:03.0000] <gsnedders>
annevk: I haven't read es-discuss in ages, and don't really care nowadays.

[09:07:03.0000] <zewt>
downloading from nginx, which definitely does

[09:07:34.0000] <annevk>
gsnedders: okay, so things might have changed for the better

[09:07:38.0000] <gsnedders>
zewt: Are you sure the browser can tell the resource is unchanged?

[09:08:30.0000] <gsnedders>
annevk: At least stuff like Object.prototype.__proto__ was effectively decided in F2F until more or less overnight all JS engines went against the decision.

[09:08:33.0000] <zewt>
not entirely, but it does have a correct Last-Modified

[09:08:39.0000] <zewt>
no ETag or cache headers though

[09:08:43.0000] <gsnedders>
annevk: And that was a year and a half ago or so?

[09:08:57.0000] <gsnedders>
zewt: Are resources cachable by default? I forget.

[09:09:05.0000] <annevk>
gsnedders: my experience is about five months :-)

[09:09:23.0000] <zewt>
i forget too, it's probably something akin to must-revalidate

[09:09:23.0000] <annevk>
(and I'm going to miss what would've been my third meeting)

[09:10:00.0000] <gsnedders>
annevk: es-discuss takes too much time having to consider PL theory, at least before. Maybe as we're close to final it's not so much now.

[09:10:14.0000] <gsnedders>
annevk: And I attended no meetings, not working for a member. :)

[09:12:05.0000] <bholley>
annevk: why can't we do it on any IDL-defined type?

[09:12:44.0000] <annevk>
bholley: so Domenic_ and others care for the ability to express platform APIs fully in terms of JS

[09:13:20.0000] <annevk>
bholley: overriding what Object.seal() and such do requires the usage of JS proxies to do that

[09:13:41.0000] <annevk>
bholley: JS proxies should really be a last resort in API design and not really used for anything that doesn't actually need it

[09:14:29.0000] <bholley>
annevk: can DOM objects as they stand be implemented without proxies?

[09:14:34.0000] <bholley>
annevk: like nodes

[09:15:06.0000] <bholley>
annevk: as in - would  this added requirement move it from possible to impossible?

[09:15:16.0000] <gsnedders>
bholley: Most of the DOM cannot. Some Nodes cans, others cannot.

[09:16:00.0000] <annevk>
bholley: so e.g. HTMLFormElement requires a proxy for sure, I'm not sure about Element in general, I don't think it does, though there are some things about branding that are not fully explained yet

[09:16:07.0000] <Domenic_>
gsnedders: which nodes cannot? The only thing I can think of is document.all

[09:16:15.0000] <Domenic_>
gsnedders: oh nevermind misread

[09:16:41.0000] <annevk>
bholley: there's a couple of proof of concepts of how branding (type checks) can be done through WeakMap, but not fully worked out afaik

[09:16:57.0000] <gsnedders>
Domenic_: My grammar is terrible. :)

[09:17:20.0000] <bholley>
annevk: basically, my feeling is that if we disallow freezing for Nodes and for Window, we've disallowed it for a good chunk of the DOM

[09:17:29.0000] <Domenic_>
annevk: I think it's pretty fully worked out

[09:17:36.0000] <bholley>
annevk: at which point we should just disallow it for everything

[09:18:33.0000] <annevk>
bholley: well, consider e.g. my <input type=file>.files thing that will return a regular JS Array

[09:18:52.0000] <annevk>
bholley: or ele.query() which will return an JS Array subclass

[09:19:06.0000] <annevk>
bholley: the lines are blurring

[09:19:15.0000] <bholley>
annevk: hm

[09:19:27.0000] <bholley>
annevk: it's true that they are

[09:20:03.0000] <annevk>
(btw, <input type=file> adoption could maybe just clear .files)

[09:20:09.0000] <annevk>
(and create a fresh array)

[09:20:44.0000] <bholley>
annevk: yeah. Are there any other cases where reparenting could theoretically involve reparenting a non-node?

[09:20:47.0000] <bholley>
I guess .style

[09:21:00.0000] <annevk>
also .classList

[09:21:13.0000] <annevk>
and .relList etc.

[09:21:24.0000] <Domenic_>
Wait isn't classList on the prototype

[09:21:32.0000] <Domenic_>
i.e. it's a getter that returns an internal representation

[09:21:32.0000] <bholley>
annevk: I would be opposed to leaving those things in the old scope

[09:21:37.0000] <bholley>
annevk: and just generating new ones

[09:21:43.0000] <bholley>
annevk: I don't think identity matters

[09:21:51.0000] <bholley>
annevk: er, sorry

[09:21:58.0000] <bholley>
annevk: _wouldn't_ be opposed

[09:22:08.0000] <annevk>
bholley: k

[09:22:28.0000] <annevk>
Domenic_: it returns an actual object though, and getting it twice will give you the same, but what bholley says can be done here

[09:22:48.0000] <annevk>
bholley: same could be done for .style and friends

[09:22:53.0000] <Domenic_>
right, what i think i was getting at (still wrapping my head around this) is that the internal object would change

[09:23:18.0000] <Domenic_>
i should go prototype this in JS with weakmaps etc.

[09:23:33.0000] <annevk>
Domenic_: that'd be cool

[09:23:40.0000] <jgraham>
So I haven't followed this enough and so should maybe not jump in here, but why can't adoption just be a clone operation that copies all the internal state into a new object?

[09:23:47.0000] <Domenic_>
^ yeah that sounds nice

[09:24:02.0000] <Domenic_>
but similar haven't-followed-this problems

[09:24:31.0000] <annevk>
jgraham: newDoc.appendChild(eleFromOldDoc); eleFromOldDoc.innerHTML = ...

[09:25:14.0000] <annevk>
Domenic_: ^

[09:25:31.0000] <jgraham>
annevk: You will have to elaborate a bit

[09:25:35.0000] <Domenic_>
what is that code supposed to illustrate, yeah...

[09:26:21.0000] <jgraham>
Oh I see

[09:28:25.0000] <jgraham>
Although you can imagine fixing that up with some sort of hack. Not that I'm advocating that or anything

[09:28:29.0000] <annevk>
That you cannot change identity

[09:28:37.0000] <Domenic_>
ahhh

[09:29:18.0000] <Domenic_>
what about if you threw when trying to adopt nodes that were extension-prevented

[09:29:47.0000] <Domenic_>
i.e. what if you just did Object.setPrototypeOf(ele.fromOldDoc, thisWindow.Element) and if that threw an exception, just let it bubble so that appendChild fails

[09:30:35.0000] <Domenic_>
ReturnIfAbrupt, as they say ;) <-- funny only to me

[09:35:52.0000] <annevk>
bholley: ^

[09:37:32.0000] <bholley>
annevk, Domenic_: there are other cases when we need to munge the prototype...

[09:37:44.0000] <bholley>
XBL/WebComponents

[09:37:46.0000] <bholley>
for example

[09:37:59.0000] <Domenic_>
sure, but presumably whatever operation needs to munge can just throw if the prototype is un-mungeable

[09:38:03.0000] <bholley>
potentially for document.open, but hopefully not

[09:38:34.0000] <bholley>
Domenic_: well, if we decide to reparent things with document.open, we can't really make document.open throw, I don't think

[09:39:11.0000] <bholley>
plugins

[09:39:41.0000] <Domenic_>
bholley: really? You think that there's some web code out there that (a) does Object.preventExtensions on a DOM node; (b) uses document.open?

[09:40:12.0000] <bholley>
Domenic_: I don't know, tbh. In Gecko, we mostly ignore preventExtensions on DOM nodes for the time being ;-)

[09:40:39.0000] <gsnedders>
Domenic_: It tends to be a good theory that there is, however stupid the thought it. Actually, especially if it is stupid.

[09:42:26.0000] <bholley>
Domenic_: I'd kind of rather not deal with C++ proto sets being fallible in a script-triggerable fashion. But I'm willing to consider it

[09:42:53.0000] <jgraham>
Is EvalScript trident thing?

[09:42:54.0000] <Domenic_>
bholley: what is a C++ :P

[09:42:55.0000] <bholley>
it just seems like the DOM is hard enough to implement as-is

[09:43:56.0000] <gsnedders>
/me very much wants JS to be able to implement the DOM

[09:44:39.0000] <jgraham>
YOu can't really ignore the fact that the DOM has a real implentation complexity. The more time that browser vendors spend chasing theoretical wins in self-hosting, the less time they have to spend on other things like performance or features

[09:45:27.0000] <bholley>
jgraham: my knight in shining armor

[09:47:06.0000] <gsnedders>
jgraham: Depends on how much gain performance would have by having the DOM all in JS and being able to be inlined.

[09:47:12.0000] <gsnedders>
s/would/we would/

[09:57:29.0000] <annevk>
bholley: what's bad about routing the prototype sets through script?

[09:59:05.0000] <bholley>
annevk: there are places in which we need to munge prototypes where we cannot fail

[09:59:30.0000] <bholley>
annevk: for example, if we fail midway through reparenting, there's no way to recover

[09:59:33.0000] <bholley>
annevk: we have to crash

[10:00:01.0000] <annevk>
bholley: could you elaborate in the bug? I have to go :/

[10:00:05.0000] <bholley>
annevk: so historically, we haven't been able to let script just decide that certain prototypes are unmungeable

[10:00:08.0000] <bholley>
annevk: ok

[10:02:15.0000] <annevk>
jgraham: as a closing note, I think nailing down the architecture in a way that everyone thinks is a win for the future is worth some time. What we decide here impacts how you architect your browser for decades to come. And hopefully many revisions to DOM implementations will be made over those decades.

[10:37:26.0000] <zewt>
man, time warner around here has the most bizarre problem: it randomly corrupts packets in a way that causes them to have the correct IP checksum

[10:38:35.0000] <zewt>
not like it's corrupting lots of packets and a couple happen to match (that would kill throughput); it just occasionally shuffles bytes around in a packet, which checksums won't detect

[10:39:42.0000] <zewt>
and tons of protocols just assume TCP streams are never corrupted, so it causes all kinds of weirdness

[10:41:38.0000] <Hixie_>
wow

[10:41:40.0000] <Hixie_>
that's messed up

[10:42:02.0000] <zewt>
it's so messed up that when we call the ISP and they send a guy out, he just goes "???"

[10:49:08.0000] <Hixie_>
"???" as in, "what's wrong", or as in, "wtf this makes no sense" ?

[10:49:36.0000] <zewt>
he just had no idea

[10:49:47.0000] <Hixie_>
no idea what you meant, or what the cause was?

[10:50:00.0000] <Hixie_>
there's two kinds of confusion possible here :-)

[10:50:05.0000] <zewt>
he understood the problem after I explained it long enough, but he had no idea why it was happening

[10:50:48.0000] <Hixie_>
aah ok

[10:50:58.0000] <zewt>
it's bizarre, since if it was just lots of packet corruption and once in a while one matched the checksum, it'd kill the connection completely

[10:51:21.0000] <Hixie_>
i'm on a business plan for my cable, it's pretty awesome, the slightest complaint and they roll a truck within 4 hours and fix things until it works

[10:51:46.0000] <Hixie_>
i was like "it seems we get occasional dropouts" at about 9pm, and by 11pm they'd rewired the entire building basically.

[10:51:57.0000] <smaug____>
slightlyoff: we really need webidl spec for ServiceWorker (https://github.com/slightlyoff/ServiceWorker/issues/99#issuecomment-26440824)

[10:52:00.0000] <smaug____>
sooner than later

[10:52:13.0000] <Hixie_>
(not even _that_ much more expensive than residential service, it's pretty crazy)

[10:52:15.0000] <smaug____>
or JSIDL and some tool which converts JSIDL to WebIDL

[10:52:16.0000] <zewt>
this is business too (it's our office), but it's one of those problems that always hides when a tech is on site

[10:52:21.0000] <smaug____>
/me doesn't understand this JSIDL stuff

[10:52:29.0000] <Hixie_>
oh the problem was gone by the time the tech got here in our case

[10:52:34.0000] <Hixie_>
he just rewired it all just in case

[10:52:52.0000] <zewt>
also, this has happened in every time warner installation i've used: my home cable, and business cable in two different offices

[10:53:21.0000] <Hixie_>
btytes shifted around pretty much has to be their back-end, right?

[10:53:27.0000] <Hixie_>
i mean, it's not like a bad cable is gonna cause that

[10:53:37.0000] <MikeSmith>
smaug____: what is TS+tests?

[10:54:03.0000] <MikeSmith>
and is anybody actually working on making a JSIDL?

[10:54:12.0000] <zewt>
seems like it has to be hardware and not cabling, yeah, seems like weird firmware in a cable modem is as likely a cause as a bad router though

[10:54:14.0000] <sgalineau>
IP checksums changing in flight? I'd call the NSA, not Time Warner :)

[10:54:17.0000] <zewt>
(which is to say, all equally unlikely)

[10:54:41.0000] <MikeSmith>
(I mean JSIDL at all for anything, as an alternative to WebIDL)

[10:54:42.0000] <zewt>
sgalineau: no, worse: the packet data is being corrupted, but in a way that results in the same IP checksum, so IP doesn't drop the packet

[10:54:44.0000] <smaug____>
TS is ...that odd format to describe classes or interfaces

[10:54:49.0000] <Hixie_>
zewt: try swapping out the router for another?

[10:54:55.0000] <smaug____>
MikeSmith: yeah, I haven't see anything concrete on JSIDL

[10:55:23.0000] <zewt>
Hixie_: i meant their routers (it could be anywhere in their stack)

[10:55:58.0000] <Hixie_>
zewt: well yeah, but you have control over one of them :-)

[10:56:50.0000] <zewt>
the only router we have is the one built into the cable modem :) (and yeah, getting a different router is one thing to try, though I suspect it's further up the chain)

[10:57:06.0000] <sgalineau>
zewt: man, that is twisted

[10:57:17.0000] <Hixie_>
get a replacement cable modem, swap it in, if it doesn't solve it, send it back :-)

[10:57:25.0000] <MikeSmith>
smaug____: seems pretty odd to be going ahead with implementations without the interface actually being documented or even without an actual spec

[10:57:43.0000] <zewt>
sgalineau: i wget'd a test file over http containing "0123456789" repeated, it downloaded without error and you'd see "0123546789" or something randomly

[10:58:05.0000] <smaug____>
MikeSmith: very much so

[10:58:11.0000] <smaug____>
MikeSmith: TS == http://en.wikipedia.org/wiki/TypeScript

[10:58:36.0000] <MikeSmith>
ah that

[10:58:46.0000] <zewt>
if IP used CRC's it'd catch it, but IP is ... old

[10:58:55.0000] <MikeSmith>
TypeScript looks kind of nice

[11:00:33.0000] <Hixie_>
zewt: time to use https for everything :-P

[11:07:04.0000] <zewt>
Hixie_: i do--that's what led to me earlier wondering about browsers not resuming downloads

[11:07:26.0000] <zewt>
https will kill the connection on error, but it won't automatically recover

[11:07:40.0000] <Hixie_>
ah

[12:26:16.0000] <smaug____>
Ms2ger: thanks

[14:01:26.0000] <annevk>
MikeSmith: JSIDL lacks resources, so we'll continue to work on IDL and address the ES6 requirements there

[14:02:14.0000] <annevk>
MikeSmith: as I understand it heycam|away managed to get a couple of months just for IDL so we should start seeing some progress there soonish

[14:02:30.0000] <annevk>
MikeSmith: including moving the thing to GitHub and such

[14:07:27.0000] <annevk>
slightlyoff: cool cool, sounds good

[14:07:42.0000] <annevk>
slightlyoff: I'll post updates once I've integrated Fetch into XMLHttpRequest

[14:24:35.0000] <smaug____>
annevk: is it still very much unclear to me what is wrong with webidl and what jsidl will change

[14:27:17.0000] <annevk>
smaug____: I think the primary change would be to describe the platform in terms of JavaScript rather than IDL types

[14:27:49.0000] <smaug____>
well, that doesn't say much about how the APIs would change in practice

[14:28:47.0000] <annevk>
smaug____: I don't think the intent is to change APIs other than encourage new APIs to follow better patterns, but that goal is shared with IDL I think

[14:30:06.0000] <smaug____>
"better patterns" tends to be vague

[14:30:27.0000] <smaug____>
there needs to be some reasoning to do Foo and not Bar

[14:31:06.0000] <annevk>
smaug____: again, the high-level reason is describing the entire platform in terms of JavaScript and making it self-hostable

[14:31:49.0000] <annevk>
smaug____: we don't necessarily need new IDL for that, but some people think they can convey their ideas better with a fresh start, although obviously they haven't found the time yet to write it out...

[14:33:06.0000] <smaug____>
I guess the question I have is that how does that help users of the APIs or implementors

[14:33:27.0000] <smaug____>
webidl is kind of a nice abstract layer above raw JS

[14:34:00.0000] <annevk>
smaug____: the idea is that APIs become more extensible than they are now

[14:34:14.0000] <annevk>
smaug____: e.g. classes become subclassable, just like built-ins are in ES6

[14:34:37.0000] <annevk>
smaug____: the other small benefit might be that we can use a somewhat better syntax, though that's discussed for IDL too

[14:35:02.0000] <smaug____>
hmm, hard to say much about better syntax without seeing any proposals

[14:35:09.0000] <annevk>
smaug____: for implementers it's mostly a cost I suppose, because the ES6-style world with subclassing is vastly more complex

[14:36:14.0000] <annevk>
smaug____: yeah, I can only say so much because I'm familiar with some of the ideas, having something concrete would indeed be way better

[14:37:28.0000] <zcorpan>
http://blog.paciellogroup.com/2013/10/using-html5-section-element/ ... why would a screen reader say "region" for each <section>? isn't that just annoying? and wrong, given that it's semantically equivalent to drop all <section>s and use h1-h6

[14:37:39.0000] <annevk>
smaug____: one change, which we're planning on making in IDL too, is to have distinction between class and interface

[14:37:45.0000] <zcorpan>
and i don't understand the recommendation to use aria-labelledby

[14:38:34.0000] <annevk>
smaug____: and IDL will adopt ES6-style classes and such, so I suspect most of the changes to happen in IDL unless JSIDL suddenly gets a bunch of resources

[14:38:59.0000] <smaug____>
right

[14:39:15.0000] <smaug____>
annevk: this all comes mainly from ServiceWorker stuff

[14:39:25.0000] <smaug____>
implementors implementing API which doesn't exist

[14:39:29.0000] <annevk>
smaug____: jdm worked out some IDL for ServiceWorker

[14:39:35.0000] <smaug____>
good

[14:40:14.0000] <annevk>
smaug____: if I had not been traveling I might have been more productive and actually done some work there, for now I'm occupied with correcting people on the internet and Fetch / XHR / URL

[14:40:39.0000] <annevk>
smaug____: less travel is one of my 2014 goals now

[14:40:56.0000] <smaug____>
ha

[14:49:09.0000] <zcorpan>
what's your knee-jerk reaction to renaming DOMRectReadOnly to DOMRectRead? (since the UA can mutate the object, it's supposedly not actually read *only* ....)

[14:49:43.0000] <Hixie_>
sounds weird

[14:49:51.0000] <Hixie_>
how about DOMRectView or something like that?

[14:50:00.0000] <Hixie_>
or DOMRect and MutableDOMRect

[14:51:49.0000] <zcorpan>
the mutable one needs the short name since it has a constructor, so that's the name people are going to write in their code

[14:52:41.0000] <zcorpan>
unless we do something magic like have a constructor for one interface that returns an object of the other, but that's really weird

[14:53:47.0000] <Hixie_>
then i'd go with DOMRect and DOMRectReadOnly

[14:53:55.0000] <Hixie_>
it's read-only, even if it can change

[14:54:18.0000] <Domenic_>
O_o

[14:54:33.0000] <Hixie_>
look at the readonly attributes in the DOM

[14:54:37.0000] <Hixie_>
most of them can change too

[14:54:41.0000] <Domenic_>
O__o

[14:55:32.0000] <Hixie_>
like firstChild

[14:55:32.0000] <Hixie_>
that's a readonly attribute

[14:55:32.0000] <Hixie_>
but if you change the DOM, it returns a different object

[14:55:35.0000] <Hixie_>
or NodeList.length

[14:55:48.0000] <Domenic_>
it sounds like a getter, not something that's read-only.

[14:55:48.0000] <Hixie_>
or formElement.validationMessage

[14:55:51.0000] <Domenic_>
since obviously it's being written.

[14:56:16.0000] <Hixie_>
i'm just saying that the IDL for these attributes reads "readonly attribute ..."

[14:56:25.0000] <Domenic_>
Right, and to that I say O__o

[14:56:34.0000] <Domenic_>
^ things JSIDL could fix

[14:57:08.0000] <Hixie_>
a readonly text field can change even while it's readonly

[14:57:16.0000] <Domenic_>
O___o

[14:57:17.0000] <Hixie_>
readonly doesn't mean "immutable", it means "can't be changed by you"

[14:57:27.0000] <Domenic_>
read only means you can only read it

[14:57:31.0000] <Hixie_>
right

[14:57:34.0000] <Hixie_>
YOU can only read it

[15:01:32.0000] <smaug____>
yeah, no need to use JSIDL for anything here.  it is pretty clear what readonly means in, webidl

[15:01:56.0000] <Domenic_>
it means we are in crazy magic land where you can write things that are read-only

[15:02:44.0000] <Hixie_>
"readonly" doesn't mean what you think it means, in pretty much any platform i've ever seen the term used in

[15:02:47.0000] <annevk>
Domenic_: <input readonly> can be written too...

[15:03:22.0000] <annevk>
Domenic_: Mark and apparently you seem to have a strange notion of readonly; I don't quite get it

[15:03:40.0000] <Domenic_>
I just don't understand how you can write something that is read only

[15:04:15.0000] <Domenic_>
but if there is precedence in other platforms and this isn't just some weird thing that WebIDL and <input> do, I guess that is my failing.

[15:04:46.0000] <annevk>
Domenic_: it seems kinda normal I can hand you an object that's readonly for you, but not me

[15:05:03.0000] <Domenic_>
i think of readonly as a property of the object, not of the object+person who's touching it pair

[15:05:20.0000] <annevk>
Domenic_: i.e. you're getting a readonly view of the situation

[15:05:43.0000] <annevk>
Domenic_: I see

[15:05:53.0000] <smaug____>
readonly is not const

[15:06:14.0000] <annevk>
Yeah, it seems immutable or const would be what you're after Domenic_

[15:06:36.0000] <Hixie_>
Domenic_: what would you call an object that can change value but that you are not allowed to directly change yourself?

[15:06:49.0000] <Hixie_>
such as the examples above?

[15:07:34.0000] <Domenic_>
Hixie_: you're describing two things here, an object, and a person with access to the object. Or, as Anne puts it, a view on the object. Typically I would not have a name for such an object, and say I have a getter to access the object.

[15:08:05.0000] <Domenic_>
Let me admit though that it seems clear the weight of the computer field is against my understanding here, so thanks for humoring me.

[15:08:09.0000] <Hixie_>
Domenic_: properties can have getters and setters, or just a getter, or just a setter. What keyword would you use in a WebIDL-analogue to indicate that a property has only a getter?

[15:12:29.0000] <Domenic_>
get

[15:15:44.0000] <Hixie_>
Domenic_: so you'd have like,  "get attribute" and "get set attribute" ?

[15:22:24.0000] <Domenic_>
Yeah

[15:24:45.0000] <zcorpan>
ok thanks, sent http://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/0125.html

[15:25:43.0000] <annevk>
I think get set name makes sense

[15:26:20.0000] <Hixie_>
delphi uses "property name: type; read reader; write writer;" so read-only ones are just "property name: type; read reader;"

[15:26:34.0000] <Hixie_>
which pretty much makes the term "read-only" obvious. :-)

[15:26:53.0000] <Hixie_>
basically, "read" seems to be a synonym for "get"

[15:27:08.0000] <Hixie_>
so "read only" is the same as "get only"

[15:28:22.0000] <Domenic_>
That does help conceptualize what I was missing, thanks :)

[15:28:52.0000] <annevk>
smaug____: that reminds me, one change I've heard people suggest is having get/set properties as everything in IDL is now, but also have data properties as JavaScript has

[15:29:56.0000] <Hixie_>
can anyone figure out a way to have a zero-width image in an img?

[15:30:03.0000] <Hixie_>
(not img width:0 so width=0)

[15:30:08.0000] <Hixie_>
s/so/or/

[15:30:15.0000] <zcorpan>
Hixie_: svg?

[15:30:43.0000] <Hixie_>
hm, interesting idea

[15:32:08.0000] <Hixie_>
data:text/xml,<svg xmlns="http://www.w3.org/2000/svg" viewbox="0 0 0 0"><circle fill="red" cx="0" cy="'0" r="10"/></svg>

[15:33:04.0000] <Hixie_>
s/'///

[15:33:09.0000] <Hixie_>
-/

[15:33:34.0000] <Hixie_>
odd, chrome doesn't render svg in img?

[15:33:47.0000] <smaug____>
annevk: use cases, use cases, please :)

[15:33:58.0000] <zcorpan>
Hixie_: you need image/svg+xml for <img>

[15:34:10.0000] <Hixie_>
oh

[15:34:13.0000] <Hixie_>
well that's lame

[15:34:18.0000] <Hixie_>
thanks

[15:35:06.0000] <Hixie_>
weird, firefox treats it as 300x150

[15:35:20.0000] <Hixie_>
chrome too

[15:35:29.0000] <Hixie_>
viewBox maybe

[15:36:05.0000] <Hixie_>
that made it disappear but didn't change the dimensions

[15:36:08.0000] <Hixie_>
weirder and weirder

[15:36:31.0000] <zcorpan>
might be how CSS sizes replaced elements without intrinsic size or something

[15:36:53.0000] <zcorpan>
dunno if svg says that 0 means no intrinsic size though

[15:37:20.0000] <Hixie_>
ah, width= and height= maybe

[15:37:20.0000] <annevk>
smaug____: I'll defer to Domenic_, but e.g. if we're going to subclass built-ins, we need to be able to express what they have

[15:37:42.0000] <Hixie_>
ok, in firefox that worked

[15:37:47.0000] <Hixie_>
<svg ... width=0 height=0>

[15:39:44.0000] <annevk>
I should really go to bed, but I just had an idea. What if JavaScript's standard library was defined in terms of an IDL that could also be used downstream... Instead of "moaning" they could be leading the way ;P

[15:43:22.0000] <Hixie_>
annevk: that would be ideal imho


2013-10-17
[18:21:27.0000] <Domenic_>
annevk-cloud: does https://twitter.com/briankardell/status/390635642407124992 mean copy-paste from WHATWG to W3C?

[18:27:39.0000] <MikeSmith>
Domenic_: what it means will be up to slightlyoff and Robin, but I think you know them well enough to know they may not just going to be doing copy-paste

[18:28:33.0000] <Domenic_>
more forking? :-/

[18:28:37.0000] <MikeSmith>
though really I'm just speculating because I don't actually know what the details of the plan are

[18:30:30.0000] <MikeSmith>
Domenic_: yeah, one way or the other

[18:35:37.0000] <MikeSmith>
Domenic_: but really if you want more than speculation I guess you should ask slightlyoff and robin what the plan is :)

[18:36:16.0000] <Domenic_>
MikeSmith: indeed, I forgot they lurked here sometimes.

[20:47:37.0000] <Hixie_>
i feel like i'm missing some context or the lastest w3c meme :-)

[20:49:31.0000] <nimbu1>
lol latest one is gold.

[21:12:46.0000] <cabanier>
I get all my news from w3c memes

[21:20:11.0000] <nimbu1>
ahahhahahah

[21:20:14.0000] <nimbu1>
that can be a meme cabanier

[22:13:13.0000] <MikeSmith>
So I interpret that w3c meme as coded language that's basically saying, "Hakon should be the chair of the CSS WG"

[22:13:18.0000] <MikeSmith>
in which case, +1

[22:20:17.0000] <karlcow>
http://lists.w3.org/Archives/Public/www-style/2013Oct/0385.html

[22:21:41.0000] <nimbu1>
lol MikeSmith

[22:44:51.0000] <Hixie_>
karlcow: it's the bottom text i don't understand, and the caption at the bottom

[22:48:42.0000] <MikeSmith>
I don't know if the context of the caption at all but even out of whatever the intended context is, It's just funny

[23:01:05.0000] <annevk>
Domenic_: you'll have to ask darobin and slightlyoff as I've no idea

[23:01:45.0000] <annevk>
Domenic_: W3C just forks, they don't really communicate about it with the original author

[23:02:15.0000] <annevk>
Domenic_: see http://lists.w3.org/Archives/Public/public-i18n-core/2013OctDec/0013.html

[01:40:40.0000] <zcorpan>
Hixie_: so if i understand correctly, the objection with DOMRectReadOnly wasn't that nobody is allowed to mutate it, but that DOMRect inherits from DOMRectReadOnly and so a mutable object has DOMRectReadOnly in the prototype chain which looks like a lie

[01:41:21.0000] <annevk>
hsivonen: so I thought <iframe></iframe><script>window[0].document.body.innerHTML = "bah"</script> was required to work

[01:41:32.0000] <annevk>
hsivonen: but it seems it's not...

[01:54:03.0000] <MikeSmith>
zcorpan: I haven't had time to mess around with the non-spec parsing idea further. I think where we had left it, it seems like my hacks were causing the script end tag to not get emitted as expected. Because the script element was still on the stack of open elements at the point where it crashed (where it's supposed to be handling the body start tag)

[01:56:39.0000] <zcorpan>
MikeSmith: ok. i guess it's clear that none of us know what we're doing :-P

[01:57:40.0000] <zcorpan>
i don't understand how the handling of the script end tag is affected by the changes

[02:01:15.0000] <MikeSmith>
zcorpan: yeah I looked back at the code and I don't understand either how it would be affecting it. Honestly it could just be that the hack I put in to serialize the stack out to

[02:01:33.0000] <MikeSmith>
...stdout is broken too

[02:02:45.0000] <annevk>
zcorpan: so a subclass should not be able to access private state?

[02:02:54.0000] <annevk>
zcorpan: is that the contention?

[02:02:56.0000] <MikeSmith>
zcorpan: but yeah I don't really know what I'm doing with that code

[02:03:26.0000] <zcorpan>
annevk: see http://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/0126.html

[02:04:16.0000] <annevk>
zcorpan: all I read in that email is Mark Miller agreeing

[02:06:52.0000] <zcorpan>
annevk: yet he objects to the name ReadOnly, so i must have misunderstood the argument. also see http://www.w3.org/mid/CABHxS9j_HshM-sHBL1cxpk+ACf91eKhvcihrLYtGJxCWEE=yBQ⊙mgc

[02:09:04.0000] <annevk>
zcorpan: interesting, I wonder if he's willing to expand on that, I'll reply

[02:42:40.0000] <zcorpan>
maybe role=region by default for <section> is a mistake?

[02:45:30.0000] <zcorpan>
aria's definition of region seems like a good match (except "large" i guess) http://www.w3.org/TR/wai-aria/roles#region

[02:47:28.0000] <zcorpan>
"Authors SHOULD ensure that a region has a heading referenced by aria-labelledby."

[03:05:39.0000] <annevk>
Game of Thrones fans: http://www.youtube.com/watch?v=5Krz-dyD-UQ

[03:27:57.0000] <jgraham>
(fwiw I note that using "readonly" to mean "not user editable" appears to be very common in GUI framworks e.g. both win32 and Qt seem to use that terminology)

[03:29:09.0000] <jgraham>
zcorpan: I assume the argument against making DOMRect extends DOMRectReadOnly is that DOMRect violates the contract of DOMRectReadOnly so it doesn't follow the LSP

[03:30:28.0000] <zcorpan>
jgraham: right

[03:30:41.0000] <jgraham>
It's an argument of the form "you can't have Square extends Rectangle because doing sqaure.width = 4 will also set square.height = 4, which violates the invariants of Rectangle

[03:31:28.0000] <jgraham>
Personally I'm not convinced that it's a more-than-theoretical concern

[03:31:34.0000] <jgraham>
Especially in JS

[03:33:49.0000] <jgraham>
(I don't really see how you could have any inheritance between a Foo and a Foo[View|ReadOnly] and conform with the LSP, so I think the only theoretically pure solution is to have two entirely seperate interfaces)

[03:34:13.0000] <annevk>
Yeah, use mixins or some such

[03:34:32.0000] <jgraham>
(even if they access the same underlying data)

[03:38:11.0000] <annevk>
Well, what roc suggested early on in the thread works too.

[03:38:34.0000] <annevk>
DOMRectBase; DOMRectReadonly extends DOMRectBase; DOMRect extends DOMRectBase;

[03:39:10.0000] <darobin>
it might be a completely stupid idea, but could frozen objects be used instead here?

[03:39:20.0000] <darobin>
I mean, you just define DOMRect, which is mutable and all

[03:39:32.0000] <annevk>
darobin: frozen doesn't mean what you think it means

[03:39:36.0000] <darobin>
and when you need to return a readonly one, you say [Frozen] DOMRect

[03:39:47.0000] <darobin>
oh, right, not the values

[03:40:15.0000] <annevk>
Best to mostly forget about Object.freeze() et al. They're only useful for Caja...

[03:40:24.0000] <darobin>
wrong term, but the idea still holds

[03:40:46.0000] <darobin>
I was thinking frozen as in, you know, frozen; not Object.freeze()

[03:40:49.0000] <annevk>
darobin: TabAtkins explored that idea, same fread

[03:40:56.0000] <annevk>
thread, evne

[03:40:57.0000] <darobin>
ah. missed that

[03:40:59.0000] <annevk>
even, even

[03:46:03.0000] <MikeSmith>
annevk: thanks for the info about JSIDL

[03:46:15.0000] <MikeSmith>
hope somebody takes an interest in working on it

[03:46:48.0000] <jgraham>
Yes, an abstract base class works

[03:46:58.0000] <annevk>
MikeSmith: apparently Domenic_ was planning to, but then we hijacked him to work on Promises & Streams, which seems much more useful anyway

[03:47:10.0000] <jgraham>
But javascript doesn't have any real concept of abstract classes

[03:47:39.0000] <MikeSmith>
annevk: I thought you guys were done on Promises

[03:47:51.0000] <MikeSmith>
btw what is XHR referencing for Streams now?

[03:48:15.0000] <annevk>
I kinda like my idea of last night to have the ECMAScript standard library defined in IDL. Anyway...

[03:48:19.0000] <annevk>
MikeSmith: nothing at the moment

[03:48:24.0000] <MikeSmith>
last I remember CHrome had implemented some support for Feras's spec

[03:48:41.0000] <annevk>
MikeSmith: ES5 promises is done, ES6 promises requires subclassing, which is tricky so there's a few issues left in the spec

[03:48:43.0000] <Domenic_>
MikeSmith: to have them be ES6-acceptable they need to work well with ES6 subclassing, so that's what's currently undergoing work. They are complete at the ES5 level

[03:48:49.0000] <jgraham>
/me thinks JSIDL seems like a waste of time

[03:48:49.0000] <Domenic_>
haha jinx

[03:49:03.0000] <Domenic_>
annevk: I like that idea to, for sure.

[03:49:17.0000] <MikeSmith>
getting Domenic_ and annevk in stereo :)

[03:50:26.0000] <MikeSmith>
so is Feras's Streams spec dead?

[03:50:50.0000] <annevk>
MikeSmith: yeah and the discussion on public-webapps is mostly being ignored too

[03:50:57.0000] <MikeSmith>
ok

[03:51:43.0000] <annevk>
jgraham: it's not helpful to be so negative all the time

[03:52:13.0000] <jgraham>
I'm not being negative all the time

[03:52:21.0000] <annevk>
jgraham: about JSIDL you are

[03:52:28.0000] <jgraham>
I think that JSIDL has lots of costs and very little value

[03:52:49.0000] <annevk>
jgraham: there are some smart people out there that want to explore it, let them be, just saying "it's a waste of time" isn't helping anyone

[03:52:59.0000] <jgraham>
for any person that's qualified to work on it, there are half a dozen more useful things that they could be doing

[03:53:23.0000] <annevk>
jgraham: the same could be said for working on Fetch

[03:53:35.0000] <annevk>
jgraham: improvements to the immediate status quo are marginal

[03:53:42.0000] <jgraham>
If you really believe that, I urge you to stop working on Fetch

[03:54:06.0000] <annevk>
I don't believe that, but if there's someone out there that would keep saying "it's a waste of time", I fould find that hugely irritating

[03:54:29.0000] <annevk>
and not very helpful

[03:55:54.0000] <jgraham>
Well if people are determined to work on it then nothing I can say is going to stop them. But so far the arguments in favour of it have been very weak. "Syntax slightly more like JS" doesn't seem like a big win.

[03:56:39.0000] <jgraham>
And there is a huge cost if specs start using something that isn't supported by bindings generators for implementations

[03:56:57.0000] <annevk>
If you think that's the main argument...

[03:57:03.0000] <jgraham>
Because you either need to implement a second set of bindings generators or port everything to WebIDL

[03:57:18.0000] <darobin>
the cost isn't in the binding generators

[03:57:35.0000] <darobin>
the cost is in remembering what a given WebIDL construct actually does in JS when the match doesn't line up all that well

[03:57:40.0000] <jgraham>
It's the main argument that I've heard that couldn't be achieved by incremental improvements to WebIDL

[03:58:39.0000] <jgraham>
darobin: Those seem like costs for quite different people

[03:59:06.0000] <darobin>
yeah, for the people writing and reading specs; they tend to be a pretty important constituency for this stuff :)

[04:00:40.0000] <darobin>
and anyway, when people are working on something that doesn't seem very useful to me, there are two situations

[04:00:49.0000] <darobin>
1) they're smart, so they probably know why they're doing it

[04:00:55.0000] <darobin>
2) they're dumb, so it doesn't matter

[04:01:13.0000] <annevk>
darobin++

[04:01:23.0000] <jgraham>
I don't think those are an active characterisation of the possibilities at all

[04:01:49.0000] <jgraham>
For example there is 3) They are smart but haven't considered the oppertunity costs of the work

[04:01:55.0000] <darobin>
no, but you have to admit that it makes for neat little boxes

[04:02:23.0000] <jgraham>
(and a whole bunch more about oppertunity costs and so on that I won't type out)

[04:02:50.0000] <darobin>
there clearly would be an opportunity cost in you typing more about opportunity costs

[04:03:01.0000] <jgraham>
If the world was full of smart people doing useful things and dumb people doing irrelevent things it would be a lot better

[04:03:12.0000] <annevk>
Playing the conservative card is not helpful. Disruption is good.

[04:03:15.0000] <jgraham>
But instead you have lots of smart people doing irrelevant things

[04:03:57.0000] <darobin>
smart people shaving yaks have been known to produce useful things once in a while

[04:04:06.0000] <darobin>
/me makes some tea for grumpy jgraham

[04:04:09.0000] <Domenic_>
like yak fur

[04:04:21.0000] <darobin>
mmmm, a yak fur pillow

[04:04:59.0000] <jgraham>
I'm not really grumpy. If there's one thing I'm sure of it's that the people who talk about JSIDL don't give a fuck what I think

[04:05:05.0000] <darobin>
anyway, with these fine words about smart people doing irrelevant things let me get back to work

[04:05:24.0000] <Domenic_>
jgraham: i dunno, your words are more hurtful/discouraging than you might imagine.

[04:06:05.0000] <darobin>
yeah, being negative on the premise that people don't care runs the risk that they actually do

[04:06:12.0000] <jgraham>
But I don't want all discussions in the present to be dragged through "but in the future JSIDL…"

[04:06:23.0000] <annevk>
jgraham: I have invested time in JSIDL and I care

[04:06:25.0000] <darobin>
that is very much a fair (and constructive) point

[04:07:48.0000] <annevk>
And I do think it's useful to think about what things might look like five years from now. And how a world where C++ is an implementation detail would work, and what that would simplify at the IDL level.

[04:08:30.0000] <annevk>
And whether we call that JSIDL or an iteration over IDL I care less about. I have been pushing changes to the latter in the absence of the former, but it's the same thing imo.

[04:08:57.0000] <jgraham>
I don't think it's the same thing at all

[04:09:02.0000] <jgraham>
One is iterative improvement

[04:09:14.0000] <jgraham>
The other is "throw it all out and start again"

[04:09:40.0000] <annevk>
Even heycam thinks he might have to do a bunch of drastic changes at once which would require a bunch of down-level work.

[04:09:47.0000] <darobin>
those aren't the only two options jgraham

[04:10:17.0000] <darobin>
jgraham: for instance, you can have "look, we figured out where we want to get that's a nice place, now we can move WebIDL closer to that in increments"

[04:10:29.0000] <annevk>
And having some people work on a clean slate approach helps informing the iterative movement.

[04:10:30.0000] <darobin>
figuring out what works and how to get there are different things

[04:11:01.0000] <jgraham>
I have already said that I think iterative improvements are good

[04:12:16.0000] <jgraham>
What *does* make me grumpy is crap like they are pulling with ServiceWorker where people refuse to use WebIDL and end up externalising the cost onto vendors and ultimately users through poorer interop.

[04:12:29.0000] <annevk>
Both are good. Just like having many programming languages is good. Temporary competition here can be great I think.

[04:12:44.0000] <annevk>
ServiceWorker isn't even a specification... It's just a set of notes and a TypeScript file...

[04:12:55.0000] <jgraham>
And yet it is being implemented

[04:13:09.0000] <jgraham>
That is exactly what is annoying about it

[04:13:18.0000] <annevk>
IDL or JSIDL has nothing to do with that.

[04:13:25.0000] <darobin>
didn't I just see that there was IDL somewhere that was gonna be contributed there?

[04:13:37.0000] <annevk>
Yeah, jdm created some IDL.

[04:14:06.0000] <jgraham>
annevk: It does if some specs are written in one dialect and some are written in another dialect and people only implement a single dialect

[04:14:20.0000] <annevk>
jgraham: ServiceWorker is not a spec

[04:14:32.0000] <jgraham>
annevk: You are not making it better

[04:14:39.0000] <annevk>
jgraham: and do you honestly think that's going to be the end situation?

[04:14:42.0000] <jgraham>
It is a technology that is being put in browsers

[04:14:46.0000] <annevk>
jgraham: transitions are always messy

[04:15:00.0000] <jgraham>
I don't really care if it gets a spec months after the implementations have shipped

[04:15:08.0000] <jgraham>
Because by then the damage is done

[04:15:17.0000] <annevk>
IDL is not going to make the damage any less, I can tell you that

[04:15:31.0000] <jgraham>
Seriously?

[04:15:35.0000] <annevk>
Especially since IDL is not interoperably implemented at the moment

[04:15:38.0000] <jgraham>
There are two reasons it would

[04:16:05.0000] <jgraham>
One is that IDL is directly supported by browsers so you can quickly get some level of interop at the bindings layer

[04:16:08.0000] <annevk>
All the issues are going to be in the processing model. Lifetime and such.

[04:17:43.0000] <jgraham>
And the second is that being prepared to write a spec and IDL suggests an interest in working with the community on their own terms, rather than doing your own thing because you can't hold your nose and use a technology you don't like

[04:18:32.0000] <annevk>
It seems your beef is with ServiceWorker and not the idea of JSIDL...

[04:18:38.0000] <annevk>
Did you email Alex?

[04:19:08.0000] <jgraham>
I specifically said that this complaint was about ServiceWorker

[04:33:02.0000] <MikeSmith>
about IDL not being interoperably implemented, does that mainly mean not implemented per spec in Blink?

[04:33:35.0000] <MikeSmith>
because Gecko now prety much follows the current spec, right?

[05:25:54.0000] <annevk>
MikeSmith: yeah, Blink and WebKit I suppose

[05:26:16.0000] <annevk>
Though to be fair to them, there's a bunch of bugs against the spec, too

[05:27:15.0000] <MikeSmith>
annevk: yeah but modulo those bugs I've heard there's some problem that prevents them from implementing it per spec

[05:27:22.0000] <MikeSmith>
performance issue or something?

[05:28:21.0000] <MikeSmith>
I know there's some intentional difference with extended attributes

[05:28:26.0000] <annevk>
Oh, there might be something like that with respect to getting the prototype chain correct

[05:28:29.0000] <MikeSmith>
and commas

[05:28:40.0000] <MikeSmith>
trailing commas

[05:28:42.0000] <annevk>
I forgot the details, but yeah, that rings true

[05:29:39.0000] <MikeSmith>
would be nice if the future IDL work (incremental or otherwise) finds some way to address that

[05:30:24.0000] <MikeSmith>
because it would really suck to have people do a bunch of new work on IDL in any form and then it still doesn't get implemented in Blink and WebKit per spec

[05:30:54.0000] <annevk>
I think this is something Blink and WebKit have agreed to figure out, because what they have now doesn't make much sense ES-wise

[05:39:35.0000] <MikeSmith>
ok

[05:40:14.0000] <annevk>
Hmm, HTML's fetching algorithm doesn't deal with termination

[05:44:00.0000] <annevk>
I guess I'll say that fetching can be <dfn>terminated</dfn> with a /reason/

[05:44:18.0000] <annevk>
Then annotate response objects with <dfn>termination</dfn> = /reason/

[05:44:41.0000] <annevk>
And then XHR can check if response.termination == "end-user abort" or some such

[06:14:06.0000] <annevk>
Hixie_: for dfn.js, it'd be kinda neat if references from obvious non-normative places were styled differently

[06:15:00.0000] <annevk>
Hixie_: I like to reference algorithms all over, but when looking up where an algorithm is used I only care about none-.note related usage

[08:02:34.0000] <zcorpan>
at least darobin is sensible enough to not let the new dom fork rot

[08:03:00.0000] <Ms2ger>
Another one?

[08:03:33.0000] <zcorpan>
why not? forking is fun

[08:06:54.0000] <Ms2ger>
Clearly

[08:16:54.0000] <jgraham>
The W3C needs more spooning

[08:31:51.0000] <SteveF>
jgraham here here

[08:33:35.0000] <annevk>
hear?

[08:33:37.0000] <annevk>
but yes

[08:41:54.0000] <SteveF>
probably

[08:55:40.0000] <niloy>
can someone look at this and please tell me if this a problem with firefox/chrome http://jsfiddle.net/4KbML/

[09:00:43.0000] <annevk>
niloy: 1 is not an IDENT

[09:00:55.0000] <annevk>
niloy: so you need quotes or an escape

[09:01:18.0000] <niloy>
annevk, got it, thanks

[09:01:36.0000] <annevk>
[data-cid=\31] should work

[09:01:44.0000] <annevk>
niloy: see http://mothereff.in/css-escapes

[09:02:21.0000] <niloy>
annevk, [data-cid=\1] failed

[09:02:36.0000] <annevk>
niloy: well that's not what I suggested

[09:02:39.0000] <TabAtkins>
niloy: That's because that's an escape for u+0001

[09:02:57.0000] <TabAtkins>
But using quotes is better.  Don't do escapes for this, it's silly.

[09:04:30.0000] <niloy>
yes got it

[09:05:24.0000] <Hixie_>
annevk: there's a "nobackref" class or something that lets you exclude them from dfn.js, if you that works

[09:05:35.0000] <annevk>
oooh

[09:06:23.0000] <annevk>
Hixie_: ah, and it can also be applied on the parent

[09:06:45.0000] <Hixie_>
if that works for you, even. not sure what my word happened.

[09:07:01.0000] <annevk>
Hixie_: seems like adding && links[k].parentNode.className != "note" would be trivial

[09:07:04.0000] <Hixie_>
i use it in the <input type=foo> sections to exclude the "doesn't apply" sections

[09:07:11.0000] <Hixie_>
annevk: yeah i'm happy to add something else if you want it

[09:07:21.0000] <annevk>
I'll play with this first I suppose

[09:08:36.0000] <Hixie_>
wow, i didn't realise the w3c even forked the URL spec

[09:08:40.0000] <Hixie_>
that's special

[09:08:51.0000] <Hixie_>
why would they not fork it when it was in the IETF but would fork it when it was at the WHATWG???

[09:09:19.0000] <Hixie_>
i mean, that's crazy. we fork the IETF spec, and they then fork the WHATWG spec.

[09:10:29.0000] <sgalineau>
it's forking all the way down

[09:11:06.0000] <annevk>
We technically didn't fork. I wrote the whole thing from scratch to prevent issues.

[09:12:23.0000] <Hixie_>
yeah i don't mean that the spec text was forked

[09:12:48.0000] <Hixie_>
and i guess the IETF had said they wouldn't maintain it, so it was more like HTML4->WHATWG HTML

[09:13:09.0000] <Hixie_>
i just don't get it.

[09:13:11.0000] <annevk_>
So there's http://www.w3.org/TR/url/

[09:13:15.0000] <sgalineau>
right; rebooting something frozen isn't forking

[09:13:23.0000] <annevk_>
I remember Charles at some point saying he was going to write the URL spec

[09:13:45.0000] <Hixie_>
it's like the w3c's desire to piss off the whatwg is greater than their desire for to not piss off the ietf.

[09:13:59.0000] <annevk_>
He was quite explicit about it not going to be a fork, but I think at the moment it's nothing...

[09:14:09.0000] <jgraham>
Nothing is not a fork

[09:14:16.0000] <jgraham>
So he was true to his word

[09:14:37.0000] <sgalineau>
it's a spork!

[09:20:37.0000] <tantek>
/me waits for URL naming bikeshedding so he can update his table. 

[09:20:56.0000] <tantek>
for *more

[09:21:52.0000] <annevk>
tantek: I'd like for http://url.spec.whatwg.org/ to be final, as a bunch of specs depend on that now

[09:22:40.0000] <annevk>
tantek: also, I guess people can bikeshed, but at this point they'll need bargaining chips to get change

[09:24:35.0000] <tantek>
annevk: Fine with me.

[09:27:18.0000] <annevk>
In other news: https://blog.mozilla.org/research/2013/10/17/studying-lossy-image-compression-efficiency/

[09:32:32.0000] <jgraham>
The right feedback for that study is "graphs without axis labels? Really?"

[09:37:16.0000] <zewt>
declaring php the ultimate failure

[09:37:26.0000] <zewt>
re: syntax changes depending on configuration

[09:42:42.0000] <Domenic_>
annevk: nrrr fix https://github.com/annevk/url/issues/1

[09:43:10.0000] <Domenic_>
file:/// should never exist on Windows systems.

[09:43:29.0000] <annevk>
so many special casing for that

[09:43:45.0000] <annevk>
Domenic_: so people run Node.js on top of Windows?

[09:43:48.0000] <astearns>
annevk: if a CORS-enabled fetch is in Anonymous mode, the 'omit credentials flag' is set. What is it set to?

[09:44:05.0000] <annevk>
astearns: a flag is either set or unset

[09:44:26.0000] <annevk>
astearns: it's the English equivalent of a boolean

[09:44:34.0000] <astearns>
ah, I'm looking for the omit credentials mode

[09:44:45.0000] <annevk>
astearns: ooh, mode would be set to CORS

[09:44:52.0000] <astearns>
ok, good

[09:44:54.0000] <astearns>
thanks!

[09:44:56.0000] <Domenic_>
annevk: yeah, it's pretty big on Windows

[09:45:28.0000] <annevk>
poor Node

[09:45:54.0000] <Domenic_>
Most of the web runs on Windows, all you elitist Mac users forget that :P

[09:46:10.0000] <Domenic_>
(most of the web's users, I mean)

[09:46:48.0000] <annevk>
I thought most of the web ran on Linux

[09:46:54.0000] <annevk>
runs, even

[09:50:21.0000] <sgalineau>
a big chunk of the back end is linux; most of the front end remains windows

[09:51:06.0000] <sgalineau>
though windows 8 could fix that *cough*

[09:51:34.0000] <astearns>
annevk: the mode being set to CORS makes sense, but I'm not seeing the part in the spec that says this

[09:52:19.0000] <annevk>
astearns: http://fetch.spec.whatwg.org/#requests has CORS as a value

[09:53:35.0000] <astearns>
it does, and HTML fetch says what it's set to, but none of the other fetch steps mention setting the value

[09:53:58.0000] <annevk>
astearns: the algorithm only reads it

[09:55:22.0000] <annevk>
there's a few fields on a Request that are supposed to be writable, but most is only ever read

[09:56:32.0000] <astearns>
annevk: I just want to make sure that what I define here: http://dev.w3.org/csswg/css-shapes/#shape-outside-property has the mode set to CORS and not 'never'

[09:57:03.0000] <astearns>
and I'm not seeing the spec text that tells me one way or the other

[09:58:04.0000] <annevk>
astearns: oh wait, it sets it to /always/

[09:58:12.0000] <annevk>
astearns: which is good

[09:58:29.0000] <astearns>
so it follows the HTML fetch steps?

[09:59:42.0000] <annevk>
so it's a slight change for same-origin requests

[10:00:23.0000] <annevk>
and that change was made after Hixie_ said he intended for it to be modeled after XHR anonymous mode

[10:00:34.0000] <annevk>
but I suppose we might need to change that back at some point

[10:00:42.0000] <annevk>
meeting, biab

[10:00:55.0000] <annevk>
gonna discuss JSON with the TAG

[10:01:00.0000] <annevk>
cannot really think of anything more exciting

[10:15:21.0000] <Domenic_>
haha

[10:42:30.0000] <jgraham>
/me still doesn't understand what's wrong with DOMRectReadOnly

[10:43:43.0000] <TabAtkins>
Me neither. :/  But DOMRectView is fine, I suppose.  Way better than DOMRectRead.

[10:45:03.0000] <jgraham>
Isn't DOMRectView confusing with ArrayBufferView?

[10:46:49.0000] <jgraham>
(since afacit ArrayBufferViews are not read-only)

[10:46:49.0000] <Hixie_>
is there a quick way to add tests to the html5lib test suite?

[10:46:55.0000] <Hixie_>
or do i need to check it out or something

[10:47:17.0000] <jgraham>
YOu can probably edit it directly on github, if that's your thing

[10:47:26.0000] <jgraham>
You still need to make a pull request though

[10:47:40.0000] <Hixie_>
wonder if i have hg

[10:47:46.0000] <jgraham>
It's git

[10:48:12.0000] <jgraham>
https://github.com/html5lib/html5lib-tests

[10:48:17.0000] <Hixie_>
oh it moved to github? k

[10:48:25.0000] <Hixie_>
google search found the google code repo

[10:48:38.0000] <Hixie_>
we should probably close that if it's dead

[10:49:26.0000] <Ms2ger>
"NOTE: html5lib is now hosted at github: https://github.com/html5lib"

[10:53:10.0000] <Hixie_>
is there some way to test my test?

[10:54:58.0000] <jgraham>
Like what?

[10:55:06.0000] <jgraham>
YOu can run the testsuite in html5lib

[10:55:14.0000] <jgraham>
It might fail of course

[10:55:22.0000] <jgraham>
Depending on what you are testing

[10:55:36.0000] <Hixie_>
guess i'd better get html5lib too

[10:55:51.0000] <Hixie_>
i just want to make sure my syntax is right :-)

[10:56:30.0000] <TabAtkins>
jgraham: Hmm, maybe, yeah.

[10:59:25.0000] <TabAtkins>
The whole conversation is ridiculous.  LSP isn't dependent on the name of a class, so being okay with subtyping under one name but not another is silly.

[10:59:36.0000] <jgraham>
Wait, what?

[10:59:53.0000] <jgraham>
I assume he still wasn't OK with subtyping because that would make no sense

[11:00:48.0000] <Hixie_>
man, i've no idea what i'm doing with these newfangled source repos and stuff

[11:01:09.0000] <Hixie_>
if i've got a local copy of the html5lib repo, how do i run it?

[11:01:14.0000] <Hixie_>
i don't want to install it...

[11:02:23.0000] <jgraham>
Well I don't think you can anymore because it needs a compat library to work in both Python 2 and 3

[11:02:50.0000] <Hixie_>
so how does an html5lib developer, like, develop it?

[11:02:52.0000] <jgraham>
But you should use a python virtualenvironment that you can blow away when you are done

[11:03:29.0000] <Hixie_>
i miss the old days of just downloading a tarball, running "make", and then sending the devs a diff.

[11:04:02.0000] <TabAtkins>
jgraham: No, no, subtyping is fine.

[11:04:21.0000] <Hixie_>
http://simononsoftware.com/virtualenv-tutorial/ "Installation is very easy." first example involves sudo.

[11:04:44.0000] <jgraham>
Hixie_: You do something like "virtualenv html5lib; source html5lib/bin/activate; cd /path/to/html5lib/clone; pip install -e ./"

[11:04:47.0000] <TabAtkins>
Virtually everything requires sudo.  That's not a marker of "not easy".

[11:05:08.0000] <jgraham>
TabAtkins: Is fine in principle or in practice?

[11:05:22.0000] <TabAtkins>
jgraham: Don't care, because practice is good enough for me.

[11:05:29.0000] <Hixie_>
wow, i actually have virtualenv installed on this box.

[11:05:33.0000] <Hixie_>
jgraham: thanks

[11:05:51.0000] <gsnedders>
TabAtkins: You can do almost everything without sudo.

[11:06:02.0000] <TabAtkins>
Except installing things.

[11:06:12.0000] <gsnedders>
TabAtkins: Just install into non-standard locations.

[11:06:17.0000] <jgraham>
I'm pretty sure that DOMRect extends DOMRectReadOnly violates the LSP. I'm not convinved that's a real problem in js, but I don't have a convincing argument

[11:06:23.0000] <TabAtkins>
Which i susually more difficult.

[11:06:43.0000] <gsnedders>
jgraham: Why would it violate the LSP?

[11:06:56.0000] <TabAtkins>
jgraham: Only if you consider "can't be modified by me, but might be modified by something else" an ability which you lose, in which case LSP would prevent virtually all subclassing.

[11:07:00.0000] <Ms2ger>
Maybe the other way around?

[11:07:03.0000] <Hixie_>
great, i have virtualenv, but not pip. sigh.

[11:07:09.0000] <gsnedders>
Hixie_: easy_install pip!

[11:07:25.0000] <Hixie_>
gsnedders: see above re sudo. :-)

[11:07:33.0000] <jgraham>
Because part of the contract of the superclass is to be ReadOnly, surely?

[11:07:44.0000] <gsnedders>
Hixie_: (what's pip? a package manager. how do I install it? `easy_install pip`. what's easy_install? a package manager)

[11:07:46.0000] <Osmose1000>
"What's pip?" "A python package manager." "How do I install it?" "easy_install pip" "What's easy_install?" "A python package manager."

[11:07:55.0000] <Osmose1000>
gsnedders++

[11:08:02.0000] <gsnedders>
(Yes, this is A Thing.)

[11:08:09.0000] <jgraham>
Although I guess, since this is actually mutable, it doesn't matter

[11:08:20.0000] <jgraham>
OK, I am mildly convinced

[11:08:32.0000] <Hixie_>
ok let's pretend i tested this test and it's good...

[11:08:59.0000] <Ms2ger>
wfm

[11:09:01.0000] <TabAtkins>
jgraham: Yeah, it's already mutable, just not by *you*.

[11:09:04.0000] <Hixie_>
hm, i guess i haven't put in the right #errors

[11:09:11.0000] <gsnedders>
jgraham: Typically mutation isn't considered part of the contract, as there are (at a high level) no setters

[11:09:14.0000] <TabAtkins>
So it's a *very weak* thing to depend on if you're trying to design by contracts.

[11:09:16.0000] <Hixie_>
not gonna be able to guess what those should be

[11:09:20.0000] <Ms2ger>
Does anyone care about errors?

[11:09:36.0000] <Hixie_>
most of the tests seem to list them

[11:09:54.0000] <jgraham>
Yep

[11:10:12.0000] <jgraham>
So inheriting from DOMRectReadOnly is fine, and ReadOnly is a better name than View

[11:10:41.0000] <Hixie_>
wait hold on. if i'm using virtualenv, why does easy_install want to install as root.

[11:10:52.0000] <Hixie_>
isn't the whole point here that i don't have to do that?

[11:11:31.0000] <jgraham>
That seems wrong

[11:11:52.0000] <jgraham>
OTOH installing pip as root makes more sense. I would do it with your system package manager

[11:12:18.0000] <Hixie_>
i'd rather not screw around with my root on this machine, at least not for something this minor

[11:12:58.0000] <gsnedders>
Hixie_: The only thing you should need installed as root is virtualenv

[11:13:04.0000] <jgraham>
Well then if you activated the virtualenv easy_install pip should work

[11:13:05.0000] <Hixie_>
yeah, i have that

[11:13:09.0000] <jgraham>
Ait

[11:13:13.0000] <jgraham>
*Wait

[11:13:31.0000] <jgraham>
Doesn't venv automatically install pip?

[11:13:35.0000] <Hixie_>
oh, i see.

[11:13:38.0000] <Hixie_>
activation is a per-shell thing.

[11:13:41.0000] <jgraham>
Are you sure that it is activated?

[11:13:47.0000] <jgraham>
YEs

[11:13:51.0000] <Hixie_>
my bad.

[11:14:00.0000] <jgraham>
It is just setting environment variables really

[11:14:13.0000] <Hixie_>
there we go.

[11:14:25.0000] <Hixie_>
yeah it makes sense, i just didn't realise what it was doing.

[11:14:41.0000] <gsnedders>
Mutating PATH and a couple of other things, basically

[11:15:36.0000] <Hixie_>
ok, making progress now.

[11:16:19.0000] <jgraham>
I'm going home, so I will leave you in the capable, if slightly dirty, hands of gsnedders

[11:16:27.0000] <Hixie_>
:-)

[11:16:29.0000] <Hixie_>
thanks for the help

[11:17:28.0000] <Hixie_>
so, how do i run the tests now that it's installed?

[11:17:48.0000] <Hixie_>
"nosetests"?

[11:18:36.0000] <Hixie_>
ok, that worked.

[11:18:45.0000] <gsnedders>
jgraham: …

[11:22:36.0000] <Hixie_>
jesus we have a lot of tests

[11:22:53.0000] <Hixie_>
are these Fs expected?

[11:23:37.0000] <Hixie_>
boo, it didn't tell me what #errors i should put in

[11:24:58.0000] <Domenic_>
I think the issue is `function f(rect) { if (!(rect instanceof DOMRectReadOnly)) { throw new Error("Anyone can modify this, I don't want to give it to untrusted consumers"); } else { untrustedConsumer.useRect(rect); /* can assume rect was not modified */ } }`

[11:26:48.0000] <Domenic_>
or more simply, `if (rect instanceof DOMRectReadOnly) { untrustedConsumer.useRect(rect); /* subsequent code can assume rect was not modified */ }`

[11:27:01.0000] <Hixie_>
gsnedders: so... what should i do with respect to #errors?

[11:27:09.0000] <Hixie_>
does hsivonen have code that tells me what they should be?

[11:27:11.0000] <Hixie_>
:-)

[11:39:29.0000] <Ms2ger>
Hixie_, ignore them, I think

[11:39:37.0000] <Ms2ger>
Hixie_, people who care will fix them up

[11:40:07.0000] <Ms2ger>
MikeSmith, there's been some work on the Blink side at least to get prototypes set up per webidl

[12:22:11.0000] <gsnedders>
Hixie_: As in what strings should they be?

[12:22:19.0000] <gsnedders>
Hixie_: And what failures where?

[12:23:20.0000] <gsnedders>
Hixie_: Up-to-date html5lib git should fail nothing, as should the latest release.

[12:30:48.0000] <Hixie_>
gsnedders: as in what strings, yeah

[12:30:48.0000] <Hixie_>
(the Fs were errors in my test)

[12:31:36.0000] <Hixie_>
gsnedders: so... how do i submit a pull request? i'm guessing that "git clone" does a local clone, which you probably can't get to...

[12:33:59.0000] <Hixie_>
/me follows https://help.github.com/articles/fork-a-repo

[12:52:14.0000] <Hixie_>
why on earth does git diff try to paginate

[12:52:34.0000] <Hixie_>
i'm in an emacs buffer, i'm good for pagination thanks

[12:53:41.0000] <Ms2ger>
You might find that git and UX don't exactly get on well

[12:54:15.0000] <Hixie_>
i'm using emacs, i'm not expecting anything impressive in terms of UX :-P

[12:54:30.0000] <Hixie_>
but seriously, this is unix, who runs a pager by default. sheesh.

[12:54:37.0000] <Hixie_>
(/me learns of  git config --global core.pager cat)

[12:56:13.0000] <Hixie_>
wow, really? |git diff| and |git commit| work on different sets?

[12:56:31.0000] <TabAtkins>
...yes?

[12:57:07.0000] <TabAtkins>
For good reason, so you don't have to put stuff into the staging area just to get a diff, and so you actually have a staging area, respectively.

[12:57:38.0000] <Hixie_>
what's a "staging area" if it's not my working repository?

[12:58:09.0000] <Hixie_>
seems weird to assume that i'd want changes from only some files, but that i'd want all the changes in those files.

[12:58:12.0000] <TabAtkins>
You've got your working files, which are the shit you're actively editing. The staging area, which are the edits you're prepping for commit.  And then the actual repo, which contains the commited stuff.

[12:58:31.0000] <Hixie_>
i don't understand the difference between the first two of those

[12:58:34.0000] <TabAtkins>
That way you can easily commit only some files, or only parts of some files, etc etc.

[12:58:44.0000] <Hixie_>
how do you only commit a part of a file?

[12:58:47.0000] <TabAtkins>
`git add -p`

[12:59:04.0000] <Hixie_>
funku

[12:59:06.0000] <TabAtkins>
It rolls through all the edited chunks of the chosen file, asking whether to stage it or not.

[12:59:06.0000] <Hixie_>
funky, even

[12:59:12.0000] <TabAtkins>
I've been using that a lot today.

[12:59:33.0000] <Domenic_>
yeah it's something you end up not being able to live without

[12:59:33.0000] <TabAtkins>
As I make general improvement to some functions while in the middle of edits to unrelated stuff that I dont' want to commit yet.

[12:59:46.0000] <Domenic_>
does seem weird and useless at first though

[12:59:46.0000] <Hixie_>
with other source control systems, i just create a different tree for each different working environment.

[12:59:51.0000] <Hixie_>
that way i can build each thing separately.

[12:59:56.0000] <Ms2ger>
I could live without git very well :)

[12:59:57.0000] <Hixie_>
otherwise, how do you test it?

[13:00:04.0000] <Ms2ger>
Hixie_, you don't test

[13:00:16.0000] <TabAtkins>
Sure, you can do that with git too, just branch more eagerly. But that's a lot of effort that you don't always want to go to.

[13:00:51.0000] <TabAtkins>
I think you can tell diff to look at the staging area instead of the active files.

[13:00:58.0000] <TabAtkins>
In case that's what you want.

[13:01:06.0000] <Hixie_>
well i have to say the number of times i have more than one edit going on at once is basically never, so it's not clear i'd care either way, but ok

[13:01:11.0000] <Hixie_>
y'all have fun with your -p :-)

[13:01:20.0000] <TabAtkins>
I used to think that too, then I didn't.  Shrug.

[13:01:34.0000] <TabAtkins>
In any case, you can ignore the staging area entirely if you just always do `git commit -a`.

[13:01:59.0000] <TabAtkins>
(Well, almost.  When adding brand new files to the repo, you still have to add them manually.  Or maybe -A does that? I haven't looked recently.)

[13:02:29.0000] <JakeA_>
Hixie_: It's really handy if you've done a chunk of work that, in retrospect, deserves to be documented as separate commits

[13:03:29.0000] <JakeA_>
Eg, if you're adding a new feature & spot a typo in another feature

[13:03:32.0000] <Hixie_>
gsnedders: https://github.com/html5lib/html5lib-tests/pull/23

[13:03:50.0000] <Hixie_>
/me closes all his github windows and nukes his local copies and goes back to hug his subversion

[13:04:37.0000] <JakeA_>
SourceTree is a really nice GUI that does the -p stuff betterer

[13:07:06.0000] <Hixie_>
(for the record, despite my sarcastic whining above, git seems to be no worse than svn or cvs or perforce or any of the other repo systems i've interacted with)

[13:07:47.0000] <Ms2ger>
Oh, it is ;)

[13:07:52.0000] <Hixie_>
(there's something about the problem of version control that just seems to result in weird UX all around)

[13:10:48.0000] <Hixie_>
Ms2ger: it's definitely no worse than perforce.

[13:10:49.0000] <Hixie_>
Ms2ger: or cvs

[13:11:18.0000] <Hixie_>
it being worse than svn or not probably boils down to whether you like distributed repos or not

[13:11:29.0000] <Hixie_>
and i could see that going either way

[13:13:13.0000] <gsnedders>
Hixie_: FY

[13:13:21.0000] <TabAtkins>
Every source control system is absolutely terrible when you initially compare it to what you're used to.

[13:13:23.0000] <gsnedders>
Hixie_: *FYI, the error strings are meaningless, currently.

[13:13:35.0000] <gsnedders>
Hixie_: One line per parse error. That's the syntax. Content is meaningless.

[13:14:10.0000] <Hixie_>
gsnedders: well in the pull request i put up, i put no errors. no idea how many errors there should be, but i expect more than one.

[13:18:49.0000] <gsnedders>
Hixie_: Ideally we'd have position and message assertions, but it's hard to know what to do (what position should a parse error be triggered? probably where the input stream is when the tokenizer/tree builder says parse error

[13:19:06.0000] <Hixie_>
yeah

[13:19:08.0000] <gsnedders>
Hixie_: and what message do we check for to make they've got the right parse error?)

[13:20:23.0000] <gsnedders>
In theory Nolan got all the positions and numbers up to date. His impl is the only one that has used the parse errors in the tests in years, though.

[13:21:49.0000] <gsnedders>
When I update html5lib-python to match the spec I'll do something.

[13:22:26.0000] <Ms2ger>
Hixie_, so it this a test for a change you're making?

[13:22:59.0000] <Hixie_>
no, mostly just an excuse to see if i can add a test.

[13:23:09.0000] <Ms2ger>
Okay

[13:23:11.0000] <Ms2ger>
/me reviews

[13:23:18.0000] <gsnedders>
Hixie_: The format hasn't changed since you last wrote any!

[13:23:35.0000] <Hixie_>
yeah, but the source code repo has changed twice since then :-P

[13:23:48.0000] <gsnedders>
This is true.

[13:23:58.0000] <Ms2ger>
Hixie_, let's see if the spec confuses me as much as the last time I tried this ;)

[13:24:05.0000] <Hixie_>
hehe

[13:24:13.0000] <gsnedders>
/me is currently trying to implement the spec using CSP!

[13:29:27.0000] <Ms2ger>
Hrm

[13:29:38.0000] <Hixie_>
did i screw up?

[13:31:05.0000] <Ms2ger>
In <svg><x>, how does x end up in the svg namespace?

[13:31:20.0000] <Hixie_>
why would it not?

[13:32:01.0000] <Hixie_>
http://www.whatwg.org/specs/web-apps/current-work/#tree-construction

[13:32:10.0000] <gsnedders>
It should

[13:32:11.0000] <Hixie_>
http://whatwg.org/html#tree-construction

[13:32:21.0000] <Hixie_>
"As each token is emitted from the tokenizer"

[13:32:32.0000] <Hixie_>
ends up in "Otherwise"

[13:32:36.0000] <Ms2ger>
Aha

[13:32:36.0000] <Hixie_>
-> foreign content

[13:32:44.0000] <Hixie_>
-> Any other start tag

[13:32:55.0000] <Hixie_>
-> Insert a foreign element for the token, in the same namespace as the adjusted current node.

[13:44:32.0000] <Ms2ger>
jgraham / gsnedders: I've reviewed it, but it doesn't seem like I have access to merge it

[13:45:42.0000] <gsnedders>
Ms2ger: Yes you do.

[13:45:56.0000] <Ms2ger>
... now :)

[13:45:59.0000] <gsnedders>
:)

[13:46:12.0000] <Ms2ger>
Thanks

[13:46:34.0000] <gsnedders>
Anyone else you think who should be added as reviewer?

[13:46:59.0000] <Ms2ger>
Not off hand

[13:47:15.0000] <gsnedders>
Okay. Then I'll leave it as is for now.

[13:48:47.0000] <jgraham>
gsnedders: Not sure how Content Security Policy would help you implement a parser :p

[13:49:58.0000] <gsnedders>
jgraham: CSP is far too overloaded!

[13:50:45.0000] <jgraham>
Don't you mean CPS?

[13:50:58.0000] <jgraham>
If not I have no idea what you do mean?

[13:54:45.0000] <Domenic_>
DOMRECTS!!!

[13:55:01.0000] <Ms2ger>
And on that note, I'm out :)

[14:08:01.0000] <gsnedders>
jgraham: Communicating sequential processes

[14:08:35.0000] <gsnedders>
(Everything I'm doing seems to resolve around CSP at the moment. Under at least five different definitions of CSP.)

[14:30:11.0000] <zcorpan>
ok what should devicePixelRatio return if there's no screen at all?

[14:32:39.0000] <zcorpan>
or if there is a screen but it doesn't have a concept of pixels?

[14:45:10.0000] <TabAtkins>
zcorpan: Every screen has some notion of resolution.

[14:45:19.0000] <TabAtkins>
(and d-p-r is just the inverse of resolution)

[14:45:44.0000] <TabAtkins>
If there's no screen at all, I dunno.

[14:46:45.0000] <zcorpan>
if my screen is a guy painting on a canvas with a brush, what's the resolution? :-)

[14:53:09.0000] <TabAtkins>
I dunno, you'd have to test him.  How tiny can he paint?

[14:53:28.0000] <TabAtkins>
(Approximate resolutions are fine - printers have fuzzy resolutions in some cases too.)

[15:25:56.0000] <annevk>
FWIW, if anyone wants IRCCloud, let me know

[15:51:56.0000] <zcorpan>
i think i'll return 1 for the no-screen case, i guess it's less likely to confuse scripts than returning e.g. 0

[15:58:54.0000] <zcorpan>
there. now bed time


2013-10-18
[20:29:57.0000] <zewt>
man, editing in gmail gets worse and worse (at least in firefox)

[20:30:31.0000] <zewt>
random spaces at the end of paragraphs magically appearing and disappearing

[20:39:10.0000] <rniwa>
rafaelw: yt?

[23:25:06.0000] <Hixie_>
anyone seen ben schwarz recently? the developers.whatwg.org site is rather out of date...

[00:01:17.0000] <MikeSmith>
Hixie_: Ben's around. Best way to reach him is twitter https://twitter.com/benschwarz

[00:20:27.0000] <Ms2ger>
hsivonen, wow, glad I don't use windows

[01:19:35.0000] <Ms2ger>
annevk-cloud, btw, I've been thinking about the suggestion to define the internal state of objects in idl

[01:20:15.0000] <Ms2ger>
I still think it'd be confusing to put it in idl, but it seems pretty useful to put it in a easy-to-read-at-a-glance table

[01:39:15.0000] <annevk>
An easy-to-read-table or a private { } block don't seem so different to me.

[01:39:54.0000] <annevk>
So I thought I outsmarted this visa application queue thing by bringing my laptop and some tethering, but the tethering sucks.

[01:40:24.0000] <annevk>
Also, they're currently servicing 1026 and I'm 1055. This is so sad.

[01:40:26.0000] <SimonSapin>
annevk: I didn’t get any signal in there

[01:43:03.0000] <jgraham>
Yeah, I did not-online work

[01:43:16.0000] <annevk>
What pisses me off the most is that they make it seem like you make an appointment, while it's actually first-come-first-serve.

[01:43:55.0000] <jgraham>
Well probably if you turn up at a time unrelated to your appointment time it's not allowed

[02:05:32.0000] <annevk>
Whoa, tethering sure makes the iPhone hot. Or maybe it's tethering in combination with Spotify...

[02:09:31.0000] <annevk>
Just saw someone who realized that she had 1075 and that it sucked badly (we're just at 1039).

[02:10:06.0000] <annevk>
Meanwhile sending email is a bitch...

[02:13:46.0000] <annevk>
I should've done express, seems they get a separate queue

[02:30:48.0000] <annevk>
Only a couple more numbers...

[03:07:08.0000] <MikeSmith>
http://beta.caniuse.com/ includes info for Firefox for Android and Chrome for Android

[03:07:22.0000] <MikeSmith>
e.g., http://beta.caniuse.com/#feat=mutationobserver

[03:07:39.0000] <MikeSmith>
but only in the "Usage relative" view

[03:08:10.0000] <MikeSmith>
oh and IE Mobile too

[03:16:10.0000] <annevk>
So that failed. My invitation letter was not sufficient at all (the new one I requested hasn't arrived so I thought I'd give it a go anyway)...

[03:20:13.0000] <wilhelm>
annevk: Did you request a visa now, or tried picking up one you already applied for?

[03:20:19.0000] <MikeSmith>
annevk: just forge one

[03:20:27.0000] <annevk>
wilhelm: I went there today

[03:21:08.0000] <MikeSmith>
I can send you the MS Word file they sent me, and you just replace my name with yours

[03:21:58.0000] <wilhelm>
To apply for one or pick it up? They accepted my application, no questions asked, but I haven't picked it up yet. Maybe they'll be difficult when I do. :P

[03:25:26.0000] <annevk>
wilhelm: apply

[03:26:20.0000] <annevk>
MikeSmith: I'll give this email thing a go first

[03:39:55.0000] <smaug____>
what does jQuery("div") do?

[03:46:29.0000] <zcorpan>
TabAtkins: could bikeshed warn about parse errors from html5lib?

[03:51:34.0000] <MikeSmith>
pornel should be named official media assassin for the web platform http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0060.html

[03:54:18.0000] <MikeSmith>
"Complexity doesn't come from DOM nodes, but from statefulness and massive JS API exposing network state."

[03:54:44.0000] <zcorpan>
smaug____: i think basically document.querySelector('div') and wraps that in an object with the jQuery stuff

[03:55:51.0000] <zcorpan>
at least that's what i gather from http://jsfiddle.net/JkB89/

[03:55:55.0000] <jgraham>
Yes

[03:56:35.0000] <jgraham>
jQuery is pretty weird. To support their chaining API, you always get back a jQuery object, but with different internal state

[03:57:15.0000] <jgraham>
Except sometimes

[03:57:27.0000] <jgraham>
(actually maybe even then?)

[03:57:57.0000] <jgraham>
For example if you pass in a function it doesn't act as a selector but gets added to DOMContentLoaded as an event handler

[03:59:58.0000] <barnabywalters>
$(function) is a shortcut for $(document).ready(function) due to frequency of use

[04:00:22.0000] <smaug____>
uh

[04:00:32.0000] <smaug____>
good that I don't need to use jQuery for anything

[04:00:40.0000] <smaug____>
(except profiling this one testcase)

[04:07:51.0000] <darobin>
jgraham: there are cases in which you don't get a chainable value back

[04:07:58.0000] <darobin>
e.g. $el.attr("foo")

[04:08:21.0000] <jgraham>
Right.

[04:08:30.0000] <darobin>
I only find it confusing in boolean cases

[04:08:38.0000] <darobin>
otherwise it is quickly vernacular

[04:09:07.0000] <jgraham>
I'm not sure that "weird" is quite the same as "confusing"

[04:09:20.0000] <barnabywalters>
or if you do item lookups on jQuery objects, e.g. $('div')[0] will return a HTMLDivElement

[04:10:26.0000] <darobin>
jgraham: true, I reckon weird only applies when you're not used to it; confusing stays so afterwards

[04:10:57.0000] <jgraham>
Well I have used it enough to be "used" to it, but it is still weird

[04:11:20.0000] <darobin>
I don't find the jQuery API weird anymore, but I still regularly do if ($("div.bar")) ...

[04:11:25.0000] <darobin>
which is always true

[04:11:53.0000] <jgraham>
I have the feeling it makes it very very easy to write unmaintainable code

[04:12:04.0000] <jgraham>
But it is indeed very very easy

[04:13:56.0000] <zcorpan>
jQuery should hook into document.all when returning falsy objects :-)

[04:14:05.0000] <barnabywalters>
if NodeList objects could be iterated over easily then document.querySelectorAll would be almost as easy to use as $()

[04:14:07.0000] <darobin>
zcorpan: heh

[04:14:47.0000] <zcorpan>
does gecko have document.all in standards mode these days?

[04:15:01.0000] <darobin>
jgraham: my experience is that it doesn't lead to unmaintainable code that easily (certainly not less maintainable than the equivalent DOM...)

[04:15:47.0000] <jgraham>
Er, yeah, well "as good as DOM" isn't that much of a compliment :)

[04:15:59.0000] <annevk>
zcorpan: log: [object HTML document.all class]

[04:16:03.0000] <zcorpan>
seems so

[04:16:49.0000] <annevk>
barnabywalters: once TC39 decides on iterators that'll be the case

[04:16:53.0000] <jgraham>
Blink were talking about removing it, I heard

[04:16:59.0000] <jgraham>
Although talk is cheap

[04:17:06.0000] <annevk>
barnabywalters: though we're introducing document.queryAll() that returns an actual array

[04:17:11.0000] <annevk>
ETA unknown

[04:17:30.0000] <zcorpan>
annevk: weird stringification

[04:17:53.0000] <jgraham>
We were talking about introducing a sane way to construct elements but that seems to have died :(

[04:18:02.0000] <barnabywalters>
annevk: oh that’s great to hear

[04:18:20.0000] <annevk>
zcorpan: yeah seems like a bug

[04:18:43.0000] <annevk>
jgraham: we couldn't figure it out

[04:19:06.0000] <darobin>
/me wonders if all the methods of Node could be on NodeList but act like map()

[04:19:21.0000] <darobin>
you get jQuery right there :)

[04:19:29.0000] <annevk>
darobin: NodeList cannot really change

[04:19:30.0000] <jgraham>
I don't remember all the discussion, but I wonder if we were letting the perfect be the enemy of the good

[04:19:48.0000] <darobin>
jgraham: that never happens

[04:19:54.0000] <annevk>
hah

[04:20:05.0000] <darobin>
annevk: I don't think we'd get away with the massive increase in API surface anyway

[04:20:09.0000] <annevk>
I think we were waiting for html`magic-pony-land`

[04:20:26.0000] <darobin>
fuck your ponies, I want unicorns

[04:20:50.0000] <annevk>
darobin: well yeah, that's what I mean

[04:21:15.0000] <annevk>
darobin: as for unicorns, I'm still plotting about:unicorn

[04:21:36.0000] <darobin>
annevk: that is a component of the Web platform that has long been missing

[04:21:46.0000] <zcorpan>
/me briefly pictures annevk fucking ponies :-(

[04:22:08.0000] <darobin>
and to say that I was thinking about lunch...

[04:22:25.0000] <jgraham>
/me wonders where his factory reset button is

[04:22:31.0000] <annevk>
TMI zcorpan

[04:24:23.0000] <darobin>
I'm pretty sure that from now on whenever I see zcorpan I'll be wondering what he's picturing in his mind's eye

[05:19:09.0000] <MikeSmith>
I wonder if somebody could summarize the state of the "canvas in workers" discussion for me

[06:21:27.0000] <annevk>
MikeSmith: people like their own horse?

[06:24:24.0000] <jgraham>
annevk: We heard all about you and horses already today

[06:24:43.0000] <annevk>
o_O

[06:26:12.0000] <Ms2ger>
tmi

[06:46:18.0000] <SimonSapin>
annevk: do you have tests for URL parsing? (where?)

[06:46:34.0000] <annevk>
SimonSapin: annevk/url

[06:46:46.0000] <annevk>
SimonSapin: I submitted them to web-platform-tests too

[06:46:50.0000] <annevk>
SimonSapin: there's a PR somewhere

[06:47:04.0000] <SimonSapin>
got it, thanks

[06:50:48.0000] <zcorpan>
annevk: https://critic.hoppipolla.co.uk/r/300 is reviewed but has open issues

[06:51:13.0000] <annevk>
oh awesome

[06:51:27.0000] <annevk>
zcorpan: I'll try to address those next week

[06:51:34.0000] <zcorpan>
ok cool

[06:51:55.0000] <annevk>
I don't have email enabled for any GitHub related stuff so that's why I hadn't seen it

[06:52:32.0000] <Ms2ger>
Please enable it for critic ;)

[07:21:14.0000] <SimonSapin>
annevk: should your URL tests have a license?

[07:23:54.0000] <jgraham>
If they are in web-platform-tests they are W3C testsuite/BSD dual licensed

[07:29:09.0000] <Domenic_>
I am tempted to write some JSON on paper, possibly using non-Unicode characters, then ask some mailing lists which spec I should use when I hand the piece of paper to a coworker so that he can unambiguously interpret it.

[07:30:14.0000] <jgraham>
JSON can't be stored on paper, evidently

[07:32:19.0000] <Domenic_>
I am surprised Crockford hasn't made an actual marble monument with JSON on it to prove his point.

[07:33:16.0000] <MikeSmith>
Domenic_: oh man it sounds like that semweb guy must still be still be involved in the discussion

[07:33:27.0000] <MikeSmith>
I thought that had petered out

[07:33:47.0000] <MikeSmith>
is that still going somewhere?

[07:33:52.0000] <MikeSmith>
es-discuss?

[07:33:56.0000] <Domenic_>
Nah full on Ecma + W3C TAG vs. IETF fight going on here from what I can tell. www-tag

[07:36:07.0000] <MikeSmith>
oh I see the discussion has reached a possible Julian-Bjoern vortex

[07:36:26.0000] <Ms2ger>
Voertex?

[07:37:51.0000] <zewt>
oh jeez, gmail can't even get links right

[07:38:08.0000] <zewt>
i click a link in an editor and get the "go to link" popup, i middle click to open in another tab and ... it's not a real link

[07:38:14.0000] <MikeSmith>
Ms2ger: :)

[07:38:19.0000] <zewt>
google using fake links = ww3

[07:41:04.0000] <MikeSmith>
anyway as far as this sitcom goes the scenes where the writers have that Peter F. Patel-Schneider character wander in to say stuff are still the funniest. Or at least the most novel. To me, the stuff they used to have the Bjoern character say was funnier than now.

[08:12:45.0000] <annevk>
SimonSapin: assume CC0

[08:26:47.0000] <SimonSapin>
annevk: all the fields are (non-optional) strings except password which is an optional string, does that look right? https://github.com/annevk/url/blob/master/urltestparser.js#L7

[08:27:05.0000] <SimonSapin>
(optional meaning null is allowed and different from the empty string)

[08:27:29.0000] <annevk>
yeah I think so

[08:57:34.0000] <annevk>
matijs: letterAt()?

[08:57:37.0000] <annevk>
matjas: ^^

[08:57:49.0000] <annevk>
matjas: only superficially works, if you don't think too hard about it :)

[08:59:20.0000] <matjas>
“…but it deals with digits too!!1”

[09:00:24.0000] <annevk>
Oh, I was thinking combining marks. I could have kept it simple I suppose.

[09:05:46.0000] <matjas>
String.prototype.lolwAt()

[09:16:11.0000] <jgraham>
Hmm, someone has scrawlled "I hate AppCache!!! :(" on a napkin and stuck it to our office fridge

[09:16:26.0000] <Ms2ger>
Hah

[10:22:50.0000] <MikeSmith>
jgraham: they misspelled "ate"

[10:23:31.0000] <jgraham>
AppCache is a delicios delicacy?

[10:23:35.0000] <jgraham>
*delicious

[10:26:01.0000] <MikeSmith>
jgraham: I think it's a puzzle. You're supposed to go identify which person ate AppCache, based on their behavior

[10:26:14.0000] <MikeSmith>
btw http://w3c-test.org/web-platform-tests/master/battery-status/battery-interface.html

[10:26:33.0000] <MikeSmith>
did not treat noncallable host object as null expected (object) null but got (function) function "function Node() { [native code] }"

[10:26:50.0000] <MikeSmith>
is this is known problem or a bug in the test?

[10:29:46.0000] <TabAtkins>
zcorpan: Maybe?  What sort of thing are you looking for?

[10:29:53.0000] <TabAtkins>
zcorpan: Also: file bugs in github, please.

[10:32:26.0000] <Ms2ger>
MikeSmith, looks like a test bug

[10:35:37.0000] <Ms2ger>
MikeSmith, yeah, window.Node has [[Call]] defined, so IsCallable(window.Node) is true, so it's just assigned

[10:37:30.0000] <MikeSmith>
Ms2ger: ok

[10:37:36.0000] <MikeSmith>
thanks

[10:37:51.0000] <Ms2ger>
Np

[11:48:32.0000] <Jasper>
Hixie_, Q on ML etiquette: if I have feedback on notifications, should I cross-post to public-notification-notification⊙wo and whatwg⊙wo, or just the former?

[11:49:48.0000] <Ms2ger>
Don't cross post

[11:49:49.0000] <MikeSmith>
Jasper: it's fine to just post to whatwg⊙wo

[11:50:31.0000] <Jasper>
MikeSmith, just whatwg@ ? OK.

[11:57:33.0000] <hober>
obv. we need to make json.spec.whatwg.org; there aren't enough competing json specs.

[11:59:25.0000] <Ms2ger>
Clearly

[12:06:41.0000] <gsnedders>
hober: I thought it was deliberate that they all defined the exact same bytestream as valid

[12:20:22.0000] <Hixie_>
Jasper: what Ms2ger and MikeSmith said.

[12:29:26.0000] <Hixie_>
anyone know what MSPointerDown, MSPointerUp, MSPointerMove, MSPointerOver, and MSPointerOut are?

[12:29:53.0000] <Hixie_>
oh i see, vendor prefix for Pointer Events

[13:01:16.0000] <GPHemsley>
TabAtkins: Is there a character or character sequence that is allowed in a CSS class name but not in an XML element name?

[13:01:37.0000] <GPHemsley>
TabAtkins: Also, is there a way to style multiple elements as if they were contained within a single pseudo-element?

[13:03:21.0000] <SimonSapin>
GPHemsley: yes, CSS accepts anything non-ASCII in identifiers. XML has a bunch of ranges: http://www.w3.org/TR/REC-xml/#NT-NameStartChar

[13:05:49.0000] <SimonSapin>
though if you count escaping, class selectors can be anything

[13:08:39.0000] <Hixie_>
GPHemsley: "1"

[13:08:57.0000] <Hixie_>
GPHemsley: or even " " :-)

[13:09:05.0000] <Hixie_>
as SimonSapin says, pretty much anything

[13:09:21.0000] <GPHemsley>
I was hoping to avoid escaping

[13:10:47.0000] <Hixie_>
.×‬

[13:10:53.0000] <Hixie_>
looks like it should be valid CSS but invalid XML

[13:11:08.0000] <Hixie_>
as in <×‬> should be invalid xml

[13:11:56.0000] <GPHemsley>
I'm converting XML to HTML, with the old XML element names as the class on the HTML element

[13:12:22.0000] <GPHemsley>
and I was hoping to somehow identify elements in non-default namespaces in a such a way that wouldn't clash with default-namespace elements of the same name

[13:13:00.0000] <GPHemsley>
without being too exotic

[13:13:44.0000] <Hixie_>
that sounds like a terrible thing to do, but shouldn't be too hard to come up with a solution :-)

[13:13:50.0000] <Hixie_>
do you need to know the namespace?

[13:14:08.0000] <Hixie_>
or do you need to distinguish namespaces in some way?

[13:14:13.0000] <Hixie_>
you could just use ':' in the class name

[13:14:23.0000] <Hixie_>
or '×‬'

[13:14:34.0000] <Hixie_>
as in, class="foo×‬bar" for <foo:bar/>

[13:14:57.0000] <GPHemsley>
I hope/plan to use the different namespace classes for styling, yeah

[13:15:04.0000] <GPHemsley>
but I suppose that could work

[13:15:27.0000] <GPHemsley>
is there anything I could use that's easier to type than the multiplication sign?

[13:15:36.0000] <GPHemsley>
(and that doesn't require escaping)

[13:15:48.0000] <Hixie_>
i would just use something like class="ns-foo e-bar" or something

[13:16:13.0000] <GPHemsley>
oh

[13:16:14.0000] <GPHemsley>
hmm

[13:16:18.0000] <GPHemsley>
I suppose that could work

[13:16:42.0000] <Hixie_>
subsuming a namespace into another is always a good way to avoid clashes :-)

[13:16:57.0000] <GPHemsley>
heh, yeah

[13:17:29.0000] <GPHemsley>
is - OK as a first character in a class?

[13:18:01.0000] <GPHemsley>
like, what if I did "-bar" and "foo-bar"?

[13:18:12.0000] <Hixie_>
you'd need .\-bar

[13:18:13.0000] <GPHemsley>
or somesuch

[13:18:18.0000] <GPHemsley>
ah, darn

[13:19:03.0000] <Hixie_>
but you can just have the "" namespace turn into "e-bar" and other namespaces turn into "e-foo-bar"

[13:19:23.0000] <Hixie_>
hm, wait

[13:19:23.0000] <GPHemsley>
ah, hmm

[13:19:24.0000] <Hixie_>
that wouldn't work

[13:19:31.0000] <Hixie_>
element names can have hyphens

[13:19:32.0000] <GPHemsley>
oh, right

[13:19:50.0000] <Hixie_>
e--bar and e-foo-bar, assuming you can normalise your namespace prefixes

[13:20:13.0000] <GPHemsley>
what am I trying to avoid?

[13:20:19.0000] <Hixie_>
-

[13:20:22.0000] <GPHemsley>
gotcha

[13:20:24.0000] <GPHemsley>
hmm

[13:20:58.0000] <GPHemsley>
I think having two separate classes would be the easier route

[13:21:10.0000] <Hixie_>
but really if you're doing this you also probably want to avoid <foo:bar xmlns:foo="a"/><bar xmlns="a"/><baz:bar xmlns:baz="a"/> from being three namespaces in the CSS

[13:21:25.0000] <Hixie_>
so you'll probably need some cleverer normalisation of the namespaces

[13:21:47.0000] <Hixie_>
s/in the CSS/in the HTML/

[13:23:26.0000] <GPHemsley>
what's wrong with <span class="ns-foo bar"></span><span class="ns- bar"></span><span class="ns-baz bar"></span> ?

[13:23:40.0000] <GPHemsley>
oh

[13:23:44.0000] <GPHemsley>
make all those e-bar

[13:25:09.0000] <GPHemsley>
what's wrong with <span class="ns-foo e-bar"></span><span class="ns- e-bar"></span><span class="ns-baz e-bar"></span> ?

[13:25:12.0000] <Hixie_>
well it depends what you're doing, but if you're doing anything sane, you've just suffered dataloss.

[13:25:36.0000] <Hixie_>
those three elements in my sample above are {a,bar}{a,bar}{a,bar}

[13:25:56.0000] <Hixie_>
if you serialise them as being in different namespaces, you're violating the Namespaces in XML spec.

[13:26:09.0000] <GPHemsley>
ah, I see

[13:26:22.0000] <Hixie_>
(i guess technically they're {a}bar,{a}bar,{a}bar)

[13:26:28.0000] <GPHemsley>
right

[13:26:44.0000] <GPHemsley>
hmm

[13:27:28.0000] <GPHemsley>
Is xmlns the default namespace?

[13:27:52.0000] <Hixie_>
that question is "not even wrong"

[13:27:55.0000] <Hixie_>
i don't know what you mean by it

[13:28:00.0000] <GPHemsley>
oh

[13:28:19.0000] <Hixie_>
do you mean, does xmlns="" set the default namespace?

[13:28:27.0000] <Hixie_>
as in, xmlns="..."

[13:28:33.0000] <Hixie_>
if so, yes.

[13:28:38.0000] <GPHemsley>
I guess the more basic question is, does the default namespace have a unique identifier? And, if so, what is it?

[13:28:38.0000] <Hixie_>
for elements

[13:29:04.0000] <Hixie_>
a namespace is an opaque string. the default namespace can be set to whatever opaque string you want.

[13:29:22.0000] <Hixie_>
in a namespace-wellformed XML file with no xmlns="" attributes, the namespace of the elements is ""

[13:29:44.0000] <GPHemsley>
oh, perhaps there's a terminology conflict... what is the part before the colon called in <foo:bar>?

[13:29:50.0000] <GPHemsley>
(i.e. "foo")

[13:30:19.0000] <GPHemsley>
<foo:bar xmlns="baz" />

[13:30:42.0000] <GPHemsley>
(or is that even valid?)

[13:30:42.0000] <Hixie_>
prefix.

[13:30:47.0000] <GPHemsley>
prefix, OK

[13:31:01.0000] <GPHemsley>
s/namespace/prefix/ wherever I sounded silly

[13:31:31.0000] <GPHemsley>
though I suppose that doesn't sound any less silly

[13:31:55.0000] <Hixie_>
(my statement above is technically incorrect. in a namespace-wellformed XML file with no xmlns="" attributes, the namespace of the elements is |no namespace|. It's unclear to me what the difference is.)

[13:32:27.0000] <GPHemsley>
null vs. the empty string?

[13:32:40.0000] <Hixie_>
(and setting the default namespace to "" using xmlns="" sets the default namespace to |no namespace|, not the empty string)

[13:32:45.0000] <GPHemsley>
ah

[13:32:52.0000] <Hixie_>
it's not "null" per se, it's just there's-no-namespace.

[13:33:01.0000] <Hixie_>
there's no way to distinguish it from "" as far as i can tell

[13:33:33.0000] <GPHemsley>
nonetheless, this is probably way off-topic from what I was looking to find out :P

[13:34:06.0000] <GPHemsley>
though you've pretty much given my answer for that

[13:34:30.0000] <Hixie_>
(and xmlns:foo="" seems like it's a well-formedness error)

[13:34:47.0000] <GPHemsley>
the subquestion I was looking to answer whether "ns-" was a valid serialization of the default namespace, or if perhaps "ns-xmlns" was better

[13:35:08.0000] <GPHemsley>
(as a CSS class)

[13:35:09.0000] <Hixie_>
what do you mean by "the default namespace"?

[13:35:21.0000] <GPHemsley>
the one represented without a prefix

[13:35:30.0000] <GPHemsley>
<bar>

[13:35:40.0000] <Hixie_>
the lack of a prefix or the presence of a prefix is not semantically relevant.

[13:35:57.0000] <GPHemsley>
hmm, OK

[13:36:01.0000] <Hixie_>
except for elements in no namespace, you can express elements with or without a prefix.

[13:36:25.0000] <Hixie_>
<bar xmlns="a"> and <foo:bar xmlns:foo="a"> are semantically indistinguishable

[13:36:55.0000] <GPHemsley>
any chance we can ignore that fact for simplicity's sake?

[13:37:00.0000] <Hixie_>
(if "a" is the empty string, then the second is non-well-formed)

[13:37:28.0000] <Hixie_>
well you can ignore anything you like, but if what you're doing is attempting to be useful and follow specs, you do so at your peril :-)

[13:37:47.0000] <Hixie_>
i mean it's like saying "can we ignore the fact that <foo/> is an empty element and just treat it like a start tag"

[13:38:05.0000] <GPHemsley>
well, I wasn't heretofore operating as if what I was doing was governed by a spec

[13:38:05.0000] <Hixie_>
or "can we ignore the fact that element names in HTML are case-insensitive"

[13:41:09.0000] <GPHemsley>
oh, wait, I think my XML parser abstracts away from this alright

[13:41:14.0000] <GPHemsley>
s/alright/already/

[13:41:22.0000] <GPHemsley>
which means I can use what prefixes I want

[13:41:44.0000] <GPHemsley>
s/what/whatever/

[13:42:50.0000] <GPHemsley>
i.e. all those things will already be treated as the same

[13:43:07.0000] <GPHemsley>
because I get the information as "{a}bar" not "{foo}bar"

[13:43:13.0000] <Hixie_>
good

[13:44:25.0000] <GPHemsley>
so I can map "a" to "foo" (in "ns-foo")

[13:44:39.0000] <GPHemsley>
the only problem is if something actually is "{foo}bar"

[13:44:58.0000] <GPHemsley>
time for another namespace, I guess

[13:45:12.0000] <GPHemsley>
"ns-p-foo" "ns-ns-foo"

[13:45:31.0000] <GPHemsley>
this is getting too complicated

[13:45:40.0000] <GPHemsley>
"p-foo" and "ns-foo" is probably better

[13:46:04.0000] <GPHemsley>
"p-foo" "ns-foo" "e-foo"

[13:46:28.0000] <GPHemsley>
I can probably figure that all out from here...

[13:46:38.0000] <GPHemsley>
any chance there's an answer to my original second question?

[13:47:11.0000] <Hixie_>
i've (a) lost track of what you're doing and (b) no idea what your second question was, sorry :-)

[13:54:34.0000] <GPHemsley>
is there a way to style multiple elements as if they were contained within a single pseudo-element?

[13:54:43.0000] <GPHemsley>
Hixie_: ^

[14:02:14.0000] <Hixie_>
not to my knowledge

[14:02:19.0000] <Hixie_>
i've been asking for stuff like that since forever

[14:04:19.0000] <Hixie_>
annevk-cloud: you around?

[14:04:28.0000] <Hixie_>
annevk-cloud: Map and Set and structured clones, what's the story

[14:04:34.0000] <Hixie_>
annevk-cloud: should i spec it?

[14:15:45.0000] <SimonSapin>
GPHemsley: not that I know of

[14:26:27.0000] <matijs>
ugh… there I was, thinking that someone finally need me in this here fine channel!

[14:26:39.0000] <matijs>
+annevk-cloud

[14:33:03.0000] <rniwa_>
rafaelw: yt?

[14:33:21.0000] <rniwa_>
aklein: yt?

[14:34:14.0000] <aklein>
ah, over her?

[14:34:21.0000] <aklein>
here

[14:34:28.0000] <aklein>
rniwa_: now I am

[14:34:32.0000] <rniwa_>
aklein: hi

[14:34:41.0000] <rniwa_>
aklein: so does template element provide some way to fill in values?

[14:34:56.0000] <rniwa_>
aklein: we were thinking of a use case where you want to define a template once

[14:35:05.0000] <rniwa_>
aklein: and use it in multiple places

[14:35:22.0000] <rniwa_>
aklein: as I understand it, you do that by template.content.cloneNodes(true)

[14:35:34.0000] <rniwa_>
aklein: but in a lot of use cases, you want to fill in some values inside the DOM

[14:36:21.0000] <aklein>
rniwa_: there's nothing in the element itself that provides a way to fill stuff in; for now that's left to (library) authors

[14:36:23.0000] <rniwa_>
aklein: e.g. <template><address><name>Ryosuke Niwa</name><email>rniwa⊙wo</email></address></template>

[14:36:37.0000] <rniwa_>
aklein: can we add some mechanism to do it declaratively either in template element or custom element?

[14:37:00.0000] <rniwa_>
aklein: it seems like this whole system is less useful if we didn't have any declarative mechanism to do that

[14:37:15.0000] <rniwa_>
aklein: e.g. to give you a more concrete example

[14:37:32.0000] <rniwa_>
aklein: suppose you wanted to add a "like button" on every article you have on your page

[14:37:36.0000] <rniwa_>
aklein: think of techcrunch.com

[14:37:51.0000] <rniwa_>
aklein: then you want to specify some parameters, etc… in your template that includes iframe

[14:37:57.0000] <rafaelw>
rniwa: catching up

[14:38:04.0000] <rniwa_>
aklein: but then the url you pass in to the Facebook needs to be different for each article

[14:38:07.0000] <aklein>
rniwa_: indeed, this was in the original MDV plan; it's since been broken into smaller pieces, but rafaelw has some ideas about the next pieces of this

[14:38:28.0000] <rniwa_>
aklein: it really sucks that people have to write any script at all to do this

[14:38:34.0000] <rafaelw>
Totally agree.

[14:38:59.0000] <rafaelw>
So the current design is that there remaining bits required to do full templating & databinding are

[14:39:01.0000] <rniwa_>
rafaelw, aklein: excelllent.

[14:39:27.0000] <rafaelw>
1) Node.bind: This makes it the concern of nodes to understand what it means to be bound to a value

[14:40:01.0000] <rafaelw>
2) TemplateBinding: This defines the syntax for replacements within a template and explains how templates produce instance of there content with bound values

[14:40:31.0000] <rniwa_>
rafaelw: does 2 require 1?

[14:40:44.0000] <rniwa_>
rafaelw: I think in a lot of use cases, you don't really have to bind a variable

[14:40:53.0000] <rniwa_>
because the value is fixed once an instance is created

[14:41:04.0000] <rafaelw>
3) TemplateBinding defines a delegation mechanism which gives script a chance to custom-interpret the meaning of bindings. This allows what we specify to be fairly simple -- bypassing lots of issues around everyone's favorite syntax & semantics, and allows script to implement more advance functionality.

[14:41:11.0000] <rafaelw>
yes, 2 requires 1.

[14:41:41.0000] <rafaelw>
These designs are currently codified as (seperable) sub-repos with in the Polymer project.

[14:42:13.0000] <rniwa_>
rafaelw: okay

[14:42:13.0000] <rafaelw>
It's still my intent to write specs for these two remaining primitives (Node.bind and TemplateBinding).

[14:42:18.0000] <rniwa_>
rafaelw: do you have pointers for those?

[14:42:28.0000] <rniwa_>
rafaelw: great.

[14:42:36.0000] <rafaelw>
If you're interested in supporting this effort, I'd love it.

[14:42:42.0000] <rniwa_>
rafaelw: presumably, all of this will be spec'ed in WebApps WG?

[14:42:50.0000] <rniwa_>
rafaelw: well, I have to talk with my colleagues

[14:42:51.0000] <rafaelw>
https://github.com/Polymer/NodeBind

[14:42:57.0000] <rniwa_>
rafaelw: but we're definitely interested in this functionality

[14:43:05.0000] <rafaelw>
https://github.com/Polymer/TemplateBinding

[14:43:32.0000] <rafaelw>
That would be my desire. Obviously WebApps has accepted this as a deliverable yet.

[14:43:33.0000] <rniwa_>
rafaelw: because we want to have a declarative form of custom element & auto-template-instantiation with parameterization

[14:43:43.0000] <rafaelw>
Your support would be helpful in that direction =-)

[14:44:02.0000] <rniwa_>
rafaelw: is there any write up of use cases or designs I can read somewhere?

[14:44:15.0000] <rafaelw>
Sounds exciting.

[14:44:23.0000] <rniwa_>
rafaelw: yeah.

[14:44:31.0000] <Domenic_>
rafaelw: I am idly curious why web components is at W3C and not WHATWG

[14:44:39.0000] <rniwa_>
rafaelw: I actually think this stuff is much more important than inheritance, etc… in shadow DOM

[14:44:56.0000] <rniwa_>
rafaelw: because customizing & instantiating a template is something everyone does already

[14:44:58.0000] <Domenic_>
e.g. the problems caused by having <template> be in an outdated W3C draft but also in the WHATWG HTML spec.

[14:45:21.0000] <rafaelw>
Unfortunately, no.  The design is conceptually simple, but I don't have a write-up at the moment.

[14:45:27.0000] <rniwa_>
rafaelw: okay.

[14:45:33.0000] <rniwa_>
rafaelw: it would be great if we could either sync up on this

[14:45:35.0000] <rafaelw>
Perhaps it's worth a white-board discussion =-)

[14:45:42.0000] <rafaelw>
Love to.

[14:45:45.0000] <rniwa_>
rafaelw: or you write write a short summary on what your current design is

[14:45:51.0000] <rniwa_>
if you could* write

[14:46:34.0000] <rafaelw>
domenic: The <template> spec has been integrated into HTML

[14:46:41.0000] <rafaelw>
it's effectively in both whatwg and w3c.

[14:47:10.0000] <rafaelw>
rniwa_; I'll send you an email.

[14:47:14.0000] <rniwa_>
rafaelw: thanks!

[14:47:27.0000] <rniwa_>
rafaelw: it seems like the current template element spec is pretty stable at this point

[14:47:35.0000] <rniwa_>
but we really need that node binding stuff though :/

[14:47:48.0000] <rniwa_>
it's nice not having to worry about adoption agency craziness

[14:48:03.0000] <rniwa_>
but it's less than ideal that you have to manually traverse the DOM and replace values yourself :/

[14:49:23.0000] <rniwa_>
rafaelw, aklein: anyways, thanks for the info!   I might come back to you guys later (not today though) asking more info LOL

[14:50:00.0000] <rafaelw>
awesome.

[14:55:32.0000] <aklein>
rniwa_: cool, thanks for pinging us

[15:04:20.0000] <annevk-cloud>
Hixie_: you could for short term benefit if you want. Long term cloning ought to move to ES

[15:12:48.0000] <abarth>
Does anyone know if ms2ger is still actively editing http://domparsing.spec.whatwg.org/ ?

[15:13:23.0000] <abarth>
some folks have asked for a version of DOMParser#parseFromString that returns a promise for a document rather than a document

[15:13:43.0000] <abarth>
(so that the parsing can happen on a background thread rather than synchronously on the main thread)

[15:13:58.0000] <abarth>
I guess I could email whatwg@ and find out

[15:14:23.0000] <smaug____>
perhaps not actively, but we were discussing about some other stuff in that spec earlier this week, and he will probably fix those issues.....

[15:15:56.0000] <Domenic_>
+1 async parsing

[15:16:01.0000] <smaug____>
I guess "not actively" is because no one has asked changes to that spec until very recently

[15:16:27.0000] <smaug____>
async parsing if there is a use case

[15:16:41.0000] <smaug____>
I guess there is

[15:16:47.0000] <smaug____>
if the string is huge

[15:16:55.0000] <smaug____>
but then, you really want to change the API

[15:17:16.0000] <smaug____>
so that the parser takes some kind of stream or buffers

[15:17:20.0000] <smaug____>
which are parsed

[15:17:44.0000] <abarth>
yeah, there's a bunch of modernization that you could do

[15:17:50.0000] <abarth>
like accepting a Blob or a Stream

[15:18:16.0000] <smaug____>
In Gecko we have parseFromStream, exposed to chrome js only

[15:18:29.0000] <smaug____>
that Stream is internal thing

[15:18:35.0000] <smaug____>
not any web api

[15:20:42.0000] <abarth>
The trickiness with Blobs and Streams it that they're binary

[15:31:46.0000] <esprehn>
abarth: once we fix xhr in Chrome someone should create a polyfill

[15:31:54.0000] <abarth>
yeah

[15:32:16.0000] <abarth>
that will still be slower than just parsing the string directly

[15:32:29.0000] <abarth>
due to memcpying the string a bunch


2013-10-19
[03:18:27.0000] <Ms2ger>
abarth, not really actively, but if there's consensus to add such an API, I can spec it

[06:28:08.0000] <MikeSmith>
Ms2ger: I'm looking at the Gecko implementation of Media Source Extensions, at the SourceBuffer object, and noticing that the prototype doesn't have a audioTracks property nor any of the *Tracks properties

[06:28:25.0000] <Ms2ger>
/me knows nothing :)

[06:29:02.0000] <MikeSmith>
ok

[06:29:21.0000] <MikeSmith>
I see they're commented out in dom/webidl/SourceBuffer.webidl

[06:29:33.0000] <MikeSmith>
but no comment there to say why

[06:29:42.0000] <MikeSmith>
I know the implementation is incomplete

[06:30:14.0000] <MikeSmith>
but I thought it was complete enough to be able to work with a simple demo

[06:30:32.0000] <MikeSmith>
but dunno how it couel work at all without those

[06:31:16.0000] <MikeSmith>
anyway, I'll move on

[12:34:41.0000] <annevk>
Ms2ger: I think we should add getElementById() to ParentNode

[12:35:20.0000] <Ms2ger>
annevk, no strong feelings about that

[12:36:25.0000] <annevk>
same, seems bz likes it, although I wonder how much of that thread is theoretical vs actual needs; hard to judge


2013-10-20
[08:19:33.0000] <zewt>
help, untangling this canvas thread is like pulling a solid wad of christmas lights out of a box after a year

[08:20:31.0000] <zewt>
three separate problems, people trying to solve combinations of two or all three with single APIs (with problems as a result), so it's hard to get people to look at them separately

[08:31:21.0000] <Domenic_>
I keep muting that canvas thread but it keeps coming back...

[08:32:07.0000] <zewt>
i don't even know what "mute" does in gmail, i've tried it and it never has any effect

[08:32:30.0000] <zewt>
it's only available in the inbox though, if you're using gmail i don't know why you'd have that thread in your inbox :P

[08:38:16.0000] <Ms2ger>
Right, that's what Report Spam is for ;)

[08:50:30.0000] <Hixie_>
if it doesn't hit my inbox, i don't read it. :-P

[08:52:08.0000] <zewt>
well you do use a MUA written shortly after conquering fire :P

[08:52:32.0000] <Ms2ger>
You sure it was *after*? :)

[08:53:02.0000] <zewt>
i guess they might have written it, then immediately got an email with instructions for creating fire

[08:54:37.0000] <Hixie_>
actually i use alpine, which post-dates gmail by several years

[09:24:39.0000] <Domenic_>
matjas: that post is really great. it will be the go-to post for Unicode in JS for years, I think. Nicely done.


2013-10-21
[20:22:07.0000] <TabAtkins>
Hixie_: Re: Map and Set and structured clone, spec plz

[20:23:28.0000] <TabAtkins>
GPHemsley: Regarding your pseudo-element question, no.  There's been proposals, but implementors in general don't seem keen to do heavy box-tree rewriting like that.

[23:15:55.0000] <zcorpan>
hmmm, i have no idea how to spec http://lists.w3.org/Archives/Public/www-style/2013Oct/0508.html

[23:16:03.0000] <zcorpan>
presumably the same applies to 'scroll'

[23:18:05.0000] <zcorpan>
several documents can resize or scroll at the same time, too. what should scripts see when you resize a page with a 50% width iframe, and the 'resize' event has fired in the iframe but not on the outer page yet?

[23:18:36.0000] <zcorpan>
i guess the updated state in the iframe and the old state in the outer page?

[00:49:12.0000] <zcorpan>
respec inception? http://darobin.github.io/html-ruby/snapshots/FPWD.html

[01:11:38.0000] <MikeSmith>
zcorpan: that's the special "emphasis" feature that Robin added

[01:12:09.0000] <MikeSmith>
it causes everything to be repeated twice for extra emphasis

[01:23:30.0000] <zcorpan>
nice

[01:23:31.0000] <zcorpan>
nice

[01:33:15.0000] <jgraham>
heh

[01:33:16.0000] <jgraham>
heh

[01:51:44.0000] <zcorpan>
matjas: "the second string uses two separate code points (U+00F1 LATIN SMALL LETTER N WITH TILDE and U+0303 COMBINING TILDE)" you mean U+006E

[01:51:50.0000] <zcorpan>
http://mathiasbynens.be/notes/javascript-unicode

[01:53:14.0000] <zcorpan>
doesn't NFC still have some stuff decomposed?

[01:53:39.0000] <matjas>
zcorpan: ah, copy-paste fail, thanks for the heads up

[01:54:26.0000] <matjas>
zcorpan: it leaves some stuff decomposed (see next example) but afaik never if there is a single-code point alternative

[01:55:11.0000] <JakeA>
Anyone know a url to a large resource/page that has an open CORS header?

[01:55:15.0000] <zcorpan>
right. *continues reading*

[01:55:36.0000] <zcorpan>
JakeA: how large?

[01:55:55.0000] <JakeA>
oh and also gzipped

[01:56:04.0000] <JakeA>
urm, upwards of 1mb?

[01:56:19.0000] <JakeA>
I should just upload one, but I'm being lazy

[01:57:18.0000] <JakeA>
looking for something large enough to trigger multiple xhr progress events on most connections

[01:57:57.0000] <JakeA>
actually, I'll just upload one

[01:58:11.0000] <zcorpan>
JakeA: validate the html spec with http://validator.nu and check 'show source'

[01:58:28.0000] <zcorpan>
dunno if it gzips though

[02:00:52.0000] <JakeA>
zcorpan: It does! Excellent, thanks!

[02:01:20.0000] <JakeA>
The html spec was the first thing I tried but no cors. validator.nu works fine, excellent.

[02:02:28.0000] <zcorpan>
i guess if you validate the html spec very often, hsivonen will be grumpy and block your IP or something :-P

[02:03:11.0000] <JakeA>
it's for a crbug ticket, so hopefully low traffic

[02:16:59.0000] <MikeSmith>
I think http://html5.validator.nu/ handles load better and is more reliable than http://validator.nu

[02:17:07.0000] <MikeSmith>
fwiw

[02:19:30.0000] <MikeSmith>
zcorpan: at this point the stance in your response to porneL about <picture> doesn't seem like a specific stance against <picture> but more of general argument against adding new elements if the same problem could be solved by adding an attribute instead

[02:19:45.0000] <JakeA>
MikeSmith: Cheers. Already closed the ticket so it's ok now.

[02:19:51.0000] <MikeSmith>
JakeA: k

[02:20:37.0000] <zcorpan>
MikeSmith: yeah

[02:20:45.0000] <michou>
hello :)

[02:20:47.0000] <MikeSmith>
zcorpan: so far noboby except you has responded in substance to porneL's proposed revision to the <source>-selection algorithm

[02:20:55.0000] <michou>
any full-screen guru's around? :)

[02:22:23.0000] <zcorpan>
MikeSmith: i noticed that <input list=""> where we introduced elements for an existing feature without losing the reuse

[02:22:36.0000] <zcorpan>
although having to maintain IDs is a drawback

[02:24:15.0000] <yoav>
zcorpan: So you see a possibility where adding <picture> won't involve adding a massive amount of tests?

[02:25:02.0000] <zcorpan>
yoav: see http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0045.html

[02:25:32.0000] <yoav>
zcorpan: So the answer is no :)

[02:27:05.0000] <yoav>
zcorpan: That's what I thought, just wanted to make sure

[02:27:18.0000] <zcorpan>
right. porneL's proposal is a big improvement because it makes testing the selection algorithm itself on par with srcset, but that doesn't change the lack of reuse for all other things

[02:28:42.0000] <zcorpan>
consider if we had done <inputwithdatalist> <option> </inputwithdatalist> instead of <input list=x> <datalist id=x> <option> </datalist> and what the consequence would be for <inputwithdatalist>'s RTL support, for instance

[02:30:27.0000] <zcorpan>
that doesn't mean that reusing an element is always the right answer. it needs to be considered on a case-by-case basis, i think

[02:31:17.0000] <zcorpan>
maybe the existing element is so horrible that it's a good idea to have a clean break

[02:31:33.0000] <yoav>
zcorpan: A crazy thought - Would it be possible to alias picture to img, with the only difference is that picture is not a self closing element?

[02:31:41.0000] <MikeSmith>
I can understand the massive-amount-of-tests argument against <picture> but I have a hard time seeing that as something that should take priority over trying to come up with the least error-prone solution for authors if possible

[02:32:48.0000] <yoav>
That way we get all of img's functionality for free, than add source children

[02:33:18.0000] <MikeSmith>
I would argue that src-N and srcset too just move the massiveness of the problem off onto authors, in terms of the costs it places on how ever many hundreds of thousands of authors making more mistakes with it over how ever many years

[02:33:54.0000] <MikeSmith>
yoav: that aliasing doesn't sound so doable to me but who knows

[02:34:16.0000] <yoav>
MikeSmith: Probably not. As I said - crazy thought

[02:34:41.0000] <Ms2ger>
Eww

[02:34:46.0000] <zcorpan>
yoav: i think there can be code reuse, but most likely it would involve refactoring and refactoring most likely means new regressions

[02:35:04.0000] <zcorpan>
yoav: also, it wouldn't enable rich fallback

[02:35:18.0000] <zcorpan>
yoav: if you want rich fallback, you have to redesign the fallback mechanism

[02:37:39.0000] <zcorpan>
anyway, i don't really mean to shoot <picture> in the head, i just want to point out the costs so we can do a reasonable cost/benefit analysis

[02:37:51.0000] <yoav>
zcorpan: I'm mainly thinking of test reuse, rather than code reuse. Picture's implementation is not that scary.  Rewriting half the platform's tests is.

[02:38:35.0000] <yoav>
zcorpan: I don't understand why aliasing won't enable rich fallback.

[02:39:10.0000] <zcorpan>
yoav: i assumed that if you did a real alias, then the fallback mechanism would use the alt="" attribute

[02:39:19.0000] <yoav>
zcorpan: I 100% agree with the need for a cost/benefit analysis

[02:40:25.0000] <yoav>
zcorpan: At first yes, but maybe it can be extended when the element is not self closing.

[02:40:30.0000] <zcorpan>
yoav: i don't understand what you have in mind for test reuse

[02:42:29.0000] <yoav>
zcorpan: I don't have a clear vision yet (a crazy though, as I said), but if picture is an alias of img, there may not be a need to test non-picture-specific functionality for it

[02:42:55.0000] <yoav>
zcorpan: Not sure that's true, just throwing it out there

[02:43:44.0000] <yoav>
the fact that it's not a real alias, but an extended one, may make it impossible

[02:45:17.0000] <zcorpan>
yoav: ok. i wouldn't trust that the aliasing doesn't have bugs, so my knee-jerk reaction is that we would need to test it anyway. but such testing doesn't need to block shipping the thing

[02:45:35.0000] <jgraham>
/me doesn't quite understand what "alias" means in this discussion

[02:45:41.0000] <MikeSmith>
zcorpan: about https://www.w3.org/Bugs/Public/show_bug.cgi?id=23568 (<ul><script>) I implemented support for that at a long time ago. If it7s getting reported to somebody as an error I think it's probably because it hasn't been pulled to html5.validator.nu and validator.nu yet

[02:45:53.0000] <jgraham>
Is it "alias" in the sense that <image> is an alias of <img>?

[02:46:08.0000] <zcorpan>
jgraham: no

[02:46:09.0000] <yoav>
jgraham: Exactly

[02:46:14.0000] <jgraham>
heh

[02:46:15.0000] <zcorpan>
LOL

[02:46:18.0000] <yoav>
zcorpan: :)

[02:46:33.0000] <yoav>
That's what I was thinking when I said "aliasing"

[02:46:38.0000] <zcorpan>
the html parser creates an "img" element out of an <image> tag

[02:46:53.0000] <zcorpan>
surely you don't want <picture> to *become* img in the DOM?

[02:47:18.0000] <Ms2ger>
Now, how do you serialize an img element with children?

[02:48:26.0000] <zcorpan>
(also, <image> doesn't have children)

[02:49:11.0000] <jgraham>
Even if you just meant that picture implements HTMLImageElement, it seems very messy

[02:49:14.0000] <zcorpan>
MikeSmith: if it's implemented, feel free to close the bug

[02:49:46.0000] <MikeSmith>
ok just did. I'll remind hsivonen to pull

[02:49:52.0000] <yoav>
zcorpan, Ms2ger: Yeah, probably a bad idea

[02:50:43.0000] <yoav>
I was just thinking that if <img> wasn't self-closing, it could have been extended by its children, without the need to add a new element for it

[02:52:29.0000] <zcorpan>
it is, and we can't change it. well, i guess technically we could change it by switching on an attribute, but that's messed up :-)

[03:05:21.0000] <zcorpan>
another thing to keep in mind is that what we're after now is probably a stop-gap measure, the real long-term solution might be something like http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0072.html

[03:07:51.0000] <jgraham>
Pretty sure the long term solution is http://twistedspeedo.com/?p=1012

[03:11:09.0000] <yoav>
zcorpan: I agree file format is the long term solution (not sure about JP2K though), but the gap would be pretty long

[03:18:46.0000] <zcorpan>
btw is anyone working on improving jpeg encoders these days?

[03:19:30.0000] <Ms2ger>
Don't think so

[03:22:17.0000] <annevk>
Kornel seems to be

[03:23:25.0000] <zcorpan>
https://github.com/pornel/jpeg-compressor ?

[03:31:08.0000] <yoav>
zcorpan: Yeah

[03:31:35.0000] <zcorpan>
nice. pornel++

[03:42:06.0000] <MikeSmith>
haha 'Codename "Nether Poppleton"'

[03:42:25.0000] <MikeSmith>
pornel rocks mightily

[03:42:34.0000] <MikeSmith>
the Web needs more pornel

[03:59:18.0000] <annevk>
matjas: I recommend reading up on grapheme clusters if you haven't already

[03:59:36.0000] <annevk>
matjas: http://www.unicode.org/reports/tr29/

[03:59:55.0000] <annevk>
matjas: if you want proper Unicode support in JavaScript, that's probably where we should be looking for inspiration

[04:17:18.0000] <jgraham>
odinho: Holy fast review batman :)

[04:34:18.0000] <SimonSapin>
matjas: http://mathiasbynens.be/notes/javascript-unicode "U+00F1 LATIN SMALL LETTER N WITH TILDE and U+0303 COMBINING TILDE" seems wrong

[04:35:28.0000] <SimonSapin>
matjas: the first should be U+004E

[04:36:09.0000] <Ms2ger>
SimonSapin, not 6E?

[04:36:15.0000] <Ms2ger>
http://krijnhoetmer.nl/irc-logs/whatwg/20131021#l-149

[04:37:26.0000] <SimonSapin>
Ms2ger: right

[05:59:08.0000] <zcorpan>
hmm, fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23566 means i have to talk about what the `options` should be when there are no arguments

[06:06:46.0000] <zcorpan>
would be nicer with webidl having [TreatUndefinedAs=false]

[06:06:59.0000] <zcorpan>
heycam: ^

[06:07:36.0000] <heycam>
zcorpan, can you not do that with an optional argument default value?

[06:07:45.0000] <heycam>
or is it not optional

[06:07:51.0000] <zcorpan>
default value is true

[06:08:13.0000] <heycam>
but explicit undefined needs to be false?

[06:08:18.0000] <zcorpan>
yeah

[06:08:48.0000] <heycam>
tbh I'd say "use any and define it in prose" :)

[06:09:22.0000] <heycam>
like anne [TreatUndefinedAs] is kind of ugly

[06:09:30.0000] <heycam>
I wonder if any current uses of it can be replaced by optional arguments with default values

[06:09:37.0000] <heycam>
s/anne/anne I think/

[06:09:52.0000] <zcorpan>
i agree it's ugly

[06:10:01.0000] <zcorpan>
but what i have now is also ugly

[06:10:12.0000] <zcorpan>
 <li><p>If invoked with no arguments, let <var>top</var> be true and let <var>options</var> be a <code>ScrollOptions</code> dictionary with its members not

[06:10:12.0000] <zcorpan>
 present or present with the default value, as appropriate.

[06:10:43.0000] <zcorpan>
how does any+prose help?

[06:11:06.0000] <heycam>
/me looks at the spec to see the actual signature

[06:11:31.0000] <zcorpan>
i haven't committed yet

[06:12:02.0000] <heycam>
the current signature

[06:12:15.0000] <zcorpan>
  void scrollIntoView();

[06:12:15.0000] <zcorpan>
  void scrollIntoView(boolean top, optional ScrollOptions options);

[06:13:01.0000] <heycam>
so you add the no-arg version, so that it can have a different value for 'top'

[06:13:04.0000] <heycam>
effectively

[06:13:19.0000] <zcorpan>
right

[06:13:26.0000] <heycam>
but then when you describe in prose how to handle a no-arg invocation, you need to talk about a ScrollOptions that you make up

[06:13:26.0000] <heycam>
ok

[06:13:56.0000] <heycam>
what about just having:

[06:14:05.0000] <heycam>
void scrollIntoView(optional boolean top, optional ScrollOptions options);

[06:14:13.0000] <heycam>
and describe what to do when top is missing?

[06:14:24.0000] <heycam>
probably results in overall less prose

[06:14:41.0000] <zcorpan>
that means explicit undefined is the same as missing

[06:14:58.0000] <heycam>
ah

[06:14:59.0000] <heycam>
then you use any

[06:15:01.0000] <heycam>
I guess :)

[06:15:08.0000] <heycam>
otherwise, no good suggestions atm

[06:15:53.0000] <zcorpan>
i don't understand the any suggestion

[06:17:54.0000] <heycam>
you make top 'any', then write in prose how to handle undefined, and in all other cases invoke ToBoolean

[06:18:28.0000] <heycam>
still, it's probably nicer to keep it as boolean

[06:18:48.0000] <heycam>
makes the IDL more informative, even if you do need to mess around with the ScrollOptions thing in prose

[06:21:46.0000] <zcorpan>
any and optional?

[06:22:36.0000] <heycam>
ah yeah

[06:23:43.0000] <zcorpan>
anyway yeah i'll keep it as boolean

[06:48:54.0000] <annevk>
whoa, heycam is in Europe again

[06:50:24.0000] <annevk>
zcorpan: can't you make omitted also false?

[06:51:19.0000] <annevk>
zcorpan: seems better if undefined and omitted keep the same semantics unless it's a really special situation

[06:54:08.0000] <heycam>
annevk, enjoying the paris office this week

[06:54:22.0000] <annevk>
was thinking you would

[06:54:31.0000] <annevk>
what has IDL to do with rendering again? ;p

[06:55:11.0000] <zcorpan>
annevk: changing how scrollIntoView() works seems to have a much bigger impact than changing how scrollIntoView(undefined) works

[06:55:33.0000] <annevk>
zcorpan: doesn't scrollIntoView() default to false in WebKit atm?

[06:55:37.0000] <heycam>
/me hides

[06:56:31.0000] <darobin>
that's all a lie annevk

[06:56:39.0000] <darobin>
if heycam were in Paris, he'd wave or something, you know

[06:57:09.0000] <zcorpan>
annevk: no

[06:57:24.0000] <zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2572

[06:57:54.0000] <zcorpan>
undefined: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2573

[06:58:09.0000] <heycam>
/me waves, and assumes darobin must have hacked into all the CC cameras in the city to be able to see it

[06:59:13.0000] <darobin>
/me waves at the computer, assumes some form of transmission

[07:00:21.0000] <annevk>
fucking merge conflicts

[07:00:31.0000] <annevk>
/me blames Ms2ger

[07:41:47.0000] <SimonSapin>
darobin: http://lists.w3.org/Archives/Public/spec-prod/2013OctDec/0029.html +1

[07:41:58.0000] <SimonSapin>
darobin: how do we start moving towards this?

[07:42:19.0000] <darobin>
SimonSapin: a small first step is to say +1 on the list too so that it is seen to be supported

[07:42:52.0000] <darobin>
beyond that, I want to confer with people who work on publication inside the Team to see if we can get this off the ground relatively quickly

[07:43:06.0000] <SimonSapin>
cool

[07:43:11.0000] <darobin>
it in fact does not really require any change to the Process as far as I can tell

[07:43:28.0000] <darobin>
most importantly, it matches the needs of the patent policy, which is a nightmare to change

[07:43:49.0000] <darobin>
glad you like it :)

[07:51:39.0000] <jgraham>
Romantic interests? Since we don't have any good way to tell who any given person might be *interested* in romantically, that suggests we have to spam the entire planet. Maybe it would just be easier to get non-conformance to pubrules brought up at the UN?

[07:52:22.0000] <darobin>
no, we just place editors under a requirement to disclose romantic interests

[07:53:00.0000] <jgraham>
Hmm, suddenly I thik we won't have any editors under your plan :)

[07:53:18.0000] <darobin>
then anyone they sleep with not previously registered gets informed that, clearly, they were just a one-night-fling due to excess alcohol consumption

[07:53:30.0000] <darobin>
I don't mind disclosing my romantic interest :)

[07:54:03.0000] <jgraham>
Oh, if "interest" just means "have slept with", that makes things easier

[07:54:17.0000] <darobin>
we're going to need a standard for that

[07:54:33.0000] <jgraham>
If "interest" means "are interested in", it could cause all sorts of strife

[07:54:48.0000] <darobin>
precisely

[07:54:52.0000] <darobin>
wait

[07:54:59.0000] <darobin>
standards aren't about creating strife?

[07:55:15.0000] <jgraham>
I think that's just a secondary effect

[07:55:48.0000] <darobin>
I have a lot of a empirical evidence showing that it's the primary effect :)

[07:55:50.0000] <jgraham>
AIUI standards are mostly about propping up Hollywood

[07:56:18.0000] <darobin>
and that is different from deliberately creating strife in which ways exactly?

[07:57:36.0000] <jgraham>
Well I guess the point of propping up business models is to make money for people in those businesses. This leads to societial inequality between those who have money and those who don't. Which causes strife and, if left unchecked, eventual revolution

[07:57:53.0000] <jgraham>
So standards are all about revolution and that's why there's so many French people involved

[08:04:23.0000] <darobin>
heh

[08:45:20.0000] <annevk>
kinda wonderful how much text from XMLHttpRequest is now obsolete

[08:45:32.0000] <annevk>
kinda scary how much will regress here

[08:56:49.0000] <Hixie_>
annevk: Map and Set structured clone -- should I do it, or is JS gonna have a definition soon?

[08:57:34.0000] <annevk>
Hixie_: since it isn't much effort, might as well do it in HTML for now

[08:57:49.0000] <Hixie_>
k

[08:58:12.0000] <annevk>
Hixie_: structured clones are not going to make it into ES6 I think, multiple globals aren't either by the looks of it :/

[08:58:45.0000] <Hixie_>
what does "ES6" mean? 2013?

[08:59:13.0000] <annevk>
"stable draft" end-of-2013, "standard" end-of-2014

[08:59:38.0000] <Hixie_>
wow, no new JS features between end of 2013 and end of 2014?

[09:00:21.0000] <annevk>
Hixie_: well since we have ES6 features now, we'll have ES7 features such as Object.observe() sooner than ES7

[09:00:40.0000] <Hixie_>
wait, Object.observe() isn't "stable"?

[09:00:51.0000] <Hixie_>
i thought people were implementing that already

[09:00:56.0000] <annevk>
Hixie_: in addition, TC39 decided to move to a more iterative process for individual features so they can be considered done before the overall spec is "done"

[09:01:06.0000] <annevk>
Hixie_: yeah, but not shipping

[09:01:12.0000] <Hixie_>
why not shipping?

[09:01:14.0000] <Hixie_>
only one more step to a living standard...

[09:01:41.0000] <annevk>
Hixie_: so yeah, the new iterative thing will allow shipping by declaring consensus sooner than "standard"

[09:02:16.0000] <annevk>
Hixie_: and indeed, it's more or less the same, with some kind of committee approval steps in between, which seem awkward, but given the way JavaScript is developed I don't immediately see a better way

[09:02:26.0000] <Hixie_>
the difference between "consensus" and "standard" is what again? :-)

[09:02:49.0000] <Hixie_>
on another note, what's that CSS property that defines how replaced content gets sized

[09:02:53.0000] <annevk>
Hixie_: "standard" is what's Ecma-approved

[09:02:54.0000] <Hixie_>
i thought it was image-fit, but seems not

[09:02:58.0000] <annevk>
Hixie_: "consensus" is TC39-approved

[09:03:11.0000] <Hixie_>
annevk: what's the word they use for "browser shipped interoperably"?

[09:03:26.0000] <annevk>
Hixie_: "legacy" :p

[09:03:30.0000] <Hixie_>
(ah, object-fit)

[09:03:52.0000] <annevk>
(I'm not sure. They consider it de facto and something they need to define without breaking things.)

[09:03:53.0000] <Hixie_>
annevk: ok so when will structured clone in JS be "legacy"? :-)

[09:04:59.0000] <annevk>
Ah, so the other thing is that they like the platform <-> language separation a bit too much. So saying workers and such are part of their world can be a hard sell depending on who you talk to. Though most implementers people are on board.

[09:05:15.0000] <jgraham>
Hixie_: Once browsers ship it interoperably :)

[09:05:18.0000] <annevk>
implementer people*

[09:05:37.0000] <Hixie_>
jgraham: well, i meant when will they have a spec that describes reality that i can defer to

[09:05:47.0000] <Hixie_>
but it sounds like "not soon", so, nevermind

[09:06:13.0000] <jgraham>
There are two states a) future things that don't ship yet and b) distasteful legacy

[09:06:18.0000] <Hixie_>
/me realises he still hasn't made HTML properly integrate with css-images and the "CSS⇋Object Negotiation" protocol

[09:06:27.0000] <Hixie_>
jgraham: sounds right

[09:07:45.0000] <Hixie_>
hm, there's no default default object size, huh

[09:09:07.0000] <Hixie_>
ok, browsers are off in lala land again.

[09:09:21.0000] <Hixie_>
default size for svg seems to be "100% of container"

[09:11:03.0000] <Hixie_>
TabAtkins: ping (how do i integrate with css-images for <img> containing svg without intrinsic dimensions but with an intrinsic ratio? it looks like i need to give you some sort of "fit the containing block width" information as the default object size for <img>, or something)

[09:11:53.0000] <gsnedders>
So what's the best way to deal with a bug that makes Fennac unusable for me on my tablet, but I can't quite reproducably hit it?

[09:13:22.0000] <Hixie_>
gsnedders: keep trying to reproduce it? :-)

[09:13:37.0000] <Hixie_>
this on android?

[09:13:39.0000] <gsnedders>
Yeah.

[09:13:51.0000] <Hixie_>
take a debug log when it happens, maybe that might help

[09:13:52.0000] <gsnedders>
Often doesn't respond to input for several seconds.

[09:14:31.0000] <Hixie_>
TabAtkins: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23581

[09:23:02.0000] <Domenic_>
Hixie_: annevk: one thing to keep in mind is that there's a difference between "consensus on a strawman" and "we nailed down all the details in spec language." Part of the proposed ES7 process is to get formal spec text earlier to get all the interoperability edge cases nailed out.

[09:23:54.0000] <Hixie_>
you can't nail down all the details until after at least one, probably several, implementations have shipped.

[09:24:28.0000] <Hixie_>
but certainly formal text should be early in the process

[09:24:47.0000] <Hixie_>
because trying to describe something formally is step one in trying to figure out if the proposal makes any sense

[09:27:26.0000] <dglazkov>
good morning, Whatwg!

[09:30:47.0000] <Domenic_>
Does anyone know why Chrome now returns HTMLElement for document.createElement('image')? Seems weird to intentionally diverge JS API and the HTML parser? http://src.chromium.org/viewvc/blink?view=revision&revision=159920

[09:31:09.0000] <Domenic_>
I guess there are already divergences (e.g. createElement throwing for certain element names), but, what motivated this?

[09:31:35.0000] <Hixie_>
"now"? didn't it always/

[09:31:36.0000] <Hixie_>
?

[09:31:58.0000] <Hixie_>
it should be HTMLUnknownElement, I _think_

[09:32:10.0000] <Hixie_>
for 'image' in createElement

[09:32:12.0000] <Hixie_>
per the spec

[09:32:59.0000] <annevk>
Domenic_: the parser creates an element for a namespace, name, and a set of attributes

[09:33:33.0000] <annevk>
Domenic_: having the special case in "creates an element" seems weird

[09:34:19.0000] <Domenic_>
annevk: not sure I understand... I am trying to see why the parser doesn't just do document.createElementNS(parsedName, parsedNS)

[09:35:51.0000] <annevk>
Domenic_: well for one, those are distinct

[09:36:06.0000] <annevk>
Domenic_: but e.g. otherwise the pre-scanner would miss out on this alias

[09:37:21.0000] <Domenic_>
hmm this seems to involve more things than i understand. i think i will attempt to retreat from this line of questioning and come back later when I learn more.

[09:37:33.0000] <Hixie_>
Domenic_: it does, except for <image> and <isindex> and a few other weird cases

[09:38:29.0000] <Domenic_>
Hixie_: <isindex> is weird, I can understand weird stuff being necessary. What's the deal with <image>?

[09:38:52.0000] <Hixie_>
<image> has to be treated like <img> because 5 years ago, 0.2% of pages used <image> and expected it to work like <img>.

[09:39:10.0000] <Domenic_>
right, but, why is the parser different from createElement?

[09:39:21.0000] <Domenic_>
Hmm maybe createElement is trying to be sane but the parser can't afford to?

[09:39:34.0000] <Hixie_>
right

[09:39:40.0000] <Domenic_>
Got it, thanks

[09:39:42.0000] <Hixie_>
we try to limit the scope of quirks

[09:41:17.0000] <annevk>
createElement("x*") -> throws

[09:41:27.0000] <annevk>
<x*> -> works

[09:41:51.0000] <Domenic_>
right, is that the same principle, that createElement can afford to enforce rules, but the parser cannot?

[09:43:38.0000] <annevk>
Hah, I don't really know who designed these APIs, but I doubt much of principles were involved we would use today.

[09:43:49.0000] <Domenic_>
fair :P

[09:44:04.0000] <Domenic_>
my interest is that in jsdom we weren't able to use the actual DOM elements to build the DOM tree because of situations like this

[09:44:15.0000] <Domenic_>
we needed to provide a "privileged" createElement that the parser could use

[09:44:19.0000] <Domenic_>
which was kind of sad

[09:44:39.0000] <annevk>
Restrictions in createElement() are influenced by XML. And in a weird way. createElement() follows Name whereas createElementNS() follows NCName. Although both create namespaced elements today...

[09:45:44.0000] <Domenic_>
Yeah, I remember following those links... fun times.

[09:45:58.0000] <jgraham>
Actually the parser can never create an element named "image" in the HTML namespace, so that isn't an example of "createElement can't, parser can"

[09:48:16.0000] <annevk>
Even in <template>!

[09:49:07.0000] <Domenic_>
jgraham: good point. I confused myself, and was trying to think of createElement('tagname') as parseHTML('<tagname>'). But it's better to think of parseHTML as using createElement, modulo XML-influenced restrictions.

[09:50:35.0000] <annevk>
The parser cannot really use createElement() directly anyway. It wants something else for saner mutation records.

[09:51:01.0000] <Domenic_>
ah interesting

[09:51:04.0000] <annevk>
Not entirely sure what, prolly something close to what browsers have internally, although that might not be ideal either.

[09:52:10.0000] <annevk>
And I believe currently some stuff in the HTML specification depends on elements being created having their relevant attributes set straight away.

[09:52:17.0000] <annevk>
So createElement() does not work for that either.

[09:55:52.0000] <Hixie_>
yup

[09:56:13.0000] <Hixie_>
Domenic_: all these features were designed by different people with different priorities and philosophies

[09:56:44.0000] <Hixie_>
some of which were things like "my boss is breathing down my neck about this other property needing this feature before friday so he can go golfing"

[09:56:57.0000] <Hixie_>
(property as in, web site owned by the vendor's company)

[10:18:47.0000] <TabAtkins>
Hixie_: Just pass the ratio as the intrinsic dimensions.  (The dimensions are width/height/ratio.)  And then, yes, set up the default image size as the size of the <img>.

[10:19:07.0000] <Hixie_>
"set up the default image size as the size of the <img>"?

[10:19:12.0000] <Hixie_>
how do you mean?

[10:21:34.0000] <TabAtkins>
When you're invoking the sizing algorithm, say that the default image size is the dimensions of the <img>.

[10:26:44.0000] <Hixie_>
the img's dimensions are what i'm trying to figure out

[10:26:46.0000] <Hixie_>
i don't follow

[10:26:57.0000] <Hixie_>
also i don't think i call the algorithm, i think that's css layout that does that

[10:38:10.0000] <annevk>
TabAtkins: it seems all HTML can give here is the height and width attributes, which already map to CSS

[10:38:49.0000] <annevk>
And I guess if HTML does the image decoder negotiation it could give information from that too...

[10:47:03.0000] <TabAtkins>
annevk: Ah, right, yeah.

[10:51:00.0000] <miketaylr>
back

[11:10:01.0000] <TabAtkins>
Hixie_: Ah, if you're trying to size the <img> itself, then CSS2.1 describes how to do it.  Alan just invoked that algorithm yesterday, let me go look up the incantation.

[11:18:57.0000] <zcorpan_>
hmm, the trackpad on my mac just went crazy. it's super sensitive and inverted in both directions

[11:24:20.0000] <gsnedders>
Hmm, so warranty replacement for my rucksack will only ship to US. Is there going to be any sane way to get that here without it costing more than the bag is worth…

[11:24:40.0000] <gsnedders>
Probably best bet is just to take a slightly large suitcase when I next go and take it that way…

[11:39:01.0000] <zcorpan_>
ah, trackpad back to normal. phew.

[12:00:49.0000] <zcorpan_>
MikeSmith: does  http://critic.hoppipolla.co.uk/r/351 support `static interface ...` ?

[12:01:52.0000] <jgraham>
zcorpan_: OK, the jgraham/python_review_2 branch now has all the track tests up to 010.html pass in opera

[12:02:20.0000] <zcorpan_>
jgraham: great

[12:14:22.0000] <zcorpan_>
MikeSmith: hmm, nevermind, seems like there's no static interface thing. confused it with something else

[12:15:26.0000] <zcorpan_>
[Unforgeable]

[12:16:18.0000] <Ms2ger>
jgraham, I'll try to look at the review a bit tomorrow

[12:19:04.0000] <jgraham>
Ms2ger: Awesome, thanks

[12:22:23.0000] <astearns>
TabAtkins: is this the incantation you're looking for? http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width

[12:29:33.0000] <Ms2ger>
2.1? Probably not

[12:31:42.0000] <zcorpan_>
jgraham: when i submit changes in critic, is there a way to make it go back to the review instead of going to the default page?

[12:32:57.0000] <zcorpan_>
0.02 % done, that's encouraging :-)

[12:58:37.0000] <TabAtkins>
astearns: Yeah, that's it.

[13:08:59.0000] <zcorpan>
jgraham: was there some change other than https://github.com/w3c/web-platform-tests/commit/b1486aa82b4174df577bb00f1796fe4a5bc5bffc ?

[13:09:28.0000] <zcorpan>
(and the comma fixup)

[13:10:10.0000] <jgraham>
zcorpan: I thpught it did go back to the review, but I might have imagined that

[13:10:20.0000] <jgraham>
In any case the answer is generically "ask jl"

[13:11:24.0000] <jgraham>
zcorpan: Those and replaicing cors-tester.php with cors-tester.py (and all the substitutions that implies)

[13:12:40.0000] <zcorpan>
jgraham: yeah i meant between the state of cors-tester.py last i looked at it and the latest fixup commit

[13:16:29.0000] <jgraham>
Right, those are the only changes in that case

[13:17:58.0000] <zcorpan>
ok

[13:41:13.0000] <Hixie_>
TabAtkins: that ends with "then the used value of 'width' is undefined in CSS 2.1." for the case i care about :-P

[13:43:18.0000] <Hixie_>
TabAtkins: isn't this what css-images is defining?

[13:44:14.0000] <zcorpan>
jgraham: looks like i get the same results as on t now. excellent!

[13:50:04.0000] <Hixie_>
bugzilla needs a severity field value that's like "enhancement" but means "removal of feature"

[13:51:08.0000] <TabAtkins>
Hixie_: Yaaaayyy

[13:51:36.0000] <jgraham>
zcorpan: Oh!

[13:51:37.0000] <TabAtkins>
Hixie_: Man, I dunno. fantasai convinced me that the 2.1 handling of replaced elements wasn't actually quite compatible with the Image Sizing Algorithm, and making them compatible wouldn't be worth it.

[13:52:31.0000] <TabAtkins>
But I've paged that argument out of my head for a while.

[13:53:11.0000] <Hixie_>
TabAtkins: someone filed a bug on me saying this case wasn't well-defined... should I reasssign it to you for now? (I'm happy to have it assigned to me, I just don't know what I should say to fix it.)

[13:54:32.0000] <jgraham>
Hixie_: BTW, how paged in do you have the session history stuff? It is being designed for servo at the moment and bholley was threatening to grill you on it

[13:54:43.0000] <jgraham>
So take this as advance warning ;)

[13:54:56.0000] <Hixie_>
hehe

[13:55:06.0000] <Hixie_>
not particularly paged in, but it's not as hard to page in as the parser :-)

[13:55:45.0000] <jgraham>
I find it much harder :)

[13:59:32.0000] <TabAtkins>
Yeah, assign it to me

[14:00:14.0000] <Hixie_>
k

[14:08:28.0000] <Hixie_>
TabAtkins: done - https://www.w3.org/Bugs/Public/show_bug.cgi?id=23581

[14:14:49.0000] <zcorpan>
jgraham: no support for wss: ?

[14:35:58.0000] <zcorpan>
wow https://www.w3.org/Bugs/Public/show_bug.cgi?id=23587

[14:36:42.0000] <zcorpan>
it took a few years, but the planets did line up

[14:38:42.0000] <jgraham>
zcorpan: *s is hard because certificates

[14:39:13.0000] <zcorpan>
jgraham: but https works?

[14:39:17.0000] <jgraham>
no

[14:39:20.0000] <zcorpan>
oh

[14:39:22.0000] <zcorpan>
ok

[14:40:09.0000] <jgraham>
For Mozilla infrastructure we will probably install a CA fir the duration of the tests (that's how Mochitest works)

[14:40:36.0000] <jgraham>
Opera/Google/Microsoft/Apple could do something similar on their test infrastructure

[14:40:57.0000] <jgraham>
For people running the tests at home I'm not sure what we will do

[14:41:55.0000] <Hixie_>
abarth: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701

[14:42:11.0000] <zcorpan>
jgraham: we can put in job openings

[14:43:35.0000] <Hixie_>
zcorpan: got any suggestions for that <script> bug?

[14:43:47.0000] <jgraham>
Well "at home" in this case really includes any situation where you don't run a browser-specific script to launch the tests

[14:46:10.0000] <zcorpan>
Hixie_: i think the recommendation should be to escape the < in <!-- and <script

[14:46:38.0000] <Hixie_>
yeah that was my conclusion too

[14:46:41.0000] <Hixie_>
or the ! and the s

[14:46:49.0000] <Hixie_>
as in <\!-- and <\script

[14:46:56.0000] <zcorpan>
right

[14:47:14.0000] <zcorpan>
and </script of course

[14:47:21.0000] <Hixie_>
yeah, always <\/script

[14:47:55.0000] <Hixie_>
oh course the _real_ answer is "don't do string substitution into your script"

[14:48:01.0000] <Hixie_>
when will people learn

[14:51:29.0000] <zcorpan>
Hixie_: also say that authors can ignore the script content model restrictions and instead avoid wrapping <!-- --> and properly escaping

[14:52:36.0000] <zcorpan>
since the restrictions are impossible to understand

[14:53:06.0000] <Hixie_>
oh that's an idea. Just have in that section some text that says that the easiest way to avoid this is to just escape all <!-- and <script> bits?

[14:54:45.0000] <zcorpan>
yeah

[14:55:20.0000] <zcorpan>
wonder if it's a good idea to make validators complain about <!-- always

[14:56:11.0000] <zcorpan>
it's pretty common, but OTOH it's a very legacy practice, and it's not without issues

[14:56:31.0000] <Hixie_>
i'd be fine with doing so, but hsivonen and MikeSmith are reluctant to warn on "harmless" stuff

[14:56:40.0000] <Hixie_>
which i can understand

[14:56:50.0000] <Hixie_>
since it makes the validator less likely to be used, arguably

[14:58:11.0000] <zcorpan>
yeah

[14:58:37.0000] <zcorpan>
i guess it's harmless until you enter double escaped state

[15:00:07.0000] <zcorpan>
hsivonen: MikeSmith: WDYT?

[15:00:13.0000] <zcorpan>
/me -> sleep

[15:18:50.0000] <Hixie_>
sweet kittens, i got a bunch of parse errors trying to write the parser section on avoiding parser errors.

[15:29:54.0000] <annevk-cloud>
oh man that security bug

[15:30:19.0000] <annevk-cloud>
one day

[15:30:50.0000] <Hixie_>
you think that's bad

[15:30:52.0000] <Hixie_>
try this one: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23366


2013-10-22
[20:08:29.0000] <AndroUser>
Hi

[22:34:58.0000] <MikeSmith>
Hixie_: offhand it doesn't seem to me like most validator users would be happier if we always emitted messages about <!--

[00:09:30.0000] <MikeSmith>
Hixie_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23587 is one of those bugs that really should have been filed against the WHATWG spec

[00:10:15.0000] <MikeSmith>
but I'm sure I'll get complaints if I move it. or plh will get a complaint about me moving it

[00:11:15.0000] <MikeSmith>
I hope we can get back to having one place for people to file HTML spec bugs, and then we can triage them however from there

[01:27:36.0000] <zcorpan>
hmm, multipage version is behind? i don't see the note in #restrictions-for-contents-of-script-elements

[01:30:52.0000] <zcorpan>
Hixie_: so actually the example given doesn't violate the restrictions

[01:32:16.0000] <zcorpan>
Hixie_: v.nu implements the restrictions and gives no error for the <!-- despite appearances, this is actually part of the script still! --> example

[01:39:57.0000] <zcorpan>
parse error when entering double escaped seems like the missing piece

[01:43:15.0000] <zcorpan>
Hixie_: looks like steve cloned the bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=23590

[02:13:57.0000] <MikeSmith>
zcorpan: are you proposing that the validator emit a warning any time it sees <!-- in script?

[02:14:09.0000] <zcorpan>
MikeSmith: no

[02:14:21.0000] <zcorpan>
MikeSmith: an error when seeing <!-- <script

[02:14:59.0000] <MikeSmith>
ok

[02:15:56.0000] <zcorpan>
the validator already emits an error for <script><!--</script>, but <script><!--<script></script>... is more problematic in a world with only html5 parsers

[02:16:10.0000] <zcorpan>
whereas the former is problematic in legacy parsers

[02:16:17.0000] <MikeSmith>
I see

[02:17:37.0000] <zcorpan>
and people who do <script><!-- document.write('<script><'+'/script>') --></script> deserve an error

[02:17:56.0000] <Ms2ger>
People who do document.write deserve one ;)

[02:18:28.0000] <zcorpan>
does any browser whine about document.write in devtools?

[02:19:42.0000] <SimonSapin>
annevk-cloud: http://url.spec.whatwg.org/#writing what does "Writing" mean? Is it different from Serializing?

[02:22:29.0000] <zcorpan>
heh, PDF tojan horse <http://www.w3.org/mid/FADAB8BA-B90A-49F0-85B1-535BC13D2E44⊙ff>

[02:25:21.0000] <SimonSapin>
I suppose this is the concern? https://en.wikipedia.org/wiki/Jpeg2000#Legal_issues

[02:25:25.0000] <annevk>
SimonSapin: yes

[02:26:43.0000] <SimonSapin>
annevk: http://krijnhoetmer.nl/irc-logs/whatwg/20131022#l-249

[02:27:46.0000] <annevk>
SimonSapin: recursion?

[02:29:13.0000] <SimonSapin>
annevk: was "yes" about URL or JPEG2000?

[02:29:27.0000] <annevk>
SimonSapin: URL

[02:29:43.0000] <SimonSapin>
so, yes it is different. What does it mean?

[02:31:09.0000] <annevk>
Serializing is often much more constrained. E.g. you can write CSS in many ways, but a CSS serializer is required to follow certain algorithms because otherwise browsers have differences that developers will trip over.

[02:31:59.0000] <SimonSapin>
so writing is what authors write, what the parser supports?

[02:38:21.0000] <annevk>
SimonSapin: yes

[02:40:54.0000] <MikeSmith>
heh "If you said something incorrect and I failed to correct you, I apologize and promise to be more vigilant in the future." http://lists.w3.org/Archives/Public/public-audio/2013OctDec/0145.html from roc

[02:43:20.0000] <jgraham>
SimonSapin: In general there are three different sets each with a subset relation to the preceeding one; the set of things that the parser supports, the set of things authors are permitted to write and the set of things that the serializer can emit.

[02:43:53.0000] <SimonSapin>
http://url.spec.whatwg.org/#concept-parsed-url Just like scheme data is not used in relative schemes, should username, password, host, port and path not be be used in non-relative schemes? I’m trying to come up with a model/data structure for parsed URLs

[02:44:34.0000] <SimonSapin>
jgraham: ok, makes sense

[02:46:17.0000] <jgraham>
SimonSapin: A better type structure for URLs sounds good

[02:47:10.0000] <SimonSapin>
I have this so far based on #writing, but #concept-parsed-url seems to disagree: https://pastebin.mozilla.org/3310970

[02:51:12.0000] <Ms2ger>
MikeSmith, that's a misquote, should end "in the future [...]."

[02:51:18.0000] <annevk>
SimonSapin: don't base the model on #writing

[02:51:37.0000] <annevk>
SimonSapin: a parsed URL is always absolute

[02:52:06.0000] <annevk>
SimonSapin: so either "scheme" and "scheme data" or "scheme", "username", etc.

[02:52:25.0000] <annevk>
SimonSapin: oh, both also have "query" and "fragment"

[02:52:39.0000] <SimonSapin>
yes, that’s what I’m trying to encode in the type system

[02:52:49.0000] <jgraham>
annevk: Look at the pastebin

[02:53:00.0000] <annevk>
jgraham: I did

[02:53:07.0000] <jgraham>
YOu should like this stuff because it forces you to define the model very carefully :)

[02:53:22.0000] <SimonSapin>
all parsed URLs have a scheme but some have a "relative scheme", ie. can be used as a base for relative URLs

[02:53:25.0000] <annevk>
Yes, the model is not yet defined

[02:53:47.0000] <annevk>
Because it's still a bit unclear to me how fragments work, because they're different all over :/

[02:54:11.0000] <SimonSapin>
Isn’t fragment just an optional string?

[02:54:14.0000] <SimonSapin>
in the model

[02:54:16.0000] <jgraham>
Does that matter here?

[02:54:45.0000] <annevk>
jgraham: kinda, are the individual bits bytes or code points

[02:55:27.0000] <jgraham>
Well, OK in that case it's not clear if it should be ~str or ~[u8]

[02:55:38.0000] <jgraham>
Or however one represents bytes

[02:55:55.0000] <jgraham>
(pretending that ~str was code points)

[02:56:14.0000] <jgraham>
But that doesn't seem very important for the rest of SimonSapin's work

[02:56:26.0000] <annevk>
SimonSapin: userinfo should prolly not be a distinct struct

[02:57:16.0000] <jgraham>
annevk: Can you have a password with no username?

[02:57:23.0000] <SimonSapin>
annevk: the struct is just a detail to encode the Option structure, ie. password can only exist with an username

[02:57:29.0000] <jgraham>
I think that's what the seperateness there encodes

[02:57:35.0000] <jgraham>
Right

[02:57:47.0000] <SimonSapin>
every other type here is an implementation detail of ParsedURL

[02:58:33.0000] <annevk>
So userinfo is not actually exposed?

[02:58:40.0000] <annevk>
I'm not sure I understand how this works

[02:59:11.0000] <jgraham>
annevk: It's part of the data structure, but you wouldn't have a .userinfo visible to script or anything

[02:59:44.0000] <annevk>
Is that the same for scheme_and_data?

[03:00:39.0000] <jgraham>
Yeah, so presumably SimonSapin will implement some accessors that will return the script-visible parts

[03:01:10.0000] <jgraham>
But this setup forces other internal code to follow the rules

[03:03:36.0000] <SimonSapin>
annevk: exposed, you mean to JS?

[03:04:20.0000] <SimonSapin>
Rust data structures do not have to map exactly to JS bindings

[03:04:51.0000] <SimonSapin>
here I tried to encode some constraints in the type system (such as password can only be set with a username)

[03:05:07.0000] <SimonSapin>
but maybe it’s fine not to do that and just have the parser never return such objects

[03:05:18.0000] <SimonSapin>
and have a "flatter" data structure

[03:05:19.0000] <annevk>
SimonSapin: I just mean in Rust

[03:05:29.0000] <annevk>
SimonSapin: I understand you can expose whatever in JS

[03:06:18.0000] <SimonSapin>
with this API yes, users of the Rust lib have to go through UserInfo to get the username/password

[03:06:56.0000] <SimonSapin>
annevk: would you rather have a simpler data structure with some constraints not enforced?

[03:07:32.0000] <annevk>
SimonSapin: I'm not sure what's best for Rust

[03:09:21.0000] <annevk>
I expected something flatter. I'll note that only the parser can directly operate on the data structure. Any API for manipulating the data structure will need to do so indirectly as conversions and such have to be made.

[03:12:53.0000] <jgraham>
FWIW I had a flatter data structure and I think this is better :)

[03:14:33.0000] <SimonSapin>
annevk: do you mean the fields should not be accessed directly but through getters and setters?

[03:16:26.0000] <annevk>
SimonSapin: for reading it might be okay, for manipulating only if you know what you're doing

[03:17:22.0000] <annevk>
SimonSapin: basically the parser guarantees certain things, being able to put in ".." as one of the entries of URL's path would be bad

[03:18:50.0000] <jgraham>
Can't encode that in Rust's type system really :)

[03:19:09.0000] <gsnedders>
Bah, just need a better type system!

[03:19:26.0000] <jgraham>
(so I imagine that yes you would have getters and setters in the external API)

[03:19:47.0000] <jgraham>
gsnedders: Is it nice up there in the ivory tower? :)

[03:27:17.0000] <gsnedders>
jgraham: Well, compilation is undecidable, but it's fine!

[03:27:30.0000] <SimonSapin>
does any browser still support gopher?

[03:28:21.0000] <jgraham>
SimonSapin: Pretty sure that they don't since Gecko removed support

[03:28:32.0000] <gsnedders>
Opera/Linux?

[03:28:52.0000] <gsnedders>
Oh, no.

[03:29:24.0000] <gsnedders>
SimonSapin: I guess lynx doesn't count? :P

[03:29:29.0000] <SimonSapin>
it’s probably harmless to have it in the URL parser

[03:30:44.0000] <jgraham>
gsnedders: As much as I wanted to say "Opera had it last", no :)

[03:32:13.0000] <annevk>
SimonSapin: yeah, dunno, it was in WebKit

[03:32:20.0000] <annevk>
SimonSapin: support for the scheme

[03:32:53.0000] <jgraham>
According to Wikipedia, of the WebKit browsers, only OmniWeb supports it by default

[03:33:03.0000] <jgraham>
Fx has an addon

[03:33:23.0000] <jgraham>
Everything else seems to be small browsers that were using old version of gecko

[03:33:32.0000] <jgraham>
and non-graphical browsers

[03:38:07.0000] <annevk>
In terms of parsing

[03:41:43.0000] <foolip>
annevk, any particular reason you think arv is interested in my UseCounter?

[03:42:16.0000] <annevk>
foolip, he likes killing stuff :-)

[03:43:00.0000] <foolip>
it is a joy to send red diffs to review

[03:43:05.0000] <foolip>
BTW, I've canceled my TPAC trip, so don't expect to see me there

[03:43:17.0000] <jgraham>
:(

[03:43:51.0000] <foolip>
too much time away from home in November otherwise, with two other conferences (FOMS and Opera-internal)

[03:44:25.0000] <foolip>
jgraham, where do you live now?

[03:44:36.0000] <foolip>
GPS coordinates for my killdrones, plz

[03:44:42.0000] <jgraham>
foolip: London, approximately.

[03:44:58.0000] <foolip>
OK, will make a big sweep then :)

[03:45:00.0000] <jgraham>
/me points the killdrones to annevk's house

[03:45:31.0000] <annevk>
hah, joke's on you, my house is not in London

[03:45:37.0000] <foolip>
jgraham, what kind of stuff are you doing at Mozilla?

[03:45:47.0000] <annevk>
mainly pestering me

[03:46:04.0000] <foolip>
annevk, but you still work from the Netherlands, right?

[03:46:12.0000] <annevk>
foolip: no I'm in London

[03:46:19.0000] <foolip>
annevk, oh, I had no idea

[03:46:31.0000] <jgraham>
Ah, good I was worried that you had a hologram or something

[03:46:36.0000] <foolip>
then I should force both of you to buy me English cider if I visit London

[03:46:53.0000] <annevk>
together we might have enough money

[03:46:54.0000] <gsnedders>
But you're Swedish, you'll complain it's not sweet.

[03:47:15.0000] <foolip>
gsnedders, I really won't, I enjoy it very much :)

[03:47:16.0000] <annevk>
I don't think I ever had cider here

[03:47:48.0000] <jgraham>
foolip: I am mostly working on the W3C web-platform-tests stuff, with the gols of getting Mozill running the tests on each push and writing tests instead of proprietary tests

[03:48:23.0000] <wilhelm>
\o/

[03:48:42.0000] <foolip>
jgraham, that would be nice for Chromium as well, I've been writing tests using testharness.js but don't have a way to keep them in sync if I should submit them to the W3C :(

[03:48:54.0000] <foolip>
(I think, I haven't actually asked anyone.)

[03:48:57.0000] <gsnedders>
Wasn't someone working on that?

[03:49:03.0000] <jgraham>
foolip: Yeah, that side of it is a huge problem

[03:49:08.0000] <jgraham>
gsnedders: Dirk Pranke

[03:49:16.0000] <gsnedders>
jgraham: Right, that's the name.

[03:49:19.0000] <foolip>
is he in this channel?

[03:49:24.0000] <jgraham>
I don't think so

[03:49:32.0000] <gsnedders>
jgraham: I was trying to find something like Derk or Deirk :P

[03:50:01.0000] <jgraham>
I think bratell spoke to him or heard a talk from him at BlinkOn so he (bratell) might know more

[03:50:17.0000] <annevk>
http://www.youtube.com/watch?v=aAZR7OUhFDU o_O

[03:50:20.0000] <foolip>
I met him at BlinkOn as well, but didn't ask about testing

[03:50:27.0000] <gsnedders>
He's in #blink at times, too

[03:51:13.0000] <foolip>
well, isn't this a nice little Opera chat room :)

[03:51:41.0000] <jgraham>
annevk: That was satire, right?

[03:51:48.0000] <annevk>
jgraham: I'm not sure, JakeA?

[03:52:09.0000] <jgraham>
I got as far as the intro and the slightly creepy host

[03:53:04.0000] <JakeA>
no

[03:53:34.0000] <JakeA>
I don't think so

[03:56:44.0000] <JakeA>
Poor Brian

[04:02:55.0000] <darobin>
I think a Standards Suck parody is in order

[04:04:55.0000] <matjas>
do any browsers support autofill fields for `autocomplete` attribute? http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofill-field

[04:05:31.0000] <matjas>
doesn’t really seem to work in Chrome — any value seems to map to `autocomplete="off"`

[04:06:05.0000] <JakeA>
matjas: really? I don't think that's the case

[04:06:13.0000] <JakeA>
I've seen it work before

[04:06:23.0000] <JakeA>
also http://www.html5rocks.com/en/tutorials/forms/requestautocomplete/

[04:06:36.0000] <foolip>
jgraham, do you have a pointer to the latest and bestest way to submit new testharness.js tests?

[04:06:47.0000] <foolip>
if it's easy enough, I want to do it...

[04:06:57.0000] <foolip>
(feel the pressure)

[04:07:57.0000] <jgraham>
foolip: http://testthewebforward.org/docs/

[04:08:36.0000] <JakeA>
matjas: I get this autocompleting https://googledrive.com/host/0B28BnxIvH5DueUxvWVNsQXd5dU0/checkout.html?

[04:08:37.0000] <jgraham>
http://testthewebforward.org/docs/github-101.html#test-repositories might be all you need to know

[04:09:27.0000] <foolip>
ok, so pull request on https://github.com/w3c/web-platform-tests is the super-short answer?

[04:10:22.0000] <annevk>
foolip: yeah

[04:10:49.0000] <foolip>
nice

[04:11:04.0000] <matjas>
JakeA: thanks. trying to pin down what i’m doing wrong

[04:11:10.0000] <foolip>
jgraham, is old-tests/submission/Opera/media/ going to stay there forever, or is there a plan?

[04:12:43.0000] <jgraham>
foolip: There is a plan

[04:13:04.0000] <jgraham>
So if possible don't submit new tests there

[04:13:20.0000] <foolip>
jgraham, ok, thanks!

[04:13:48.0000] <foolip>
zcorpan, do you know if all of our media tests are somewhere in https://github.com/w3c/web-platform-tests ?

[04:13:55.0000] <foolip>
would be super nice :)

[04:14:18.0000] <zcorpan>
foolip: they are not

[04:14:29.0000] <zcorpan>
foolip: a few of them are, though

[04:14:36.0000] <foolip>
zcorpan, because they need to be converted to testharness.js?

[04:14:39.0000] <zcorpan>
in particular the track tests are all submitted i think

[04:15:45.0000] <zcorpan>
i had a few attempts at submitting most media tests (without converting), but for some reason it hasn't actually happened yet

[04:16:17.0000] <foolip>
zcorpan, I will cheer when it happens :)

[04:16:24.0000] <zcorpan>
iirc the track tests are still to be reviewed

[04:17:07.0000] <zcorpan>
past experience suggests that it's better to convert to testharness first and then submit

[04:17:19.0000] <foolip>
I want to do a spec-implementation sync for video and track in Blink, so having our tests public would be helpful in that endeavor

[04:17:41.0000] <foolip>
zcorpan, do you have some half-finished conversion work sitting around in case I'm curious?

[04:18:02.0000] <zcorpan>
because some people get grumpy about there being tests in the wrong format and expect a deadline for when i will have them converted. and nobody else helps converting. Ms2ger is exception to the rule who helped convert some worker tests

[04:18:43.0000] <foolip>
zcorpan, oh, some of the stuff in old-tests/submission/Opera/ is not converted?

[04:19:11.0000] <jgraham>
/me converted some websockets tests

[04:19:21.0000] <jgraham>
But I think I was being paid by Opera at the time

[04:19:25.0000] <wilhelm>
If that helps, there's always http://testsuites.opera.com/ . You can sync things directly from the t server to there. That gets the tests out in the open, at least, even if they are the wrong format.

[04:19:33.0000] <jgraham>
So maybe that doesn't count

[04:20:07.0000] <foolip>
wilhelm, hmm, I see that there are none of the media tests, so maybe dumping them directly into https://github.com/w3c/web-platform-tests would be just as easy

[04:20:08.0000] <zcorpan>
jgraham: yeah, maybe i was unfair with the no help statement

[04:20:34.0000] <wilhelm>
Leaving mostly-good tests to rot on an internal server is the worst option anyway. (c:

[04:20:38.0000] <jgraham>
Putting things unconverted in web-platform-tests is much much better than testsuites.opera.com

[04:20:54.0000] <wilhelm>
Then I withdraw my above comment. (c:

[04:21:18.0000] <jgraham>
At least in the latter case it might eventually be my job to do the conversions

[04:21:44.0000] <zcorpan>
anyway i'll have another look at dumping the tests

[04:21:47.0000] <jgraham>
The problem we have at the moment is that there are relatively lots of people that want a testsuite and relatively few who are apid to work on it

[04:22:02.0000] <wilhelm>
That sounds vaguely familiar.

[04:22:22.0000] <jgraham>
Also W3C seem to have assigned denis to do some work on the testsuite for the purposes of HTML->Rec

[04:22:36.0000] <jgraham>
So now is probably a good time to dump HTML tests

[04:22:45.0000] <jgraham>
(now lunch)

[04:47:51.0000] <MikeSmith>
apid?

[04:48:25.0000] <jgraham>
paid

[04:48:47.0000] <jgraham>
My fingers aren't race-free

[04:50:59.0000] <MikeSmith>
heh

[04:58:04.0000] <Ms2ger>
Oh hey, hadn't seen http://testsuites.opera.com/ before

[04:59:03.0000] <Ms2ger>
FWIW, I'm happy to help converting tests to th.js, given infinite free time :)

[04:59:10.0000] <wilhelm>
Ms2ger: It predates the W3C servers by a small margin, I think. It wasn't really used much.

[05:04:52.0000] <jgraham>
Started work on https://github.com/jgraham/html-testsuite/blob/documentation/docs/critic.md

[05:05:27.0000] <jgraham>
I think I really need to walk through an actual review to make it work though. Which is quite a lot of work :|

[05:08:36.0000] <Ms2ger>
I've got https://critic.hoppipolla.co.uk/r/208 to offer ;)

[05:10:02.0000] <jgraham>
Yeah, but to tick all the boxes, I need a review with multiple commits, possibly touching multiple files, and some deliberate errors

[05:10:53.0000] <jgraham>
I think I will have to construct something artificial

[05:11:16.0000] <jgraham>
/me does something else for a bit

[05:22:43.0000] <Ms2ger>
jgraham, done

[05:25:24.0000] <Ms2ger>
Ta

[05:25:41.0000] <jgraham>
Thanks for the tests :)

[05:26:39.0000] <zcorpan>
jgraham: for the timeout_multiplyer change, what's the story for existing tests that set timeout?

[05:27:10.0000] <Ms2ger>
/me is down to two branches in his wpt clone

[05:28:37.0000] <Ms2ger>
Now I could focus on reviewing!

[05:28:39.0000] <Ms2ger>
Could

[05:28:45.0000] <smaug____>
/me wonders what is happening with Web Audio API

[05:28:58.0000] <smaug____>
Ms2ger: want to take some patches from my queue ;)

[05:29:11.0000] <Ms2ger>
Ugh

[05:29:19.0000] <smaug____>
WAAPI doesn't have an active editor anymore, I think

[05:29:22.0000] <Ms2ger>
Thanks for reminding me off my code review queue :/

[05:29:30.0000] <smaug____>
and that spec certainly could use some heavy editing

[05:29:49.0000] <Ms2ger>
smaug____, volunteering? :)

[05:31:15.0000] <smaug____>
nouu

[05:31:48.0000] <smaug____>
well, I could kill all the nonsense first and focus on the stuff people actually need

[05:44:11.0000] <zcorpan>
what i remember from looking at web audio is sad panda

[05:48:57.0000] <zcorpan>
jgraham: hmm, the per-test timeout setting is still supported?

[05:49:34.0000] <zcorpan>
seems so

[05:51:42.0000] <smaug____>
oh, the trash version has different editors

[05:52:09.0000] <smaug____>
odd, is TR/ of web audio the real version

[05:52:34.0000] <annevk>
maybe they moved to GitHub?

[05:52:47.0000] <smaug____>
aha, my mistake. The editor's draft is in unusual place

[05:53:07.0000] <annevk>
smaug____: https://github.com/WebAudio/

[05:53:12.0000] <smaug____>
yes

[05:53:14.0000] <smaug____>
unsual

[05:53:30.0000] <smaug____>
ok, silly me. my mistake

[05:53:38.0000] <annevk>
par for the course in the WHATWG

[05:53:54.0000] <smaug____>
how so?

[05:54:02.0000] <smaug____>
I see whatwg specs under whatwg.org

[05:54:16.0000] <smaug____>
not some random .com

[05:54:26.0000] <annevk>
ah, yeah, checked out versions are, but they are copied from https://github.com/whatwg/

[05:55:08.0000] <smaug____>
but whatwg.org versions are generated immediately when github version changes, right?

[05:55:47.0000] <annevk>
yes

[05:55:53.0000] <smaug____>
but anyway, total failure from my side :)

[05:55:55.0000] <annevk>
sorry for the confusion

[05:56:06.0000] <jgraham>
zcorpan: Yeah, still supported although you are encouraged to leave it alone unless you know what you are doing

[05:56:20.0000] <smaug____>
/me wants consistency also in spec document management :)

[05:56:58.0000] <annevk>
we're still in the competition phase, not ready to standardize quite yet

[06:14:52.0000] <darobin>
yeah, it's hardcore competition phase there

[06:15:18.0000] <darobin>
which is why W3C has decided to adopt a vastly improved spec location system based on subdomains

[06:15:43.0000] <darobin>
for instance, we'll now have http://web-audio.wd.2013.10.05.specs.rectrack.w3.org/

[06:15:51.0000] <darobin>
much simpler that way!

[06:16:27.0000] <Ms2ger>
Wrong order in your date

[06:17:11.0000] <darobin>
Ms2ger: only if you're trying to make it useful :)

[06:17:31.0000] <Ms2ger>
Should have known better

[06:18:01.0000] <foolip>
TabAtkins, ping

[06:19:33.0000] <TabAtkins>
foolip: pong

[06:21:28.0000] <foolip>
TabAtkins, I started following some weird Blink code around video sizing, and found myself in your spec: http://dev.w3.org/csswg/css-images/

[06:22:07.0000] <foolip>
TabAtkins, in particular, Blink uses default intrinsic size 300x150, instead of default object size 300x150

[06:22:50.0000] <foolip>
and there's a comment in RenderReplaced::computeReplacedLogicalWidth that says that it isn't what the spec says, but could be risky to change

[06:23:16.0000] <foolip>
my concrete question is which spec should specify that the default object size of images should be 0x0

[06:24:16.0000] <TabAtkins>
Why would that be what you wanted?

[06:25:13.0000] <foolip>
I was under the impression that 300x150 is the default for replaced content, but that could just be what Blink does

[06:25:29.0000] <foolip>
now that I checked I couldn't find a default at all

[06:25:31.0000] <foolip>
(in the specs)

[06:25:41.0000] <TabAtkins>
This keeps coming up. ^_^

[06:25:59.0000] <darobin>
TabAtkins: have you thought about using https://github.com/tobie/specref for Bikeshed?

[06:26:01.0000] <Ms2ger>
So spec it ;)

[06:26:03.0000] <TabAtkins>
Replaced elements are sized in a slightly weird way which is *almost* the sizing algorithm in Images, but not quite.  Just follow 2.1.

[06:26:19.0000] <TabAtkins>
Specifically, the "inline replaced elements" stuff.

[06:26:25.0000] <Ms2ger>
So does 2.1 say "whatever"? :)

[06:26:40.0000] <TabAtkins>
Ms2ger: Only in one case.

[06:26:57.0000] <Ms2ger>
/me hears "yes"

[06:27:09.0000] <TabAtkins>
darobin: I do plan on adding that in as a source, but it's hard to integrate as the links are untyped. :/

[06:29:19.0000] <foolip>
TabAtkins, http://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width ends up with 300px, that isn't what any browser does for images

[06:30:44.0000] <TabAtkins>
Interesting. What's the precise conditions that land you there?

[06:31:39.0000] <foolip>
TabAtkins, try http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2579 in a few different browsers

[06:31:46.0000] <foolip>
the conditions are very simple, as you will see :)

[06:32:02.0000] <darobin>
TabAtkins: can you file a bug on the repo indicating what your needs are? it would be good to have a single point there, and we're happy to improve things

[06:34:26.0000] <TabAtkins>
foolip: Ah, this is an interesting case, as there's no image at all.

[06:34:47.0000] <foolip>
TabAtkins, I'm guessing this will also be the size while the image is loading, although I haven't tried

[06:34:50.0000] <TabAtkins>
Not too surprised that browsers handle this differently than the has-image case.

[06:35:30.0000] <TabAtkins>
Using delayed-image, yeah, it is.

[06:35:46.0000] <TabAtkins>
Okay, looks like this is a case the spec doesn't touch.  I'll put it on my list of things to explore and spec.

[06:35:54.0000] <foolip>
my guess is that making images 300x150 for either the no-src or the still-loading case is not Web compatible

[06:36:15.0000] <TabAtkins>
Yeah.

[06:36:47.0000] <foolip>
right now, I'm trying to decide how to fix <video> sizing, without also breaking all other replaced content

[06:37:22.0000] <foolip>
but it sounds like the "default object size" concept in your spec isn't ready for implementation?

[06:37:47.0000] <TabAtkins>
https://github.com/tabatkins/specs/issues/17

[06:38:28.0000] <TabAtkins>
It doesn't cover replaced elements, but is otherwise fine and should be web-compatible.

[06:39:51.0000] <foolip>
TabAtkins, ok, maybe I'll try to clean up the other things that are wrong about this first, and leave splitting of intrinsic size from default object size until later

[06:40:01.0000] <foolip>
(about <video> that is)

[06:40:32.0000] <tobie>
TabAtkins: don't understand what you mean by "typed links".

[06:42:07.0000] <TabAtkins>
tobie: Bikeshed (and Shepherd) gives a type to all definitions, to reduce the chance of clashing.  Links are thus also typed.  (The typing information also has other benefits, like making it easier to auto-gen some kinds of documentation.)

[06:43:18.0000] <tobie>
/me confused.

[06:43:25.0000] <tobie>
In practice, what does that mean?

[06:44:12.0000] <TabAtkins>
It means that you can write 'foo' and be assured that it'll link to the foo *property*, not anything else, and that you won't have to disambiguate the link unless there are multiple definitions of the property.

[06:44:33.0000] <TabAtkins>
(Because 'foo' is a markup shortcut in Bikeshed that expands to <a data-dfn-type=property>foo</a>.)

[06:44:51.0000] <TabAtkins>
Sorry, data-link-type

[06:45:29.0000] <tobie>
oh, are you referring to the fact that some of the references in specref are still html strings?

[06:46:00.0000] <tobie>
because mostly it's just structured data, now.

[06:47:31.0000] <TabAtkins>
tobie: No, not that.

[06:47:41.0000] <TabAtkins>
Look at the difference between https://github.com/tobie/specref/blob/master/xrefs.json and https://raw.github.com/tabatkins/bikeshed/master/bikeshed/spec-data/anchors.json

[06:47:51.0000] <tobie>
oh---that.

[06:48:02.0000] <TabAtkins>
The xrefs are just a mapping from arbitrary string to anchor.

[06:48:18.0000] <TabAtkins>
While bikeshed's data is much richer and makes it easier to autolink.

[06:48:23.0000] <tobie>
I have no idea how that works or what it does. Afaik, no one uses it. Ask darobin.

[06:48:34.0000] <TabAtkins>
Oh, you were just wanting to talk about the biblio data?

[06:48:54.0000] <TabAtkins>
Yeah, as far as I can tell biblio is fine.  I can integrate that.  I'll file an issue on myself for it.

[06:49:35.0000] <mabj>
Hi

[06:49:46.0000] <TabAtkins>
tobie: Do you know what the relation is between specref's biblio data and Bert's biblio.ref stuff?

[06:50:06.0000] <Ms2ger>
tobie, are these just gh/whatwg/xref merged into one file?

[06:50:46.0000] <tobie>
Ms2ger: think so. darobin would know more about this .

[06:51:46.0000] <darobin>
right, so the xrefs data is specref is just a rather old whatwg import; it would certainly be good to update it and make it more useful, as per TabAtkins's usage notably

[06:51:53.0000] <tobie>
TabAtkins: afaik relationship is historical: Bert's biblio ref stuff was used by darobin's respec.biblio which I ripped out turn into a service earlier this year.

[06:52:32.0000] <darobin>
re the bibrefs, they were initially imported from Bert's stuff, then massively edited, then the whatwg refs were merged in, then more editing, then the automatic W3C refs were imported too

[06:53:10.0000] <TabAtkins>
Okay, so using the bibref data should be approximately a superset.  Cool.

[06:53:42.0000] <tobie>
TabAtkins: hopefully.

[06:54:34.0000] <TabAtkins>
So long as it's kept reasonably up-to-date, I'm happy.

[06:54:39.0000] <darobin>
it is

[06:54:42.0000] <TabAtkins>
kk

[06:55:05.0000] <darobin>
I think we could make it more manageable by splitting the source into lots of small files

[06:55:09.0000] <darobin>
but that's a backend detail

[06:56:34.0000] <TabAtkins>
All right, I'll handle this later: https://github.com/tabatkins/bikeshed/issues/86

[06:56:41.0000] <darobin>
sweet

[06:57:17.0000] <TabAtkins>
darobin: It's okay if I don't use your API, right? Bikesheed needs to be able to run without network.

[06:57:32.0000] <TabAtkins>
So I'd just download the file locally.

[06:57:36.0000] <darobin>
having a bunch of preprocessors flourish is good, but the stupid work-intensive stuff should be shared if possible

[06:57:43.0000] <darobin>
TabAtkins: yeah, you can just grab a snapshot

[06:57:46.0000] <TabAtkins>
kk

[06:57:57.0000] <TabAtkins>
And yeah, I agree.

[06:58:00.0000] <darobin>
TabAtkins: GETting the endpoint without parameters gives you a dump

[06:58:08.0000] <TabAtkins>
Cool.

[06:58:22.0000] <darobin>
I recommend that over getting the GH content because we reserve the right to change how that's organised

[06:58:35.0000] <TabAtkins>
Okay.

[06:58:41.0000] <tobie>
+ the data is already transformed quite a bit.

[06:58:44.0000] <TabAtkins>
We should work on merging the xref stuff too, though.  Shepherd's data is much richer and more useful.

[06:58:51.0000] <darobin>
definitely

[06:58:59.0000] <tobie>
agreed.

[06:59:07.0000] <darobin>
maybe this should be moved out of tobie-space somewhere where we can more easily collaborate on it

[06:59:15.0000] <Ms2ger>
Does it insist on linking to outdated specs?

[06:59:31.0000] <darobin>
Ms2ger: specref is not opinionated there, it gives you a choice

[06:59:46.0000] <darobin>
I'm not sure if it gives enough of a choice yet, but if not it will

[06:59:51.0000] <TabAtkins>
No.  Within W3C space, Shepherd maintains both an ED and TR link.

[06:59:59.0000] <darobin>
it basically knows about multiple version for a document

[07:00:05.0000] <darobin>
oh, you were talking about Shepherd, sorry

[07:00:26.0000] <Ms2ger>
How about w3c forks?

[07:00:52.0000] <TabAtkins>
Those are separate specs.  If Shepherd is parsing them, then they'll just be more definition sources.

[07:00:53.0000] <darobin>
Ms2ger: forks of the ED? I reckon otherwise it might be TR?

[07:01:00.0000] <TabAtkins>
(Possibly requiring disambiguation.)

[07:01:17.0000] <TabAtkins>
There's no preference for anything, though, beyond some special-casing of CSS2.1/SVG1.1 things.

[07:01:36.0000] <tobie>
darobin: moving specref to gh.com/w3c is on my todo list, but far from the top, unfortunately.

[07:02:12.0000] <darobin>
tobie: I could easily move the repo, but I guess that won't help with the nodejitsu bit

[07:02:22.0000] <tobie>
Exactly.

[07:03:02.0000] <darobin>
just give me your nodejitsu admin password and all will be fine

[07:03:05.0000] <darobin>
I *promise*

[07:04:24.0000] <tobie>
TabAtkins: where's the shepherd api endpoint got this x-ref stuff and what exactly is included in it?

[07:04:47.0000] <tobie>
(or more to the point: where can I read more about this?)

[07:04:57.0000] <zcorpan>
heycam: please help https://critic.hoppipolla.co.uk/showcomment?chain=615

[07:05:22.0000] <TabAtkins>
Dunno how much docs plinss maintains on shepherd.

[07:05:55.0000] <TabAtkins>
But it just downloads and parses all the specs it knows about regularly (in the case of dvcs.w3.org specs, it has commit hooks for some repos that lets it parse within a few minutes).

[07:06:19.0000] <TabAtkins>
It shares definition extraction logic with Bikeshed, so you can read Bikeshed's docs to learn about that.

[07:07:02.0000] <Ms2ger>
zcorpan, so what's the question?

[07:08:40.0000] <zcorpan>
Ms2ger: i think, what does webidl require to happen for InterfaceObject.staticOperation.apply(null, args)

[07:09:23.0000] <Ms2ger>
zcorpan, the this value doesn't matter at all for static operations

[07:10:10.0000] <heycam>
Ms2ger, zcorpan, correct

[07:10:35.0000] <Ms2ger>
So you basically can't test anything

[07:10:49.0000] <heycam>
well you can test passing funny values and checking that the method is still run

[07:11:01.0000] <heycam>
(as the first argument to .call)

[07:11:05.0000] <darobin>
but that requires knowing some good jokes

[07:11:25.0000] <Ms2ger>
heycam, the static operation can throw TypeErrors if it likes

[07:11:42.0000] <Ms2ger>
heycam, so you can't assert that it doesn't

[07:11:51.0000] <heycam>
Ms2ger, sure. oh is this the generic idl tests, not knowing what the exact function is?

[07:11:57.0000] <Ms2ger>
Right

[07:12:14.0000] <heycam>
ok then yes

[07:12:24.0000] <heycam>
maybe you could bake in a function you know will never throw TypeError?

[07:13:07.0000] <Ms2ger>
As part of your test suite, sure

[07:13:23.0000] <heycam>
(maybe I do already)

[07:13:37.0000] <zcorpan>
ok thx

[07:13:55.0000] <annevk>
merging XMLHttpRequest and Fetch...

[07:14:35.0000] <annevk>
this is why people get upset when you change the invariants

[07:19:18.0000] <tobie>
TabAtkins: thanks.

[07:36:38.0000] <annevk>
I think the end might be in sight...

[07:36:57.0000] <annevk>
I mean, the point where everyone will start complaining about how it's all different and has bugs

[07:43:50.0000] <jgraham>
Is that "the end" as in "the point where you die and then are eaten by the bugs you created"?

[07:47:42.0000] <annevk>
jgraham: hard to predict the future

[08:01:17.0000] <zcorpan>
TabAtkins: is it intended to invoke bikeshed as "bikeshed" or "bikeshed.py" in Makefile? i installed it using sudo python setup.py install and the former only works, but for dirk only the latter works

[08:01:48.0000] <TabAtkins>
If the thing has been installed, "bikeshed" works.  If it hasn't, bikeshed.py exists as a launcher.

[08:02:02.0000] <TabAtkins>
I don't use and don't understand Makefiles, so I can't help you with that.

[08:04:28.0000] <zcorpan>
ok, thx

[08:49:28.0000] <annevk>
When there's more example than normative text, you gotta wonder... http://dev.w3.org/csswg/css-snappoints/

[08:52:01.0000] <annevk>
Are there any browser vendor blogs out there that don't read like press releases?

[09:15:56.0000] <annevk>
Whoa, I got rid of the XMLHttpRequest task source

[09:26:23.0000] <annevk>
Aight, landed.

[09:30:41.0000] <annevk>
Initial breakage fixes landed.

[09:37:05.0000] <sangwhan__>
annevk: why is there a w3c clone of the url spec?

[09:37:39.0000] <Ms2ger>
sangwhan__, uh-oh...

[09:37:49.0000] <annevk>
sangwhan__: is there?

[09:37:49.0000] <sangwhan__>
/me notes a off record answer is fine, just want to know which one to follow as I might have to make some changes to GURL

[09:38:08.0000] <Ms2ger>
sangwhan__, follow the whatwg one :)

[09:38:16.0000] <Ms2ger>
What channel did you think you were in? ;)

[09:38:22.0000] <annevk>
sangwhan__: http://url.spec.whatwg.org/ is the only one with maintenance to my knowledge

[09:38:43.0000] <sangwhan__>
annevk: the w3c one i bumped into, which has your name on it in big bold text :)

[09:40:06.0000] <sangwhan__>
/me wonders if i plucked the tiger's whisker

[09:40:49.0000] <sangwhan__>
So we have a problem that needs solving, namely pointer events (thank you IPR) not acknowledging touch events exist, but implementations that have to deal with pointer/mouse/touch all in one merry basket

[09:42:24.0000] <sangwhan__>
And then there are the even less fortunate ones who have to deal with spatnav only browsing, which have no clue on what kind of compat events we need to fire

[09:45:09.0000] <annevk>
sangwhan__: hmm, pointer?

[09:45:15.0000] <annevk>
sangwhan__: https://dvcs.w3.org/hg/url/raw-file/tip/Overview.html maybe?

[09:45:20.0000] <sangwhan__>
annevk: yeah, that thing

[09:45:56.0000] <sangwhan__>
annevk: "the editor" is where i thought something is strange

[09:46:14.0000] <annevk>
sangwhan__: the date is a clue

[09:47:56.0000] <sangwhan__>
annevk: ah, a clue

[09:48:02.0000] <annevk>
sangwhan__: so yeah, you want the URL Standard, the rest is the W3C doing things without my permission (but with permission from the URL Standard's copyright)

[09:49:26.0000] <sangwhan__>
annevk: i'm not gonna ask why nor who, i figured something was funny

[09:49:49.0000] <annevk>
sangwhan__: it's all quite public

[09:50:01.0000] <annevk>
sangwhan__: see e.g. http://lists.w3.org/Archives/Public/public-i18n-core/2013OctDec/

[09:50:16.0000] <annevk>
sangwhan__: and there's some posts on the web about copyright and such

[09:50:51.0000] <sangwhan__>
annevk: i don't follow i18n, so had no idea - i just happened to bump into it and got a bit curious. guess i'm late to the party.

[09:57:49.0000] <MikeSmith>
zcorpan: so about that function in idlharness that's attempting to test the "if this is null, throw a TypeError" requirement in the WebIDL spec for the non-static case

[09:58:04.0000] <MikeSmith>
it throws a TypeError for the static case too

[09:58:36.0000] <MikeSmith>
the window[this.name].prototype[member.name].apply(null, args) part

[09:59:05.0000] <zcorpan>
MikeSmith: isn't that because window[this.name].prototype[member.name] is undefined in the static case?

[09:59:08.0000] <MikeSmith>
for the static case, it throws "window[this.name].prototype[member.name] is undefined"

[09:59:11.0000] <MikeSmith>
yeah

[09:59:20.0000] <zcorpan>
right, that's expected

[09:59:23.0000] <MikeSmith>
yeah

[09:59:58.0000] <MikeSmith>
but for the non-static case, it throws a TypeError with the message, "close' called on an object that does not implement interface Notification"

[10:00:46.0000] <MikeSmith>
which, that doesn't seem like what I'd expect the message to be

[10:01:12.0000] <zcorpan>
yeah, that's also expected. normal operations require this to be the right kind of object

[10:01:18.0000] <MikeSmith>
ok

[10:01:49.0000] <MikeSmith>
well, I'm just wondering if there's any way I can make that test more specific

[10:02:02.0000] <MikeSmith>
so that it doesn't pass for the static case

[10:02:45.0000] <zcorpan>
there are more things that can be tested in the normal case, but i think nothing that can safely be tested in the static case

[10:02:47.0000] <MikeSmith>
(since all that current test is doing is checking for any kind of TypeError at all)

[10:02:53.0000] <MikeSmith>
ok

[10:03:50.0000] <MikeSmith>
so I guess then I should just put if (!member["static"]) around it and leave it that

[10:03:58.0000] <zcorpan>
yeah

[10:04:03.0000] <MikeSmith>
ok

[10:04:04.0000] <MikeSmith>
thanks

[10:06:05.0000] <zcorpan>
annevk: i looked through the xhr+fetch diff but didn't get much wiser :-) maybe you can check if cssom is using fetch correctly?

[10:06:44.0000] <TabAtkins>
I'm confused and betrayed by the Snap Points spec, because I was literally in the process of writing that very thing this week. ^_^

[10:07:18.0000] <TabAtkins>
Damn Rossi, all putting me off with "oh no, I need to check with Legal before you write the spec" WHEN HE WAS WRITING IT BEHIND ME BACK THE WHOLE TIME

[10:07:27.0000] <TabAtkins>
*MY

[10:07:32.0000] <TabAtkins>
(I'm not a leprechaun.)

[10:07:45.0000] <hober>
no no, it's so much better with you doing an awful fake irish accent

[10:07:47.0000] <TabAtkins>
(Typing all caps on a Pixel is hard, as there's no Caps Lock.)

[10:07:50.0000] <Ms2ger>
[citation needed]

[10:08:02.0000] <TabAtkins>
Ms2ger: You've seen me. I'd be the tallest leprechaun ever.

[10:24:00.0000] <Hixie_>
annevk: multipage thingy seems broken

[10:24:06.0000] <annevk>
le sigh

[10:26:52.0000] <annevk>
http://www.whatwg.org/specs/web-apps/current-work/do-multipage-complete-update

[10:26:52.0000] <annevk>
Resolving www.whatwg.org... 2607:f298:1:105::340:cd86, 69.163.222.251

[10:26:52.0000] <annevk>
Connecting to www.whatwg.org|2607:f298:1:105::340:cd86|:80... connected.

[10:26:53.0000] <annevk>
HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable

[10:26:56.0000] <annevk>
    The file is already fully retrieved; nothing to do.

[10:27:02.0000] <annevk>
oh fuck sorry

[10:31:01.0000] <annevk>
MikeSmith: is http://code.google.com/p/html5/source/browse/trunk/spec-splitter/spec-splitter.py still the latest copy of spec-splitter.py?

[10:31:31.0000] <Hixie_>
wow, don't see 416 very often

[10:31:50.0000] <Hixie_>
looks like something worked, fwiw

[10:36:41.0000] <TabAtkins>
annevk: I'm interested in adding splitting functionality to Bikeshed.  Is there good documentation on the existing tools?

[10:37:10.0000] <annevk>
TabAtkins: no

[10:37:14.0000] <TabAtkins>
Also: how do I respond to a mailing list thread that I'm not already subscribed to, with the least chance of accidentally splitting it?

[10:37:16.0000] <TabAtkins>
annevk: Awesome.

[10:37:23.0000] <TabAtkins>
webkit-dev, if it matters.

[10:38:00.0000] <annevk>
TabAtkins: everything non-vital is a hack and receives no active maintenance, because people want to work on other things

[10:38:32.0000] <TabAtkins>
annevk: All right.  In that case, I guess I'll just need to figure out what people want out of a spec splitter.

[10:38:37.0000] <annevk>
TabAtkins: subscribe to the list

[10:38:44.0000] <annevk>
TabAtkins: spec-splitter.py above is what HTML uses

[10:38:54.0000] <Hixie_>
TabAtkins: have someone forward you the thread in multipart digest form, then reply to the e-mail from that

[10:39:00.0000] <annevk>
TabAtkins: it was written by Philip` back in the day

[10:39:19.0000] <TabAtkins>
Hixie_: That's a decent idea.  I wonder if Gmail supports that?

[10:39:23.0000] <Hixie_>
haha no.

[10:39:25.0000] <Hixie_>
:-)

[10:39:27.0000] <Hixie_>
pine does though :-)

[10:39:28.0000] <MikeSmith>
annevk: that is the latest, yeah

[10:39:38.0000] <TabAtkins>
Man, why you gotta get my hopes up like that.

[10:39:43.0000] <Hixie_>
:-(

[10:39:54.0000] <annevk>
MikeSmith: I a dded a comment

[10:40:01.0000] <Hixie_>
i don't know if gmail does threading right at all

[10:40:02.0000] <annevk>
MikeSmith: http://code.google.com/p/html5/source/detail?r=202

[10:40:09.0000] <Hixie_>
there's a bunch of headers you have to get right for threading to work properly

[10:40:20.0000] <annevk>
MikeSmith: I don't really know how to commit to that repo...

[10:40:39.0000] <Hixie_>
is |e => { }| modern shorthand for |function (e) { }| ?

[10:40:45.0000] <Hixie_>
or is it something more?

[10:40:49.0000] <Ms2ger>
Hixie_, roughly

[10:40:59.0000] <annevk>
we should maybe put spec-splitter on github.com/whatwg too

[10:41:00.0000] <MikeSmith>
annevk: svn commit?

[10:41:01.0000] <Ms2ger>
Hixie_, it also doesn't get its own |this|

[10:41:04.0000] <annevk>
just like web-apps-tracker

[10:41:06.0000] <MikeSmith>
annevk: yeah

[10:41:25.0000] <Hixie_>
Ms2ger: |function (e) { }.bind(this)| ?

[10:41:28.0000] <MikeSmith>
Google Code is the new Sourceforge

[10:41:32.0000] <Ms2ger>
Hixie_, and it returns its expression like in |x => x*x|

[10:42:09.0000] <Ms2ger>
TabAtkins, you get the right headers from the archive, write it out in a text editor and send it with telnet? :)

[10:42:14.0000] <Hixie_>
Ms2ger: so |e => { statements; expr }| is |function (e) { statements; return expr; }.bind(this)| ?

[10:42:22.0000] <TabAtkins>
Ms2ger: Seems reasonable.

[10:42:50.0000] <Ms2ger>
Hixie_, I think that's about it; I haven't followed that closely

[10:42:53.0000] <TabAtkins>
Hixie_: It's a little bit more, but basically yeah.  Important difference is that it doesn't shadow `this`.

[10:43:17.0000] <TabAtkins>
It just lexically binds `this` like a normal variable.

[10:43:18.0000] <Hixie_>
TabAtkins: it captures |this| instead of binding it?

[10:43:51.0000] <Hixie_>
is the {...} necessary? Ms2ger's example didn't have it, but i don't understand what that means

[10:44:01.0000] <TabAtkins>
Yeah.  Also, you can omit the braces if the body is just a single expression, and in that case, omit the "return" too.

[10:44:12.0000] <TabAtkins>
[1,2,3].map(x=>x*2)

[10:44:23.0000] <jgraham>
And you can't use it as a generator aiui

[10:44:39.0000] <Ms2ger>
Well, you can't use function() {} as a generator either

[10:44:46.0000] <Ms2ger>
Needs function*... aiui

[10:44:50.0000] <TabAtkins>
Yup.

[10:44:50.0000] <Hixie_>
oh ok, so |e => { ... }| is |function (e) { ... }.bind(this)| but |e => f| is |function (e) { return f }.bind(this)| ?

[10:45:01.0000] <Hixie_>
wtf is function*

[10:45:07.0000] <Ms2ger>
Generators

[10:45:09.0000] <TabAtkins>
Generator function.  From Python.

[10:45:11.0000] <MikeSmith>
zcorpan: ok all issues for https://critic.hoppipolla.co.uk/r/351 now addressed I think

[10:45:20.0000] <Hixie_>
oh "yield" no longer makes a generator magically?

[10:45:24.0000] <TabAtkins>
Nah.

[10:45:25.0000] <Ms2ger>
Right

[10:45:32.0000] <jgraham>
Wait, what? There's a special form for declaring that a function will be a generator

[10:45:37.0000] <Hixie_>
well that's an improvement. Not sure why you'd use "function*" instead of "generator" but ok

[10:45:47.0000] <TabAtkins>
Hixie_: Reserved words (or lack of them).

[10:45:49.0000] <zcorpan>
MikeSmith: and reviewed

[10:45:50.0000] <jgraham>
Not sure that's really better

[10:45:51.0000] <Ms2ger>
Hixie_, doesn't distinguish based on the {}s, but on the number of expressions, I think

[10:46:15.0000] <Hixie_>
Ms2ger: of {expr} is the same as expr? interesting

[10:46:18.0000] <TabAtkins>
Ms2ger: Ah, so [1,2,3].map(x=>{x*2}) is okay too?

[10:46:24.0000] <Domenic_>
no

[10:46:40.0000] <Hixie_>
is there, like, a spec for this? :-)

[10:46:44.0000] <TabAtkins>
Yes, ES6.

[10:46:48.0000] <Hixie_>
url?

[10:46:50.0000] <Ms2ger>
Apparently not

[10:46:51.0000] <TabAtkins>
But I haven't read it.

[10:46:55.0000] <Domenic_>
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-arrow-function-definitions

[10:47:05.0000] <Hixie_>
thanks Domenic_

[10:47:11.0000] <Ms2ger>
Hixie_, looks like it does look at {}s, nvm that last bit

[10:47:52.0000] <Hixie_>
Domenic_: is there somewhere to file bugs on that text? i found a typo

[10:48:14.0000] <Domenic_>
Hixie_: https://bugs.ecmascript.org/

[10:48:23.0000] <Hixie_>
thanks

[10:48:43.0000] <Ms2ger>
We should get jorendorff to add a widget like html has

[10:49:58.0000] <Domenic_>
There are lots of typos/little inconsistencies, as he's focusing on getting all the semantics in by end of year. But yeah filing them is good if you have the time.

[10:55:03.0000] <zcorpan>
https://github.com/w3c/web-platform-tests/pull/135 looks epic. i wonder if the tests are still valid since <template> was integrated in html

[10:58:10.0000] <jgraham>
zcorpan: Seems to be closed (it might still be wrong now ofc)

[10:58:32.0000] <zcorpan>
right

[10:58:34.0000] <Hixie_>
this is quite dense spec text. i don't think i'll be able to file anything but typos :-)

[10:58:44.0000] <Hixie_>
(can't file anything until bugzilla mails me a password, of course)

[11:00:06.0000] <Domenic_>
Hixie_: check spam folder, I am pretty sure my password went there. And yes, pretty dense :-/

[11:02:22.0000] <Hixie_>
nope

[11:05:25.0000] <Domenic_>
What's the most semantic way to mark up tabs again? Kinda surprised this wasn't in "common idioms without dedicated elements"...

[11:06:38.0000] <hober>
Domenic_: <div><section><h1>tab name</h1>...</section><section><h1>tab name</h1>...</section>...</div> ?

[11:07:05.0000] <Domenic_>
hober: seems right, although tricky to style. thanks.

[11:07:26.0000] <Hixie_>
most semantic way is to not mark them up at all, or maybe use <fieldset> or some such, and then do overflow:tabs (but that doesn't exist yet) or bind to it with a custom Web Component (but that doesn't really exist yet either)

[11:07:51.0000] <Hixie_>
failing that... hober's markup is probably reasonable

[11:08:19.0000] <Hixie_>
fundamentally the key is to realise that tabs are a device-specific rendering of an overflow mechanism (consider what it'd be like in an aural context)

[11:09:42.0000] <Hixie_>
stylistic question for people who know the JS spec. Is "[[DefineOwnProperty]]" considered just a word of the english language, or is it considered code, or a special term (<i>), or something else?

[11:14:06.0000] <Domenic_>
Hixie_: from what I can tell internal methods and properties (i.e. [[things]]) are not marked up specially.

[11:14:21.0000] <Hixie_>
yeah, that was my conclusion too

[11:14:29.0000] <Hixie_>
weirdly, even property descriptors seem to just be prose

[11:14:34.0000] <Hixie_>
ugly ugly prose :-P

[11:21:16.0000] <zcorpan>
MikeSmith: ? https://github.com/w3c/testharness.js/pull/45 no merge?

[11:22:40.0000] <MikeSmith>
zcorpan: I rebase -i'ed/squashed the commits and pushed that

[11:23:14.0000] <MikeSmith>
I guess there's probably some other way I should do it..

[11:23:50.0000] <zcorpan>
dunno, i usually click the green button :-)

[11:23:52.0000] <MikeSmith>
did "git push upstream HEAD:master" where upstream is git⊙gc:w3c/testharness.js.git

[11:24:08.0000] <MikeSmith>
yeah I don't like those buttons

[11:24:14.0000] <MikeSmith>
or GUIs

[11:24:42.0000] <MikeSmith>
I like consoles and curses

[11:25:08.0000] <MikeSmith>
like Hixie, I like pine. Except I spell it "mutt"

[11:27:15.0000] <MikeSmith>
zcorpan: I'm not looking forward so much to Hixie updating the ABNF for the <!-- stuff in <script>

[11:28:30.0000] <zcorpan>
bright side, now is an opportunity to make the rules simpler

[11:29:26.0000] <MikeSmith>
guess so

[11:30:20.0000] <MikeSmith>
zcorpan: anyway thanks for the review

[11:31:06.0000] <MikeSmith>
I plan to spend all my time at TPAC writing tests

[11:31:21.0000] <zcorpan>
nice

[11:31:26.0000] <Ms2ger>
At least that time will be spent usefully

[11:32:15.0000] <MikeSmith>
yeah plus I'm not counting on having usable internet access

[11:32:36.0000] <MikeSmith>
so it's either talk to people or write tests

[11:33:09.0000] <Ms2ger>
Eh, talking to people

[11:43:32.0000] <annevk>
Hixie_: you might have to email Allen directly for a Bugzilla account there

[12:38:22.0000] <jgraham>
I plan to spend all my time at TPAC whining about TPAC

[12:38:30.0000] <jgraham>
Not really

[12:38:34.0000] <jgraham>
Or do I?

[12:38:52.0000] <Ms2ger>
You will find out in the next episode of Standards Suck!

[12:38:55.0000] <annevk>
Best to just relax and hang out with MikeSmith

[12:39:19.0000] <annevk>
I guess we could take that time to record at least one episode, although if marcosc doesn't make it that'd be tricky

[12:40:00.0000] <marcosc>
I'm about to cancel everything

[12:40:15.0000] <annevk>
Oh you can? My stuff is non-refundable...

[12:40:27.0000] <marcosc>
I think I can get the hotel back

[12:40:38.0000] <marcosc>
And should be able to get the registration fee back from w3c

[12:40:42.0000] <Ms2ger>
With so few people going, maybe the wifi will work

[12:40:47.0000] <marcosc>
heh

[12:40:49.0000] <annevk>
I'm gonna give it a few more days.

[12:41:06.0000] <marcosc>
the flight was not very expensive (relatively speaking)

[12:43:06.0000] <marcosc>
heh, there are at least 6 ways to access bookmarks in browsers.

[12:43:43.0000] <annevk>
I'd actually really like a web platform unconference in the bay area someday. I should probably do some reaching out to other companies to how hard that'd be to organize. Something like Edgeconf but more about standards and more parallel (small) sessions.

[12:45:05.0000] <marcosc>
that would be nice

[12:45:15.0000] <annevk>
Oh, and alongside we'd visit the zoo or a museum or some such for fun / team building. Best not do heated discussion all the time if you're only with each other for limited time.

[12:45:55.0000] <marcosc>
I like zoos

[12:47:25.0000] <Ms2ger>
/me puts marcosc into a zoo :)

[12:47:48.0000] <marcosc>
I thought that's where I was already

[12:50:18.0000] <Ms2ger>
http://dev.w3.org/CSS/biblio/biblio.ref

[13:21:47.0000] <annevk>
zcorpan: I guess the question is whether you want incremental loading of style sheets or not

[13:22:01.0000] <annevk>
zcorpan: or more relevant, whether that's observable

[13:22:44.0000] <annevk>
zcorpan: seems kinda observable with a timing attack in HTML using offsetWidth or some such, dunno

[13:24:44.0000] <zcorpan>
annevk: i *think* API-wise it shouldn't be observable, the whole style sheet should be applied atomically

[13:25:08.0000] <annevk>
zcorpan: right

[13:25:29.0000] <annevk>
If people want to bikeshed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23586

[13:25:34.0000] <zcorpan>
but obviously it's observable when subresources are fetched. but that can be considered optimization magic

[13:26:24.0000] <zcorpan>
searchObj seems ok to me

[13:27:09.0000] <Hixie_>
annevk: they don't accept bugs from the public...?

[13:27:24.0000] <zcorpan>
or searchObject

[13:27:51.0000] <zcorpan>
like srcObject

[13:28:03.0000] <annevk>
Hixie_: I think so, but the registration system is broken or some such

[13:28:17.0000] <annevk>
Hixie_: at least, lots of people have had problems with it thus far

[13:28:28.0000] <annevk>
Hixie_: they should maybe just stop bothering and outsource to W3C like we did

[13:28:38.0000] <Hixie_>
ah ok

[13:28:52.0000] <Hixie_>
do you know Allen's e-mail?

[13:29:07.0000] <annevk>
pm'd

[13:31:06.0000] <Hixie_>
thanks

[13:31:38.0000] <zcorpan>
W3C - administrating other standards organizations' bugzillas to their full potential

[13:39:08.0000] <Domenic_>
annevk: I kind of like searchObj?

[13:39:57.0000] <annevk>
zcorpan: is srcObject what <video> has these days?

[13:40:36.0000] <annevk>
or HTMLMediaElement I suppose

[13:40:36.0000] <annevk>
suddenly rain

[13:40:47.0000] <zcorpan>
annevk: i think it was proposed but is not in the spec yet

[13:41:11.0000] <zcorpan>
so we could call that srcObj if we like

[13:41:46.0000] <annevk>
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#direct-assignment-to-media-elements

[13:42:31.0000] <zcorpan>
oh

[13:42:55.0000] <Domenic_>
I feel like there must be a brilliant bikeshed color here waiting to be discovered (for the property formerly known as query).

[13:43:48.0000] <annevk>
zcorpan: we could ask for srcObj; precedent has srcdoc, srclang

[13:45:18.0000] <zcorpan>
i don't see srcObject implemented on video or source in blink or gecko

[13:45:39.0000] <annevk>
zcorpan: emailed

[13:50:42.0000] <annevk>
roc: you want a wiki account?

[14:05:15.0000] <roc>
um

[14:05:16.0000] <roc>
sure

[14:05:37.0000] <roc>
zcorpan: Gecko has mozSrcObject

[14:06:49.0000] <zcorpan>
when will you stop with these prefixes? :-P

[14:07:55.0000] <Domenic_>
annevk: some guy on Twitter says "queryComponent" "since this is what the RFC uses"

[14:08:42.0000] <annevk>
Domenic_: meh, https://tools.ietf.org/html/rfc3986#section-3.4

[14:08:55.0000] <annevk>
Also, "the RFC" is obsoleted by this standard, so...

[14:09:55.0000] <Domenic_>
ya

[14:10:16.0000] <Domenic_>
queryPairs?

[14:10:47.0000] <annevk>
I think I start liking queryObj more... but I guess we can give it some time.

[14:11:03.0000] <annevk>
Or only expose .query on URL objects. That's another option.

[14:11:20.0000] <Domenic_>
seems sad, poor HTMLAnchorElements

[14:11:41.0000] <annevk>
Yeah, and you kinda want it for window.location too which would require more weirdness...

[14:11:59.0000] <annevk>
And I don't think we want to rename ParentNode#query

[14:12:04.0000] <annevk>
So yeah, searchObj

[14:13:13.0000] <Domenic_>
yeah seems fine to me, only slightly awkward

[14:13:39.0000] <zcorpan>
i see no relevant actual instances of srcObject or mozSrcObject in webdevdata (june dataset)

[14:14:02.0000] <Domenic_>
queryPairs?

[14:16:15.0000] <roc>
zcorpan: we have stopped, mostly, but this is quite old

[14:16:27.0000] <zcorpan>
ok

[14:17:27.0000] <annevk>
Suggested renaming in http://lists.w3.org/Archives/Public/public-media-capture/2013Oct/0121.html btw

[14:22:06.0000] <zcorpan>
sigh... https://www.w3.org/Bugs/Public/show_bug.cgi?id=23596

[14:35:53.0000] <Domenic_>
queryParams

[14:44:32.0000] <zcorpan>
Hixie_: also in regexp literals

[15:02:40.0000] <Hixie_>
zcorpan: ta

[15:12:37.0000] <matjas>
Hixie_: seems a bit unmaintainable to hardcode all the cases where it needs to be escaped… can’t you just say it should always be escaped?

[15:14:20.0000] <Hixie_>
can you escape it in the case of "if (3 < 4)" ?

[15:14:54.0000] <matjas>
Hixie_: only in X(HTML)… but you could just say escape it whenever it’s followed by "/script"

[15:15:12.0000] <Hixie_>
i already said that earlier in the sentence

[15:15:15.0000] <zcorpan>
if ( 3<script ) is also problematic though

[15:15:51.0000] <Hixie_>
hm, yeah, that means escaping < is a non-starter

[15:15:52.0000] <matjas>
Hixie_: this can also happen in a property name literal in an object literal (those are like a string) or in ES6 template literals etc. etc.

[15:16:09.0000] <Hixie_>
what's a "property name literal"?

[15:16:37.0000] <matjas>
the `'foo'` in `var x = { 'foo': 42 }` is represented by a `Literal` in the AST

[15:16:48.0000] <Hixie_>
isn't that just a string?

[15:16:55.0000] <matjas>
not really

[15:16:59.0000] <Hixie_>
how does it differ?

[15:17:31.0000] <matjas>
Hixie_: string literals can be replaced with a reference to a variable. in this case that’s not possible

[15:17:41.0000] <matjas>
but this was just an example

[15:18:38.0000] <Hixie_>
well sure, but a string literal isn't a variable

[15:18:39.0000] <matjas>
listing all the different cases where escaping is needed seems like a maintainability burden

[15:18:41.0000] <Hixie_>
it's a string literal

[15:19:10.0000] <Hixie_>
you can use a string literal in an expression or where you need a property name literal, no?

[15:19:14.0000] <Hixie_>
i mean, aren't they both strings?

[15:19:27.0000] <Hixie_>
anyway it's academic, as zcorpan says, it won't work anyway

[15:26:33.0000] <matjas>
in the `3<script` case, adding a space after `<` could be considered as “escaping”

[15:27:51.0000] <Hixie_>
<!-- is never valid JS, right?

[15:27:59.0000] <Hixie_>
so so long as you always escape it, you'll always be fine.

[15:28:07.0000] <Hixie_>
same with </script>

[15:28:18.0000] <Hixie_>
which is what the spec already suggests

[15:29:03.0000] <Hixie_>
(though i guess the same could be said for the other case...)

[15:29:06.0000] <Hixie_>
(bah)

[15:31:29.0000] <Hixie_>
why on earth does 'input' not apply to type=radio, checkbox, and file? anyone know?

[15:39:41.0000] <matjas>
Hixie_: <!-- is a singlelinecomment in JS http://javascript.spec.whatwg.org/#comment-syntax

[16:05:49.0000] <zewt>
matjas: that's an impressively concise piece of insanity

[16:27:00.0000] <zewt>
annoyed at having to say "xxx-related use cases" instead of "xxx use cases" Every Single Time, or some dictionary lawyer immediately jumps out of a bush going THAT'S NOT A USE CASE


2013-10-23
[17:27:01.0000] <Hixie_>
zewt: how does "-related" help with that?

[17:28:43.0000] <zewt>
"randomProposal()-related use cases" meaning "the use cases that randomProposal() addresses"

[17:29:14.0000] <zewt>
sometimes just feels like i'm talking to a room of lawyers :)

[17:29:58.0000] <Hixie_>
i don't undrstand the difference between "randomProposal()-related use cases" and randomProposal() use cases" but ok :-)

[20:46:38.0000] <zewt>
<social> element? sounds like a subject of an onion article

[23:15:34.0000] <MikeSmith>
zewt: where that come from ?

[23:53:15.0000] <MikeSmith>
Hixie_: good trolling with your sockpuppet <social> proposal

[23:53:19.0000] <MikeSmith>
well played

[01:09:21.0000] <zcorpan>
<!-- could be valid JS if it wasn't for being a line comment. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2582

[01:10:35.0000] <zcorpan>
Hixie_: </script> also http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2583

[01:34:41.0000] <zcorpan>
can we make the name getter on HTMLCollection throw or return null for out-of-document trees?

[01:35:39.0000] <zcorpan>
or on elements

[01:42:09.0000] <Ms2ger>
Mm

[01:53:36.0000] <zcorpan>
maybe throw and null are both bad options; being undefined/not present probably

[02:27:01.0000] <Ms2ger>
Lachy, congratulations, btw

[02:27:12.0000] <Lachy>
thanks :-)

[02:28:48.0000] <annevk>
"None of this is an excuse for the W3C selling its soul, of course."

[02:29:08.0000] <Ms2ger>
It had one?

[02:35:35.0000] <karlcow>
MS2ger: Exactly.

[02:36:01.0000] <annevk>
zcorpan: I'm not sure why we want to change the named getter algorithm to forbid certain scenarios. Could you elaborate?

[02:36:21.0000] <karlcow>
no organization has a soul. It frightens mean each time, people try to do anthropomorphism with social entities outside of a poetic license

[02:37:18.0000] <annevk>
You need a poetic license these days to write nice things?

[02:37:29.0000] <annevk>
Seems pretty clear what Brendan meant.

[02:37:46.0000] <karlcow>
annevk: and I disagree.

[02:38:46.0000] <karlcow>
It's a rhetorical way for polarizing the debate, which doesn't help.

[02:39:49.0000] <karlcow>
it's like saying Opera, Mozilla, Microsoft have a soul. Same. Exact same. They have interests, a set of described values (sometimes).

[02:48:37.0000] <foolip>
annevk, where was that quote from?

[02:48:58.0000] <foolip>
Lachy, congratulations! (what am I congratulating you about?)

[02:49:21.0000] <annevk>
foolip: mozilla.dev.planning

[02:49:53.0000] <Lachy>
foolip, https://twitter.com/Lachy/status/390431332766982144

[02:50:22.0000] <foolip>
Lachy, congratulations indeed!

[02:50:23.0000] <Lachy>
I was on holiday in the Maldives last week

[02:52:05.0000] <jgraham>
Lachy: You should have waited 24 days

[02:55:04.0000] <jgraham>
karlcow: I don't think people have souls either, but it doesn't mean that I can't understand what is meant when they are mentioned

[02:56:35.0000] <Lachy>
jgraham, we're having the engagement party on the 9 November. That is day 1024.

[02:56:53.0000] <karlcow>
jgraham: ;) I think I agree with the first part. I still disagree with the second. What $ORG is doing is part of its constituencies, it evolves with what the constituency is made of. :)

[02:57:38.0000] <annevk>
Nah, it also depends on leadership. The patent policy happened over the dead body of some members.

[02:58:10.0000] <annevk>
The whole "W3C is not responsible for anything" spiel is a half-truth.

[02:58:34.0000] <Ms2ger>
It's not responsible for anything good? ;)

[03:01:05.0000] <jgraham>
karlcow: Even if you believe that (which I think I don't), W3C is still free to choose its constituents

[03:02:36.0000] <karlcow>
annevk: agreed about leadership.

[03:02:50.0000] <karlcow>
I never said W3C was not responsible either.

[03:03:09.0000] <karlcow>
Mozilla, Microsoft, and Google are responsible for their actions too.

[03:03:12.0000] <karlcow>
:)

[03:04:34.0000] <karlcow>
but we may have a different idea of what you put in "W3C" when we say the letters.

[03:06:21.0000] <jgraham>
Anyone know anything about London JS Conf?

[03:07:41.0000] <jgraham>
Like, is it something that has happened before? How big is it?

[03:31:57.0000] <annevk>
MikeSmith: https://groups.google.com/a/chromium.org/d/msg/blink-dev/yujPcy889e4/0GN9eNO4koAJ

[03:32:18.0000] <annevk>
(Rant by Kornel about AWebP. It's nice.)

[03:38:52.0000] <MikeSmith>
annevk: thanks

[03:39:04.0000] <MikeSmith>
yeah, classic kornel

[03:43:14.0000] <karlcow>
oh and agreed with Henri on this one http://lists.w3.org/Archives/Public/www-tag/2013Oct/0052.html

[04:00:56.0000] <MikeSmith>
karlcow: I think one thing we can all agree on is that http://twoproblems.com/ is good for the Web

[04:01:50.0000] <MikeSmith>
and that porneL should be made Minister of Education

[04:02:13.0000] <annevk>
'Some people, when confronted with a problem, think "I know, I'll check teh interwebs for teh codez" Now they have two videos of cats.'

[04:02:16.0000] <annevk>
All the time...

[04:40:32.0000] <zcorpan>
Lachy: congrats! what happens on day 1,000,000?

[04:45:07.0000] <zcorpan>
annevk: i thought the objection to Element.getElementsByTagName was that HTMLCollection has a named getter and it has bad perf in such cases.

[05:19:12.0000] <annevk>
zcorpan: the objection is that HTMLCollection is a terrible API

[05:19:29.0000] <zcorpan>
ok

[07:26:45.0000] <SimonSapin>
jgraham: to test selectors, do you think it makes more sense to have reftest with a green square, or something JS-based?

[07:27:31.0000] <jgraham>
SimonSapin: js-based I would have thought

[07:27:49.0000] <jgraham>
It should be much faster to run, since you can test lots of things on a single page

[07:28:21.0000] <jgraham>
(it does mean that it depends on js ofc, but even Servo is getting to the point where that's acceptable :)

[07:28:45.0000] <darobin>
oh please js-based

[07:28:53.0000] <darobin>
green squares must die, if at all possible

[07:29:07.0000] <jgraham>
Poor green squares :(

[07:29:39.0000] <jgraham>
If you are testing rendering, green squares are good

[07:30:00.0000] <jgraham>
But if you are just testing selector matching, that doesn't really depend on rendering

[07:30:44.0000] <darobin>
yeah yeah I know

[08:12:52.0000] <SimonSapin>
js-based means cssselect is out :/

[08:13:01.0000] <SimonSapin>
(and by extension WeasyPrint)

[08:13:56.0000] <SimonSapin>
or it could be a JS harness that uses text/json/whatever static data

[08:13:56.0000] <jgraham>
But it does mean everyone else gets a factor of 100 in runtime or something

[08:14:07.0000] <jgraham>
Sure

[08:14:58.0000] <jgraham>
querySelector[All] already has tests, if that helps

[08:15:12.0000] <darobin>
in fact that's even a very good idea, since if needed you could just generate a lot of green squares from it

[08:16:05.0000] <SimonSapin>
jgraham: https://github.com/w3c/web-platform-tests/tree/master/selectors-api ? Interesting

[08:16:25.0000] <Ms2ger>
/me needs to poke Servo some more

[08:18:15.0000] <SimonSapin>
jgraham: are these based on testharness.js?

[08:19:08.0000] <Ms2ger>
/me clicks on one

[08:19:09.0000] <Ms2ger>
Yes

[08:20:10.0000] <zcorpan>
jgraham: what does ^M mean in https://critic.hoppipolla.co.uk/showfile?sha1=4536ea21c7f33904626e6e72a06c2a59dc499f51&path=cors/resources/cors-headers.asis&review=368 ?

[08:20:23.0000] <jgraham>
See also:         self.assertEquals("Some Status", resp.msg) self.assertEquals("test-value", resp.info()["test-header"])

[08:20:28.0000] <jgraham>
Sigh

[08:20:37.0000] <jgraham>
See also: http://w3c-test.org/web-platform-tests/master/selectors-api/level1-baseline.html

[08:20:43.0000] <jgraham>
SimonSapin: ^

[08:20:53.0000] <jgraham>
zcorpan: It's a CR, I hope]

[08:22:19.0000] <zcorpan>
ah, that makes sense. first line should have that also, right?

[08:22:59.0000] <jgraham>
Yeah, good point

[08:23:35.0000] <zcorpan>
/me adds an issue

[08:25:44.0000] <jgraham>
Probably also need to ensure that the repo is configured not to touch line endings

[08:26:50.0000] <Ms2ger>
jgraham, took me a while to figure out you didn't mean CR :)

[08:28:10.0000] <jgraham>
I did mean CR :p

[08:59:09.0000] <jgraham>
Oh joy. longdesc tests. I wonder what happens if I reject them all on the basis that they're not in the spec.

[08:59:51.0000] <jgraham>
Oh, I guess they don't claim to be

[09:05:01.0000] <zcorpan>
© chaals

[09:05:38.0000] <gsnedders>
jgraham: Approve them, on grounds that you can then mark them at risk due to implementation lack.

[09:25:26.0000] <annevk>
Pretty sure I commented on <iframe>'s weird loading model before. An error event for 4xx would never fly...

[09:26:02.0000] <jgraham>
Hmm, I wonder if the © is actually a problem

[09:26:40.0000] <annevk>
However, I don't think we have ever defined that "http://test:test/" and "http://test.invalid/" should give different results for <iframe>...

[10:54:33.0000] <dglazkov>
good morning, Whatwg!

[13:26:40.0000] <Hixie_>
i don't understand the w3c bugzilla

[13:26:52.0000] <Hixie_>
i do a search, i walk down the bugs in that search one by one, and sometimes, i end up on a bug that isn't in the search

[13:26:59.0000] <Hixie_>
it's like it gets confused as to which bug list i'm looking at

[13:37:53.0000] <foxtrotwhiskey>
Are you doing multiple searches while paging through one list? I think it only works right on your most recent search.

[13:40:00.0000] <Hixie_>
i'm definitely doing multiple searches, but this is happening without intevening searches.

[13:40:34.0000] <Hixie_>
like, search, search, search, open bug, submit, submit, next, next, submit, woah, what bug is this

[14:04:56.0000] <Hixie_>
annevk: so what's the story on https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296 ? (microtasks)

[14:33:58.0000] <annevk>
Hixie_: wycats wants a model that he has found works well for systems such as ember.js; Rafael questions whether that model is always better and worth the added complexity

[14:34:55.0000] <annevk>
Hixie_: note that Rafael would like wycats to be correct, as he's trying to address the same kind of use cases

[14:38:51.0000] <jgraham>
Hixie_: presumably W3C bugzilla is required to show you a random selection of bugs to better reflect the interests of the Member organisations

[14:41:41.0000] <Hixie_>
annevk: so should i be making changes?

[14:42:15.0000] <annevk>
Hixie_: so... I recommend pinging rafaelw

[14:42:21.0000] <Hixie_>
rafaelw: ping

[14:43:20.0000] <annevk>
Hixie_: it's starting to become somewhat important now promises and Object.observe() are closer to shipping

[14:44:01.0000] <annevk>
Hixie_: so how they queue relative to mutation observer stuff will become observable and we'll have to figure out a story here

[14:45:14.0000] <Hixie_>
annevk: agreed, i just don't know what i should be speccing

[15:16:26.0000] <Hixie_>
gsnedders: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22818


2013-10-24
[18:55:01.0000] <GPHemsley>
Hixie_, et al.: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#events-mouseevent-event-order

[18:55:23.0000] <GPHemsley>
(mouse event order is now specified)

[18:59:35.0000] <GPHemsley>
relevant changesets:

[18:59:35.0000] <GPHemsley>
https://dvcs.w3.org/hg/dom3events/rev/42b609150da6

[18:59:51.0000] <GPHemsley>
https://dvcs.w3.org/hg/dom3events/rev/709178ecd5fb

[20:52:28.0000] <Hixie_>
GPHemsley: have we given up trying to get them to spec it in actual spec style?

[20:53:31.0000] <Hixie_>
GPHemsley: as opposed to basically by vague example, which is what that is

[21:07:34.0000] <zewt>
Hixie_: "Implementations MUST implement an API compatible with one another." all specs solved

[00:07:03.0000] <Ms2ger>
annevk-cloud, a question... Is it safe to replace if (a) { foo.classList.add("x") } else { foo.classList.remove("x") } with foo.classList.toggle("x", a)?

[00:31:55.0000] <MikeSmith>
Ms2ger: I'm looking forward to seeing the response you get to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23532#c29

[00:32:28.0000] <Ms2ger>
Maybe it's safer if I don't read the response :)

[00:35:34.0000] <MikeSmith>
heh

[01:21:59.0000] <jgraham>
Yeah, I see Ms2ger is wearing his flame-retardant pants this morning

[01:23:27.0000] <zcorpan>
logic <http://www.w3.org/mid/CALzNm5qDrPt+_AgPrYfn_c3jjcZN8drkAxE6UF8L0XCbM504xg⊙mgc>

[01:23:46.0000] <Ms2ger>
zcorpan, /topic

[01:24:39.0000] <jgraham>
<doubletake>

[01:25:33.0000] <Ms2ger>
<x-doubletake>

[01:38:01.0000] <MikeSmith>
"data-* attributes are not parsed." https://lists.webkit.org/pipermail/webkit-dev/2013-October/025775.html

[01:39:52.0000] <MikeSmith>
saying src-N doesn't present any new problems because we've already data-* is like the fallacy of saying <picture><source> doesn't present any new problems because we already have <video><source>

[01:43:57.0000] <MikeSmith>
with that, I'll trot my hobbyhorse back to the stable and take a short j break

[01:48:16.0000] <zcorpan>
of course blink doesn't match gecko for img.x. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2590

[01:53:06.0000] <zcorpan>
hmm. not sure how to get a non-zero value in blink

[01:58:23.0000] <zcorpan>
oh, it returns 0 if the image isn't rendered when the script runs

[02:00:03.0000] <Ms2ger>
That seems plausible

[02:00:50.0000] <zcorpan>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/HTMLImageElement.cpp&type=cs&l=331

[02:05:09.0000] <zcorpan>
http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLImageElement.cpp#143

[02:07:24.0000] <zcorpan>
gecko seems to do a layout first

[02:12:03.0000] <zcorpan>
Hixie_: can you add a delayed-style to domviewer?

[02:30:09.0000] <zcorpan>
Hixie_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23610 i think it doesn't work that way. expecting screen readers to not use screen media is as bad idea as expecting handheld devices to not use screen media

[02:31:00.0000] <zcorpan>
'handheld' and 'tv' media are dead

[02:37:55.0000] <Ms2ger>
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0248.html

[02:39:18.0000] <wilhelm>
zcorpan: Indeed. I only use "@media (min-width: 900px)"  and the like today, even without screen specified. Oh, and @media print.

[02:40:53.0000] <zcorpan>
wilhelm: what *you* use is irrelevant :-) what UAs do is to have two mutually exclusive media, 'screen' and 'print'

[02:40:57.0000] <annevk>
Ms2ger: does if(x) do ToBoolean(x)?

[02:41:07.0000] <annevk>
Ms2ger: if so, I suspect them to be identical, yes

[02:41:11.0000] <Ms2ger>
I assume so

[02:41:25.0000] <Ms2ger>
annevk, how about a===undefined?

[02:42:24.0000] <annevk>
Ms2ger: hah

[02:43:59.0000] <Ms2ger>
annevk, not at all surprising, right? :)

[02:50:21.0000] <Marcos>
I want to ask this to the room generally, it's more or less a quick question. In terms of spec (or at least, conceptually in some way) is there any reason why, in HTML, the body element's, or the html element's default/minimum size isn't the size of the viewport? I mean, it's easier, from the developer's perspective to make it/content translucent so that it doesn't fill to the viewport if desired than it is to make it such that co

[02:50:22.0000] <Marcos>
ntent DOES stretch to the viewport, right?

[02:50:24.0000] <webben>
zcorpan: I think Hixie_ conflates a non-visual browser and a system screen reader in an impractical way.

[02:52:19.0000] <annevk>
Marcos: other than using some weird table magic and maybe now with flexbox there was no way to describe that before

[02:56:24.0000] <Marcos>
... given that the viewport exists (and is otherwise white) whether or not the content fills it, what I'm probably saying is that the root element of a document should BE the viewport. Outside of it being defined by the document author, I see no advantage of the reverse. It's /sort of/ required in order to make pages display on all screens appropriately, (up to infinitely sized should probably be done, given the unpredictability)

[02:56:24.0000] <Marcos>
I've never seen a website which intentionally didn't take up the viewport with w/e background it had.

[02:56:57.0000] <jgraham>
Marcos: Surely annevk or Hixie_ has one that does that :)

[02:57:10.0000] <jgraham>
It's the law of little-known web featurs

[02:57:12.0000] <jgraham>
*features

[02:57:50.0000] <Marcos>
I realise that NOW it might be hard to change, whilst maintaining backward compability, this is a hypothetical.

[02:57:53.0000] <annevk>
Marcos: do you mean viewport or canvas?

[02:58:12.0000] <Ms2ger>
Or SVG?

[02:58:24.0000] <Marcos>
Well, that depends on how we define canvas, annek.

[02:58:43.0000] <annevk>
Marcos: per its CSS definition

[02:59:01.0000] <annevk>
Ms2ger: :p

[02:59:14.0000] <Ms2ger>
/me should do something useful

[02:59:30.0000] <Marcos>
That's not something I've seen myself, annevk. I

[02:59:52.0000] <Marcos>
am not the type to read every word ever written about sotfware that I use.

[03:00:27.0000] <Ms2ger>
Good

[03:00:31.0000] <Marcos>
Addmittedly, the issue is that I find the process of drawing the line between what is and isn't superflous exausting.

[03:00:35.0000] <Ms2ger>
A lot of the words written are nonsense :)

[03:00:55.0000] <Marcos>
So, you'll have to link me, annek

[03:01:19.0000] <annevk>
Marcos: if you don't understand the distinction it's kinda hard to go into hypotheticals

[03:01:31.0000] <Marcos>
It

[03:02:17.0000] <Marcos>
isn't that I don't understand it, it's that I go into too many hypertheticals when thinking about it, until there's too much to concentrate on.

[03:03:59.0000] <Marcos>
I generally only look up what I need to do what I'm doing, any further than that requires knowing what I willl do in future definitively.

[03:04:51.0000] <Marcos>
The point is that I've never seen anything that directed me toward the "css definition" of canvas.

[03:05:23.0000] <Marcos>
It sounds like it's some 9001 page preamble somewhere.

[03:08:11.0000] <Marcos>
Which version of CSS defines "canvas" in it's terminology?

[03:08:42.0000] <Ms2ger>
http://www.w3.org/TR/CSS21/intro.html#canvas

[03:10:59.0000] <Marcos>
okay, annevk, according to that page, the canvas is infinite, so, neither

[03:12:19.0000] <Marcos>
I am reffering to the area enclosing any rendered content, to infinite precision

[03:13:23.0000] <annevk>
Yeah, but what if you have something absolutely positioned with bottom:-5px?

[03:13:56.0000] <annevk>
In any event, that's not the viewport. You can actually size something to be the viewport these days quite easily. With "height:100vh; width:100vw"

[03:14:24.0000] <Ms2ger>
Or 1vh/1vw?

[03:15:02.0000] <Marcos>
"vh", "vw" are these implimented dimensions?

[03:15:31.0000] <annevk>
Ms2ger: no, for some reason they decided to divide by 100

[03:15:56.0000] <Ms2ger>
annevk, I guess that must be 100 times better

[03:17:00.0000] <Marcos>
And if you have an absolutely positioned bottom:-5px, unless it's inside a container that's been made  non-static, it would, display be extending the canvas.

[03:17:46.0000] <Marcos>
In fact, absolutely positioned objects behave as I would want to body tag to.

[03:17:47.0000] <Marcos>
>_>

[03:18:00.0000] <Marcos>
Sort of,

[03:19:23.0000] <annevk>
I recommend studying CSS a bit more rather than wondering how it could be different ;-)

[03:19:31.0000] <Marcos>
It's not functionality I can't produce, it's more that it's something a lot of websites overlook.

[03:19:56.0000] <Marcos>
I produce it perfectly well, that's not the issue.

[03:21:54.0000] <Marcos>
It's more that I would have thought that wanting to have the main background minimum sized to the viewport would be more common than not, so I'm wondering why the default is the way it is, I was hoping there was a practical reason I'd overlooked.

[03:22:14.0000] <Marcos>
I may also be too exhausted to convey my thoughts, which happens a lot.

[03:30:19.0000] <Marcos>
Lets try this: if I have a page, containing only the body, head, etc. The body tag has a blue background, and a single 50x50 div, black background, absolutely positioned, bottom:-5px;. Why would it be assumed that I want this white bar below it? https://dl.dropboxusercontent.com/u/37122446/Capture.PNG

[03:30:39.0000] <Marcos>
annevk?

[03:34:26.0000] <annevk>
Marcos: seems like a browser bug

[03:34:55.0000] <annevk>
Marcos: background on <body> puts it on the canvas (unless you have a background on <html>) so you cannot see white anywhere

[03:35:19.0000] <Marcos>
Ah, so it IS supposed to do that.

[03:36:07.0000] <Marcos>
It occurs cross browser though, I could have sworn

[03:36:21.0000] <annevk>
No it doesn't

[03:38:11.0000] <Marcos>
hold on, I'll upload something I had from class,

[03:40:38.0000] <Marcos>
https://dl.dropboxusercontent.com/u/37122446/temp2/w8/airline.xml

[03:42:03.0000] <Marcos>
background-size:cover; covers only content on the page in ff, chrome and ie

[03:42:08.0000] <annevk>
Marcos: in XML you need to style the <html> element

[03:42:51.0000] <Marcos>
As in, put the background on there?

[03:42:56.0000] <Marcos>
because I've tried that

[03:43:24.0000] <annevk>
Marcos: oh no it's not that

[03:43:33.0000] <annevk>
Marcos: you put a gradient there

[03:43:53.0000] <Marcos>
so?

[03:44:07.0000] <annevk>
Marcos: gradients are images, and won't stretch over the canvas, because the canvas is infinite

[03:44:36.0000] <annevk>
Marcos: in any event, for further questions please find someone else or go to stackoverflow.com

[03:44:53.0000] <annevk>
Marcos: I'm supposed to be writing standards, not help students with their homework

[03:46:50.0000] <Marcos>
It's not homework, it's a question about the standards, but you've given me a lot of time, and actually brought some light to the issue for me, so thank you.

[03:47:28.0000] <Marcos>
If the canvas is by default infinite, that does cause problems.

[03:48:04.0000] <Marcos>
It really doesn't have any bearing on school work or anything, it's just a peeve I have, lol.

[03:48:10.0000] <Marcos>
Anyway, bye.

[04:22:18.0000] <zcorpan>
annevk: no, background on body applies to canvas in xhtml also

[04:49:41.0000] <jgraham>
Hmm, looks like bratell misunderstood the internet. imgur is for cats/"memes"

[06:09:35.0000] <annevk>
zcorpan: I know

[06:13:56.0000] <zcorpan>
annevk: ok, the "in XML you need to style the <html> element" comment was what i responded to, i didn't look at the page

[06:14:18.0000] <annevk>
zcorpan: yeah, I retracted that a statement later

[06:14:31.0000] <annevk>
I guess I could have been clearer

[06:18:40.0000] <GPHemsley>
Hixie_: As I recall, there was more support for fixing the W3C spec than starting a new one. I may be wrong.

[06:21:02.0000] <annevk>
GPHemsley: you cannot really fix something inherently broken though

[06:21:25.0000] <GPHemsley>
annevk: I though you were the one suggesting it... :/

[06:21:27.0000] <GPHemsley>
+t

[06:21:45.0000] <GPHemsley>
/me shrugs

[06:22:49.0000] <annevk>
GPHemsley: I think my suggestion has always been to write a lot of tests, write down the optimal model supported by those tests and legacy constraints, write the API requirements around that model, write new tests, get implementations fixed, etc.

[06:25:24.0000] <jgraham>
Yes, fixing events is a lot of work, and no one seems to want to put in the hours

[06:25:48.0000] <jgraham>
e.g. http://i.imgur.com/039VHDk.png is just for the click event on links

[06:26:52.0000] <jgraham>
Then you have to work out which of those bewhaviours forms the sanest compatible subset, and specify that

[06:27:18.0000] <jgraham>
and also get implementors on board with changing their browser in a potentially dark-matter affecting way

[06:29:28.0000] <GPHemsley>
/me wonders who is testing Minefield in 2013.

[06:30:41.0000] <annevk>
I was. Until I got a new laptop in Feb at which point I downloaded Nightly.app. Before that it was called Minefield.app though otherwise identical.

[06:32:52.0000] <jgraham>
Right, it can locally be called "Minefield" even though that's not the name any more

[06:33:11.0000] <jgraham>
The point is that it's the 2013-08-20 nightly build

[06:36:43.0000] <GPHemsley>
/me shrugs again

[06:37:32.0000] <annevk>
GPHemsley: you should get that looked at

[06:37:55.0000] <GPHemsley>
/me was hoping you were already looking at his shrugs

[06:40:35.0000] <GPHemsley>
But anyway, the point of my shrugs is that I'm just reporting my observations; I'm not qualified to do much analysis, I don't think.

[06:44:33.0000] <annevk>
Is there a way to get a raw diff out of GitHub?

[06:45:28.0000] <MikeSmith>
.diff

[06:46:05.0000] <MikeSmith>
appended to a commit URL

[06:46:37.0000] <jgraham>
The great thing about github is the super-intuitive UI

[06:46:53.0000] <MikeSmith>
yes!

[06:46:58.0000] <MikeSmith>
like Critic :)

[06:47:36.0000] <jgraham>
I don't think that's ever a claim anyone made though :)

[06:52:01.0000] <zcorpan>
does ie11 support img.x ?

[06:52:24.0000] <zcorpan>
ie11 in browserstack doesn't seem to like live dom viewer

[07:11:19.0000] <Hixie_>
zcorpan: (re media) agreed about handheld and tv, we should fix that. screen readers are basically an artefact of not having real aural browsers, though. anyway my real point in hat bug was the second part, not he first.

[07:12:07.0000] <Hixie_>
GPHemsley: for which spec?

[07:12:44.0000] <GPHemsley>
Hixie_: The DOM3/mouse events

[07:12:58.0000] <GPHemsley>
but apparently I am misremembering

[07:14:09.0000] <Hixie_>
GPHemsley: ah, well, depends support from whom

[07:14:12.0000] <Hixie_>
GPHemsley: :-)

[07:14:20.0000] <Hixie_>
GPHemsley: only person who matters is the one writing the spec, really

[07:22:56.0000] <zcorpan>
hmm, blink doesn't have scroll() or scrollY?

[07:24:49.0000] <zcorpan>
seems like img.x / y is just relative to the ICB always

[07:33:15.0000] <matjas>
annevk: is there more to “grapheme clusters” than just combining marks?

[07:34:02.0000] <annevk>
matjas: I don't actually know in detail, but it does seem that you always want to operate on grapheme clusters if you are dealing with text

[07:34:46.0000] <jgraham>
Depends what you mean "dealing with"

[07:34:55.0000] <annevk>
matjas: you don't want to lose the diaeresis of that n

[07:42:54.0000] <Hixie_>
zcorpan: thanks so much for taking that bug

[07:43:17.0000] <Ms2ger>
^

[07:43:58.0000] <zcorpan>
Hixie_: np

[07:46:58.0000] <annevk>
matjas: so the answer is no

[07:51:53.0000] <annevk>
matjas: http://www.unicode.org/reports/tr29/#Regular_Expressions and the next section are somewhat interesting

[07:54:04.0000] <zcorpan>
there, x/y specified

[07:55:47.0000] <GPHemsley>
¨n or ñ ?

[08:19:56.0000] <annevk>
So we have Response objects. They're cool. But how do we indicate that for most responses Set-Cookie / Set-Cookie2 are not exposed. And for CORS responses anything but a whitelist is exposed?

[08:20:20.0000] <annevk>
Create some kind of visor concept that is returned instead?

[08:21:02.0000] <annevk>
With a wormhole option if you're feeling adventurous?

[08:26:00.0000] <jgraham>
annevk: Your mixed mataphors are not making things clear :)

[08:28:52.0000] <annevk>
jgraham: basically I need a way where APIs such as XMLHttpRequest do the right thing by default but internal callers such as "basic fetch" can still get access to the full response

[08:29:30.0000] <annevk>
"basic fetch" will want to see any Location headers, but XMLHttpRequest is not allowed by default for a cross-origin response.

[08:30:36.0000] <annevk>
I could of course move the logic to XMLHttpRequest, but then we'll hit the same problem with ServiceWorker and fetch(), etc.

[08:49:44.0000] <annevk>
I guess I should just describe the "visor" semantics and invent a new term, "actual" that when used passes through the "visor". E.g. location is null, but actual location could be something...

[09:14:23.0000] <annevk>
Wait, custom elements is in LC?

[09:14:42.0000] <annevk>
With its monkey patching of createElement()... Crazy world.

[09:20:46.0000] <annevk>
jgraham: so we had "filtered response" and an associated "internal response", right?

[09:27:03.0000] <Ms2ger>
annevk, ahahaha LC

[09:27:54.0000] <jgraham>
annevk: Yes

[09:32:28.0000] <annevk>
Hmm, so no-backref does not work two parents up. Hixie_ would it be too expensive to make that recursive or at least check for two parents?

[09:33:08.0000] <annevk>
Hixie_: scenario is <div class="note no-backref"> <p> <span title=...> ... </span>

[09:35:33.0000] <annevk>
Hixie_: another problem is that you do .className != "no-backref" rather than !(...classList.has("no-backref)

[09:47:38.0000] <gsnedders>
Ms2ger: https://github.com/html5lib/html5lib-tests/pull/21

[09:47:40.0000] <gsnedders>
Ms2ger: kthxbai

[09:48:24.0000] <Ms2ger>
gsnedders, ah, whatever. Squash and land it

[09:50:38.0000] <MikeSmith>
I formally object

[09:50:44.0000] <gsnedders>
Too late.

[09:50:46.0000] <gsnedders>
Suck0rz.

[09:52:51.0000] <Domenic_>
Really impressed and excited by all the html5lib-tests and web-platform-tests work, btw. A half-year or so ago I was trying to find a good set of tests to run jsdom through and it was a mess. (Apparently the original author had run a PHP script to scrape some w3c site to get the original tests, and those were ... not very thorough.)

[09:53:15.0000] <Domenic_>
It leads to stuff like https://npmjs.org/package/parse5 which runs the parser tests against itself, which is pretty awesome.

[09:55:02.0000] <MikeSmith>
Domenic_: what parser does jsdom use? it's together in the same repo?

[09:55:26.0000] <Domenic_>
MikeSmith: no, it uses https://npmjs.org/package/htmlparser2, which is not very good. I want to switch to parse5.

[09:55:35.0000] <Domenic_>
Actually I want someone else to submit a pull request to switch us to parse5 :P

[09:57:09.0000] <MikeSmith>
/me is not familiar with either parse5 or htmlparser2

[09:57:36.0000] <MikeSmith>
last time I tried any HTML parsing it node was a long time ago

[09:57:37.0000] <gsnedders>
MikeSmith: https://github.com/html5lib/html5lib-tests/tree/master/validator is useless, I presume?

[09:57:40.0000] <MikeSmith>
and it was really slow

[09:57:57.0000] <MikeSmith>
gsnedders: no not completely useless

[09:57:59.0000] <gsnedders>
Domenic_: html5lib-tests is scarcely new. Almost nothing in it dates from the last couple of years

[09:58:22.0000] <Domenic_>
gsnedders: hmm did not really realize. i guess i was mostly excited about web-platform-tests then.

[09:58:50.0000] <annevk>
it wasn't on GitHub before, so out of mind

[10:00:26.0000] <jgraham>
Yes, web-platform-tests is a nice step forward for testing. But there are still *significant* steps that have to be taken before it fulfils its potential. In particular vendors have to both run and *write* tests for w-p-t as part of their normal CI/QA processes

[10:00:30.0000] <MikeSmith>
Domenic_: have you tried Aria Stewart's parser?

[10:00:52.0000] <hober>
https://github.com/aredridel/html5

[10:00:53.0000] <MikeSmith>
Domenic_: https://github.com/aredridel/html5

[10:00:58.0000] <Domenic_>
MikeSmith: I personally haven't but a lot of jsdom users have, yeah. My understanding is it's compliant but slow. And not sure if it's run the tests against itself?

[10:01:00.0000] <hober>
MikeSmith: :)

[10:01:01.0000] <MikeSmith>
hober: jinx

[10:01:28.0000] <MikeSmith>
Domenic_: last time I tried it, it was slow, yeah

[10:01:31.0000] <Domenic_>
jgraham: yes agreed. Similar issues for test-262. Apparently only Microsoft writes their tests in test-262 format.

[10:01:38.0000] <MikeSmith>
hober knows it better than me

[10:01:47.0000] <gsnedders>
Domenic_: Bigger problem with test262 is only ECMA members can contribute

[10:02:00.0000] <Domenic_>
gsnedders: well, but Ecma members can copy and paste CC0 licensed code.

[10:02:00.0000] <gsnedders>
Domenic_: And the format got changed to something stupid :(

[10:02:11.0000] <Ms2ger>
Which is why wpt also contains js tests

[10:02:48.0000] <Domenic_>
Decent parts of ES are moving to copy-and-paste CC0 stuff :P. Promises and maybe modules in ES6, and likely some test-262.

[10:03:57.0000] <gsnedders>
(The original format was one function per test, which is nice because you can just run it n times to check JIT behaviour)

[10:04:16.0000] <gsnedders>
(Probably breaking if the second run gives a different result to the first, when you assume it is stateful)

[10:06:21.0000] <gsnedders>
Domenic_: Also having to go via a proxy can be a sufficent obstruction to demotivate releasing stuff. I probably would've pushed to get Opera's stuff released long before I actually did if there was a decent chance of it getting into any worthwhile testsuite, instead of it merely be "well some Ecma member might be willing to spend the time to get it in".

[10:07:18.0000] <Domenic_>
gsnedders: that's fair. Hopefully there will be some Ecma licensing fights soon to clear things up.

[10:10:31.0000] <gsnedders>
(In the end I only did after Presto became a zombie, and all the easier testsuites to release had been. Was still just going to be a code dump given test262 still seemed a lofty goal. And then I got distracted by other things.)

[10:22:05.0000] <dglazkov>
good morning, Whatwg!~

[10:23:59.0000] <Hixie_>
annevk: should be on the element with the title="", no?

[10:24:19.0000] <annevk>
Hixie_: well, there's a bunch of those and they're all part of a note

[10:24:29.0000] <Hixie_>
ah

[10:26:04.0000] <Hixie_>
annevk: i added grandparent checks

[10:26:09.0000] <Hixie_>
and switched to classList

[10:26:18.0000] <annevk>
coolio

[10:26:19.0000] <Hixie_>
i don't want to walk the whole tree because that can be expensive

[10:26:28.0000] <Hixie_>
this runs on startup of the html spec across the entire dom

[10:26:31.0000] <Hixie_>
takes forever as it is

[10:26:36.0000] <annevk>
:-)

[10:27:26.0000] <Hixie_>
(i wish i had a better way to fix that)

[10:27:44.0000] <Hixie_>
(actually the status boxes are the main problem iirc)

[10:28:25.0000] <jgraham>
Well the status boxes are useless, so there's an easy fix there

[10:28:43.0000] <jgraham>
(I agree that in principle they are useful, but in practice they aren't)

[10:29:03.0000] <Hixie_>
i use the bug numbers all the time

[10:29:14.0000] <jgraham>
Ah, yeah, fair point

[10:29:24.0000] <Hixie_>
and i refer people to the status lines quite often

[10:29:25.0000] <jgraham>
It's the other parts that aren't useful

[10:29:30.0000] <Hixie_>
people who aren't deeply in the work here

[10:29:33.0000] <Hixie_>
not on the list, etc

[10:29:45.0000] <Hixie_>
i wish we had a better solution though

[10:31:01.0000] <jgraham>
Anything that says that "the a element" is "ready for first implementations" is broken to the point of uselessness

[10:31:14.0000] <jgraham>
Even the W3C allows you to implement <a>

[10:32:21.0000] <Hixie_>
heh

[10:32:23.0000] <Hixie_>
update it :-)

[10:32:37.0000] <Hixie_>
it was the new spec that was ready for first implementations

[10:32:47.0000] <Hixie_>
but yeah, i should probably go through and mark things as done

[10:32:56.0000] <annevk>
I'm loving this filtered response concept.

[10:34:20.0000] <jgraham>
Hixie_: Well of course we could update everything once, but unless someone actually keeps it up to date, it isn't that useful. And so far we have several years of evidence that no one wants to keep it up to date.

[10:35:17.0000] <Ms2ger>
We should get test links in there, though

[10:37:47.0000] <jgraham>
Ms2ger: Yeah, that might even work OK for HTML since the directory structure somewhat supports it

[10:45:45.0000] <hober>
Domenic_: MikeSmith: it's slow, but correct. i've mostly used it in static markup generation, where it doesn't really matter how fast it is

[10:55:41.0000] <Hixie_>
jgraham: if we updated it every few years, we'll still be keeping it more up to date than anyone else :-)

[10:55:52.0000] <Hixie_>
annevk: filtered response?

[10:56:46.0000] <jgraham>
Hixie_: Well less up to date than caniuse.com, for example. And mcuh less up to date than the relevant timescale of 6 weeks set by the browser cadence

[10:56:51.0000] <annevk>
for APIs such as XHR I want to hand them something where if they ask for the headers, Set-Cookie and Set-Cookie2 are already out

[10:57:05.0000] <annevk>
and if it's a CORS thing, only a certain set of headers are in

[10:57:33.0000] <Hixie_>
jgraham: yeah, we should probably remove the browser icons.

[10:57:41.0000] <Hixie_>
jgraham: they seem useless

[10:57:51.0000] <Hixie_>
jgraham: what we really should do is fine some way to propagate caniuse to them

[10:58:28.0000] <annevk>
and maybe http://www.chromestatus.com/features

[10:59:19.0000] <Hixie_>
i wonder what's a good way to do it

[10:59:27.0000] <Hixie_>
maybe we can put some attributes in the spec somehow

[10:59:35.0000] <Domenic_>
hober: do you know if it passes the test suite?

[10:59:35.0000] <Hixie_>
that identify the caniuse data or something

[11:00:07.0000] <Domenic_>
Hixie_: jgraham: yes please kill the browser icons, quite misleading. "Ready for first implementations" on features that already are everywhere confuses me massively.

[11:01:15.0000] <hober>
Domenic_: not offhand. i also don't know if it's up to date with the latest parser changes

[11:02:48.0000] <jgraham>
Hixie_: Well in the long term we should link the status icons to the test suite with zero tests or zero passes meaning "no implementation" and grab the test results from browser-provided data

[11:03:01.0000] <Hixie_>
i'd be good with that too

[11:03:15.0000] <Hixie_>
do we have anything resembling the infrastructure for that?

[11:03:58.0000] <jgraham>
No because as of today no one is running the tests

[11:04:00.0000] <Ms2ger>
That's jgraham's day job ;)

[11:05:41.0000] <jgraham>
But yes, this is part of the long term goal of what I'm trying to achieve

[11:05:57.0000] <Hixie_>
i'm basically happy to implement any of these ideas to make the boxes more useful

[11:06:06.0000] <Hixie_>
any or all

[11:06:21.0000] <Hixie_>
last i checked, i just didn't have the data

[11:06:32.0000] <jgraham>
Right, so that is the big problem

[11:07:00.0000] <jgraham>
But slowly, slowly we are getting to a world where you will have the data

[11:07:23.0000] <Ms2ger>
I believe "glacial pace" is the term you're looking for

[11:07:46.0000] <jgraham>
Aren't 90% of all glaciers retreating?

[11:08:02.0000] <jgraham>
That seems quite pessimistic :)

[11:09:25.0000] <Domenic_>
that is a pretty cool day job jgraham

[11:09:37.0000] <annevk>
jgraham: even by your standards?

[11:11:02.0000] <Ms2ger>
Domenic_, want to help? ;)

[11:11:16.0000] <jgraham>
Domenic_: To clarify it doesn't actually involve glaciers ;)

[11:11:47.0000] <jgraham>
But yes, working on public test infrastructure is cool

[11:34:19.0000] <Domenic_>
Wait what, XForms is still a thing? https://twitter.com/w3c/status/393437288702570496

[11:34:50.0000] <Ms2ger>
No

[11:35:44.0000] <Ms2ger>
/me considers going to ask that question

[11:36:03.0000] <Ms2ger>
Oh, he gave a talk called "Everything is XML, XML is Everywhere (we just couldn't know it)" yesterday

[11:38:52.0000] <smaug____>
I wouldn't be surprised if some insurance companies still used it

[11:39:32.0000] <smaug____>
and I think FF+Xforms addon was used in Germany in some hospitals ... for something

[13:57:33.0000] <Hixie_>
gsnedders: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22818

[13:57:55.0000] <Hixie_>
gsnedders: i'm marking it NEEDSINFO. Reopen if you can clarify it. https://www.w3.org/Bugs/Public/show_bug.cgi?id=22818

[14:22:27.0000] <gsnedders>
Hixie_: I'll look at it eventually!

[14:41:21.0000] <Hixie_>
gsnedders: k. you won't get more reminders from me though, because it's off my radar :-)

[14:43:05.0000] <gsnedders>
Hixie_: It's open in a tab now. It'll get dealt with at some point. :P

[14:43:13.0000] <Hixie_>
:-)


2013-10-25
[18:55:57.0000] <rniwa>
MikeSmith: hi

[18:56:05.0000] <rniwa>
Hixie_: yt?

[19:06:44.0000] <Hixie_>
rniwa: vaguely

[19:07:05.0000] <rniwa>
Hixie_: did you see my thread about async iframe load?

[19:07:24.0000] <rniwa>
Hixie_: I'd appreciate your help if could either clarify the currently spec'ed behavior

[19:07:47.0000] <rniwa>
Hixie_: or if you can change the spec to either one of existing behaviors (except sync behavior webkit/blink browsers exhibit)

[19:07:57.0000] <rniwa>
i.e. either IE or FF behavior

[20:17:28.0000] <zewt>
cool, youtube managed to break scrolling in chrome on macs

[20:17:37.0000] <zewt>
on the trackpad, anyway

[20:32:34.0000] <Hixie_>
rniwa: in whatwg@?

[20:33:56.0000] <Hixie_>
rniwa: i haven't looked in detail, but as far as i can tell, the last e-mail describes what the spec does?

[20:34:14.0000] <Hixie_>
rniwa: i'll try to look tomorrow

[20:34:55.0000] <Hixie_>
rniwa: (remind me when you get online tomorrow so i don't forget!)

[21:19:22.0000] <rniwa>
Hixie_: okay, thanks

[00:30:02.0000] <zcorpan>
was there tests for reflecting attributes somewhere?

[00:33:14.0000] <zcorpan>
/me finds https://github.com/w3c/web-platform-tests/blob/master/html/dom/elements-metadata.js

[00:34:05.0000] <Ms2ger>
Right, Aryeh's

[00:46:33.0000] <MikeSmith>
there is no standard for document.charset, right?

[00:47:30.0000] <MikeSmith>
should be document.charsetSet per the Encoding spec?

[00:48:08.0000] <Ms2ger>
I think the standard is "drop it"

[00:49:36.0000] <Ms2ger>
http://w3c-test.org/web-platform-tests/master/dom/historical.html agrees

[00:50:38.0000] <MikeSmith>
Ms2ger: ok

[00:51:07.0000] <MikeSmith>
but document.charsetSet isn't historical though

[00:51:20.0000] <MikeSmith>
it's current per the Encoding spec

[00:51:22.0000] <MikeSmith>
right?

[00:51:26.0000] <Ms2ger>
That's specced in DOM

[00:51:50.0000] <MikeSmith>
oh

[00:52:06.0000] <MikeSmith>
thanks

[00:52:23.0000] <Ms2ger>
Np

[00:55:50.0000] <zcorpan>
any opinions about https://www.w3.org/Bugs/Public/show_bug.cgi?id=23627 Move offsetParent et al from HTMLElement to Element?

[01:09:50.0000] <MikeSmith>
zcorpan: why?

[01:10:09.0000] <zcorpan>
blink does it

[01:10:10.0000] <MikeSmith>
why does Blink implement them that way?

[01:10:14.0000] <zcorpan>
oh, dunno

[01:10:45.0000] <MikeSmith>
I wonder if it'd prudent to assume they have good reason..

[01:10:51.0000] <zcorpan>
maybe someone thought they'd be useful on <svg> elements?

[01:11:18.0000] <zcorpan>
or maybe it was just the way it was implemented way back when

[01:11:35.0000] <zcorpan>
wonder what ie does

[01:12:01.0000] <MikeSmith>
it seems like there's probably no downside to moving them

[01:13:09.0000] <zcorpan>
presto has them on Element too

[01:16:54.0000] <zcorpan>
oops, forgot the doctype when testing ie

[01:20:06.0000] <zcorpan>
only HTMLElement in ie9/10

[01:23:58.0000] <zcorpan>
annevk-cloud: ping https://critic.hoppipolla.co.uk/r/300

[01:29:29.0000] <MikeSmith>
what if anything does testharness.js actually use meta@assert for?

[01:31:22.0000] <MikeSmith>
meta@name=assert

[01:42:45.0000] <zcorpan>
testharness.js itself doesn't use it i think

[01:51:46.0000] <MikeSmith>
zcorpan: ok

[01:56:35.0000] <MikeSmith>
so after re-trying to use github for test-review comments I don't think I'll do that any more because it makes me remember why critic is better

[01:57:03.0000] <MikeSmith>
sorry tobie

[02:00:09.0000] <MikeSmith>
critic is better both for the reviewers and for the people submitting tests for review

[02:00:33.0000] <MikeSmith>
the built-in github stuff is not a review system, it's a commenting system

[03:03:07.0000] <annevk>
zcorpan: offset* is quite a terrible API, that's why it's defined on HTMLElement

[03:03:28.0000] <annevk>
zcorpan: sorry about the URL tests :/

[03:09:22.0000] <zcorpan>
annevk: ok

[03:38:56.0000] <darobin>
MikeSmith: yeah, I just wish the frontend code for Critic were separated from the backend so that it would be easier to tweak and improve it

[03:42:16.0000] <MikeSmith>
darobin: I wish the critic UI sucked less so there'd be no need to spend much time improving it :)

[03:44:35.0000] <jgraham>
after a while you stop noticing the UI

[03:44:40.0000] <jgraham>
Like the matrix

[03:45:02.0000] <darobin>
MikeSmith: heh, yeah

[03:45:02.0000] <jgraham>
Except that in this case you mostly see "issue", "bug", "bad whitespace"

[03:45:11.0000] <darobin>
jgraham: I'm not quite there yet...

[03:45:23.0000] <jgraham>
Which is quite a bit less exciting ;)

[03:45:33.0000] <darobin>
Issue Smith

[03:46:35.0000] <jgraham>
(I agree that the UI could be improved, and that the particular nature of the code makes this less easy to achieve than it could be)

[03:48:00.0000] <darobin>
jgraham: yeah, I poked through the code to see if I could do something, but all the HTML is pretty much hardcoded

[03:48:12.0000] <jgraham>
(but the flip side is that it went from "doesn't exist" to "better than any other code review system we tried at Opera" in a few months)

[03:48:21.0000] <darobin>
yeah, I'm not dissing it

[03:48:51.0000] <darobin>
just a bit annoyed that I can't tweak it without starting from a major refactoring

[03:50:04.0000] <jgraham>
Well the HTML is hardcoded in the sense that it uses a kind of code-based HTML generation system that goes in a python file rather than in an external template

[03:50:17.0000] <MikeSmith>
darobin: I think I'm not there yet either. It's like the scene in the Blues Brothers where Jake finds out a noisy train runs just a few feet away right outside to the window of the bed where he needs to sleep, and he says, How often does the train come by? and then Elwood says, So often you won't even notice it.

[03:50:47.0000] <darobin>
MikeSmith: lol

[03:51:02.0000] <darobin>
jgraham: that's pretty hardcoded :)

[03:53:47.0000] <jgraham>
I will grant you that it doesn't have a clear template/controller seperation

[03:57:27.0000] <darobin>
ideally, for things that are really apps like this, I prefer to have a backend that does nothing more than provide a JSON interface, and let the frontend handle all of the UI on the client

[03:58:28.0000] <darobin>
basically move everything from PAGES into OPERATIONS

[03:58:35.0000] <darobin>
the one thing it makes harder is extensions

[04:00:22.0000] <jgraham>
So someone made a backend that exposed the data as JSON

[04:00:29.0000] <jgraham>
*extension

[04:01:13.0000] <jgraham>
Anyway, I guess if you are serious about working on this you should talk to jl

[04:01:16.0000] <darobin>
oh, you mean that exposes all the things currently done as pages using an API? that's pretty cool

[04:01:30.0000] <darobin>
well, I'm half-serious

[04:01:36.0000] <darobin>
I would be serious if I had more bandwidth

[04:01:50.0000] <darobin>
I certainly don't have the bandwidth to do a full refactor

[04:02:17.0000] <darobin>
but if there's an extension that at least exposes everything as JSON, I could possibly find the time to hack a UI

[04:02:33.0000] <jgraham>
Well, like I say you should talk to jl

[04:03:24.0000] <darobin>
where's jl?

[04:03:56.0000] <jgraham>
@opera.com

[04:04:00.0000] <darobin>
ah, gotcha

[04:04:06.0000] <darobin>
do you know where that extension is?

[04:04:33.0000] <jgraham>
I don't know if it was ever released anywhere. I don't remember who made it

[04:05:53.0000] <molsson>
I think it was Alexey Feldgendler that did the JSON extension

[04:51:28.0000] <MikeSmith>
so if the Notification API does end up being exposed to workers, I guess that'd actually make Notification.permission useful for something

[04:53:38.0000] <MikeSmith>
for the normal case I still don't see when it's actually ever necessary to directly check .permission rather than just calling requestPermission and having it automatically check the permission state

[05:08:29.0000] <MikeSmith>
zcorpan: about https://www.w3.org/Bugs/Public/show_bug.cgi?id=23627 is there a precedent for moving members from HTMLElement to Element?

[05:08:55.0000] <zcorpan>
MikeSmith: yeah, e.g. id

[05:09:04.0000] <zcorpan>
innerHTML

[05:09:12.0000] <MikeSmith>
ok

[05:23:02.0000] <MikeSmith>
anybody here build chromium from sources in the last couple days?

[05:23:09.0000] <MikeSmith>
I asked this on #chromium but didn't get any response

[05:23:42.0000] <MikeSmith>
gclient sync is failing for me with "Fetching origin... error: index-pack died of signal 10... fatal: index-pack failed"

[05:27:11.0000] <annevk>
https://twitter.com/antimattur/status/393714996951011328 <3

[05:31:44.0000] <MikeSmith>
so that explains those glasses that HT wears

[05:36:56.0000] <zcorpan>
TabAtkins: a comment above the h1 makes bikeshed not read the h1

[05:58:55.0000] <annevk>
Hixie_: fffuuu

[05:59:07.0000] <annevk>
Hixie_: it's not classList.has; it's classList.contains()

[06:35:41.0000] <darobin>
wow, I had no idea that someone had reused the Horse JS engine on mattur

[06:37:59.0000] <annevk>
Pretty sure animattur and mattur are authored by the same person.

[06:42:07.0000] <zcorpan>
MikeSmith: are you able to fiddle with repo permissions? i want push access to the FXTF repo

[06:42:47.0000] <MikeSmith>
zcorpan:

[06:43:04.0000] <MikeSmith>


[06:43:33.0000] <zcorpan>
/me nods

[06:43:41.0000] <MikeSmith>
zcorpan: yeah I can but away from PC now

[06:43:57.0000] <zcorpan>
ok, no rush :-)

[06:44:08.0000] <MikeSmith>
will be beck in about 90 minutes

[07:04:05.0000] <darobin>
bah, clicked a link by mistake, lost my critic review :(

[07:06:54.0000] <darobin>
ah, no, it only half lost the review...

[07:17:29.0000] <jgraham>
darobin: Which review?

[07:18:38.0000] <darobin>
your big python change

[07:19:53.0000] <darobin>
and mostly sputtering at critic :)

[07:20:49.0000] <darobin>
jumping between the list of files and the code view is driving me positively insane

[07:21:22.0000] <darobin>
jgraham: there seem to be quite a few changes in there that aren't related to the functionality

[07:24:42.0000] <Hixie_>
annevk: try now

[07:24:47.0000] <jgraham>
darobin: Yeah, for reviews that have a lot of changes that does get pretty annoying

[07:24:56.0000] <jgraham>
Well a lot of files changed

[07:25:55.0000] <jgraham>
Which changes are unrelated?

[07:25:55.0000] <jgraham>
I made some fixes to tests that were brokwn

[07:27:57.0000] <darobin>
jgraham: I don't know, right now I'm just going through the bits that seem obvious to get them out of the way

[07:28:12.0000] <darobin>
I saw some fixes that are indeed good fixes, but don't touch PHP->PY in any way

[07:28:53.0000] <darobin>
I mean, it's great that you're fixing tests too, but it would make a large review like that easier if you did so separately :)

[07:29:08.0000] <darobin>
also, some files seem to have seen only white space change

[07:29:38.0000] <jgraham>
darobin: Yeah, but it would also have been a nightmare to actually make the changes :)

[07:30:12.0000] <darobin>
fair enough, I'm not complaining, just bitching because I'm getting seasick from all the scrolling critic is putting me through

[07:30:37.0000] <darobin>
I wish the code view just opened under the file, or at least that there were a link back to the position in the list

[07:30:41.0000] <jgraham>
The errors I fixed were spotted because I was running the tests which required the changes needed to run the tests

[07:30:55.0000] <jgraham>
Yes, I totally agree

[07:31:56.0000] <zewt>
ffff i need FileSaver

[07:31:57.0000] <darobin>
jgraham: what is utils.js's token() used for?

[07:32:12.0000] <darobin>
oh, it's a uuid generator

[07:32:16.0000] <jgraham>
darobin: Yes

[07:32:23.0000] <jgraham>
It's needed for the stash stuff

[07:32:30.0000] <jgraham>
You have to pass in a uuid

[07:32:37.0000] <jgraham>
(as they key)

[07:37:26.0000] <jgraham>
darobin: Checking things are per-spec isn't really in the spirit of testing :)

[07:38:25.0000] <zewt>
heh, aw snap'd chrome with a data: url

[07:38:34.0000] <Ms2ger>
jgraham, eh?

[07:42:03.0000] <darobin>
jgraham: wait, what?

[07:42:34.0000] <jgraham>
Oh, I see that sentence didn't make sense outside my head

[07:42:50.0000] <Ms2ger>
It did make sense there?

[07:43:06.0000] <jgraham>
I mean only allowing spec-conformant input as part of tets isn't really in the spirit of testing

[07:43:56.0000] <Ms2ger>
Yes, but that's not what you said ;)

[07:43:57.0000] <jgraham>
c.f. http://critic.hoppipolla.co.uk/showcomment?chain=653

[07:44:21.0000] <jgraham>
Well it is if you assume that "things" are "inputs"

[07:44:43.0000] <Ms2ger>
Maybe

[07:46:28.0000] <jgraham>
Anyway, to distract you from my inability to form a coherent sentence http://hoppipolla.co.uk/410/coverage/

[07:46:44.0000] <jgraham>
Might be the coverage from running all the web-platform-tests

[07:47:19.0000] <darobin>
jgraham: oh, that

[07:47:43.0000] <darobin>
jgraham: that's why I phrased it as a question (admittedly, that could have been clearer outside my head, too)

[07:47:59.0000] <Ms2ger>
jgraham, that sucks :)

[07:48:05.0000] <jgraham>
(obviously most of this data is not useful. Would be good to figure out what the right set of files/modules to include would be)

[07:48:19.0000] <darobin>
if it's meant to be a friendly helper that gives you a redirect when you need one, then it should test that you're asking for something sensible

[07:48:42.0000] <darobin>
but if it's meant to be a nasty thing that checks you're not doing stupid stuff on redirects, then indeed it should just do whatever :)

[07:48:54.0000] <darobin>
I just couldn't figure out which just from looking at it

[07:49:11.0000] <jgraham>
I think it's OK for it to have sharp edges

[07:49:22.0000] <Ms2ger>
Also implausible

[07:49:26.0000] <darobin>
jgraham: rofl, I love what you did with the red there

[07:49:40.0000] <Ms2ger>
No tests that get htmlelement.title?

[07:50:11.0000] <Ms2ger>
jgraham, does that include the reflection tests?

[07:50:20.0000] <jgraham>
Ms2ger: Hmm. did I mention that I only just generated this data

[07:50:29.0000] <jgraham>
And haven't looked at it yet :)

[07:50:42.0000] <Ms2ger>
jgraham, well, I don't believe what I see ;)

[07:50:51.0000] <jgraham>
And might well have some it wrong :)

[07:53:43.0000] <jgraham>
It should in theory have included everything. But maybe gcov gets upset with multiple processes writing the files at the same time?

[07:55:01.0000] <annevk>
Hixie_: works, ta!

[07:55:02.0000] <Ms2ger>
That seems plausible

[07:55:45.0000] <jgraham>
It does. Sadly it takes an hour to run all the tests one at a time

[07:55:45.0000] <jgraham>
But I guess I'm not going anywhere for the next hour!

[07:57:44.0000] <annevk>
darobin: https://critic.hoppipolla.co.uk/showcomment?chain=653 you don't wanna do that

[08:00:48.0000] <annevk>
darobin: e.g. you want to test 702 with a Location header and observe it not following the redirect

[08:02:32.0000] <jgraham>
Yeah, so I think that the issue about needing a docstring is fair

[08:03:05.0000] <darobin>
I'm pretty sure it won't be too taxing for your coding ability

[08:03:37.0000] <darobin>
heh, according to Critic 32% done, 67% remaining — gotta love computers

[08:04:28.0000] <wilhelm>
It may be philosophical. Nothing is ever _done_.

[08:04:49.0000] <jgraham>
It's quite fun when it decides something is 99.999% done

[08:05:03.0000] <jgraham>
In my experience, those reviews never are :)

[08:15:23.0000] <jgraham>
darobin: Thanks for all your review btw

[08:24:38.0000] <darobin>
jgraham: no worries, thanks for coding it up in the first place

[08:24:46.0000] <darobin>
I can tell you had a blast updating the websockets tests

[08:33:54.0000] <annevk>
If you say, return all of list X with each of X separated by Y. Does that imply you return nothing if X is empty?

[08:35:01.0000] <Ms2ger>
Sure

[08:35:08.0000] <annevk>
Well I guess that's what it said today, so I'll go with that for now.

[08:43:38.0000] <MikeSmith>
/me looks around for zcorpan

[08:44:21.0000] <annevk>
https://dvcs.w3.org/hg/xhr looks kinda scary

[08:45:16.0000] <annevk>
MikeSmith: any chance the description field for XHR can also mention xhr.spec.whatwg.org?

[08:45:25.0000] <MikeSmith>
"Initial commit for Level 1."

[08:46:35.0000] <MikeSmith>
annevk: sure

[08:48:42.0000] <annevk>
MikeSmith: seems you might also want to fix the owner of that dvcs.w3.org component if you care

[08:48:53.0000] <MikeSmith>
will do

[08:52:41.0000] <MikeSmith>
annevk: check the description now

[08:52:56.0000] <MikeSmith>
that probably won't get me in any trouble

[08:53:41.0000] <MikeSmith>
good thing we didn't have this conversation on a public channel where somebody could point plh to the logs when they complain

[08:54:16.0000] <MikeSmith>
/me will change the owner part now

[08:54:38.0000] <Ms2ger>
Interesting

[09:12:05.0000] <MikeSmith>
"an all-sing, all-dance script of amazingness" https://groups.google.com/a/chromium.org/d/msg/blink-dev/fnWX8n6JrTg/iCwZ8mmOBdUJ

[09:14:17.0000] <annevk>
So in particular https://dvcs.w3.org/hg/xhr seems to now have descended into monkey patching hell where they take some fixes and not others and don't even discuss that on the list

[09:15:36.0000] <jgraham>
Woah

[09:15:49.0000] <jgraham>
Is Dirke not on public-test-infra?

[09:20:31.0000] <MikeSmith>
jgraham: he is

[09:20:48.0000] <MikeSmith>
at least his e-mail address is

[09:20:54.0000] <MikeSmith>
@chromium.org

[09:23:39.0000] <jgraham>
Interesting

[09:23:39.0000] <MikeSmith>
jgraham: oh I guess you're reading the blink-dev thread

[09:23:45.0000] <jgraham>
MikeSmith: Yes

[09:23:48.0000] <MikeSmith>
mention of PHO

[09:23:58.0000] <jgraham>
Although I now have a read/write relationship with it

[09:24:00.0000] <MikeSmith>
aka PHP

[09:24:29.0000] <MikeSmith>
jgraham: time to use the write function :-)

[09:24:53.0000] <MikeSmith>
oh you did

[09:25:20.0000] <jgraham>
Yes

[09:25:29.0000] <jgraham>
But it's nice to know that you got it

[09:25:39.0000] <jgraham>
I don't really trust Google Groups

[09:25:50.0000] <jgraham>
s/ Groups/

[09:25:56.0000] <annevk>
I got it, via email

[09:28:09.0000] <MikeSmith>
speaking of mailing lists, for following Web-platform-related work in Gecko, what lists might should I be on along with dev-platform⊙lmo?

[09:28:49.0000] <Ms2ger>
There's some smaller ones... m.d.t.layout, perhaps

[09:29:33.0000] <Ms2ger>
Maybe m.d.servo

[09:32:06.0000] <MikeSmith>
Ms2ger: ok

[09:33:55.0000] <annevk>
I wish dev.platform was a bit more focused

[09:36:05.0000] <MikeSmith>
it does seem to cover a lot more ground than other browser-engine -dev lists

[09:36:43.0000] <MikeSmith>
not that it's uninteresting

[09:44:24.0000] <Ms2ger>
Here's the spec:

[09:44:24.0000] <Ms2ger>
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_targetmodule

[09:44:43.0000] <Ms2ger>
With quote marks around it, of course

[09:58:03.0000] <annevk>
http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0067.html "W3C web platform" oh god

[09:58:06.0000] <annevk>
I think it's time to go home

[10:00:55.0000] <Jasper>
i really hate that encrypted content is called premium content

[10:01:10.0000] <Jasper>
like, I don't really care about EME that much. it's a necessary evil imo. but "premium content" just pushes my buttons

[10:01:54.0000] <hober>
i think every single term that people have come up with press someone's buttons

[10:02:02.0000] <hober>
so it's best not to bikeshed it too much

[10:02:23.0000] <Jasper>
yeah, that's true

[10:02:29.0000] <jgraham>
Well, in this case "Premium Content" is basically advertising from netflix

[10:02:38.0000] <Jasper>
not trying to change anything, just sort of ranting off-topic

[10:03:34.0000] <annevk>
Giving web platform gets qualifiers seems way worse... Anyway...

[10:03:39.0000] <annevk>
s/gets//

[10:04:36.0000] <jgraham>
annevk: I think that was intended to have the opposite effect :)

[10:04:42.0000] <MikeSmith>
the VSOP Web Platform

[10:04:50.0000] <MikeSmith>
aged 20 years

[10:05:14.0000] <Jasper>
enterprise web-scale platforce

[10:05:18.0000] <annevk>
XO is where it's at MikeSmith

[10:05:42.0000] <MikeSmith>
well I drink Old Crow and like it

[10:05:57.0000] <jgraham>
Nothing to do with the Vienna Symphonic Orchestra Project then?

[10:06:25.0000] <MikeSmith>
brandy confuses me

[10:07:00.0000] <Jasper>
it has everything to do with Vienna Symphonic Orchestra Project, jgraham

[10:12:27.0000] <MikeSmith>
long earthquake here

[10:12:42.0000] <MikeSmith>
seems to be getting stronger, oddly

[10:12:42.0000] <hober>
MikeSmith: :(

[10:13:38.0000] <MikeSmith>
http://quake.twiple.jp/quake/view/20131026021102

[10:13:47.0000] <MikeSmith>
7.3 it seems

[10:13:59.0000] <MikeSmith>
up in Fukushima

[10:40:53.0000] <bholley>
Hixie_: ping

[10:41:53.0000] <bholley>
jgraham: ping

[10:42:28.0000] <Ms2ger>
/me hides

[10:42:53.0000] <bholley>
Ms2ger: ping :-)

[10:43:01.0000] <Ms2ger>
Not here!

[10:43:22.0000] <bholley>
Ms2ger: do you know if any spec defines where we should cut off stack traces?

[10:43:35.0000] <bholley>
Ms2ger: like, when we spin the event loop, for example

[10:43:44.0000] <Ms2ger>
No idea

[10:43:53.0000] <bholley>
we obviously don't want stack traces to go all the way up

[10:44:09.0000] <Ms2ger>
TC39 wanted to maybe spec stacks, I think

[10:44:11.0000] <Ms2ger>
annevk, ^

[10:44:23.0000] <Hixie_>
bholley: here

[10:44:29.0000] <bholley>
Hixie_: see my question above

[10:44:46.0000] <bholley>
Hixie_: I'd thought that this was specced in terms of the script entry point, but I don't see anything of the sort in the spec

[10:44:50.0000] <Hixie_>
bholley: i don't even know of a spec that requires stack traces in the first place

[10:45:04.0000] <bholley>
Hixie_: (new Error()).stack?

[10:45:21.0000] <Hixie_>
that's probably specced in JS land

[10:45:28.0000] <Ms2ger>
If it's specced at all by now

[10:45:37.0000] <bholley>
Hixie_: well, it's our problem now in HTML5

[10:45:41.0000] <bholley>
Hixie_: because we specced an event loop

[10:45:55.0000] <Hixie_>
how does the event loop affect this?

[10:46:02.0000] <bholley>
Hixie_: well, if you spin an event loop

[10:46:14.0000] <bholley>
Hixie_: does your stack trace see through that?

[10:46:29.0000] <Domenic_>
yes please!

[10:46:35.0000] <Domenic_>
long stack traces would be a killer dev tools feature

[10:46:41.0000] <Hixie_>
bholley: that's defined in the spec

[10:46:58.0000] <Domenic_>
user-land libraries are emulating that right now using V8 stack trace API and duck-punching every async method to record the stack at call time then stitch it together with subsequent ones.

[10:47:19.0000] <bholley>
Hixie_: where?

[10:47:28.0000] <Hixie_>
bholley: spin the event loop actually doesn't do a nested event loop, per the spec. it ends the previous task entirely, saves off its current state in a continuation, and returns back to the original event loop.

[10:47:45.0000] <Hixie_>
bholley: then it queues a task when it's ready to resume, and the task resumes the previous state

[10:47:52.0000] <Hixie_>
bholley: so there's nothing unusual on the stack

[10:47:56.0000] <Hixie_>
http://www.whatwg.org/specs/web-apps/current-work/#spin-the-event-loop

[10:48:06.0000] <bholley>
Hixie_: so, per spec, stack traces don't see through nested event loops

[10:48:10.0000] <Hixie_>
right

[10:48:13.0000] <Hixie_>
cos there aren't any

[10:48:35.0000] <Hixie_>
"spin the event loop" is really "queue a continuation"

[10:49:07.0000] <bholley>
Hixie_: ok. And as far as the spec is concerned, there's no reason stack traces wouldn't see through event dispatches and whatnot?

[10:49:25.0000] <Hixie_>
well

[10:49:43.0000] <Hixie_>
i don't see anything in HTML that would say one way or the other

[10:49:49.0000] <Hixie_>
or DOM (which specs dispatches)

[10:49:49.0000] <Hixie_>
but

[10:49:52.0000] <Hixie_>
the real question

[10:49:58.0000] <Hixie_>
is what the spec for Error.stack is

[10:50:00.0000] <Hixie_>
and i can't find out

[10:50:05.0000] <Hixie_>
can't find one, even

[10:50:12.0000] <Domenic_>
there's a ES strawman

[10:50:19.0000] <Hixie_>
nothing in http://people.mozilla.org/~jorendorff/es6-draft.html#sec-properties-of-the-error-prototype-object or anywhere near it

[10:50:31.0000] <Domenic_>
didn't make the ES6 cutoff, too much edge-case debate IIRC

[10:50:37.0000] <Domenic_>
http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

[10:50:50.0000] <bholley>
Domenic_: ok. So currently this stuff is unspecced, and we're still working it out?

[10:50:54.0000] <Ms2ger>
Ah, good old strawmen

[10:51:12.0000] <Hixie_>
/me waves a "please join the living standard movement" flag near the ES spec's office

[10:51:17.0000] <Domenic_>
bholley: yeah, i mean, i don't know what the HTML spec says about it, but I know the ES spec says nothing about error.stack

[10:51:42.0000] <Hixie_>
bholley: personally i would define it as being only the stack trace from the point where JS thinks it was invoked

[10:51:57.0000] <Hixie_>
bholley: so dispatching an event would reset the stack for the "child" "program"

[10:52:28.0000] <Hixie_>
bholley: but authors may prefer something else

[10:52:41.0000] <Hixie_>
bholley: i guess if dispatchEvent() can never go cross-origin, it's probably more useful to include it

[10:53:12.0000] <Hixie_>
bholley: as for spinning the event loop... maybe have something hanging off the stack object that says "and btw, here's the stacks for the various things currently waiting in a "spin the event loop" algorithm"

[10:53:22.0000] <Hixie_>
bholley: though that _can_ be cross-origin

[10:53:27.0000] <Domenic_>
in user space we've preferred to have separators where the "async" boundaries live, e.g. https://github.com/kriskowal/q#long-stack-traces or https://github.com/tlrobinson/long-stack-traces/#usage

[10:53:29.0000] <bholley>
Hixie_: that seems logical to me. But doesn't appear to jive with the current behavior of Gecko and Blink. http://bit.ly/16ylHO2

[10:53:48.0000] <Hixie_>
ah well if there's implementations and they're interoperable, i'd just go with that

[10:53:53.0000] <Hixie_>
(unless it's crazy)

[10:54:04.0000] <bholley>
Hixie_: well, I'm still trying to sort that part out

[10:55:03.0000] <bholley>
Domenic_: as in, formatting separators

[10:55:18.0000] <bholley>
Domenic_: I don't think we can cross async boundaries very easily in the platform

[10:56:20.0000] <bholley>
Hixie_: our long-term thinking was that we would just have one single stack

[10:56:25.0000] <bholley>
Hixie_: and filter out cross-origin stuff

[10:56:46.0000] <bholley>
which is probably what Domenic_ wants

[10:57:21.0000] <bholley>
Domenic_: would Blink be interested in implementing something like that?

[10:59:54.0000] <gsnedders>
Hixie_: Part of the problem with Error.stack is some things (Closure used to, maybe still does?) rely on subtly different formats based on UA strings.

[11:00:06.0000] <Hixie_>
ew

[11:00:22.0000] <Hixie_>
shouldn't it be a structured array of tuples

[11:00:29.0000] <Ms2ger>
Hah

[11:00:39.0000] <gsnedders>
Hixie_: And seem very hard to get changed (i.e., the Opera code still relies on Futhark behaviour, never having gotten changed for Carakan despite having had patches made for it)

[11:00:59.0000] <Hixie_>
isn't that codebase dead

[11:01:05.0000] <gsnedders>
Closure?

[11:01:08.0000] <gsnedders>
Haha. No.

[11:01:50.0000] <gsnedders>
Still really actively developed.

[11:02:02.0000] <gsnedders>
Not used by so many things internally to Google, AFAIK, though

[11:02:12.0000] <gsnedders>
" At Google, it's used in Web Search, Maps, YouTube, Google Plus, Gmail, Docs, Sites, Books, Blogger, Calendar, Picasa Web Albums, and more. "

[11:02:41.0000] <Hixie_>
no, opera

[11:02:57.0000] <gsnedders>
Oh, yeah. Now.

[11:03:11.0000] <bholley>
gsnedders: yuck

[11:03:26.0000] <bholley>
gsnedders: would Closure get confused if we started including more stack frames?

[11:03:33.0000] <gsnedders>
But Carakan shipped in 2010, so three years of that bug being current and unfixed

[11:03:55.0000] <gsnedders>
bholley: In what UA's codepath?

[11:04:31.0000] <bholley>
gsnedders: well, I'm mostly interested in Gecko

[11:04:41.0000] <gsnedders>
(Yes, it's horrible that that's even a relevant question.)

[11:04:50.0000] <gsnedders>
IIRC, Gecko would be fine.

[11:05:03.0000] <bholley>
gsnedders: who _wouldn't_ be fine, if I dare ask?

[11:05:13.0000] <gsnedders>
The WebKit codepath, I think.

[11:05:20.0000] <bholley>
gsnedders: why?

[11:05:54.0000] <gsnedders>
bholley: Because it does things like length checks.

[11:06:04.0000] <gsnedders>
In quite bizarre ways.

[11:06:22.0000] <gsnedders>
(Disclaimer: I haven't looked at this in about a year, so it could've changed. I wouldn't have much hope, though)

[11:06:57.0000] <gsnedders>
AFAICT, what practically need be done is standardize SpiderMonkey's Error.stack, as that's what is most relied on.

[11:07:07.0000] <gsnedders>
However much it sucks. :(

[11:07:30.0000] <bholley>
gsnedders: ok. I'd really like to try including more stack frames

[11:07:43.0000] <bholley>
gsnedders: I guess we'll see

[11:07:54.0000] <gsnedders>
bholley: I'd like to try that too. Not overly hopeful, though. :(

[11:08:23.0000] <gsnedders>
Carakan, FWIW, has both Error.stack (~SpiderMonkey behaviour), and Error.stacktrace (human readable, with more detail)

[11:21:48.0000] <Domenic_>
bholley: I don't work for Blink, but I hope so. I have heard the Firefox dev tools guys might want to make long stack traces work, and then that could cause competitive pressure like it did for dev tools file blacklisting.

[11:22:33.0000] <bholley>
Domenic_: aren't you doing Web Components at Google?

[11:22:43.0000] <Domenic_>
One solution generally might be to give up on standardizing error.stack and try standardizing a more-useful array of tuples (error.stackFames or similar).

[11:22:48.0000] <bholley>
Domenic_: or are  you purely at the spec level?

[11:22:55.0000] <Domenic_>
bholley: nope, haha. i work for a consultancy.

[11:23:05.0000] <Domenic_>
i happen to be doing the es6 promises spec, but just in my spare time.

[11:23:23.0000] <bholley>
oh, you're a different Dominic

[11:23:24.0000] <bholley>
er

[11:23:26.0000] <bholley>
yes

[11:23:28.0000] <bholley>
you are not Dominic

[11:23:37.0000] <bholley>
(Cooney)

[11:23:43.0000] <Domenic_>
ah right

[11:27:21.0000] <gsnedders>
Domenic_: On the other hand Error.stack isn't going away

[11:28:27.0000] <Domenic_>
gsnedders: yeah. but if there are compat constraints that *prevent* convergence, e.g. ua-sniffing dependent codepaths, can't imagine what to do to fix that...

[11:33:35.0000] <Ms2ger>
Evangelism

[11:42:40.0000] <Hixie_>
i hope rniwa is happy with my e-mail

[14:20:26.0000] <jgraham>
bholley: We should really avoid mested event loops in servo. No good ever came of them

[14:20:55.0000] <bholley>
jgraham: you mean, design it like the spec does it?

[14:21:21.0000] <jgraham>
For example

[14:21:30.0000] <bholley>
jgraham: that requires a lot of help from the JS engine

[14:21:45.0000] <bholley>
in particualr, being able to pause execution

[14:21:48.0000] <jgraham>
hmm

[14:21:57.0000] <bholley>
the spec makes it sound easy, but it's not

[14:22:15.0000] <bholley>
especially because JS and C++/Rust interleave

[14:22:31.0000] <bholley>
how do you save all of that state without leaving it on the stack?

[14:22:33.0000] <jgraham>
Everything not-carakan sucks

[14:22:45.0000] <bholley>
jgraham: how does carakan do it?

[14:23:38.0000] <jgraham>
/me can't type fast enoihh to have a real conversation; using a phone

[14:24:32.0000] <bholley>
/me would be impressed if carakan could avoid this problem

[14:24:33.0000] <jgraham>
well opera, even pre carakan could pause the script engine

[14:25:23.0000] <bholley>
ah, to process events and be responsive, right?

[14:26:07.0000] <jgraham>
I don't remember if it could run different script whilst pausing one

[14:26:17.0000] <jgraham>
right

[14:27:35.0000] <bholley>
jgraham: so how does that work with C++ and JS interleaving?

[14:27:55.0000] <jgraham>
but I thought other browsers were at least different to gecko here and msybe simpler

[14:29:33.0000] <jgraham>
bholley: I am the wrong person to ask about the exact implementation

[15:26:50.0000] <Hixie_>
rniwa: did you see my mail?

[15:28:28.0000] <Hixie_>
bholley: i don't know how opera did it exactly, but you can envisage a mode where js execution operates entirely separate from the C++ stack, much like how parsing HTML doesn't use the C++ stack, and where any API that might involve spinning the event loop is implemented as two halves, one of which just queues the other.

[15:28:42.0000] <Hixie_>
bholley: i doubt it would be particularly efficient

[15:28:52.0000] <Hixie_>
bholley: but it's certainly implementable in theory

[15:29:12.0000] <bholley>
Hixie_: but how does JS operate separately from the C++ stack? What happens when the calls interleave?

[15:29:40.0000] <Hixie_>
bholley: you mean like event dispatch?

[15:30:08.0000] <bholley>
Hixie_: or callbacks

[15:30:49.0000] <Hixie_>
bholley: you'd just treat that the same as spinning the event loop, essentially. have the C++ API implemented in a completely interruptible way, so that at the point where it would call the JS, it starts that off, queues itself again (with its internal state) as the thing to run once the script is done, then actually returns.

[15:31:04.0000] <Hixie_>
bholley: (i'm not saying this is a sane way to actually implement a performant UA)

[15:31:12.0000] <Hixie_>
(or a maintainable one)

[15:31:34.0000] <Hixie_>
the better way to implement what the spec does would be to use real continuations, in a language that supports those natively.

[15:31:47.0000] <bholley>
heh

[15:31:52.0000] <Hixie_>
so that you could shunt the entire stack, C++ and JS together, into a continuation.

[15:32:14.0000] <bholley>
I don't think rust does

[15:32:16.0000] <bholley>
heh

[15:32:17.0000] <Hixie_>
in practice, i assume most UAs just actually nest the event loop, though that has a whole suit of issues.

[15:32:45.0000] <bholley>
Hixie_: which issues does the spec's approach avoid?

[15:33:01.0000] <Hixie_>
you never have to worry about whether you have more than one event loop going

[15:33:08.0000] <Hixie_>
makes it much easier to reason about when things actually run

[15:33:45.0000] <Hixie_>
also, should it ever be possible for "spin the event loop" conditions to return out of order, you don't end up unable to return to the right caller

[15:33:53.0000] <Hixie_>
also, you avoid your stack getting out of hand

[15:34:12.0000] <Hixie_>
and you can never return without it costing anything

[15:34:23.0000] <Hixie_>
just throw the continuation away

[15:34:34.0000] <Hixie_>
no need to be able to handle "this is irrelevant, just unwind please" cases

[15:36:03.0000] <bholley>
Hixie_: I also wanted to talk to you about session history, though maybe this isn't the time

[15:36:53.0000] <Hixie_>
bholley: there's never a good time for talking about session history :-P

[15:36:59.0000] <Hixie_>
bholley: might as well try now :-P

[15:37:06.0000] <Hixie_>
(unless it's not a good time for you)

[15:37:14.0000] <bholley>
Hixie_: well, I'm concerned that I'm too tired

[15:37:22.0000] <bholley>
Hixie_: but maybe I'll just try a high-level

[15:37:27.0000] <Hixie_>
you want to be very awake to talk about session history stuff

[15:37:39.0000] <Hixie_>
it's part of the whole navigation subsystem, which is probably the most complicated part of the spec

[15:37:45.0000] <bholley>
Hixie_: that or Location ;-)

[15:37:52.0000] <Hixie_>
(but don't worry! we've proven it's interoperable, so we're good! just as the HTMLWG!)

[15:38:11.0000] <rniwa>
Hixie_: yes

[15:38:18.0000] <rniwa>
Hixie_: thanks!

[15:38:20.0000] <Hixie_>
bholley: well, the nav parts of Location are part of the same thing, and the security parts of Location are definitely not as complicated, they're far more localised

[15:38:27.0000] <rniwa>
Hixie_: haven't had a chance to read through hit

[15:38:32.0000] <Hixie_>
rniwa: right-o

[15:38:33.0000] <rniwa>
Hixie_: but I think your response makes sense

[15:38:35.0000] <Hixie_>
rniwa: let me know if i can help further

[15:38:39.0000] <rniwa>
Hixie_: will read & respond as needed

[15:38:41.0000] <rniwa>
Hixie_: yeah, thanks!

[15:39:07.0000] <Hixie_>
rniwa: i did find a couple of errors in the spec walking through it, so thanks for asking, even though my answer was basically just "the spec already says that" :-)

[15:40:13.0000] <bholley>
Hixie_: so anyway. In Gecko, session history is stored at the top of the BC tree, and is represented as a tree of session history entries, each of which represents a given BC in the tree as it is currently navigated

[15:40:45.0000] <bholley>
Hixie_: whenever anything navigates, we snapshot/clone the entire tree and add that as an entry

[15:41:17.0000] <bholley>
Hixie_: IIUC, the spec's model is quite different. Am I correct?

[15:42:32.0000] <Hixie_>
bholley: i think the spec's model is isomorphic, but it's certainly described very differently

[15:43:12.0000] <bholley>
Hixie_: in the spec, is a browsing context parented to a document, or parented to another browsing context?

[15:43:47.0000] <Hixie_>
bholley: neither, precisely

[15:44:45.0000] <Hixie_>
bholley: nested browsing contexts are, in most cases, parented to an element (<iframe>, <frame>, <object>, and in some edge cases involving SVG, <embed> or <img>), which themselves belong to documents, which belong to browsing contexts.

[15:45:38.0000] <Hixie_>
/me sprinkles "in most cases" and "roughly speaking" througout that sentence

[15:45:42.0000] <Hixie_>
throughout

[15:47:30.0000] <bholley>
Hixie_: do session history entries live on the browsing context?

[15:47:55.0000] <Hixie_>
bholley: "The sequence of Documents in a browsing context is its session history"

[15:48:39.0000] <bholley>
Hixie_: so this means that, when the UA decides to GC a document, the relevant session history goes away too?

[15:49:07.0000] <Hixie_>
bholley: insufficient detail, please elaborate

[15:49:29.0000] <Hixie_>
bholley: when a document is GC'ed, session history entries relating to frames within that document go away

[15:49:34.0000] <Hixie_>
bholley: session history entries involving that document itself do not

[15:50:13.0000] <bholley>
Hixie_: If the session history is just the list of documents, how does that last part work?

[15:50:35.0000] <bholley>
Hixie_: if the document is GCed, then it's nulled out, right?

[15:52:06.0000] <Hixie_>
bholley: the entries include more information than just the reference to the Document

[15:52:16.0000] <Hixie_>
bholley: but yeah, the sentence i pasted does make that unclear

[15:52:44.0000] <Hixie_>
a few sentences later it says "Each session history entry consists of a URL and optionally a state object, and may in addition have a title, a Document object, form data, a scroll position, and other information associated with it."

[15:52:45.0000] <bholley>
Hixie_: ok. So a browsing context has a list of entries, which include both URIs and direct document references

[15:53:40.0000] <Hixie_>
yeah. traversing the history checks if the document is still alive, and if not, brings a new one up

[15:54:10.0000] <Hixie_>
(filed a bug on making that contradiction less blatent)

[15:56:09.0000] <bholley>
Hixie_: so, consider  this: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2569

[15:56:27.0000] <bholley>
Hixie_: (you want rendered view for this one)

[15:57:20.0000] <Hixie_>
yeah, i was gonna say, live dom viewer with session history, you're a brave man

[15:57:24.0000] <bholley>
Hixie_: basically, we have an outer frame, P. P begins with an inner frame, C, which gets navigated to C'

[15:57:31.0000] <bholley>
Hixie_: then, P gets navigated to P'

[15:57:40.0000] <Hixie_>
yup

[15:57:44.0000] <Hixie_>
lgtm so far

[15:57:56.0000] <bholley>
Hixie_: in Gecko, hitting back after the P' navigation gives you a C' subframe

[15:58:01.0000] <Hixie_>
chrome also

[15:58:09.0000] <Hixie_>
which we explain via the bfcache

[15:58:10.0000] <bholley>
Hixie_: but in the spec, it depends on GC

[15:58:44.0000] <Hixie_>
yeah, it's true that if we assume the doc got GC'ed (which i guess it did in chrome), the spec doesn't explain this

[15:58:58.0000] <Hixie_>
having said that, i'd argue this behaviour if the doc _did_ get GC'ed is rather dubious

[15:59:22.0000] <Hixie_>
because you don't really have a sane way to know how to reconstruct the right state

[15:59:34.0000] <bholley>
Hixie_: well, Gecko does a whole lot of work to do so

[15:59:40.0000] <Hixie_>
i mean, how do you know which iframe to use?

[15:59:44.0000] <Hixie_>
it's all one big heuristic

[15:59:47.0000] <bholley>
Hixie_: yep

[15:59:54.0000] <Hixie_>
/me votes to kill the heuristic

[16:00:09.0000] <bholley>
Hixie_: me too, but doing so is not necessarily web compatible

[16:00:25.0000] <bholley>
Hixie_: I mean, implementing the spec is like, 10 times easier than implementing it Gecko-style

[16:00:28.0000] <Hixie_>
well, the heuristic isn't either, especially in the case of web apps

[16:00:38.0000] <Hixie_>
web compatible, that is

[16:00:50.0000] <bholley>
Hixie_: the heuristic is totally web-compatible

[16:00:56.0000] <Hixie_>
i think it's reasonable to do it in the case of the page being static

[16:01:01.0000] <bholley>
Hixie_: Gecko does it. Chrome mostly kinda sorta tries to copy it

[16:01:07.0000] <Hixie_>
that heuristic has actually broken my pages

[16:01:13.0000] <Hixie_>
i've had to do all kinds of workarounds to stop it

[16:01:20.0000] <bholley>
Hixie_: sure. But that's your problem as a web author

[16:01:28.0000] <Hixie_>
i care about web authors :-)

[16:01:51.0000] <bholley>
Hixie_: I know. But I'm saying that you're conflating "developer-friendly" with "web-compatible"

[16:01:58.0000] <Hixie_>
well fair enough

[16:01:58.0000] <bholley>
Hixie_: they're two very different concepts

[16:02:13.0000] <Hixie_>
though i'm sure this breaks web apps that use iframes internally but haven't been tested with the back button

[16:02:16.0000] <Hixie_>
anyway

[16:02:20.0000] <bholley>
Hixie_: yeah, sure

[16:02:25.0000] <Hixie_>
i'm happy to spec this if that's where we're going with this

[16:02:30.0000] <bholley>
Hixie_: so, I'm all in favor of the spec

[16:02:32.0000] <Hixie_>
but i need a detailed precise description of the heuristic

[16:02:39.0000] <bholley>
Hixie_: and I want to try to implement the spec in servo

[16:02:51.0000] <bholley>
Hixie_: but smaug is adamant that Gecko's model is necessary to avoid breaking the web

[16:03:05.0000] <Hixie_>
bholley: in the case of non-static pages?

[16:03:27.0000] <bholley>
Hixie_: he didn't go into detail. But it sounds like this whole situation is very touchy

[16:03:39.0000] <Hixie_>
this is certainly a third rail issue

[16:04:26.0000] <bholley>
Hixie_: so anyway. Implementing the spec is very straightforward, so that's what I'm going to do in servo

[16:04:57.0000] <Hixie_>
basically my view is that in all the cases where you can't tell from script that the docs got GC'ed, i'm all in favour of the browsers pretending the docs weren't GC'ed and bringing everything back. but in the case where there's a way to tell whether or not the doc got GC'ed, e.g. going back is going to rerun some script that creates iframes or whatnot, then the spec model is the only sane option. imho.

[16:05:37.0000] <bholley>
(also, onpageshow)

[16:06:13.0000] <Hixie_>
oh pretty much any script

[16:07:57.0000] <bholley>
so anyway. The spec might need to change, but at the moment it's the simplest option to implement, and I only want to implement the Gecko setup if it becomes clear that the spec model breaks the web and that servo is going to be shippable modulo this issue

[16:08:31.0000] <Hixie_>
k

[16:08:33.0000] <Hixie_>
sounds good

[16:08:44.0000] <Hixie_>
if you do decide the spec needs to change, i need a description of what it should say

[16:08:50.0000] <Hixie_>
because i'm at a loss as to how to spec that heuristic

[16:08:55.0000] <bholley>
/me doesn't look forward to it


2013-10-26
[00:14:51.0000] <MikeSmith>
Ms2ger: any idea why http://w3c-test.org/web-platform-tests/master/dom/interfaces.html doesn't run to completion?

[00:15:11.0000] <Ms2ger>
It doesn't?

[00:15:12.0000] <MikeSmith>
there are 3983 tests in the source

[00:15:46.0000] <MikeSmith>
in Firefox and Chrome for me, both run only 1331 tests and stop

[00:15:57.0000] <Ms2ger>
How did you count? :)

[00:16:45.0000] <MikeSmith>
ran it locally with http://web-platform.test:8000/html/dom/interfaces.html

[00:17:39.0000] <MikeSmith>
and if you examine the restults results from w3c-test.org you'll a bunch of tests from teh source are not reported

[00:18:19.0000] <Ms2ger>
Such as?

[00:18:55.0000] <MikeSmith>
all of the HTMLInputElement tests

[00:19:03.0000] <Ms2ger>
Ah

[00:19:10.0000] <Ms2ger>
You're looking at the wrong test

[00:19:11.0000] <MikeSmith>
maybe in fact all of the HTML*Element tests

[00:19:13.0000] <MikeSmith>
oh

[00:19:16.0000] <Ms2ger>
http://w3c-test.org/web-platform-tests/master/dom/interfaces.html != http://w3c-test.org/web-platform-tests/master/html/dom/interfaces.html

[00:19:28.0000] <MikeSmith>
fuuuuu

[00:19:36.0000] <MikeSmith>
sorry for the noise

[00:19:39.0000] <Ms2ger>
Np

[00:19:57.0000] <Ms2ger>
Not sure how to make this more obvious

[00:22:37.0000] <MikeSmith>
I think it's pretty clear to anybody who's being careful and paying attention

[00:23:46.0000] <MikeSmith>
plus one tab says "DOM4 IDL tests" and the other says "HTML IDL tests"

[00:23:47.0000] <MikeSmith>
etc.

[00:25:37.0000] <Ms2ger>
Even then, you're not the first to be confused :)

[00:31:42.0000] <MikeSmith>
could just add <h1>DOM4 IDL tests</h1> to the source before <div id=log>

[00:31:48.0000] <Ms2ger>
Fair

[00:31:56.0000] <Ms2ger>
Let me go and do that

[00:33:36.0000] <Ms2ger>
/me sees https://github.com/w3c/web-platform-tests/pull/368 landed

[00:33:38.0000] <Ms2ger>
zcorpan++

[00:33:40.0000] <Ms2ger>
denis++

[00:45:09.0000] <MikeSmith>
ah cool

[00:45:54.0000] <MikeSmith>
having Denis working on tests is going to be a big win

[00:49:36.0000] <Ms2ger>
https://github.com/w3c/web-platform-tests/pull/388

[01:00:39.0000] <MikeSmith>
/me looks 

[01:01:14.0000] <MikeSmith>
btw, I wonder if wptserve can handle the kind of case that abarth describes in https://groups.google.com/a/chromium.org/d/msg/blink-dev/fnWX8n6JrTg/qw1OC_P_AlEJ

[01:01:37.0000] <MikeSmith>
"requires sending broken unicode on the wire and controlling exactly when the underlying socket is flushed"

[01:05:09.0000] <MikeSmith>
Ms2ger: how come Critic didn't create a review for https://github.com/w3c/web-platform-tests/pull/388 ?

[01:05:56.0000] <Ms2ger>
No idea

[01:06:00.0000] <Ms2ger>
jgraham?

[01:07:53.0000] <MikeSmith>
Ms2ger: how come you're using /resources/WebIDLParser.js instead of /resources/webidl2/lib/webidl2.js ?

[01:08:17.0000] <MikeSmith>
WebIDLParser.js doesn't actually exist in the repo

[01:08:29.0000] <Ms2ger>
That's the one that works everywhere at this point

[01:08:40.0000] <Ms2ger>
Except in the repo, unfortunately

[01:10:21.0000] <MikeSmith>
by "everywhere" you mean only some places? because it doesn't work on the jgraham/python branch with wptserve

[01:12:43.0000] <Ms2ger>
I thought that was going to get fixed

[01:13:25.0000] <MikeSmith>
oh

[01:13:56.0000] <MikeSmith>
I notice you used the passive voice there

[01:13:57.0000] <jgraham>
MikeSmith: wptserve should be able to do that. And I thought I fixed the idlharness thing but maybe not

[01:14:16.0000] <jgraham>
will check thst pr later

[01:14:42.0000] <MikeSmith>
ok

[01:15:24.0000] <MikeSmith>
Ms2ger: https://github.com/w3c/web-platform-tests/pull/388 LGTM as long as you guys know the /resources/WebIDLParser.js is OK

[01:15:54.0000] <MikeSmith>
but I been using /resources/webidl2/lib/webidl2.js in IDL tests I wrote so I guess I should change that in my tests

[01:17:00.0000] <Ms2ger>
It seems to be OK for the DOM / HTML tests ;)

[01:21:26.0000] <MikeSmith>
ah sorry yeah I mispoke

[01:21:57.0000] <MikeSmith>
it does work in jgraham/python too

[01:22:13.0000] <jgraham>
OK, good

[01:22:37.0000] <jgraham>
and I just fixed critic which hit a known bug

[01:23:12.0000] <MikeSmith>
cool

[01:27:40.0000] <Ms2ger>
On another note, I've found a way to reduce the review backlog: https://github.com/w3c/web-platform-tests/pull/389

[01:57:56.0000] <MikeSmith>
yeah

[01:58:24.0000] <MikeSmith>
are those tests that plh added?

[01:58:54.0000] <MikeSmith>
weren't some really old crufty DOm tests imported in at some point?

[01:59:51.0000] <MikeSmith>
ah I see NIST listed in those W3C/domhtml/HTML* tests

[02:06:24.0000] <Ms2ger>
Yeah, the NIST ones

[02:07:02.0000] <Ms2ger>
With the extremely readable code that results from autogenerating Java and JS tests from XML files

[02:19:53.0000] <MikeSmith>
yeah we should dump those

[09:59:59.0000] <jgraham>
I didn't realise that the history navigation stuff was supposed to be GC-dependent. That seems unfortunate

[10:00:26.0000] <gsnedders>
jgraham: Is there any odd of you picking up the review/PR of your tests? :P

[10:00:32.0000] <gsnedders>
jgraham: Speaking of history navigation

[10:01:11.0000] <jgraham>
I don't think I can review my own tests :)

[10:01:38.0000] <jgraham>
But maybe I can convince someone to review them when they are workong on Servo

[10:03:29.0000] <gsnedders>
jgraham: Not so much review, but deal with any feedback, etc.

[10:03:41.0000] <gsnedders>
I don't really have the time or motivation :)

[10:11:56.0000] <jgraham>
I can probably do that

[11:46:30.0000] <rektide>
does a script when executing have any context information available telling it what it's context is?

[11:47:19.0000] <rektide>
how does/can a script find it' origin in the dhtml?


2013-10-27
[06:14:59.0000] <Ms2ger>
annevk_, should document.characterSet return "utf-8" or "UTF-8"?

[06:27:12.0000] <annevk-cloud>
The former per spec

[06:31:01.0000] <Ms2ger>
Hrm

[06:31:07.0000] <odinho>
likey those small letters

[06:31:11.0000] <Ms2ger>
Gecko and Chrome seem to return the latter

[07:03:40.0000] <Ms2ger>
annevk_, r? http://critic.hoppipolla.co.uk/r/378

[07:09:43.0000] <MikeSmith>
Ms2ger: you filed a bug on "utf-8" vs "UTF-8"?

[07:10:06.0000] <MikeSmith>
/me noticed // XXX Spec says "utf-8", browsers do "UTF-8" in dom/nodes/Document-constructor.html

[07:10:40.0000] <MikeSmith>
maybe that comment should also cite a bug number ..

[07:12:43.0000] <annevk-cloud>
We could change the spec I suppose, but browsers are inconsistent across labels and not very predictable iirc

[07:13:20.0000] <annevk-cloud>
Ms2ger, I'm at MozFest without laptop

[07:31:57.0000] <CSN>
guys

[07:32:00.0000] <CSN>
i need help

[07:32:13.0000] <CSN>
it's a simple question but i cant find any solution online

[07:32:28.0000] <CSN>
i have added a google webfont to my website

[07:32:43.0000] <CSN>
the ubuntu font to be more precise

[07:32:55.0000] <CSN>
now, I have some content in <em> and <strong> tags

[07:33:25.0000] <CSN>
should i change the font family for em and strong to italic and bold or what? im really confused

[07:54:13.0000] <gsnedders>
CSN: Web fonts load a single font face, so you'll need to explicitly load bold and italic faces too.

[07:54:24.0000] <gsnedders>
CSN: The fact they use "font-family" is really just confusing.

[07:55:05.0000] <CSN>
gsnedders: what should i type and where then? i have no clue

[16:33:39.0000] <annevk-cloud>
Ms2ger: so yeah… that bug getting resolved positively depends on someone answering the overall question differently from me

[16:34:12.0000] <annevk-cloud>
Have not seen a complete argument in that direction yet


2013-10-28
[00:07:26.0000] <Ms2ger>
annevk-cloud, it's resolved positively if you consider it ;)

[00:46:17.0000] <zcorpan>
jgraham: now i get the following error when trying to start wptserve

[00:46:22.0000] <zcorpan>
    from wptserve import server as wptserve, handlers

[00:46:22.0000] <zcorpan>
ImportError: cannot import name handlers

[02:07:53.0000] <zcorpan>
there's no non-rendering almost standards quirk, right?

[02:08:30.0000] <zcorpan>
MikeSmith: any news on FXTF?

[02:08:50.0000] <MikeSmith>
oh

[02:08:55.0000] <MikeSmith>
forgot

[02:08:58.0000] <MikeSmith>
lemme do it now

[02:09:09.0000] <MikeSmith>
zcorpan: for dvcs.w3.org, right?

[02:09:11.0000] <jgraham>
zcorpan: OK, I will fix

[02:09:15.0000] <zcorpan>
my user is spieters

[02:09:17.0000] <zcorpan>
MikeSmith: yeah

[02:09:45.0000] <MikeSmith>
npok

[02:09:51.0000] <MikeSmith>
oops

[02:09:55.0000] <MikeSmith>
ok checking now

[02:12:29.0000] <MikeSmith>
zcorpan: ok should be working now

[02:13:54.0000] <zcorpan>
nice way to resolve bugs http://www.w3.org/2011/webappsec/minutes/webappsec-minutes-27-Aug-2013.html#item03

[02:18:22.0000] <MikeSmith>
haha

[02:20:53.0000] <zcorpan>
MikeSmith: hmm, still get auth failed

[02:21:21.0000] <MikeSmith>
hmm

[02:21:51.0000] <MikeSmith>
zcorpan: you only have one w3c username, right?

[02:22:02.0000] <zcorpan>
yeah

[02:22:45.0000] <zcorpan>
should it work with user+password?

[02:23:46.0000] <MikeSmith>
yeah

[02:23:53.0000] <MikeSmith>
lemmme try right now myself

[02:24:01.0000] <MikeSmith>
with my credentials

[02:27:03.0000] <MikeSmith>
so it works for me

[02:27:33.0000] <MikeSmith>
zcorpan: another thing I can try just for the heck of it is to add you to the "CSS-SVG Task Force"

[02:28:02.0000] <MikeSmith>
the ACLs allows anybody in that DB group to push

[02:28:07.0000] <MikeSmith>
OK if I add you there?

[02:28:13.0000] <zcorpan>
sure

[02:29:15.0000] <MikeSmith>
OK, I've added you

[02:29:20.0000] <MikeSmith>
so please try again

[02:29:35.0000] <MikeSmith>
I don't think it will make a difference but who knows

[02:32:10.0000] <MikeSmith>
yeah error logs show 401 for earlier attempts

[02:43:36.0000] <zcorpan>
/me testing ...

[02:43:52.0000] <zcorpan>
seems to work!

[02:44:18.0000] <zcorpan>
thanks MikeSmith

[02:44:30.0000] <MikeSmith>
cool

[02:47:00.0000] <MikeSmith>
zcorpan: btw I guess you already know there's a big delay when pushing to the csswg repo and the FXTF one too

[02:47:31.0000] <MikeSmith>
it's expected due to stuff on the hg server side that Peter asked me to set up

[03:01:11.0000] <hsivonen>
Lots of words in a destined-to-be-WONTFIXed bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23646

[03:01:36.0000] <MikeSmith>
zcorpan: any idea where the editor's draft of CORS is?

[03:02:47.0000] <annevk-cloud>
MikeSmith: fetch.spec.whatwg.org

[03:02:51.0000] <MikeSmith>
hsivonen: yeah

[03:03:09.0000] <annevk-cloud>
hsivonen: whoah

[03:04:20.0000] <MikeSmith>
annevk-cloud: :) I meant the WebAppSec one. Last I saw they still had your name on it as editor, which seems especially odd now that they've summarily closed bugs you raised against the spec.

[03:05:08.0000] <MikeSmith>
hmm, or are they not even maintaining a separate ED at all?

[03:19:55.0000] <zcorpan>
why maintain a spec if you can INVALID the bugs?

[03:20:25.0000] <zcorpan>
(dunno where the spec is if there is one)

[03:23:51.0000] <hsivonen>
Whoa. Web MIDI. Is Chrome implementing that stuff?

[03:24:19.0000] <MikeSmith>
hsivonen: yeah I think they already have

[03:24:39.0000] <MikeSmith>
cwilso been working on it

[03:25:18.0000] <MikeSmith>
hsivonen: why Whoa? bad idea?

[03:29:25.0000] <MikeSmith>
hsivonen: also https://bugzilla.mozilla.org/show_bug.cgi?id=836897 (re: Web MIDI)

[03:31:55.0000] <odinho>
The CORS-thingy is meant to go through the process about as it is now.

[03:36:21.0000] <MikeSmith>
odinho: if that's how the group wants to do things, I won't complain but I guess it means the W3C spec is just going to become further irrelevant to implementors

[03:37:43.0000] <MikeSmith>
in which case the sooner it goes to Rec the better, I guess

[03:38:04.0000] <odinho>
CORS is not getting a frenzy of updates by annevk-cloud either.  And yes, everyone is clear (I think) that the canonical spec is at fetch.spec.whatwg.org

[03:38:22.0000] <odinho>
At least that's how I think of it.

[03:38:34.0000] <MikeSmith>
ah OK

[03:44:25.0000] <Ms2ger>
zcorpan, bah, high-quality review comments :)

[03:46:50.0000] <cwilso>
Hsivonen: yup, chrome canary on osx has experimental web midi support.  I also wrote an NPAPI-based plugin.

[03:47:11.0000] <cwilso>
And yes, please elaborate "whoa." :)

[03:48:45.0000] <MikeSmith>
http://chrislord.net/index.php/2013/10/28/sabbatical-over/ is a good read; "WebGL cannot be relied upon", "Canvas performance isn’t great", "Appcache is awful", "DOM rendering is slow" ...

[04:03:11.0000] <zcorpan>
Ms2ger: sorry :-P

[04:04:35.0000] <zcorpan>
Ms2ger: you could review my PRs as payback :-)

[04:10:38.0000] <zcorpan>
does w3cmemes have a mod queue for new posts?

[04:12:12.0000] <hsivonen>
cwilso, MikeSmith: whoa as in "I didn't realize Google cared about MIDI peripherals."

[04:13:00.0000] <MikeSmith>
hsivonen: ah OK

[05:05:19.0000] <jgraham>
zcorpan: Pushed the directory listing fixes

[05:06:20.0000] <zcorpan>
jgraham: thanks

[05:14:10.0000] <annevk>
Ms2ger: seems zcorpan already reviewed

[05:14:17.0000] <Ms2ger>
Yeah

[05:15:08.0000] <Ms2ger>
annevk, so I made the characterSet test a case-insensitive match for now, if you don't object

[05:15:15.0000] <annevk>
ew

[05:15:27.0000] <annevk>
I won't object, but ew

[05:15:47.0000] <annevk>
Ms2ger: IE10 does lowercase

[05:16:23.0000] <Ms2ger>
Yeah, agreed with ew

[05:16:38.0000] <Ms2ger>
I'll check if we have a test for characterSet itself already

[05:22:03.0000] <cwilso>
Hsivonen well, some of us definitely do. :)

[05:27:36.0000] <MikeSmith>
cwilso: I guess you know MIDI-peripheral vendors seem to care about Web MIDI too

[05:28:31.0000] <cwilso>
Yeah.  Now I just need to get some other browsers interested.

[05:28:38.0000] <MikeSmith>
yeah

[05:29:03.0000] <cwilso>
And yeah - I'm meeting with some of the this week (I'm in Tokyo)

[05:29:07.0000] <Ms2ger>
cwilso, seems like patches to Gecko might get accepted ;)

[05:29:15.0000] <MikeSmith>
cwilso: ahah

[05:29:51.0000] <cwilso>
Ms2ger: dunno.  Really need some more review of the spec.

[05:29:59.0000] <Ms2ger>
zcorpan, reviewing your PRs hardly seems like payback :)

[05:30:21.0000] <zcorpan>
worth a shot

[05:30:42.0000] <Ms2ger>
Also, those are all complex ones, no? :)

[05:31:28.0000] <Ms2ger>
"move Opera's media tests" - aaah

[05:31:35.0000] <Ms2ger>
"Add media resource selection tests" - aaah

[05:32:25.0000] <Ms2ger>
"Add tests for structured clone for workers" - hrm, maybe

[05:33:09.0000] <MikeSmith>
cwilso: if you're free for lunch some time this week, please ping me. I'll probably be nearby the Mori-tower area tomorrow around lunchtime. I meet up with Dominic Cooney for lunch now and then, and sometimes Eiji Kitamura and others there

[05:34:46.0000] <Ms2ger>
jgraham, uh, looks like you're getting a few error emails from critic :)

[05:34:58.0000] <cwilso>
MikeSmith:  sounds good.  Might be able to do tomorrow, or Wednesday.

[05:36:16.0000] <MikeSmith>
cwilso: OK. I'll try to ping you around 11am or so tomorrow

[05:38:17.0000] <Ms2ger>
/me poofs

[05:41:17.0000] <smaug____>
cwilso: I'd be interested to see midi in gecko, but need to figure out first whether it is possible to get reasonable low latency midi+audio handling

[05:41:49.0000] <smaug____>
midi api should be exposed in workers as the audio api

[05:42:29.0000] <smaug____>
/me has tried to find some midi experts in Finland to comment the spec

[05:42:54.0000] <cwilso>
Smaug:  of course.  Audio latency can be around 3ms;  MIDI should be around that, but I haven't tested yet.

[05:43:35.0000] <cwilso>
And yeah, we've discussed availability in workers, but we should solve that together with audio in workers.

[05:44:38.0000] <smaug____>
cwilso: what kind of latency you get midi-input->synthesizing audio->audio output

[05:46:59.0000] <cwilso>
It's audio hardware dependent, of course - but under ten ms, on osx at least.

[05:47:36.0000] <cwilso>
(Sorry for brevity - on mobile)

[05:48:10.0000] <smaug____>
ok, under 10 is better than I thought

[05:48:46.0000] <smaug____>
anything complex in the main thread ofc breaks that

[05:48:56.0000] <smaug____>
which is why worker support is rather crucial

[06:10:34.0000] <jgraham>
/me is worried Ms2ger works for the NSA

[07:16:07.0000] <annevk>
I guess I should clone those CORS bugs...

[07:21:53.0000] <annevk>
And done...

[07:49:07.0000] <MikeSmith>
I know I'm preaching to the choir here, but how incredibly assheaded is it for a W3C WG to fork a spec from somewhere else and then just ignore legitamate bugs/comments that are raised against the spec, refuse to make any changes to it, and so force the bugs to get cloned

[07:49:52.0000] <MikeSmith>
nobody is forcing the WebAppSec WG to do this

[07:49:56.0000] <annevk>
So what I think is going on here is that Brad wants to publish it as a REC

[07:50:07.0000] <annevk>
Because p-word

[07:50:13.0000] <MikeSmith>
ah

[07:50:26.0000] <annevk>
And he's taking every shortcut he can, although I'm in the loop

[07:50:31.0000] <annevk>
So I might be wrong

[07:50:42.0000] <MikeSmith>
christ the levels of absurdity we have reached here

[07:50:49.0000] <annevk>
I definitely don't hope the plan is for other specifications to reference the CORS REC, that'd be terrible

[07:50:52.0000] <jgraham>
So this kind of feels like a fundamental tension at the W3C

[07:51:08.0000] <annevk>
(And doesn't work anyway.)

[07:51:41.0000] <jgraham>
The W3C's big value proposition is the P— Policy

[07:52:02.0000] <MikeSmith>
jgraham: yeah

[07:52:22.0000] <jgraham>
But having to get specs through a process to Rec. means the specs are, generally speaking, wrong

[07:52:40.0000] <annevk>
I meant to say I'm not in the loop above... All I know about WebAppSec can be observed on the public list.

[07:52:54.0000] <jgraham>
Because the needs of The Process are very different to the needs of implementors

[07:53:36.0000] <MikeSmith>
jgraham: the p policy is still important, since despite years of talking about it, we still offer no alternative for that part

[07:53:47.0000] <MikeSmith>
jgraham: right again

[07:54:15.0000] <jgraham>
This is the fundamental problem that the W3C has to resolve, or someone will come along and eat its lunch

[07:54:55.0000] <gsnedders>
I see no end of people stopping caring about the W3C brand, though, outside of the browser vendors.

[07:55:03.0000] <MikeSmith>
but we would maybe  have that problem regardless of where we did things, if we have any mechanism for getting actual RF agreements

[07:55:28.0000] <jgraham>
gsnedders: Try that sentence again with fewer negatives

[07:56:13.0000] <MikeSmith>
jgraham: I mean maybe we would have such as tension anywhere, if we were to be implementing some way to get RF agreements

[07:56:14.0000] <jgraham>
MikeSmith: It is very unclear that an organisation set up with the goal of having the lowest-overhead-possible process and a RF policy would look much like the W3C

[07:56:30.0000] <jgraham>
MikeSmith: You aren't gsnedders, I think :)

[07:56:32.0000] <MikeSmith>
jgraham: there's only one way to test that

[07:56:40.0000] <gsnedders>
s/no end of people/nobody/

[07:57:31.0000] <jgraham>
gsnedders: Or, with fewer negatives, "People outside the browser vendors continue to care about the W3C brand"?

[07:58:01.0000] <MikeSmith>
annevk: I guess the sad part is that there will be other specs referencing the CORS REC and we won't have any way to stop them

[07:58:02.0000] <gsnedders>
It's sad there's been no real process towards RF agreements, and as long the W3C WGs have more members, the W3C RF agreements will still be more valuable.

[07:58:08.0000] <gsnedders>
jgraham: Indeed.

[07:58:13.0000] <jgraham>
MikeSmith: Yes. If I was the W3C I might be worried that someone was going to test that

[07:58:22.0000] <annevk>
MikeSmith: we'll wave the 386 flag

[07:58:50.0000] <MikeSmith>
hehheh

[07:58:55.0000] <jgraham>
gsnedders: If only the W3C found an easy way to drag its name through the mud. Like getting on board with the DRM people, for example.

[07:59:22.0000] <MikeSmith>
somebody should make an actual 386 flag

[07:59:24.0000] <gsnedders>
jgraham: But most W3C members don't care, AFAICT.

[07:59:58.0000] <jgraham>
gsnedders: Oh, you mean Members

[08:00:20.0000] <annevk>
What have W3C Members ever done for the web?

[08:00:34.0000] <annevk>
Most of them, not much, as far as I can tell

[08:00:59.0000] <jgraham>
Well I find it very hard to understand why most Members even join.

[08:01:00.0000] <annevk>
They pay the W3C, which puts the money towards getting more W3C Members

[08:01:05.0000] <gsnedders>
jgraham: I posit the W3C brand still being valuable is because of the Members.

[08:01:26.0000] <jgraham>
And keeping MikeSmith in trousers

[08:01:29.0000] <jgraham>
That's very important

[08:01:51.0000] <MikeSmith>
I think most sane people care about having an environment to work in that isn't causing redunancy and out-of-date information to be published as standards, and referenced by others as standard

[08:01:59.0000] <jgraham>
gsnedders: Really? Does anyone know or care that Disney and Boeing are part of the W3C?

[08:02:07.0000] <annevk>
jgraham: hah, agreed

[08:02:40.0000] <MikeSmith>
people care

[08:02:48.0000] <annevk>
(with keeping MikeSmith dressed)

[08:02:52.0000] <MikeSmith>
heh

[08:03:09.0000] <MikeSmith>
Members are companies comprised of people

[08:03:19.0000] <jgraham>
People that aren't W3C Team or employees of those companies?

[08:03:21.0000] <MikeSmith>
people who are generally pretty smart

[08:03:39.0000] <MikeSmith>
employees

[08:03:45.0000] <MikeSmith>
jgraham: ^

[08:04:10.0000] <jgraham>
Right. So, I don't think that is relevant to gsnedders' point

[08:04:12.0000] <gsnedders>
jgraham: Evangelism

[08:04:21.0000] <gsnedders>
Which is mostly done by W3C Members, no?

[08:04:26.0000] <gsnedders>
Or rather their employees.

[08:04:42.0000] <jgraham>
Evangalism of what, to whom?

[08:04:54.0000] <gsnedders>
If you want to wreck the W3C's standing, convince browser manufacturers to terminate their membership.

[08:05:06.0000] <gsnedders>
It'd be stupid given the IP rules, but it would make a big statement.

[08:05:17.0000] <MikeSmith>
I would think anybody in the W3C membership who's objectively looking at what the WebAppSec WG is  doing with CORS would have to be kinda wondering WTF?

[08:05:38.0000] <MikeSmith>
anyway, I should shut up and take a break

[08:06:13.0000] <jgraham>
gsnedders: To do that you would need somewhere else to go that had a similar RF agreement

[08:06:51.0000] <jgraham>
Hence my point above that the W3C should be worried that if they don't fix their Process someone will come along with a much lighter-weight process, but the same or similar IPR rules and eat their lunch

[08:07:25.0000] <jgraham>
It would perhaps have happened with WHATWG if we had had the IPR stuff to get Microsoft on board

[08:08:39.0000] <gsnedders>
jgraham: The value of the IPR agreements at the W3C comes from the number of Members, though. What does the WHATWG have to offer? It makes it harder for employees of plenty of orgs to join the mailing list if you require everyone on the mailing list to have agreed to IPR agreement.

[08:08:58.0000] <jgraham>
Does it?

[08:09:13.0000] <annevk>
W3C does not require that either for its mailing lists.

[08:09:15.0000] <jgraham>
It only comes from the Members that are actually in the group publishing the spec

[08:09:49.0000] <annevk>
So I guess I should define document.origin. People have been asking about it for a while now...

[08:10:51.0000] <gsnedders>
annevk: Which mailing lists? I thought this was the reason why public-html-comments was a separate list?

[08:10:58.0000] <annevk>
And so document.origin would return the global object's associated document's origin.

[08:11:13.0000] <annevk>
gsnedders: e.g. I'm on plenty of lists without being a WG Member

[08:11:17.0000] <gsnedders>
jgraham: Well, the number of patents you get RF licensing of is presumably linked to the number of members.

[08:11:42.0000] <gsnedders>
annevk: You're employed by a member though, which seems to have an effect.

[08:11:57.0000] <annevk>
not as far as subscribing rules go...

[08:13:50.0000] <gsnedders>
So, one can still get patented stuff into a W3C spec by sending feedback on a spec, then suing everyone?

[08:13:58.0000] <gsnedders>
Then what's the worth of the patent agreement.

[08:14:13.0000] <gsnedders>
Why not just not "join" any WG, because that means you then need to declare patents?

[08:17:43.0000] <annevk>
gsnedders: dude, given that the W3C blatantly copies WHATWG drafts, there's any number of ways that can happen

[08:19:44.0000] <gsnedders>
Then what does the W3C actually gain you?

[08:19:53.0000] <gsnedders>
And can it please stop raining? I know I'm in Glasgow, but...

[08:21:20.0000] <jgraham>
gsnedders: The W3C gains you that Apple can't sue you. It doesn't prevent Eolas suing you.

[08:23:49.0000] <jgraham>
(other litigators are avaliable)

[09:04:21.0000] <Domenic_>
annevk: seems like it's time to bust out the streams API counterproposal...

[09:04:40.0000] <annevk>
Domenic_: referring to Brian's tweet?

[09:04:51.0000] <Domenic_>
annevk: ya and the public-webapps mailing list post

[09:05:25.0000] <annevk>
Domenic_: would be pretty great if you have the time

[09:05:59.0000] <annevk>
Domenic_: talked with sicking a bit last Tuesday and basically it seems Firefox OS will go with MozStream (details unclear) if we don't have something soon

[09:06:20.0000] <annevk>
Domenic_: (which might be fine as long as it remains contained in the Firefox OS walled garden)

[09:06:42.0000] <Domenic_>
annevk: Yeah well I just finished my major promises refactor so should be able to do it this week/end.

[09:07:06.0000] <annevk>
Domenic_: also talked with Max Ogden at MozFest and he was mostly like "just give us the features" :-)

[09:07:35.0000] <Domenic_>
annevk: haha yeah. he will just build a solid abstraction on top of it, as long as it is possible.

[09:07:43.0000] <annevk>
right

[09:08:20.0000] <Domenic_>
but it would be good to have something usable by specs, not just people who consume Max's libraries :)

[09:10:57.0000] <annevk>
Domenic_: do you want me to email public-webapps about your forthcoming proposal or do it yourself?

[09:11:07.0000] <annevk>
Domenic_: or maybe wait until Monday

[09:11:33.0000] <annevk>
ooh wait, Monday it will have expired

[09:12:30.0000] <Domenic_>
annevk: not sure what would be best. Advertising semi-vaporware seems bad. I could have it done by Sunday-ish. Or I could outline what's wrong with the current proposal pretty quickly? Get Isaac to chip in on that?

[09:14:27.0000] <marcosc>
Domenic_: yeah, comment on the current one.

[09:14:49.0000] <marcosc>
We can postpone the current CFC then

[09:15:07.0000] <marcosc>
We can just mention you have an alternative and need a few more days

[09:15:19.0000] <annevk>
Domenic_: yeah, a hint of sorts that you're working on something seems helpful though

[09:15:22.0000] <marcosc>
Having multiple specs published will be confusing

[09:15:40.0000] <marcosc>
I'm happy to block the other one if need be

[09:16:42.0000] <Domenic_>
kk awesome thanks guys. will reply tonight.

[09:25:15.0000] <Hixie>
i love that a bug not having any activity since it was filed is an argument for closing it

[09:31:27.0000] <Hixie>
cabanier: your most recent e-mail is again lacking in reasons. Any time you write "I think" or "We should" you need to add "because..." or "as shown by..." explaining your reasons, otherwise the feedback just gets dismissed as not having any rationale.

[09:32:20.0000] <Ms2ger>
That sounds better in the active mood

[09:32:33.0000] <Ms2ger>
... otherwise I just dismiss the feedback as ...

[09:33:08.0000] <cabanier>
Hixie: why am I held to a different standard?

[09:33:10.0000] <Hixie>
well it's not necessarily me, the same would apply to any other whatwg spec

[09:33:13.0000] <Hixie>
cabanier: you're not

[09:33:30.0000] <Hixie>
cabanier: you're just particularly bad at giving rationale

[09:33:42.0000] <Hixie>
cabanier: yet give a lot of feedback

[09:34:43.0000] <cabanier>
Hixie: I'm stating how stroking is done. If this was the first email, I'd agree but we've been going back and forth

[09:35:15.0000] <cabanier>
Hixie: Isn't the whatwg spec supposed to reflect what browser do?

[09:35:25.0000] <cabanier>
Hixie: I'm not proposing anything new

[09:35:33.0000] <Hixie>
your most recent e-mail did not provide ay argument showing that what the spec says differs from what browsers do

[09:35:59.0000] <Hixie>
as far as i'm aware, i've already fixed the spec to match what browsers do on every test people have shown a difference on

[09:36:20.0000] <cabanier>
Hixie: OK. I will recheck

[09:37:07.0000] <cabanier>
Hixie: it would be better if the spec describes what actually happens in case there are weird side effects

[09:38:11.0000] <Hixie>
that begs the question of in what way it doesn't currently describe what actually happens.

[09:38:26.0000] <cabanier>
Hixie: I find the current spec very hard to read

[09:38:28.0000] <Hixie>
(woot, i got to use "begs the question" the way the pedants always want it to be used)

[09:39:13.0000] <TabAtkins>
I've given up on that, and just resolved to use the older "beggars the question" for the "proper" meaning.

[09:39:14.0000] <cabanier>
:-)

[09:39:28.0000] <Hixie>
cabanier: if the problem is just that it's hard to read, that's an entirely different argument than "Isn't the whatwg spec supposed to reflect what browser do?"

[09:39:47.0000] <Hixie>
cabanier: hence why it's important to describe your actual problems and reasons and arguments and data

[09:39:53.0000] <cabanier>
ok

[09:40:21.0000] <cabanier>
Hixie: we did settle on the dashing, correct?

[09:40:40.0000] <cabanier>
Hixie: by breaking dashing out, the current spec will already get more readable

[09:40:43.0000] <Hixie>
cabanier: if it's hard to read, then the thing to do is to walk through the spec and show, quoting each statement in the spec, where you are finding it hard to read, what terms are confusing, etc.

[09:41:13.0000] <Hixie>
cabanier: the way i did e.g. here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0345.html

[09:47:40.0000] <annevk>
kinda wish DOM was in WHATWG as well in W3C Bugzilla, would be easier when moving things around

[09:47:58.0000] <Hixie>
you could move the product over

[09:48:04.0000] <Hixie>
since it's a WHATWG spec now anyway

[09:48:10.0000] <Hixie>
or create a new component and move the bugs over

[09:50:12.0000] <annevk>
haha http://nodejsreactions.tumblr.com/

[09:50:34.0000] <annevk>
Hixie: yeah, been thinking about doing just that

[09:51:25.0000] <dglazkov>
good morning, Whatwg!

[09:52:20.0000] <annevk>
oops

[09:52:25.0000] <annevk>
forgot to actually serialize the origin

[10:04:03.0000] <Domenic_>
annevk: GitHub issues FTW?

[10:05:11.0000] <annevk>
Domenic_: I'm still kinda conservative with respect to that...

[10:05:44.0000] <annevk>
Domenic_: Bugzilla has some nice properties such as mailing list integration and being able to move issues between specifications

[10:05:58.0000] <annevk>
Domenic_: but maybe at some point I'll start doing that instead

[10:05:59.0000] <Domenic_>
annevk: I've drunk the coolaid... but yes, I see how those could be useful properties.

[10:06:10.0000] <Domenic_>
annevk: what do you mean mailing list integration?

[10:06:23.0000] <annevk>
I could give it a go maybe for the Notifications API

[10:06:33.0000] <Ms2ger>
Github issues are pretty terrible

[10:06:43.0000] <annevk>
Domenic_: just that emails go to the mailing list if someone opens a new issue or one is resolved

[10:06:46.0000] <annevk>
Ms2ger: not useful

[10:07:04.0000] <Ms2ger>
Sure, not useful either ;)

[10:07:32.0000] <Domenic_>
annevk: ah OK. Yeah I guess you could hack it by creating a GitHub user for that mailing list and having him watch the repo, but, meh.

[10:07:53.0000] <gsnedders>
It's so plainly obviously fucked up when "working to contracted hours" is sufficient to be considered practically a strike.

[10:07:56.0000] <Domenic_>
annevk: on the other hand most devs are much happier with teh GitHub interface than the mailing list interface.

[10:08:00.0000] <gsnedders>
(Universiy teaching staff, in the UK)

[10:08:18.0000] <annevk>
Domenic_: yeah, seems like you might get some kind of involvement that is lacking now

[10:08:36.0000] <jgraham>
annevk: Ms2ger is right though, they are

[10:09:04.0000] <Ms2ger>
(For once)

[10:10:49.0000] <annevk>
jgraham: not useful

[10:11:33.0000] <Ms2ger>
annevk, itym "please elaborate"

[10:11:47.0000] <annevk>
itym?

[10:12:21.0000] <jgraham>
annevk: Well it's pretty annoying that the rallying cry is "GitHub all the things" when GitHub isn't obviously a win

[10:13:10.0000] <annevk>
jgraham: given that everyone and their dog is on GH you really have to say something more coherent than that

[10:13:44.0000] <jgraham>
Everyone and their dog is on twitter too, but it doesn't make it a good medium for spec development

[10:13:58.0000] <jgraham>
So you'll need a better argument than "look at all the people"

[10:14:36.0000] <jgraham>
I don't have a problem with hosting specs on github

[10:16:05.0000] <jgraham>
But I think that the issue tracker sucks compared to almost all other issue trackers

[10:16:40.0000] <Domenic_>
It depends on what features you want

[10:16:42.0000] <Domenic_>
It definitely has holes

[10:16:46.0000] <annevk>
Well Domenic_ gave his argument. Developers are familiar with doing development on GH. Specifications are already on GH. We could move a larger part of that development there, to more closely involve everyone following the specification there.

[10:16:47.0000] <Domenic_>
But those holes don't impact my use cases

[10:16:51.0000] <jgraham>
And there is a tendecy to ghettoise because you have to actively know about the spec and subscribe to a huge firehose of notifications

[10:17:14.0000] <annevk>
public-webapps⊙wo is a similar firehose though...

[10:17:19.0000] <annevk>
And less focused.

[10:17:22.0000] <Domenic_>
Whereas its ergonomics are *way* better, in terms of ecosystem integration, Markdown support, lightweight tags and milestones, a sane notification interface, ...

[10:18:19.0000] <jgraham>
I really don't consider the GH notification system to be a "feature"

[10:18:19.0000] <Domenic_>
It's definitely a value judgement though, whether you prefer the features of other issue trackers over the ones GitHub provides (including the community involvement it brings).

[10:18:40.0000] <Domenic_>
I really like them. Nice to get them bucketed.

[10:18:41.0000] <jgraham>
And I don't think that merely being on GitHub brings community involvement

[10:19:01.0000] <Domenic_>
Obviously not. It just lowers the barrier to both entry and continued participation.

[10:19:27.0000] <jgraham>
Really?

[10:19:33.0000] <umgrosscol>
Yeah.  You can just git it.

[10:20:04.0000] <annevk>
jgraham: yes, you don't have to create a Bugzilla account

[10:20:09.0000] <annevk>
jgraham: or subscribe to a mailing list

[10:20:13.0000] <umgrosscol>
Single link to the project, and it makes contributing pretty easy.

[10:20:30.0000] <jgraham>
For example, a lot of the feedback on specs is from a mail to a mailing list that someone who might previously have been unaware of the spec can respond to intelligently based on their knowledge of the web platform

[10:20:41.0000] <jgraham>
But with github you have to know that the repo exists

[10:21:01.0000] <Domenic_>
the mailing list <-> spec correspondence is insanely arcane

[10:21:03.0000] <TabAtkins>
That's my big problem with doing things solely on github, too - the fact that you have to magically know that a given repo exists.

[10:21:07.0000] <Domenic_>
and the archives are not easy to interface with

[10:21:28.0000] <Domenic_>
as for the repo's existence, i find organizations can be quite helpful with that. i like browsing through github.com/whatwg and such.

[10:21:44.0000] <Domenic_>
but I am not sure even where I would browse on the W3C's site to find all the specs under development?

[10:21:46.0000] <TabAtkins>
The archives aren't *great*, but I've repeatedly stumbled on spec repos only *well after* they've started making progress, when someone mentions the repo on a mailing list.

[10:21:55.0000] <Domenic_>
last time I did that I found a bunch of XHTML2 stuff.

[10:21:56.0000] <jgraham>
I don't generally spend my time browsing for repos that might exist

[10:22:18.0000] <jgraham>
and if I did I wouldn't know where to start on githib. Your personal account?

[10:22:43.0000] <jgraham>
Some specific organisation for a single project/spec?

[10:22:54.0000] <Domenic_>
I guess I don't understand why this problem is unique to GitHub vs. to wherever the WHATWG or W3C hosts their specs?

[10:23:07.0000] <Domenic_>
Mailing list lurkers need to be made aware of a new mailing list/spec URL somehow.

[10:23:35.0000] <Domenic_>
whether that URL starts with github.com or not doesn't seem to make things more or less easy to find.

[10:23:43.0000] <jgraham>
The WHATWG only has one mailing list. TC39 has one mailing list. The W3C has a few relevant ones broadly split up by area

[10:23:55.0000] <TabAtkins>
*Anyone* talking about the spec on a mailing list alerts all the lurkers.  Anyone talking about the spec in a github issue alerts no one that isn't already following the spec.

[10:24:08.0000] <jgraham>
And as I said before it's not the actual hosting that's the problem

[10:24:37.0000] <Domenic_>
Ah so you appreciate the constant reminders of a spec's existence that come from conflating its issue tracking into the general whatwg mailing list.

[10:24:43.0000] <jgraham>
For example it would be an improvement if Hixie hosted HTML on GH. But it would be much worse if he moved discussion to there

[10:24:47.0000] <TabAtkins>
Domenic_: Basically, yeah.

[10:24:55.0000] <TabAtkins>
What jgraham just said, too.

[10:25:23.0000] <TabAtkins>
Domenic_: It's just a social issue, unfortunately.  If you're not already looped into the right cliques, GH is much harder to follow.

[10:25:35.0000] <Hixie>
jgraham: there's a github repo that mirrors the svn repo, fwiw

[10:25:37.0000] <Hixie>
foolip maintains it

[10:25:51.0000] <jgraham>
Hixie: I know that :)

[10:25:54.0000] <Hixie>
k

[10:26:00.0000] <Domenic_>
TabAtkins: and I guess the argument is that getting looped into a single whatwg mailing list is easier than getting looped into the right GH cliques? makes sense i guess.

[10:26:21.0000] <Domenic_>
If this is a real issue though it's easy to solve, by making a whatwg user that watches all under-development specs.

[10:26:25.0000] <TabAtkins>
Yeah, one is a single point, easily communicated or stumbled upon.  The latter is a mishmash of social circles.

[10:26:37.0000] <TabAtkins>
Domenic_: Solve it first, then ask to switch. ^_^

[10:26:53.0000] <TabAtkins>
Don't deprecate the existing solution while the new solution isn't finished yet.

[10:27:11.0000] <Domenic_>
TabAtkins: seems doable. Just never realizde that people wanted that feature.

[10:28:07.0000] <Domenic_>
Maybe if annevk moves notifications to GH he can set up that watched-by whatwg⊙wo association as a good test.

[10:28:36.0000] <TabAtkins>
Does that spam the mailing list with every commit?

[10:28:42.0000] <Domenic_>
no just issues

[10:28:45.0000] <jgraham>
/me thinks that will just fragment the discussion

[10:28:55.0000] <TabAtkins>
New issues, or every comment to an issue?

[10:29:04.0000] <Domenic_>
both

[10:29:14.0000] <TabAtkins>
Hm, okay.

[10:29:26.0000] <Domenic_>
you've used GitHub before right? And gotten emails from it for projects you're watching?

[10:29:30.0000] <TabAtkins>
Yeah.

[10:29:37.0000] <Domenic_>
yeah should be just like that.

[10:29:50.0000] <umgrosscol>
They get nicely sorted by gmail, if you use that.

[10:30:11.0000] <TabAtkins>
Just making sure it's not leaning too far into the spam territory.  Mailing lists, while noisy, at least have humans behind the wheel that prevent accidentally sending 500 unique messages in a few minutes.

[10:30:21.0000] <Domenic_>
nice feature: if people stay inside their mail clients and reply, the reply gets into the issue tracker just fine, but the conversation can continue by email. I guess this is just a parity-bugzilla feature though tbh.

[10:30:33.0000] <jgraham>
But you couldn't reply to a mail from GH, address it to whatwg@ and have it show up in GH. So you need to be super-careful about how you reply

[10:30:33.0000] <jgraham>
Otherwise people will miss stuff

[10:30:39.0000] <Domenic_>
Right, but I mean, that's the same thing as how bugzilla spams mailing lists.

[10:31:00.0000] <Domenic_>
jgraham: indeed if you change the "To" header it'll not show up.

[10:31:20.0000] <Domenic_>
jgraham: seems the same as bugzilla I assume?

[10:31:44.0000] <jgraham>
Yeah, the bugzilla integration with mailing lists has also not been great :|

[10:32:11.0000] <jgraham>
/me has always got all commits and issues when he subscribed to a GH repo

[10:32:28.0000] <jgraham>
And all other random things too

[10:32:29.0000] <annevk>
We could set up whatwg-issues maybe

[10:32:45.0000] <annevk>
Or whatwg-gh

[10:34:22.0000] <annevk>
And we can set up email preferences to be sane

[10:34:43.0000] <annevk>
MikeSmith: maybe we can get public-whatwg-github⊙wo or some such?

[10:34:52.0000] <annevk>
Hixie: or would you prefer this to be on whatwg⊙wo?

[10:35:09.0000] <annevk>
TabAtkins: jgraham: Domenic_: ^^

[10:35:23.0000] <Hixie>
what's the problem we're trying to solve here?

[10:36:06.0000] <Domenic_>
I believe: Tab likes having one mailing list to subscribe to in order to get ambient notifications about all new and ongoing spec activity.

[10:36:17.0000] <jgraham>
/me wonders where this setting is to only get issue comments and not other types of notifications

[10:36:41.0000] <TabAtkins>
More specifically: Moving spec dev to GitHub and using GitHub Issues to track issues has a number of benefits over using mailing lists, but you lose the ambient notification quality of MLs.

[10:37:06.0000] <jgraham>
As far as I can tell the level of granularity is "single issues" or "everything"

[10:37:14.0000] <Hixie>
imho we should stick to a minimum number of mechanisms

[10:37:15.0000] <jgraham>
But I will be very happy if I am wrong

[10:37:18.0000] <Hixie>
a mailing list, a bug system

[10:37:23.0000] <Hixie>
we have too many of both already

[10:37:27.0000] <TabAtkins>
I'm hoping there's a way to get "all issues, no commits".

[10:38:20.0000] <annevk>
Hixie: make it easier for everyone on GH to give feedback and get involved in spec development

[10:39:05.0000] <annevk>
Hixie: we use GH issues for javascript.spec.whatwg.org at the moment

[10:39:06.0000] <Domenic_>
TabAtkins: jgraham: I've never found the ability to get notifications on all commits (unless someone tagged me in them); would actually love to be able to turn that on in some cases.

[10:39:19.0000] <Hixie>
easier than what? right now contributing to HTML just involves loading the spec, typing in a box, and hitting enter

[10:39:41.0000] <Hixie>
there's a point below which making it easier to participate starts making it too easy for us to get spammed or receive junk feedback...

[10:39:56.0000] <Hixie>
(that point might be the form on the w3 TR/ page, i get a ton of nonsense feedback through those forms)

[10:40:09.0000] <annevk>
Hixie: that's one-off feedback which doesn't really give good ways for follow ups

[10:40:24.0000] <Hixie>
plenty of people cc themselves on those bugs

[10:40:35.0000] <Hixie>
or leave their e-mail address

[10:40:51.0000] <Hixie>
(though in my experience they rarely respond to e-mails when i follow up with them directly)

[10:41:27.0000] <jgraham>
Domenic_: Hmm, maybe you are right. It might be that I was thinking of repos that have noisy bots adding comments for each commit

[10:43:20.0000] <annevk>
Lol, some guy on Twitter suggests DRM should be in WHATWG instead. Not very good at reading tea leaves it seems...

[10:43:29.0000] <Domenic_>
O_____o

[10:43:39.0000] <gsnedders>
annevk: Hey, it would all be okay if it were!

[10:43:45.0000] <gsnedders>
The WHATWG design better stuff!

[10:43:55.0000] <jgraham>
(so it's still all-or-nothing for notifications, which is generally very annoying, but might be OK for this use case)

[10:43:57.0000] <Hixie>
DRM in the WHATWG would be a very short spec

[10:44:40.0000] <TabAtkins>
"No"

[10:45:41.0000] <jgraham>
We could give them the spec encrypted, and explain that we don't trust them not to use it in a way that breaks various laws related to reverse engineering, fair use, etc.

[10:46:05.0000] <jgraham>
*that doesn't break

[10:46:06.0000] <jgraham>
/me gives up

[10:47:22.0000] <annevk>
Hixie: So I agree that generally I want fewer ways of doing something. It's just not completely clear to me the current GitHub / Bugzilla / Email setup is the best. Making it GitHub / Email seems like we'd have less in the end and less things to learn.

[10:47:45.0000] <annevk>
Hixie: there's a transition cost of course.

[10:48:31.0000] <jgraham>
(just because someone will say this: it would also mean that we had a greater dependence on third-party infrastructure)

[10:49:54.0000] <Ms2ger>
Third party to the W3C? ;)

[10:50:39.0000] <Hixie>
annevk: github is the one from that pile that i would most quickly dispose of :-)

[10:51:13.0000] <Ms2ger>
Hixie++

[10:51:52.0000] <Hixie>
i know it's all the rage today, but so was code.google.com before that, and sourceforge before that, and most developers don't use any of these

[10:52:33.0000] <Hixie>
optimising for "developers who use github" is short-sighted imho

[10:53:06.0000] <Hixie>
not saying there's anything _wrong_ with github

[10:53:09.0000] <Hixie>
and using it is fine

[10:53:24.0000] <Hixie>
just, we should be careful not to assume it's The One True Way

[10:53:56.0000] <Hixie>
mailing lists and bugzilla might not be the current fashion, but they're proven technologies that are highly mature and have been used for literally decades

[10:54:15.0000] <Hixie>
(ok, 1.something decades in bugzilla's case)

[10:54:25.0000] <jgraham>
I don't think that code.google.com was ever all the rage :) But I think there is substance to the general point

[10:54:44.0000] <Hixie>
it was all the rage enough that we hosted a bunch of stuff on it before transitioning to github

[10:54:53.0000] <jgraham>
That is true

[10:54:57.0000] <Domenic_>
I don't think anyone's claiming GH is The One True Way. Just that it has advantages worth pursuing.

[10:55:19.0000] <Hixie>
what are those advantages?

[10:55:25.0000] <annevk>
And in fact, the current proposal was to have a mailing list backup of everything going on GitHub.

[10:55:26.0000] <Ms2ger>
"It's github"

[10:55:51.0000] <annevk>
Hixie: familiar to part of our target audience

[10:56:12.0000] <Hixie>
lots of things are familiar to part of our target audience

[10:56:28.0000] <Hixie>
if we're going by that, we should probably move all development to a facebook group

[10:58:06.0000] <annevk>
I wonder how you end up there

[10:58:24.0000] <annevk>
I don't know anyone who uses FB for development other than FB engineers

[10:58:30.0000] <Ms2ger>
More of our target audience are on facebook than on github?

[10:58:31.0000] <TabAtkins>
Because Hixie likes reductio ad adbsurdum?

[10:58:41.0000] <marcosc>
It might be best to think about this in terms of the people we want to participate in the spec development process at particular stages. Like Service Workers was a closed group of folks working on stuff first stuff... then opened up a bit to more folks on GH. Eventually, dev of that spec will likely move to a mailing list or continue on GH.

[10:59:17.0000] <Ms2ger>
marcosc, that's a pretty good point against gh

[10:59:44.0000] <marcosc>
it might be... that's not the point tho. I'm just saying that it's about finding what is best for people to collaborate on stuff

[10:59:55.0000] <annevk>
Yes, because us not using GH issues will totally prevent that from happening. Oh wait it didn't Ms2ger...

[10:59:59.0000] <Hixie>
the way Service Workers has been developed is a case study in how now to do things

[11:00:03.0000] <Hixie>
how not to do things

[11:00:14.0000] <marcosc>
now or not?

[11:00:19.0000] <Ms2ger>
Not

[11:00:27.0000] <marcosc>
Hixie, why is that?

[11:00:42.0000] <annevk>
(Not that I think doing development in private is ever a good idea, but it seems unrelated.)

[11:01:38.0000] <Hixie>
marcosc: because it was designed in a silo without seeking feedback from people who are likely to disagree with the design

[11:02:02.0000] <Hixie>
marcosc: it's the best way to end up with a tech that doesn't take off

[11:02:15.0000] <Ms2ger>
In any case, it seems that gh issues make it impossible to receive a different amount of email than everything or nothing

[11:02:37.0000] <jgraham>
Can we pretend that service workers wan't mentioned? I think that's a path we don't want to go down

[11:02:39.0000] <TabAtkins>
Ms2ger: I don't understand that objection.  Mailing lists give you everything.

[11:02:49.0000] <Ms2ger>
What?

[11:02:52.0000] <TabAtkins>
Unless you meant "also commit messages" by "everything"?

[11:02:54.0000] <Hixie>
i really don't understand what we're trying to solve here.

[11:03:02.0000] <Ms2ger>
I don't want everything

[11:03:06.0000] <Ms2ger>
I also don't want nothing

[11:03:13.0000] <TabAtkins>
I don't know what you mean by "everything".

[11:03:21.0000] <Ms2ger>
All comments ever

[11:03:31.0000] <TabAtkins>
I want every issue and comment.  That's precisely what I get today on mailing lists.

[11:03:36.0000] <Ms2ger>
I don't!

[11:03:48.0000] <Ms2ger>
But gh issues supports your preference, not mine

[11:03:56.0000] <TabAtkins>
Then you're screwed in all cases, I guess?

[11:03:57.0000] <jgraham>
Hixie: So, in the spirit of trying to argue both sides, I think that the high level goal is to get more people who are web technology users but aren't browser engineers to give feedback on specs

[11:04:11.0000] <Ms2ger>
Not with bugzilla

[11:04:22.0000] <Hixie>
jgraham: ok, that seems like a solid goal.

[11:11:40.0000] <Hixie>
walk me through what you think it would look like to file feedback on github, for the reviewer and the editor. i'm nothing if not willing to be convinced. :-)

[11:11:48.0000] <Ms2ger>
Plausibly more people know how to do it / have an account on github vs the w3c bugzilla

[11:11:59.0000] <jgraham>
Right, but we are assuming as an axiom that there exists a large population of users who are comfortable with that kind of thing on GH but not bugzilla

[11:12:42.0000] <jgraham>
I *also* assume that there is a class of bugs that don't work well with the inout widget in the spec

[11:12:48.0000] <Ms2ger>
A way to subscribe to bugs without having to deal with bugzilla somehow might be interesting

[11:12:56.0000] <jgraham>
Things like "this whole design sucks"

[11:13:11.0000] <jgraham>
Which might need to be longer than one text input

[11:13:27.0000] <jgraham>
And that is also a kind of feedback we would like

[11:13:29.0000] <Hixie>
well for that kind of feedback you really need a mailing list

[11:13:48.0000] <Hixie>
/me hasn't been impressed by github for _any_ kind of feedback

[11:14:32.0000] <marcosc>
I guess fixing Bugzilla so people can log in with Twitter, GH, or even FB might help?

[11:14:42.0000] <jgraham>
So I think the idea here is that the spec would have a home on gh like github.com/whatwg/brain-transfer

[11:14:57.0000] <jgraham>
And the issue tracker would be enabled

[11:15:26.0000] <jgraham>
But all issue notifications would *also* be sent to the mailing list

[11:16:00.0000] <jgraham>
So people could write their long issue on GH and just subscribe to that issue

[11:16:20.0000] <jgraham>
Or they could subscribe to all notifications just for that spec

[11:16:30.0000] <jgraham>
Or they could get notifications for all specs

[11:16:44.0000] <Hixie>
this would be a separate list? like whatwg-commits?

[11:17:09.0000] <jgraham>
It could be, but I guess then only zcorpan would subscribe and it would be rather pointless

[11:17:42.0000] <jgraham>
IMHO, anything we do is a failure if it doesn't pass the "bz test"

[11:17:59.0000] <jgraham>
Which is more or less what it sounds like

[11:18:12.0000] <Ms2ger>
Bugzilla or Boris?

[11:18:19.0000] <jgraham>
Boris

[11:18:43.0000] <jgraham>
i.e. given some discussion happening, will someone who engages in the way that bz does see the discussion

[11:18:54.0000] <jgraham>
And have the chance to comment on it

[11:19:06.0000] <marcosc>
how does bz engage that is differently from other people?

[11:19:25.0000] <jgraham>
I don't know

[11:19:43.0000] <jgraham>
But he is very good at providing "ambient" feedback

[11:19:58.0000] <Hixie>
i really don't get why mailing lists are so hard here

[11:20:01.0000] <Hixie>
but ok

[11:20:11.0000] <Ms2ger>
People don't like mailing lists much ;)

[11:20:16.0000] <marcosc>
email sucks

[11:20:24.0000] <jgraham>
Well I also don't think that mailing lists are hard, obviously

[11:20:26.0000] <Ms2ger>
It's only better than all the alternatives

[11:20:49.0000] <Ms2ger>
jgraham, you're pretty literally a rocket scientist, though

[11:20:51.0000] <marcosc>
some people just seem to have more meaningful interactions on things like GH issues

[11:20:57.0000] <Ms2ger>
(Except maybe nntp)

[11:21:10.0000] <jgraham>
Really?

[11:21:21.0000] <jgraham>
marcosc: ^

[11:21:29.0000] <cabanier>
Hixie: didn't you have a jsfiddle-like site? Should I use that to post samples?

[11:21:35.0000] <Ms2ger>
bit.ly/livedom

[11:21:47.0000] <jgraham>
Some distressingly high fraction of GH issue comments are inane comments

[11:21:47.0000] <cabanier>
Hixie: codepend and jsfiddle are not permanent

[11:21:54.0000] <jgraham>
s/comments/graphics/

[11:22:29.0000] <cabanier>
Ms2ger: is that permanent?

[11:22:50.0000] <Ms2ger>
cabanier, permanent how?

[11:22:53.0000] <jgraham>
One *big* disadvantage of this kind of proposal is that it will make it much harder to exert the kind of etiquette controls that you can on a mailing list

[11:23:16.0000] <cabanier>
Ms2ger: If I create it and link to it from a message, will it ever be deleted?

[11:23:44.0000] <jgraham>
cabanier: It comes with a real long URL

[11:23:48.0000] <jgraham>
Just use that

[11:24:16.0000] <marcosc>
jgraham: sure. It's the point I was trying to make earlier. Depending on the group: some people like mailing lists, other people like GH issues, other like other things or a combination.

[11:25:03.0000] <marcosc>
jgraham: the inane comments just serve as a replacement for IRC

[11:25:32.0000] <jgraham>
IRC doesn't go to my inbox

[11:26:13.0000] <Ms2ger>
I can fix that

[11:26:59.0000] <marcosc>
heh

[11:27:27.0000] <Ms2ger>
One email per line, you say?

[11:27:55.0000] <marcosc>
Ms2ger: he particularly needs to know when people join and leave the channel

[11:28:03.0000] <Ms2ger>
Ouch

[11:28:08.0000] <Ms2ger>
Even *I* wouldn't be that cruel

[11:35:02.0000] <Hixie>
jgraham: well my experience with w3c lists is we _definitely_ don't want bugzilla bugs forwarding to a mailing list with discussion. that's a recipe for driving people away.

[11:35:11.0000] <Hixie>
jgraham: but anyway

[11:35:21.0000] <Hixie>
if people want to try using github as a source of issues, i'm all for y'all trying

[11:38:13.0000] <jgraham>
FWIW the webapps solution where the new bug notification comes to the list is an OK compromise

[11:38:43.0000] <jgraham>
But you can't do that with GH (unless you build a custom thing using the API)

[11:39:04.0000] <Hixie>
i don't read web-apps anymore in part because of that, fwiw

[11:39:08.0000] <jgraham>
Heh

[11:39:37.0000] <jgraham>
You probably use the bug tracker as a bug tracker more than most people though

[11:39:51.0000] <annevk>
Hixie: so you're okay with missing out on what issues are filed and what's decided on in Bugzilla?

[11:40:34.0000] <jgraham>
So one compromise solution (which might just combine the worst parts of all worlds)

[11:40:34.0000] <jgraham>
Is that you build a special thing that uses the GH API

[11:41:06.0000] <jgraham>
And sends one email per issue to the main list, with a single click link to opt in to getting more mail for that issue

[11:42:00.0000] <jgraham>
Bonus points if it deletes messages containing graphics with prejudice

[11:42:10.0000] <jgraham>
s/messages/comments/

[11:42:25.0000] <Hixie>
annevk: there is zero way i can keep track of everything that's going on on every web spec

[11:42:37.0000] <Hixie>
annevk: i trust the editors to take feedback into account and do the right thing

[11:42:49.0000] <Hixie>
annevk: and for them to cc me when they think i might have a relevant opinion

[11:43:40.0000] <Hixie>
(i can barely keep track of the stuff that affects the spec i edit, heh)

[11:45:08.0000] <Ms2ger>
You can?

[11:46:07.0000] <annevk>
Seems fair. Open bugs are still accessible via the standard... Might be transparent enough although not super useful towards newcomers with knowledge about a particular subject.

[11:46:27.0000] <Ms2ger>
jgraham, no tests/non-functional dir in wptserve?

[11:46:54.0000] <jgraham>
Ms2ger: All my tests function!

[11:47:21.0000] <jgraham>
But in this case the atonym of "functional" would be "unit". And indeed there are no unit tets.

[11:47:31.0000] <Ms2ger>
jgraham, I see

[11:47:34.0000] <annevk>
It happens quite often that people I had not thought of ask about some issue (in a way that suggests they've done a bunch of work) that's been long on file. Always feels like a waste of time for them.

[11:48:04.0000] <Hixie>
annevk: how do you mean?

[11:49:05.0000] <Ms2ger>
jgraham, does docs/makefile come from somewhere?

[11:49:14.0000] <jgraham>
Ms2ger: Sphinx

[11:49:21.0000] <annevk>
Hixie: e.g. someone will do some research around something incompatible they've found only to realize it's already been done before one I point towards the bug

[11:49:26.0000] <jgraham>
Ms2ger: I would never write a Makefile :)

[11:49:32.0000] <jgraham>
/me is not MikeSmith 

[11:49:34.0000] <Ms2ger>
Heh

[11:49:36.0000] <annevk>
once*

[11:49:48.0000] <Ms2ger>
They're not too terrible for small things

[11:50:51.0000] <Hixie>
annevk: ah, yeah. making the bugs more visible in the spec would help with that, but we already don't expose e.g. the mailing list feedbac in that manner.

[11:51:08.0000] <Hixie>
annevk: (i don't see how github issues would make this any better, though maybe you're not saying it would)

[11:52:06.0000] <annevk>
I'm not saying GH would make this better. This is separate.

[11:52:58.0000] <Ms2ger>
jgraham, is the output of the docs somewhere?

[11:53:11.0000] <Hixie>
annevk: k

[11:54:26.0000] <jgraham>
Ms2ger: http://wptserve.readthedocs.org/en/latest/

[11:55:38.0000] <Ms2ger>
Ta

[11:56:44.0000] <Ms2ger>
jgraham, hrm, is :: at the end of a line some special syntax?

[11:57:40.0000] <jgraham>
Ms2ger: Yeah

[11:57:47.0000] <jgraham>
ReST is kind of horrible

[11:58:39.0000] <jgraham>
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#literal-blocks

[11:59:11.0000] <Ms2ger>
FAscinating

[12:01:19.0000] <Ms2ger>
jgraham, I'll assume you didn't write make.bat either ;)

[12:07:30.0000] <annevk>
zcorpan: https://github.com/w3c/web-platform-tests/pull/319#commits-pushed-fe71648

[12:08:23.0000] <jgraham>
Ms2ger: That would be a good assumption :)

[12:09:25.0000] <jgraham>
annevk: It's OK zcorpan *reads* his critic email :)

[12:48:28.0000] <Ms2ger>
jgraham, is wptserve py3k-ready?

[12:56:38.0000] <Hixie>
anyone on non-mac around? i'm looking to see what http://www.hixie.ch/tests/adhoc/html/global-attributes/title/003.html does on non-mac browsers

[12:58:43.0000] <TabAtkins>
What exactly do you want me to report?

[13:05:43.0000] <Hixie>
reload it, look at the tooltip on the last one. what does it look like? (screenshot might be easiest)

[13:06:03.0000] <Hixie>
i'm trying to work out how many spaces the browsers are using as the replacement for 'tab'

[13:11:20.0000] <TabAtkins>
okay, sent

[13:12:45.0000] <Hixie>
thanks!

[13:17:28.0000] <Hixie>
TabAtkins: where did you send it?

[13:17:36.0000] <TabAtkins>
ian⊙hc

[13:17:42.0000] <Hixie>
k

[13:17:45.0000] <Hixie>
/me pokes his server

[13:18:33.0000] <jgraham>
Ms2ger: No

[13:22:14.0000] <Krinkle>
MikeSmith: Hi, I noticed you mentioned "ResourceLoader".

[13:22:35.0000] <Krinkle>
If you have any questions regarding the meta tag in Wikipedia's MediaWiki software, I can answer any :)

[13:27:15.0000] <Hixie>
TabAtkins: fwiw, still haven't gotten it :-(

[13:28:33.0000] <TabAtkins>
It's in my sent mail from 17 minutes ago.

[13:28:57.0000] <Hixie>
i have nothing from you since 10:50am

[13:29:54.0000] <Hixie>
aah, e-mail.

[13:30:01.0000] <Hixie>
i loe you so.

[13:30:04.0000] <Hixie>
love, even

[13:30:11.0000] <Hixie>
though "loathe" might be closer?

[13:30:40.0000] <Hixie>
TabAtkins: well in any case, https://www.w3.org/Bugs/Public/show_bug.cgi?id=22973 is the bug for that test, if you have anything to comment on it

[13:30:59.0000] <Hixie>
(mostly pasting that here so i can find it again when i do get your mail)

[13:43:25.0000] <TabAtkins>
Hixie: I just attached it to the bug.

[13:46:54.0000] <Hixie>
thanks

[13:56:30.0000] <Hixie>
TabAtkins: wohay, got your e-mail

[13:56:37.0000] <Hixie>
TabAtkins: my server must just have been taking the day off

[14:50:14.0000] <Hixie>
TabAtkins: what's the story on the 'content' property in CSS applying to elements, do you know?L

[14:50:17.0000] <Hixie>
-?

[14:50:21.0000] <Hixie>
er, +?, -L.

[14:50:39.0000] <TabAtkins>
The spec says to do it, it's just a matter of browsers actually doing so.

[14:51:06.0000] <Hixie>
do you know which spec it's in?

[14:51:21.0000] <TabAtkins>
Content

[14:51:26.0000] <Hixie>
thanks

[14:52:11.0000] <Hixie>
hm, is there a more up to date version than http://dev.w3.org/csswg/css-content/ ? that says it's dead.

[14:52:27.0000] <matjas>
afaik only old Opera (<= 12) implemented that

[14:52:34.0000] <matjas>
…unfortunately

[14:53:16.0000] <Hixie>
oh wow, parts of that still refer to my old 'move-to' idea

[14:53:30.0000] <TabAtkins>
Nah, I haven't taken the time to fix it up yet.

[14:53:36.0000] <Hixie>
k

[14:53:51.0000] <Hixie>
we're fast coming up on the date i said i'd actually resume work on that spec

[14:53:53.0000] <Hixie>
that's scary

[15:07:55.0000] <zcorpan>
Hixie: what date?

[15:12:29.0000] <Domenic_>
I still want ::before::before::before and ::after(5) and all that. That was a great spec.

[15:15:30.0000] <Hixie>
cabanier: i haven't changed the canvas stuff in at least a week...

[15:16:26.0000] <Hixie>
zcorpan: 2018, iirc

[15:16:47.0000] <Hixie>
Domenic_: that's a great example of what i come up with when i just brute-force my way to a solution and ignore design aesthetics. :-)

[15:20:07.0000] <Domenic_>
Hixie: oh man I didn't even notice the editor, awesome :D.

[15:22:58.0000] <Hixie>
i wish we'd come up with a good way to wrap siblings in a pesudo-element

[15:33:17.0000] <cabanier>
Hixie: you did it 2 weeks ago. "[giow] (3) Change how tracing a path works so that it's more similar …"

[15:34:29.0000] <cabanier>
Hixie: I didn't realize you changed the spec until I started reading it :-)

[15:37:05.0000] <crocket>
hi guys

[15:37:14.0000] <crocket>
Is HTML5 still a moving target?

[15:37:19.0000] <Hixie>
HTML5 is dead

[15:37:21.0000] <Hixie>
long live HTML!

[15:37:31.0000] <crocket>
Hixie : not funny

[15:37:40.0000] <Hixie>
no i mean that seriously

[15:37:43.0000] <Hixie>
we dropped the version number

[15:37:47.0000] <Hixie>
http://whatwg.org/html

[15:38:07.0000] <crocket>
Hixie : What about WC3?

[15:38:12.0000] <crocket>
Did WC3 also drop 5?

[15:38:27.0000] <Hixie>
the w3c forked html a while back and have kinda gone into the weeds

[15:38:59.0000] <crocket>
Hixie : Does it mean WC3 HTML is incompatible with WHATWG HTML?

[15:39:01.0000] <jgraham>
crocket: Browsers are a moving target

[15:39:19.0000] <jgraham>
crocket: But by, and large, the things that work today will continue to work tomorrow

[15:39:21.0000] <crocket>
jgornick: If HTML moves too, it's hard to get on the train.

[15:39:37.0000] <jgraham>
and that fact has nothing to do with the status of the spec

[15:39:42.0000] <crocket>
I want to get on the web bandwagon.

[15:40:01.0000] <crocket>
Is it a mistake to read an HTML5 book now?

[15:40:03.0000] <Hixie>
crocket: you'd have to ask them (whether there's is compatible with the trunk/whatwg version of html), because last i heard they weren't documenting their differences

[15:40:09.0000] <jgraham>
It's entirely a product of the fact that browsers that break sites are unpopular and so don't keep marketshare

[15:40:32.0000] <Hixie>
crocket: but the whatwg spec intends to remain compatible with browsers, fwiw

[15:40:53.0000] <jgraham>
So once a feature is used by enough sites, browsers can't change the way it works, whatever any spec says and however much they might want to

[15:40:59.0000] <crocket>
Will browser vendors keep up with WHATWG or WC3?

[15:41:07.0000] <Hixie>
crocket: whatwg will keep up with browser vendors

[15:41:17.0000] <crocket>
the hell?

[15:41:37.0000] <crocket>
Hixie : I feel frightened to start learning HTML.

[15:41:41.0000] <jgraham>
Developing web technologies isn't a top down process

[15:41:46.0000] <Hixie>
crocket: you may be suffering from the impression that standards are developed in isolation and browsers then do what the specs say

[15:42:10.0000] <Hixie>
crocket: what actually happens is that the browsers and the specs develop in tandem, and continually converge over time

[15:42:24.0000] <Hixie>
(at least, the whatwg specs converge, in theory. dunno about others.)

[15:42:28.0000] <crocket>
Hixie : So is it a mistake to learn HTML?

[15:42:42.0000] <Hixie>
crocket: nope

[15:42:51.0000] <Hixie>
crocket: HTML is a great technology to use if what you want to do is target the Web

[15:43:02.0000] <Hixie>
crocket: just like any other platform, it's in active development

[15:43:14.0000] <Hixie>
well, any other platform that's not dead

[15:43:29.0000] <crocket>
Without explicit version management, it's more confusing.

[15:43:34.0000] <Hixie>
why?

[15:43:52.0000] <crocket>
Hixie : Without version management, you always have to keep up with the master branch.

[15:43:52.0000] <Hixie>
the difference between the web and other platforms is that there's more than one implementation of the web

[15:44:06.0000] <Hixie>
crocket: no, because with html if something works, we don't break it

[15:44:33.0000] <crocket>
Hixie : Any HTML book you recommend?

[15:44:41.0000] <Hixie>
crocket: so web sites written in the 90s and not maintained since still work today, by and large

[15:45:03.0000] <Hixie>
(assuming they worked on more than one browser of the time, anyway)

[15:45:23.0000] <Hixie>
crocket: i'm not familiar with the books, sorry

[15:45:34.0000] <crocket>
Hixie : Did WC3 drop the version number, too?

[15:46:10.0000] <Hixie>
crocket: it's not clear what they're doing. they've got two versions of HTML with different numbers that are different from each other and that are both changing regularly.

[15:46:26.0000] <Hixie>
crocket: i would encourage you to ignore them :-)

[15:46:34.0000] <cabanier>
:-)

[15:46:41.0000] <crocket>
what the hell

[15:48:23.0000] <Hixie>
like i said, i'd encourage ignoring them

[15:48:29.0000] <Hixie>
they mostly just copy what we do anyway

[15:49:57.0000] <jsbell>
The phrase "reality-based spec writing" just got stuck in my head.

[15:51:31.0000] <TabAtkins>
Ugh, github's insistence on serving everything as text/plain is frustrating as hell, as it means I can't link to an SVG file that's just in the repo alongside everything else.

[15:51:34.0000] <Hixie>
crocket: you may find http://whatwg.org/faq interesting

[15:51:58.0000] <Hixie>
TabAtkins: it'd be a security wackamole for them to do anything else

[15:52:04.0000] <Hixie>
but yeah

[15:53:05.0000] <TabAtkins>
They serve things just fine if you put it on your gh-pages branch and link to it from [repo].github.io, though.

[15:53:43.0000] <Hixie>
ah, interesting

[15:53:54.0000] <Hixie>
well, that's cross-origin

[15:53:56.0000] <Hixie>
so that'd be ok

[15:54:27.0000] <Hixie>
i'm rapidly running out of words in the english vocabulary

[15:54:40.0000] <Hixie>
object. collection. bag. list.

[15:54:46.0000] <Hixie>
pile of things

[15:54:55.0000] <Hixie>
stack of widgets

[15:55:03.0000] <Hixie>
heap of thingymajimmies

[15:55:14.0000] <Hixie>
assemblage, haven't used that yet.

[15:55:40.0000] <jsbell>
TabAtkins: For non-production use, there's http://rawgithub.com/

[15:55:42.0000] <Hixie>
(it's amusing how many words in the thesaurus under "collection" are terms of art by now)

[15:55:59.0000] <TabAtkins>
jsbell: Yeah, but I don't like using that in my project docs.

[15:56:04.0000] <TabAtkins>
But I guess whatever

[15:56:24.0000] <crocket>
yo

[16:00:22.0000] <Domenic_>
TabAtkins: you can just remove the dot from raw.github.com and it works. rawgithub.com is a proxy service that sets the right content type

[16:00:31.0000] <TabAtkins>
Domenic_: Yeah, I know, I've used it before.

[16:00:58.0000] <Domenic_>
oh whoops i was 5 minutes too late, that's what i get for not scrolling

[16:07:13.0000] <TabAtkins>
If anyone ever wanted to put railroad diagrams in their spec, a la CSS Syntax or JSON.org, Bikeshed now does that automatically.

[16:08:39.0000] <crocket>
Does anyone know a good HTML book?

[16:15:00.0000] <jsbell>
crocket: I don't think you'll get a good answer here. It's like wandering into the records room of a Boeing factory and asking for recommendations on learning to fly a plane.

[16:15:36.0000] <crocket>
jsbell: A funny analogy

[16:28:49.0000] <annevk>
TabAtkins: sounds like I should give it a try at some point

[16:29:01.0000] <annevk>
TabAtkins: make some railroads for URL and such

[16:29:08.0000] <Domenic_>
ooh that'd be cool

[16:29:24.0000] <TabAtkins>
Yeah, that'd be great.  Railroads are so easy to read for simple constructions like that.

[16:30:29.0000] <Hixie>
mmm, railroads

[16:42:48.0000] <jgraham>
TabAtkins: Dammit, now we have lost Hixie for two months as he tries to invent a way to 3D-print model railway pieces from his web browser

[16:43:05.0000] <TabAtkins>
I accept no blame for this.

[16:45:35.0000] <jgraham>
Railroads. You mentioned railroads. You should know that's a bad idea

[16:45:54.0000] <Hixie>
teehee

[16:46:04.0000] <Hixie>
i can already 3d-print model railway pieces from my web browser

[16:46:08.0000] <Hixie>
it's called "shapeways.com"

[16:47:31.0000] <jgraham>
OK, crisis averted


2013-10-29
[17:57:18.0000] <gsnedders>
Hixie: OMG THAT IS AMAZING.

[17:57:22.0000] <gsnedders>
Sorry.

[17:57:27.0000] <gsnedders>
I may be all of the excite now.

[18:02:08.0000] <Hixie>
shapeways?

[18:02:15.0000] <Hixie>
shapeways + sketchup = awesome

[18:02:29.0000] <Hixie>
not exactly cheap, though

[18:26:10.0000] <cabanier>
Hixie: was my last reply better?

[18:28:16.0000] <Yuhong>
As I said before, I now consider HTML version numbering even as a buzzword a misnomer.

[19:15:10.0000] <gsnedders>
Hixie: Yeah

[19:16:07.0000] <MikeSmith>
Krinkle|detached: yeah i had asked about that mediawiki resourceloader thing

[19:17:14.0000] <MikeSmith>
which plainly seems like a not-well-considered hack

[19:17:30.0000] <MikeSmith>
cwilso: lunch?

[20:09:48.0000] <cwilso>
Mikesmith: Eiji and I are heading down now

[20:12:26.0000] <MikeSmith>
cwilso: ok

[23:59:54.0000] <MikeSmith>
did annevk-cloud or somebody already make an idlharness test for the URL spec?

[00:01:17.0000] <JakeA>
Can anyone think of a high-profile site that uses web fonts on body copy?

[00:02:04.0000] <JakeA>
Particularly one that doesn't base64-encode the font

[00:13:04.0000] <JakeA>
(no worries, got one)

[00:21:22.0000] <zcorpan>
TabAtkins: you can use rawgithub.com

[00:21:59.0000] <zcorpan>
oh that was mentioned already

[00:22:49.0000] <heycam>
TabAtkins, can you include |details, summary { display: block; }| in Bikeshed's style sheet so that <details class=why> looks normal in browsers that don't implement details/summary yet?

[00:38:36.0000] <Ms2ger>
Well, that "early next week" ended up a little later

[00:43:48.0000] <heycam>
TabAtkins, also, with my current details/summary patches applied, Firefox renders it like this: http://mcc.id.au/temp/details-why.png

[00:43:58.0000] <heycam>
I think I'm following the UA style sheet rules that are in the HTML spec

[00:50:34.0000] <Ms2ger>
Hrm

[00:50:42.0000] <Ms2ger>
Should :first-child apply to the root?

[00:52:16.0000] <heycam>
not really clear from the spec...

[00:52:46.0000] <Ms2ger>
Indeed

[01:43:16.0000] <annevk-cloud>
MikeSmith: dunno

[01:55:21.0000] <SimonSapin>
MikeSmith: https://dvcs.w3.org/hg/csswg/rev/db9b855680ef gives a 500 error

[01:55:50.0000] <SimonSapin>
MikeSmith: who has access to fix it?

[02:19:44.0000] <MikeSmith>
SimonSapin: seems to be working

[02:19:56.0000] <SimonSapin>
MikeSmith: yeah, it’s back now

[02:20:31.0000] <MikeSmith>
the machine isn't super reliable

[02:21:16.0000] <MikeSmith>
the python hg stuff on the server sometimes gets into a weird error stat

[02:21:20.0000] <MikeSmith>
*state

[02:22:10.0000] <MikeSmith>
I'll go in and check the logs and restart the server if it seems like there might be more problems

[02:23:55.0000] <zcorpan>
MikeSmith: can i haz a bugzilla component for FXTF Geometry spec plz?

[02:24:27.0000] <MikeSmith>
zcorpan: ah yeah saw that in scrollback

[02:24:31.0000] <MikeSmith>
oh man

[02:24:34.0000] <MikeSmith>
cgid daemon process died, restarting

[02:24:49.0000] <MikeSmith>
Cannot allocate memory: fork: Unable to fork new process

[02:25:09.0000] <zcorpan>
MikeSmith: k :-)

[02:27:07.0000] <MikeSmith>
dvcs.w3.org shut itself down and restarted twice withing the last few hours

[02:27:21.0000] <MikeSmith>
 child process 19748 still did not exit, sending a SIGKILL

[02:27:48.0000] <MikeSmith>
Resource temporarily unavailable: apr_thread_create: unable to create worker thread

[02:27:56.0000] <MikeSmith>
never seen that before

[02:34:25.0000] <MikeSmith>
I restarted the server. If anybody starts getting 500's or whatever from it again lemme know

[02:36:52.0000] <MikeSmith>
zcorpan: make you the default assignee?

[02:37:11.0000] <zcorpan>
MikeSmith: sure

[02:37:16.0000] <MikeSmith>
k

[02:39:52.0000] <MikeSmith>
zcorpan: ready to use

[02:40:01.0000] <zcorpan>
MikeSmith: thanks!

[02:40:07.0000] <MikeSmith>
cheers

[02:46:01.0000] <hsivonen>
do we require new APIs to use EcmaScriptish lists? do we require new APIs to use Promises/Futures?

[02:46:13.0000] <hsivonen>
what's the latest thinking on Promises/Futures?

[02:46:35.0000] <hsivonen>
is there documentation for how to write a new API these days?

[02:49:11.0000] <MikeSmith>
does anybody remember any discussion of http://www.mediawiki.org/wiki/ResourceLoader/ResourceLoaderDynamicStyles_specification on whatwg@ or anywhere at all?

[02:49:20.0000] <MikeSmith>
<meta content="" name="ResourceLoaderDynamicStyles">

[02:49:24.0000] <hsivonen>
are all new APIs that have callback-ish things now blocked on Promises?

[02:49:34.0000] <MikeSmith>
"The purpose is to mark the DOM position before which dynamic styles should be added."

[02:49:41.0000] <MikeSmith>
hsivonen: yes, basically

[02:50:18.0000] <MikeSmith>
as far as I understand it

[02:50:46.0000] <hsivonen>
so there's this API. and the last time I reviewed it, I said it should use callbacks instead of synchronous operations. so the WG changed it to callbacks

[02:50:58.0000] <MikeSmith>
hsivonen: as far as how-to-write-a-new-API docs, I think there is something around

[02:51:01.0000] <MikeSmith>
/me looks

[02:51:03.0000] <hsivonen>
if I now say that it's no good, because it should use promises, it'll sound like "fetch me another rock"

[02:51:20.0000] <Ms2ger>
hsivonen, alternatively, make annevk tell them to use promises :)

[02:51:31.0000] <darobin>
there's a lot of talk about a how-to-write-an-API doc, but there's nothing good around

[02:51:50.0000] <darobin>
I made a braindump a long time ago but it's neither complete, nor good, nor up to speed with today

[02:52:15.0000] <darobin>
about once a month someone asks if they can use it as a starting point to do something better, I say yes, and nothing happens

[02:52:30.0000] <darobin>
that said, isn't there something in the whatwg wiki about using promises?

[02:53:09.0000] <darobin>
hsivonen: just blame them for not finishing faster, if they had shipped they'd be allowed to stick to callbacks

[02:53:17.0000] <darobin>
if they take even longer, it'll be something other than promises

[02:54:18.0000] <MikeSmith>
I thought there were notes somewhere at least

[02:56:02.0000] <MikeSmith>
darobin: I guess I was remembering http://darobin.github.io/api-design-cookbook/

[02:56:21.0000] <darobin>
MikeSmith: yeah, that's the one I said was bad

[02:56:26.0000] <MikeSmith>
oh

[02:56:35.0000] <darobin>
well, it was initially just a braindump about things that people often did wrong with WebIDL

[02:56:44.0000] <MikeSmith>
infobot, remove http://darobin.github.io/api-design-cookbook/ from the logs

[02:56:46.0000] <darobin>
which isn't all that helpful for design

[02:56:52.0000] <darobin>
heh

[02:57:04.0000] <darobin>
well, there are probably a few small bits to save

[02:57:11.0000] <darobin>
but I wouldn't recommend it for anyone

[02:57:32.0000] <darobin>
anyone can steal the content if they want though

[02:57:44.0000] <darobin>
(assuming they have the patience to dig for the useful bits)

[03:00:12.0000] <MikeSmith>
well I canna find anything about Promises nor Futures in wiki.w3.org nor http://www.w3.org/wiki

[03:02:06.0000] <MikeSmith>
for further depression read http://wiki.whatwg.org/index.php?title=Talk:MetaExtensions&curid=1691&diff=9354&oldid=9302

[03:02:09.0000] <MikeSmith>
http://wiki.whatwg.org/wiki/Talk:MetaExtensions#Structured_Data_proposal

[03:04:03.0000] <MikeSmith>
"authors should know which is the most modern and useful way to provide metadata" = use <meta property=""> with RDFa instead of <meta name="">

[03:04:44.0000] <MikeSmith>
nice quote there, though "Ian Hickson has suggested to me that what is more important than whether there are standards that define them, is whether there is any software that consumes them in a useful manner."

[03:12:35.0000] <wilhelm>
MikeSmith: There are some amusing links from that discussion. Like this: http://members.tripod.com/martin_leese/

[03:14:16.0000] <MikeSmith>
wilhelm: wow that's pretty cool

[03:14:27.0000] <MikeSmith>
guy has a sense of humor at least

[03:14:55.0000] <wilhelm>
And significant amounts of metadata.

[03:15:07.0000] <MikeSmith>
yeah

[03:15:12.0000] <MikeSmith>
"Taught myself the PostScript computer language"

[03:15:28.0000] <MikeSmith>
I think that's the part that did the permanent damage

[03:15:59.0000] <MikeSmith>
the red book

[03:16:31.0000] <MikeSmith>
turns out it's actually a cookbook, for cooking your brain

[03:17:14.0000] <MikeSmith>
hsivonen: so I been trying to find one good resource on "Why use Promises?" for API design, anywhere, but no luck

[03:17:33.0000] <MikeSmith>
trying to with Deferreds and other synonyms

[03:18:45.0000] <MikeSmith>
would be good to have something to point your WG too in your message when you apologize to them for their decision to take your previous advice

[03:20:50.0000] <Ms2ger>
MikeSmith, I still haven't figured out why you would use promises, so if you find something, let me know

[03:21:47.0000] <karlcow>
no luck with https://duckduckgo.com/?q=why+promises+extensiblewebmanifesto

[03:23:02.0000] <karlcow>
https://github.com/slightlyoff/Promises/blob/master/README.md

[03:24:34.0000] <MikeSmith>
Domenic's slides have too many slides

[03:25:24.0000] <MikeSmith>
Ms2ger: lacking Domenic_ right now I'm trying to find some Domenic_ words

[03:26:00.0000] <MikeSmith>
http://www.slideshare.net/domenicdenicola/callbacks-promises-and-coroutines-oh-my-the-evolution-of-asynchronicity-in-javascript

[03:26:03.0000] <MikeSmith>
slide 42

[03:36:28.0000] <Ms2ger>
!summon TabAtkins

[03:39:06.0000] <annevk-cloud>
hsivonen: promises & arrays, yes; also, unlike the organization, ECMAScript was not renamed

[03:42:36.0000] <SimonSapin>
annevk-cloud: do you think we should really have HTML define an "environment encoding" for CSS, or is it just nice to have? http://dev.w3.org/csswg/css-syntax/#issue-b26a56fd

[03:43:22.0000] <SimonSapin>
to simplify the current spec of "charset attr on <link>, then encoding of the referring document" http://dev.w3.org/csswg/css-syntax/#input-byte-stream

[03:45:09.0000] <annevk-cloud>
If you want a well designed system, yes.

[03:58:26.0000] <Ms2ger>
SimonSapin, also, might want to ask hsivonen about [css-syntax] Cross-origin fallback charset

[04:02:16.0000] <SimonSapin>
Ms2ger: if it was an issue, wouldn’t it be for script at well?

[04:07:33.0000] <Ms2ger>
Oh look, my professor has Opera installed

[04:07:46.0000] <Ms2ger>
But Chrome and Firefox open

[04:11:37.0000] <annevk>
Opera was closed first?

[04:12:33.0000] <Ms2ger>
Or maybe IE

[04:13:06.0000] <annevk>
SimonSapin: security considerations between style sheets and scripts are different

[04:13:27.0000] <annevk>
Not sure if Ms2ger is missing the joke or trolling

[04:14:31.0000] <Ms2ger>
Hey, you know me

[04:14:36.0000] <Ms2ger>
Surely the latter

[04:17:01.0000] <annevk>
Yeah

[04:45:55.0000] <hsivonen>
I thought we had the CSS charset stuff figured out a year ago. Has something changed?

[04:47:18.0000] <annevk>
hsivonen: I wasn't entirely sure if we were decisive about <link charset="">

[04:48:09.0000] <annevk>
hsivonen: and currently http://dev.w3.org/csswg/css-syntax/#determine-the-fallback-encoding seems to allow <link charset="utf-16">

[04:50:37.0000] <hsivonen>
is that a problem?

[04:51:23.0000] <annevk>
hsivonen: I forgot details of XSS bugs basically

[04:51:28.0000] <annevk>
hsivonen: so I don't know

[05:11:23.0000] <SimonSapin>
hsivonen: is there a reason the rules for encoding of script would not be safe to use for stylesheets?

[05:12:05.0000] <annevk>
hsivonen: just invalidated https://bugzilla.mozilla.org/show_bug.cgi?id=145828 Seems like that might (part of) the cause of the mess of your recent cleanup?

[05:14:33.0000] <hsivonen>
SimonSapin: what's the difference except CSS defaults to UTF-8 when there's no referring doc and JS defaults to windows-1252 and JS doesn't have an internal encoding declaration like @charset?

[05:15:38.0000] <hsivonen>
annevk: whoa. that bug is sad. thanks for invalidating it.

[05:30:36.0000] <zcorpan>
does <script> fallback encoding need to work cross-origin for compat?

[05:41:34.0000] <SimonSapin>
hsivonen: I think it’s the same, other than that

[05:41:56.0000] <SimonSapin>
the question is: should the document’s encoding only be considered in same-origin?

[05:46:27.0000] <annevk>
Well, first the question is whether that's a security problem

[05:53:24.0000] <annevk>
SimonSapin: I recommend looking at what Gecko / Chrome do right now

[06:17:50.0000] <SimonSapin>
great, http://lists.w3.org sends Content-Type: text/html;charset=ISO-8859-1 for HTML attachments

[06:18:31.0000] <SimonSapin>
which apparently takes precedence over <meta charset=latin2> in my test case

[06:18:41.0000] <jgraham>
Yes

[06:18:44.0000] <jgraham>
Don't you love HTTP

[06:19:09.0000] <Ms2ger>
... no?

[06:20:24.0000] <SimonSapin>
http://lists.w3.org/Archives/Public/www-archive/2013Oct/att-0048/css-cross-origin-encoding.html is green when accessed with file://

[06:22:32.0000] <annevk>
I tried to summarize the GitHub discussion here: http://wiki.whatwg.org/wiki/GitHub

[06:28:50.0000] <hsivonen>
SimonSapin: wouldn't making it non-cross-origin break CDNs if there are scripts being loaded from CDNs with the assumption that the charset inherits?

[06:29:34.0000] <SimonSapin>
hsivonen, annevk: Firefox and Chromium do use the document’s encoding for cross-origin stylesheets: data:text/html;charset=latin2,<link rel=stylesheet href=http://test.csswg.org/suites/css2.1/20110323/html4/support/none.css><span class=&%23258;&%23733;&%23258;&%23164;&%23258;&%23168>Test

[06:29:50.0000] <hsivonen>
so what's the problem?

[06:30:35.0000] <SimonSapin>
hsivonen: there is an open issue in the spec that maybe they shouldn’t: http://dev.w3.org/csswg/css-syntax/#issue-ab273e4b

[06:31:47.0000] <jgraham>
SimonSapin: That seems like the issue can be closed then

[06:31:48.0000] <annevk>
So generally the problem with overriding at the embedder's point is that you might leak data from the resource.

[06:32:24.0000] <hsivonen>
I'd rather not change this without a demo of a credible exploit

[06:32:35.0000] <hsivonen>
if a credible exploit needs HZ, let's get rid of HZ

[06:32:54.0000] <annevk>
However, a) the resource is required to be text/css in this scenario b) I cannot think of any encoding tricks that would allow more exposure of information using a different decoder

[06:33:46.0000] <annevk>
a) is not true for <script> which might be why that is somewhat more dangerous although again I have a hard time thinking of something...

[06:36:15.0000] <hsivonen>
pretty unlikely for non-scripts to compile as scripts

[06:38:18.0000] <annevk>
I guess the scenario is that you'd have some UTF-16 JSONP stored on an intranet and using this you can read it.

[06:38:48.0000] <hsivonen>
annevk: UTF-16 doesn't inherit, though

[06:38:55.0000] <annevk>
The same would apply to the CSS. Although using UTF-16 as a defence mechanism which does not actually work today in practice is rather broken.

[06:38:58.0000] <hsivonen>
so you'd need charset=""

[06:39:18.0000] <hsivonen>
yes, you are doing it wrong if you are using UTF-16 for security

[06:39:24.0000] <SimonSapin>
hsivonen: it does per http://dev.w3.org/csswg/css-syntax/#input-byte-stream

[06:39:27.0000] <annevk>
hsivonen: CSS says "Otherwise, if the referring style sheet or document has an encoding, use that as the fallback encoding."

[06:39:28.0000] <SimonSapin>
is that a bug?

[06:39:37.0000] <annevk>
I think we considered that to be fine

[06:39:50.0000] <hsivonen>
oh. my memory fails me then

[06:40:12.0000] <annevk>
<link charset> and charset of the document <link> is in are in control of the same entity

[06:40:20.0000] <annevk>
so there's no need treating those differently

[06:40:44.0000] <hsivonen>
what does the no true Scotsman W3C Meme refer to?

[06:40:44.0000] <annevk>
and in fact that should become an input parameter as one of the issues in css3-syntax suggests

[06:40:54.0000] <hsivonen>
public-restrictedmedia?

[06:41:34.0000] <annevk>
hsivonen: given jernoble seems like hober would be able to explain

[06:43:13.0000] <annevk>
or jernoble who is actually in this channel :)

[06:59:37.0000] <Domenic_>
hsivonen: promises are finished and have been for a while. Implementations shipped a few weeks ago.

[07:03:20.0000] <MikeSmith>
that picture of Lord Hakon looks like he's wearing an electric sombrero

[07:47:43.0000] <MikeSmith>
Domenic_: is Takeshi Yoshino's Streams draft no longer relevant?

[07:47:49.0000] <MikeSmith>
I mean https://github.com/tyoshino/stream/blob/master/streams.html

[07:48:04.0000] <MikeSmith>
annevk: ^

[07:48:31.0000] <annevk>
Lol, the Notifications API does not actually define activating a notification (firing click)

[07:48:55.0000] <annevk>
MikeSmith: http://krijnhoetmer.nl/irc-logs/whatwg/20131028#l-440

[08:10:35.0000] <MikeSmith>
annevk: thanks

[08:11:56.0000] <annevk>
marcosc: what is https://github.com/sensorweb ?

[08:12:07.0000] <annevk>
marcosc: other than maybe a home for the serial API stuff

[08:12:10.0000] <marcosc>
Web Serial API

[08:12:56.0000] <marcosc>
more stuff will likely be needed

[08:14:10.0000] <Ms2ger>
Clearly we need a Web Parallel API instead

[08:16:16.0000] <annevk>
marcosc: any reason we need yet another org for that?

[08:21:02.0000] <marcosc>
annevk: it's nice for communities to have their own space. They might want to create a website, and other bits and pieces. Similar to the RICG.

[08:21:21.0000] <annevk>
because that was so successful?

[08:22:37.0000] <jgraham>
marcosc: It's not quite clear why it couldn't happen at the WHATWG

[08:23:47.0000] <marcosc>
oh, the initial work can be done in the CG (on Gh) and then we can hand it over

[08:26:52.0000] <annevk>
marcosc: dude, that totally failed last time around

[08:27:05.0000] <marcosc>
really?

[08:27:08.0000] <Ms2ger>
marcosc, I can't say I've got good experiences with people inventing something in a silo and then expecting others to just swallow it whole

[08:27:27.0000] <annevk>
Yeah, each time that happens it's just a massive pain

[08:27:56.0000] <marcosc>
It's not really a silo. It's just an org on GH with a repo. You can just subscribe to it?

[08:28:18.0000] <Ms2ger>
marcosc, not useful

[08:28:29.0000] <marcosc>
how's it any different than the WHATWG?

[08:29:05.0000] <Ms2ger>
People aren't there

[08:29:20.0000] <annevk>
marcosc: the WHATWG has implementor buy-in, over 2000 people subscribed with an interest in this space, etc. Seems pretty clear what's different.

[08:30:08.0000] <marcosc>
Do we want people to subscribe to the mailing list too?

[08:30:13.0000] <marcosc>
that seems a little aweful

[08:32:34.0000] <marcosc>
Ok, so, I don't mind moving the repo over

[08:32:44.0000] <marcosc>
I'll just shut it all down

[08:32:54.0000] <marcosc>
Where the work is done doesn't matter

[08:33:21.0000] <annevk>
marcosc: so if you want to write a standard, you need to have lots of eyes

[08:34:05.0000] <annevk>
marcosc: if you want a sandbox, you can have your private silo, but don't expect standardizing it afterwards to be a breeze

[08:34:08.0000] <marcosc>
Sure... I'm confused. Is this so you are automatically subscribed to the repo on GH?

[08:34:45.0000] <marcosc>
Is all discussion also supposed to happen on the whatwg list?

[08:34:51.0000] <annevk>
marcosc: it's not about what I want, it's about what you want

[08:35:33.0000] <darobin>
<annevk> ... and you probably want to want... what I want

[08:35:39.0000] <annevk>
marcosc: I would expect the WHATWG list to be kept in the loop, maybe not have all discussion there, but certainly some

[08:36:23.0000] <marcosc>
sure. But having people subscribe to the WHATWG firehose seems like a nonstarter to me.

[08:36:56.0000] <marcosc>
But I don't mind having the repo hosted there.

[08:37:01.0000] <annevk>
marcosc: works fine for Fullscreen and the Notifications API, and a number of other small efforts

[08:37:37.0000] <annevk>
marcosc: but note that a lot of detailed discussion takes places in bugs too

[08:38:10.0000] <marcosc>
sure

[08:39:41.0000] <marcosc>
annevk: should I just call the repo "serial" or "serialapi"?

[08:39:47.0000] <annevk>
and in fact until the responsive images community took a wrongheaded suggestion by someone who almost never posts on the WHATWG list to go away that was working okay too

[08:40:03.0000] <annevk>
marcosc: "serial" I guess

[08:40:19.0000] <marcosc>
annevk, I think the people from the community see it differently

[08:41:16.0000] <marcosc>
unless by okay you mean getting everyoen upset and pissed off, but which yes... it was working great :)

[08:41:55.0000] <marcosc>
developer community management is not one of the WHATWG's strong suites, but that's ok

[08:42:19.0000] <marcosc>
/me moves stuff over

[08:45:20.0000] <Ms2ger>
marcosc, in general, "here's a use case" tends to work better than "here's an API" ;)

[08:45:37.0000] <marcosc>
sure

[08:45:53.0000] <annevk>
marcosc: if you think we can be better there, you're most welcome to help out :-)

[08:46:05.0000] <marcosc>
/me trying 

[08:46:17.0000] <marcosc>
Let's see how this serial api thing goes

[08:52:05.0000] <marcosc>
Ms2ger, annevk, how should we handle new Editors? Should they just be organization owners or should there be a contributor team with pull/push rights?

[08:53:22.0000] <annevk>
marcosc: if this is going to be a bunch of new people maybe add a group for serial?

[08:53:50.0000] <marcosc>
yeah, it's going to be a few till we work out who will lead it

[08:54:06.0000] <annevk>
marcosc: the current list of owners is people we feel we can trust, but if there's a bunch of new unknown individuals I'm not entirely sure I want them to be able to just delete everything

[08:54:32.0000] <marcosc>
exactly my feeling too... I'll make a new group for them

[09:06:13.0000] <annevk>
marcosc: want @WHATWG to tweet about it?

[09:06:29.0000] <marcosc>
sure, but let me finish setting up

[09:06:33.0000] <darobin>
marcosc: note that there's a common misconception about GH ACLs

[09:06:33.0000] <darobin>
if you create a group to work on a repo, don't give  them admin rights

[09:06:33.0000] <darobin>
it might look like you're giving them admin rights just to the repo, but it actually gives them admin for the org

[09:06:34.0000] <darobin>
they just need push & pull for pretty much everything to do with a repo

[09:06:35.0000] <marcosc>
will ping you in a few mins

[09:07:09.0000] <annevk>
darobin: whoa

[09:07:22.0000] <darobin>
annevk: yeah

[09:08:08.0000] <annevk>
FWIW, anyone in this channel who wants to tweet something should just let us know. @WHATWG is community-owned, but restricted because of spammers.

[09:08:28.0000] <darobin>
annevk: I found out when jgraham started creating new repos under w3c, which we didn't think he would be able to :)

[09:09:04.0000] <marcosc>
darobin: I only gave push/pull

[09:09:15.0000] <marcosc>
was only going to give pull

[09:09:36.0000] <marcosc>
and only for the serial repo

[09:09:47.0000] <darobin>
marcosc: if people are going to be working on the repo, just giving them pull isn't much :)

[09:10:19.0000] <Ms2ger>
darobin, eh, make them explain their reasoning in PRs ;)

[09:10:27.0000] <marcosc>
exactly

[09:10:57.0000] <darobin>
Ms2ger: heh, sure, but in that case they might as well have their own forks, no?

[09:11:49.0000] <marcosc>
nah, that get's even messier

[09:20:47.0000] <annevk>
I wonder if I should attempt to make an IDL version of ServiceWorker

[09:21:01.0000] <annevk>
It doesn't really seem like anyone is working on a specification either...

[09:21:34.0000] <Ms2ger>
Eh, specifications are overrated

[09:21:50.0000] <Ms2ger>
Rough consensus and shipping code is where it's at

[09:24:21.0000] <annevk>
Short term, maybe

[09:25:02.0000] <Ms2ger>
In case it wasn't clear, this was most definitely trolling

[09:31:04.0000] <Domenic_>
annevk: any idea why Firefox 25 (released today) has global.PromiseResolver but not global.Promise?

[09:32:11.0000] <annevk>
Domenic_: no, but Nightly.app does not have that problem

[09:35:20.0000] <Ms2ger>
Bah

[09:38:00.0000] <Ms2ger>
Domenic_, bz wonders how you noticed

[09:54:32.0000] <Domenic_>
Ms2ger: I saw "Future renamed to Promise" in the FF 25 for devs release notes, so I opened up my console and typed "Promise" which autocompleted to "PromiseResolver"

[09:54:48.0000] <Ms2ger>
Domenic_, okay, thanks

[09:55:09.0000] <Ms2ger>
Should be gone again in Fx26; not much we can do about Fx25 at this point, though

[09:55:24.0000] <Domenic_>
yeah seems fine it's not useful anyway, nobody will depend on it

[10:07:50.0000] <annevk>
Okay I filed a bunch of bugs on ServiceWorker instead

[10:14:49.0000] <Domenic_>
annevk: marcosc: I am going to create a repo for streams work; any interest in hosting it under whatwg/ instead of another domenic/ repo?

[10:15:13.0000] <annevk>
Domenic_: seems good

[10:15:22.0000] <annevk>
Domenic_: are you a member?

[10:15:27.0000] <Domenic_>
annevk: nope

[10:15:56.0000] <annevk>
Domenic_: are now

[10:16:43.0000] <marcosc>
Domenic_: sounds awesome

[10:17:19.0000] <Ms2ger>
annevk, so he gets to vote to throw Hixie out? ;)

[10:17:42.0000] <annevk>
Ms2ger: lowercase GH member ;p

[10:17:56.0000] <annevk>
although technically uppercase GH Owner

[10:18:05.0000] <Domenic_>
thanks <3

[10:23:15.0000] <SimonSapin>
Does <link rel=stylesheet> even have a charset attribute?

[10:23:40.0000] <Hixie>
no

[10:24:48.0000] <SimonSapin>
oh. That means the whole "Environment encoding" concept I’m adding to CSS Syntax is only needed for XML processing instructions :/

[10:30:52.0000] <TabAtkins>
heycam|away: Sure, I can do that (re: stylesheet for details/summary)

[10:31:09.0000] <TabAtkins>
SimonSapin: We could just ignore XML PIs?

[10:31:27.0000] <TabAtkins>
Ms2ger: What did you summon me for?

[10:31:46.0000] <Ms2ger>
TabAtkins, I was wondering if :first-child applied to the root element

[10:31:55.0000] <Ms2ger>
TabAtkins, and where the spec says that

[10:32:20.0000] <dglazkov>
good morning, Whatwg!

[10:32:33.0000] <TabAtkins>
Yes it does. http://dev.w3.org/csswg/selectors/#the-nth-child-pseudo "represents an element that has an+b-1 siblings before it in the document tree."

[10:32:41.0000] <TabAtkins>
There's no explicit mention of parents, on purpose.

[10:32:58.0000] <TabAtkins>
We discussed this in the CSSWG a few months ago, and clarified the language accordingly.

[10:35:01.0000] <MikeSmith>
annevk: is there an open bug for getting rid of xml:base?

[10:35:07.0000] <MikeSmith>
gecko bug

[10:35:24.0000] <MikeSmith>
or also blink bug if you know of one

[10:35:57.0000] <Ms2ger>
TabAtkins, browsers don't seem to agree

[10:36:04.0000] <TabAtkins>
That's very possible.

[10:36:19.0000] <MikeSmith>
annevk: nm

[10:36:32.0000] <MikeSmith>
found https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c5

[10:36:34.0000] <TabAtkins>
I think Blink skips the root element, frex.

[10:36:45.0000] <TabAtkins>
We should fix that.

[10:37:10.0000] <annevk>
MikeSmith: only Gecko implements xml:base as far as I can tell

[10:37:14.0000] <TabAtkins>
Skipping elements without a parent complicates lots of other things, like use of :nth-child in a shadow tree (there's no parent element there, just a shadow root)

[10:37:35.0000] <MikeSmith>
annevk: oh. all the more reason to drop then I guess

[10:37:55.0000] <annevk>
MikeSmith: yeah, it'll simplify a bunch of things greatly

[10:38:01.0000] <SimonSapin>
TabAtkins: re :first-child, is that a change from level 3?

[10:38:05.0000] <MikeSmith>
annevk: plus I see I'm already had Cc'ed myself on that bugg

[10:38:10.0000] <SimonSapin>
3 says "and has a parent" explicitly

[10:38:14.0000] <MikeSmith>
annevk: yeah

[10:38:29.0000] <SimonSapin>
TabAtkins: re XML PIs, maybe, though they’re kinda in CSSOM http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction

[10:38:33.0000] <Ms2ger>
SimonSapin, well, the root has a parent, the document...

[10:38:57.0000] <TabAtkins>
Ms2ger: Not according to the element tree that Selectors sees.

[10:39:04.0000] <SimonSapin>
Ms2ger: sorry, "and has a parent element"

[10:39:53.0000] <Ms2ger>
TabAtkins, where's that defined? :)

[10:40:15.0000] <TabAtkins>
Ms2ger: It's not.  Yay!

[10:40:34.0000] <SimonSapin>
http://www.w3.org/TR/css3-selectors/#nth-child-pseudo says something different from http://dev.w3.org/csswg/selectors-4/#the-nth-child-pseudo

[10:40:39.0000] <Ms2ger>
TabAtkins, so then I claim the document is in the tree ;)

[10:40:42.0000] <TabAtkins>
Technically, HTML should define how it produces an element tree, but I'd be fine with Selectors defining this for HTML and XML.

[10:40:51.0000] <SimonSapin>
Ms2ger: the document is not an element

[10:40:58.0000] <TabAtkins>
Ms2ger: That means that "*" would select it. ^_^

[10:41:09.0000] <Ms2ger>
TabAtkins, sure

[10:41:15.0000] <Ms2ger>
TabAtkins, sounds like your spec is broken :)

[10:43:42.0000] <TabAtkins>
Yeah, it does.

[10:44:17.0000] <annevk>
TabAtkins: given that Selectors needs to know about text nodes and such, it seems much more useful for Selectors to operate on DOM rather than undefined theory

[10:45:50.0000] <TabAtkins>
Well, Selectors operates on more than just DOM.  There's a library that runs selectors over JSON, frex.

[10:45:51.0000] <annevk>
Requiring your core constituencies to make that mental translation each time rather than requiring the minority to make the translation of DOM to something else seems to place the burden incorrectly.

[10:45:52.0000] <Ms2ger>
On the Infoset, clearly

[10:46:12.0000] <TabAtkins>
But the translation from DOM to Selectors element tree is trivial.

[10:46:38.0000] <Ms2ger>
No it isn't

[10:46:43.0000] <Ms2ger>
You're cutting off the document

[10:46:46.0000] <annevk>
If it was trivial someone would have defined it by now...

[10:46:49.0000] <jernoble>
hsivonen, annevk: I was referring to public-restrictedmedia, but hober claims to have multiple entendres.

[10:46:57.0000] <annevk>
jernoble: heh

[10:48:57.0000] <TabAtkins>
annevk: You know as well as I do that trivial things are often the last things to be defined. ^_^

[10:50:04.0000] <annevk>
Well, I guess in this case it just seems bad to me to define it this way.

[10:50:32.0000] <TabAtkins>
Well, you don't want things like the Document to show up in the Selectors tree, because selecting it is meaningless and confusing.

[10:51:04.0000] <annevk>
And Selectors even talks about DocumentFragment

[10:51:32.0000] <annevk>
So if you really want to be abstract; you'll need to carefully define that abstract model in as much detail as the DOM is defined now, and then define the mapping

[10:51:58.0000] <annevk>
And then wonder why the DOM is not your abstract model for implementations that do not care about the DOM...

[10:52:27.0000] <annevk>
Something being in a tree does not mean it can be selected...

[10:52:48.0000] <annevk>
E.g. you cannot select a text node, but selectors assume text nodes are around

[10:53:06.0000] <TabAtkins>
Only insofar as pseudo-classes are concerned, and they're concerned with tons of shit that is very specific to HTML.

[10:53:21.0000] <annevk>
And e.g. :empty also refers to processing instructions and such...

[10:54:48.0000] <TabAtkins>
Yes, that's what I just said.  Pseudo-classes operate on information outside the element tree, which is host-language-specific.

[10:54:57.0000] <TabAtkins>
(Usually - some are just structural.)

[10:56:07.0000] <SimonSapin>
Ms2ger, annevk: this doesn’t change anything for :first-child, the Level 3 spec says "and has a parent *element*"

[10:56:48.0000] <Ms2ger>
SimonSapin, and apparently selectors4 tries to change that :/

[10:57:56.0000] <annevk>
TabAtkins: you can't have both an "abstract model" and then when you talk about your abstract model also talk about another model

[10:57:59.0000] <annevk>
TabAtkins: that makes no sense

[10:58:08.0000] <SimonSapin>
this looks like a bug in L4, implementations do as L3 says: data:text/html,<style>:root:first-child{background:green

[10:58:23.0000] <TabAtkins>
SimonSapin: Nah, intentional.  We discussed this a few months ago.

[10:58:55.0000] <TabAtkins>
We don't want :nth-child to depend on ahving a parent, as it fucks up our ability to target children of document fragments and shadow roots.

[10:58:58.0000] <SimonSapin>
TabAtkins: I remember the discussion about DocumentFragment. Did we decide to change it for the root element too?

[10:59:11.0000] <TabAtkins>
It's against impls, but it's a small, likely insignificant change.

[10:59:13.0000] <SimonSapin>
did implementers agree to do the change?

[10:59:27.0000] <TabAtkins>
We discussed it on a call, so probably?

[10:59:32.0000] <TabAtkins>
I don't recall the details now.

[10:59:40.0000] <SimonSapin>
should L3 be updated?

[10:59:49.0000] <TabAtkins>
Don't particularly care. ^_^

[10:59:52.0000] <annevk>
lol versions

[11:00:03.0000] <SimonSapin>
I care for Servo. What should I read?

[11:00:25.0000] <Ms2ger>
Clearly not L4, that has gratuitous changes

[11:00:32.0000] <TabAtkins>
The latest spec, always.  Why is this even a question?

[11:00:32.0000] <SimonSapin>
annevk +1

[11:00:58.0000] <Hixie>
i thought we agree that :nth-child() and :first-child and :only-child would match :root elements like half a decode ago

[11:01:01.0000] <Hixie>
agreed

[11:01:07.0000] <Hixie>
decade

[11:01:09.0000] <Hixie>
typing hard

[11:01:12.0000] <SimonSapin>
well, we just passed Acid 1

[11:01:53.0000] <SimonSapin>
I’m don’t really bother with the newest stuff yet

[11:02:29.0000] <annevk>
hehe

[11:02:56.0000] <TabAtkins>
It's fine to look at a reduced feature set, but never look at old specs.

[11:03:09.0000] <Hixie>
TabAtkins++

[11:03:48.0000] <Hixie>
(that's why it's bad to publish versioned specs)

[11:03:59.0000] <jgraham>
It's hard not to look at old specs when (unril recently) there were things where you were saying "don't look at X L3, CSS2.1 is more correct"

[11:04:19.0000] <Hixie>
jgraham: there's still css specs that say that (e.g. css3-content)

[11:04:57.0000] <TabAtkins>
I apologize that some specs are still too shitty to replace 2.1.

[11:05:28.0000] <Hixie>
we should just be extending 2.1, imho

[11:05:34.0000] <Hixie>
instead of fragmenting the tech into multiple shards

[11:05:40.0000] <Hixie>
but i'm not doing the work

[11:05:45.0000] <Hixie>
so my opinion is worthless here :-)

[11:05:52.0000] <jgraham>
Anyway, does anyone actually plan to implement selectors-on-JSON? It might be theoretically trivial (although I doubt it is in detail), but unless there are actual consumers it seems utterly absurd to move up the abstraction ladder just to allow it

[11:06:23.0000] <Hixie>
you wouldn't need to move the abstraction ladder anyway. you can just define a mapping of JSON to elements.

[11:06:27.0000] <TabAtkins>
jgraham: I mentioned that in reference to a JS library that does it.

[11:06:34.0000] <jgraham>
If there are actual consumers, given how unimportant they are compared to web browsers, it it merely absurd to do it that way

[11:06:54.0000] <jgraham>
Rather than making the consumers do the JSON-to_DOM mapping

[11:07:09.0000] <TabAtkins>
I don't understand what you're complaining about.

[11:07:28.0000] <Ms2ger>
Your abstraction

[11:07:40.0000] <jgraham>
Hixie: Sure, but TabAtkins seems to be saying that selectors needs to operate on a more abstract model than the DOM because of non-browser use cases

[11:07:55.0000] <annevk>
The HTML parser is defined in terms of DOM. Does not actually mean DOM is required or that you cannot parse into a weird JSON structure instead. It just means it uses the dominant most widely understood tree model to describe its behavior.

[11:08:15.0000] <Hixie>
jgraham: i'd disagree with "needs". you just need a mapping; it might be cleaner to have an abstraction, but it's not necessary.

[11:08:23.0000] <TabAtkins>
But then using the DOM directly makes Ms2ger confused, as <html> has Document as parent, but Selectors doesn't want to care about that.

[11:08:36.0000] <Ms2ger>
TabAtkins, on the contrary

[11:08:47.0000] <TabAtkins>
DOM has a bunch of extra crap that Selectors doesn't need for its general model.  Pseudo-classes operate on more information, but that's fine.

[11:08:48.0000] <Ms2ger>
TabAtkins, then you could just *say* that Document doesn't count

[11:08:48.0000] <jgraham>
Hixie: Me too. I am just repeating what TabAtkins is asserting

[11:09:18.0000] <Hixie>
why would it matter if Document counts?

[11:09:35.0000] <annevk>
The idea of abstraction for Selectors is nice, but given that it still references a ton of DOM concepts while failing to define a bunch of things, I think it should just give up.

[11:09:59.0000] <annevk>
be given up*

[11:09:59.0000] <TabAtkins>
Good lord, you can just file a freaking bug that says "hey, define the mapping between DOM and Selectors plz".

[11:10:28.0000] <TabAtkins>
The mapping was trivial enough that nobody realized it wasn't defined, because we use the same words in the same way in both trees.

[11:10:38.0000] <annevk>
That's not the bug TabAtkins. The abstraction layer is not even defined.

[11:10:58.0000] <TabAtkins>
Then file that bug, rather than bitching about how I should just give up.

[11:11:22.0000] <annevk>
Well I think you should define the thing in terms of the DOM. Which we use throughout all specs.

[11:11:37.0000] <annevk>
And is a fine abstraction for people that don't want it directly.

[11:12:01.0000] <Hixie>
so long as the spec defines itself properly, i don't really care what abstraction model it uses, i'm happy to let the editor figure that out

[11:12:02.0000] <annevk>
And maybe at some point I'll file a bug about that :-)

[11:12:37.0000] <Hixie>
and "this css spec is vague" seems like a bug that editors should just assume applies to all css specs they edit :-P

[11:12:44.0000] <TabAtkins>
What I'm going to do is define the mapping, because the abstraction is simple, and the mapping is trivial.  Then I don't have to chase DOM to exclude or modify things that Selectors doesn't want to care about.

[11:12:57.0000] <fantasai>
You're excluding everything except Elements

[11:13:04.0000] <fantasai>
I don't think that requires tracking anything

[11:13:12.0000] <annevk>
Not for :empty you're not fantasai

[11:13:45.0000] <annevk>
Or for matching in a DocumentFragment...

[11:13:54.0000] <annevk>
Anyway... day is over

[11:14:43.0000] <Hixie>
also attributes

[11:14:47.0000] <SimonSapin>
Hixie: This should probably be added to the HTML spec: http://dev.w3.org/csswg/css-syntax/#environment-encoding-html

[11:15:27.0000] <Hixie>
SimonSapin: can you post about this on https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 ? thanks

[11:15:40.0000] <fantasai>
annevk: ok, elements and text

[11:15:42.0000] <SimonSapin>
will do

[11:16:25.0000] <Hixie>
fantasai: well, you have to define one way or the other what the implications of comments and PIs are. and namespaces. and attributes. and namespaced attributes.

[11:16:43.0000] <Hixie>
and CDATA blocks, if you map to XML without mapping to DOM

[11:17:32.0000] <Hixie>
and DocumentFragments if you want to have :nth-* work on their children

[11:17:55.0000] <Hixie>
and Document if you want :root to not match :root ~ :root on a DocFrag

[11:18:33.0000] <Hixie>
also DOCTYPEs if you want to make sure * + :first-child is clearly defined for HTML's root element

[11:19:00.0000] <Hixie>
the point is just that it needs to be defined, i think

[11:22:05.0000] <SimonSapin>
<link charset=…> is in http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#obsolete , what does that mean for implementations?

[11:22:55.0000] <Hixie>
it doesn't do anything with respect to parsing style sheets

[11:23:30.0000] <Hixie>
the only impact is on the .charset IDL attribute on HTMLLinkElement, which just reflects it

[11:23:41.0000] <Hixie>
http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#dom-link-charset

[11:28:51.0000] <SimonSapin>
Hixie: it does in Gecko

[11:28:54.0000] <SimonSapin>
Hixie: it does in Gecko, BLin

[11:29:06.0000] <SimonSapin>
Gecko, Blink, and Presto: data:text/html,<link%20charset=latin2%20rel=stylesheet%20href=http://test.csswg.org/suites/css2.1/20110323/html4/support/none.css><span%20class=&%23258;&%23733;&%23258;&%23164;&%23258;&%23168>Test

[11:29:14.0000] <Hixie>
huh

[11:29:27.0000] <Hixie>
well, we should either fix the spec or fix the implementations

[11:30:06.0000] <Hixie>
wait

[11:30:11.0000] <Hixie>
how are you determining that it has an effect?

[11:30:24.0000] <Hixie>
i get the same results regardless of the attribute's value

[11:31:13.0000] <SimonSapin>
I get green with charset=latin2, red without or with another value

[11:31:45.0000] <Hixie>
hm, i have to reload a bunch of times sometimes to get it to change, but ok, yeah, got it to change

[11:31:48.0000] <SimonSapin>
this is misintepreting a UTF-8 stylesheet as latin2, and the class name has the corresponding mojibake

[11:32:18.0000] <Hixie>
well, i guess the question is "does anyone use this"

[11:32:20.0000] <Hixie>
if not, let's drop it

[11:32:32.0000] <Ms2ger>
/me approves of dropping

[11:32:39.0000] <SimonSapin>
How can we find out?

[11:32:47.0000] <Ms2ger>
Even more so if some �Mozilla vendor wants to try

[11:32:52.0000] <Hixie>
(it's probably not a security risk per se in this case, but changing character encodings in this way is dodgy at the best of times)

[11:33:08.0000] <Hixie>
SimonSapin: well, chrome or mozilla could add instrumentation

[11:34:25.0000] <SimonSapin>
I’m gonna specify it, and let someone who cares push for dropping it

[11:35:15.0000] <Ms2ger>
SimonSapin, do add a note, then

[11:35:26.0000] <SimonSapin>
ok

[11:40:44.0000] <Ms2ger>
Wow

[11:41:03.0000] <Ms2ger>
Calling in DOMParser, XMLHttpRequest, XMLSerializer and RGBColor to support you on naming?

[11:45:23.0000] <jgraham>
?

[11:46:18.0000] <Ms2ger>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0361.html

[11:46:20.0000] <jgraham>
(XMLHttpRequest has bizarro naming, and not just because it isn't related to XML)

[11:46:34.0000] <jgraham>
(Surely it should be XmlHttp or XMLHTTP

[11:46:38.0000] <jgraham>
)

[11:52:23.0000] <SimonSapin>
oh, re :first-child, css3-selectors has an errata: http://www.w3.org/Style/2011/REC-css3-selectors-20110929-errata.html

[11:57:27.0000] <gsnedders>
Yay errata!

[11:57:38.0000] <Hixie>
could have sworn we agreed to that years ago

[11:57:46.0000] <Hixie>
like, ~2005

[12:52:48.0000] <marcosc>
Hixie: do you want me to do anything with the navigator.languages proposal I have up on GH?

[12:54:00.0000] <marcosc>
People at Mozilla are asking what happens next with that.

[13:00:34.0000] <Hixie>
marcosc: is there another browser vendor interested in implementing it?

[13:00:58.0000] <marcosc>
Well, there was that person from the Chrome team

[13:01:13.0000] <Hixie>
marcosc: oh that's right. cool. then no, it should just get added in due course.

[13:01:28.0000] <Hixie>
marcosc: iirc it was sound

[13:01:32.0000] <marcosc>
Ok, cool.

[13:02:20.0000] <Hixie>
sorry right now i'm in the middle of this gnarly refactoring of how scripts and ports and workers and event loops work

[13:02:29.0000] <Hixie>
so that it's not quite as insane as it is in the spec today

[13:02:46.0000] <Hixie>
trying to define everything in terms of a "script settings object" for each global object

[13:02:59.0000] <Hixie>
rather than each script having its own referrer source, etc

[13:22:23.0000] <marcosc>
sounds fun :)

[13:22:44.0000] <Hixie>
ugh

[13:22:55.0000] <Hixie>
that's not the word i would use

[13:23:00.0000] <marcosc>
heh

[13:27:02.0000] <Hixie>
the worst part of spec writing is that there's no real way to compile and test the resulting program

[13:27:59.0000] <Ms2ger>
Well, you make us implement it... ;)

[13:28:25.0000] <Hixie>
"make"

[13:28:47.0000] <Ms2ger>
You implement it for us in Servo...

[13:29:37.0000] <Hixie>
my other compilers don't turn around and tell me that actually, they prefer this kind of API design, and also, this file needs this or that feature, and would i therefore code that up, kthxbye

[13:29:41.0000] <Hixie>
:-P

[13:30:15.0000] <Hixie>
on the plus side, while much slower than regular compilers, my compiler for the spec _does_ tend to be better about catching bugs

[13:30:29.0000] <Ms2ger>
bz?

[13:30:38.0000] <Hixie>
e.g.

[16:05:40.0000] <Hixie>
can anyone think of a situation where there's a Window object that's not a global scope that some script could in theory execute with, other than when script is disabled?

[16:23:53.0000] <Hixie>
can anyone think of a way to have a script survive document.open() ?


2013-10-30
[17:11:05.0000] <fantasai>
Hixie: I believe you wrote tests proving the opposite in 2005 :)

[17:12:19.0000] <fantasai>
Hixie: http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/tests/css3-modsel-27a.html

[18:18:45.0000] <jamesr__>
Hixie: Window object that's not a global scope?

[21:22:15.0000] <MikeSmith>
fyi dvcs.w3.org is down and I can't do anything to fix it right now because I can't even ssh into it a the moment

[21:22:44.0000] <MikeSmith>
likely will not be back til Europe comes online

[21:23:25.0000] <MikeSmith>
the lesson is, move your spec sources to github

[21:28:05.0000] <MikeSmith>
when did writing technical documents in HTML become such a challenge for Web developers? https://github.com/whatwg/serial/issues/3

[21:37:44.0000] <zewt>
losing hope at the future of the web when even github does that "don't link to the real file, link to a page that does an html refresh to the file" crap

[21:38:21.0000] <zewt>
re: no, really, copying a download link on my desktop and wgetting it in a terminal doesn't mean i want to download a 15k html file

[23:31:05.0000] <MikeSmith>
kinetik: dunno if you're on the dashjs mailing list but https://groups.google.com/d/msg/dashjs/4UfYEYZ_Zno/5lMubhuqxfcJ

[00:24:41.0000] <kinetik>
MikeSmith: thanks, i wasn't aware of it!

[00:40:11.0000] <MikeSmith>
kinetik: cheers

[02:28:33.0000] <Ms2ger>
annevk, ping

[02:33:52.0000] <jgraham>
zewt: I am starting to wonder if you are turning into RMS and mainly browsing the web async through command line tools :)

[02:34:55.0000] <Ms2ger>
Javascript is the devil's work!

[02:39:33.0000] <MikeSmith>
yay https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/t0XiZuMey7M ("Intent to Implement and Ship: Moving DOM attributes to prototype chains")

[02:40:15.0000] <Ms2ger>
Woo

[02:40:59.0000] <Ms2ger>
- The new behavior makes it easy to port Blink�s C++ implementation into JavaScript and reduce complexity of Blink. For example, we are planning to move editing implementation (e.g., execCommand) from C++ to JavaScript. With the new behavior, we just need to hook DOM attribute getters/setters and implement the logic all in JavaScript.

[02:41:09.0000] <MikeSmith>
though still "This change will regress several micro benchmarks by 10% or so. We have been working on this project for two years and are concluding that it would be hard to decrease the regression any more without crankshafting binding callbacks to V8."

[02:41:30.0000] <MikeSmith>
Ms2ger: yeah part that sounds pretty coold

[02:41:51.0000] <Ms2ger>
We'll see :)

[02:42:38.0000] <MikeSmith>
V8 sure seems to introduce a lot of quirky limitations

[02:43:47.0000] <Ms2ger>
Well, they've had a speed advantage because their setup meant they didn't have to do some checks

[02:44:09.0000] <MikeSmith>
ok

[03:06:39.0000] <jgraham>
"we just need to implement all the logic in javascript" - that's a usage of the word "just" that I haven't previously encountered

[03:09:30.0000] <Ms2ger>
I read "we just need to hook DOM attribute getters/setters, and then we can implement the logic all in JavaScript."

[03:11:25.0000] <jgraham>
I think what they meant to write was "we just need to hook COM attribute getters/setters, and then arghhh execCommand my eyes, my eyes, they burn, make it go away, please Mummy, please…"

[03:14:29.0000] <Ms2ger>
COM?

[03:17:39.0000] <jgraham>
er, DOM

[03:17:46.0000] <jgraham>
Although freudian slip really

[04:02:57.0000] <zcorpan>
nice. i didn't know that was a two-year project already

[04:03:15.0000] <zcorpan>
(or i didn't know it was a project at all)

[04:16:59.0000] <Ms2ger>
That's quite long

[04:17:18.0000] <Ms2ger>
We haven't even been working on webidl bindings for two years

[04:35:36.0000] <annevk>
Ms2ger: yo

[04:37:33.0000] <Ms2ger>
annevk, I think I figured it out... Wasn't sure if http://dom.spec.whatwg.org/#node-is-inserted would be called on all nodes in the inserted tree or just the roots of the subtrees

[05:22:53.0000] <smaug____>
"We cannot observe any regression in Robohornet."

[05:22:59.0000] <smaug____>
robohornet is still a thing?

[05:23:49.0000] <smaug____>
I thought it died immediately after it was announced

[05:38:32.0000] <MikeSmith>
smaug____: I don't remember hearing about it all

[05:40:42.0000] <smaug____>
https://github.com/robohornet/robohornet doesn't look too active

[05:41:11.0000] <smaug____>
robohornet was just mentioned in the google doc about getter/setters

[05:42:16.0000] <smaug____>
and that doc was dated 2013 Oct 30

[05:57:12.0000] <Ms2ger>
xhr-1 is back?

[05:57:38.0000] <Ms2ger>
"Initially, we'd planned to put together a draft with only the parts that are *already compatibly* supported across the major implementations, but it turned out that most of the major features are showing *subtle differences* in behavior."

[05:57:43.0000] <Ms2ger>
... and that's surprising?

[06:07:44.0000] <Ms2ger>
odinho, so RESO INVALID?

[06:21:51.0000] <annevk>
Ms2ger: it's only invoked for the inserted node

[06:22:10.0000] <annevk>
Ms2ger: if that node has descendants, they're not notified

[06:22:19.0000] <annevk>
Why does Ms2ger keep leaving the channel?

[06:23:48.0000] <annevk>
As for "xhr-1", sounds like everything old is new again.

[06:27:11.0000] <annevk>
Blink finally getting major IDL compliance boost: https://groups.google.com/a/chromium.org/d/msg/blink-dev/t0XiZuMey7M/j9PnVUUzBuUJ

[06:39:41.0000] <zcorpan>
i see 201 cases of <link charset> that's different from the document's content-type charset in webdevdata june

[06:40:36.0000] <zcorpan>
and 2359 <link charset>s in total

[06:40:36.0000] <Ms2ger>
annevk, because my class isn't in the restaurant

[06:42:19.0000] <Ms2ger>
annevk, and yeah, that's what I ended up with, but I was a little confused by things like... "for each node in nodes, in tree order, run node is inserted."

[06:42:44.0000] <annevk>
Ms2ger: DocumentFragment man

[06:42:48.0000] <Ms2ger>
Yeah

[06:43:00.0000] <zcorpan>
808 if i also log files with no content-type charset

[06:43:05.0000] <Ms2ger>
Maybe it'd make more sense to use "in order", or so

[06:43:09.0000] <annevk>
Soon we're gonna define ShadowRoot...

[06:43:14.0000] <Ms2ger>
Since nodes is a list, not a tree

[06:43:39.0000] <annevk>
Hmm, are they not still in a tree?

[06:43:59.0000] <Ms2ger>
Not anymore, at that point

[06:44:31.0000] <Ms2ger>
Oh, for inserted, they're in the new tree

[06:48:41.0000] <zcorpan>
322 if i take <meta charset> into account

[06:50:24.0000] <annevk>
zcorpan: Hixie: SimonSapin: I don't see the point in dropping <link charset> / <?xml-stylesheet charset?> as long as you still inherit from the document

[06:50:36.0000] <annevk>
zcorpan: Hixie: SimonSapin: both are in control of a potential attacker

[06:50:58.0000] <annevk>
zcorpan: Hixie: SimonSapin: so given that, the compatibility risk does not seem worth it

[06:51:14.0000] <SimonSapin>
agreed

[06:51:15.0000] <zcorpan>
yeah

[06:51:40.0000] <zcorpan>
the motivation would probably be to simplify things if nobody uses it

[06:51:45.0000] <SimonSapin>
I kept it in http://dev.w3.org/csswg/css-syntax/#environment-encoding

[06:51:57.0000] <zcorpan>
but people seem to use it

[06:52:12.0000] <SimonSapin>
zcorpan: do we have data on that?

[06:52:21.0000] <zcorpan>
SimonSapin: see above

[06:52:53.0000] <zcorpan>
next step would be to check if the style sheet actually contains non-ascii, but i'm not sure it's worth the trouble

[06:53:32.0000] <zcorpan>
SimonSapin: i can dump the data somewhere suitable. was there a bug about specifying <link charset> in html?

[06:54:27.0000] <SimonSapin>
z

[06:54:31.0000] <SimonSapin>
zcorpan: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703#c20

[06:55:14.0000] <zcorpan>
not a clean bug :-) i can file a new one though

[06:55:47.0000] <SimonSapin>
Hixie: told me to post it there, but I can make a new one if it helps

[06:55:54.0000] <SimonSapin>
s/://

[06:56:30.0000] <zcorpan>
oh, ok then i'll just use that bug

[07:01:38.0000] <SimonSapin>
zcorpan: also http://lists.w3.org/Archives/Public/www-style/2013Oct/0690.html

[07:02:08.0000] <zcorpan>
SimonSapin: yep

[07:05:28.0000] <zewt>
jgraham: D:

[07:06:35.0000] <annevk>
smaug____: your comment in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23565 makes it seem as if you have not read the bug

[07:06:57.0000] <annevk>
smaug____: what am I missing?

[07:11:25.0000] <zcorpan>
commented in the bug

[07:12:06.0000] <Ms2ger>
annevk, I think the argument about undefined==omitted really isn't as strong as some people make it out to be

[07:13:10.0000] <smaug____>
annevk: I have read the bug. And undefined !== omitted

[07:13:16.0000] <annevk>
Ms2ger: it's now core of the language

[07:13:56.0000] <Ms2ger>
annevk, it's not, it's core of what TC39 thinks the language should be

[07:14:11.0000] <Ms2ger>
annevk, in practice, it isn't true right now

[07:14:15.0000] <smaug____>
right

[07:14:19.0000] <annevk>
Ms2ger: unless you change ES6, that's nonsense

[07:14:55.0000] <Ms2ger>
annevk, and making it true has costs that may well be bigger than the benefit

[07:15:15.0000] <annevk>
Ms2ger: again, unless you change the direction of the language, this is not an argument we need to have here

[07:15:50.0000] <Ms2ger>
annevk, changing the direction of the language is fine with me

[07:15:57.0000] <annevk>
Ms2ger: so make it so

[07:16:14.0000] <annevk>
Ms2ger: meanwhile I'll skate to where the puck is going to be

[07:16:38.0000] <Ms2ger>
annevk, but people in TC39 seem to be so stubborn about it that it's not worth my time

[07:17:05.0000] <Ms2ger>
annevk, and backcompat in the DOM seems to be ignored

[07:17:09.0000] <annevk>
Ms2ger: have you ever engaged with them?

[07:17:32.0000] <annevk>
Ms2ger: just arguing with me on the sidelines is not going to do you much good and kind of feels like a waste of time for both of us

[07:18:06.0000] <Ms2ger>
annevk, you introduced a bug in dom

[07:18:12.0000] <Ms2ger>
annevk, who else should I argue with?

[07:18:56.0000] <smaug____>
Ms2ger: you're an editor too. Fix the bug :p

[07:18:58.0000] <Ms2ger>
annevk, and do you think that arguing with tc39 about this is not a waste of time?

[07:19:24.0000] <annevk>
Ms2ger: well, I think you're wrong and I think it makes sense to strive towards undefined and omitted being equal

[07:20:01.0000] <Ms2ger>
annevk, perhaps in general

[07:20:27.0000] <Ms2ger>
annevk, but in actual APIs, it seems to turn out to be developer-hostile or not web compatible

[07:20:46.0000] <Ms2ger>
annevk, case in point, classList.toggle

[07:21:01.0000] <annevk>
Ms2ger: that bug is not about classList.toggle

[07:21:32.0000] <Ms2ger>
annevk, sure, so that makes two cases where undefined==omitted leads to a dev-hostile API

[07:21:44.0000] <annevk>
What exactly is dev-hostile?

[07:22:06.0000] <Ms2ger>
cloneNode() not doing a deep clone is dev-hostile

[07:22:21.0000] <Ms2ger>
toggle("foo", bar) working right iff bar is not undefined is dev-hostile

[07:22:33.0000] <annevk>
cloneNode() not being equal to cloneNode(undefined) is more dev-hostile imo, especially longer term.

[07:22:49.0000] <smaug____>
why?

[07:23:05.0000] <annevk>
Because it would be inconsistent with all other APIs

[07:23:06.0000] <Ms2ger>
I'm not convinced it's *more* dev-hostile

[07:23:32.0000] <annevk>
So you cannot simply pass arguments through to a cloneNode() invocation. You have to special case undefined.

[07:24:02.0000] <Ms2ger>
The simply "pass through arguments" point is, to use one of the words you seem to like a lot, nonsense

[07:24:08.0000] <Ms2ger>
That's what ... is for

[07:25:03.0000] <annevk>
I don't see how ... would work in an API that takes an object as argument and you just want to pass one of that object's properties to cloneNode()

[07:25:32.0000] <Ms2ger>
That's not "simply pass through arguments", though

[07:25:37.0000] <annevk>
Yes it is

[07:26:07.0000] <annevk>
Anyway, s/arguments/parameters/ if that makes it easier

[07:26:28.0000] <Ms2ger>
I fully agree that cloneNode(something that happens to be undefined) should do a deep clone

[07:26:34.0000] <Ms2ger>
But we can't do that

[07:26:45.0000] <Ms2ger>
Yay webcompat

[07:27:06.0000] <Ms2ger>
But making cloneNode() not do a deep clone is throwing the baby out with the bathwater, IMO

[07:27:43.0000] <Ms2ger>
As bz said, it's the tail wagging the dog

[07:27:50.0000] <smaug____>
oh, cloneNode(undefined) should definitely not do deep clone

[07:28:17.0000] <annevk>
I'm going back to doing something useful

[07:28:22.0000] <smaug____>
:)

[07:28:38.0000] <smaug____>
lunch time

[07:28:45.0000] <Ms2ger>
Agreed to fix it as Gecko is going to implement it, then?

[07:46:23.0000] <Ms2ger>
Interestingly, the only hits on Google for sobbenbunker are brucel's

[08:02:41.0000] <annevk>
This is so fucked: https://rniwa.com/2013-10-29/web-compatibility-story-of-scrolltop-and-scrollleft/

[08:04:53.0000] <annevk>
Where did zcorpan go?

[08:04:57.0000] <annevk>
I wonder how https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c11 is relevant.

[08:05:48.0000] <annevk>
Never mind.

[08:30:02.0000] <annevk>
Domenic_: should there be some kind of convenience callback for promises when they complete? E.g. rather than .then(a,a) have .complete(a) or some such?

[08:30:20.0000] <Domenic_>
annevk: you mean like .then(a)?

[08:30:20.0000] <annevk>
Domenic_: so if you have cleanup code you don't do the mistaken thing of .then(a)

[08:30:33.0000] <Domenic_>
oh you mean .finally(a)

[08:30:33.0000] <annevk>
Domenic_: that's invoked for the failure case too?

[08:30:39.0000] <annevk>
Domenic_: ah right, finally

[08:30:41.0000] <Domenic_>
yes i really want .finally

[08:30:56.0000] <Domenic_>
not sure if there's political will for it, we tried earlier and decided not to rock the boat too much

[08:31:01.0000] <Domenic_>
might be worth trying again?

[08:31:15.0000] <annevk>
Domenic_: let's wait until we have two stable browsers shipping promises

[08:31:19.0000] <annevk>
Domenic_: and maybe some tests?

[08:31:22.0000] <Domenic_>
yeah seems good.

[08:31:38.0000] <Ms2ger>
Tests are good

[08:32:46.0000] <Domenic_>
we have lots of tests for the hardest part of the API, but only for one of the sugar methods.

[08:32:52.0000] <Domenic_>
also want to convert to test-262 form

[08:45:10.0000] <annevk>
Domenic_: for streams; is there an issue of notifying the reader of the writer having stopped writing to the stream because an error of sorts occurred?

[08:45:52.0000] <annevk>
Domenic_: for connection dropping, timeout, etc.

[08:55:46.0000] <MikeSmith>
annevk: re https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c8 the components work seems to be creating some unwelcome side effects

[08:55:55.0000] <MikeSmith>
the xml:base-under-another-name things

[08:56:12.0000] <MikeSmith>
in that specific case

[08:56:46.0000] <annevk>
MikeSmith: if Chrome implements it correctly it might be okay, but xml:base has always been fraught with bugs

[09:15:56.0000] <Hixie>
no opinions on how ports should work, huh

[09:21:23.0000] <dglazkov>
good morning, Whatwg!

[10:08:20.0000] <annevk>
Hixie: I'm having a hard time with GC vs memory

[10:18:59.0000] <Hixie>
annevk: hm?

[11:17:52.0000] <Domenic_>
annevk: yeah that's generally handled by pipe, but, yeah, error notification is tricky, worth opening an issue for tracking.

[11:37:07.0000] <marcosc>
Is anyone planning to (or already) implement this quota API?  https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html

[11:40:54.0000] <aklein>
Hixie: yt? I've got a MessageChannel/MessagePort question

[11:41:00.0000] <Hixie>
shoot

[11:41:10.0000] <Hixie>
/me is actually deeply in MessagePort right now

[11:41:30.0000] <aklein>
Hixie: see the attachment on https://code.google.com/p/chromium/issues/detail?id=312962

[11:41:37.0000] <Hixie>
marcosc: i don't understand why it's necessary, fwiw

[11:41:45.0000] <aklein>
basically I clone a port via postMessage

[11:41:50.0000] <aklein>
then transfer it again

[11:42:02.0000] <aklein>
neither Chrome nor Safari throw, even though I'm transferring the "target" port

[11:42:38.0000] <aklein>
I expect what ends up happening is the message (and the transferred port) end up in limbo, since the cloning process neuters the MessagePort that was expected to receive the message

[11:43:08.0000] <Hixie>
uh yeah, shouldn't that throw?

[11:43:18.0000] <marcosc>
Hixie, I'm thinking the same thing... but was not sure if maybe someone was implementing it.

[11:43:25.0000] <Hixie>
aklein: nobody could ever _want_ to write that though right?

[11:43:28.0000] <aklein>
the trick is that in a multi-thread, multi-process architecture it's hard to synchronously answer the question "what's the remote end of this port"

[11:43:36.0000] <aklein>
Hixie: right, it's a stupid thing to do

[11:43:44.0000] <Hixie>
yeah, i could see it'd be hard to tell

[11:44:00.0000] <aklein>
I'm wondering if we can relax the spec to not throw there

[11:44:26.0000] <aklein>
but I can admit that it seems nice to tell the author they've done something stupid

[11:44:56.0000] <Hixie>
aklein: so you're saying "If any of the objects in transfer are either the source port or the target port (if any), then throw a DataCloneError exception and abort these steps" should be changed?

[11:45:09.0000] <Hixie>
or rather, it should only check for source port

[11:45:19.0000] <aklein>
Hixie: that's the line I'm asking about, yeah. source port (should) be easy enough to check

[11:45:29.0000] <Hixie>
we can have an async requirement later that says "if it's the target port, abort, and optinally notify the author in the console"

[11:45:29.0000] <aklein>
Chrome can check the target port only in a really simple case

[11:45:41.0000] <aklein>
Hixie: that sounds much more implementable

[11:45:59.0000] <annevk>
Domenic_: done

[11:45:59.0000] <aklein>
haven't tried IE yet to see what it does

[11:46:14.0000] <Hixie>
aklein: can you file a bug on me to do that? http://whatwg.org/newbug

[11:46:42.0000] <Hixie>
aklein: while i have you here and thinking about ports, any opinion on http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0362.html ?

[11:47:03.0000] <aklein>
Hixie: heh, I'll take a look, but I only ended up here due to a memory leak

[11:47:06.0000] <aklein>
will file a spec bug

[11:47:16.0000] <Hixie>
aklein: heh

[11:47:19.0000] <aklein>
(after lunch, apparently)

[11:47:29.0000] <Hixie>
aklein: i only ended up here due to trying to define how scripts execute

[11:47:33.0000] <aklein>
Hixie: ha

[11:47:36.0000] <Hixie>
funny how many things end up at message ports :-P

[11:52:17.0000] <Hixie>
wtf, does firefox not support MessageChannel?

[11:52:46.0000] <Hixie>
even IE supports MessageChannel

[11:53:07.0000] <Hixie>
speaking of which... any IE10 or IE11 people able to get me the results of running http://www.hixie.ch/tests/adhoc/dom/web-apps/postMessage/ports/001.html and http://www.hixie.ch/tests/adhoc/dom/web-apps/postMessage/ports/002.html ?

[11:55:37.0000] <annevk>
Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=911972

[12:23:59.0000] <annevk_>
Hixie: will run in IE10 in a bit

[12:25:17.0000] <annevk>
Hixie: 001: did not receive, 002: received

[12:28:26.0000] <aklein>
Hixie: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23685, reading that thread now

[12:30:33.0000] <aklein>
Hixie: I probably don't know enough about history in Chromium to answer that thread well, but (C) sounds the best to me.

[12:32:15.0000] <annevk>
rafaelw: have you discussed with wycats what needs to happen for microtasks btw?

[12:32:26.0000] <annevk>
rafaelw: Hixie is apparently blocking on you guys

[12:38:55.0000] <rafaelw>
annevk: I think the discuss needs input from others.

[12:39:15.0000] <rafaelw>
I don't see Yehuda or I convincing each other.

[12:39:31.0000] <rafaelw>
s/discuss/discussion

[12:40:18.0000] <rafaelw>
Although this reminds me that Polymer hit an issue that was apropos. I'll go add info about that to the bug.

[12:52:32.0000] <Hixie>
annevk: thanks.

[12:53:04.0000] <rniwa>
annevk: indeed!

[12:53:29.0000] <Hixie>
aklein: looks like chrome and IE make the port get owned by the Window that received it, and so don't deliver if that frame gets navigated away

[12:53:43.0000] <Hixie>
which isn't intuitive to me as an author, but i understand why it happens

[13:25:58.0000] <zcorpan_>
i wonder if mpeg la will just remove the upper cap in the future to avoid the loop hole

[13:33:40.0000] <jamesr__>
the blockage on microtasks is about what to do when a microtask spins the event loop, right?

[13:33:53.0000] <jamesr__>
i tried to remove the HTML tokenizer dependency

[13:33:59.0000] <Domenic_>
no it's about different microtasks sources being interleaved or separate

[13:34:04.0000] <jamesr__>
ah

[13:34:06.0000] <jamesr__>
just FIFO

[13:34:08.0000] <jamesr__>
everything else is insane

[14:08:52.0000] <smaug____>
yes, microtasks should be fifo

[14:13:32.0000] <jamesr__>
make that FIFO, make the parser not spin the event loop, make sync XHR + window.showModalDialog() throw an exception when called from a microtask. done

[14:15:58.0000] <Hixie>
"make the parser not spin the event loop"?

[14:17:24.0000] <jamesr__>
Hixie: right now 12.2.5.4.8 The "text" insertion mode has a step that invokes the spin the event loop algorithm

[14:17:31.0000] <jamesr__>
if you managed to call that from within a microtask, you'd have a bad time

[14:17:46.0000] <Hixie>
i know, there's a bug about it

[14:17:59.0000] <Hixie>
you can't just not spin the event loop though

[14:18:01.0000] <jamesr__>
but i don't think the behavior of that algorithm is observably different from an algorithm that doesn't invoke the spin the event loop

[14:18:02.0000] <Hixie>
i mean, the alternative is to hang...

[14:18:04.0000] <jamesr__>
i think you can

[14:18:05.0000] <jamesr__>
nah

[14:18:21.0000] <jamesr__>
you can just refactor it. i send a proposal to whatwg a month ago, you replied, and i haven't had a chance to respond yet

[14:18:27.0000] <jamesr__>
we don't actually spin the event loop in blink

[14:18:37.0000] <jamesr__>
i doubt any browser really does

[14:18:39.0000] <Hixie>
if you don't return to the event loop, the event loop doesn't pump, so you can't do anything that requires the event loop

[14:18:55.0000] <Hixie>
since the parser is waiting for hte event loop to pump something...

[14:19:11.0000] <jamesr__>
you just return

[14:19:14.0000] <Hixie>
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=20821)

[14:19:20.0000] <Hixie>
returning is what spinning the event loop is

[14:19:51.0000] <Hixie>
"spin the event loop" is just "remember where you are, return, and then when the condition is met, queue a task to resume"

[14:23:39.0000] <jamesr__>
hm, well couldn't you just return to running microtasks?

[14:24:38.0000] <Hixie>
sure, the parser isn't a problem here

[14:24:46.0000] <Hixie>
it's showModalDialog() that's the probelm

[14:24:47.0000] <Hixie>
problem

[14:24:52.0000] <Hixie>
and document.close()

[14:25:20.0000] <Hixie>
well, actually, i guess the parser is too

[14:25:27.0000] <Hixie>
the problem is that the spec says to suspend the current task

[14:25:34.0000] <Hixie>
and there's no task running in a micortask

[14:25:35.0000] <Hixie>
microtask

[14:25:54.0000] <jamesr__>
ah, but you don't need to suspend the current task

[14:26:19.0000] <jamesr__>
since there's nothing to keep track of. once you hit the step in the algorithm that would spin the event loop you can just run the rest of the steps asynchronously

[14:26:21.0000] <jamesr__>
there's no context to return to

[14:26:30.0000] <Hixie>
there is in showModalDialog()

[14:26:38.0000] <jamesr__>
right. that should throw if called in a microtask

[14:27:04.0000] <Hixie>
i proposed that, people didn't like it

[14:27:32.0000] <Hixie>
see e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20821#c3 #c4 and #c5

[14:28:26.0000] <jamesr__>
hrm

[14:29:01.0000] <jamesr__>
well, i suppose if folks feel that having showModalDialog work in microtasks is important they can propose a way to make it work

[14:29:41.0000] <Hixie>
i proposed a way to do that too (see the end of that bug)

[14:29:56.0000] <Hixie>
it's just waiting on dom to be edited, but anne wants something else to be resolved first

[14:30:15.0000] <Hixie>
not sure what that is exactly, but it's in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296

[14:43:47.0000] <sicking>
/me wishes showModalDialog would just die a painful death

[14:44:10.0000] <Hixie>
we could make it die quicker by making it throw here

[14:44:11.0000] <sicking>
does anyone know how much it's used? Event-loop spinning is terrible for both authors and implementors

[14:44:38.0000] <Hixie>
i don't think it's used much on the open web

[14:44:48.0000] <Hixie>
more so probably in intranets and obscure web apps

[14:44:55.0000] <Hixie>
(in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20821#c3 you argued it shouldn't throw, fwiw)

[14:45:08.0000] <sicking>
i think we implemented it because it was used on some yahoo property

[14:45:31.0000] <Hixie>
i know the chrome guys keep trying to kill it

[14:45:45.0000] <Hixie>
so if you want some support, you can definitely find it there :-)

[14:45:54.0000] <Hixie>
support in a quest to kill it, i mean

[14:47:30.0000] <sicking>
Hixie: got any names?

[14:47:43.0000] <Hixie>
jamesr__ (see above), aklein, abarth...

[14:48:34.0000] <abarth>
SHOW MODAL DIALOG

[14:48:45.0000] <abarth>
that thing is a disaster

[14:49:29.0000] <sicking>
abarth: does chrome do warnings for deprecated APIs?

[14:49:53.0000] <sicking>
abarth: i.e. would you guys be willing to add a warning anytime its used and gather stats on how often that is?

[14:50:02.0000] <abarth>
sure

[14:50:13.0000] <sicking>
great, i bet we could do that too. I'll email

[14:50:41.0000] <abarth>
I'll add it right now

[14:50:57.0000] <sicking>
yay!

[14:51:09.0000] <aklein>
abarth: will happily lgtm such a usecounter

[14:51:42.0000] <sicking>
Hixie: does the new <dialog> still support modal (as in sync and event-loop-spinning) APIs?

[14:51:45.0000] <Hixie>
sicking: see how eager they are? i'm telling you, they hate it ;-)

[14:51:52.0000] <Hixie>
sicking: no

[14:51:57.0000] <sicking>
Hixie: great

[14:52:16.0000] <Hixie>
sicking: you call showModal() and it returns right away

[14:52:21.0000] <rafaelw>
sicking: I thought the issue with showModalDialog was OutlookWebAccess uses it.

[14:52:23.0000] <sicking>
nice

[14:52:34.0000] <Hixie>
sicking: if it takes long enough for <dialog> to get figured out, it might get updated to return a promise

[14:52:40.0000] <Hixie>
sicking: for now it fires an event on the <dialog> when closed

[14:54:10.0000] <jamesr__>
every now and then we try to kill it and find another page that depends on it that we can't break

[14:54:14.0000] <jamesr__>
but it's worth trying again

[14:55:16.0000] <sicking>
adding warnings first tends to be a good way to give it a declining usage rate

[14:55:29.0000] <sicking>
rather than an increasing one "because it's there"

[14:55:48.0000] <sicking>
killing it at this point is likely too early, but it's not too early to start driving down adoption

[14:56:25.0000] <jamesr__>
we only barely support it

[14:58:48.0000] <sicking>
it was a pretty late addition for us. I'm sad that we didn't resist harder.

[15:01:05.0000] <zcorpan_>
i see 65 showModalDialogs in http://webdevdata.org june data set (no external scripts)

[15:04:20.0000] <zcorpan_>
sicking: does warnings work for decreasing usage?

[15:05:32.0000] <zcorpan_>
sicking: absolute usage, that is?

[15:05:49.0000] <sicking>
zcorpan_: i don't actually have hard data. But I don't know if we're measuring it anywhere. What I do know is that we've received relatively little complaints about removing APIs once we've been warning about them for a while. Much more complaints when we remove APIs without warning first. But that could be a conicidence.

[15:10:40.0000] <zcorpan_>
sicking: is there a list of things you are warning about or have warned about, with start-end dates?

[15:12:45.0000] <sicking>
zcorpan_: see this file and its history: http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsDeprecatedOperationList.h

[15:13:25.0000] <zcorpan_>
sicking: thx

[15:14:50.0000] <sicking>
zcorpan_: warning text here: http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/dom/dom.properties#47

[15:23:16.0000] <zcorpan_>
mutation events seems like a suitable thing to check for

[15:25:08.0000] <zcorpan_>
although that sort of thing is likely to be in external scripts maybe

[15:26:22.0000] <sicking>
seems like we're already warning, no?

[15:28:09.0000] <zcorpan_>
yes. i mean check the usage of it and see if it has changed over time

[15:32:36.0000] <zcorpan_>
97 showModalDialogs in webdevdata's september data set (102,000 pages). so ~0.1% use showModalDialog in inline scripts

[15:35:55.0000] <Domenic_>
I ... I may have used showModalDialog ... don't hurt me ... https://github.com/NobleJS/setImmediate/blob/master/qUnitTest/tests.js#L80-L96

[15:52:08.0000] <jamesr__>
that's a silly test

[15:52:36.0000] <Domenic_>
nah, it failed before i added some interesting code

[16:00:11.0000] <zcorpan_>
sicking: march 2012, 0 instances of mutation events (small dataset though, i'm downloading the bigger december 2012 dataset now). september 2013, 86 instances out of 102,000 pages

[16:00:54.0000] <sicking>
zcorpan_: what dataset are you looking at? some set of urls? Or usage statistics from some browser?

[16:01:03.0000] <zcorpan_>
sicking: http://webdevdata.org

[16:01:58.0000] <sicking>
that's cool

[16:02:38.0000] <sicking>
i don't know if that's an approach that would make me feel comfortable with removing an API implementation though...

[16:04:28.0000] <zcorpan_>
i agree

[16:05:14.0000] <Hixie>
the bias towards home pages in these public data sets is the biggest problem i've seen with them

[16:05:41.0000] <Hixie>
home pages are a different kettle of fish entirely to the majority of web content, in my experience

[16:05:44.0000] <zcorpan_>
yeah, and lack of external scripts and styles is also a problem

[16:06:09.0000] <Hixie>
yeah

[16:06:14.0000] <Hixie>
(still, better than nothing)

[16:06:33.0000] <Hixie>
lack of external scripts and styles was the biggest problem i had doing research at google

[16:06:36.0000] <zcorpan_>
i've filed bugs about that but i haven't done any work to fix it, and it appears no one else has either

[16:07:50.0000] <zewt>
(what does "home pages" mean, exactly)

[16:07:56.0000] <gsnedders>
How does CommonCrawl stand up, BTW?

[16:08:07.0000] <zcorpan_>
zewt: GET /

[16:08:57.0000] <zewt>
"home pages" to me means "my personal website" (which seem not that common these days, overall)

[16:09:19.0000] <TabAtkins>
"the facebook home page" clearly means www.facebook.com, on the other hadn.

[16:09:43.0000] <zewt>
that's pretty meaningless to me

[16:09:52.0000] <TabAtkins>
Shrug, ok.

[16:10:28.0000] <zewt>
most people would probably interpret that as the page you see when logged in (not the login page), which incidentally are both served as "www.facebook.com"

[16:10:29.0000] <Hixie>
"home page" is pretty much industry standard speak for "/"

[16:11:03.0000] <zcorpan_>
gsnedders: how do i use it?

[16:12:07.0000] <gsnedders>
zcorpan_: Practically, you use Elastic MapReduce. The dataset, uncompressed, is over 100TB, so one can't really download it.

[16:15:14.0000] <zewt>
"XMLHttpRequest Level 1" :|

[16:15:58.0000] <zcorpan_>
gsnedders: is it free to run searches? i don't even see where to start. i tried creating an account but don't like to continue when it requires my credit card details :-|

[16:16:49.0000] <zcorpan_>
also, amazon account registration fails at handling non-ascii input

[16:17:12.0000] <gsnedders>
zcorpan_: No, you need to have credit for AWS server time

[16:17:49.0000] <gsnedders>
/me realizes why he can't ssh into his desktop

[16:17:52.0000] <gsnedders>
It's not turned on.

[16:20:11.0000] <odinho>
classic fault with modern computers.

[16:23:25.0000] <zcorpan_>
gsnedders: can i do this sort of thing with Elastic MapReduce? http://www.w3.org/Bugs/Public/show_bug.cgi?id=14703#c21

[16:25:12.0000] <gsnedders>
zcorpan_: You can do anything! Typically with Java, but anything!

[16:25:27.0000] <gsnedders>
zcorpan_: Also doing stuff on the entire dataset is kinda expensive.

[16:30:30.0000] <zcorpan_>
gsnedders: ok, so on the plus side it has deep pages. it doesn't seem to have external styles or scripts. and i'm totally unfamiliar with how to run the searches, and i have to pay for it

[16:34:27.0000] <Hixie>
oh bummer, something broke in my bug updating code

[16:34:50.0000] <zewt>
who's going to say it

[16:39:21.0000] <TabAtkins>
I tried to report a bug about ti, but...

[16:39:50.0000] <Hixie>
i don't understand what's wrong

[16:40:15.0000] <Hixie>
it's complaining about a bad token

[16:40:18.0000] <Hixie>
but the token is right...

[16:41:31.0000] <Hixie>
the hell

[16:41:43.0000] <Hixie>
TabAtkins: the bug _reporting_ code is actually fine :-P

[16:41:52.0000] <Hixie>
it's only the script that updates the bug with the diff that's broken


2013-10-31
[17:59:55.0000] <JakeA>
Lazy question about the Streams API incoming, brace for impact…

[18:00:20.0000] <JakeA>
Can you have two listeners for the same stream, or is the intent to create two streams?

[18:01:49.0000] <JakeA>
Eg, if I was returning a stream from a method, but also wanted to feed the output into storage

[18:02:22.0000] <JakeA>
Would I return one stream, add my own 'listeners' for the offline storage, then return the stream so the user could add their own

[18:02:50.0000] <JakeA>
or would I return two streams to the same resource, one to feed to the storage, and another to return

[18:34:56.0000] <JakeA>
(read the spec, looks like streams are single-use, so two streams would need to be created

[18:34:58.0000] <JakeA>
)

[19:39:12.0000] <rastus_vernon>
Thinking of it, why isn't border-width called border-thickness?

[02:10:54.0000] <Ms2ger>
"@csswg welcomes Daniel Glazman from Samsung Electronics Co., Ltd. as a new member of the @csswg ^DG"

[02:13:24.0000] <MikeSmith>
the sound of one chair clapping

[02:45:17.0000] <zcorpan>
31 mutation event uses in 2012-dec

[02:46:54.0000] <zcorpan>
so less than 0.1%

[02:55:02.0000] <MikeSmith>
zcorpan: you collecting data to support removing mutation events?

[02:55:41.0000] <zcorpan>
MikeSmith: no, i was curious to see if firefox issuing warnings for something meant that usage of it decreased over time

[02:56:01.0000] <MikeSmith>
ok

[02:56:20.0000] <zcorpan>
MikeSmith: for mutation events, it hasn't decreased between dec 2012 and sep 2013 looking at webdevdata

[02:57:00.0000] <zcorpan>
firefox started warning in march 2012

[02:57:01.0000] <MikeSmith>
it's probably just all the same sites using it

[03:19:18.0000] <darobin>
zcorpan: do you have the list of sites handy?

[03:19:48.0000] <zcorpan>
darobin: that use mutation events?

[03:20:02.0000] <darobin>
yeah

[03:23:58.0000] <zcorpan>
http://pastebin.com/9MyByTa9 http://pastebin.com/cmydcCwQ

[03:27:01.0000] <darobin>
zcorpan: thanks!

[05:25:51.0000] <zcorpan>
annevk: multi-browser bug filer, yes please

[06:12:51.0000] <annevk>
I'm missing zcorpan in http://foolip.files.wordpress.com/2013/10/webtech.jpg

[06:13:03.0000] <annevk>
and a whole bunch of other people. Did it really shrink that much?

[06:15:02.0000] <zcorpan>
no, it grew by most people on the picture. the rest of us already had a f2f like 2 weeks before so didn't have to join

[06:15:03.0000] <hsivonen>
"that's a small team" was my thought, too

[06:18:18.0000] <MikeSmith>
Erik's beard getting bigger

[06:19:01.0000] <MikeSmith>
soon he'll qualify for the IETF

[06:20:18.0000] <darobin>
ouch

[06:20:24.0000] <MikeSmith>
looking forward to seeing zcorpan with a Viking beard

[06:20:45.0000] <annevk>
zcorpan: ah, good to have some context

[06:25:05.0000] <zcorpan>
MikeSmith: i tried growing a beard once but it doesn't work. i can't grow a full beard. which i guess is nice from the point of view of easier shaving

[06:32:59.0000] <Ms2ger>
Oh, wow

[06:33:11.0000] <Ms2ger>
Servo supports <directory> rather than <dir>

[06:34:04.0000] <hsivonen>
Ms2ger: in HTML? why?

[06:34:43.0000] <Ms2ger>
Clearly HTMLDirectoryElement is the interface for <directory>

[06:34:45.0000] <zcorpan>
hmm, why does svg say that <title> can be shown in a tooltip?

[06:38:15.0000] <zcorpan>
Ms2ger: does it also support <anchor>, <media>, <quote>, <tablecaption>, <tablecol>, <mod>, <dlist>, <heading>, <image> (not as macro), <olist>, <paragraph>, <tablesection>, <tableheadercell>, <tablerow>, <ulist>?

[06:38:46.0000] <Ms2ger>
Not afaict :)

[06:43:14.0000] <annevk>
zcorpan: because in SVG <title> was the way to do tooltips

[06:43:26.0000] <annevk>
zcorpan: because they bought into the thing that you want markup in your tooltips

[06:44:01.0000] <annevk>
zcorpan: without really defining the rendering context and such for that, mind you

[06:45:21.0000] <zcorpan>
and <title> also seems to serve the purpose of being the title of the image, which doens't seem suitable for a tooltip (you don't show HTML's <title> as a tooltip)

[06:45:53.0000] <zcorpan>
and dirk says <title> also serves the purpose of being the alternative text of the image

[06:46:37.0000] <annevk>
SVG: broken and rarely used...

[06:46:45.0000] <zcorpan>
while chrisl says the text in <text>s are sufficient for text alternative

[06:47:12.0000] <annevk>
Although reportedly we want to use it more in Firefox OS to deal with screen differences and such. So mostly for its vector aspects.

[06:47:28.0000] <annevk>
zcorpan: you're in a meeting?

[06:48:01.0000] <zcorpan>
no

[06:48:49.0000] <wilhelm>
annevk: With IE8 gone real soon now, SVG usage will increase significantly. I use it on all my current projects. It may be shit, but it's still The Way to get vectors on the Web.

[06:49:38.0000] <annevk>
wilhelm: yeah, it's too bad it has all that other useless baggage.

[06:49:42.0000] <zcorpan>
the context here was tab announcing bikeshed's railroad thing on w3c-css-wg

[06:50:17.0000] <zcorpan>
i noticed *now* that i was talking about stuff on a non-public list

[06:51:35.0000] <annevk>
zcorpan: seems like he's actually saying <svg><circle/> LOL I'M TEXT </svg> is the way to do it

[06:51:38.0000] <SimonSapin>
Context is Bert complaining about http://dev.w3.org/csswg/css-syntax/#token-diagrams not showing up in a browser that does not support SVG

[06:52:04.0000] <wilhelm>
annevk: I don't disagree with that. <line>, <g> and <circle> ought to be enough for anyone. Drop the rest. (c;

[06:52:24.0000] <zcorpan>
annevk: but that's not valid svg, right? so that's hardly how it's designed

[06:52:34.0000] <annevk>
zcorpan: and yet he claims...

[06:53:07.0000] <annevk>
Which goes to show that nobody really uses SVG or this would have been figured out. But one day...

[06:53:43.0000] <zcorpan>
in other news, <!DOCTYPE html><svg><title>foo</title></svg> sets document.title in blink

[06:53:43.0000] <marcosc>
I made my first ever SVG image yesterday :)

[06:54:27.0000] <zcorpan>
marcosc: congrats! i remember making my first SVG image, i think i made the Atom logo back in 2006 or so :-)

[06:55:23.0000] <zcorpan>
http://simon.html5.org/sandbox/svg/atom

[06:55:39.0000] <marcosc>
fancy!

[06:56:11.0000] <annevk>
That reminds me, need to get "whatwggreen" to mean "#3c790a"

[06:56:39.0000] <marcosc>
heheheh, I just tried to post my SVG image to twitter and it told me SVG is not an image!!!

[06:57:27.0000] <Ms2ger>
wilhelm, how about <rect>?

[06:57:30.0000] <SimonSapin>
annevk: Feel free to send a pull request :) https://github.com/mozilla-servo/rust-cssparser/blob/master/make_color_data.py

[06:58:35.0000] <wilhelm>
Ms2ger: I haven't actually needed that one yet. But yes, the basic shapes should stay.

[06:59:04.0000] <zcorpan>
annevk: what happened with about:unicorn?

[06:59:12.0000] <Ms2ger>
I have... A long time ago I worked on flags a bit on wikipedia

[07:06:40.0000] <annevk>
zcorpan: still around somewhere

[07:07:30.0000] <odinho>
zcorpan: Shouldn't that clearly be <unorderedlist>?

[07:07:52.0000] <annevk>
zcorpan: http://html5.org/temp/unicorn.svg

[07:08:09.0000] <zcorpan>
odinho: no the interface is HTMLUListElement

[07:08:40.0000] <annevk>
zcorpan: could even support about:unicorn?whatwggreen

[07:08:52.0000] <annevk>
although that'd require some escaping I suppose

[07:09:08.0000] <odinho>
zcorpan: Ah, that was the connection. :)

[07:37:13.0000] <MikeSmith>
finally found a photo of zcorpan when he had his beard http://goo.gl/CJsQRW

[07:38:00.0000] <zcorpan>
that looks more like you MikeSmith

[07:38:16.0000] <wilhelm>
Ho, Ho?

[09:36:22.0000] <dglazkov>
good morning, Whatwg!

[10:20:06.0000] <Hixie>
annevk: i thought <desc> was for alternative text in svg...

[10:20:31.0000] <annevk>
Hixie: rings true, but SVG WG members all say something else

[10:23:10.0000] <Hixie>
what does the spec say?

[10:29:45.0000] <annevk>
no idea, don't really care

[10:29:52.0000] <Ms2ger>
"This involved fixing a flaky test, which was fun."

[10:30:06.0000] <Ms2ger>
/me wonders if foolip is interested in fixing Mozilla's flaky tests

[10:31:01.0000] <TabAtkins>
s/all say something else/Dirk says something else/

[10:34:45.0000] <Hixie>
i'm amused as to how tab and anne disagree about when "everyone" says something. this isn't the first time. :-P

[10:49:25.0000] <Ms2ger>
"My purpose was to lament..."

[10:49:37.0000] <Ms2ger>
Anyone have a guess who starts their emails like that?

[10:52:17.0000] <Hixie>
heh. i complained to dreamhost about low disk space on the host disk for whatwg.org. they responded basically "oops, we'll fix that" and then pasted some boilerplate at the end that said "if it's still going on in 2 days let us know. please include steps to reproduce."

[10:52:28.0000] <Hixie>
steps to reproduce being out of disk space? :-o

[10:54:21.0000] <annevk>
Ms2ger: if he only put that effort into doing something about it rather than complaining about my priorities over several emails

[11:27:22.0000] <Hixie>
TabAtkins: any update on what I should reference re "scoping element" ?

[11:28:14.0000] <Hixie>
TabAtkins: right now i reference "CSS Scoped Style Sheets, T. Atkins. Your Imagination."

[11:31:52.0000] <Hixie>
TabAtkins: would http://dev.w3.org/csswg/css-cascade/#scoping-element be more helpful?

[11:31:57.0000] <Hixie>
or accurate?

[11:31:58.0000] <Hixie>
long term?

[11:32:19.0000] <TabAtkins>
Will answer you in a bit - debugging something

[11:35:36.0000] <annevk>
So I need a better name than queryParams by tomorrow. Just go with searchParams and live with query being a spec concept and not exposed in APIs for this?

[11:35:40.0000] <annevk>
Anyway, movie

[11:41:58.0000] <Ms2ger>
Wasn't the string called search?

[11:42:10.0000] <Ms2ger>
Then that's probably good to match, even if it's a poor name

[12:26:25.0000] <krit>
MikeSmith:

[12:26:29.0000] <krit>
MikeSmith: ping

[12:30:17.0000] <krit>
Hixie: annevk: <desc> is better if you want to describe the purpose of the SVG document indeed.

[14:23:59.0000] <smaug____>
huh, I'm being told http://wiki.ecmascript.org/doku.php?id=strawman:weak_references might actually happen

[14:24:17.0000] <smaug____>
tc39 is on crack

[14:31:47.0000] <jamesr__>
who doesn't like observing gc behavior?

[14:32:24.0000] <TabAtkins>
From what I understand, there are some useful things that simply can't be done without weakrefs, unless you like leaking. :/

[14:32:58.0000] <Hixie>
that was my argument for PortCollection, but people aren't liking that either :-)

[14:34:03.0000] <smaug____>
exposing gc behavior forces all the implementations to use same gc behavior, effectively

[14:34:17.0000] <smaug____>
or leads to really odd bugs

[14:34:31.0000] <smaug____>
that weakref proposal especially

[14:34:43.0000] <smaug____>
PortCollection might not be as bad

[14:37:26.0000] <fantasai>
Hixie: Probably want to hook into both http://www.w3.org/TR/selectors4/#scoping-element and http://www.w3.org/TR/css-cascade-3/#scoping-element

[14:38:29.0000] <Hixie>
fantasai: wait, the term is defined in two places?

[14:38:55.0000] <Hixie>
smaug____: yeah (PortCollection's leak of GC behaviour is a real problem, i just don't know how to do anything to avoid it)

[14:39:05.0000] <fantasai>
Hixie: one's for scoping selectors, the other for scoping the cascade

[14:39:11.0000] <fantasai>
Hixie: You can do one without doing the other

[14:39:46.0000] <fantasai>
Hixie: I'm not 100% convinced the wording is awesome in that respect, but you do need to reference both specs' scoping sections

[14:40:42.0000] <Hixie>
isn't there some way i can just say "this is a style sheet whose scoping element is this element" and then have CSS take care of the rest? I don't want to keep having to have deep links into CSS, that's a maintenance nightmare

[14:41:22.0000] <fantasai>
Yeah, that should work. But you should still point at both specs

[14:41:30.0000] <fantasai>
For selectors, you also have to say what kind of scoping you're doing

[14:42:04.0000] <fantasai>
There will at some point probably exist a CSS spec that defines scoped styles as an overall concept

[14:42:13.0000] <fantasai>
but atm we only have the Selectors and Cascade pieces defined

[14:42:20.0000] <fantasai>
thus HTML has to tie them together :/

[14:42:54.0000] <fantasai>
/me putters in a text editor a moment

[14:43:22.0000] <Hixie>
well right now what i do is point to a fictional spec and let that tie them together

[14:43:37.0000] <Hixie>
which sounds like it might still be the right solution

[14:44:27.0000] <fantasai>
Maybe something like

[14:44:28.0000] <fantasai>
This is a style sheet whose selectors are scope-contained [SELCTORS4]

[14:44:28.0000] <fantasai>
and whose declarations are scoped in the cascade [CASCADE3] with

[14:44:29.0000] <fantasai>
the scoping element given as [rule to find scoping element].

[14:44:50.0000] <fantasai>
s/style sheet/CSS style sheet/

[14:44:58.0000] <Hixie>
avoiding doing that is the whole point here

[14:45:30.0000] <Ms2ger>
annevk-cloud, wdyt about making pre-insert step 6 a switch?

[14:46:05.0000] <fantasai>
Hixie: I don't think pointing at a fictional spec is helping implementers any

[14:46:45.0000] <fantasai>
Hixie: And this is still better than defining the mechanics of the CSS cascade and selection inline in the HTML spec

[14:47:14.0000] <Hixie>
there should just be one spec to point to that does all this

[14:47:31.0000] <Hixie>
i'm not setting myself up for wackamole, that just wastes my time and is no help to implementors either

[14:47:32.0000] <fantasai>
I'm not arguing with that statement

[14:47:46.0000] <fantasai>
but the fact is, such a spec does not yet exist

[14:48:21.0000] <fantasai>
and it's not anywhere on my immediate to-do list, either

[14:48:36.0000] <fantasai>
so this is the best I can do for you atm

[14:49:22.0000] <Hixie>
i think tab said it was on his todo list, which is why it's under his name in the refs right now :-)

[14:49:52.0000] <fantasai>
Sure, and helping him with it is on my todo list as well :)

[14:50:28.0000] <fantasai>
but it's so far down, that I wouldn't advise anyone to wait for it :)

[14:51:23.0000] <fantasai>
It'll happen someday, but for now, I think it's best to just point at Selectors 4 and Cascade 3

[14:51:38.0000] <fantasai>
at least that way there *is* a definition

[14:51:53.0000] <fantasai>
and it's not that much more complicated than referencing a theoretical Scoped Styles spec

[14:52:02.0000] <fantasai>
Either way you still have to pick what kind of selectors you want :)

[14:52:47.0000] <Hixie>
i plan on making precisely one change in this area, ever, in the future, and that should be an update to the references

[14:54:15.0000] <fantasai>
Suit yourself

[15:17:06.0000] <smaug____>
annevk-cloud: ping

[15:17:29.0000] <smaug____>
annevk-cloud: why getElementById() looks for descendants only

[15:18:32.0000] <smaug____>
I'd assume var d = document.createElement("div"); div.id = "foo"; div.getElementById("foo") == div;

[15:19:27.0000] <Ms2ger>
What does querySelector do?

[15:22:06.0000] <smaug____>
looks like it is buggy too

[15:25:27.0000] <TabAtkins>
Hixie: What's the reference you *want* to make?  I'll put it in my issues list and make sure I hit it properly when I write that spec.

[15:26:01.0000] <Hixie>
last time we chatted about that, we ended up on the following text and reference:

[15:26:04.0000] <Hixie>
A style sheet declared by a style element that has a scoped attribute and has a parent node that is an element is scoped, with the scoping element being the style element's parent element. [CSSSCOPED]

[15:26:17.0000] <Hixie>
[CSSSCOPED] CSS Scoped Style Sheets, T. Atkins. Your Imagination.

[15:26:48.0000] <Hixie>
though that seems to be grammatically bogus

[15:27:01.0000] <Hixie>
oh, no, i misread it

[15:27:40.0000] <Hixie>
anyway, that seems like sufficient text on the HTML spec's side, right? just needs the hooks on the CSS side, either in "CSS Scoped Style Sheets" or somewhere else

[15:28:09.0000] <Hixie>
("Your Imagination" is the publisher, as in "W3C" or "IETF")

[15:29:44.0000] <Hixie>
MikeSmith: you around?

[15:31:48.0000] <TabAtkins>
Yeah, that's sufficient.  kk

[15:32:18.0000] <Hixie>
cool

[15:32:34.0000] <Hixie>
there's some other prose around there that's looking for a home in the css world, fwiw

[15:32:54.0000] <TabAtkins>
https://github.com/tabatkins/specs/issues/20

[15:33:10.0000] <TabAtkins>
Feel free to file issues on me if you'd like me to work on them later.

[15:36:13.0000] <Hixie>
TabAtkins: filed a couple of them

[15:36:23.0000] <Hixie>
TabAtkins: (i think there's only two such things right now)

[15:36:32.0000] <Hixie>
TabAtkins: (do you prefer github's issue system to bugzilla?)

[15:36:37.0000] <TabAtkins>
Yes.

[15:36:47.0000] <TabAtkins>
Largely because of Markdown.

[15:36:48.0000] <Hixie>
fascinating

[15:36:51.0000] <Hixie>
ah

[15:36:53.0000] <Hixie>
i was gonna ask

[15:37:07.0000] <TabAtkins>
but also, you can reply directly, and also you can easily attach commits to them.

[15:37:13.0000] <TabAtkins>
reply directly from email*

[15:38:40.0000] <Hixie>
attaching commits to bugzilla is something i have a script for (though i'm in the process of debugging it right now). interesting that you like markdown though. i've always found it annoying when my text gets reinterpreted, especially in specs and programming where random syntax already has meaning. :-)

[15:39:05.0000] <TabAtkins>
Oh man, Markdown is the *best*. My blog is written in it. I write emails in it.

[15:39:13.0000] <TabAtkins>
And you have fenced code blocks for when you need syntax.

[15:39:20.0000] <Ms2ger>
/me will refrain from commenting :)

[15:39:21.0000] <TabAtkins>
Or inline code formatting, too.

[15:39:36.0000] <Hixie>
to each his own i guess :-)

[15:40:04.0000] <TabAtkins>
It's kiddie HTML, basically, that looks like writing a plain-text email.  It works very well.

[15:42:36.0000] <Hixie>
i really don't understand why bugzilla is refusing my token

[16:56:35.0000] <MikeSmith>
Hixie:  here now

[16:56:49.0000] <MikeSmith>
krit:  pong