2013-09-01
[04:43:30.0000] <MikeSmith>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22889#c1

[06:04:48.0000] <Ms2ger>
Mm, patches for css variables in Gecko

[09:15:00.0000] <Ms2ger>
jgraham, around, perhaps?

[09:18:31.0000] <Ms2ger>
Nvm, commented in the review

[10:05:13.0000] <Ms2ger>
jgraham, hrm, I seem to have been assigned IDB reviews in critic... That's probably a bad idea :)

[10:18:45.0000] <jgraham>
Ms2ger: Not around, but you can exclude yourself from certain paths using filters

[10:19:29.0000] <Ms2ger>
jgraham, the strange thing is that my filters don't (currently?) include idb

[10:20:33.0000] <jgraham>
Oh

[10:20:47.0000] <jgraham>
I can check. Remind me tomorrow?

[10:21:20.0000] <Ms2ger>
Okay, thanks

[10:21:27.0000] <Ms2ger>
Enjoy your weekend :)

[11:02:31.0000] <Ms2ger>
MikeSmith, needs-test and has-test keywords would be nice on the W3C bugzilla

[11:21:23.0000] <Ms2ger>
http://lists.w3.org/Archives/Public/www-talk/2013SepOct/0000.html

[11:21:28.0000] <Ms2ger>
I wonder how that will go

[13:08:59.0000] <jgraham>
Ms2ger: Which review(s)?

[14:21:51.0000] <Ms2ger>
jgraham, I'll look tomorrow :)

[14:34:59.0000] <MikeSmith>
about Ms2ger needs-test and has-test keywords, I see https://bugzilla.mozilla.org/describekeywords.cgi has testcase-wanted and testcase keywords instead, so I reckon I will make ours match those instead


2013-09-02
[17:31:39.0000] <crocket>
hi guys

[17:31:59.0000] <crocket>
Internet Explorer 8,9,10 can't display http://pastebin.com/9wRMvk3c

[17:32:13.0000] <crocket>
I think IE can't display an image if its src attribute contains ampersands.

[21:45:24.0000] <gsnedders>
jgraham: Do you want to handle your doc loading tests?

[21:45:32.0000] <gsnedders>
jgraham: Review-wise, etc.?

[22:00:49.0000] <heycam>
TabAtkins, the SVG WG's review of CSS Variables will be one day late; hope that's ok

[22:01:35.0000] <heycam>
(forgot to get to the review earlier, and our call to approve the review comments will be on Thursday)

[01:12:57.0000] <zcorpan_>
TabAtkins: why not drop dppx altogether if we add x?

[01:28:05.0000] <SimonSapin>
zcorpan_: isn't it too late to remove it from MQs?

[01:28:21.0000] <zcorpan_>
SimonSapin: dunno?

[01:28:44.0000] <SimonSapin>
oh, wait, it’s not in MQ

[01:29:23.0000] <SimonSapin>
at least not in the L3 spec

[01:29:58.0000] <SimonSapin>
but L4 refers to Values & Units which does have dppx

[01:31:16.0000] <SimonSapin>
and it’s implemented data:text/html,<style>@media(max-resolution:14dppx){body{background:green

[01:59:06.0000] <Ms2ger>
jgraham, https://critic.hoppipolla.co.uk/r/40 for example

[02:12:04.0000] <jgraham>
gsnedders: I am happy for other people to push fixes to them ofc

[02:12:45.0000] <jgraham>
(if they are forked from your gh, I don't think I *can* push fixes. Also: I hate github.)

[02:13:06.0000] <jgraham>
Ms2ger: OK, investigating

[02:20:32.0000] <MikeSmith>
Ms2ger: so I added "testcase-wanted" and "testcase" but if you really want "needs-test" and "has-test" instead (or something else), lemme know

[02:23:47.0000] <zcorpan_>
SimonSapin: i see it being used in webdevdata also, so yeah

[02:24:11.0000] <zcorpan_>
mostly youtube.com

[02:25:41.0000] <jgraham>
Ms2ger: I'm not really sure what's going on. Did you change your filters at some point in the past from e.g. "/" to something more specific? I don't think such a chnage will unassign you from specific reviews (but you can do that manually on a per-review basis)

[02:25:51.0000] <jgraham>
If that's not the case, I will look more closely

[04:18:59.0000] <jgraham>
TIL: DRM is evil

[04:19:13.0000] <jgraham>
Only joking, that was a long time ago

[04:20:49.0000] <jgraham>
But today I discovered that the "docking station" for my laptop doesn't provide external monitor support under linux "because of content protection"

[04:23:05.0000] <smaug____>
there is mxr like thing for blink somewhere, right?

[04:23:34.0000] <smaug____>
hmm, perhaps I can just check webkit

[04:26:55.0000] <smaug____>
so, hrm, what...

[04:27:12.0000] <smaug____>
HTML spec doesn't define window.moveTo and other similar methods ?

[04:30:21.0000] <Ms2ger>
smaug____, might be in cssom?

[04:31:17.0000] <smaug____>
hmm

[04:31:19.0000] <smaug____>
maybe

[04:31:46.0000] <smaug____>
no

[04:43:26.0000] <zcorpan_>
what's moveTo?

[05:01:23.0000] <smaug____>
zcorpan_: https://developer.mozilla.org/en-US/docs/Web/API/window.moveTo

[05:06:40.0000] <zcorpan_>
doesn't seem to work in opera 16, but works in chrome and firefox

[05:07:42.0000] <zcorpan_>
the html spec for window.open() says to ignore the third argument, iirc

[05:09:05.0000] <zcorpan_>
"The third argument, features, has no defined effect and is mentioned for historical reasons only. User agents may interpret this argument as instructions to set the size and position of the browsing context, but are encouraged to instead ignore the argument entirely." http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-open

[05:09:44.0000] <smaug____>
opera 16?

[05:10:02.0000] <smaug____>
I thought opera was like 12.x or perhaps 13

[05:10:52.0000] <smaug____>
ah, 12.16

[05:11:13.0000] <smaug____>
oh, for windows there is 16

[05:12:22.0000] <zcorpan_>
we skipped 13 in the move to blink, so the first version with blink on mobile was opera 14. then the first version with blink on desktop was opera 15 since it used a later version of chromium

[05:12:33.0000] <zcorpan_>
and now the version on the Next channel is 16

[05:17:39.0000] <zcorpan_>
i guess it makes sense to spec moveTo in cssom-view

[05:23:19.0000] <smaug____>
no sure why there

[05:23:54.0000] <smaug____>
oh, scroll* are there

[05:24:00.0000] <smaug____>
but those are kind of separate things

[05:24:05.0000] <smaug____>
they are about the view port

[05:24:16.0000] <smaug____>
move* are about the OS-level window

[05:25:07.0000] <smaug____>
hmm, Screen is there too

[05:25:52.0000] <zcorpan_>
filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23127

[05:27:09.0000] <zcorpan_>
i'm tempted to require css pixels since using device pixels seems like an effective way to make things confused and broken

[06:21:00.0000] <zcorpan_>
hsivonen: MikeSmith: validator.nu times out for me

[07:07:01.0000] <MikeSmith>
zcorpan_: for me to. but http://html5.validator.nu/ is responding at least

[07:07:15.0000] <zcorpan_>
yeah

[07:08:13.0000] <zcorpan_>
does html5.validator.nu have better uptime or is it just that it happens to work when validator.nu is down?

[07:08:56.0000] <MikeSmith>
it's on a completely different server I think

[07:09:09.0000] <MikeSmith>
and works pretty much all the time

[07:09:37.0000] <zcorpan_>
i've changed my Makefiles to use html5. instead

[07:16:14.0000] <zcorpan_>
"IE11 Preview changes the character encoding for URLs. Specifically, query strings and XHR requests are now encoded using UTF-8 character encoding." http://msdn.microsoft.com/en-us/library/ie/bg182625(v=vs.85).aspx#utf8

[07:17:06.0000] <zcorpan_>
is that web compatible for query strings?

[07:17:15.0000] <zcorpan_>
annevk: ^

[07:21:29.0000] <zcorpan_>
the doctype can now trigger edge mode

[07:40:56.0000] <zcorpan_>
TabAtkins: can you give an example of how to do what he wants with flexbox or grid (if it's possible) in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22772#c13 ?

[10:11:16.0000] <SteveF>
zcorpan: new dataset http://files.paciellogroup.com/blogmisc/data/webdevdata.org-2013-09-01-201332.7z 102,000 pages

[12:44:14.0000] <annevk>
zcorpan_: seems like they just aligned URL parsing with XMLHttpRequest's requirement to not override the default encoding for that (which is utf-8)?


2013-09-03
[20:58:58.0000] <zcorpan>
SteveF: man that is going to kill my poor macbook :-)

[22:57:05.0000] <gsnedders>
jgraham: I guess the GH workflow would be PRs to me on the PR branch. Ergh.

[22:57:23.0000] <gsnedders>
jgraham: But idk if I know the spec well enough and/or have the time.

[22:57:49.0000] <gsnedders>
jgraham: Whereas you probably have an employer kean on you getting them into the testsuite. :)

[01:54:07.0000] <jgraham>
Ms2ger: Achievement unlocked: used all of map, filter and reduce in a single expression

[01:54:25.0000] <jgraham>
gsnedders: It could be. That would be terrible though

[01:55:22.0000] <Ms2ger>
jgraham, very much Aryeh's achievement :)

[01:58:03.0000] <annevk>
When is heycam going to make IDL a Living Standard already?

[01:58:13.0000] <heycam>
(yeah gosh)

[01:58:21.0000] <annevk>
v1/v2, everyone implements v2 anyway

[01:58:29.0000] <annevk>
heycam!

[01:58:32.0000] <heycam>
hi!

[01:58:38.0000] <heycam>
Living Standard in CVS

[01:58:41.0000] <heycam>
undead standard

[01:58:50.0000] <annevk>
hah, CVS

[01:59:21.0000] <annevk>
I can teach you some GitHub if you want :p

[01:59:25.0000] <heycam>
pfft

[01:59:39.0000] <annevk>
heycam: about IDL, we have ByteString and [EnforceUTF16] and they're supposedly doing the same thing, but different

[01:59:51.0000] <Ms2ger>
You can even get some idl.spec.whatwg.org

[02:00:06.0000] <annevk>
heycam: e.g. they both coerce the input to a different type, which is arguably what DOMString, long, etc. do too

[02:00:33.0000] <annevk>
heycam: well, you didn't spec [EnforceUTF16] that way, which is kinda annoying and which I think is why we want to make that a type

[02:00:42.0000] <heycam>
annevk, so they should be the same kind of thing

[02:01:10.0000] <annevk>
heycam: if we don't want to make that a type, we should maybe drop ByteString and [EnforceUTF16] and just deal with it at the spec level... not sure that's necessarily great

[02:02:14.0000] <heycam>
/me brb phone

[02:02:27.0000] <Ms2ger>
bz may feel differently

[02:02:55.0000] <jgraham>
Ms2ger: r+ but I didn't check tht you were actually using idlharness correctly, only that the code you posted would implement the parts of the spec that you quoted if you were using the datastructures correctly\

[02:03:32.0000] <Ms2ger>
jgraham, the DOM/HTML tests seem to pass, so I'm going to claim it's correct :)

[02:03:33.0000] <annevk>
ByteString = code units -> bytes; [EnforceUTF16] DOMString = code units -> mapped code units (whereas I wanted Unicode scalar values)

[02:03:45.0000] <annevk>
heycam: ^

[02:03:52.0000] <annevk>
Ms2ger: about what?

[02:03:54.0000] <jgraham>
Ms2ger: Right, I think what I checked, plus some passing tests is convincing

[02:04:00.0000] <jgraham>
+,

[02:04:37.0000] <Ms2ger>
annevk, the types thing, but maybe I misunderstood you

[02:06:24.0000] <Ms2ger>
jgraham, thanks

[02:06:49.0000] <heycam>
annevk, yeah I can see it from that perspective. (was just thinking that before the phone rang.)

[02:06:57.0000] <annevk>
Ms2ger: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22808 is a pretty pointless comment... We often "break" something that works and we do that because of X. So if you don't give an argument against X...

[02:07:16.0000] <heycam>
annevk, I'm sympathetic to the argument of not having ByteString given it's not likely to be used elsewhere

[02:07:24.0000] <heycam>
whereas [EnforceUTF16] sounds like something that could be more generally useful

[02:07:48.0000] <heycam>
btw I'm going to be in the london office for the few days before the summit

[02:08:12.0000] <annevk>
heycam: that's awesome, but I won't be in London, but I'll be in Brussels

[02:08:17.0000] <heycam>
oh =P

[02:08:18.0000] <heycam>
ok

[02:08:58.0000] <annevk>
TAG is meeting the days leading up to it in Boston...

[02:09:41.0000] <heycam>
I'll see you in Brussels then hopefully

[02:10:13.0000] <heycam>
oh, gotta go; maybe back later

[02:10:18.0000] <annevk>
Okay, so say we remove ByteString and deal with it in prose. Can we make the output of EnforceUTF16 Unicode scalar values?

[02:13:23.0000] <annevk>
Hah, whenever I meet heycam|away on IRC, it's for 5 minutes and he typically has a call or meeting during that :-)

[02:14:14.0000] <Ms2ger>
jgraham, oh, and a "merge this PR" button in critic would be nice :)

[02:15:50.0000] <jgraham>
Ms2ger: Indeed, but when I tried to add one I couldn't get the authentication right

[02:16:15.0000] <jgraham>
I guess I could just use the github account of the critic instance itself

[02:19:24.0000] <Ms2ger>
/me grumbles at the bbc

[02:20:25.0000] <jgraham>
Ms2ger: You've started reading the Telegraph or something?

[02:20:34.0000] <Ms2ger>
Nah

[02:21:06.0000] <Ms2ger>
I'm well in range of the radio 4 LW signal, but due to "rights restrictions", I can't listen online

[02:21:37.0000] <jgraham>
To sport or something? Usually you can listen to the radio online

[02:22:01.0000] <Ms2ger>
Cricket

[02:22:07.0000] <jgraham>
Ah

[02:22:21.0000] <jgraham>
Yeah, not sure that's the BBC's fault really

[02:22:40.0000] <jgraham>
I mean it is obviously stupid, but they get sold region-restricted rights

[02:22:46.0000] <Ms2ger>
/me grumbles at some unidentified party

[02:22:51.0000] <jgraham>
Very annoying

[03:01:00.0000] <annevk>
Man, token-based security people are at it again on public-webappsec

[03:01:12.0000] <annevk>
I wonder if anyone else here is subscribed to that list...

[03:02:50.0000] <Ms2ger>
Not me

[03:15:21.0000] <darobin>
me neither

[03:15:47.0000] <Ms2ger>
Ah, darobin

[03:15:53.0000] <Ms2ger>
Back from vacation? :)

[03:15:54.0000] <darobin>
Ms2ger!

[03:16:00.0000] <darobin>
I'm still pondering that one

[03:19:23.0000] <jgraham>
Sounds like France

[05:08:24.0000] <annevk>
Anyone recall when Hixie_ and I discussed how to write down tasks in Fetch?

[05:08:52.0000] <annevk>
Most recent discussion that is, not the one Google returns in March...

[05:20:51.0000] <zcorpan>
anyone know if it's possible to achieve this with css? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2504

[05:21:00.0000] <zcorpan>
(i.e. what the script does)

[05:27:47.0000] <annevk>
Found it: http://krijnhoetmer.nl/irc-logs/whatwg/20130723#l-734

[05:51:12.0000] <annevk>
Fetch thing is https://www.w3.org/Bugs/Public/show_bug.cgi?id=22387 now

[06:18:56.0000] <annevk>
matjas: clearly we need @spaceatkins as a fake @tabatkins

[06:19:28.0000] <Ms2ger>
annevk, so you're fake Alex?

[06:19:32.0000] <matjas>
oh god, please make this happen internets

[06:19:48.0000] <annevk>
Ms2ger: your logic is infallible

[06:24:53.0000] <jgraham>
At least it would be clear that spaceatkins was better than tabatkins

[06:29:44.0000] <matjas>
you guys, tabs are way better

[06:30:45.0000] <Ms2ger>
At inducing rage?

[06:33:24.0000] <Ms2ger>
annevk, r? https://critic.hoppipolla.co.uk/r/295

[06:34:57.0000] <annevk>
Ms2ger: commit message could say empty string names, seems fine otherwise

[06:35:19.0000] <SimonSapin>
tabs are theoretically superior, but worse is better

[06:35:35.0000] <annevk>
Ms2ger: done it through the interface now

[06:35:39.0000] <Ms2ger>
Thanks

[06:37:45.0000] <jgraham>
The "tabs are better" arguments are all crazy talk

[06:38:42.0000] <Ms2ger>
There's something to be said for them, but in real life you also want alignment, and that needs spaces

[06:38:49.0000] <Ms2ger>
And mixing them is a horror

[07:24:47.0000] <darobin>
/me wonders if people here know about http://w3tmemes.tumblr.com/

[07:29:39.0000] <SimonSapin>
darobin: what does w3t stand for?

[07:30:09.0000] <darobin>
W3C Team

[07:30:54.0000] <SimonSapin>
wow, this is even more obscure than w3cmemes :p

[07:34:29.0000] <darobin>
SimonSapin: yeah, it references all the Sikkrit Cabal stuff

[07:34:47.0000] <darobin>
that said, if you know about W3C I reckon you can figure out what most apply to, or at least imagine the situation :)

[07:59:37.0000] <annevk>
darobin: with some you can imagine half of the text being censored :)

[07:59:55.0000] <annevk>
darobin: does this have a Twitter account?

[08:00:23.0000] <annevk>
http://w3tmemes.tumblr.com/image/55808644257 :-)

[08:02:57.0000] <darobin>
annevk: I don't believe it does, but you can set Tumblr up to tweet automatically, right?

[08:11:40.0000] <annevk>
darobin: yeah, should be pretty easy

[08:13:31.0000] <darobin>
well I couldn't possibly know who's behind this, but I'll try to pass the suggestion along

[08:17:42.0000] <SteveF>
anybody know of any implementations of inert attribute?

[09:30:34.0000] <TabAtkins>
Ms2ger: I mix tabs for indent and spaces for alignment regularly, and I haven't died yet.  It Just Works (tm).

[09:32:02.0000] <Ms2ger>
TabAtkins, do you get it right?

[09:32:27.0000] <TabAtkins>
...yes?  How do you get it wrong?  It seems like something you'd have to be deliberately stupid at to mess up.

[09:32:29.0000] <jgraham>
TabAtkins: Has anyone else working with your code died?

[09:32:42.0000] <TabAtkins>
jgraham: Not to my knowledge, but it's open-source, so who knows?

[09:33:17.0000] <jgraham>
TabAtkins: Uh, really? I don't think it's even well specified how to do it

[09:33:19.0000] <jgraham>
e.g.

[09:33:28.0000] <jgraham>
def foo(bar,

[09:33:36.0000] <TabAtkins>
You... tab to the indentation level you want, then space to the alignment you want.

[09:33:36.0000] <jgraham>
       baz)

[09:33:44.0000] <jgraham>
(heh, missed a space)

[09:33:59.0000] <TabAtkins>
I'm not in a fixed-width font anyway, so it's lost on me.

[09:33:59.0000] <jgraham>
How many tabs and how many spaces on the second line?

[09:34:01.0000] <JakeA>
I used to use tabs for a semantic block indent, and spaces for a presentational alignment

[09:34:09.0000] <TabAtkins>
JakeA: Yes.

[09:34:35.0000] <TabAtkins>
jgraham: Tab to the same line indentation as the primary line, because you're not wanting to indent any more.  Space to whatever alignment you want.

[09:34:50.0000] <JakeA>
so you'd never have tabs after a space, but you may have spaces after a tab

[09:34:59.0000] <JakeA>
hah, yes, that

[09:35:01.0000] <jgraham>
TabAtkins: Some people would consider that to need one extra level of indentation

[09:35:15.0000] <TabAtkins>
jgraham: Literally *any other combination* would be completely fucked up if you changed your tab size.

[09:35:23.0000] <TabAtkins>
Those people are dumb.

[09:35:29.0000] <TabAtkins>
And don't understand what tabs are for.

[09:35:32.0000] <jgraham>
I think the sematic argument is pure crazy

[09:35:42.0000] <Ms2ger>
It's fine in theory

[09:35:47.0000] <Ms2ger>
Like astrophysics

[09:35:48.0000] <jgraham>
Your code has the semantics that the compiler gives it

[09:35:56.0000] <TabAtkins>
The "sementic" argument is just a shorthand for "look, dammit, I like a different indent size than you".

[09:36:09.0000] <jgraham>
If the complier isn't infering any semantics from it, there aren't any

[09:36:10.0000] <JakeA>
yeah

[09:36:20.0000] <TabAtkins>
(I often go for a 3-space indent.)

[09:37:08.0000] <jgraham>
So the "semantic" argument is a shorthand for "presentation"?

[09:37:10.0000] <jgraham>
Weird

[09:37:42.0000] <TabAtkins>
Um, no.  Quit being deliberately difficult.  You know what Jake means by "semantic block".

[09:37:45.0000] <JakeA>
a tab is 1 unit of indent sized to the viewer's preference, space is a single char-width alignment where the user's preference is deliberately ignored

[09:38:38.0000] <TabAtkins>
The rule is very simply expressed in terms of presentation - if I change the tab size, will I fuck up anything's alignment?  If so, you're using them wrong.

[09:39:01.0000] <JakeA>
yeah, that's a better explanation

[09:39:21.0000] <TabAtkins>
If you want to link that up to the word "semantics", it's similar to "if I view this page in a different modality, will anything fuck up?".

[09:43:22.0000] <TabAtkins>
One could certainly think that it's not worth it to have a variable indentation size, but I point you to the fact that WebKit and Chrome settled on *different* indent sizes, and editing both at the same time is extremely frustrating.

[09:43:32.0000] <TabAtkins>
Especially now that we're Blink.

[09:43:44.0000] <Ms2ger>
Shrug

[09:44:08.0000] <Ms2ger>
It's only infuriating if you don't use the tab key for indentation

[09:44:41.0000] <jgraham>
TabAtkins: Having seen the code style choices of chromium, I can only conclude that it's possible to fuck anything up if you put your mind to it

[09:44:47.0000] <TabAtkins>
There's also my observation that, in the absence of machine-based hygiene checking, I have *never* seen a space-based indent file that didn't fuck up its indentation at some point.

[09:45:23.0000] <jgraham>
I don't know who thought that making python look like C++ (not just in indentation, but in every way they could find) was a good idea

[09:45:28.0000] <TabAtkins>
As evidenced by the fact that every time I have to edit one, and I try a basic conversion of "apparent indent size -> tabs", there's stray spaces everywhere.

[09:45:40.0000] <TabAtkins>
jgraham: No comment. :/

[09:49:03.0000] <TabAtkins>
heycam|away: Yeah, late review is fine.

[09:55:17.0000] <zewt>
dear people who say "fx" when they mean "ff": stop it, it's confusing

[09:55:47.0000] <Ms2ger>
Fx

[10:17:21.0000] <TabAtkins>
F5x

[10:27:59.0000] <TabAtkins>
zcorpan: Regarding that bug, depending on his markup Grid can handle that.  Otherwise, it's dependent on us improving the Position property, which fantasai and I intend to do next year.

[10:28:31.0000] <zcorpan>
TabAtkins: see the last comment for the markup

[10:29:42.0000] <TabAtkins>
zcorpan: Right, if he actually needs the <table>, he'll have to wait for Position.  If he's just wanting to put things in a grid, and can make #i2 a sibling of the other "cells", then Grid'll do.

[10:30:34.0000] <zcorpan>
TabAtkins: is there a bugzilla component for Position?

[10:31:27.0000] <zcorpan>
TabAtkins: can grid create cells that overlap?

[10:31:40.0000] <TabAtkins>
Maybe.  If not, ask MikeSmith to create one.

[10:31:52.0000] <TabAtkins>
And yes, grid items can overlap.

[10:32:11.0000] <TabAtkins>
(Named grid areas, created by the template, can't, but you can always manually specify the position and size of grid items.)

[10:35:09.0000] <Hixie_>
Ms2ger: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=23119 ?

[10:35:20.0000] <Ms2ger>
Hixie_, yes

[10:35:31.0000] <Hixie_>
Ms2ger: what's the problem with the spec?

[10:35:53.0000] <Ms2ger>
/me loads up that part of the spec

[10:36:23.0000] <Ms2ger>
"If the stack of open elements has a button element in scope, then run these substeps:"

[10:36:28.0000] <Ms2ger>
I have no idea what that means

[10:36:52.0000] <Ms2ger>
"has a button element in scope" links to "have an element in scope", which lost track of the button

[10:37:37.0000] <Ms2ger>
Then I get a link titled "has an element in the specific scope" to "have an element target node in a specific scope"

[10:37:50.0000] <Ms2ger>
Where suddenly a 'target node' appears out of thin air

[10:38:33.0000] <jgraham>
Right, iirc, there are two problems. It doesn't define the inputs to the algorithm, and it doesn't define the concept of equality it is using

[10:41:05.0000] <Hixie_>
Ms2ger: "has an element in scope" defines which elements are in scope

[10:41:17.0000] <Hixie_>
Ms2ger: so then you see if one of the elemnets in scope is a button element

[10:41:55.0000] <Hixie_>
Ms2ger: it's like saying "does this fruit bowl have a red apple" where you have an algorithm that defines whether "a fruit is an apple in a bowl"

[10:41:56.0000] <jgraham>
Hixie_: The problem is deeper

[10:42:13.0000] <jgraham>
Hixie_: "has an element in a specific scope" is broken

[10:42:18.0000] <Hixie_>
how so?

[10:42:26.0000] <Ms2ger>
Hixie_, jgraham managed to explain to me what you meant, but that doesn't make the spec say it

[10:42:45.0000] <Hixie_>
Ms2ger: as far as i can tell, it's what the spec says.

[10:42:54.0000] <Hixie_>
Ms2ger: i don't understand why it wouldn't say that.

[10:42:59.0000] <jgraham>
Hixie_: It uses a concept "target node" that is undefined

[10:43:05.0000] <Hixie_>
jgraham: that was fixed over the weekend

[10:43:28.0000] <Ms2ger>
You write an algorithm that takes an argument "target node"

[10:43:40.0000] <jgraham>
http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#has-an-element-in-the-specific-scope looks wrong to me

[10:43:55.0000] <Ms2ger>
But none of the callers of that algorithm explain what they're passing as "target node"

[10:44:25.0000] <Hixie_>
Ms2ger: the algorithm isn't ever called as far as i know

[10:44:31.0000] <Ms2ger>
What

[10:44:37.0000] <Hixie_>
Ms2ger: it's a definition, not an imperative algorithm that's called

[10:44:45.0000] <jgraham>
I am now super-confused

[10:44:59.0000] <Ms2ger>
"The stack of open elements is said to have an element in scope when it has an element in the specific scope consisting of the following element types:"

[10:45:03.0000] <Ms2ger>
That's calling it

[10:45:15.0000] <Hixie_>
no

[10:45:23.0000] <Ms2ger>
Well, it sure should be!

[10:45:31.0000] <Hixie_>
calling an algorithm is more like "Insert an HTML element for the token for which the element entry was created, to obtain new element"

[10:45:42.0000] <Hixie_>
this is just defining "have an element in scope"

[10:45:51.0000] <Ms2ger>
Well, it's defining it poorly

[10:45:57.0000] <Hixie_>
it's just simple english

[10:46:02.0000] <Hixie_>
i really don't understand the problem here

[10:46:14.0000] <Hixie_>
it's defining a property of elements

[10:46:19.0000] <jgraham>
I don't understand how you don't understand the problem

[10:46:29.0000] <Ms2ger>
Me neither

[10:46:57.0000] <Ms2ger>
So if only the editor understands the spec, is the spec good?

[10:47:11.0000] <jgraham>
Hixie_: The spec specifically says it's defining a property of the stack of open elements

[10:47:16.0000] <Hixie_>
everyone actually understand this, given that it's been implemented consistently by multiple people

[10:47:19.0000] <jgraham>
Not a property of the elements themselves

[10:47:31.0000] <jgraham>
I don't think this used to be brokwn in this way

[10:47:48.0000] <Hixie_>
jgraham: jgraham yeah, it's really defining a property of the stack for each element

[10:47:49.0000] <jgraham>
Otherwise I was incredibly negligent in not giving feedback

[10:48:01.0000] <Hixie_>
this part of the spec hasn't changed in months if not years

[10:48:16.0000] <Hixie_>
not in a meaningful way, anyway

[10:49:04.0000] <Ms2ger>
Has anyone implemented it since?

[10:49:08.0000] <jgraham>
Apart from the change at the weekend (which I think I have now), that slightly unbroke it, you mean?

[10:49:21.0000] <Hixie_>
"A fruit bowl is said to have a fruit /target fruit/ on top when the following algorithm terminates in a match state: 1. /target fruit/ has no fruit above it"

[10:49:38.0000] <Hixie_>
"If there is a pear that is on top of the fruit bowl, then..."

[10:49:49.0000] <Hixie_>
this is the exact same formulation

[10:49:58.0000] <jgraham>
OK, so, I think this makes sense if you imagine that the algorithm gets run for every element on the stack of open elements

[10:50:27.0000] <jgraham>
(perhaps)

[10:50:41.0000] <Hixie_>
it's jsut a definition, i wouldn't expect anyone to actually run this each time

[10:50:46.0000] <Hixie_>
i'd probably just set a bit

[10:50:53.0000] <Hixie_>
when the condition becomes true

[10:50:57.0000] <jgraham>
Ignore implementations

[10:50:58.0000] <Hixie_>
and unset it when it becomes false

[10:51:42.0000] <jgraham>
(fwiw I'm pretty sure that html5lib runs this each time. And it isn't a noticable perf. problem in non-pathological cases)

[10:51:52.0000] <jgraham>
But like I said, ignore implementations

[10:52:11.0000] <jgraham>
The way the spec is worded, it feels like you take a type of element

[10:52:13.0000] <Ms2ger>
"The stack of open elements is said to *have an element in scope* when..."

[10:52:24.0000] <jgraham>
e.g. a P element

[10:52:47.0000] <jgraham>
and run it through the algorithm, which will return whether that element is in a particular scope or not

[10:52:53.0000] <Ms2ger>
That would mean Stack::HasElementInScope(/* no arguments */)

[10:53:26.0000] <jgraham>
Ms2ger: Try a force reload

[10:53:44.0000] <Ms2ger>
Not the specific scope

[10:53:54.0000] <Ms2ger>
The plain "in scope"

[10:53:54.0000] <jgraham>
Oh

[10:53:57.0000] <Hixie_>
jgraham: the definition is applied to types ("is there any element in scope that happens to have this type") as well as specific nodes ("is this specific element in scope right now")

[10:54:10.0000] <TabAtkins>
Tangent: does anyone know what the timezone is in gavin's stats?

[10:54:13.0000] <jgraham>
Ms2ger: Yes, that's still wrong

[10:54:47.0000] <Hixie_>
hm yeah, "when it has an" should be "when it has that"

[10:55:58.0000] <jgraham>
Hixie_: But then it still doesn't make sense. You are conflating E and type(E)

[10:56:27.0000] <Ms2ger>
Maybe ... *have an element with _local name_ /local name/ and _namespace_ /namespace/ in scope* when...

[10:56:34.0000] <Hixie_>
jgraham: where does type(E) come in?

[10:56:41.0000] <Ms2ger>
/x/ => var, _x_ => a

[10:56:44.0000] <jgraham>
Hixie_: "has a P element in scope"

[10:57:10.0000] <jgraham>
The algorithm works with specific elements

[10:57:14.0000] <Hixie_>
Ms2ger: it's defining the property for each node in the stack, it's not an algorithm you run to get a boolean result for the stack.

[10:57:40.0000] <Hixie_>
go back to my fruit bowl example. why is that one fine but the spec not?

[10:57:48.0000] <jgraham>
Hixie_: The fundamental problem is tht the way the spec is worded implies it's an algorithm you invoke at specific times

[10:57:52.0000] <Ms2ger>
Because the spec isn't a fruit bowl

[10:58:31.0000] <jgraham>
Hixie_: I don't care about fruit bowl examples. The spec is confusing irrespective of whether some other instance of the same construction is (I didn't even read the example)

[10:58:31.0000] <Hixie_>
jgraham: if you're reading implications, then you're misreading the spec. read what it says, not between the lines.

[10:58:53.0000] <Hixie_>
ok if you're not even willing to consider the examples i'm giving, this conversation isn't being very productive.

[10:59:19.0000] <Hixie_>
the fruit bowl example would help because it would help me understand what the difference is between an obviously fine construction, and the one that's confusing you.

[10:59:37.0000] <jgraham>
Hixie_: Unless you are going to give the same examples to everyone that reads the spec, I don't understand their value in the face of the fact that both Ms2ger and I find the spec confusing

[11:00:16.0000] <Ms2ger>
Hixie_, okay, let me compare to your fruit bowl

[11:00:32.0000] <Ms2ger>
"A fruit bowl is said to have a fruit /target fruit/ on top when the following algorithm terminates in a match state: ..."

[11:00:45.0000] <Ms2ger>
"The stack of open elements is said to have an element in scope when..."

[11:00:54.0000] <Hixie_>
jgraham: the value is that that construction is unambiguously ok, but the spec is apparently not, yet i think they're identical. so if you can explain to me why they're not, it helps me understand the problem with the spec.

[11:01:07.0000] <Ms2ger>
The obvious difference: the fruit bowl one takes an algorithm, the stack one doesn't

[11:01:25.0000] <jgraham>
Hixie_: I have now read it and don't think your fruit bowl example is very clear either fwiw

[11:01:30.0000] <Hixie_>
Ms2ger: the fruit bowl one is about the specific scope definition

[11:01:38.0000] <Hixie_>
jgraham: oh

[11:02:05.0000] <Hixie_>
jgraham: then i am even more confused :-)

[11:02:19.0000] <Ms2ger>
But you don't jump from the use in the parser straight to the specific scope

[11:02:48.0000] <Ms2ger>
You jump from the parser to the #has-an-element-in-scope then to #has-an-element-in-the-specific-scope

[11:03:14.0000] <Ms2ger>
And it's not clear that the 'button' in the parser needs to end up as the /target node/ in #has-an-element-in-the-specific-scope

[11:03:16.0000] <jgraham>
You are invoking an algorithm (that is itself a bit magic, but let's not worry about that) in a very roundabout way that makes it unclear what the arguments to the algorithm are

[11:03:20.0000] <TabAtkins>
annevk: Can you add an "adopt" hook to the Promises spec?  Also, is the correct way to invoke one of the static Promise methods (in the case I'm writing right now, Promise.every()), just to invoke it as code or something?

[11:04:00.0000] <Hixie_>
Ms2ger: the analogous fruit bowl one would be "the fruit bowl is said to have a fruit on top when that fruit is specifically on top of the following fruit types: ..." where "a fruit is specifically on top" is similar to the earlier example but the algorithm is longer and checks for those fruit types.

[11:04:10.0000] <zcorpan>
TabAtkins: is http://dev.w3.org/csswg/css-position/#position-root a placeholder for this?

[11:04:11.0000] <Ms2ger>
(Or what "If /node/ is the target node, terminate in a match state." means when you fill in /target node/==|button|)

[11:04:17.0000] <Hixie_>
Ms2ger: woah, the "button" in the parser _doesn't_ end up being the /target node/.

[11:04:23.0000] <Hixie_>
Ms2ger: what makes you think it does?

[11:04:43.0000] <Ms2ger>
It's the only thing I *can* fill in!

[11:04:43.0000] <Hixie_>
jgraham: there's no algorithm invokation, it's a definition.

[11:05:02.0000] <Ms2ger>
What else would it be?

[11:05:06.0000] <jgraham>
Hixie_: There is an algorithm. Conceptually it must be invoked

[11:05:07.0000] <TabAtkins>
zcorpan: Yes, and see http://www.xanthir.com/blog/b48H0 for a more fleshed out early early draft of it.

[11:06:05.0000] <jgraham>
If you just wrote the spec to invoke the actual algorithm rather than having invoked behind the scenes at some point when you read the definition, everything would be much clearer

[11:06:13.0000] <Hixie_>
Ms2ger: every node ever created in the history of the world is passed to the definition, to see if it is in scope or not. this makes every node have a true or false state, which is all you are later checking.

[11:06:17.0000] <zcorpan>
TabAtkins: thx

[11:06:56.0000] <jgraham>
Hixie_: Where does the spec say that?

[11:06:56.0000] <Ms2ger>
Huh

[11:07:09.0000] <Ms2ger>
So what is "the target node"?

[11:07:30.0000] <Hixie_>
jgraham: certainly you could phrase the spec that way, but i would rather phrase the spec in a way that just asks if there's a node that fits the criteria. i'm happy to consider better ways to do that, though, since apparently (despite interop...) the spec doesn't do it well enough

[11:08:05.0000] <jgraham>
Why would you rather do that?

[11:08:37.0000] <Hixie_>
jgraham: because generally speaking it makes the text easier to reason about.

[11:08:44.0000] <Hixie_>
declarative > imperative, where possible.

[11:08:57.0000] <jgraham>
This conversation isn't supporting that point of view

[11:09:00.0000] <Hixie_>
Ms2ger: it's the "x" in "an x has property y if..."

[11:09:27.0000] <Hixie_>
Ms2ger: it's the mathematical equivalent of the indefinite article

[11:09:27.0000] <Ms2ger>
Let's step back

[11:09:43.0000] <Ms2ger>
I was looking at the following text in the parser:

[11:09:45.0000] <Ms2ger>
"If the stack of open elements has a button element in scope, then run these substeps:..."

[11:09:56.0000] <Ms2ger>
How am I supposed to interpret that

[11:09:57.0000] <Ms2ger>
?

[11:10:30.0000] <Hixie_>
Ms2ger: is there a button element that has the property "currently is in scope"?

[11:10:40.0000] <Hixie_>
Ms2ger: or to put it another way:

[11:11:05.0000] <Hixie_>
Ms2ger: is there an element X, which has X.type "button" and X.inScope "true"?

[11:11:12.0000] <jgraham>
I have no idea how you could get to that interpretation from the spec as written

[11:11:31.0000] <Hixie_>
i have no idea how you could interpret it as an imperative algorithm invocation

[11:11:31.0000] <jgraham>
There is nothing to suggest that elements have a property of being in scope

[11:11:45.0000] <Hixie_>
"The stack of open elements is said to have an element in scope when"

[11:11:49.0000] <Ms2ger>
That seems a very unintuitive interpretation

[11:12:04.0000] <jgraham>
Or that a question about the stack of open elements is supposed to be a quaestion about the set of all elements

[11:12:08.0000] <jgraham>
*question

[11:12:30.0000] <Ms2ger>
Now if it had said "If the stack of open elements _has an element in scope_ that is a button element"

[11:12:46.0000] <Ms2ger>
Is that what you mean?

[11:12:55.0000] <jgraham>
/me has to go now

[11:13:00.0000] <Hixie_>
I honestly truly don't see why this is hard. The spec defines "The stack of open elements is said to have an element in scope when" and then it asks whether "the stack of open elements has an element in scope" (specifically, whether it has one that is also a button element)

[11:13:17.0000] <Ms2ger>
It's not obvious that that's what it asks

[11:13:23.0000] <Hixie_>
what else could it ask?

[11:13:45.0000] <Hixie_>
i mean, this is just regular english

[11:13:51.0000] <Ms2ger>
Does the stack have the property "has a button element in scope"

[11:14:07.0000] <Ms2ger>
And then the issue is that nothing defines what that means

[11:14:08.0000] <Hixie_>
"a kid is wearing a sweater when..." "is there a red kid wearing a sweater?"

[11:14:40.0000] <Ms2ger>
Whet you're saying now is "is there a...", "does there exists a..."

[11:14:46.0000] <Ms2ger>
But the spec doesn't say that

[11:14:53.0000] <Ms2ger>
*exist

[11:15:04.0000] <Hixie_>
"If the stack of open elements has a button element in scope" is a "Does there exist a" question.

[11:15:28.0000] <Ms2ger>
I don't read it that way

[11:15:30.0000] <Hixie_>
(or rather, "a classroom has a kid wearing a sweater when"... "if the classroom has a red kid wearing as sweater, then..."

[11:15:33.0000] <Hixie_>
)

[11:15:39.0000] <Hixie_>
s/as/a/

[11:15:47.0000] <Hixie_>
what other way is there to read it?

[11:15:51.0000] <Hixie_>
i'm really baffled by this

[11:15:58.0000] <Ms2ger>
'Does the stack have the property "has a button element in scope"?'

[11:16:15.0000] <Hixie_>
it has the property "has an element in scope", which is even hyperlinked from the sentence you're asking about

[11:16:49.0000] <Ms2ger>
So the hyperlink goes to the definition of

[11:17:01.0000] <Ms2ger>
"Does the stack have a/any element in scope"

[11:17:15.0000] <Hixie_>
a/any ?

[11:17:29.0000] <Ms2ger>
"Does the stack have a element in scope" or "Does the stack have any element in scope"

[11:18:13.0000] <Hixie_>
where do you get "does the stack have any element in scope"?

[11:18:31.0000] <Ms2ger>
That's just plain English

[11:18:49.0000] <Ms2ger>
"The stack of open elements is said to have an element in scope when..."

[11:19:11.0000] <Ms2ger>
That defines the answer to "Does the stack have any element in scope?"

[11:19:21.0000] <Hixie_>
hmm, ok, i buy that

[11:19:23.0000] <Hixie_>
one sec

[11:20:46.0000] <Hixie_>
ok, renamed it to "have a particular element in scope"

[11:21:10.0000] <Hixie_>
does that solve the "any" issue?

[11:21:27.0000] <Ms2ger>
/me thinks

[11:23:00.0000] <Ms2ger>
Yes, I think so

[11:23:01.0000] <Ms2ger>
However

[11:23:39.0000] <Ms2ger>
That still means you define it for one particular element in the history of the world

[11:24:24.0000] <Ms2ger>
And that's IMO quite a leap from the way you link to the definition in "If the stack of open elements has a button element in scope"

[11:24:59.0000] <Hixie_>
isn't that just what a definition always is?

[11:25:11.0000] <Hixie_>
you define some property of an abstract thing

[11:25:22.0000] <Hixie_>
then you can refer to that property for all concrete things

[11:25:54.0000] <Ms2ger>
I guess the main issue is this

[11:26:20.0000] <Ms2ger>
When I end up here, I want to follow imperative steps

[11:26:48.0000] <Ms2ger>
And I've been doing that repeatedly since I started reading

[11:27:20.0000] <Hixie_>
what's the imperative step for "the current node is a MathML text integration point"?

[11:27:25.0000] <Ms2ger>
But suddenly, without a warning, I end up with a declarative definition

[11:27:32.0000] <Hixie_>
or "is an element in the HTML namespace"?

[11:27:46.0000] <Hixie_>
or "the current node"?

[11:27:48.0000] <Ms2ger>
1. Get the namespace

[11:27:59.0000] <Ms2ger>
2. If the namespace if the HTML namespace, return true

[11:28:04.0000] <Hixie_>
where's that in the spec?

[11:28:04.0000] <Ms2ger>
3. Otherwise, return false

[11:28:14.0000] <Hixie_>
all the spec does is define the namespace property

[11:28:30.0000] <Ms2ger>
It's a straightforward translation, though

[11:28:40.0000] <Ms2ger>
I find the case here less straightforward

[11:28:52.0000] <Hixie_>
how about "If the parser's Document has a style sheet that is blocking scripts" ?

[11:29:14.0000] <Hixie_>
or "if there is an adjusted current node and it is not an element in the HTML namespace and the next seven characters are a case-sensitive match for the string "[CDATA["" ?

[11:29:20.0000] <Hixie_>
the parser is full of these property checks

[11:29:26.0000] <Hixie_>
in fact i don't really see how else you could do it

[11:29:32.0000] <Hixie_>
programming is full of property checks

[11:29:41.0000] <Ms2ger>
I agree there are property checks

[11:30:03.0000] <Hixie_>
how would you phrase "If the stack of open elements does not have a body element in scope, this is a parse error; ignore the token." if it wasn't a property check?

[11:30:21.0000] <Ms2ger>
Loop over the stack, until you find a body element

[11:31:03.0000] <Hixie_>
that would like double the length of this part of the spec

[11:31:11.0000] <Hixie_>
and make it harder to reason about to boot

[11:31:35.0000] <Ms2ger>
You don't have to write that out every time

[11:32:11.0000] <Hixie_>
what exact text would you replace the above with?

[11:33:19.0000] <Ms2ger>
Either you keep the definition with the particular node for "has a particular element in scope", and then you write:

[11:33:57.0000] <Ms2ger>
"If the stack of open elements does not have a particular element in scope that is a body element, this is..."

[11:34:13.0000] <Ms2ger>
Or you keep that text, and define...

[11:35:37.0000] <Ms2ger>
The stack of open elements has an element of kind (or whatever) /x/ in scope when... loop... if /node/ is of kind /x/: match

[11:35:44.0000] <Hixie_>
i don't understand why "If the stack of open elements does not have a particular element in scope" is ok for you, but "...does not have a button element in scope" is not, given the way english works.

[11:36:13.0000] <Ms2ger>
They're both fine, but they don't connect

[11:37:06.0000] <Hixie_>
"The player has a fruit if their inventory contains a fruit" "Does the player have a pear?" connects, does it not?

[11:37:10.0000] <Hixie_>
why is this different?

[11:37:35.0000] <Ms2ger>
Doesn't connect for me

[11:37:46.0000] <Hixie_>
...

[11:37:50.0000] <Hixie_>
really?

[11:37:57.0000] <Ms2ger>
If you define "The player has a fruit if their inventory contains a fruit", I can only answer "Does the player have any fruit"

[11:38:04.0000] <Hixie_>
i gotta go to lunch. bbiab.

[11:38:17.0000] <Ms2ger>
And I'm going to head off for the night, ttyl

[11:39:11.0000] <annevk>
Hixie_: it's kinda weird that "does not have a body element in scope" links to "have an element in scope" whose types don't list the body element

[11:39:36.0000] <annevk>
might be xref issue I suppose

[11:40:21.0000] <Ms2ger>
Maybe "If the stack of open elements does not have >>any<< body element in scope, this is..." might be clearer already

[11:40:33.0000] <Ms2ger>
But my brain is too fried to continue right now :)

[11:46:42.0000] <annevk>
"a" is the same as "any" really

[11:46:46.0000] <annevk>
in this context

[12:09:53.0000] <TabAtkins>
What's the idiomatic way to deal with exceptions in a spec?  Specifically, I need to take a 'font' value and turn it into a list of matching Font objects.  If there's no matching objects, I want to throw an error.  (Actually, reject a promise, but I'll reject it with an error.)  What's the right thing to do with something like this?

[12:13:47.0000] <TabAtkins>
(also, lunch now - replies will be responded to in an hour or so)

[12:19:21.0000] <annevk>
TabAtkins: prolly a plain JavaScript TypeError or RangeError

[12:20:32.0000] <annevk>
TabAtkins: doesn't seem like there's a nice semantic mapping though between 'font' property values (assuming that's what you meant) and Font objects (representing individual fonts I assume once again)

[13:48:46.0000] <TabAtkins>
annevk: Yeah, there is - you just do the font resolution algo that Fonts defines, for choosing which faces to use.

[13:48:52.0000] <TabAtkins>
Each face is a Font object.

[13:49:02.0000] <TabAtkins>
Hm, so I should probably name the interface FontFace.

[13:49:34.0000] <TabAtkins>
annevk: I don't do anything more special than say "reject with a TypeError"?

[13:49:44.0000] <annevk>
That seems confusing with @font-face.

[13:50:03.0000] <annevk>
TabAtkins: yeah, if it's actually an error condition that seems fine. The browser can add a nice message...

[13:50:30.0000] <TabAtkins>
annevk: @font-face creates implicit FontFace objects, prepopulating the document.fonts set.

[13:50:36.0000] <annevk>
TabAtkins: maybe say a JavaScript TypeError exception given that the rest of the language is prolly based around IDL..

[13:50:37.0000] <TabAtkins>
annevk: Okay, cool.

[13:51:50.0000] <annevk>
TabAtkins: I see. As for the objects. It might help thinking about what we'd expose if we went lower on the stack.

[13:52:06.0000] <annevk>
TabAtkins: as some day we might want to go there and it'd be great if things would still fit together if we did.

[13:52:13.0000] <Ms2ger>
https://twitter.com/glazou/status/374998161473155072

[13:52:44.0000] <TabAtkins>
annevk: My idea right now is to have a FontSet attached to documents and workers.  @font-face rules pre-populate the document's set with FontFace objects.  You can manually construct FontFaces with a descriptor dict and either a url or a TypedArray of font data, then add them to the set.

[13:52:48.0000] <annevk>
TabAtkins: that's the idea behind http://extensiblewebmanifesto.org/ anyway. Running the design by Yehuda and public-script-coord will prolly help us get there.

[13:52:57.0000] <jgraham>
Reasons I hate merges: http://git-scm.com/blog/2010/03/02/undoing-merges.html

[13:53:00.0000] <TabAtkins>
FontFaces would be transferrable, so you can hand them to a Worker to let it use fonts.

[13:53:16.0000] <TabAtkins>
annevk: Yeah, I'm doing first draft in spec, then plan to socialize it on public-script-coord.

[13:53:20.0000] <jgraham>
If you git revert a merge then redoing the merge doesn't work the way you expect

[13:53:28.0000] <Ms2ger>
jgraham, but why would you ever do that?!

[13:54:19.0000] <jgraham>
So you either need to edit history or remember that branch is special when you re-merge

[13:54:25.0000] <TabAtkins>
annevk: I signed that webpage, so yeah, I know the principles.  ^_^

[13:54:36.0000] <Ms2ger>
Mm, signing web pages

[13:54:50.0000] <jgraham>
Ms2ger: In this case because https://github.com/w3c/web-platform-tests/pull/316#issuecomment-23740848

[13:55:26.0000] <Ms2ger>
/me raises one eyebrow

[13:55:28.0000] <annevk>
TabAtkins: aight, sounds good.

[13:55:44.0000] <annevk>
TabAtkins: btw, why is code unit order not sensible for string ordering? I didn't quite get that thread...

[13:56:19.0000] <TabAtkins>
code unit order would be unambiguous, but it's not a proper "unicode ordering".

[13:56:45.0000] <jgraham>
I thought it only had to be well-defined, not useful

[13:56:55.0000] <TabAtkins>
Yeah, I suppose well-defined is enough here.

[13:57:11.0000] <TabAtkins>
And I can produce a well-defined-but-not-that-useful ordering for FontFace objects too.

[13:57:35.0000] <TabAtkins>
Do we have something on the platform that says that everything is just NFC or something?

[13:58:52.0000] <jgraham>
Is that even true?

[13:59:11.0000] <TabAtkins>
Oh man, it'll be nice when bikeshed integrates shepherd's IDL parsing, so I can avoid marking up all these IDL things as definitions and links.

[13:59:15.0000] <TabAtkins>
jgraham: Shrug.

[13:59:19.0000] <jamesr_`>
where are tests for http://encoding.spec.whatwg.org/ supposed to go?

[13:59:28.0000] <TabAtkins>
I think JS does NFC for its strings.

[14:00:03.0000] <jamesr_`>
TabAtkins: for sort?

[14:00:20.0000] <annevk>
TabAtkins: Unicode ordering is overrated imo. Also, it seems better than undefined / random.

[14:00:23.0000] <TabAtkins>
jamesr_`: For what? That question doesn't have enough context.

[14:00:28.0000] <TabAtkins>
annevk: Yeah, better than undefined.

[14:01:00.0000] <annevk>
TabAtkins: "JS does NFC for its strings" doesn't have enough context either ;-)

[14:01:20.0000] <annevk>
jamesr_`: I suggest https://github.com/w3c/web-platform-tests

[14:01:31.0000] <annevk>
jamesr_`: since all W3C specs rely on it these days

[14:01:32.0000] <TabAtkins>
I'm thinking I might be wrong, but I thought that JS mandated its strings to be in NFC.

[14:01:40.0000] <annevk>
TabAtkins: nah doesn't

[14:01:44.0000] <TabAtkins>
Ah, kk then.

[14:01:46.0000] <annevk>
TabAtkins: JS has 16-bit code unit strings

[14:01:52.0000] <TabAtkins>
Well, yeah, but still.

[14:02:01.0000] <TabAtkins>
And CSS doesn't mandate a normalization form either. :/

[14:02:10.0000] <annevk>
Pretty sure it doesn't do conformance like HTML does :-)

[14:02:12.0000] <TabAtkins>
Which means that technically "code unit" is still ambiguous.

[14:02:14.0000] <jamesr_`>
JS has 16-bit unsigned integers

[14:02:21.0000] <jamesr_`>
calling them 'code unit' is a stretch

[14:02:44.0000] <zewt>
makes sense to me, distinguishing from codepoints

[14:02:52.0000] <jamesr_`>
there's basically nothing in the language that requires or assumes the contents of JS strings have anything to do with unicode

[14:03:07.0000] <annevk>
jamesr_`: that's not true

[14:03:14.0000] <TabAtkins>
There's tons that *assumes*.

[14:03:16.0000] <annevk>
jamesr_`: and not that code unit != code point

[14:03:30.0000] <TabAtkins>
Anything that interacts with the string as a string assumes it's in a bastardized utf-16.

[14:03:39.0000] <jamesr_`>
UCS-2

[14:03:56.0000] <TabAtkins>
No, UCS-2 can't encode anything over 16-bits.  It's bastardized utf-16.

[14:04:04.0000] <TabAtkins>
With a UCS-2-like structure.

[14:04:20.0000] <annevk>
serialized utf-16 with 16-bit indexing

[14:04:56.0000] <jamesr_`>
except that it isn't necessarily valid utf-16

[14:05:01.0000] <TabAtkins>
Right.

[14:05:11.0000] <TabAtkins>
So there's no *requirement*.  But there's plenty of assumption.

[14:05:15.0000] <jamesr_`>
you can have arbitrary bits in each element and pretty much everything works

[14:05:16.0000] <annevk>
16-bit code units is the term for that though...

[14:05:29.0000] <TabAtkins>
Anyway, back to writing specs.

[14:05:38.0000] <TabAtkins>
Oh yeah, annevk, while you're here - adopt hook?

[14:05:43.0000] <annevk>
or code points up to U+FFFD with special meaning for valid surrogate pairs

[14:05:59.0000] <annevk>
TabAtkins: file a bug I guess?

[14:06:02.0000] <TabAtkins>
annevk: kk

[14:07:01.0000] <TabAtkins>
And how best to say "Promise.every(some-spec-defined-list-of-promises)"?

[14:08:42.0000] <annevk>
TabAtkins: I guess for that you want to wait until we've re-defined Promise.every() and then simply reference its internal algorithm (that cannot be replaced).

[14:09:03.0000] <TabAtkins>
annevk: Cool.  I'll just hand-wave for now with an issue about it.

[14:12:06.0000] <jsbell>
jamesr_`: Might be a bit crufty now, but my JS prototype for the Encoding API has W3C-style tests in https://code.google.com/p/stringencoding/source/browse/tests.js

[14:13:04.0000] <jsbell>
i.e. someone could clean up and submit those

[14:22:05.0000] <jgraham>
jsbell: Submit them now and we can track the cleanup in critic

[14:22:41.0000] <jgraham>
(create a branch in the W3C repo rather than using your personal GH and we can even have multiple contributers)

[14:43:29.0000] <annevk>
jgraham: I guess I should look into doing that for my URL tests too at some point?

[14:43:54.0000] <annevk>
I wonder what the licensing deal is these days

[14:44:09.0000] <jsbell>
jgraham: I need to be a member of the org presumably?

[14:49:53.0000] <jsbell>
/me grabs "jsbell" at github, yay for multiple personalities

[14:53:23.0000] <TabAtkins>
Suggestions on an interface name for "a set of fonts usable in a given context"?

[14:53:35.0000] <TabAtkins>
"FontFaceSet" might be sufficient.

[14:58:43.0000] <zcorpan>
code unit order? i guess i need to say that for getComputedStyle huh

[14:59:33.0000] <TabAtkins>
zcorpan: Yeah.

[14:59:59.0000] <TabAtkins>
zcorpan: But we still need to specify a normalization form to do that.

[15:00:32.0000] <zcorpan>
why?

[15:01:58.0000] <TabAtkins>
Because given var-Á, whether it's encoded as A followed by combining acute accent or as A with acute accent changes what code units it's using.

[15:02:08.0000] <TabAtkins>
And whether it sorts before or after var-B.

[15:03:04.0000] <SimonSapin>
TabAtkins: can’t we just ignore that and deal with code points?

[15:03:06.0000] <zcorpan>
do css parser normalize for e.g. selectors?

[15:03:15.0000] <TabAtkins>
Not specified.

[15:03:21.0000] <TabAtkins>
Unfortunately.

[15:03:24.0000] <zcorpan>
what about impls?

[15:03:36.0000] <TabAtkins>
SimonSapin: Code points gives you the same problem.

[15:03:44.0000] <TabAtkins>
This is a normalization issue, not an encoding issue.

[15:03:49.0000] <TabAtkins>
zcorpan: Dunno.

[15:03:55.0000] <zcorpan>
/me checks

[15:04:35.0000] <TabAtkins>
SimonSapin: The two characters A + combining acute accent and the single character Á are the same grapheme cluster, but they're different sets of code points and code units.

[15:05:28.0000] <SimonSapin>
TabAtkins: I understand that. But I think CSS can get away with considering them different

[15:05:39.0000] <zcorpan>
huh. blink uppercases the å in http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2505

[15:06:01.0000] <zcorpan>
i guess that's in .nodeName rather than the parser

[15:06:11.0000] <SimonSapin>
i.e. ignore abstract characters and normalization, only compare code points

[15:06:56.0000] <TabAtkins>
SimonSapin: Hm, I suppose it could.  Just treat CSS and JS as black-box sources of codepoint lists.

[15:09:24.0000] <TabAtkins>
In that case it's not actually an issue.

[15:11:01.0000] <zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2507

[15:11:25.0000] <zcorpan>
at least gecko and blink don't normalize

[15:13:21.0000] <zcorpan>
css could do what js does and say "source text is assumed to be NFC without checking that it is"

[15:15:18.0000] <TabAtkins>
I wish I could go back in time and make the unicode consortium exist earlier, and only produce utf-8 as a valid encoding.

[15:15:45.0000] <Hixie_>
rniwa: i don't understand why, in your proposal, A.js executes immediately before B.js which executes immediately C.js in use case U, but in use case S, A.js executes asap when B is needed, and B.js only executes when it can after A.js is run.

[15:15:51.0000] <TabAtkins>
Also, not do the weird thing where there are 17 planes, so you need a 21st bit to encode only that last plane.

[15:16:17.0000] <TabAtkins>
I mean, 16 or 32 or gtfo.

[15:17:31.0000] <rniwa>
Hixie_: sorry, there is a typo there :(

[15:19:33.0000] <Hixie_>
rniwa: i don't really understand how your proposal differs from the one in my last e-mail, other than renamign "whenneeded" to "prefetch" and dropping the =jit feature.

[15:19:55.0000] <rniwa>
Hixie_: so my "prefix" behaves like whenneeded=jit

[15:19:59.0000] <rniwa>
prefetch*

[15:20:16.0000] <rniwa>
Hixie_: or rather a hybrid of whenneeded=true & hit

[15:20:22.0000] <rniwa>
Hixie_: jit*

[15:20:44.0000] <Hixie_>
they seem rather different... one executes asap, the other as late as possible. how can you do a hybrid without losing one or the other?

[15:21:27.0000] <rniwa>
Hixie_: i'm dropping the ability to execute asap since that can be done by async=true if i'm not mistaken

[15:22:54.0000] <Hixie_>
rniwa: how do you do that while still not executing asap if you're not needed?

[15:24:04.0000] <rniwa>
Hixie_: which use case is that?

[15:25:39.0000] <Hixie_>
all of them except U, basically

[15:26:08.0000] <Hixie_>
you don't know how long scripts will take to run, so you don't usually want to wait if you know you need to run it

[15:26:27.0000] <Hixie_>
even if the relevant dependency is itself still loading

[15:27:00.0000] <zewt>
"U" is the only use case for "jit", iirc

[15:27:07.0000] <Hixie_>
right

[15:27:24.0000] <zewt>
oops, never finished my last mail to that thread

[15:27:37.0000] <rniwa>
Hixie_: why doesn't async: true work in that case?

[15:28:56.0000] <rniwa>
Hixie_: say you have a script a.js and another script b.js that depends on a.js.  then all you need is <script src="a.js" async></script><script src="b.js" needs="a.js" async></script>

[15:29:01.0000] <Hixie_>
rniwa: take use case S. two scripts, second depends on the first. at time t=1, you have downloaded A.js, but still don't have B.js. User indicates he needs B.js's services, so the script marks B.js as needed.

[15:29:23.0000] <Hixie_>
rniwa: now how do you ensure that A.js doesn't run until B.js is needed, but does run before B.js is downloaded, since B.js is being slow?

[15:29:40.0000] <gavin>
TabAtkins: should be pacific time?

[15:30:09.0000] <Hixie_>
rniwa: if you're parsing <script src="a.js" async></script>ZZZ<script src="b.js" needs="a.js" async></script> and while parsing "ZZZ" you get a.js down and are ready to run it, how do you know _not_ to run it?

[15:30:18.0000] <rniwa>
<script src="A.js" prefetch></script><script src="B.js" needs="A.js" prefetch></script>

[15:30:22.0000] <TabAtkins>
gavin: Okay.  Mind indicating that somewhere on the page?

[15:30:31.0000] <Hixie_>
rniwa: why won't that wait until B.js is ready to run?

[15:30:54.0000] <rniwa>
Hixie_: it will.

[15:30:56.0000] <gavin>
TabAtkins: I will try to remember. might wokr better if you email me :)

[15:31:09.0000] <rniwa>
Hixie_: i don't understand. if B.js is needed, then we need to have downloaded both A.js and B.js

[15:31:09.0000] <Hixie_>
rniwa: i don't want it to

[15:31:21.0000] <Hixie_>
rniwa: B.js might still be downloading.

[15:31:32.0000] <Hixie_>
rniwa: but if B is needed, then you generally want to execute A.js

[15:31:52.0000] <TabAtkins>
gavin: kk

[15:32:27.0000] <TabAtkins>
gavin: Dunno your email address.

[15:33:06.0000] <rniwa>
Hixie_: so are you saying that in your example for CMS plugin 1, when you call B.execute();

[15:33:12.0000] <rniwa>
Hixie_: B.js might be still downloading?

[15:33:16.0000] <Hixie_>
right

[15:34:17.0000] <rniwa>
I see. Thanks for the clarification.

[15:35:45.0000] <rniwa>
Hixie_: I have somewhat similar use case for U then.

[15:36:06.0000] <rniwa>
Hixie_: which is that sometimes you want to execute the script immediately only if it's available in the cache

[15:36:34.0000] <rniwa>
if not, then you want to delay it until more important assets such as images are loaded

[15:36:57.0000] <gavin>
TabAtkins: it's at the bottom of http://gavinsharp.com/

[15:37:07.0000] <zewt>
FWIW, my instinct for U was "it's not the job of a dependancy management system", and should either be added and discussed separately--it seems to bloat this discussion a bit

[15:37:44.0000] <Hixie_>
rniwa: if you have a new use case, please mail the list :-)

[15:38:52.0000] <rniwa>
Hixie_: can't U be addressed by looking for load event on each script?

[15:38:56.0000] <rniwa>
Hixie_: or maybe by exposing readyState?

[15:39:05.0000] <rniwa>
Hixie_: i'm inclined to ditch the use case U for those alternatives...

[15:39:43.0000] <rniwa>
but I guess it'll be nice to address that declaratively as well.

[15:40:18.0000] <Hixie_>
well like i said earlier, if it's something we don't want to address, that's a different argument

[16:36:06.0000] <MikeSmith>
heads up: starting at 18:30 UTC, the W3C Systems Team

[16:36:06.0000] <MikeSmith>
will upgrade Bugzilla to the latest version 4.4. This process is

[16:36:06.0000] <MikeSmith>
expected to take less than an hour. While the upgrade is underway, it

[16:36:13.0000] <MikeSmith>
will not be possible to view or update bugs."

[16:36:25.0000] <MikeSmith>
Thursday, 5 September

[16:44:13.0000] <gsnedders>
jgraham: Yeah, indeed. GitHub sucks. We need shared work branches (guess we could just use some on the w3c org repo).

[16:44:22.0000] <gsnedders>
jgraham: (Though I couldn't push to them, AFAIK)

[16:46:06.0000] <MikeSmith>
what's a shared work branch?

[16:46:42.0000] <MikeSmith>
or what's different about it than a normal remote branch?

[16:47:37.0000] <gsnedders>
MikeSmith: Well, multiple committers


2013-09-04
[17:01:16.0000] <TabAtkins>
Do I have to write something special to say that an IDL method takes a TypedArray or a TypedArrayView, or is that implicit in saying TypedArray?

[17:01:52.0000] <TabAtkins>
Or maybe there's a typedef living somewhere that means that.

[17:02:03.0000] <heycam>
Uint32Array is a "typed array view" interface

[17:05:41.0000] <TabAtkins>
heycam: Right.  But there's no reason for a method taking a TypedArray to not take a Uint32Array, right?  So is there an easy way to just say "any of those typed array things"?

[17:06:03.0000] <heycam>
what is "TypedArray"?

[17:06:25.0000] <heycam>
the same as "any of those typed array things"?

[17:06:34.0000] <TabAtkins>
sorry, ArrayBuffer

[17:06:37.0000] <heycam>
ah

[17:06:40.0000] <TabAtkins>
Dunno why my fingers kept typing TypedArray.

[17:06:53.0000] <zewt>
tab: that API makes me sad, such a mess

[17:07:09.0000] <Hixie_>
what isn't

[17:07:26.0000] <zewt>
an unexcusable mess, as far as the distinction goes

[17:07:53.0000] <heycam>
TabAtkins, I don't think there's an existing typedef for "an untyped ArrayBuffer or a specific typed array type"

[17:07:55.0000] <heycam>
if that's what you're after

[17:08:06.0000] <TabAtkins>
Yeah, that's what I'm after.

[17:08:26.0000] <TabAtkins>
I guess someone needs to do a "typedef BinaryData (ArrayBuffer or ...);" somewhere.

[17:09:04.0000] <TabAtkins>
Because, again, there's definitely no reason that something taking an ArrayBuffer shouldn't be able to accept a JS Struct, once they finish speccing that stuff.

[17:09:40.0000] <TabAtkins>
Frex, you could set up a WOFF file as a somewhat-complex JS binary-data Struct, and you should be able to pass that directly to the FontFace constructor I'm writing.

[17:10:11.0000] <zewt>
all of the views should have just been subclasses of ArrayBuffer ... iirc, the only thing preventing doing that now is some difference in how slice() works, or something like that

[17:11:18.0000] <TabAtkins>
zewt: You mean that .slice() works different on an ArrayBuffer versus a view?

[17:13:36.0000] <TabAtkins>
.slice() doesn't seem to be defined on ArrayBufferViews at all - they have .subarray() instead, which is different (a sliced view, rather than a slice of the data).

[17:22:00.0000] <MikeSmith>
earthquake in tokyo just now

[17:27:51.0000] <zewt>
great, now gmail is intentionally ignoring what I tell it to search for too

[17:28:29.0000] <zewt>
apparently all search engines from now on will treat the user like an imbecile, and assume search queries are just vague suggestions

[17:31:01.0000] <TabAtkins>
zewt: If you saw the average search query...

[17:31:30.0000] <zewt>
how about: don't treat me like an idiot (and cripple my tools) because other people are idiots

[17:31:34.0000] <zewt>
</rant>

[17:33:32.0000] <zewt>
oh, i think i remember what I was thinking about

[17:34:07.0000] <zewt>
new UInt8Array(buffer) creates a copy, where it should have just created a view over the buffer

[17:36:09.0000] <zewt>
and new UInt8Array(buffer, offset, length) does create a view--which alongside the above, is confusing as hell

[17:36:29.0000] <zewt>
but the mantra of web apis: oh well, too late

[17:37:28.0000] <zewt>
(not entirely sure that's what I was thinking about, but no real point in digging around to find it)

[17:40:50.0000] <zewt>
oh, lovely gmail bug

[17:41:37.0000] <zewt>
i see an empty editing reply in a thread I'm reading; I discard it (assuming it was a temporary reply, which I often create before merging replies); then I go "hold on", hit undo discard, and surprise: there was a whole reply in there

[17:41:50.0000] <TabAtkins>
zewt: Aw jeez, that's a really dumb behavior.

[17:41:54.0000] <TabAtkins>
Like, crazy stupid.

[17:42:11.0000] <zewt>
the arraybuffer thing or the gmail thing? (heh)

[17:42:15.0000] <zewt>
(answer: yes)

[17:42:17.0000] <TabAtkins>
The arraybuffer thing.

[17:44:57.0000] <TabAtkins>
Am I missing something, or is http://dom.spec.whatwg.org/#error-names-0 missing TypeError and RangeError?

[17:49:23.0000] <zewt>
two simple changes would have simplified typed arrays to a stupid degree: get rid of ArrayBuffer entirely (return Uint8Array from APIs, don't have a typeless class at all) and fix the ctor problem (to make it easy to cast Uint8Array to whatever you need)

[17:49:51.0000] <zewt>
i think i suggested that and the response was something like "some Java API did that and it caused performance problems so it's a bad idea" o_O

[17:51:47.0000] <TabAtkins>
That was indeed the response.  I didn't understand it well enough to really figure out what the issue was.

[17:52:32.0000] <zewt>
java and javascript have so little in common, all I can say is o_O

[17:52:35.0000] <TabAtkins>
Or no, that was about endianness.

[17:52:50.0000] <zewt>
(wish I could remember where that discussion was, if only to verify my recollection, but I have no idea)

[17:52:51.0000] <TabAtkins>
It wasn't a syntax issue, so Java vs Javascript is fairly irrelevant to the point.

[17:53:06.0000] <zewt>
err, java and javascript's differences are much deeper than syntax

[17:53:20.0000] <zewt>
probably the only thing they have in common is GC

[17:53:34.0000] <TabAtkins>
None of which are particularly relevant to the treatment of binary data.

[17:54:35.0000] <zewt>
if somebody saw performance issues with returning a uint8_t* and then casting it to uint32_t* in Java, that doesn't inform JS API development at all

[17:55:27.0000] <TabAtkins>
It was something about processors and memory pipelines or something like that.  Something pretty language-agnostic.

[17:55:53.0000] <zewt>
maybe it was a different conversation, since in the one I had I don't recall any technical followups

[17:55:54.0000] <TabAtkins>
Doesn't mean it was validly generalizable - it may have been something more API-specific, or dated.  But it wasn't *language*-specific.

[17:56:07.0000] <TabAtkins>
Kenneth Russell was the one talking about it.

[17:56:13.0000] <TabAtkins>
And Gregg Tavares.

[17:58:01.0000] <zewt>
nothing in my experience would explain a processor-level performance difference between "return an object that accesses a void* as 8-bit unsigned ints, then create an object that accesses the same void* as 32-bit unsigned ints" and "return an opaque object holding a buffer, then create an object that accesses the buffer as 32-bit unsigned ints"

[17:58:51.0000] <TabAtkins>
The only Java-based performance argument I recall was one about endianness.  I don't really remember one about ArrayBuffer vs ArrayBufferView.

[17:59:16.0000] <TabAtkins>
If I pass a DOMString representing a url to a function, does it make sense to parse the url and reject it if there's a parse error?

[17:59:28.0000] <TabAtkins>
Or should I be forgiving and just work with whatever the URL parser spits out?

[17:59:28.0000] <zewt>
i think i remember that conversation (but it's a different one, or at least a different subargument)

[17:59:39.0000] <TabAtkins>
Ah, then I dunno what we're talking about. ^_^

[18:00:03.0000] <zewt>
where we were saying "having UInt32Array be the platform endianness is interop death and don't do it"

[18:02:14.0000] <zewt>
TabAtkins: copy whatever new WebSocket(url) does?

[18:02:25.0000] <zewt>
(was going to say "xhr", but thought better of that)

[18:02:28.0000] <TabAtkins>
Good point.

[18:03:35.0000] <TabAtkins>
Throw a SyntaxError and abort.  Can do.

[18:45:21.0000] <zewt>
now there's somebody on www-dom who's so important he's sending all his mails in Gigantic Red

[18:48:52.0000] <TabAtkins>
annevk: How do I deal with a response once it's been returned by Fetch?

[18:49:04.0000] <TabAtkins>
Just check if it returned a code of 200 and a non-null body?

[18:51:58.0000] <TabAtkins>
(I presume redirects are automatically handled for me and I wont' see them, unless I've set the manual redirects flag.)

[19:04:09.0000] <TabAtkins>
annevk: If it helps, I'm doing a synchronous fetch, because I'm already in an async portion of the algorithm, and it seemed like that was easiest.

[20:56:47.0000] <zewt>
also cool google joins the ranks of "you gave us your email address, and we've decided it's okay to use it for ads"

[20:57:07.0000] <zewt>
"Your Google Wallet has exciting new updates", as if I've ever used "google wallet" (much less opted into ads)

[23:41:59.0000] <TabAtkins>
zewt: You should use Wallet - it's a lot more convenient than PayPay for sending people money.

[23:43:20.0000] <annevk>
TabAtkins: so yes, don't do normalization in CSS. Just say people ought to normalize, but don't require it from implementations. Deal in 16-bit code units as the whole thing bottoms out to JavaScript in the end...

[23:43:47.0000] <annevk>
TabAtkins: TypeError and RangeError are defined by JavaScript, not DOM (we need to revise DOMException in some way still, haven't figured out how)

[23:44:17.0000] <TabAtkins>
annevk: Ah, the error thing is confusing.  Perhaps a note in the Event Names section is warranted?  I'll file a bug.

[23:44:38.0000] <annevk>
TabAtkins: so there's a bug on moving the whole error thing over to Web IDL already

[23:45:02.0000] <TabAtkins>
Ah, then I'll just leave it alone I suppose.

[23:45:30.0000] <annevk>
TabAtkins: as for something accepting bytes, just use ArrayBuffer for now and we'll think of something better once ES6 has assimilated the whole bunch

[23:45:53.0000] <TabAtkins>
I just did a typedef for (ArrayBuffer or ArrayBufferView).

[23:47:30.0000] <annevk>
TabAtkins: yeah I guess, one technical problem with that is that ArrayBuffer/ArrayBufferView are no longer IDL-defined

[23:47:43.0000] <TabAtkins>
Meh.

[23:51:46.0000] <annevk>
I guess I should file a bug on IDL for that too, though I suspect heycam might wanna wait for ES6 with that...

[23:52:15.0000] <heycam>
are they going in to the ES spec in the ES6 timeframe?

[23:52:25.0000] <heycam>
(not that I know what that timeframe is)

[00:00:01.0000] <TabAtkins>
annevk: So what about my last question, regarding what to do with a response returned by fetch?

[00:00:26.0000] <annevk>
heycam: yeah, timeframe is end-of-year plus a year to fix bugs I think

[00:00:38.0000] <annevk>
TabAtkins: we generally don't look at the response code at all, except for redirects which Fetch handles

[00:01:04.0000] <heycam>
ok

[00:01:06.0000] <annevk>
TabAtkins: so you either get something back which you decode or you get a network error

[00:01:08.0000] <TabAtkins>
Okay, so I just trust that if I got a response rather than an error, I can read the body for the data?

[00:01:20.0000] <TabAtkins>
Ooh, I have to decode it now?

[00:01:21.0000] <annevk>
TabAtkins: that's how <img>, <script>, et al work, yes

[00:01:36.0000] <annevk>
TabAtkins: dunno, depends on what you're fetching :)

[00:01:48.0000] <TabAtkins>
Oh, right, just font data, so no text decoding necessary.

[00:01:50.0000] <TabAtkins>
Okay.

[00:01:57.0000] <TabAtkins>
This would be useful information in Fetch. ^_^

[00:02:02.0000] <annevk>
TabAtkins: just font decoding then :)

[00:02:21.0000] <annevk>
TabAtkins: file a bug?

[00:02:45.0000] <annevk>
/me is still at the stage where he tries to make Fetch work for the entire platform

[00:06:30.0000] <annevk>
heycam: they're in http://people.mozilla.org/~jorendorff/es6-draft.html fwiw

[01:56:42.0000] <annevk>
TabAtkins: I guess the other thing is that I hope example usage needs go away once more specs start using the revised building blocks; you just happen to be an early adaopter... :/

[02:33:24.0000] <jgraham>
annevk: Yes. Tests are BSD/W3C dual licensed

[02:33:48.0000] <jgraham>
i.e. they are BSD licensed but you don't get to call it the "W3C testsuite"

[02:33:54.0000] <annevk>
They cannot be more liberally licensed I guess?

[02:34:07.0000] <jgraham>
Not really

[02:34:18.0000] <jgraham>
I mean that's pretty reasonable I think

[02:34:42.0000] <jgraham>
(more liberal than any browser engine, for example)

[02:52:13.0000] <zcorpan>
TabAtkins: WebSocket throws if the url is invalid

[02:52:34.0000] <zcorpan>
TabAtkins: but there's probably also precedent for silent fail

[02:52:57.0000] <annevk>
Like <a>

[02:53:07.0000] <annevk>
And setting <a>.href

[03:08:17.0000] <annevk>
Why has nobody noticed that http://encoding.spec.whatwg.org/#dom-textencoder-encode does not throw the exception it should?

[03:08:25.0000] <annevk>
That's kind of disturbing...

[03:10:18.0000] <darobin>
annevk: probably because no one has read it?

[03:10:37.0000] <annevk>
Oh wait, only utf-8 / utf-16. Doh.

[03:10:55.0000] <annevk>
No people have read that and implemented it. I just assumed it had to work for arbitrary encodings which is not true.

[03:11:09.0000] <annevk>
We might want to add that at some point I suppose.

[03:23:13.0000] <annevk>
/me wonders where SimonSapin is

[03:23:48.0000] <Ms2ger>
Behind you!

[03:28:15.0000] <annevk>
Ms2ger, typically that'd be very close, but today...

[03:28:42.0000] <Ms2ger>
I dunno, he's French, maybe on vacation? :):

[03:30:31.0000] <annevk>
So both the utf-8 and utf-16 encoders deal with lone surrogate input... Does that make sense?

[03:31:24.0000] <annevk>
That also contradicts my earlier point about them always being safe...

[03:31:58.0000] <jgraham>
annevk: draw a cone out from your back across the surface of the earth, and he is contained in the cone. At least if you allow it to wrap around the surface

[03:32:09.0000] <jgraham>
So I guess he is behind you?

[03:32:51.0000] <annevk>
s = new TextEncoder("utf-16le"); w(s.encode("\ud800"))

[03:32:57.0000] <annevk>
Gives 0, 216

[03:33:29.0000] <SimonSapin>
annevk: should it throw?

[03:34:37.0000] <annevk>
SimonSapin: either that, or before it even reaches the encoder it should've been replaced with FFFD

[03:35:06.0000] <annevk>
I think currently the latter is what's required through IDL...

[03:35:42.0000] <annevk>
I'm fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23103 so I ran into this

[03:38:19.0000] <annevk>
Gecko does the FFFD treatment for utf-8

[03:38:25.0000] <SimonSapin>
uh. JS strings biting us again

[03:39:37.0000] <annevk>
The more I run into it, the more I think we should just embrace it and define everything in terms of 16-bit code units. Although that'd be a pain for some encodings...

[03:39:58.0000] <annevk>
Like rewriting gbk to work on 16-bit code units is way less nice.

[03:40:28.0000] <annevk>
And by everything I mean URL, Encoding, HTML, CSS, ...

[03:48:46.0000] <smaug____>
/me wonders why Promises are so hip

[03:49:43.0000] <jgraham>
Because they are new and unproven and therefore we don't fully understand all the problems with them yet

[03:50:08.0000] <Ms2ger>
zcorpan, jgraham: do you know if there's tests for MessageChannel and stuff somewhere?

[03:51:28.0000] <jgraham>
Or, to be less synical, because all the async primitives we have tried in in so far have sucked, so trying a new approach that has theoretical benefits and some positive experience in the js framework community seems like a good idea

[03:51:33.0000] <jgraham>
*cynical

[03:53:07.0000] <zcorpan>
Ms2ger: https://github.com/w3c/web-platform-tests/tree/master/webmessaging/message-channels

[03:54:38.0000] <Ms2ger>
zcorpan, thanks

[04:27:22.0000] <SimonSapin>
annevk: code points everywhere

[04:28:12.0000] <annevk>
SimonSapin: that might mean encoders that fail, depending on how we define them

[04:32:51.0000] <SimonSapin>
annevk: do "16bits units everywhere" fix that? You can still get lone surrogates

[04:33:07.0000] <SimonSapin>
is whatwg.org supposed to support https?

[04:33:43.0000] <SimonSapin>
<link href="//www.whatwg.org/style/specification" rel="stylesheet"> times out from https://rawgithub.com

[04:34:03.0000] <jgraham>
I don't think it is

[04:35:22.0000] <SimonSapin>
HTML uses href="http://www.whatwg.org/style/specification"

[04:46:40.0000] <Ms2ger>
Apparently the Google Authenticator update is no good

[04:48:49.0000] <annevk>
SimonSapin: yeah, but then we just embrace lone surrogates, and only catch them when absolutely necessary

[04:49:05.0000] <annevk>
SimonSapin: which is almost never

[04:49:06.0000] <SimonSapin>
annevk: same as with code points?

[04:49:26.0000] <annevk>
SimonSapin: code points doesn't really exist

[04:49:35.0000] <annevk>
SimonSapin: so that seems kinda pointless as a concept

[06:27:01.0000] <annevk>
(In case you were wondering, that's false starting with ES6. It'll expose methods around String objects that deal with code points, not 16-bit code units, or Unicode scalar values. That's a first though I think.)

[06:39:32.0000] <SimonSapin>
annevk: I went through the Encoding changes. Looks good.

[06:40:07.0000] <annevk>
Thanks. I guess next would be figuring out if I want that abstract stream concept...

[06:40:39.0000] <annevk>
Or maybe look into the various issues around encodings...

[07:01:05.0000] <GPHemsley>
W3C is updating its Bugzilla instance tomorrow! \o/

[07:01:31.0000] <jgraham>
W3C is breaking bugzilla tomorrow!

[07:01:36.0000] <GPHemsley>
\o/

[07:10:29.0000] <Domenic_>
Where is Mozilla's JS engine source located?

[07:10:41.0000] <Domenic_>
Preferably web-viewable

[07:13:01.0000] <jgraham>
https://dxr.mozilla.org

[07:13:34.0000] <jgraham>
http://dxr.mozilla.org/mozilla-central/source/js specifically

[07:13:46.0000] <Domenic_>
Awesome, thanks

[07:14:19.0000] <annevk>
jgraham: what's the difference with http://mxr.mozilla.org/mozilla-central/source/js/ ?

[07:14:43.0000] <jgraham>
dxr is shinier

[07:15:00.0000] <jgraham>
It has a bunch of fancy features based on static analysis of the code

[07:15:18.0000] <jgraham>
But only works on m-c and one revision

[07:15:18.0000] <SimonSapin>
cool

[07:15:42.0000] <annevk>
But it's not live it seems

[07:16:04.0000] <SimonSapin>
live?

[07:16:55.0000] <jgraham>
Right, it probably only gets updated sometimes

[07:17:04.0000] <jgraham>
Because you need to do all the static analysis

[07:18:21.0000] <jgraham>
I'm not sure how often, but the files seem to be dated 3rd September, so I guess daily?

[07:45:33.0000] <Ms2ger>
Mxr isn't live either

[07:51:37.0000] <Ms2ger>
annevk, r? https://critic.hoppipolla.co.uk/r/294 :)

[07:51:57.0000] <annevk>
long test is long

[07:55:49.0000] <zewt>
TabAtkins: nothing I use supports it

[07:57:18.0000] <jgraham>
That's a long test?

[07:58:18.0000] <Ms2ger>
Have you seen jgraham's loading tests?

[07:59:11.0000] <jgraham>
Well they're just silly

[07:59:25.0000] <jgraham>
Tests that require navigation to three different files

[07:59:55.0000] <Ms2ger>
I started reviewing, but...

[08:00:26.0000] <jgraham>
Yeah :|

[08:00:34.0000] <annevk>
jgraham: I know I know

[08:00:41.0000] <jgraham>
I would love to say "they were reviewed internally at Opera and are fine"

[08:00:47.0000] <jgraham>
But that just isn't true

[08:00:55.0000] <Ms2ger>
Well

[08:01:10.0000] <Ms2ger>
The result of that would probably be people filing bugs and bz having to review them

[08:01:27.0000] <jgraham>
gsnedders probably reviewed them a bit, but they are quite likely to be buggy, and the spec was unstable and the implementation was never finished

[08:01:34.0000] <jgraham>
So..

[08:02:07.0000] <SimonSapin>
annevk: ES6 codePointAt and fromCodePoint are the only things that "expose" code points to the platform … but are unicode scalar values exposed ?

[08:02:19.0000] <annevk>
Yes, utf-8

[08:02:24.0000] <SimonSapin>
if exposed means from JS

[08:02:32.0000] <annevk>
No it just means exposed

[08:04:49.0000] <SimonSapin>
data:text/html,<script>document.write('\uD800')</script> looks like a missing glyph in Gecko. Isn’t that the text subsystem working on code points?

[08:05:01.0000] <SimonSapin>
(missing glyph, as opposed to replacement character)

[08:05:02.0000] <jgraham>
Ms2ger: So I don't mind bz reviewing them :)

[08:05:30.0000] <Ms2ger>
jgraham, well, I'm not sure if I'd prioritize it over his other work ;)

[08:05:37.0000] <Ms2ger>
Maybe I should enlist the Servo folks

[08:06:30.0000] <jgraham>
Yeah, well the servo people are the ones that should benefit the most from this

[08:06:56.0000] <jgraham>
But afaict they are so far away from having a working DOM that it is too early to do any of this kind of testing

[08:07:04.0000] <jgraham>
Maybe I should work out how to build servo

[08:08:36.0000] <Ms2ger>
I mentioned getting testharness.js to work to jdm and he seemed positive

[08:08:47.0000] <annevk>
SimonSapin: doesn't seem interoperable

[08:09:44.0000] <SimonSapin>
chrome just seems to just stop at lone surrogate and drop the rest of the string: data:text/html,<script>document.write('ab\uD800cd')</script>

[08:10:28.0000] <SimonSapin>
well, worse than that: data:text/html,<script>document.write('ab\uD800cd')</script>ef

[08:10:38.0000] <Ms2ger>
/me wonders how to update his tree again

[08:11:04.0000] <Domenic_>
annevk: SimonSapin: there's a bit more code point exposure in ES6 than just those methods, e.g. http://www.slideshare.net/domenicdenicola/es6-is-nigh/41

[08:12:16.0000] <annevk>
Domenic_: I mentioned the iterator in my email I think

[08:12:21.0000] <annevk>
Domenic_: it's not in the draft though

[08:12:31.0000] <annevk>
Domenic_: anyway, it could do the same

[08:12:39.0000] <Domenic_>
annevk: ah right, sorry missed that

[08:13:44.0000] <Domenic_>
I believe the ES6 conceptual model was supposed to be 21 bit code points, with "legacy" string[i] and string.charCodeAt(i) exposing 16-bit code units.

[08:14:50.0000] <annevk>
Yeah, it's pretty clear what they went for, I think it'd be better to align with Unicode's actual data model if possible (which means not exposing surrogates if we don't have to)

[08:15:47.0000] <Domenic_>
I don't know very much about this so I'm not sure what they're doing wrong, heh.

[08:26:25.0000] <zewt>
well, if you have UTF-16 as your underlying storage, random access to indexed codepoints is hard, heh

[08:27:37.0000] <Ms2ger>
If you have anything but utf-32? :)

[08:27:39.0000] <SimonSapin>
The i in s.codePointAt(i) counts 16 bit units, not code points

[08:28:27.0000] <zewt>
SimonSapin: sure, replying to "supposed to be 21-bit codepoints"

[08:29:06.0000] <zewt>
Ms2ger: utf-32 is probably the right storage format

[08:29:26.0000] <Domenic_>
SimonSapin: I don't believe that's true, I believe it's supposed to count 21-bit code points.

[08:29:41.0000] <jgraham>
zewt: Arguably that depends on what you think is important

[08:30:03.0000] <jgraham>
If indexed access isn't important then UTF-32 is just a waste of memory in most cases

[08:30:25.0000] <jgraham>
Well, unless your system is mainly storing Linear-B I guess

[08:30:39.0000] <zewt>
indexed access isn't particularly important, as long as you have an API model that works with it ... JS developers are probably too programmed for it

[08:31:20.0000] <SimonSapin>
Domenic_: from the draft: Let first be the code unit value of the element at index position in the String S.

[08:31:38.0000] <SimonSapin>
ie. first = S[position]

[08:32:02.0000] <Domenic_>
SimonSapin: no, indexed positions are code points

[08:33:17.0000] <Domenic_>
SimonSapin: []s are not, but those are different from the spec term "index position"

[08:33:33.0000] <jgraham>
Uh

[08:33:40.0000] <jgraham>
That's one confusing spec then

[08:33:53.0000] <Domenic_>
SimonSapin: compare codePointAt and charAt (which uses "the code unit at position position")

[08:34:50.0000] <SimonSapin>
So is this wrong? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/charCodeAt#Example_4.3A_ES_6_codePointAt_shim

[08:34:58.0000] <zewt>
exposing anything about codepoint indexes on top of utf-16 would be pretty ugly, though you can probably optimize the most common cases to avoid n^2 (forward and backward scanning)

[08:35:34.0000] <annevk>
Domenic_: where is index position defined?

[08:35:47.0000] <Domenic_>
annevk: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.8.6

[08:36:22.0000] <Domenic_>
there are broken links pointing to 8.4, but that is outdated. (Wasn't keeping references up to date an actual feature of Word? :-S)

[08:37:10.0000] <annevk>
Domenic_: searching for "index position" doesn't get there...

[08:37:43.0000] <Domenic_>
annevk: right, but SV is an (indexed) sequence of CVs, which are defined there.

[08:38:45.0000] <zewt>
(though I guess caching could run into catastrophic performance dropoffs; eg. if only a single position is cached, and a parser is scanning linearly from two different places, performance would mysteriously fall through the floor)

[08:39:03.0000] <SimonSapin>
I’m confused

[08:39:22.0000] <annevk>
Domenic_: CV only seems to talk about code unit sequences, not code point sequences

[08:39:44.0000] <Domenic_>
annevk: I don't think so... e.g. the CV of \u{six digits} is given as a single number

[08:40:02.0000] <annevk>
Domenic_: no, it says to unwrap it using utf-16 into two code units

[08:40:13.0000] <annevk>
Domenic_: if it's higher than U+FFFF anyway

[08:41:03.0000] <Domenic_>
ah yeah, you're right

[08:41:04.0000] <Domenic_>
hrm

[08:41:08.0000] <annevk>
Domenic_: the CV stuff is kinda confused

[08:41:21.0000] <annevk>
Domenic_: it suddenly starts talking about characters now and then rather than empty code unit sequence

[08:42:13.0000] <Domenic_>
I wonder if I have the intent right though. Notably codePointAt(i) and charAt(i) say very different things about what to do with `i`.

[08:43:01.0000] <annevk>
maybe :)

[08:43:27.0000] <annevk>
it'd make codePointAt quite a bit slower

[08:44:50.0000] <Domenic_>
http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aunicode_supplementary_characters&cache=cache&media=harmony:supplementary_characters_for_ecmascript.pdf

[08:45:28.0000] <annevk>
The way TC39 operates reminds me of OMA back in 2005 when I started at Opera...

[08:45:44.0000] <annevk>
It's 2013, PDFs you have to download to read a proposal? Come on...

[08:46:11.0000] <Domenic_>
my hatred of PDFs has decreased significantly since pdfjs got into Firefox stable :)

[08:46:27.0000] <zewt>
pdf is still terrible, even in chrome's viewer

[08:47:03.0000] <zewt>
spent like a minute copying a couple pages of a list the other day because it wouldn't let me extend a selection (in osx)

[08:47:10.0000] <annevk>
Domenic_: codePointAt is implemented in terms of charCodeAt there

[08:47:43.0000] <annevk>
Domenic_: passing index directly to charCodeAt that is to find the first surrogate (if any)

[08:48:06.0000] <annevk>
Domenic_: sure, but this is not served in a way that opens in pdf.js automatically

[08:48:11.0000] <Domenic_>
annevk: yeah, looks like I was just wrong, darn. codePointAt seems not very useful.

[08:48:25.0000] <Domenic_>
annevk: interesting, it opened in pdfjs automatically for me.

[08:48:41.0000] <annevk>
Domenic_: the language differences are kinda broken though

[08:49:17.0000] <Domenic_>
annevk: agreed, if they are supposed to be using the same indexing paradigm, the current spec does not make that clear.

[08:50:19.0000] <zewt>
could be maybe sort-of useful if it returned -1 for high surrogates, so you could say for(i=0;i<n;++i) { codepoint = s.codePointAt(n); if(codepoint == -1) continue; /* skip */ log(codepoint); }

[08:50:27.0000] <annevk>
It might be better to just have the iterator and maybe String.fromUnicode(...) or some such

[08:50:33.0000] <annevk>
Does String.from() exist?

[08:50:38.0000] <Domenic_>
no

[08:50:45.0000] <zewt>
so you'd just skip over high surrogates (that you already dealt with at n-1)

[08:50:55.0000] <annevk>
Why is not called String.from()?

[08:51:00.0000] <zewt>
(er, probably flip high/low)

[08:51:05.0000] <Hixie_>
i use http://people.mozilla.org/~jorendorff/es6-draft.html as the js spec, but i don't know if there's proposals in html format

[08:51:26.0000] <annevk>
Hixie_: same and there's the wiki pages...

[08:51:44.0000] <Domenic_>
annevk: what would you want as String.from()? Your proposed String.fromUnicode()?

[08:51:47.0000] <annevk>
Hixie_: last meeting there was talk about putting it all in GH but inertia I guess

[08:52:20.0000] <annevk>
Domenic_: yeah, sequence of 21-bit code points, but with surrogates banned (so, Unicode scalar values)

[08:52:24.0000] <Ms2ger>
And you're not allowed to look at the wiki, because you have to smell that they're out of date, why are you even looking there, stupid

[08:53:09.0000] <Domenic_>
annevk: like... String.from(65, 1234, 23341)?

[08:53:29.0000] <annevk>
They could use some project management indeed. Outward communication is really poor. You kinda have to attend meetings to understand what's going on and how stuff works, which I'm doing atm...

[08:53:30.0000] <annevk>
Domenic_: yeah

[08:53:46.0000] <annevk>
Domenic_: just a better String.fromCharCode()

[08:54:00.0000] <Domenic_>
That's called String.fromCodePoint() now :)

[08:54:15.0000] <annevk>
Domenic_: I know, but that one outputs lone surrogates

[08:54:21.0000] <annevk>
Domenic_: and I thought we preferred shorter names?

[08:54:41.0000] <Ms2ger>
Well, that or put everything that's being implemented into the spec

[08:55:14.0000] <annevk>
Ms2ger: they are in on that plan now I think

[08:55:45.0000] <Domenic_>
What other plan would there be O_o

[08:56:08.0000] <Ms2ger>
But maybe also not have the spec in a word document that's only released once in a blue moon

[08:56:23.0000] <annevk>
Ms2ger: so if something is missing we could file a bug... although BE does still value underdefining features

[08:57:05.0000] <annevk>
Domenic_: well they refused to document a bunch of stuff until we made it clear via e.g. http://javascript.spec.whatwg.org/ that it's actually implemented

[08:57:15.0000] <Domenic_>
annevk: ah right that stuff.

[08:57:20.0000] <annevk>
Domenic_: I'm not sure if '<!--'-style comments are now?

[08:57:36.0000] <Domenic_>
annevk: there's a TODO for those in annex B I believe

[08:57:49.0000] <annevk>
they're gonna patch the core grammar in an annex? maha

[08:58:26.0000] <Domenic_>
ideally Node.js would not need <!-- comments

[08:58:49.0000] <annevk>
I don't really see what's ideal about having an additional code path in your ES engine about something so minor

[08:58:54.0000] <Ms2ger>
annevk, sounds like css21

[08:59:03.0000] <annevk>
especially if it means more transition cost when converting JS files

[09:00:55.0000] <jgraham>
Domenic_: Doesn't node.js get wahtever V8 provides?

[09:01:04.0000] <jgraham>
Which I assume includes <!--

[09:01:12.0000] <Domenic_>
jgraham: yeah. you can do HTML comments in Node at the moment.

[09:01:52.0000] <Ms2ger>
Well

[09:01:58.0000] <Ms2ger>
Ideally node doesn't use JS ;)

[09:10:04.0000] <gsnedders>
jgraham, Ms2ger: I vetted them for release, not so much following the spec. And given I know they never matched the spec…

[09:10:47.0000] <annevk>
hah, matjas ^^

[09:11:26.0000] <matjas>
:)

[09:12:30.0000] <matjas>
still not as bad as php recognizing <script>

[09:23:58.0000] <annevk>
I hope Norbert has rationale for the surrogate thing because it sure seems like Brendan didn't think of it

[09:25:49.0000] <matjas>
Allen mentioned use cases like strings containing “binary data” before

[09:26:05.0000] <matjas>
at one point he wanted to allow up to 8 digits for the new `\u{xx}` escapes for that reason

[09:26:46.0000] <matjas>
maybe this surrogates thing is similar?

[09:27:05.0000] <jgraham>
String containing binary data?

[09:27:11.0000] <matjas>
well, you know

[09:27:12.0000] <jgraham>
Those aren't strings…

[09:27:44.0000] <jgraham>
Having a single data type for strings and random binary data is an oft-repeated mistake in language design

[09:27:46.0000] <matjas>
e.g. `foo © bar` becomes `\x66\x6F\x6F\x20\xC2\xA9\x20\x62\x61\x72` if you represent it as UTF-8

[09:28:08.0000] <matjas>
if you dont wanna use an array of bytes for some reason, i guess

[09:28:21.0000] <annevk>
matjas: I'd like to see why

[09:28:33.0000] <matjas>
yeah, i was glad when they decided only to allow 6 digits in \u{xx}

[09:28:34.0000] <annevk>
in any event, climbing time

[09:30:09.0000] <matjas>
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021919.html: “Exclude 0xD800-0xDFFF?  No.”

[10:01:11.0000] <TabAtkins>
Why would you *possibly* want 8 character in \u?

[10:02:31.0000] <TabAtkins>
Unicode is only 21 bits wide, which is 6 hex chars.  utf-8 is 4 bytes wide, or 8 hex chars, but \u doesn't specify utf-8, it specifies unicode code points (or scalars, whatever).

[10:03:58.0000] <TabAtkins>
I mean, maybe plan for the future and make sure the syntax can be expanded up to 8, just in case we ever expand unicode up to 32 bits, but that's it.  (And the \u{} syntax is okay with that, so we're good.)

[10:05:07.0000] <gsnedders>
A lot of languages use \U00000000, because they go back to UCS-4 days.

[10:05:21.0000] <jgraham>
TabAtkins: YOu might, if you wanted the string type to be used for both strings and arrays of binary data. Then \u{} notation would provide a convenient way of specifying 32bits of data at a time

[10:06:28.0000] <jgraham>
(you would be wrong to want that, but lots of languages have historically worked like that so you would be in good company)

[10:06:31.0000] <TabAtkins>
jgraham: But... it *doesn't* specify 32 bits at a time.  Unless you have some magic switch in your encoder that says that codepoints greater than u+10ffff get encoded as raw 32-bit ints.

[10:07:02.0000] <jgraham>
Well you could have that

[10:07:13.0000] <jgraham>
Although I guess it still doesn't really work

[10:07:21.0000] <jgraham>
So pass?

[10:07:53.0000] <TabAtkins>
Right.

[10:08:14.0000] <TabAtkins>
It sounds like the sort of thing you'd do only if you were certain that it would get encoded in ucs-4.

[11:06:55.0000] <dglazkov>
good morning, Whatwg!

[11:17:05.0000] <TabAtkins>
marcosc: There an agenda posted for the ricg meetup next week?

[11:22:05.0000] <Domenic_>
So there's no event for <details> opening and closing. My guess is you're supposed to use "click" on the <summary>?

[11:26:46.0000] <TabAtkins>
Hixie_ was just saying a few weeks ago that he was surprised nobody had ever requested a <details> event.  Yeah, for now you just use "click" on <summary>.

[11:28:56.0000] <Domenic_>
thanks! converting my boss to using semantic HTML :P

[11:31:19.0000] <Hixie_>
Domenic_: if you have an opinion on whether we should have onopen/onclose or just one event, comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=22942

[11:32:02.0000] <Domenic_>
Hixie_: hmm. I don't think I have a strong enough opinion. My opinion is more along the lines of "damn browser vendors, hurry up and implement `Object.observe` already."

[11:32:32.0000] <Hixie_>
oh well if you just want that you can use a mutation observer on the open="" attribute

[11:33:41.0000] <Domenic_>
i get so confused on these boolean attributes, whether they work or not. i guess it's just [checked] vs. defaultChecked vs. checked that threw me off but the confusion persists.

[11:42:51.0000] <marcosc>
TabAtkins: only an initial one - still waiting for confirmation from speakers. https://github.com/ResponsiveImagesCG/paris-meetup#proposed-agenda

[11:43:28.0000] <TabAtkins>
marcosc: Good enough for me, I just had my boss request an agenda.

[11:58:37.0000] <TabAtkins>
Hixie_: How should I hook into the Structured Clone algorithm to define a new type that can be cloned?

[11:59:07.0000] <TabAtkins>
I need to define that FontFace objects can be cloned to Workers (creating a fresh FontFace with the same information on the other end).

[12:04:49.0000] <Ms2ger>
See the typed array spec

[12:06:06.0000] <Hixie_>
TabAtkins: e-mail me and i'll add it, probably

[12:08:41.0000] <Hixie_>
looking for bike shed colours in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22942 (event name for <details>)

[12:32:58.0000] <Domenic_>
What was the point of the wheel event (as opposed to mousewheel)?

[12:33:58.0000] <Ms2ger>
D3E not wanting to figure out what legacy browsers did, and instead inventing something else?

[12:34:08.0000] <Domenic_>
yeah ok that's what it seemed like

[12:34:16.0000] <Domenic_>
then FF had to go and implement wheel but not mousewheel :-S

[12:34:23.0000] <Ms2ger>
Disclaimer: I wasn't around at the time

[12:42:03.0000] <annevk>
TabAtkins: your email doesn't make sense

[12:42:48.0000] <annevk>
TabAtkins: to elaborate, encoder != decoder, and the decoder already does the right thing

[12:48:16.0000] <smaug____>
Domenic_: all the browser which implement mousewheel implement it in very different ways

[12:48:38.0000] <smaug____>
and it didn't have the features I wanted :)

[12:49:05.0000] <smaug____>
hmm, who knows about hgroup?

[12:49:31.0000] <smaug____>
why it is so controversial ?

[12:49:49.0000] <smaug____>
/me doesn't want to read html wg mailing list

[12:52:39.0000] <jgraham>
Because people like arguning over silly things

[12:52:53.0000] <jgraham>
*arguing

[12:54:14.0000] <darobin>
is hgroup controversial?

[12:54:29.0000] <darobin>
I thought some people thought one thing, others thought another, but they didn't bother talking about it anymore

[12:54:38.0000] <Ms2ger>
HTMLWG forked

[12:54:41.0000] <jgraham>
I can't actually remember what the controversy was about now, but I am pretty sure it was something that will become irrelevant once the feature is used

[12:54:44.0000] <Ms2ger>
Apart from that, no

[12:55:13.0000] <jgraham>
(and will clearly be irrelevant if the feature is never used)

[12:55:16.0000] <Ms2ger>
I think the argument was that you were supposed to break the outline

[12:55:17.0000] <darobin>
I reckon either the feature gets used, and the debate becomes irrelevant, or it doesn't get used, and the debate becomes irrelevant

[12:55:33.0000] <darobin>
but then again the outline is broken :)

[12:56:16.0000] <darobin>
pulling wheel out of the 927 trap might be more useful

[12:56:38.0000] <smaug____>
darobin: well, we have a bug which has been reopened and closed many times depending on who is looking at it... the ones who care about W3C HTMLx specs close it, and the ones who care about WhatWG HTML spec reopen it

[12:57:20.0000] <darobin>
smaug____: how can one open and close a bug on this? even the forked HTML WG version has it as a legacy element so browser can safely just support it

[12:58:21.0000] <smaug____>
can or must?

[12:58:30.0000] <darobin>
I don't recall

[12:58:38.0000] <darobin>
that's how much I care :)

[12:58:41.0000] <smaug____>
:)

[12:58:46.0000] <smaug____>
I should not care either

[12:59:06.0000] <jgraham>
The element doesn't *do* anything in a typical browser

[12:59:12.0000] <annevk>
matjas: thanks for the help!

[12:59:26.0000] <Ms2ger>
Well, the bug is about the mapping to a11y apis

[12:59:28.0000] <darobin>
smaug____: in the parser at least it's clearly must

[12:59:32.0000] <jgraham>
Oh right

[12:59:37.0000] <darobin>
oh that

[12:59:45.0000] <jgraham>
Well that is the one place it does make a difference

[13:00:03.0000] <annevk>
matjas: ooh, sad email is sad.

[13:00:42.0000] <darobin>
jgraham: it actually makes very minor differences in a few other places

[13:00:52.0000] <darobin>
e.g. it closes a <p>

[13:01:26.0000] <darobin>
it's also in the UA style sheet with some non-default rules

[13:01:28.0000] <darobin>
but yeah, no big deal

[13:02:26.0000] <darobin>
interestingly, in the parsing section it's marked as having "special parsing rules", but then it proceeds to only appear under the comment "the normal ones" :)

[13:02:28.0000] <darobin>
anyway

[13:03:01.0000] <darobin>
/me trots off to read stuff made of paper

[15:04:05.0000] <annevk>
Domenic_: I wondered whether it might be better to give you promises.spec.whatwg.org and note in dom.spec.whatwg.org the spec has moved

[15:04:40.0000] <annevk>
Domenic_: it seems you're doing a fine job of maintaining it and there's not really any good reason I can see for me to sit in the middle

[15:37:15.0000] <Hixie_>
annevk: yt?

[15:39:15.0000] <Hixie_>
annevk: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/thread.html#msg207 http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/thread.html#msg1 looks like a thread for your spec, but i don't see a response from you -- did it slip your radar or is it something you want me to deal with?

[15:44:39.0000] <annevk>
Hixie_: we wontfixed that plan before that thread started, not sure if someone referenced the bug

[15:45:19.0000] <Hixie_>
could you update the people on the thread and respond to any novel points there or point people to where the points are already answered?

[15:45:24.0000] <Hixie_>
or i can, if you know what bug it was

[15:45:59.0000] <annevk>
Hixie_: yeah I guess I can, not now though

[15:46:44.0000] <Hixie_>
k

[16:25:09.0000] <TabAtkins>
What's an idiomatic way to write a "safe" version of a method for a spec to call (not overridable)?  Define some operation abstractly, then for the actual method, just say "do foo"?

[16:26:57.0000] <Hixie_>
that's a sound way to do it

[16:27:23.0000] <Hixie_>
but i basically rely on invokations of methods from prose implicitly not going through idl

[16:27:30.0000] <Hixie_>
so it's always gonna call the "real" one

[16:27:32.0000] <Hixie_>
imho

[16:28:13.0000] <TabAtkins>
Yeah, I've depended on that before too. It seems silly to *not* depend on it, but shrug.

[16:34:14.0000] <TabAtkins>
heycam: The [MapClass] section says that if you're manually implementing the Map methods, you *must* match the method signatures given there.  CSSFontFeatureValuesMap doesn't do this, though: http://dev.w3.org/csswg/css-fonts/#om-fontfeaturevalues

[16:34:48.0000] <TabAtkins>
Its value type is sequence<unsigned long>, but its set() method accepts (unsigned long or sequence<unsigned long>), with prose converting the former into the latter, and I think that's reasonable.

[16:35:13.0000] <TabAtkins>
heycam: Also, I'm now using SetClass, just by extrapolating from MapClass.

[16:36:17.0000] <heycam>
yeah, that's probably ok for the type to be a superset there. I'll make a note to allow that.

[16:36:43.0000] <heycam>
TabAtkins, where are you using SetClass btw?

[16:37:07.0000] <TabAtkins>
Font Load Events.  I'll have a version uploaded in a moment.

[16:37:18.0000] <heycam>
ok

[16:45:10.0000] <TabAtkins>
heycam: Okay, it's still under heavy editing churn at the moment, but the SetClass-relevant parts are in now: http://dev.w3.org/csswg/css-font-load-events/#FontFaceSet-interface

[16:46:30.0000] <heycam>
TabAtkins, I don't think you'd be able to inherit from EventTarget if you make it a SetClass

[16:46:43.0000] <TabAtkins>
EventTarget is dumb.

[16:46:54.0000] <TabAtkins>
It shouldn't be a superclass. :/

[16:47:00.0000] <Hixie_>
i tried to fight that

[16:47:01.0000] <Hixie_>
but lost.

[16:47:26.0000] <Hixie_>
people were like, "oh, you'll always be able to inherit from it"

[16:47:49.0000] <Hixie_>
TabAtkins: (you can cheat, just say "MyInterface implements EventTarget"... :-) )

[16:48:05.0000] <TabAtkins>
Heh, that works.

[16:48:12.0000] <TabAtkins>
Also: those people were dumb.  No.  Bad.


2013-09-05
[19:56:10.0000] <MikeSmith>
is there an online JS linter to which you can just feed the URL for an HTML document and it'll check the contents of the <script> elements in the document ?

[22:00:40.0000] <Domenic_>
dun-dun-DONE.... https://github.com/domenic/promises-unwrapping

[22:02:36.0000] <TabAtkins>
Is it implied that, when defining a foo() operation that calls bar() in one of its substeps, that if bar() throws an exception it'll propagate up and foo() will automatically throw it as well unless it specifically catches it?

[22:02:41.0000] <TabAtkins>
Like normal JS?

[22:02:58.0000] <TabAtkins>
Or do we have to explicitly catch and throw exceptions to avoid them being swallowed when doing spec-ese?

[22:11:18.0000] <zewt>
tab: i'm strongly in favor of always explicitly saying what to do with all exceptions from sub-algorithms; it should always be possible to read an algorithm in isolation and see what *all* of the logic paths are, without having to dig all the way into everything it calls in case something four levels deep might throw an exception

[22:14:48.0000] <zewt>
which really means specs shouldn't throw exceptions at all (all that makes exceptions exceptions is implicit stack unwinding); "exceptions" should really be return values, and only become actual exceptions when they propagate out of an API call

[22:23:01.0000] <TabAtkins>
zewt: Well, I'm using API calls within spec definitions (with the implication that it's the internal operation, not the user-facing function object), so I can't easily do that.

[22:23:11.0000] <TabAtkins>
But sure, I can explicitly throw the exception.

[01:12:39.0000] <annevk>
TabAtkins: I'm in favor of adopting JS semantics for that

[01:13:11.0000] <annevk>
TabAtkins: i.e. rethrow if an invoked algorithm throws, return terminates, throw terminates, etc.

[01:14:24.0000] <annevk>
TabAtkins: haven't really spelled the conventions out yet though

[02:24:43.0000] <annevk>
http://tomdale.net/2013/09/maybe-progressive-enhancement-is-the-wrong-term/ "This is a little bit like arguing that we should still be laying out our websites using tables and inline styles in case users disable CSS." I am disappoint

[02:31:44.0000] <jgraham>
annevk: Who is "everyone else"?

[02:31:58.0000] <jgraham>
Microsoft don't comment on whatwg

[02:32:19.0000] <annevk>
They actually did comment on that thread, forgot about that

[02:37:07.0000] <annevk>
jgraham: but e.g. Apple, Opera, Intel, Samsung?

[02:39:08.0000] <wilhelm>
annevk: Why disappoint?

[02:45:48.0000] <annevk>
wilhelm: because the argument doesn't make sense?

[03:02:48.0000] <annevk>
Hixie_: replied

[03:06:51.0000] <wilhelm>
annevk: It'a silly strawman, I agree. But his point still stands. Disabling JS was fine in 2003, but now it's a bit optimistic. (c:

[03:07:38.0000] <annevk>
wilhelm: I agree with JS being non-optional. I don't really agree with CSS being non-optional, although maybe it's true today.

[03:07:53.0000] <annevk>
wilhelm: although for many sites JS is optional still

[03:08:31.0000] <annevk>
hsivonen: are there bugs on Gecko for decoder EOF handling?

[03:10:04.0000] <wilhelm>
Then we are in agreement. (c:

[03:33:48.0000] <zcorpan>
jgraham: https://critic.hoppipolla.co.uk/r/257 the PR is closed. would it make sense for critic to drop reviews whose PR is closed?

[03:56:41.0000] <hsivonen>
annevk: Yes. Gecko decoders don't know about EOF.

[03:57:10.0000] <annevk>
hsivonen: also see email, per jsbell we do the correct thing for the API

[04:02:51.0000] <annevk>
Domenic_: https://github.com/domenic/promises-unwrapping/blob/master/README.md#propagatetoderivedp seems the note should refer to step 3

[04:17:35.0000] <jgraham>
zcorpan: It is supposed to do that

[04:17:42.0000] <jgraham>
But for some reason it doesn't work

[04:18:07.0000] <jgraham>
I'm not sure if we never get the message from github, or if the implementation is broken

[04:27:34.0000] <annevk>
Domenic_: seems I have commit access, fixed

[05:26:01.0000] <zcorpan>
jgraham: ok

[07:49:33.0000] <tobie_>
annevk: re your question about test licensing this morning, the idea is to prevent an implementor from picking an choosing just the tests it passes then claiming full W3C conformance. You're still free to do that, but you can't claim the test suite created that way has anything to do with W3C.

[07:50:02.0000] <Hixie_>
you don't need copyright or a license to do that

[07:50:11.0000] <Hixie_>
just use trademark law

[07:50:51.0000] <jgraham>
Right

[07:50:56.0000] <tobie_>
I'm not suggesting this is the best/only way to do so. just describing the intent behind it.

[07:51:43.0000] <jgraham>
For all intents and purposes the tests are BSD licensed

[07:52:32.0000] <tobie_>
Would trademark law work outside of the U, though? (not a lawyer)

[07:52:40.0000] <tobie_>
s/U,/US/

[07:53:44.0000] <jgraham>
I'm not sure that there's anywhere that would respect copyright more than trademark law, but I might be wrong

[07:54:27.0000] <Hixie_>
the real question is, is anyone really going to sue anyone if someone _does_ try to claim that they pass a twisted test suite?

[07:55:10.0000] <wilhelm>
Public shaming may be much more effective. And cheap.

[07:55:18.0000] <tobie_>
^ that

[07:55:40.0000] <jgraham>
Hixie_: BTW I looked and afaict all the implementations I have access to treat the element-in-scope stuff as an algorithm that takes a tag name and operates on the stack of open elements at the time the information is required, rather than as an ambient property of the environment that is kept up to date

[07:55:56.0000] <Hixie_>
well yeah

[07:56:03.0000] <Hixie_>
doing it the other way would be massively inefficient

[07:56:20.0000] <Hixie_>
the goals of a spec and the goals of implementations aren't the same

[07:56:29.0000] <Hixie_>
(obviously)

[07:56:41.0000] <jgraham>
Well it doesn't really make the spec more understandable if the way that you implement it and the way that you read the spec intentionally diverge

[07:57:20.0000] <Hixie_>
there's very few parts of the spec where they _don't_ diverge

[07:57:42.0000] <Hixie_>
(and since implementations vary in how they implement things, that'll always be true)

[07:58:28.0000] <jgraham>
In this case the implementations all implement things in roughly the same way, and the spec could easily use that way, but instead uses something different and, apparently, confusing

[07:58:52.0000] <Hixie_>
yeah. i don't understand what's confusing about it, but certainly some people are confused by it.

[08:03:42.0000] <annevk>
jgraham: is there a pointer on how I contribute to web-platform-tests?

[08:03:56.0000] <jgraham>
annevk: Ask tobie_

[08:03:58.0000] <annevk>
jgraham: I might be just awake enough to move the tests from my URL repo

[08:04:01.0000] <annevk>
tobie_: ^^

[08:04:15.0000] <jgraham>
I don't understand the documentation situation anymore

[08:04:34.0000] <jgraham>
There is some replacement for the testtwf site that's supposed to have all this stuff on

[08:04:49.0000] <tobie_>
Working on getting this out asap

[08:05:10.0000] <tobie_>
was delayed by personal matters over the last couple of weeks.

[08:06:17.0000] <jgraham>
Do you have an expected timeline?

[08:06:28.0000] <tobie_>
annevk: you probably want to look at https://github.com/w3c/testtwf-website/blob/gh-pages/docs/migration-process.md in the meantime

[08:06:36.0000] <tobie_>
jgraham: by the end of the week

[08:06:53.0000] <jgraham>
That sounds good

[08:07:02.0000] <tobie_>
(or early next)

[08:24:20.0000] <annevk>
Hixie_: some people on Twitter got upset with your definition of resource

[08:25:02.0000] <annevk>
Hixie_: although I think you know and I don't really and none of it was constructive :/

[08:25:11.0000] <annevk>
care /\

[08:27:17.0000] <Hixie_>
annevk: my definition of resource?

[08:27:38.0000] <annevk>
Hixie_: https://twitter.com/mnot/status/375439468343209984 and onwards

[08:31:47.0000] <Hixie_>
oh, \/\/hatever. it's a non-normative statement of fact. if they disagree they can learn to send feedback using real mechanisms.

[08:33:42.0000] <jgraham>
Your feedback has been ignored because: [x] It was posted in a medium designed for sharing cat pictures

[08:36:54.0000] <Hixie_>
more like, your feedback has been considered and rejected but you have not received a personalised response becouse: [x] it was posted in a medium not designed for useful debate

[08:37:56.0000] <zewt>
more like "designed to prevent useful debate"

[08:38:10.0000] <Hixie_>
i doubt it was literally designed to prevent useful debate

[08:38:16.0000] <jgraham>
Well

[08:38:43.0000] <jgraham>
it's hard to imagine that they thought people would try and have debates in 140 characters

[08:38:49.0000] <Hixie_>
right

[08:38:57.0000] <Hixie_>
hence the way i phrased it

[08:39:04.0000] <jgraham>
I imagine that they conciously optimised for other use cases (sharing links to cat pictures)

[08:39:35.0000] <Hixie_>
yeah

[08:39:45.0000] <Hixie_>
can you dispatchEvent() the event you are currently handling?

[08:39:47.0000] <Hixie_>
or does that fail

[08:40:00.0000] <Hixie_>
and if it fails, is there a way to clone an event?

[08:41:12.0000] <annevk>
no way to clone

[08:41:42.0000] <annevk>
Hixie_: "If event's dispatch flag is set, or if its initialized flag is not set, throw an "InvalidStateError" exception. "

[08:42:36.0000] <Hixie_>
k

[08:42:50.0000] <Hixie_>
/me manually creates a new event and copies all the state over

[08:49:59.0000] <annevk>
Hixie_: I hope this isn't in a spec

[08:50:24.0000] <annevk>
Hixie_: also, if you have a use case...

[08:50:38.0000] <Hixie_>
not in a spec

[08:50:49.0000] <Hixie_>
my use case is, when i get a resize event, i want to dispatch it to the currently visible "panel"

[08:50:54.0000] <annevk>
new Event(evObj) could work maybe

[08:51:16.0000] <annevk>
although there's some trickery with regards to types and what to clone, etc.

[08:51:44.0000] <annevk>
I guess each event object would only clone from the passed event what they know about, although even then you have to be careful about identically named members

[08:52:27.0000] <zewt>
iirc i've had to manually "clone" events, in cases where i intercept a real event in a capture, do something else, then want to re-fire the original event later

[09:03:30.0000] <annevk>
Too bad people don't really report those kind of things as annoyances... Btw zewt, are you gonna update the Zip wiki entry?

[09:23:13.0000] <zewt>
haven't had a chance, I want to go through the appinfo again first, see what needs additional specification and how brittle doing it by delta instead of clean slate seems...

[09:29:09.0000] <annevk>
zewt: aight

[09:29:24.0000] <annevk>
zewt: no hurry I suppose, need to figure out a ton of other stuff anyway

[10:02:08.0000] <reyre>
zcorpan: ping

[10:02:21.0000] <zcorpan>
reyre: pong

[10:02:54.0000] <zcorpan>
/me is on a flaky connection

[10:02:56.0000] <reyre>
zcorpan: can you point out to me where <track> has 'onload' and 'onerror'? i'm having trouble finding it

[10:03:13.0000] <Ms2ger>
Probably on HTMLElement or whatever

[10:03:34.0000] <Ms2ger>
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#globaleventhandlers

[10:03:35.0000] <reyre>
Ms2ger: i'm looking at HTMLTrackElement, but don't see it

[10:03:40.0000] <Ms2ger>
HTMLElement implements GlobalEventHandlers;

[10:03:47.0000] <Ms2ger>
interface HTMLTrackElement : HTMLElement {

[10:04:40.0000] <reyre>
Ms2ger: ah okay

[10:05:00.0000] <reyre>
so we have to specify when HTMLTrackElement should emit these events

[10:05:07.0000] <reyre>
correct?

[10:05:19.0000] <reyre>
otherwise it would just be the default from HTMLElement

[10:06:11.0000] <zcorpan>
reyre: "Queue a task to first change the text track readiness state to failed to load and then fire a simple event named error at the track element." http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#start-the-track-processing-model

[10:07:14.0000] <zcorpan>
reyre: and:

[10:07:18.0000] <zcorpan>
If the file was successfully processed, fire a simple event named load at the track element.

[10:07:19.0000] <zcorpan>
Otherwise, the file was not successfully processed (e.g. the format in question is an XML format and the file contained a well-formedness error that the XML specification requires be detected and reported to the application); fire a simple event named error at the track element.

[10:08:55.0000] <reyre>
zcorpan: okay cool, thank you for that

[10:09:07.0000] <reyre>
this should be enough for our needs

[10:09:10.0000] <reyre>
in regards to that bug

[10:09:46.0000] <zcorpan>
ok. i think there are tests for the events in https://critic.hoppipolla.co.uk/r/74

[10:11:00.0000] <zcorpan>
at least the CORS tests rely on load/error events

[10:11:17.0000] <reyre>
zcorpan: nice, book marking that now, thanks :)

[10:12:16.0000] <zcorpan>
reyre: if you find issues with the tests, please raise in the review

[10:13:12.0000] <reyre>
zcorpan: will do

[10:14:14.0000] <zcorpan>
reyre: what does gecko do wrt the MIME type for <track>? (see yellow box in the spec linked to above)

[10:22:57.0000] <reyre>
zcorpan: we check for 'text/vtt', and i'm not exactly sure *what* happens in the underlying code there as it goes through the networking library which i don't know much about

[10:36:04.0000] <zcorpan>
reyre: ok. presto ignores the mime type for <track>. check http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2509 and change the type or the signature in opera 12.x

[11:06:15.0000] <GPHemsley>
Even employees of the Government of Canada don't know how to read directions.

[11:06:29.0000] <GPHemsley>
And yet somehow I have more empathy for them.

[13:33:28.0000] <Ms2ger>
... CSS3Test.com?

[13:33:47.0000] <miketaylr>
looks legit, has ads

[13:34:56.0000] <Ms2ger>
I thought Lea had more brains than that

[13:37:16.0000] <TabAtkins>
The numbers are useless as always, but the actual results look useful.

[13:40:33.0000] <jgraham>
TabAtkins: Isn't this the opposite? The numbers are "useful" but the results are useless (except in a caniuse sense)

[13:40:56.0000] <jgraham>
(of course the numbers aren't actually useful)

[13:40:58.0000] <TabAtkins>
No, knowing that a browser does/doesn't parse something is pretty useful.

[13:41:01.0000] <Hixie_>
/me really is at a loss as to what mnot and company were complaining about

[13:42:05.0000] <Hixie_>
oh well

[13:42:18.0000] <jgraham>
/me refers Hixie to the previous conversation about twitter

[13:42:39.0000] <jgraham>
But at a guess, your concept of "resource" doesn't map exactly to the http concept

[13:43:43.0000] <Hixie_>
what on earth is the http concept of origin, if it doesn't match the change mnot was complaining about?

[13:44:47.0000] <jgraham>
s/origin/resource/

[13:44:48.0000] <jgraham>
?

[13:44:54.0000] <Hixie_>
uh, yeah, sorry

[13:45:00.0000] <Hixie_>
too many balls in the air over here

[13:45:11.0000] <Hixie_>
TabAtkins: what's the place to look for for the definition of "replaced element" these days?

[13:45:19.0000] <TabAtkins>
css 2.1

[13:45:47.0000] <Hixie_>
is http://www.w3.org/TR/CSS2/ the latest version of that?

[13:45:56.0000] <TabAtkins>
Yes.

[13:46:17.0000] <Hixie_>
thanks

[13:47:25.0000] <Domenic_>
hmm interesting css 2.1 base spec is still useful for things?

[13:47:53.0000] <SimonSapin>
yes, many parts of it do not yet have a level 3 equivalent

[13:48:04.0000] <TabAtkins>
Yeah, we obsolete parts as we write specs to replace them.

[13:48:11.0000] <TabAtkins>
Until then 2.1 is still authoritative.

[13:48:14.0000] <Domenic_>
huh, interesting

[13:48:21.0000] <Domenic_>
Location: http://css3test.com/ Access has been blocked as the threat Mal/HTMLGen-A has been found on this website. O__o

[13:48:42.0000] <SimonSapin>
TabAtkins: are any parts explicitly obsoleted?

[13:48:55.0000] <SimonSapin>
I mean other by the existence of another document

[13:49:04.0000] <TabAtkins>
SimonSapin: No, unfortunately.  It would be nice to maintain such a list.  Perhaps in the snapshot.

[13:49:21.0000] <TabAtkins>
I expect we'll be publishing another one of those this year, since we have several specs in CR or Rec now.

[13:50:00.0000] <Ms2ger>
/me would just pull all the parts of css2 that are still relevant into modules and publish those as recs as-is

[13:50:15.0000] <SimonSapin>
interesting

[14:01:11.0000] <gsnedders>
Ms2ger: As CSS 3 modules?

[14:02:05.0000] <gsnedders>
https://github.com/html5lib/html5lib-python/issues/111 — is that expectation right?

[14:02:10.0000] <SimonSapin>
I we would still call them "Level 2", but as CSS modules yes

[14:02:27.0000] <gsnedders>
I'd just push them as CSS 3 FPWDs

[14:02:28.0000] <SimonSapin>
I think*

[14:02:41.0000] <gsnedders>
Lot less work to get them as FPWDs than RECs

[14:08:14.0000] <Hixie_>
TabAtkins: "technically" in what sense?

[14:08:29.0000] <Hixie_>
i don't understand your e-mail

[14:08:31.0000] <TabAtkins>
In "it's treated as replaced element by the spec".

[14:08:47.0000] <Hixie_>
which spec? the html spec doesn't, that's what bz was asking for

[14:08:50.0000] <TabAtkins>
But browsers treat it as something much closer to a normal element.

[14:09:05.0000] <TabAtkins>
Hmm, actually not quite sure.  Does HTML define other elements as replaced?

[14:10:18.0000] <Hixie_>
http://whatwg.org/html#replaced-elements

[14:11:01.0000] <TabAtkins>
I don't see *any* of the form controls here.

[14:11:37.0000] <cballenar>
whatup :)

[14:11:54.0000] <Hixie_>
TabAtkins: correct :-)

[14:12:34.0000] <SimonSapin>
Domenic_: IMO, the parts of CSS 2.1 that are still relevant are most of chapters 8 to 12, and appendix E. Everything else has a Level 3 spec that I consider "good"

[14:12:38.0000] <TabAtkins>
Well, that's definitely wrong.  Form elements have definitely been *considered to be* replaced elements, at least, for a very long time.  Browsers allow an inconsistent set of properties to affect them, though.

[14:12:56.0000] <cballenar>
@lilmonkey, I apologize for my attitude, I see what you meant, clearly the example I posed was incorrect and went against all good practices for the web.

[14:14:22.0000] <gsnedders>
SimonSapin: Not App H?

[14:14:36.0000] <cballenar>
lilmonkey: though u weren't exactly the easiest person to deal with… ok now i'm done… :)

[14:14:58.0000] <lilmonkey>
cballenar: if you have something to tell me, you can PM me. It is of no concern to this channel.

[14:15:23.0000] <cballenar>
i never use IRC, this thing still confuses the hell out of me…

[14:15:44.0000] <SimonSapin>
gsnedders: Appendix H? That doesn’t seem to exist…

[14:15:58.0000] <gsnedders>
SimonSapin: Go to App G and press next. It exists.

[14:16:16.0000] <SimonSapin>
oh

[14:16:22.0000] <Hixie_>
TabAtkins: well, buttons are just inline-block elements. similar things apply to some of the others.

[14:16:37.0000] <SimonSapin>
well, we probably don’t need to make a new L3 spec for this one :)

[14:16:47.0000] <gsnedders>
Hixie_: We don't care about parse errors that can only be hit in the scripting enabled case, do we?

[14:16:57.0000] <gsnedders>
Hixie_: Given they cannot be checked by a conformance checker.

[14:17:19.0000] <gsnedders>
Hixie_: Unless, of course, it has solved the halting problem. :)

[14:17:32.0000] <Hixie_>
gsnedders: you can report such errors in a js console

[14:17:46.0000] <gsnedders>
Hixie_: I am aware.

[14:17:50.0000] <Hixie_>
so we care

[14:18:26.0000] <gsnedders>
Hixie_: You don't define "control character" anywhere.

[14:19:47.0000] <rniwa>
wycats: yt?

[14:19:53.0000] <Hixie_>
gsnedders: is it used in a normative sense?

[14:20:16.0000] <Hixie_>
ah, yes

[14:20:17.0000] <Hixie_>
it's a term from unicode

[14:20:17.0000] <gsnedders>
"must not contain control characters other than space characters", phrasing content.

[14:20:22.0000] <gsnedders>
Yes, obviously.

[14:21:31.0000] <gsnedders>
Just whether you care about defining it explicitly.

[14:21:46.0000] <gsnedders>
(Presumably to be all characters in Gc C*)

[14:21:51.0000] <gsnedders>
(Or just Cc?)

[14:22:21.0000] <gsnedders>
Cc is control.

[14:24:53.0000] <Hixie_>
yeah working on it

[14:27:10.0000] <Ms2ger>
SimonSapin, you knew that people spent time to make sure the first letters of the appendix titles matched up, right? :)

[14:27:31.0000] <gsnedders>
SimonSapin, Ms2ger: it is rather obvious given how contrived they end up.

[14:27:40.0000] <gsnedders>
(Sorry Hixie)

[14:27:54.0000] <Ms2ger>
Yeah... I mean, "Elaborate description"?

[14:28:01.0000] <Hixie_>
well, it _is_ elaborate

[14:28:11.0000] <Hixie_>
the most telling sign is the lack of an "H" appendix

[14:28:15.0000] <gsnedders>
Well, yes. But you'd still not ordinarily call it that.

[14:28:26.0000] <Hixie_>
IT IS ELABORATE.

[14:28:35.0000] <Ms2ger>
/me pats Hixie_ on the back

[14:28:52.0000] <SimonSapin>
Ms2ger: I did not

[14:28:55.0000] <gsnedders>
Hixie_: So is the HTML parser. Rename that to the Elaborate description of the HTML Parsing algorithm.

[14:29:02.0000] <gsnedders>
/me awaits the next commit

[14:29:48.0000] <SimonSapin>
I got involved after 2.1 became REC

[14:30:31.0000] <SimonSapin>
that probably explains why appendix E is an appendix at all, although it seems like a bad reason

[14:31:53.0000] <Hixie_>
it was an appendix before the naming joke started

[14:32:07.0000] <Hixie_>
gsnedders: the html spec has lots and lots of jokes, doesn't need to copy css' :-)

[14:34:33.0000] <gsnedders>
Are there any Cc characters outwith latin1?

[14:35:28.0000] <SimonSapin>
http://www.fileformat.info/info/unicode/category/Cc/list.htm says no

[14:35:29.0000] <Hixie_>
no

[14:35:29.0000] <Hixie_>
they're C0 and C1 and that's it

[14:35:45.0000] <gsnedders>
Right, okay.

[14:38:55.0000] <wycats>
rniwa: what's up?

[14:39:03.0000] <rniwa>
wycats: hi

[15:08:33.0000] <gsnedders>
Wait, I should be submitting bugs, not emails, shouldn't I? Not that Hixie cares.

[15:11:15.0000] <gsnedders>
jgraham: Does html5lib need to match the current spec for 1.0?

[15:11:21.0000] <gsnedders>
/me votes no

[15:11:25.0000] <gsnedders>
For the sake of shipping.

[15:14:10.0000] <Hixie_>
gsnedders: bugs and e-mails are equivalent for html

[15:14:14.0000] <Hixie_>
just don't do both

[15:14:25.0000] <zewt>
it's like crossing the streams

[15:16:24.0000] <gsnedders>
:)

[15:16:52.0000] <gsnedders>
Also, we should totally make expected behaviour clearer for when the input stream is a sequence of Unicode codepoints.

[15:17:11.0000] <gsnedders>
e.g., parsing a unicode string in most modern languages.

[15:17:13.0000] <Hixie_>
i thought we did that recently

[15:17:18.0000] <gsnedders>
Did we?

[15:17:23.0000] <gsnedders>
It's better, but not entirely clear.

[15:17:25.0000] <Hixie_>
there's a new section or something

[15:17:27.0000] <gsnedders>
Will look later.

[15:26:10.0000] <MikeSmith>
anybody know what people normally use for parsing json in java? I see there's a javax.json but that seems to be separate jsr

[15:26:35.0000] <zewt>
Hixie_: are you still going through the "blurry lines" thread? my suggestion was essentially to allow optional pixel snapping (as well as a way to make pixel alignment easier), without making it the default and screwing up animations

[15:27:00.0000] <Hixie_>
i just replied to that entire thread

[15:27:03.0000] <zewt>
(i made an attempt at describing how the actual mechanics would work, but I don't know enough about the details of canvas paths, so it's probably not a very good attempt)

[15:27:09.0000] <Hixie_>
pixel snapping just makes things ugly

[15:27:27.0000] <zewt>
well, you asked how exactly we want it to work, and I already gave one answer to that

[15:28:57.0000] <zewt>
depends on what you're rendering; it definitely shouldn't be the default

[15:28:59.0000] <Hixie_>
i didn't see anything in the thread that was detailed enough to count as an answer :-)

[15:32:05.0000] <zewt>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0342.html i think any more detail than that would be getting ahead of the discussion

[15:32:48.0000] <zewt>
(i don't know enough about canvas paths or implementations to know if it's a direction even worth following in any more detail)

[15:34:56.0000] <zewt>
afk


2013-09-06
[17:00:46.0000] <Hixie_>
zewt: "causes coordinates to be snapped to integers" is just a fancy way of saying "pixel snapping".

[17:09:19.0000] <zewt>
Hixie_: well yes, since that's the whole point :)

[17:10:50.0000] <gsnedders>
Oooh! Producivity win! Nabbed one of the (few) desks at SFO.

[17:13:06.0000] <zewt>
it's probably true that it's only really useful with rectangles, like borders and backgrounds of boxes (though it also works with rectangles with rounded corners, etc)

[17:13:47.0000] <zewt>
(it shouldn't cause problems with things like circles, but it isn't helpful either)

[17:15:33.0000] <Hixie_>
there's an entire api of stuff. you don't know when drawing a moveTo() command if the next thing is gonna be a line or an arc. you don't know whether it's going to be rotated or scaled or what.

[17:15:38.0000] <Hixie_>
so

[17:15:42.0000] <Hixie_>
it would need much more detail

[17:17:11.0000] <zewt>
well the point of the way I tried to picture it was to avoid having to know or care where the coordinates are going, and the snapping happens after the transform so rotations and scales are applied

[17:20:37.0000] <zewt>
(but like I said, there's a lot of Canvas I don't know about and that only handles the simple "call moveTo() or rect() and draw immediately" cases--for example, I don't know anything about Path objects--so I acknowledge the chances of that being a practical solution in general are small)

[17:21:11.0000] <Hixie_>
so it snaps all coordinates? even, like, arcs?

[17:22:04.0000] <zewt>
sure, because it's only snapping the "initial" coordinates--the ones you pass to the API (after the transform), not the coordinates of the stuff that gets drawn (like the individual pixels or slices or whatever of the circle)

[17:22:55.0000] <zewt>
(it could be selective as to which commands it's actually applied on; no real sense in preventing fractional circle radiuses, after all)

[17:24:11.0000] <zewt>
i guess I don't know how it would work with Path objects, glancing over the API a bit; the transform when the path is ultimately drawn may be completely different, so snapping at the time you create the Path doesn't make any sense

[17:24:58.0000] <Hixie_>
i don't understand "the ones you pass to the API (after the transform)"

[17:25:04.0000] <Hixie_>
what api?

[17:26:49.0000] <zewt>
canvas path functions, eg. rect()

[17:29:19.0000] <zewt>
all values that are transformed (including line widths, or else it wouldn't work)

[17:31:28.0000] <zewt>
(i guess coordinates would need to be rounded to the nearest pixel center, not the nearest integer)

[17:32:50.0000] <Hixie_>
i don't understand what this means in practice in the canvas api.

[17:35:57.0000] <zewt>
if you have a scale of 0.5, and you call rect(11, 11, 3, 3), the top-left and bottom-right coordinates, after the transform, are (5.5, 5.5) and (7, 7); the rounding would happen at that point, to (5,5),(7,7), which is what would actually be used to render.

[17:37:06.0000] <zewt>
(or 5.5/7.5, if it's pixel-centered coordinates that are needed, which is probably the case)

[17:39:03.0000] <zewt>
i'm not sure I can explain it any better, and I'm pretty sure if you want to add pixel snapping to Canvas you don't actually need my help, but I'm happy to continue if wanted :)

[19:37:04.0000] <cabanier>
Hixie_: as zewt said, the coordinates are snapped so the initial draw fills a device pixel. (This is usually not an integer coordinate)

[19:39:07.0000] <cabanier>
Hixie_: the flash people told me that they're snapping the control points too but I don't understand why that's needed

[00:12:02.0000] <Ms2ger>
Hmm? gsnedders is in SFO?

[02:15:25.0000] <jgraham>
Ms2ger: Well probably not any more. If I had stolen a desk there I wouldn't hang around to get caught

[02:17:38.0000] <jgraham>
gsnedders: In which respect would we be non-compliant? In general I think shipping is good, and am more worried by the sanitizer thing, which maybe you have fixed, than precise compliance with the spec in recent changes or extreme adge cases

[04:02:10.0000] <Ms2ger>
Anyone feel like a bit of WebIDL spec wrangling?

[04:02:12.0000] <Ms2ger>
https://bugzilla.mozilla.org/show_bug.cgi?id=913417

[04:20:26.0000] <zcorpan>
Ms2ger:  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2510

[04:37:06.0000] <Ms2ger>
So now we get a bug about "document.createElement('select').__proto__ = {};" not working

[04:37:10.0000] <Ms2ger>
/me is baffled

[04:38:57.0000] <zcorpan>
i guess http://dev.w3.org/2006/webapi/WebIDL/#defineownproperty is the right section (for the first thing)

[04:41:25.0000] <zcorpan>
which should skip to step 4 for 'n' and window, i think

[05:46:44.0000] <zcorpan>
wonder why twitter censored this image for me https://twitter.com/BRIAN_____/status/375923038908211200

[05:48:26.0000] <tomasf>
NSA did it

[06:35:26.0000] <zcorpan>
are web-platform-tests PRs on w3c-test.org somewhere?

[06:35:46.0000] <zcorpan>
found it

[06:36:53.0000] <zcorpan>
319 isn't there yet

[06:41:15.0000] <darobin>
zcorpan: you want annevk's PR up there?

[06:41:20.0000] <darobin>
I don't think he's in the maintainers

[06:41:32.0000] <zcorpan>
darobin: ya

[06:42:25.0000] <darobin>
zcorpan: I mirrored it

[06:42:40.0000] <darobin>
I reckon we could trust that annevk guy

[06:43:06.0000] <Ms2ger>
Probably

[06:43:36.0000] <darobin>
I've added both annevk and zcorpan

[06:44:45.0000] <darobin>
zcorpan, annevk: this means that your PRs are automatically mirrored, and that you can always add a "w3c-test:mirror" comment to any PR to cause it to mirror

[06:45:00.0000] <Ms2ger>
And you can merge things, I assume

[06:45:26.0000] <darobin>
please make sure that the PRs you authorise do not contain untrusted executable code, typically PHP

[06:45:35.0000] <darobin>
yeah, and other adminy stuff

[06:45:57.0000] <zcorpan>
i thought PHP wasn't synced automatically?

[06:47:39.0000] <zcorpan>
darobin: thx

[06:50:49.0000] <darobin>
zcorpan: the new system is that PRs by trusted people, or vetted by them with the special magic comment, are synced; others aren't

[06:51:03.0000] <zcorpan>
darobin: i see

[06:51:04.0000] <jgraham>
It isn't really easy to not sync PHP automatically

[06:51:10.0000] <jgraham>
Although I guess we could

[06:51:18.0000] <jgraham>
Anyway this system works at the moment

[06:51:33.0000] <darobin>
yeah it works

[06:51:35.0000] <zcorpan>
yeah i'm not arguing either way

[06:51:50.0000] <darobin>
well, apart from the bit where I always have to look at old PRs to remember what the magic comment is :)

[06:58:24.0000] <jgraham>
I just look at the source code :p

[07:19:45.0000] <annevk>
Trust me? Muhahaha

[07:24:06.0000] <Ms2ger>
Oh dear

[07:24:13.0000] <Ms2ger>
What have we done...

[07:25:46.0000] <annevk>
zcorpan: so euh. I think generic utility features that unravel tricky CSS bits, such as CSS escapes, is basically a win

[07:26:12.0000] <annevk>
zcorpan: I guess figure out if they're relatively cheap to add first, but if so, I tend to think we should expose more of those primitives

[07:28:04.0000] <zcorpan>
annevk: sure, but it's still useful to know what the use cases are. for instance, do we also need an API to unescape?

[07:28:39.0000] <zcorpan>
do we need an API to convert between a quoted and unquoted font-family name?

[07:30:34.0000] <annevk>
maybe a toCSSString() or some such

[07:30:45.0000] <annevk>
but yeah, fair enough

[07:32:27.0000] <jgraham>
odinho: http://w3c-test.org/web-platform-tests/master/IndexedDB/submissions/Opera/invalid/idbfactory_deleteDatabase.htm huh?

[07:32:43.0000] <jgraham>
Can these files be deleted?

[07:33:26.0000] <Ms2ger>
odinho, and can you review all the idb tests? :)

[07:49:08.0000] <annevk>
The patience of hsivonen explaining to people why sniffing for utf-8 is a bad idea is something to be greatly admired.

[07:49:37.0000] <Ms2ger>
hsivonen in general

[07:50:55.0000] <zewt>
(sniffing has its places, as long as it's strictly defined; for example, it may be hard to avoid for ZIPs)

[07:51:55.0000] <wilhelm>
Does Mozilla have any statistics on how often Firefox features are used? (I'm wondering whether anyone uses the 'zoom text only' feature.)

[07:52:25.0000] <annevk>
zewt: I don't think anyone disagrees there

[07:52:34.0000] <annevk>
Ms2ger: true

[07:52:40.0000] <zewt>
i use that a lot (zoom text makes things a lot easier to read, but zooming images makes everything blurry)

[07:52:49.0000] <Ms2ger>
wilhelm, we can get that set up

[07:56:47.0000] <wilhelm>
Ms2ger: That would be very interesting. The reason for why I'm wondering is this: Using media queries, I essentially have four different designs for sites I'm building. I have a 4-column, 3-column, 2-column and 1-column design. They sort of map to the screen sizes of a laptop, a landscape tablet, a portrait tablet and a phone. If you zoom in with the normal page zoom, the page magically reformats to fit your screen. A zoomed page on a laptop may ...

[07:56:53.0000] <wilhelm>
... give you the 2-column layout, which is readable and nice.

[07:57:06.0000] <wilhelm>
If you use the "zoom text only" feature, you're screwed with this approach.

[07:57:41.0000] <Ms2ger>
hsivonen has set up something like that for the encoding override menu, I suppose he can give pointers

[07:58:54.0000] <wilhelm>
Ooh.

[07:59:37.0000] <wilhelm>
hsivonen: I'll buy you a case of beverages of your choice in exchange for information here. (c;

[08:03:59.0000] <wilhelm>
zewt: Do you try the other zoom first, or do you go straight for text zoom? Do you have any trouble with it?

[08:05:08.0000] <hsivonen>
wilhelm: http://telemetry-dash.mozilla.org/

[08:05:18.0000] <hsivonen>
wilhelm: I don't see a variable for that in the middle menu

[08:05:23.0000] <zewt>
i don't fiddle much with zoom on a per-site basis, it's not too uncommon for it to do odd things to layouts though

[08:05:25.0000] <hsivonen>
wilhelm: could be added

[08:06:00.0000] <hsivonen>
wilhelm: http://mxr.mozilla.org/mozilla-central/search?string=gatherCharsetMenuTelemetry for example code

[08:06:39.0000] <hsivonen>
(afk)

[08:07:27.0000] <wilhelm>
hsivonen: Oh, interesting.

[08:58:37.0000] <annevk>
Using Bugzilla for issue tracking in standards is so useful.

[08:59:57.0000] <Ms2ger>
^

[09:10:00.0000] <annevk>
marcosc: you seem to have your bugmail turned off, I just resolved one of your bugs: https://www.w3.org/bugzilla_public/show_bug.cgi?id=22336

[09:10:30.0000] <jgraham>
I love tests that play audio

[09:10:39.0000] <marcosc>
annevk: strange... I get bugmail everyday

[09:13:12.0000] <marcosc>
annevk: go to fetch (http://fetch.spec.whatwg.org/), and hit print preview.

[09:13:23.0000] <marcosc>
Then you might appriciate the problem at bit ;)

[09:34:33.0000] <Ms2ger>
RESOLVED MOVED?

[09:42:23.0000] <annevk>
Ms2ger: made sense to me

[09:42:34.0000] <annevk>
Ms2ger: no idea what it's for though

[09:43:04.0000] <marcosc>
RESOLVED MOVED: "you resolved it by making someone else's problem"

[09:43:11.0000] <marcosc>
I like that :)

[09:48:27.0000] <jsbell>
I want one of Hixie's imaginary displays with rotating pixels.

[09:53:12.0000] <annevk>
So in http://wiki.whatwg.org/wiki/FormData if you do fd.append("tralal", blob); and then x = fd.get("tralal"); x != blob depending on whether blob is a Blob or a File

[09:53:38.0000] <jgraham>
Hmm, it would have been really nice if the whole treeview thing had happened

[09:53:52.0000] <annevk>
That seems bad for a map-like

[09:54:12.0000] <annevk>
Although I guess you also get that for URLQuery if you pass in something that's then toString()'d

[09:54:16.0000] <annevk>
So maybe it's okay...

[09:54:33.0000] <annevk>
jgraham: whole treeview thing?

[09:59:42.0000] <annevk>
So... Surrogates, how do you work with FormData and multipart/form-data?

[10:01:32.0000] <jgraham>
annevk: There was a plan to have a tree-like datastructure in HTML

[10:01:36.0000] <jgraham>
It died

[10:01:46.0000] <annevk>
<datagrid>

[10:01:52.0000] <annevk>
?

[10:02:07.0000] <jgraham>
Yeah, that sounds right

[10:02:38.0000] <annevk>
http://blog.whatwg.org/this-week-in-html-5-episode-31 "This big news this week is the <datagrid> element. This is a brand spanking new element introduced in r2962."

[10:03:02.0000] <annevk>
There might be another entry mourning its demise, dunno.

[10:03:36.0000] <annevk>
Hah, <keygen> is the next bit of news, still there...

[10:06:43.0000] <zewt>
<keygen>? what next, <tetris>

[10:07:13.0000] <zewt>
<tetris> would make more sense, heh

[10:24:02.0000] <Domenic_>
do data URLs count as cross origin? O_o

[10:24:09.0000] <Domenic_>
I seem to have tainted my canvas by writing data URLs into it?

[10:24:38.0000] <annevk>
Domenic_: does that happen in Gecko or WebKit?

[10:24:44.0000] <Ms2ger>
WebKit, probably

[10:24:47.0000] <Domenic_>
annevk: webkit yeah

[10:24:53.0000] <Domenic_>
(blink)

[10:24:59.0000] <Domenic_>
fuuuu

[10:25:09.0000] <annevk>
Yeah they have a bug which they think is not a bug and we haven't resolved it one or another and it's annoying...

[10:25:26.0000] <Domenic_>
oh nooo

[10:25:52.0000] <Domenic_>
my html -> svg -> data URL -> img -> canvas -> do crazy pixellation effects on the canvas plan is falling apart

[10:26:08.0000] <annevk>
Recommend everyone to use Firefox -_-

[10:30:20.0000] <Domenic_>
ok new plan is html -> svg -> server HTTP handler -> same-origin SVG image -> canvas -> do crazy pixellation

[10:44:45.0000] <annevk>
Hmm, it seems like FormData might not need to care about "type" for form data set

[10:44:56.0000] <annevk>
It's only used by text/plain and application/x-www-form-urlencoded

[10:47:01.0000] <Domenic_>
oh damn

[10:47:14.0000] <Domenic_>
it's because http://www.w3.org/2000/svg is cross-origin

[10:54:05.0000] <GPHemsley>
/me also prints things in order to read/study them better

[11:26:11.0000] <Ms2ger>
Meaningless statistic of the day: "web-platform-tests took an estimated 84 years of effort"

[15:04:31.0000] <odinho>
jgraham: WAT, u no see the invalid folder? :P

[15:05:02.0000] <odinho>
jgraham: But yeah, it's basically just a dump of what I was currently having on my computer. Very bad form. But I just wanted to get it released there, so we could rather do the cleanup afterwards.


2013-09-07
[17:00:54.0000] <zewt>
cool, the last chrome update exposes window.Touch, which means Prototype detects it as a touchscreen browser, causing random breakage

[22:01:43.0000] <super_danik>
Hello. What is the best way to ask or discuss about improving some HTML spec?

[03:38:27.0000] <gsnedders>
jgraham: Believe we should ship with sanitizer fixed and another other API changes, without updating to latest spec. We are wrong most obviously wrt template.

[03:41:02.0000] <gsnedders>
And yes, Ms2ger, I was at SFO trying to escape the Bay Area.

[04:22:23.0000] <annevk>
gsnedders: interviews?

[04:24:16.0000] <gsnedders>
annevk: Nah, my gf lives out there now.

[04:26:08.0000] <annevk>
gsnedders: so why did you try to escape?

[04:26:27.0000] <gsnedders>
annevk: To get home.

[04:26:52.0000] <annevk>
;)

[04:27:18.0000] <gsnedders>
annevk: Also the stamp in my passport obliges me to do so.

[13:33:04.0000] <jgraham>
odinho: So can I delete those files?

[13:33:10.0000] <jgraham>
gsnedders: Sounds reasonable

[13:36:54.0000] <gsnedders>
jgraham: You may want to review stuff piece-meal. Because the end review will be huge. For the sanitizer, a least.

[13:37:02.0000] <gsnedders>
jgraham: And take a look through open reviews at some point?

[13:43:53.0000] <gsnedders>
jgraham: s/reviews/pull requests/

[15:38:47.0000] <odinho>
jgraham: Yea


2013-09-08
[02:45:16.0000] <jgraham>
gsnedders: OK

[02:45:21.0000] <jgraham>
odinho: OK

[04:30:25.0000] <odinho>
ok2k

[05:10:30.0000] <gsnedders>
jgraham: for html5lib-tests, opinion on whether to use rST, as we do in html5lib-python (though mostly because it is the Python norm), or whether to use Markdown (which seems to be more universal)?

[05:21:04.0000] <gsnedders>
jgraham: https://github.com/html5lib/html5lib-tests/pull/21

[08:29:40.0000] <jgraham>
gsnedders: rST for sure if we might use readthedocs

[08:29:52.0000] <jgraham>
Otherwise I don't have a strong preference

[08:30:13.0000] <jgraham>
MD is simpler and github likes it, but I don't like github and consistency is good

[08:30:27.0000] <Ms2ger>
HTML? :)

[08:30:55.0000] <jgraham>
Crazy talk :p

[09:22:37.0000] <Ms2ger>
annevk: would be nice if you could turn on critic emails (for DOM, at least)

[10:01:44.0000] <annevk>
Domenic_: https://bugzilla.mozilla.org/show_bug.cgi?id=911216

[13:21:53.0000] <Ms2ger>
Hmm, this http://crbugs.com link didn't go where I expected...

[13:37:47.0000] <Domenic_>
annevk: sweet, thanks

[13:40:40.0000] <Ms2ger>
annevk, ping

[13:42:28.0000] <matjas>
jgraham, gsnedders: rST is to formatting syntax as brainfuck is to programming languages

[13:43:35.0000] <Ms2ger>
So you're supporting rST?

[13:45:02.0000] <matjas>
well played, Ms2ger

[13:45:25.0000] <matjas>
research on default color for disabled form elements across various platforms: https://github.com/h5bp/html5-boilerplate/pull/1403#issuecomment-24028814

[13:46:04.0000] <Ms2ger>
matjas, I try :)

[15:25:22.0000] <annevk_>
Ms2ger: oh... tomorrow then

[16:37:19.0000] <Hixie_>
why do i still get a click if i cancel mouseup

[16:37:42.0000] <Hixie_>
and how can i figure out if the click i just got is related to earlier mousedown/mouseup events?


2013-09-09
[17:17:23.0000] <zewt>
because mouse events are dumb, and as far as I know you can't (reliably)

[17:17:57.0000] <zewt>
(other than unreliable hacks, like adding a click listener on mouseup and removing it in a timer)

[23:13:39.0000] <Hixie_>
zewt: i ended up just not bothering with click and doing all the work in mousedown/mouseup

[00:53:44.0000] <darobin_>
a browser validated in Coq, that's for jgraham http://goto.ucsd.edu/quark/

[01:01:45.0000] <Ms2ger>
MikeSmith, so, actually, I didn't want a keyword for "Indicates that a test case for this bug is included somewhere in the bug report.", I wanted one for "has a test in the test suite"

[02:08:22.0000] <annevk>
Ms2ger: pong

[02:09:54.0000] <Ms2ger>
annevk, I was looking at http://dom.spec.whatwg.org/#concept-node-replace-all...

[02:10:35.0000] <Ms2ger>
Step 5 queues a mutation record with addedNodes and removedNodes set

[02:10:55.0000] <Ms2ger>
But those seem to be only used if "addedNodes, removedNodes, previousSibling, and nextSibling are given"

[02:11:39.0000] <annevk>
Also, step 4 sets it to null rather than the empty list, that might be wrong too, no?

[02:11:49.0000] <Ms2ger>
Well, this was my first issue :)

[02:12:49.0000] <Ms2ger>
"node's children" in the DocumentFragment case in step 4 is going to be empty after step 3

[02:13:12.0000] <Ms2ger>
And "parent's children" in step 5 are the new nodes by that point

[02:15:14.0000] <annevk>
Ms2ger: so let's see; in http://dom.spec.whatwg.org/#queue-a-mutation-record 4.3 we want to split that up in four distinct steps to set the properties properly

[02:16:04.0000] <Ms2ger>
So it's supposed to mean "for each that's given, set it"?

[02:16:17.0000] <Ms2ger>
Makes sense

[02:16:48.0000] <annevk>
Ms2ger: yeah, maybe word it that way

[02:17:29.0000] <annevk>
Ms2ger: and then a bunch of variable re-ordering in replace-all

[02:17:35.0000] <Ms2ger>
Yep

[02:17:42.0000] <Ms2ger>
And that null thing

[02:18:06.0000] <annevk>
What a mess

[02:47:30.0000] <annevk>
Ms2ger: fixed I think

[02:47:45.0000] <Ms2ger>
Thanks, will check in a bit

[03:02:34.0000] <jgraham>
Anyone able to contact Lachy? It would be nice to know if there's a reason for /selectors-api/tests/submissions/Opera/level1/*

[03:02:41.0000] <jgraham>
In web-platform-tests

[03:07:16.0000] <jgraham>
Well they diff identical so I think I am happy to remove them

[03:07:34.0000] <jgraham>
(identical to tests not under submission/)

[03:08:14.0000] <Ms2ger>
r=me

[03:18:31.0000] <jgraham>
Hmm, I seem to be typing "blink" and wondering why it doesn't launch chrome[ium]

[03:48:01.0000] <annevk>
So if you have an object that represents a list of name/value pairs. Would you still expose getNames() and getValues() or would you just have an iterator that returns {name, value} objects?

[03:49:26.0000] <jgraham>
In what context?

[03:49:50.0000] <annevk>
API design

[03:50:17.0000] <jgraham>
API Design isn't a single thing

[03:50:30.0000] <jgraham>
Do you mean web API or some other type of API

[03:51:59.0000] <annevk>
Seems Map has entries(), keys(), values()

[04:04:17.0000] <annevk>
So we should have some kind of consistent design between URLQuery and FormData

[04:05:12.0000] <annevk>
FormData needs to deal with Blob+filename->File/File. URLQuery needs to deal with being created from a string

[04:07:41.0000] <annevk>
Maybe http://url.spec.whatwg.org/#interface-urlquery should instead have set / setAll / delete / deletaAll

[04:07:47.0000] <annevk>
The current workings are a bit inconsistent...

[04:09:37.0000] <annevk>
(setAll would set the first one and remove the rest)

[04:11:25.0000] <annevk>
Or maybe the API should be simpler...

[04:11:40.0000] <annevk>
get() returns a sequence always. append() always appends. delete() removes all always.

[04:11:51.0000] <annevk>
and set() doesn't exist.

[04:12:03.0000] <annevk>
and if set() would exist it'd do what setAll does

[04:35:22.0000] <darobin>
jgraham: I spoke to Lachy on Twitter over the weekend, so presumably he's reachable

[04:35:32.0000] <Lachy>
yo

[04:35:57.0000] <darobin>
look! he's even here

[04:36:08.0000] <darobin>
<jgraham> Anyone able to contact Lachy? It would be nice to know if there's a reason for /selectors-api/tests/submissions/Opera/level1/*

[04:37:01.0000] <darobin>
annevk: entries() is the only one you absolutely need, but having keys() and values() is often nice

[04:37:26.0000] <darobin>
but it's just sugar that saves you from having to make the list unique

[04:37:37.0000] <annevk>
darobin: if the object supports iteration you don't even need entries()

[04:38:04.0000] <darobin>
annevk: I didn't mean as necessarily a distinct method, just the functionality

[04:38:08.0000] <SimonSapin>
or just use an array?

[04:38:14.0000] <annevk>
darobin: you mean keys() and values() would be set(keys()) / set(values()) ?

[04:38:35.0000] <Lachy>
The level1 files were tests that only required selectors api level 1 to be implemented. The level 2 tests are intended to include the additional APIs like matches and find as well, though they are incomplete.

[04:39:07.0000] <darobin>
annevk: sorry, I'm not sure I get your question

[04:39:26.0000] <annevk>
darobin: the values returned by keys() and values() would be unique?

[04:39:42.0000] <darobin>
ah, that Set

[04:39:48.0000] <darobin>
yeah — otherwise what's the point?

[04:40:33.0000] <darobin>
a typical case for keys is e.g. when you need to generate a <select> in which people can pick something

[04:40:48.0000] <darobin>
and if the key maps to multiple values you just show multiple things

[04:40:50.0000] <darobin>
that sort of usage

[04:58:08.0000] <Lachy>
jgraham, if you were actually asking why they exist there as well as in the approved dir, it's just because they were put in submissions first before they reached the approved state. I suppose submissions/level1-* can be removed now.

[05:03:32.0000] <hsivonen>
Hixie_: www.whatwg.org is down

[05:04:16.0000] <hsivonen>
Is there a mirror of the spec somewhere?

[05:04:23.0000] <hsivonen>
Without W3C changes, that is.

[05:11:48.0000] <Ms2ger>
hsivonen, wfm

[05:12:06.0000] <hsivonen>
weird charset thing of the day: normal navigation in Firefox doesn't inherit charset from previous doc but open in new window tries to inherit

[05:12:25.0000] <hsivonen>
Ms2ger: weird. considering http://www.downforeveryoneorjustme.com/www.whatwg.org

[05:12:29.0000] <Ms2ger>
hsivonen, but https://github.com/whatwg/html-mirror should be up-to-date, I think

[05:12:43.0000] <hsivonen>
Ms2ger: thank

[05:12:45.0000] <hsivonen>
s

[05:12:50.0000] <Ms2ger>
Np

[05:14:04.0000] <hsivonen>
so the spec says not to inherit from the previous doc

[05:14:23.0000] <hsivonen>
which means that Gecko inheriting on POST and on Open in New Window is bogus

[05:15:52.0000] <Ms2ger>
I'd agree with that, I think

[05:16:36.0000] <Ms2ger>
"Two of the top four New York Times Hardcover bestsellers this week were done with CSS."

[05:22:34.0000] <hsivonen>
Has anyone tested if other browsers inherit from the previous document when clicking normal links within the same origin?

[05:23:22.0000] <hsivonen>
I didn't want to be writing test cases for this.

[05:23:52.0000] <hsivonen>
aaargh. so much bogosity in this general area.

[05:24:10.0000] <hsivonen>
and more magic being proposed.

[05:24:47.0000] <Ms2ger>
Would be nice to have those test cases, though ;)

[05:34:15.0000] <jgraham>
Lachy: OK, thanks, I removed the submissions/ files

[05:37:24.0000] <hsivonen>
awesome. we're inconsistent between new tab and new window

[05:48:02.0000] <annevk>
hsivonen: I think basically you have to assume that there's no design and that we're responsible for creating a somewhat sensible design taking into account the constraints of deployed content

[05:49:55.0000] <annevk>
hsivonen: most of the browser engine is like HTML4 spec-era, not actually understood

[05:51:52.0000] <hsivonen>
Ms2ger: here you go http://hsivonen.iki.fi/test/moz/charset-inheritance/

[05:52:10.0000] <hsivonen>
annevk: Safari suggests Firefox is doing too much DWIM

[05:52:23.0000] <foolip>
annevk, does http://html5.org/tools/web-apps-tracker die together with whatwg.org?

[05:52:25.0000] <hsivonen>
annevk: I'll test a few IE versions and will come up with suggestions

[05:52:37.0000] <annevk>
foolip: yeah, queries svn.whatwg.org

[05:53:01.0000] <foolip>
annevk, does it still have that diff cache that needs to be thrown out periodically?

[05:53:08.0000] <annevk>
foolip: yeah :/

[05:53:35.0000] <annevk>
foolip: https://github.com/whatwg/web-apps-tracker has the code these days

[05:53:43.0000] <annevk>
foolip: though I suppose you still have direct access

[05:54:27.0000] <hsivonen>
http://hsivonen.iki.fi/test/moz/charset-inheritance/iframe.htm says utf-8 in IE10 on Windows 8 for me!

[05:54:31.0000] <foolip>
foolip, actually I've lost that ssh key

[05:54:57.0000] <annevk>
hsivonen: booting VMWare

[05:55:26.0000] <foolip>
annevk, I've thought from time to time that web-apps-tracker could be converted to use a local git repo and be faster+smaller

[05:55:39.0000] <annevk>
foolip: if you want I can set you up again

[05:55:41.0000] <foolip>
but apparently I've had other things to do

[05:56:32.0000] <annevk>
hsivonen: windows-1252 on Windows 7 / IE10

[05:56:48.0000] <hsivonen>
annevk: that's surprising, too!

[05:57:06.0000] <hsivonen>
annevk: Safari and Firefox say windows-1251

[05:58:02.0000] <annevk>
hsivonen: Chrome on Windows does windows-1251 too

[05:58:26.0000] <hsivonen>
Chrome agrees with Safari in all those test cases, it seems

[05:58:41.0000] <hsivonen>
time to boot some XP VMs!

[06:00:34.0000] <annevk>
Almost seems like IE defaults to their default encoding. But I hope that did not change to utf-8 in Windows 8?

[06:03:02.0000] <dsheets>
someone knows whatwg.org is down?

[06:03:19.0000] <annevk>
yeah

[06:06:03.0000] <dsheets>
/me checks logs and sees 1hr downtime... sorry for noise

[06:07:53.0000] <gsnedders>
jgraham: But we don't use readthedocs for html5lib-tests, only html5lib-python.

[06:08:08.0000] <hsivonen>
annevk: They didn't change their default on Windows 8 in the general case.

[06:08:33.0000] <hsivonen>
annevk: Now I have to check if the baseline assumptions hold. Even IE6 doesn't inherit in the iframe case

[06:08:40.0000] <gsnedders>
jgraham: And under the assumption people are most likely to read the README on github, Mardown works best

[06:09:04.0000] <jgraham>
gsnedders: I don't think I disagreed with that

[06:09:14.0000] <jgraham>
I said rST iff readthedocs

[06:09:22.0000] <annevk>
hsivonen: wow, if that's not needed that'd be so much better

[06:09:25.0000] <gsnedders>
That wasn't clear.

[06:11:24.0000] <hsivonen>
annevk: I added a baseline and the baseline works as expected in IE6.

[06:11:44.0000] <gsnedders>
jgraham: Also, any idea when you can look at reviews, at those from me? Esp. of html5lib-tests?

[06:19:38.0000] <jgraham>
gsnedders: Internet access is a bit problematic at the moment…

[06:25:06.0000] <foolip>
annevk, ok to s/HTML5/HTML/ in web-apps-tracker?

[06:25:14.0000] <gsnedders>
jgraham: That wonderful British thing o taking a month to activate a phone line that already exists?

[06:25:39.0000] <jgraham>
gsnedders: If I told you you wouldn't believe me

[06:25:49.0000] <gsnedders>
I probably would, sadly.

[06:26:10.0000] <annevk>
foolip: "HTML Standard Tracker" then

[06:26:17.0000] <foolip>
annevk, ok

[06:33:27.0000] <foolip>
it might amuse people to know that web-apps-tracker now has 22GB of diffs cached

[06:34:09.0000] <foolip>
annevk, are you going to TPAC? /me is

[06:36:23.0000] <annevk>
foolip: yeah

[06:37:05.0000] <annevk>
foolip: haven't really sorted out travel plans yet

[06:37:05.0000] <foolip>
cool, see you there then

[06:52:41.0000] <hsivonen>
Ah. I forgot to test the encoding that document.open()ed docs use for scripts and styles

[07:15:39.0000] <annevk>
hsivonen: okay so I can make it say utf-8 in Windows 7

[07:15:47.0000] <annevk>
hsivonen: fresh start, load http://hsivonen.iki.fi/test/moz/charset-inheritance/iframe.htm directly, get windows-1252

[07:16:17.0000] <annevk>
hsivonen: load http://hsivonen.iki.fi/test/moz/charset-inheritance/ click iframe.htm, get utf-8

[07:17:35.0000] <annevk>
hsivonen: baseline.htm seems to always give windows-1251

[07:19:23.0000] <hsivonen>
annevk: well. that's *weird*

[07:20:01.0000] <annevk>
hsivonen: one might call it a bug

[07:20:08.0000] <annevk>
hsivonen: maybe the same bullshit Gecko has

[07:20:16.0000] <zewt>
Hixie_: i've had to do that, it's tricky if i'm trying to actually mimic when click would normally happen though

[07:43:30.0000] <annevk>
https://twitter.com/jdfitzgerald/status/376998570001715200 but what is 3?

[08:42:46.0000] <GPHemsley>
annevk: (1) those who understand binary; (2) those who don't [understand binary]; (3) those who didn't expect this joke to be in base 3

[08:49:25.0000] <jgraham>
/me grumbles about people that make tests render stuff when there is no need

[08:49:44.0000] <Ms2ger>
Hmm?

[08:50:51.0000] <jgraham>
I'm just watching a bunch of tests falsh by that have a big formatted table and stuff, but only actually need the DOM

[08:50:56.0000] <jgraham>
*flash

[08:51:12.0000] <annevk>
GPHemsley: you didn't get my joke

[08:51:38.0000] <GPHemsley>
annevk: Nope.

[08:53:01.0000] <Ms2ger>
jgraham, oh, not the th.js output?

[08:54:04.0000] <jgraham>
No

[08:56:48.0000] <Hixie_>
sorry about down time

[08:56:51.0000] <Hixie_>
dunno what happened there

[08:56:55.0000] <Hixie_>
rebooted server though

[09:13:36.0000] <zcorpan>
annevk: yeah it would be more funny if it said "base 10"

[09:18:19.0000] <annevk>
It's kinda hard for base 3 to be part of the joke if the joke is actually in base 3, indeed.

[09:19:07.0000] <SimonSapin>
annevk: http://url.spec.whatwg.org#parse are the different parts of a parsed URL bytes or Unicode? And did I miss it in the spec?

[09:19:53.0000] <annevk>
SimonSapin: parser appends code points

[09:20:00.0000] <annevk>
SimonSapin: not entirely sure it's correct though

[09:20:32.0000] <SimonSapin>
code points that all happen to be in ASCII, right?

[09:20:41.0000] <annevk>
yeah, except fragment

[09:20:46.0000] <annevk>
fragment needs more research

[09:22:18.0000] <Hixie_>
btw, if anyone cares, i agree with those saying that getElementById() has a useful purpose and isn't something that querySelector() should replace.

[09:22:29.0000] <Hixie_>
querySelector() has its purpose too, but it's a different beast entirely imho.

[09:23:07.0000] <Jude>
Hello everyone, the link under Storage and files from platform.html5.org  is broken

[09:23:08.0000] <Jude>
http://www.w3.org/html/wg/drafts/html/master/offline.html#offline

[09:23:22.0000] <Jude>
the above link is broken

[09:23:34.0000] <Hixie_>
Jude: use http://whatwg.org/html#offline instead

[09:23:49.0000] <Hixie_>
(not sure why platform.html5.org is pointing to w3.org forks)

[09:24:16.0000] <Jude>
thanks for the info

[09:24:19.0000] <dglazkov>
good morning, Whatwg!

[09:24:51.0000] <gsnedders>
good morning, dglazkov!

[09:28:09.0000] <annevk>
Hixie_: what's wrong with first of #blah as selection mechanism?

[09:29:10.0000] <Hixie_>
all the things people have already said in the list

[09:29:20.0000] <Hixie_>
you have to escape it, it's not as fast, etc

[09:29:25.0000] <Hixie_>
it's ugly in code

[09:29:45.0000] <annevk>
So where do you stop?

[09:30:00.0000] <Hixie_>
where we ra enow seems fine

[09:30:02.0000] <Hixie_>
are

[09:30:09.0000] <jgraham>
I don't really have a problem with the existing DOM methods

[09:30:27.0000] <annevk>
Lots of people do though with getElements*

[09:30:43.0000] <annevk>
And especially with the objects they reeturn

[09:30:44.0000] <jgraham>
I have never really understood why CSS Selectors are the One True API

[09:30:44.0000] <Hixie_>
(i mean, i wish the method name was pithier and easier to type, but that's water under the bridge)

[09:30:48.0000] <annevk>
getElementById() might be okay

[09:31:01.0000] <Hixie_>
it's not like we can ever actually remove these apis

[09:31:03.0000] <annevk>
jgraham: just turned out that way

[09:31:15.0000] <Hixie_>
so why bother pretending we might

[09:31:30.0000] <jgraham>
annevk: That's sort of just a jquery limitation though

[09:31:37.0000] <zcorpan>
consider <div style="outline-style:initial">. should div.style.cssText say 'outline-style: none;' or 'outline-style: initial;' ? (not asking what the spec says, but what should happen in your opinion)

[09:31:51.0000] <annevk>
Hixie_: I don't think we're pretending that, we're just not putting them in new places

[09:31:52.0000] <jgraham>
Their design favoured a single API to do all things

[09:32:21.0000] <annevk>
jgraham: as I said in the thread, I'm not opposed to new better APIs for specific purposes

[09:32:21.0000] <Hixie_>
zcorpan: style[x].cssTest should say what was specified, imho, so 'initial'

[09:32:45.0000] <Hixie_>
annevk: oh ok, the thread sounded like you were down on them in general

[09:33:13.0000] <annevk>
Hixie_: well I am, because of their return values, which is why I don't want to spread them :)

[09:34:37.0000] <Hixie_>
getElementById()'s return value is fine

[09:34:39.0000] <gsnedders>
The problem with their return values doesn't go away unless we entirely get rid of them, which won't hpapen.

[09:35:01.0000] <annevk>
Hixie_: fair, torn on that one

[09:35:13.0000] <annevk>
gsnedders: all of that is true

[09:35:31.0000] <annevk>
gsnedders: and none of that was disputed

[09:36:05.0000] <gsnedders>
It means that return types are no reason to avoid proliferation

[09:36:33.0000] <zcorpan>
Hixie_: ok. i think that matches the spec (the keyword gets swapped for initial value at specified value time, but element.style doesn't do specified value but just expands shorthands and removes dups)

[09:36:38.0000] <annevk>
gsnedders: I disagree

[09:40:01.0000] <zcorpan>
annevk: are the return values still bad if [ArrayClass] succeeds?

[09:40:27.0000] <annevk>
zcorpan: [ArrayClass] is not on HTMLCollection

[09:40:39.0000] <Ms2ger>
zcorpan, also, named getter

[09:40:48.0000] <annevk>
zcorpan: iteration might improve matters a bit I suppose

[09:41:44.0000] <zcorpan>
annevk: is there a reason it can't be on HTMLCollection?

[09:41:57.0000] <annevk>
zcorpan: names getters

[09:41:59.0000] <annevk>
named*

[09:42:04.0000] <zcorpan>
ok

[09:42:17.0000] <annevk>
iteration can be though, I think

[09:47:19.0000] <zcorpan>
today i implemented http://dev.w3.org/csswg/cssom/#serialize-a-css-declaration-block in javascript to find my mistakes in my untested spec algorithm, but was surprised to find nothing but a typo. i was expecting infinite loops and bogus checks

[09:50:59.0000] <zewt>
nothing is scarier than complex code that works the first time

[09:58:29.0000] <zcorpan>
works the first time is what i meant. :-) but now i found a bug, so maybe there are bogus checks

[10:08:35.0000] <annevk>
TabAtkins: I'm not happy with the current design

[10:08:55.0000] <annevk>
TabAtkins: I'm happy to work out something better, but the current thing just feels inconsistent

[10:10:26.0000] <annevk>
TabAtkins: see also http://krijnhoetmer.nl/irc-logs/whatwg/20130909#l-316

[11:48:31.0000] <zcorpan>
heh, i've been debugging what was wrong in my code, it turned out i had forgotten to type ".length" in a for loop so it was always skipped

[12:25:48.0000] <zcorpan>
has anyone apart from annevk implemented the URL spec?

[12:26:14.0000] <Ms2ger>
Not afaik

[12:27:50.0000] <annevk>
zcorpan: I've had comments on tokenizer bits, and Node.js copied bits, but not straight up

[12:28:24.0000] <zcorpan>
ok. was wondering if there was an obvious candidate for reviewing https://critic.hoppipolla.co.uk/r/300

[12:30:12.0000] <zcorpan>
annevk: have you run the tests in multiple browsers and pondered about cases where all or most fail a certain test?

[12:30:39.0000] <annevk>
zcorpan: I've certainly pondered a fair bit over URLs

[12:30:58.0000] <annevk>
zcorpan: but I suspect others have different opinions on how I handled various cases

[12:32:56.0000] <zcorpan>
yeah, i know you have pondered over URLs, but that wasn't exactly what i asked :-)

[12:33:59.0000] <annevk>
zcorpan: sorry, I pondered over the results too, I used the tests to fix the specification and such

[12:34:08.0000] <zcorpan>
ok, cool

[12:34:30.0000] <annevk>
could certainly use scrutiny though I suppose

[12:36:47.0000] <Ms2ger>
zcorpan, so I'm happy to look at those tests some, but I have no opinion on what the results *should* be :)

[12:37:17.0000] <zcorpan>
Ms2ger: go ahead :-)

[12:37:55.0000] <Ms2ger>
But probably only when I get back from vacation

[12:41:27.0000] <zcorpan>
annevk: "Parsing: <http://f:b/c> against <http://example.org/foo/bar>	assert_equals: scheme expected ":" but got "http:"" is that right?

[12:42:08.0000] <annevk>
yeah, f:b would fail to parse

[12:51:01.0000] <zcorpan>
annevk: does it fail to parse in http://tools.ietf.org/html/rfc3490#section-4.1 ?

[12:51:27.0000] <annevk>
zcorpan: no it fails because :b is not a numeric port

[12:52:11.0000] <annevk>
zcorpan: url.spec.whatwg.org/#port-schem

[12:52:21.0000] <annevk>
zcorpan: http://url.spec.whatwg.org/#port-state sorry

[12:52:32.0000] <zcorpan>
ah yeah i saw it now

[12:55:06.0000] <zcorpan>
seems to fail to resolve in gecko

[12:56:17.0000] <zcorpan>
annevk: but the error message for expected-fail-to-resolve could be more obvious. maybe also the source data file could have a special thing to indicate expected parse failure?

[12:57:17.0000] <annevk>
":" seems clear

[12:57:23.0000] <annevk>
you can't get that any other way

[12:57:38.0000] <annevk>
well not clear, but yeah, we could build a message around that

[12:57:58.0000] <annevk>
I meant it's not needed in the source

[13:00:33.0000] <zcorpan>
yeah it's not needed, but it would be less cryptic :-) but a comment in the source might do the trick

[13:29:39.0000] <zcorpan>
hmm, though a dedicated field could be shown in the message. like http://f:b/ error:port-state

[14:43:54.0000] <Hixie_>
we need a RESOLVED LOOKSLIKESPAM in bugzilla

[15:39:14.0000] <jwalden>
is data:text/html;charset=UTF-8,<script>onerror=function(){alert('hi")};</script><script>var%20function;</script> supposed to alert, or no?  I think yes, if I'm reading the spec right, but Gecko at least doesn't right now

[15:39:53.0000] <Hixie_>
why would it not?

[15:40:02.0000] <Hixie_>
it's a syntax error, no?

[15:40:30.0000] <Hixie_>
are you trying to establish if it's a JS error, or if it's reported at the HTML level? :-)

[15:40:45.0000] <Hixie_>
note that 'hi" isn't valid

[15:40:46.0000] <jwalden>
it wasn't/isn't clear to me that the onerror hook should necessarily be triggered for syntax errors in scripts

[15:40:51.0000] <jwalden>
er, ugh

[15:40:57.0000] <Hixie_>
so i'm assuming your real test doesn't have that

[15:41:04.0000] <jwalden>
no, that was my real test :-)

[15:41:07.0000] <Hixie_>
ah

[15:41:08.0000] <jwalden>
explains things :-)

[15:41:09.0000] <Hixie_>
well then

[15:41:12.0000] <Hixie_>
i don't expect an alert :-)

[15:41:18.0000] <Hixie_>
several console messages though

[15:41:20.0000] <jwalden>
erm

[15:41:28.0000] <jwalden>
no, I get alert("hi") with that typo-fix

[15:42:00.0000] <jwalden>
data:text/html;charset=UTF-8,<script>onerror=function(){alert("hi")};</script><script>var%20delete;</script> for people following logs

[15:42:32.0000] <Hixie_>
yeah that should alert

[15:42:56.0000] <jwalden>
okay, this might be handy-ish then

[15:43:00.0000] <jwalden>
well

[15:43:12.0000] <jwalden>
handy *if* Gecko exposed the error object that was thrown

[15:43:15.0000] <jwalden>
which it doesn't

[15:43:26.0000] <jwalden>
or at least I remember strong complaints about it not doing so

[15:43:59.0000] <Hixie_>
the spec just changed to expose it

[15:44:03.0000] <Hixie_>
but that's new

[15:44:12.0000] <jwalden>
yeah

[15:45:00.0000] <jwalden>
(this use wouldn't care about CORS concerns, to be completely clear, so .error should always be there)

[15:55:51.0000] <zcorpan>
jwalden: why would it not care about CORS concerns? (what do you mean by that?)

[15:56:43.0000] <zcorpan>
/me -> sleep, will read logs tomorrow

[16:08:33.0000] <jwalden>
zcorpan: onerror fires with non-interesting error data ("muted errors") if "the script came from a resource that was fetched in the steps above, and the resource was CORS-cross-origin" per http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#execute-the-script-block 2.6.

[16:43:17.0000] <Hixie_>
hmm. so the high density stuff in canvas failed because people create canvases today expecting a 1:1 mapping.

[16:43:33.0000] <Hixie_>
i wonder if we can still provide a 1:n mapping if we just have a setting in the getContext call for it

[16:44:13.0000] <Hixie_>
e.g. a 'density' option, valid values being '1:1' and 'native'

[16:44:35.0000] <Hixie_>
and if it's native we can also just blow away the canvas when you zoom and fire an event letting you know you'd better repaint now


2013-09-10
[19:54:05.0000] <ghena1986>
http://bit.ly/183GBEv

[20:55:13.0000] <cabanier>
Hixie_: I don't think adding auto-resizing helps

[21:28:44.0000] <Hixie_>
cabanier: you don't think it helps with what?

[21:29:51.0000] <cabanier>
Hixie_: helping authors deal with HiDPI canvas

[21:30:08.0000] <Hixie_>
the idea is to help them not have to even think about it

[21:31:21.0000] <cabanier>
Hixie_: that would be nice but since many use temporary canvases, just changing the one in the DOM won't do

[21:31:43.0000] <Hixie_>
hmmm... interesting point

[21:31:57.0000] <Hixie_>
(that's maybe what you should have led with, rather than just "i don't think it helps" :-P )

[21:32:07.0000] <Hixie_>
we'd need a kind of "slave" mechanism

[21:32:24.0000] <cabanier>
Hixie_: what is that?

[21:32:49.0000] <Hixie_>
a way to say "this canvas is a slave of that one, wipe it and resize it accordingly when the other one gets resized"

[21:33:58.0000] <cabanier>
Hixie_: *thinking*

[21:36:07.0000] <cabanier>
Hixie_: I can see how that would help for certain scenarios, but there will be cases where you'd have to do it manually

[21:36:17.0000] <Hixie_>
sure, i said that in one of the e-mails

[21:36:25.0000] <Hixie_>
there's always going to be people who want crazy stuff

[21:36:34.0000] <Hixie_>
nobody's talking of removing anything that they can already do

[21:37:50.0000] <cabanier>
I

[21:38:36.0000] <cabanier>
I'd really want there to be a way for pinch-zoom to influence the dpi

[21:39:03.0000] <Hixie_>
why?

[21:39:19.0000] <Hixie_>
(not saying it's a bad idea, just curious as to your use case)

[21:39:43.0000] <cabanier>
well, as you zoom in, the canvas pixels just get blockier

[21:40:31.0000] <cabanier>
you'd have to write JS to deal with zooming

[21:40:53.0000] <Hixie_>
browsers don't let you pinch-zoom to more than 1 in-page CSS pixel per display CSS pixel, do they?

[21:41:02.0000] <Hixie_>
the idea is that JS can't see pinch zooming at all

[21:41:08.0000] <cabanier>
yeah

[21:41:12.0000] <Hixie_>
i'm confused

[21:41:43.0000] <cabanier>
you have to write JS to avoid blockiness in canvas if you pinch-zoom

[21:42:13.0000] <cabanier>
pinch-zoom does not affect the devicepixelratio

[21:44:55.0000] <cabanier>
your proposal deals with changes in devicePixelRatio and change in CSS pixels

[21:45:05.0000] <cabanier>
but not with pinch zoom

[21:46:19.0000] <cabanier>
- maybe we're miscommunicating wrt 'page zoom' -

[21:48:28.0000] <Hixie_>
"you have to write JS to avoid blockiness in canvas if you pinch-zoom" is false, as far as i can tell.

[21:48:48.0000] <cabanier>
?

[21:49:00.0000] <cabanier>
it's like zooming into an image.

[21:49:01.0000] <Hixie_>
<Hixie> browsers don't let you pinch-zoom to more than 1 in-page CSS pixel per display CSS pixel, do they?

[21:49:26.0000] <cabanier>
unsure

[21:49:40.0000] <Hixie_>
well if my statement is true, your statement is false

[21:49:48.0000] <Hixie_>
so if you're unsure about my statement, how can you be sure about yours :-)

[21:49:50.0000] <cabanier>
but you can have a lot of display pixels per CSS pixel

[21:50:43.0000] <cabanier>
so a 10x10 px canvas can fill the whole screen

[21:50:51.0000] <Hixie_>
not via pinch-zoom, though, right?

[21:51:13.0000] <Hixie_>
(assuming you're not articifically making it bigger than it should be)

[21:51:30.0000] <Hixie_>
maybe this conversation would be easier if we had a concrete example

[21:51:32.0000] <cabanier>
yes. pinch-zoom makes it bigger

[21:51:34.0000] <Hixie_>
can you put a test up i can test?

[21:51:45.0000] <Hixie_>
showing what you mean?

[21:52:05.0000] <cabanier>
sure. you will need a device that can pinch zoom

[21:52:22.0000] <Hixie_>
i am surrounded by them

[21:54:42.0000] <Domenic_>
i am pretty sure i can pinch zoom very far on most web pages, such that only a few words fit on the screen

[21:55:15.0000] <cabanier>
try https://developer.mozilla.org/samples/canvas-tutorial/2_4_canvas_arc.html and zoom in on the canvas in the top left

[21:55:44.0000] <cabanier>
Domenic_: yes, and as you zoom in, everything is rerendered so it stays sharp

[21:55:54.0000] <cabanier>
except images and canvas

[21:56:02.0000] <Domenic_>
right

[21:56:31.0000] <Domenic_>
i imagine if my font-size is 12px, by the time i zoom in very far, it's way more than 12px in size.

[21:57:05.0000] <cabanier>
Hixie_: in your mail: "when the display density changes size (e.g. due to page zoom)"

[21:57:24.0000] <cabanier>
Hixie_: did you mean pinch zoom, or pixelratio?

[21:57:49.0000] <Hixie_>
cabanier: i mean page zoom. command+/command- or ctrl+mousewheel or whatever.

[21:58:13.0000] <cabanier>
Hixie_: ah, OK so we're on the same page

[21:59:28.0000] <Hixie_>
ah, interesting, yeah, you can pinch-zoom to more than 100%

[21:59:29.0000] <Hixie_>
crazy

[21:59:30.0000] <Hixie_>
ok

[21:59:45.0000] <Hixie_>
well in that case we should just handle that the same way as page zoom.

[21:59:57.0000] <Hixie_>
and it should affect the device pixel ratio.

[22:00:02.0000] <Hixie_>
same as page zoom.

[22:00:16.0000] <cabanier>
no, it shouldn't :-(

[22:00:37.0000] <cabanier>
changing dpr would change the layout of the page

[22:00:49.0000] <cabanier>
which is not allowed to happen for pinch zoom

[22:01:27.0000] <Hixie_>
what?

[22:01:34.0000] <Hixie_>
changing the device pixel ratio doesn't affect the layout of the page.

[22:01:52.0000] <Hixie_>
(unless it also affects the width at the same time, as page zoom does)

[22:02:07.0000] <Hixie_>
(but then that's the width being changed that is affecting the layout)

[22:04:13.0000] <cabanier>
Hixie_: doing command +/- will cause reflow of text

[22:04:28.0000] <cabanier>
Hixie_: inline boxes will move

[22:04:51.0000] <Hixie_>
sure, because the page width is changing (in CSS pixels)

[22:04:58.0000] <Hixie_>
pinch zoom doesn't affect the page width.

[22:05:01.0000] <cabanier>
Hixie_: percentages stay the same, but boxes in CSS pixels will change size

[22:05:25.0000] <cabanier>
correct, pinch zoom does not affect anything today

[22:05:57.0000] <Hixie_>
well it affects the real device pixel ratio, it just doesn't get reported as doing so

[22:06:08.0000] <cabanier>
yes, that's true :-)

[22:06:44.0000] <cabanier>
it would be nice if one could find out about the real dpr

[22:07:03.0000] <cabanier>
http://stackoverflow.com/questions/995914/catch-browsers-zoom-event-in-javascript

[22:07:51.0000] <cabanier>
scratch that link, it's page zoom

[22:10:41.0000] <cabanier>
* going to bed *

[23:35:56.0000] <hsivonen>
has MS removed IE7 from Windows Update?

[23:36:25.0000] <hsivonen>
Windows Update doesn't offer it for me (on XP) when I have IE8 blocked using the command-line IE8 blocker

[01:42:56.0000] <MikeSmith>
Ms2ger: about [[I didn't want a keyword for "Indicates that a test case for this bug is included somewhere in the bug report.", I wanted one for "has a test in the test suite"]], yeah, understood

[01:43:09.0000] <MikeSmith>
so I can change the description

[01:43:26.0000] <Ms2ger>
That would be nice

[01:43:33.0000] <MikeSmith>
I'm happy to change the keyword too if you want

[01:44:28.0000] <Ms2ger>
Maybe that would be good... Either way

[01:51:22.0000] <MikeSmith>
Ms2ger: OK https://www.w3.org/Bugs/Public/describekeywords.cgi now updated with testcase-wanted="Indicates that this bug needs a test case in the test suite." and testcase="Indicates that this bug has a test case in the test suite."

[01:51:32.0000] <Ms2ger>
Thanks!

[01:52:28.0000] <MikeSmith>
I can change "testcase" to testcase-has or testcase-done or .. something

[01:53:51.0000] <MikeSmith>
Ms2ger: or has-testcase and needs-testcase (instead of testcase-wanted)

[01:54:28.0000] <Ms2ger>
Those would work

[01:55:13.0000] <MikeSmith>
zcorpan: if you're around I wanted to ask if you could be the reviewer for web-platform-tests/conformance-checkers tests

[01:56:42.0000] <MikeSmith>
Ms2ger: OK, changeed to has-testcase and needs-testcase https://www.w3.org/Bugs/Public/describekeywords.cgi

[01:58:13.0000] <MikeSmith>
hsivonen: if it's OK with you, this week I can change the validator build script to pull from the github repos instead of bitbucket

[02:00:25.0000] <Ms2ger>
MikeSmith, much appreciated

[02:23:12.0000] <zcorpan>
MikeSmith: sure

[02:23:29.0000] <MikeSmith>
zcorpan: OK, thanks

[02:24:09.0000] <zcorpan>
my critic filter is "/" so i should get emails for everything. not that i keep up, but...

[02:24:35.0000] <MikeSmith>
OK

[02:24:38.0000] <MikeSmith>
now I have a question for anybody about media-query syntax

[02:24:56.0000] <MikeSmith>
is "@media screen and (min-width: 400px) and(max-width: 600px) {}

[02:25:01.0000] <MikeSmith>
valid?

[02:25:28.0000] <MikeSmith>
is @media screen and (min-width: 400px)and (max-width: 600px) {} ?

[02:25:44.0000] <MikeSmith>
I mean the lack of whitespace around "and"

[02:28:01.0000] <MikeSmith>
I'm looking at http://www.w3.org/TR/css3-mediaqueries/#syntax and from that it seems like the whitespace around "and" is optional

[02:28:55.0000] <MikeSmith>
see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=23188

[02:29:51.0000] <zcorpan>
look at the editor's draft

[02:29:51.0000] <zcorpan>
i can't load it right now because the wifi is "horribly bad" here

[02:30:29.0000] <zcorpan>
iirc you can omit the space before but not after, because and( parses into a function

[02:30:38.0000] <MikeSmith>
zcorpan: ok

[02:30:41.0000] <zcorpan>
but i can't look it up. i remember discussing it on the list

[02:31:02.0000] <MikeSmith>
yeah, I find a Example 20 in the spec says, "The following is an malformed media query because having no space between ‘and’ and the expression is not allowed. (That is reserved for the functional notation syntax.)"

[02:31:03.0000] <zcorpan>
ok now the spec loaded

[02:31:35.0000] <MikeSmith>
but isn't that different from what the BNF says?

[02:31:48.0000] <MikeSmith>
/me looks at the ED

[02:32:12.0000] <MikeSmith>
"expression [ AND S* expression ]*"

[02:32:47.0000] <zcorpan>
ok so http://dev.w3.org/csswg/mediaqueries4/ says S+ AND S+ in the syntax

[02:35:53.0000] <zcorpan>
although the whitespace before *could* be omitted and still parsed correctly, it's required in the syntax. you could also omit the space after if you put in a comment in its place

[02:36:18.0000] <zcorpan>
since literal "and(" doesn't parse into an IDENT token it can't match the syntax even if it says the space is optional

[02:36:50.0000] <zcorpan>
i.e. and/**/( would parse correctly, but is not allowed in the current syntax, afaict

[02:47:08.0000] <MikeSmith>
zcorpan:  ok, thanks

[02:48:05.0000] <darobin>
zcorpan: can I steal your power source?

[02:54:01.0000] <Ms2ger>
One does not steal in such a palace

[02:58:07.0000] <jgraham>
You at the CSSWG meeting or something?

[02:58:52.0000] <zcorpan>
responsive images meeting

[02:59:15.0000] <jgraham>
Oh

[02:59:35.0000] <jgraham>
That makes more sense

[03:00:32.0000] <zcorpan>
csswg meeting is tomorrow

[03:02:02.0000] <jgraham>
That was one reason it made more sense

[03:02:16.0000] <jgraham>
But I know CSS like to have pre-meetings

[03:02:21.0000] <jgraham>
and after-meetings

[03:22:28.0000] <SimonSapin>
MikeSmith: http://www.w3.org/Style/2012/REC-mediaqueries-20120619-errata.html

[03:23:19.0000] <SimonSapin>
the problem is that and( tokenizes as a function

[03:23:45.0000] <SimonSapin>
so whitspace (or a comment, but nobody does that outside test cases) was effectively required there

[03:24:25.0000] <SimonSapin>
so we changed the grammar to not suggest that it is optional

[03:24:51.0000] <SimonSapin>
)and was changed as well, but just for symmetry

[03:28:11.0000] <Ms2ger>
/me wonders if there are tests

[03:28:33.0000] <SimonSapin>
good point

[03:30:02.0000] <annevk>
http://dev.w3.org/2006/webapi/WebIDL/#MapClass I wonder to what extent this has been coordinated outside of Tab / heycam

[03:30:18.0000] <Ms2ger>
I'd write some, but I don't want to deal with the csswg's bureaucracy

[03:34:09.0000] <SimonSapin>
Ms2ger, if you write them I can deal with the bureaucracy

[03:34:23.0000] <Ms2ger>
Bah

[03:34:33.0000] <Ms2ger>
You weren't supposed to say that :)

[03:34:44.0000] <SimonSapin>
:)

[03:35:14.0000] <SimonSapin>
I think this is the source file for the test suite http://hg.csswg.org/test/file/tip/approved/css3-mediaqueries/src/test_media_queries.html but I don’t know how #metadata_cache is supposed to work

[03:35:39.0000] <Ms2ger>
I know

[03:35:42.0000] <Ms2ger>
I wish I didn't

[03:35:48.0000] <SimonSapin>
uh

[03:36:11.0000] <Ms2ger>
It's commented out JSON that duplicates the arguments to test()

[03:42:40.0000] <smaug____>
annevk: in other words, you wonder if bz has reviewed that :)

[03:42:42.0000] <Ms2ger>
https://pastebin.mozilla.org/3015980?

[03:43:19.0000] <annevk>
smaug____: more public-script-coord I think

[03:45:51.0000] <annevk>
smaug____: e.g. whether it passes the "is this a good idea" test

[03:47:07.0000] <annevk>
smaug____: in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23189 are you saying you did not implement the specification? :/

[03:48:29.0000] <smaug____>
annevk: I did implement the spec

[03:48:35.0000] <smaug____>
but we could change the spec

[03:49:09.0000] <annevk>
smaug____: I see, the way you phrased that makes it sound like you think it behaves differently from how the specification says it is

[03:49:27.0000] <smaug____>
oh, indeed

[03:50:13.0000] <smaug____>
I shouldn't have commented so late

[03:50:40.0000] <annevk>
midnight is late these days? :p

[03:51:06.0000] <smaug____>
it was midnight utc

[03:51:23.0000] <annevk>
Fair enough :-) I guess I can figure out some phrasing for how this would alternatively work...

[03:51:32.0000] <MikeSmith>
SimonSapin: thanks for the info

[03:52:31.0000] <annevk>
I wonder if we should change the exception to be a JavaScript TypeError...

[03:54:14.0000] <MikeSmith>
Ms2ger: there are some media-queries-in-HTML tests in web-platform-tests/conformance-checkers/html/media-queries

[03:55:41.0000] <MikeSmith>
but I guess it would be better to use the tests from http://hg.csswg.org/test/file/tip/approved/css3-mediaqueries/src/test_media_queries.html for testing the validator too

[03:57:31.0000] <MikeSmith>
...though I find no tests there for checking case of lack of whitespace before or after "and"

[03:58:49.0000] <MikeSmith>
plus I guess those are parser tests for checking UA conformance and not document-conformance tests

[03:58:52.0000] <SimonSapin>
MikeSmith: yes, this a recent change and we still need to add tests for it

[03:58:59.0000] <MikeSmith>
ok

[04:01:15.0000] <annevk>
Did w3.org/Bugs really go down while I submitted a massive comment? So glad I copy and pasted that...

[04:01:32.0000] <annevk>
"504 Gateway Time-out"

[04:03:11.0000] <MikeSmith>
annevk: should probably let sysreq⊙wo know

[04:03:29.0000] <MikeSmith>
they just upgraded it to v4.4 on Thursday

[04:03:42.0000] <annevk>
MikeSmith: I think the thing is just down, can you get to it?

[04:03:59.0000] <MikeSmith>
I could just a few minutes ago

[04:04:04.0000] <MikeSmith>
/me tries again

[04:04:11.0000] <annevk>
Oh, it's back...

[04:04:26.0000] <MikeSmith>
yeah

[04:04:33.0000] <annevk>
It's kinda slow...

[04:04:45.0000] <annevk>
smaug____: care to review https://www.w3.org/Bugs/Public/show_bug.cgi?id=23189#c3 ?

[04:07:48.0000] <annevk>
Oh, you suggested something slightly different... You wanted no defaults for *OldValue...

[04:08:00.0000] <smaug____>
annevk: I think just passing attributeOldValue is enough to set attributes true

[04:08:13.0000] <annevk>
smaug____: same for characterData?

[04:08:17.0000] <smaug____>
right

[04:08:38.0000] <annevk>
smaug____: okay, so remove the defaults for those from the IDL too and just do a present check

[04:09:16.0000] <annevk>
smaug____: would it then make sense to have subtree presence imply childList?

[04:09:45.0000] <annevk>
darobin: ^^

[04:09:52.0000] <smaug____>
no

[04:10:26.0000] <smaug____>
subtree might as well imply attributes

[04:10:33.0000] <smaug____>
or characterData

[04:10:42.0000] <annevk>
aight

[04:11:02.0000] <smaug____>
hmm, "If attributeFilter is a non-empty array and attributes is false, throw a TypeError."

[04:11:16.0000] <smaug____>
does it need to be non-empty

[04:11:24.0000] <smaug____>
/me can't recall the current spec

[04:11:59.0000] <smaug____>
ah, the current spec requires non-empty, ok

[04:15:31.0000] <annevk>
I think to allow people to pass [] as default and not worry about it

[04:15:48.0000] <annevk>
however, if they pass [] as default and don't set attributes to false, attributes will become true with this new model

[04:16:20.0000] <annevk>
smaug____: so I think we should check for non-empty array before setting attributes to true, otherwise it's not quite compatible

[04:17:53.0000] <smaug____>
right

[04:18:46.0000] <smaug____>
empty array is still odd case

[04:19:03.0000] <smaug____>
it shouldn't create any Mutationrecords for attr changes

[04:20:00.0000] <smaug____>
hmm, thinking

[04:20:25.0000] <smaug____>
I guess gecko has a bug

[04:20:33.0000] <smaug____>
it checks the existence of the array

[04:20:43.0000] <smaug____>
which is better option, IMO

[04:20:50.0000] <smaug____>
than the length of the array

[04:21:57.0000] <annevk>
then you cannot have a default value for all init members that doesn't cause throwing

[04:22:04.0000] <annevk>
I don't see how that's better

[04:25:14.0000] <annevk>
smaug____: ^

[04:25:41.0000] <smaug____>
why should attributefilter have default value?

[04:26:21.0000] <annevk>
smaug____: it seems libraries often end up creating generic code that has default values for everything

[04:26:34.0000] <annevk>
smaug____: I guess you could still do undefined in that case...

[04:26:48.0000] <annevk>
Alright, undefined works for me

[04:32:07.0000] <annevk>
smaug____: in http://dom.spec.whatwg.org/#queue-a-mutation-record should it be a present check too then in step 3?

[04:32:45.0000] <smaug____>
looking

[04:33:16.0000] <smaug____>
yeah

[04:33:24.0000] <smaug____>
I think empty should just means empty

[04:33:35.0000] <smaug____>
you filter out all the attribute changes

[04:35:43.0000] <annevk>
alright, lunch...

[04:41:10.0000] <Ancil>
Hi

[04:42:25.0000] <Ms2ger>
http://what-if.xkcd.com/imgs/a/62/balloon_wolfram.png

[04:43:46.0000] <Ancil>
Should CORS be applied on a image with crossorigin="anonymous" only when image is used in Canvas

[04:44:42.0000] <Ancil>
should it be applied for when the image is used in without any canvas

[04:45:45.0000] <Ancil>
Firefox applies CORS for both the cases

[04:46:09.0000] <Ancil>
whereas Chrome does it only when image is used in a Canvas

[04:47:25.0000] <Ancil>
which is the correct behavior?

[04:48:41.0000] <Ancil>
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-crossorigin

[04:49:20.0000] <Ancil>
is the spec reference

[04:54:01.0000] <odinho>
Ancil: It should do a CORS then.

[04:54:32.0000] <odinho>
Ancil: Thing is, you can do   <img src=bla crossorigin>   and then later use that image in canvas. It'd be stupid to actually do a new fetch in order to check CORS status.

[04:55:12.0000] <odinho>
http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch

[04:55:31.0000] <odinho>
Read -> If mode is "Anonymous" or "Use Credentials"

[04:58:30.0000] <Ancil>
odinho: Okay, so whenever the crossorigin attribute is mentioned CORS rules should be applied irrespective of where its used

[04:59:21.0000] <odinho>
Ancil: You don't know where it'll be used.

[05:00:00.0000] <Ancil>
odinho: right

[05:02:16.0000] <Ancil>
odinho: Thanks

[05:05:09.0000] <annevk>
Ancil: Firefox is correct

[05:05:26.0000] <annevk>
Ancil: I think this might be a known bug in Chrome, but maybe report it just in case

[05:07:05.0000] <Ancil>
annevk: Thanks, will log a bug in Chrome

[06:02:48.0000] <hsivonen>
MikeSmith: wow. the bitbucket diff viewer is comically bad

[06:03:29.0000] <hsivonen>
MikeSmith: empty lines match and nothing else, so let's consider arbitrary empty lines as unchanged while the bits between the empty lines changes

[06:03:34.0000] <hsivonen>
*change

[06:04:15.0000] <MikeSmith>
hsivonen: yeah, that's among the things that bitbucket doesn't seem to be trying too hard at

[06:07:20.0000] <hsivonen>
MikeSmith: also, changing from spaces to tabs doesn't make diffs particularly fun

[06:07:40.0000] <MikeSmith>
yeah

[06:07:56.0000] <MikeSmith>
eclipse

[06:08:47.0000] <hsivonen>
isn't this configurable in Eclipse? I use Eclipse.

[06:10:10.0000] <hsivonen>
I wonder if I should give up trying to review individual change sets on bit bucket and if I should review a massive  diff that ignores whitespace

[06:10:57.0000] <hsivonen>
MikeSmith: are the changes from char[] to String headed somewhere? Those were char[] for a reason...

[06:12:44.0000] <MikeSmith>
hsivonen: I can'T see that those are headed anywhere, no. They seem like an arbitrary change he decided on his own.

[06:13:00.0000] <hsivonen>
MikeSmith: apparently this code isn't supposed to stay working after each changeset?

[06:17:20.0000] <MikeSmith>
hsivonen: after looking at that code more since the time when I pinged you about reviewing it, I am now really wondering myself if it's worth putting any more time into reviewing it

[06:17:36.0000] <MikeSmith>
I'm not sure it's solving any problem that we need solved

[06:19:05.0000] <MikeSmith>
which is part of the reason why in the mean time I wrote the code in validator/SimpleDocumentValidator.java

[06:19:55.0000] <MikeSmith>
that is, to expose an interface that does something similar to what this code seems to be trying to do

[06:20:10.0000] <Ancil>
odinho: annevk: Chrome checks for the image during rendering it. If a image is fetched with crossOrigin attribute. And  if the CORS check fails, then it renders the image when used without canvas and doesn't render it when used within canvas in the same html

[06:20:31.0000] <MikeSmith>
but to do it without refactoring huge swathes of existing code that we otherwise have no need to touch

[06:20:41.0000] <hsivonen>
MikeSmith: Is a problem with change sets or problem with big pockets that the bit bucket viewer shows moves as removals and additions in stone moves?

[06:21:12.0000] <Ancil>
annevk: so the Chrome behaviour also is acceptable. Isn't it?

[06:22:14.0000] <MikeSmith>
hsivonen: I think that's a problem with the way the code was reformatted, and bitbucket not dealing with that well

[06:22:17.0000] <Ancil>
annevk: odinho: doesn't fetch the image twice

[06:22:35.0000] <slartsa>
Yes this regards css not html, but does someone have knowledge about the current state of object-fit?

[06:23:51.0000] <hsivonen>
MikeSmith: whoa. whoa. does thing make the validator's output non-streaming?

[06:24:02.0000] <hsivonen>
https://bitbucket.org/bsdgabor/validator-refactoring/commits/49fca1a93cb43f3c25daa0fb7b352913525249b5

[06:24:24.0000] <hsivonen>
or is that code only used in the non-servlet case?

[06:25:04.0000] <MikeSmith>
/me looks

[06:27:21.0000] <MikeSmith>
hsivonen: that code is not only used for the non-servlet case, I think

[06:27:22.0000] <odinho>
slartsa: lastorset implemeted it in Presto.

[06:28:20.0000] <MikeSmith>
hsivonen: but another thing I need to mention to you is that the current code does not actually run with the servlet properly

[06:28:54.0000] <MikeSmith>
so that's clearly a show stopper regardless

[06:29:14.0000] <MikeSmith>
he has been working on trying to troubleshoot the problem but last I heard from him he had not fixed it

[06:49:24.0000] <hsivonen>
MikeSmith: the changes toward newer history suggest that  the servlet side hasn't been tested after each change during the refactoring. That scares me.

[06:53:24.0000] <MikeSmith>
hsivonen: yeah, as crazy as it might seem to say it, I don't think testing the servlet behavior is something he made a priority at all

[06:54:28.0000] <MikeSmith>
and when I agreed to help with this initially, I wasn't agreeing to do that testing for him

[06:56:13.0000] <MikeSmith>
hsivonen: really what it comes down to is, I was not the one who outlined the goals for him. That came from a member of the systems team who wants to have an API exposed that's not bound to the servlet.

[06:56:54.0000] <MikeSmith>
I agreed to help with questions about the existing code if had any

[06:57:05.0000] <MikeSmith>
but I never got any questions from him

[06:57:37.0000] <MikeSmith>
I just got essentially the same code you're looking at now too

[06:58:47.0000] <MikeSmith>
and meanwhile my colleague has done zero review of the code himself to even say whether it meets his needs or not

[07:00:09.0000] <MikeSmith>
so at this point I have lost whatever small amount of enthusiasm I may have ever had to for ever trying to help get it landed

[07:01:14.0000] <MikeSmith>
so I think it's probably not worth your time to try to figure out if it's workable or not, or how it could be make workable

[07:02:03.0000] <MikeSmith>
I'd been meaning to ping you to say I think you could hold off on the review

[07:02:41.0000] <hsivonen>
MikeSmith: ouch.

[07:03:03.0000] <hsivonen>
MikeSmith: well, I sent you email. I'll hold off attempts to diff the end state with the tip of the trunk, then.

[07:03:34.0000] <MikeSmith>
hsivonen: OK

[07:04:16.0000] <MikeSmith>
I'll look at what you sent already by mail and try to pass it on

[07:04:51.0000] <hsivonen>
MikeSmith: isn't GSoC supposed to ensure that there's a mentor? were you the assigned mentor or the person from the systeam

[07:07:08.0000] <MikeSmith>
I think we both were. But in hindsight I think it was a mistake for me to agree to be a mentor for a code project that was not scoped out to solve any problem that I needed solved.

[07:08:20.0000] <MikeSmith>
my intent was to be available to answer questions about the code and give some guidance about the best way to approach it for whatever the goal was

[07:08:52.0000] <MikeSmith>
but I never got any questions and never had much opportunity to give guidance

[07:09:17.0000] <hsivonen>
:-(

[07:09:48.0000] <hsivonen>
there is some good bits in there. But I can't just pull it all to the trunk without some confidence that it doesn't break the servlet side.

[07:22:41.0000] <annevk>
Ancil: yeah, that's a bug in how Chrome implements CORS

[07:23:03.0000] <annevk>
Ancil: if CORS fails it's to be treated as a network error

[07:23:08.0000] <annevk>
Ancil: rendering it is forbidden

[08:09:57.0000] <dglazkov>
good morning, Whatwg!

[08:30:30.0000] <say2joe>
hixie, I agree. my 2 pence.

[08:40:21.0000] <Hixie_>
agree with what? :-)

[08:55:45.0000] <zewt>
with whatever you disagree with

[09:01:07.0000] <annevk>
Domenic_: for some reason I'm not getting your later reply but I did get the one from Jonas...

[09:09:35.0000] <say2joe>
Hixie_: sorry… playing catchup to yesterday (i get a backlog in my IRC client). I was referring to your comments on getElementById

[09:13:35.0000] <Domenic_>
annevk: weird. well he quoted it in full so nothing lost i guess.

[09:14:03.0000] <annevk>
Domenic_: yeah, maybe some mail server delay, it's archived on w3.org too so I could read it there

[09:14:24.0000] <annevk>
Oh, just got it :)

[10:08:24.0000] <qtax^w>
i've read what i could find on "hgroup" but i found no "final" answer on the fate of this element. should it be avoided? is it still in whatwg html spec?

[10:09:00.0000] <qtax^w>
(i guess the answer to the last question is yes)

[10:09:14.0000] <Ms2ger>
Indeed

[10:09:25.0000] <Ms2ger>
So the answer to the first is "no"

[10:10:26.0000] <qtax^w>
hmm. i like it and would like to use it, but not sure since so much fuss about it

[10:10:55.0000] <jgraham>
I'm not really sure what the worst that can happen is

[10:10:58.0000] <Ms2ger>
Don't worry about the fuss, that's just the HTMLWG trying to assert authority they don't have

[10:11:30.0000] <jgraham>
Some future a11y tool fails to extract the perfect heading semantics from your page

[10:11:46.0000] <jgraham>
An outline generation tool gets stuff a bit wrong

[10:11:59.0000] <qtax^w>
well i'd like the possible (future?) implementations of outlining algorithms to work properly

[10:12:10.0000] <jgraham>
They don't seem like significant failure modes, though of course they would be nicer to get right

[10:13:49.0000] <qtax^w>
btw, are lower "rank" h\d tags valid before higher ranked ones in a hgroup?

[10:14:27.0000] <qtax^w>
eg <hgroup><h2>foo</h2><h1>bar</h1></hgroup>

[10:21:40.0000] <Hixie_>
qtax^w: <hgroup> is stable, implemented, and isn't going anywhere.

[10:22:06.0000] <qtax^w>
great

[10:39:04.0000] <SteveF>
<font> is stable implemented and is going anywhere

[10:42:31.0000] <Ms2ger>
It is?

[10:43:31.0000] <Hixie_>
don't feed the troll, Ms2ger

[10:44:06.0000] <Ms2ger>
I'm surprised it is going anywhere, apparently

[10:45:00.0000] <SteveF>
Ms2ger: thanks <font> is stable implemented and isn't going anywhere

[12:46:04.0000] <smaug____>
hmm, no anne

[14:47:10.0000] <Hixie_>
http://www.smashcompany.com/technology/ian-hickson-is-always-wrong-about-everything :-(

[14:52:57.0000] <jgraham>
Hixie_: That seems unlikely. Otherwise you would die the first time you tried to cross the street

[15:05:30.0000] <annevk>
smaug____: was getting food and such, gonna watch a series and sleep soon though

[15:07:47.0000] <smaug____>
annevk: it was just about http://logbot.glob.com.au/?c=content#c128978

[15:08:32.0000] <say2joe>
Damn, Hixie_ i didn't know people could be so wrong (sarcastic) lol

[15:10:38.0000] <say2joe>
you should reply… "how about them apples" (in reference to Mr. Krubner's work as an apple picker in an orchard as well as his "extensive" experience with Apple products / programming).

[15:11:06.0000] <annevk>
smaug____: ah yeah, you mentioned that before

[15:11:19.0000] <annevk>
I should get better at filing bugs I guess

[15:12:49.0000] <smaug____>
well, that is why some automatic tool might be good. In the case the spec change is significant, implementation bugs would be filed when committing the spec change

[15:13:39.0000] <smaug____>
hopefully wouldn't cause more work for spec authors

[15:15:20.0000] <annevk>
we could have a commit hook in GitHub I suppose

[15:15:49.0000] <annevk>
I guess Bugzilla has an API?

[15:16:11.0000] <annevk>
I could look into this I suppose, might be interesting for other browser projects too

[15:16:36.0000] <smaug____>
bugzilla has some API yes

[15:19:07.0000] <annevk>
I need an intern to do stuff like this :p

[15:28:14.0000] <jamesr_`>
if i'm reading things correctly the <dialog>'s UI always shows up in the top layer of the document the element is in, right?

[15:28:27.0000] <jamesr_`>
meaning if you have a <dialog> inside an <iframe> the dialog is constrained within the iframe?

[15:28:44.0000] <jamesr_`>
is there any way to break out?

[15:30:46.0000] <jamesr_`>
Hixie_: ^^ ?

[15:32:12.0000] <zewt>
wow, now even amazon has product listing items that are fake javascript links that i can't middle-click

[15:32:15.0000] <zewt>
ww3

[16:04:15.0000] <Hixie_>
jamesr_`: there's no way to break out of an iframe currently, right

[16:06:03.0000] <jamesr_`>
Hixie_: that means you can't use <dialog> as a clickjacking mitigation

[16:06:09.0000] <jamesr_`>
has there been much discussion about this?

[16:06:25.0000] <Hixie_>
jamesr_`: there's lots of things you can't use it for, sure

[16:06:49.0000] <Hixie_>
i don't think you'd ever be able to use it as a click-jacking mitigation -- i mean, there's no way we can allow a cross-origin iframe to break out of itself over a different-origin iframe

[16:06:53.0000] <Hixie_>
that's a huge spoofing risk

[16:07:03.0000] <Hixie_>
would just enable reverse clickjacking

[16:07:27.0000] <jamesr_`>
i get the spoofing concern although i'm not sure what reverse clickjacking is

[16:12:36.0000] <Hixie_>
the inner iframe click-jacking the outer frame

[16:12:56.0000] <Hixie_>
i.e. spoofing


2013-09-11
[18:39:53.0000] <jamesr_`>
zewt: you consider macbooks to be 'mobile' instead of 'desktop'?

[20:02:00.0000] <Yuhong>
Interestingly, Acid3 itself renders differently in real IE7 and IE8 in IE7 standards mode.

[20:06:22.0000] <Yuhong>
Interestingly, Acid3 itself renders differently between real IE7 and IE8 in IE7 standards mode.

[20:09:07.0000] <Yuhong>
Using IE developer toolbar in IE7 with Acid3 open I was able to easily crash IE7 with a null pointer.

[22:31:42.0000] <slartsa>
odinho: thanks, but I don't understand what you mean

[00:42:32.0000] <zcorpan>
annevk: ok i reviewed https://critic.hoppipolla.co.uk/r/300

[01:22:17.0000] <MikeSmith>
zcorpan: I don't find a definition of "whitespace" in http://dev.w3.org/csswg/mediaqueries4/

[01:22:31.0000] <MikeSmith>
SimonSapin: ↑

[01:22:57.0000] <zcorpan>
MikeSmith: look in css-syntax

[01:23:22.0000] <MikeSmith>
zcorpan: ok

[01:23:33.0000] <zcorpan>
but media queries should probably define its whitespace since they don't always come from a css file

[01:24:44.0000] <MikeSmith>
well it should also normatively reference some definition of whatever it means by it

[01:24:55.0000] <MikeSmith>
so I find http://dev.w3.org/csswg/css-syntax/#whitespace-diagram

[01:25:03.0000] <MikeSmith>
and http://dev.w3.org/csswg/css-syntax/#newline-diagram

[01:25:14.0000] <MikeSmith>
space, tabl

[01:25:16.0000] <MikeSmith>
oops

[01:25:58.0000] <MikeSmith>
space, tab, \n, \r\n, \r, \f

[01:26:18.0000] <MikeSmith>
zcorpan: which matches the definition in the HTML spec of whitespace, right?

[01:27:07.0000] <MikeSmith>
I find that the current media-queries checker in the validator doesn't allow \f

[01:27:32.0000] <MikeSmith>
oh wait

[01:27:40.0000] <MikeSmith>
http://dev.w3.org/csswg/css-syntax/#whitespace

[01:27:54.0000] <MikeSmith>
ah that's the same

[01:27:55.0000] <MikeSmith>
A newline, U+0009 CHARACTER TABULATION, or U+0020 SPACE.

[01:28:13.0000] <MikeSmith>
hmm, sorta

[01:28:18.0000] <MikeSmith>
http://dev.w3.org/csswg/css-syntax/#newline

[01:28:28.0000] <MikeSmith>
"U+000A LINE FEED. Note that U+000D CARRIAGE RETURN and U+000C FORM FEED are not included in this definition, as they are converted to U+000A LINE FEED during preprocessing."

[01:28:42.0000] <zcorpan>
question is what should happen with \f when the string comes from CSSOM

[01:28:58.0000] <zcorpan>
i'll file a bug on MQ

[01:29:15.0000] <MikeSmith>
OK

[01:29:29.0000] <zcorpan>
MQ currently refers to CSS21 for its grammar

[01:29:41.0000] <MikeSmith>
oh

[01:30:11.0000] <zcorpan>
S	[ \t\r\n\f]+

[01:31:32.0000] <zcorpan>
so i guess that makes it unambiguous

[01:31:46.0000] <MikeSmith>
yeah I like that a lot better actually

[01:35:53.0000] <zcorpan>
but this is something to keep in mind when css specs move to being defined in terms of css-syntax

[01:37:12.0000] <SimonSapin>
MikeSmith: I suppose it could link to http://www.w3.org/TR/CSS21/syndata.html#whitespace directly

[01:37:45.0000] <SimonSapin>
zcorpan: css-syntax-3’s pre-processing also applies to strings that come from CSSOM

[01:44:02.0000] <zcorpan>
SimonSapin: cssom refers to MQ for parsing a MQ, which in turn doesn't mention css-syntax, so that's not clear

[01:44:14.0000] <zcorpan>
we also have the case of HTML's media="" attribute

[01:45:17.0000] <zcorpan>
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#matches-the-environment also refers directly to MQ

[01:50:02.0000] <SimonSapin>
zcorpan: I mean if you’re using the tokenizer as defined in Level 3, the pre-processing always applies

[01:50:37.0000] <zcorpan>
yeah sure

[02:15:06.0000] <tantek>
hober, FYI https://wiki.mozilla.org/Standards/license

[02:23:21.0000] <TabAtkins>
Lots of things refer to 2.1 for grammar right now, because Syntax is just now hitting WD.

[02:23:32.0000] <odinho>
slartsa: It works in Opera 12. The presto-based line of Opera :)

[02:23:36.0000] <TabAtkins>
But you should interpret everything as if it was using Syntax, because that's what we're actually basing it all on.

[02:24:50.0000] <MikeSmith>
TabAtkins: ok, good to know

[02:29:04.0000] <MikeSmith>
zcorpan: so I have a minor issue in trying to automate testing of the validator, which is that if I test for U+000c being handled as whitespace, then we emit a warning saying, "This document is not mappable to XML 1.0 without data loss due to U+000c which is not a legal XML 1.0 character."

[02:30:08.0000] <MikeSmith>
and I can suppress that by telling my test runner to ignore warnings, but then it ignores all warnings

[02:30:29.0000] <MikeSmith>
and the warnings are something I want to test for too

[02:32:26.0000] <hsivonen>
MikeSmith: this is checkin-needed right? https://bugzilla.mozilla.org/show_bug.cgi?id=910588

[02:34:04.0000] <MikeSmith>
I guess we need to add another class of test case, "has warning", along with "not valid" (has error) and "valid" (has no errors)

[02:34:42.0000] <MikeSmith>
hsivonen: yes , checkin needed

[02:36:22.0000] <hsivonen>
MikeSmith: ok

[02:47:50.0000] <annevk>
"Some comments I made a long time ago:" points to message between April and June this year :-)

[02:52:30.0000] <MikeSmith>
hsivonen: I had realized that was going to affect View Source. I guess I should have noted it in the bug report. I wonder if there's anybody actually testing the View Source behavior.

[03:40:27.0000] <hsivonen>
MikeSmith: OK to use your hg  user line for the generated C++ patch?

[03:42:08.0000] <MikeSmith>
hsivonen: yep, fine by me

[03:42:32.0000] <hsivonen>
MikeSmith: ok

[04:12:59.0000] <annevk>
Hmm, should URL.username and URL.password actually be settable?

[04:13:29.0000] <annevk>
abarth: ^^

[04:18:18.0000] <annevk>
I guess it's fine

[04:23:44.0000] <zcorpan>
MikeSmith: maybe the validator could be configured to not whine about XML-mappability?

[04:29:53.0000] <MikeSmith>
zcorpan: I thought I already had the test runner configured that way, actually. So I'm not sure why I'm seeing them.

[04:31:10.0000] <MikeSmith>
anyway, I guess I will probably make the change to have the test runner recognize some files as being expected to cause warnings to be emitted intead of errors. Because it's useful to distinguish the diference.

[05:29:36.0000] <annevk>
TabAtkins: you should really get some more sleep ;)

[05:29:41.0000] <annevk>
TabAtkins: oooh wait, you're in Paris

[05:38:17.0000] <annevk>
TabAtkins: I'm running into that problem you always seem to run into, how do I use http://dev.w3.org/csswg/selectors/ to do what I need?

[05:38:17.0000] <annevk>
TabAtkins: :-)

[05:39:35.0000] <SimonSapin>
annevk: which problem is that?

[05:40:18.0000] <annevk>
SimonSapin: I have a string, what parsing algorithm do I pass it to to get a selector object out? The algorithm needs to return failures for unresolved namespaces and other parsing errors.

[05:41:14.0000] <annevk>
SimonSapin: The next step is then using that selector object to match against a set of nodes. It's not clear what algorithm to use for that either, although the spec does seem to suggest to use "scope-filtered selectors" in that in some way because of the example I just read...

[05:42:16.0000] <annevk>
SimonSapin: that next step also needs to take the context object into account and discard it if it's not an Element, I guess

[05:42:22.0000] <SimonSapin>
there is no explicit algorithms

[05:42:43.0000] <annevk>
SimonSapin: so I just need to monkey patch my way out of this mess?

[05:42:49.0000] <SimonSapin>
but the first step is parse per the grammar http://dev.w3.org/csswg/selectors/#grammar and check that the result is not invalid http://dev.w3.org/csswg/selectors/#invalid

[05:43:16.0000] <hsivonen>
MikeSmith: what OS do you deploy the Nu Validator on?

[05:43:29.0000] <hsivonen>
MikeSmith: do you deploy on Java 7?

[05:43:32.0000] <annevk>
SimonSapin: how does that deal with namespaces?

[05:44:10.0000] <annevk>
SimonSapin: and why is there no algorithm for parsing? that's kinda fundamental, no?

[05:44:33.0000] <annevk>
SimonSapin: we have lots of contexts that need selector parsing...

[05:45:40.0000] <SimonSapin>
there is a grammar

[05:45:55.0000] <annevk>
orly?

[05:46:06.0000] <SimonSapin>
http://dev.w3.org/csswg/selectors/#grammar

[05:46:13.0000] <annevk>
yeah you already gave that link

[05:46:17.0000] <SimonSapin>
yeah

[05:46:40.0000] <annevk>
Again, that's not parsing, doesn't return anything, doesn't describe what it means what you get back when you follow it, etc.

[05:46:45.0000] <annevk>
Doesn't deal with resolving namespaces

[05:47:01.0000] <SimonSapin>
yes, the "invalid" concept includes undeclared namespace prefixes

[05:47:09.0000] <annevk>
You  can't say "grammar" and expect magic

[05:48:03.0000] <SimonSapin>
not everything has to be written in imperative style

[05:48:11.0000] <annevk>
SimonSapin: yes, but it doesn't define if the namespace prefixes need to be declared ahead of parse time or not, etc.

[05:48:55.0000] <annevk>
SimonSapin: but you need clear hooks between specs, I don't really care how you define what gets implemented as an algorithm

[05:49:07.0000] <annevk>
SimonSapin: but if you don't define an algorithm, you need to be clear on how things work

[05:49:26.0000] <annevk>
SimonSapin: you can't just say, "there a grammar" and there's rules for "invalid" and you can derive the parsing algorithm from that

[05:49:58.0000] <SimonSapin>
yes, this spec should have better-defined hooks for other specs

[05:50:19.0000] <SimonSapin>
beyond that, I don’t see what’s the problem

[05:50:36.0000] <annevk>
Well, does parsing a selector fail if namespaces are not (yet) declared?

[05:51:32.0000] <annevk>
I.e. does parsing need a map of namespace declarations, or is that an after the fact thing on top of the output. That affects the implementation and affects designs around selectors.

[05:51:38.0000] <SimonSapin>
http://dev.w3.org/csswg/selectors/#namespaces says that you need a (possibly empty) set of namespace prefix declarations

[05:51:46.0000] <annevk>
Yes, but it doesn't say when.

[05:53:04.0000] <SimonSapin>
that depends on what uses selectors. For stylesheets, http://www.w3.org/TR/css3-namespace/ defines that @namespace rules must be before style rules

[05:53:18.0000] <SimonSapin>
because having to go back and change the meaning of previous rules would suck

[05:53:37.0000] <annevk>
So you're saying the parse operation itself is independent of namespaces?

[05:53:45.0000] <SimonSapin>
Selectors APIs defines that the set is always empty, I believe

[05:54:17.0000] <SimonSapin>
in practice, you get namespace prefix declarations before parsing

[05:54:35.0000] <annevk>
Well that depends on what API I design

[05:54:50.0000] <annevk>
The specification doesn't seem to constrain me either way

[05:54:51.0000] <SimonSapin>
I mean http://www.w3.org/TR/selectors-api/

[05:55:04.0000] <annevk>
I don't

[05:55:34.0000] <SimonSapin>
ok, so if you’re making a new thing that uses selectors, you need to define what ns declarations apply to any given selector

[05:55:49.0000] <annevk>
Again, I could do that after parse has completed it seems...

[05:55:57.0000] <annevk>
Because you don't define what parsing means, it's up to me

[05:56:29.0000] <annevk>
And I think that would be a problem for implementations, which is why I bring this up...

[05:57:00.0000] <SimonSapin>
well, if you want to separate the parsing into a concrete syntax tree per the grammar and then replace ns prefixes with URLs in a later step, you could do that

[05:57:08.0000] <SimonSapin>
I believe that’s an implementation detail

[05:58:28.0000] <annevk>
:-(

[05:58:49.0000] <SimonSapin>
there is no model of "what you get" after parsing a selector because they’re basically black boxes. On the platform you can only observe their string serialization

[05:58:50.0000] <annevk>
That sounds like really bad systems design. I wonder if TabAtkins agrees with this...

[05:59:50.0000] <SimonSapin>
we’re in the middle in the F2F and he’s talking about gradient interpolation, but I’ll point him to this later

[06:01:02.0000] <annevk>
If you define a syntax, whether the result object is a black box you can do things with or not, defining "parse X using namespace map Y" seems like a good thing to do.

[06:01:38.0000] <annevk>
And then you can ask the opaque object to query /tree/ using /scope/ or some such...

[06:01:51.0000] <SimonSapin>
ok, we could do that

[06:03:24.0000] <annevk>
We might even want to expose a Selector as a thing in script at some point I suppose... Hmm

[06:03:36.0000] <SimonSapin>
maybe

[06:03:43.0000] <SimonSapin>
for now all you get is .selectorText

[06:04:36.0000] <SimonSapin>
In my experience when implementing Selectors, the data structure you want to represent them varies *a lot* based on the matching strategy

[06:05:09.0000] <TabAtkins>
annevk: I can add algo hooks for converting string to selector, and matching selector against a set of nodes in a tree.

[06:05:25.0000] <annevk>
TabAtkins: sweet

[06:05:38.0000] <annevk>
SimonSapin: interesting

[06:05:58.0000] <annevk>
SimonSapin: I wasn't thinking of exposing the data structure anymore than an opaque Selector object, perhaps with serialization

[06:06:07.0000] <annevk>
SimonSapin: but if it depends on matching, that might not be good

[06:07:01.0000] <annevk>
TabAtkins: I'll add something to the DOM standard for querySelector / querySelectorAll for now and then you can fill in the boxes I leave open and then we patch 'm up

[06:07:58.0000] <TabAtkins>
Yeah, all you need is a "selector" thinger, no internal structure.  That's perfectly fine to expose.

[06:08:09.0000] <hsivonen>
If I set up a new VM for running Validator.nu, which Ubuntu version should I use? The latest are the LTS?

[06:08:15.0000] <TabAtkins>
But there is still an internal structure insofar as it's a complex selector list or whatever.

[06:08:19.0000] <SimonSapin>
well, exposing a Selector object that does do anything but its serialization is not very useful

[06:08:38.0000] <hsivonen>
The canonical supported version of OpenJDK in the LTS 6. in the latest, it's 7.

[06:09:22.0000] <TabAtkins>
SimonSapin: It's used by the "match a selector against some nodes" algo that Anne will be doing

[06:09:43.0000] <SimonSapin>
TabAtkins: do you mean a spec concept, or a JS object?

[06:10:01.0000] <TabAtkins>
It's just convenient to have a spec concept for "selector" rather than having to cart around a string and constantly say "interpret as a selector...".

[06:10:05.0000] <TabAtkins>
Spec concept only.

[06:10:15.0000] <TabAtkins>
I suspect.

[06:10:17.0000] <TabAtkins>
annevk: ?

[06:10:36.0000] <SimonSapin>
then yes, +1 on spec concepts

[06:10:43.0000] <annevk>
TabAtkins: spec concept for sure, I was thinking maybe a JS object at some point

[06:11:00.0000] <TabAtkins>
Yeah, if you can find a use for it, I'm not against a JS object for it.

[06:11:02.0000] <annevk>
TabAtkins: we've had requests for that too, but if as SimonSapin says you want different data structures that might not be good to have

[06:11:19.0000] <SimonSapin>
requests for what exactly?

[06:11:32.0000] <MikeSmith>
hsivonen: w3c vnu backends I deploy on are all running java7

[06:11:36.0000] <annevk>
TabAtkins: but yeah, for most specs with a syntax having string -> object and object -> string is nice :)

[06:12:05.0000] <annevk>
SimonSapin: compile a string into a selector and then use it; similar to regular expressions

[06:12:21.0000] <annevk>
SimonSapin: selector.test(node) or some such

[06:12:30.0000] <hsivonen>
MikeSmith: ok. thanks

[06:12:38.0000] <annevk>
SimonSapin: we're adding the opposite now, which is okay I suppose, but somewhat ugly

[06:12:49.0000] <annevk>
(node.matches())

[06:12:57.0000] <SimonSapin>
annevk: if that JS object can be used in Selectors APIs, then yes it’s useful

[06:13:08.0000] <annevk>
Selectors API is going away

[06:14:09.0000] <SimonSapin>
uh, ok

[06:14:30.0000] <annevk>
SimonSapin: but what about your point about wanting to parse it into different structures depending on usage?

[06:14:34.0000] <SimonSapin>
or whatever its replacement is

[06:15:06.0000] <jgraham>
(I would totally prefer selector.matches(node) to node.matches(selector) fwiw)

[06:15:17.0000] <annevk>
jgraham: noted

[06:15:21.0000] <MikeSmith>
hsivonen: OS on all is Debian stable, 64 bit Intel

[06:15:34.0000] <jgraham>
Only for aesthetic reasons though

[06:15:35.0000] <annevk>
jgraham: depending on SimonSapin's answer to that question I might propose that on public-webapps

[06:16:29.0000] <SimonSapin>
annevk: if you want to expose the parts of a selector such as combinators, pseudo-classes, etc

[06:17:11.0000] <SimonSapin>
there are many ways to organize these in data structures

[06:17:14.0000] <annevk>
SimonSapin: the point is that if you parse it into an object, you lose context of what it might be used for

[06:17:41.0000] <hsivonen>
MikeSmith: OK.

[06:18:02.0000] <hsivonen>
MikeSmith: does Debian already have OpenJDK 7 as a system package?

[06:18:03.0000] <annevk>
SimonSapin: in particular, you remark was "In my experience when implementing Selectors, the data structure you want to represent them varies *a lot* based on the matching strategy"

[06:18:17.0000] <SimonSapin>
yes

[06:18:28.0000] <annevk>
SimonSapin: if you have a single object without context, it seems that is still a problem

[06:18:57.0000] <SimonSapin>
when adding an optimization to make matching faster, you may want to change the internal representation of selectors to make that easier

[06:19:10.0000] <jgraham>
But is "strategy" a constant for a given implementation?

[06:19:20.0000] <annevk>
SimonSapin: that's a different comment

[06:19:28.0000] <jgraham>
Or is it something that varies between e.g. CSS and qSA

[06:19:43.0000] <SimonSapin>
that’s a more specific example of what you quoted

[06:19:56.0000] <annevk>
*sigh*

[06:20:01.0000] <jgraham>
I think annevk is worried about the latter but not the former

[06:20:26.0000] <jgraham>
Or, maybe that's not a good example of the latter

[06:20:30.0000] <annevk>
Changing the data structure overall is indeed fine. That's why you have it as opaque object.

[06:20:56.0000] <SimonSapin>
ok, so we agree on that much

[06:21:01.0000] <annevk>
But if the data structure needs to be different between sel.matches(node) and sel.matchAgainst(tree), there's a problem

[06:21:08.0000] <annevk>
doh

[06:21:12.0000] <SimonSapin>
but then if that object is opaque, why is it useful?

[06:21:28.0000] <annevk>
SimonSapin: regular expression objects are opaque too...

[06:21:31.0000] <SimonSapin>
ok, you have a matching API on it

[06:21:39.0000] <SimonSapin>
I was missing that part

[06:22:22.0000] <jgraham>
So I think the idea is that it would be like re.compile in python

[06:22:46.0000] <jgraham>
var s = new Selector(".foo > bar")

[06:22:54.0000] <annevk>
Why else would you have an object...

[06:22:58.0000] <jgraham>
s.matches(node)

[06:23:03.0000] <jgraham>
-> bool

[06:25:42.0000] <MikeSmith>
I believe Debian does have Java 7 as a package, but not sure. I did not do the Java installs on those hosts. I think Yves did, so I'll ask him.

[06:25:54.0000] <SimonSapin>
so, yeah, a matching API with "pre-compiled" objects would be good

[06:26:11.0000] <SimonSapin>
though I don’t know how much it really affects performance in practice

[06:31:38.0000] <hsivonen>
MikeSmith: no need. I'll go with the latest non-LTS Ubuntu

[06:32:15.0000] <jgraham>
SimonSapin: Well it's not just a performance thing

[06:33:01.0000] <jgraham>
I quite like the idea of inverting the API so that instead of everything hanging off node you have a selector that you can run against various objects

[06:33:18.0000] <SimonSapin>
jgraham: what’s the difference with using strings, other than perf?

[06:33:28.0000] <jgraham>
Others probably disagree though

[06:33:56.0000] <jgraham>
SimonSapin: YOu can't have the API this way around and strings

[06:34:08.0000] <annevk>
Domenic_: you're now my default-cc for a bunch of things, I'm gonna assume you'll let me know when it gets annoying

[06:34:32.0000] <jgraham>
".foo > bar".matches(node) seems like all kind of wrong

[06:34:59.0000] <hober>
zcorpan: does cssom view define when an element establishes a scrolling box?

[06:35:14.0000] <annevk>
jgraham: making selectors first-class citizens makes a lot of sense to me

[06:35:17.0000] <zcorpan>
hober: no. known bug

[06:35:25.0000] <hober>
ok, thanks

[06:35:27.0000] <annevk>
jgraham: it's also less work for me :)

[06:35:55.0000] <annevk>
hober: zcorpan: CSS ought to define that...

[06:36:17.0000] <annevk>
hober: zcorpan: CSSOM is just there to expose the properties of the box and manipulate it, not to define when it exists

[06:37:27.0000] <hober>
yeah, i don't really care where the definition is so long as there's one i can xref

[06:37:57.0000] <annevk>
hober: dude, you're on the CSS WG, it's your job to care, and I shouldn't have to :)

[06:38:34.0000] <SimonSapin>
jgraham: Selector("foo").match(node) vs. Selector.match("foo", node), meh.

[06:38:37.0000] <hober>
i mean, i do care from a "specs should be well organized" perspective, but i care less about that than that it gets written down somewhere. we can always move the definition to somewhere more appropriate

[06:38:54.0000] <Lachy>
I once had a proposal to be able to construct new slectors like that, though it was being considered for some other reason.

[06:43:05.0000] <hober>
zcorpan: looks like you can reference "flow root" in css-box

[06:43:45.0000] <zcorpan>
hober: ? i don't edit css-box

[06:44:10.0000] <zcorpan>
oh do you mean for scrolling box?

[06:44:18.0000] <hober>
zcorpan: i mean the term "scrolling box" in cssom-view can reference that

[06:44:24.0000] <zcorpan>
ah

[06:44:37.0000] <hober>
although it looks like the definition could use a lot of love

[06:45:52.0000] <zcorpan>
it's not clear that it's the same as scrolling box

[06:46:16.0000] <zcorpan>
float:left causes flow root but not scrolling box

[06:46:41.0000] <zcorpan>
you need overflow:auto or something

[06:52:14.0000] <annevk>
Lachy: time to chat for a bit?

[06:52:32.0000] <Lachy>
in a few minutes

[06:53:37.0000] <annevk>
Lachy: element.querySelector(): tree is element's node document, subject is element; document.querySelector(); tree is document, subject is document; documentfragment.querySelector(); tree is documentfragment, subject is documentfragment?

[06:55:04.0000] <annevk>
Lachy: and where I said subject, I meant scoping root

[06:56:57.0000] <zcorpan>
hober: http://dev.w3.org/csswg/css-box/#scrolling-mechanism looks closer

[06:59:57.0000] <annevk>
Actually, element's node document is wrong if element's ancestor is not document.

[07:00:09.0000] <annevk>
Ah yeah, you want element's root

[07:00:22.0000] <annevk>
And root also works for Document and DocumentFragment

[07:00:26.0000] <annevk>
brilliant

[07:14:27.0000] <hober>
zcorpan: yeah, that doesn't handle overflow:hidden (which can be scrolled by script but has no scrolling mechanism)

[07:15:01.0000] <zcorpan>
hober: good point

[07:15:35.0000] <Lachy>
annevk, I'm back

[07:16:09.0000] <zcorpan>
hober: so has overflow and either overflow:hidden or has a scrolling mechanism

[07:18:44.0000] <annevk>
Lachy: TabAtkins: http://dom.spec.whatwg.org/#evaluate-a-selectors-string

[07:18:57.0000] <annevk>
ms^^

[07:19:06.0000] <annevk>
oh, meant that for Ms2ger, who is MIA

[07:24:19.0000] <annevk>
Lachy: also question, the idea with find/select is that instead of the tree being the context object's root, it's the context object itself, and the selector is a relative selector, right?

[07:27:22.0000] <Lachy>
tree is always the root element. It has to be since find can match elements anywhere in the document. Find basically just has an implied :scope that matches the context object.

[07:28:27.0000] <annevk>
oh okay, so tree is still the same, it's just that parsing is different?

[07:29:01.0000] <Lachy>
From memory, I think it works like this. element.find("+p") implies :scope+p

[07:30:19.0000] <Lachy>
yes, parsing is different. I will review what I'd written in here. I can take a look later tonight. I have to leave in about 2 minutes. https://github.com/lachlanhunt/dom/blob/master/dom-core.html

[07:31:08.0000] <annevk>
Lachy: it's fine I guess, I'll figure it out, seems like a few things are gonna change anyway per public-webapps discussion

[07:32:19.0000] <Lachy>
ok

[07:32:34.0000] <Lachy>
I should catch up with that stuff. Feel free to do whatever you think is best.

[07:32:54.0000] <annevk>
ta

[07:39:52.0000] <Lachy>
annevk, btw, the name select isn't usable. It clashes with an existing method. I'll check which one it is later.

[07:39:57.0000] <Lachy>
bye

[07:58:12.0000] <TabAtkins>
annevk: Difference between find and querySelector is solely:

[07:58:25.0000] <TabAtkins>
a) find allows relative selectors (starts with a combinator)

[07:58:58.0000] <annevk>
right, that's parsing

[07:59:24.0000] <annevk>
I'd appreciate review of http://dom.spec.whatwg.org/#evaluate-a-selectors-string btw

[07:59:33.0000] <TabAtkins>
b) find doesn't do any scoping, while qSA does scope-filtering.  (But the effect of relative selectors means that it kinda looks like scoping.)

[07:59:58.0000] <annevk>
Ah interesting. And c) has a much better return value...

[08:00:05.0000] <TabAtkins>
Yes.

[08:00:20.0000] <TabAtkins>
And yeah, i'll review in a bit.  I'm still minuting...

[08:00:29.0000] <annevk>
poor TabAtkins

[08:01:08.0000] <Domenic_>
ugh these stream proposals are getting out of hand

[08:02:57.0000] <annevk>
Domenic_: a decade ago someone would have just shipped something and we'd be stuck with that

[08:03:04.0000] <annevk>
Domenic_: count your blessings

[08:03:34.0000] <jgraham>
Now we will spend a year iterating the design, someone will just ship something, it will turn out to be crappy, and we will be stuck with that

[08:04:04.0000] <Domenic_>
annevk: was more a comment on quality than quantity, but yeah, i know what you mean

[08:04:34.0000] <Domenic_>
going to have to just take isaacs's proposed minimal API, slap one or two promise-returning sugar methods on top of it, and see how that goes over

[08:04:41.0000] <Domenic_>
will write up after i finish these damn jsconf eu slides

[08:04:55.0000] <annevk>
Man, everyone is going to Berlin?

[08:05:12.0000] <annevk>
Maybe next year...

[08:06:05.0000] <annevk>
darobin: for some reason your matchesSelector email doesn't show up in my inbox, I guess there's delayed delivery for you too :/

[08:06:29.0000] <annevk>
darobin: but seems like there'd be transition cost either way

[08:06:33.0000] <darobin>
annevk: yeah, it seems there's some weirdness

[08:06:59.0000] <darobin>
oh I'm not against the idea, I think I like it — I was just pointing out that there are implementations

[08:07:53.0000] <Domenic_>
while it seems cool conceptually, i am not sure I would ever use a Selectors object...

[08:08:10.0000] <darobin>
Domenic_: hence my "I think I like it"

[08:08:20.0000] <darobin>
I'm still thinking about which contexts I'd actually use it in

[08:12:07.0000] <annevk>
If you wouldn't use that, would you use matches()?

[08:12:20.0000] <annevk>
They're identical, except one has less parsing over time...

[08:12:34.0000] <annevk>
And puts less cruft on Element

[08:12:57.0000] <Domenic_>
yeah I use the jQuery equivalent (.is) all the time

[08:14:37.0000] <Domenic_>
I meant, in a world where both were available, I can never see myself doing `(new Selectors("x")).matches(el)` over `el.matches("x")`, so I need to think of cases where caching the selector is important, and I can't think of any right now.

[08:14:57.0000] <annevk>
Yeah understood. Hmm...

[08:16:12.0000] <annevk>
.matches() takes relative selectors too?

[08:27:24.0000] <annevk>
So <input> has select(), but it doesn't take an argument...

[08:27:36.0000] <Domenic_>
oh boy :P

[08:27:57.0000] <Domenic_>
i humbly put forth query/queryAll, which are not as good, but no such issues i would hope

[08:28:23.0000] <annevk>
That might work

[08:36:46.0000] <Domenic_>
Hmm did the ascii-art get dropped from grid layout?

[08:50:31.0000] <TabAtkins>
Domenic_: No, of course not.  Why would you think so?

[08:51:18.0000] <Domenic_>
TabAtkins: was reading some links tweeted by @CSSWG and saw a different syntax being used. Probably additive then, not instead of.

[08:51:44.0000] <TabAtkins>
Yeah, grid-template-areas is the ascii-art property.

[08:56:35.0000] <darobin>
/me wishes it were just called "ascii-art"

[10:05:26.0000] <gsnedders>
jgraham: Can you rebase r/287?

[10:05:46.0000] <gsnedders>
jgraham: Should be in-place to ca4041f2e005748559189af27c92c1db73e76159

[10:08:38.0000] <gsnedders>
jgraham: Okay, managed to do the rebase, now can't enable tracking

[10:09:02.0000] <gsnedders>
jgraham: And now it's working again suddenly. Weird.

[10:37:29.0000] <mounir>
Domenic_: in 'promises-unwrapping', the .race() method in inspired by what? A+? previous DOM spec?

[10:38:59.0000] <mounir>
Domenic_: ... I wonder why it is designed to reject if one of the promises is rejected

[11:38:43.0000] <Hixie_>
http://larry.masinter.net/1307multipart-form-data.pdf https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909#c8

[14:28:33.0000] <Hixie_>
do we really still not have a cross-browser mousewheel story?

[14:28:54.0000] <zcorpan>
Hixie_: my chrome passes http://www.hixie.ch/tests/adhoc/dom/level0/window/security/001.html

[14:29:41.0000] <Hixie_>
zcorpan: yes? are we expecting otherwise?

[14:30:48.0000] <zcorpan>
Hixie_: you claimed otherwise in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23218#c1

[14:31:51.0000] <zcorpan>
oh the pass condition is backwards

[14:32:15.0000] <Hixie_>
that test is checking something else

[14:32:16.0000] <Hixie_>
my bad

[14:32:20.0000] <Hixie_>
i changed it after filign the bug

[14:32:24.0000] <Hixie_>
forgot i'd mentioned it in the bug

[14:32:38.0000] <zcorpan>
ok

[14:33:35.0000] <jgraham>
gsnedders: Yeah, I think the caching gets screwed up or something

[14:35:51.0000] <zewt>
Hixie_: it's not even interoperable across browser versions, heh

[14:39:43.0000] <zewt>
(iirc event.detail is the amount of the scroll, and since mousewheels snap to lines it's some constant N times the number of lines--but that constant isn't very constant)

[14:40:00.0000] <Hixie_>
wheelDelta, not detail, but yeah

[14:42:41.0000] <zewt>
it's event.detail somewhere, or at least I have code that tries both

[14:45:37.0000] <zewt>
oh yeah it's .detail on DOMMouseScroll (firefox), .wheelDelta on mousewheel (webkit)

[14:46:12.0000] <zewt>
and for added fun, not only are their scales completely different--their signs are opposite

[14:48:16.0000] <jgraham>
Just call it "natural scrolling" and sell it as a feature

[14:50:58.0000] <zewt>
zing

[16:31:17.0000] <Hixie_>
annevk: i'm confused by "fetch" step 7, the one that queues tasks. what are the tasks? are these the same as the tasks to process the data as it is downloaded from HTML?

[16:31:30.0000] <Hixie_>
are they fired for incomplete headers? just data?


2013-09-12
[01:50:08.0000] <Domenic_>
what's the thing that's supposed to make reset stylesheets go away? `default`? it's not `initial`, is it?

[01:57:39.0000] <TabAtkins>
It's called "unset" now.

[01:57:58.0000] <TabAtkins>
== initial or inherit, whichever is correct.

[02:01:31.0000] <Domenic_>
thanks. and is there a nesting spec still active?

[02:02:16.0000] <Domenic_>
hierarchies, got it

[02:22:06.0000] <TabAtkins>
Domenic_: The syntax in Hierarchies isn't what we're going to use.  It's too annoying, and prevents some stuff that SASS allows, like "foo { bar & {...} }".

[02:23:13.0000] <TabAtkins>
Domenic_: To do that, we need an explicit wrapper switching our context to selectors, and I think I'm just going to do {}.

[02:23:31.0000] <TabAtkins>
Like "foo { color: red; { bar { color: blue; } } }"

[02:23:51.0000] <TabAtkins>
That's really hard to read here in linear form, but it's fine when properly indented in a stylesheet. ^_^

[02:28:11.0000] <annevk>
Hixie_: the task queuing part of Fetch is broken

[02:30:47.0000] <annevk>
Domenic_: yay for closing issues

[02:34:18.0000] <Domenic_>
TabAtkins: fascinating. FWIW I've never been able to use SASS's ampersand-afterwards style very effectively, so something without it seems OK. But I'll trust you on this one.

[02:34:30.0000] <Domenic_>
annevk: ya, I thought it was time.

[02:35:13.0000] <TabAtkins>
Domenic_: The explicit context also lets you drop the ampersand from "& bar", like SASS does, which is nice.

[02:36:02.0000] <Domenic_>
TabAtkins: why doesn't SASS's exact syntax work? (Sorry I know these are nooby questions that could be answered by finding the right forum threads.)

[02:36:28.0000] <TabAtkins>
SASS is willing to do arbitrary lookahead to disambiguate selectors and properties.  CSS isn't.

[02:36:54.0000] <Domenic_>
gotcha

[02:36:56.0000] <TabAtkins>
You can't tell whether "a:hover a a a a a a a..." is a selector or a property until you hit a "{" or a ";".

[02:40:43.0000] <annevk>
foolip: yo, I told the i18n guys I wouldn't do Encoding standard updates for a couple of weeks, so I'll get back to that in October

[02:40:56.0000] <annevk>
foolip: wanted to let you know that and thank you for big5 research once more :)

[03:04:34.0000] <zcorpan>
anyone want to review https://critic.hoppipolla.co.uk/r/307 ?

[03:07:15.0000] <annevk>
Domenic_: so jQuery supports node.is("> test") // doesn't throw

[03:07:21.0000] <annevk>
Domenic_: how does that ever make sense?

[03:07:53.0000] <annevk>
whoa, but <body>.is("html > body") // true

[03:08:07.0000] <annevk>
that seems very weird

[03:10:44.0000] <Domenic_>
hmm

[03:11:05.0000] <Domenic_>
annevk: tbh mostly i use very simple selectors with .is, like tag names.

[03:11:45.0000] <annevk>
I think it should behave just like the selectors passed to querySelector

[03:11:50.0000] <Domenic_>
i agree .is("> test") doesn't make much sense, but then again, not throwing might be a useful property

[03:12:22.0000] <annevk>
The thing is, if you parse it as a relative selector, is .is("body") going to work?

[03:12:32.0000] <Domenic_>
<body>.is("html > body") seems good, I would use that

[03:12:47.0000] <annevk>
Then you cannot parse it as a relative selector

[03:13:10.0000] <Domenic_>
is there any reason it shouldn't just be an absolute selector? hmm

[03:13:14.0000] <annevk>
Or we'd have to redefine relative selector to be "sometimes relative selector" or some such and a different algorithm

[03:13:27.0000] <annevk>
Yeah, I don't know

[03:13:44.0000] <annevk>
Lachy: why did spec .matches() as taking a relative selector?

[03:13:58.0000] <annevk>
Domenic_: Elements.prototype.matches() should exist too right?

[03:14:24.0000] <annevk>
Hmm, maybe something like queryFilter() would be more useful

[03:14:30.0000] <Domenic_>
annevk: hmm probably, with for-all semantics i assume (not there-exists)?

[03:14:43.0000] <annevk>
Domenic_: yes

[03:15:28.0000] <Domenic_>
shall i add to gist?

[03:17:02.0000] <annevk>
Domenic_: dunno, I'm suggesting this because http://dev.w3.org/2006/webapi/selectors-api2/#the-apis has it

[03:17:36.0000] <annevk>
Domenic_: (matches() having a second argument for reference nodes)

[03:18:21.0000] <annevk>
Domenic_: btw, if I were to define Elements as a JavaScript thing, is there some ES6 precedent I can follow for that?

[03:18:41.0000] <Domenic_>
annevk: you mean, if you were to write a spec? hmm.

[03:18:58.0000] <Domenic_>
I think GeneratorFunction derives from Generator?

[03:19:07.0000] <Domenic_>
err, from Function

[03:22:08.0000] <annevk>
Domenic_: doesn't look like it

[03:23:20.0000] <Domenic_>
annevk: no, it does. It's not very clear though. e.g. "The value of the [[Prototype]] internal data property of the GeneratorFunction constructor is the intrinsic object %Function%."

[03:23:52.0000] <Domenic_>
Plus "The value of the [[Prototype]] internal data property of the GeneratorFunction prototype object is the %FunctionPrototype% intrinsic object."

[03:24:19.0000] <Domenic_>
the first is constructor-side inheritance, the second prototype-side, together I think they do the trick.

[03:25:44.0000] <annevk>
"The GeneratorFunction prototype object is an ordinary object. It is not a function object and does not have a [[Code]] internal data property or any other of the internal data properties listed in Table 25 or Table 39."

[03:26:28.0000] <Lachy>
annevk, that's useful when there are reference nodes passed as well, so you can see if an element matches a selector relative to other specified elements.

[03:27:12.0000] <annevk>
Lachy: but it makes <body>.matches("html > body") fail, no?

[03:27:32.0000] <Lachy>
e.g. element.matches(">span", [el1, el2, el3]); matches if the element is a span that is a child of one of those elements.

[03:27:34.0000] <Lachy>
No.

[03:27:44.0000] <Lachy>
a relative selector doesn't always prepend :scope

[03:28:14.0000] <annevk>
Oh, it's always potentially relative?

[03:28:23.0000] <Domenic_>
annevk: yeah that's just the standard ES6 thing of making X.prototype not a useful instance of X.

[03:28:31.0000] <Lachy>
from memory, I think the algorithm for parsing relative selectors checks if there are any reference nodes first.

[03:28:55.0000] <Lachy>
if there aren't any, no :scope is prepended.

[03:29:02.0000] <Lachy>
or something like that.

[03:29:30.0000] <Domenic_>
(bbl, lunch)

[03:29:36.0000] <annevk>
Domenic_: okay, so why does a bunch of things need to be redefined?

[03:29:50.0000] <Domenic_>
annevk: which things?

[03:29:56.0000] <annevk>
Domenic_: e.g. the constructor

[03:30:04.0000] <annevk>
Domenic_: I guess it has a different constructor?

[03:30:14.0000] <Domenic_>
annevk: well probably yeah, generators are pretty different from functions

[03:30:32.0000] <annevk>
Domenic_: it seems to me for Elements we'd only have to define a minimal set of things, right?

[03:30:46.0000] <Domenic_>
annevk: agree, I am pretty sure.

[03:32:24.0000] <Domenic_>
Lachy: annevk: has anyone implemented "absolutize relative selector list" algorithm in JS? THat may be the easiest way to ensure it does what we want.

[03:33:28.0000] <annevk>
Domenic_: dunno, it'd require parsing selectors in JS... http://dev.w3.org/csswg/selectors/#absolutizing

[03:34:21.0000] <foolip>
annevk, sure, as long as it's on your radar. but why did the i18n people not want you to update the spec?

[03:35:29.0000] <annevk>
Lachy: http://dev.w3.org/csswg/selectors/#absolutizing seems to pretty much always prepend :scope? TabAtkins?

[03:35:46.0000] <annevk>
foolip: they want to publish a fork on TR/

[03:36:33.0000] <foolip>
annevk, ew, but I take it you'll allow it?

[03:36:43.0000] <annevk>
foolip: I'd just have to notify them if I made a change so they could sync up again before publication, seemed easier to not update for a bit

[03:36:57.0000] <annevk>
foolip: I agreed to this before I decided it was a bad idea :/

[03:37:54.0000] <annevk>
foolip: also, CC0

[03:37:58.0000] <foolip>
I sure hope no one finds that TR/ spec and implements big5 with the wrong error handling

[03:38:22.0000] <foolip>
annevk, do you know if similar conditions might be needed for similar encodings?

[03:39:01.0000] <annevk>
foolip: yeah, if you follow the link at the top of the spec for open bugs, you'll find we're trying to figure out the right behavior for most multi-byte encodings :/

[03:39:13.0000] <annevk>
foolip: I need to study browsers some more basically

[03:40:14.0000] <foolip>
annevk, no open bug for gb* encodings, which do decrease the byte pointer. is that an oversight or are you confident it's already correct?

[03:41:00.0000] <annevk>
foolip: I think gbk / gb18030 are correct, however, the mapping story needs work

[03:41:10.0000] <foolip>
annevk, btw, I tried to figure out what error handling chromium has, but it looks like maybe libicu is used and I couldn't grep my way to the source

[03:41:23.0000] <annevk>
foolip: they use ICU

[03:41:27.0000] <annevk>
foolip: but modified

[03:41:35.0000] <foolip>
yeah, I saw some patches there as well

[03:42:01.0000] <foolip>
but still nothing that looks like "decode big5 here" so I guess that it shares the algorithm with some other encodings or some such

[03:42:14.0000] <annevk>
foolip: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu51/

[03:43:34.0000] <foolip>
annevk, in any event, thanks for the feedback. I'm guessing that Mozilla is the most likely first implementor of the Big5 changes so I'm not worried that they/you'll look at the wrong spec :)

[03:44:04.0000] <annevk>
foolip: and maybe http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu46/ I suppose, looks like it has more patches, but maybe they've been upstreamed meanwhile

[03:44:24.0000] <annevk>
foolip: yeah, sure hope we fix that mess

[03:44:47.0000] <foolip>
chromium really should too, AFAIK it's still using PUA mappings :/

[03:45:14.0000] <Lachy>
annevk, check the algorithm I had in my fork of dom on github. That should have had the most recent version that I wrote.

[03:47:50.0000] <annevk>
Lachy: yours is different from the one that's in the Selectors specification

[03:47:56.0000] <annevk>
:/

[03:48:07.0000] <mounir>
Domenic_: ping

[03:48:11.0000] <TabAtkins>
annevk: It prepends :scope unless there's already a :scope somewhere in it.

[03:48:33.0000] <annevk>
TabAtkins: looking at https://github.com/lachlanhunt/dom/commit/453f2e2457202f49bd2743966a6f2f66f78a771a we don't want to prepend :scope if there's no reference elements

[03:49:13.0000] <TabAtkins>
There's a difference between "no reference elements" and "empty array of reference elements".

[03:49:22.0000] <annevk>
TabAtkins: ooh, and it looks like there was a way with a :scope flag

[03:49:59.0000] <annevk>
TabAtkins: no reference elements ends up at " Otherwise, this is a spec error. Please report it to the relevant standards body. "

[03:51:02.0000] <TabAtkins>
annevk: Yeah, we don't have a clause for explicitly "no reference elements", because there wasn't a way to do that in Selectors API 2, I thought.

[03:51:27.0000] <TabAtkins>
Really, if you have no reference elements at all, you shouldn't absolutize it - it's already an absolute selector.

[03:51:54.0000] <annevk>
TabAtkins: so what Selectors Level 2 had was a "scope flag"

[03:52:11.0000] <TabAtkins>
Btw, if there's context missing in the scrollback, let me know - I'm too busy with the meeting to read back right now.

[03:52:17.0000] <annevk>
TabAtkins: so for matches("html > body") it would not turn into ":scope html > body"

[03:52:37.0000] <annevk>
TabAtkins: but matches("> body") would turn into ":scope > body"

[03:52:58.0000] <TabAtkins>
Huh, so it wants to be stricter about relative-ness?

[03:53:16.0000] <TabAtkins>
/me isn't sure how you can match :scope > body in the first place.

[03:53:25.0000] <annevk>
TabAtkins: it's more like "potentially relative"

[03:53:38.0000] <annevk>
TabAtkins: the latter would not match and would only work if you provide reference elements...

[03:54:20.0000] <TabAtkins>
ah, kk.

[03:54:28.0000] <annevk>
TabAtkins: it's not entirely clear to me whether we want the reference element feature if we're going to let things work on Elements, but jQuery parity would require not throwing for "> body" and making "html > body" work

[03:54:35.0000] <TabAtkins>
If you need it, I can provide an "absolutize a potentially relative selector" algo.

[03:55:31.0000] <annevk>
TabAtkins: it looks like jQuery always uses that

[03:55:41.0000] <annevk>
TabAtkins: e.g.  w($("body").select("html > body")) returns the body element

[03:55:49.0000] <TabAtkins>
Depends on the function.  jQuery's find() uses the currently specced algo.

[03:56:15.0000] <TabAtkins>
$("body").find("body") returns an empty set.

[03:56:16.0000] <TabAtkins>
iirc

[03:56:49.0000] <annevk>
TabAtkins: ah you're right

[03:57:19.0000] <TabAtkins>
Like I said, just let me know, and I can add the alternate algo.

[03:57:40.0000] <annevk>
TabAtkins: do I file bugs somewhere?

[03:57:50.0000] <TabAtkins>
send email, please.

[03:58:01.0000] <TabAtkins>
or just tell me right here, since I can do that immediately.

[03:58:09.0000] <annevk>
TabAtkins: alright, I'll send a single email once I know all the things I want

[03:58:11.0000] <TabAtkins>
kk

[04:07:21.0000] <annevk>
Domenic_: seems .is() has any semantics

[04:07:44.0000] <annevk>
Domenic_: e.g. [<script>, <div>].is("div") -> true

[04:15:23.0000] <annevk>
Also seems like is("> ..") has no useful semantics other than not throwing...

[04:36:51.0000] <Lachy>
annevk, right. .is() in jquery is more limited than matches() was specced to be in that regard, because matches("> …", refNodes) made that syntax potentially more useful than simply not throwing.

[04:41:20.0000] <Lachy>
Adding support to refNodes and using a relative selector there was a way to address the syntax error issue, though the actual use case for using them with matches() is somewhat limited in practice. So, if you decide not to support refNodes in matches(), at least for now, and instead work around the syntax issue in some other way, then it wouldn't be a huge loss.

[04:54:43.0000] <Domenic_>
mounir: pong

[04:55:34.0000] <Domenic_>
annevk: any semantics seem ok, dunno, seems like a rare case.

[04:57:15.0000] <Domenic_>
annevk: Lachy: seems like unlike find, for matches the reference nodes actually have a meaning, maybe. (although as Lachy says, not a terribly useful one.)

[04:59:07.0000] <Domenic_>
in any case I think singleElement.matches(...) would be the 95% case.

[05:01:11.0000] <Domenic_>
does body.is("> body") work? feels like it should

[05:01:26.0000] <Domenic_>
nope, false

[05:01:28.0000] <Lachy>
Domenic_, no, it doesn't.

[05:01:28.0000] <Domenic_>
weird

[05:01:47.0000] <Lachy>
why would that be weird? You're basically asking is it a child of some undefined element

[05:02:08.0000] <Domenic_>
to me it feels like asking if it's the child of any element

[05:02:28.0000] <Domenic_>
but i guess i can't think of a real reason for that feeling so shrug

[05:02:41.0000] <Lachy>
if that's what you want, then use "*>body" or check if parentNode is null

[05:03:02.0000] <Domenic_>
right, "* > body" works, seems good.

[05:19:15.0000] <annevk>
Lachy: the syntax being compatible was deemed important?

[05:19:38.0000] <annevk>
Lachy: my inclination would be to throw for .matches("> test")

[05:21:18.0000] <annevk>
Domenic_: I'd be inclined to not support Element.prototype.matches() until someone makes a compelling case

[05:21:50.0000] <Lachy>
You could do that too. Then when jquery uses matches, it can just catch the exception and ignore if it ever happens.

[05:21:56.0000] <Domenic_>
annevk: really? do you not think it'd be the 95% case?

[05:22:22.0000] <annevk>
Domenic_: sorry, Elements*

[05:22:29.0000] <Domenic_>
ah ok. yes in that case i agree.

[05:22:52.0000] <annevk>
Lachy: yeah

[05:23:25.0000] <annevk>
It seems kind of weird to start copying the quirks of libraries...

[05:23:45.0000] <Domenic_>
i think the question is, should asking whether something is a match ever throw

[05:23:47.0000] <annevk>
Although I guess we're doing that with promises...

[05:23:55.0000] <Lachy>
I liked it though, cause it basically gave refNodes support in matches for negligible implementation cost, once they're implemented for find()

[05:24:12.0000] <mounir>
Domenic_: I was wondering where the name Promise#race came from, I didn't see it in other libraries but I might as well have not searched enough

[05:24:17.0000] <annevk>
Domenic_: jQuery throws for e.g. is("::blah") which is a parse error in Selectors too

[05:24:38.0000] <annevk>
Lachy: we don't want them for find() anymore

[05:24:43.0000] <Lachy>
why not?

[05:24:44.0000] <Domenic_>
mounir: no libraries really have the operation, but MarkM's concurrency strawman does and Q added it recently based on that.

[05:24:50.0000] <annevk>
Lachy: see public-webapps

[05:24:51.0000] <Lachy>
at least for document.find(), there were some valuable use cases

[05:25:00.0000] <Lachy>
ok, will look

[05:25:09.0000] <Domenic_>
annevk: hmm ok, well if it does throw in some cases then throwing for "> body" seems totally fine.

[05:25:45.0000] <mounir>
Domenic_: why is that added in the first place? is this a commonly used feature?

[05:26:48.0000] <Domenic_>
mounir: not really sure, MarkM likes it I guess, and it was in the original DOM promises, so that is probably the impetus.

[05:30:11.0000] <Lachy>
annevk, is Elements.from() specced anywhere yet?

[05:30:31.0000] <Lachy>
I'm assuming that's the alternative solution to refNodes you're talking about

[05:30:39.0000] <annevk>
Lachy: that's like Array.from()

[05:30:53.0000] <annevk>
Lachy: Elements is just an array subclass that has query/queryAll as methods

[05:31:07.0000] <annevk>
Lachy: and is the return value for query/queryAll

[05:31:21.0000] <Lachy>
ah, ok. Is that Elements object specced somewhere then?

[05:31:36.0000] <annevk>
Lachy: it's https://gist.github.com/domenic/5864658

[05:31:48.0000] <annevk>
Lachy: I'm going to turn that into a spec at some point, once I figure out how

[05:32:08.0000] <Lachy>
ok

[05:32:59.0000] <Lachy>
That looks like a reasonable alternative to refNodes to me, in which case, I agee, just make matches a normal selector instead of relative.

[05:33:08.0000] <Lachy>
*agree

[05:36:34.0000] <Domenic_>
sounds like we're going with query instead of select, updating

[05:41:12.0000] <annevk>
Domenic_: yeah, seems safer

[05:41:26.0000] <annevk>
Domenic_: and hey, we just got everyone used to the name query...

[05:47:51.0000] <Lachy>
what was wrong with the name "find"?

[05:48:28.0000] <annevk>
Lachy: Array.prototype.find is a thing

[05:48:40.0000] <Lachy>
oh, right.

[06:20:34.0000] <annevk>
I think I'll just use my own IDL syntax until heycam|away fixes bugs

[06:20:50.0000] <annevk>
Don't really want to go all ES6 on this as implementers are not going to use that anyway for the foreseeable future

[06:35:10.0000] <Domenic_>
mmm, yeah, lack of @@create is hurting.

[06:35:26.0000] <Domenic_>
i guess i should file those bugs

[06:37:10.0000] <annevk>
engine bugs? cc me please

[06:37:32.0000] <Domenic_>
this one already exists it seems. https://bugzilla.mozilla.org/show_bug.cgi?id=838540

[06:37:49.0000] <Domenic_>
I'll add a comment

[06:37:50.0000] <annevk>
for all the benefits closer cooperation with ES brings, speeding things up is not one of them :/

[06:38:03.0000] <Domenic_>
ah

[06:38:05.0000] <Domenic_>
*hah

[06:40:34.0000] <mounir>
Domenic_: sorry to start again with Promise#race(), I was called for an urgent meeting

[06:40:49.0000] <mounir>
Domenic_: reading the issue, it seems like some people are not trilled with the name and the behaviour

[06:41:00.0000] <mounir>
Domenic_: why not simply not add it to the standardise subset?

[06:44:29.0000] <Domenic_>
mounir: it's more of a question of "why not simply remove it from the standard," which is quite a different question. Under a different name, it's in DOM promises.

[06:47:48.0000] <mounir>
Domenic_: I know it was in DOM promises

[06:47:51.0000] <mounir>
but why was it there?

[06:48:15.0000] <mounir>
Domenic_: DOM promises wasn't stable enough to be an authoritative document ;)

[06:50:45.0000] <mounir>
Domenic_: I mean, I don't see the pros in adding this to the spec and there seem to be cons, if it was a Web API, I would say that the simplest solution would be to simply not add it and figure out later how things evolve

[06:51:31.0000] <Domenic_>
mounir: I won't shed a tear if it dies, but nobody gave any real arguments against it that were more than "I don't like the bikeshed color" (and nobody even proposed a better color).

[06:51:57.0000] <Domenic_>
mounir: if you really want to campaign to kill someone's pet feature, be ready for having a fight on your hands, and start opening issues/gathering consensus from parties involved.

[06:55:54.0000] <mounir>
Domenic_: I will not campaign against it but I just don't understand the reasons behind this feature

[06:57:24.0000] <Domenic_>
mounir: basically it is an easy-to-spec combinator that some people, in particular MarkM, have found useful in their work.

[06:58:47.0000] <mounir>
Domenic_: will file an issue and see how it goes

[06:59:12.0000] <mounir>
I will not die on that hill and no need to discuss it in a not-so-public way

[07:00:14.0000] <Domenic_>
seems like a plan

[07:01:43.0000] <annevk>
Domenic_: not sure Mark felt that strongly about it

[07:02:21.0000] <Domenic_>
annevk: agree, he probably wouldn't mind that much, but just mentioning that he is the one who has actually used it.

[07:34:27.0000] <Domenic_>
annevk: you were probably planning on it already, but would love a cc on that www-style thread.

[07:34:42.0000] <annevk>
Domenic_: wasn't :)

[07:38:22.0000] <Domenic_>
annevk: how are you handling people putting non-elements in Elements? The gist handles it by blowing up in the appropriate place.

[07:39:16.0000] <annevk>
Domenic_: I copy Element nodes from the array before doing anything

[07:39:16.0000] <Domenic_>
annevk: also to enable subclassing ideally `queryAll` should return an instance of `this.constructor`, not necessarily an `Elements`.

[07:40:12.0000] <annevk>
hmm yeah

[07:41:18.0000] <Domenic_>
somehow allen convinced me blowing up was better, i wonder why. will have to re-read.

[07:42:00.0000] <annevk>
Domenic_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18878

[07:42:10.0000] <annevk>
Domenic_: you mean throw if something fails the brand check?

[07:42:20.0000] <annevk>
Domenic_: ooh, wait, just calling the internal thing

[07:42:40.0000] <Domenic_>
annevk: yeah like that, although it's essentially equivalent.

[07:42:54.0000] <annevk>
not quite

[07:43:11.0000] <Domenic_>
hmm right subclasses and such

[07:43:21.0000] <Domenic_>
well depends on how the brand is installed?

[07:44:06.0000] <Domenic_>
i mean the hard part is allowing implementations room for optimization

[07:44:33.0000] <Domenic_>
but then again i guess the es spec generally just says "do this" and implementations are like "i'll do something vaguely like that, but probably completely different under the covers, as long as the semantics are the same."

[07:44:37.0000] <annevk>
there's a whole bunch of these things we'll have to sort out in due course

[07:44:43.0000] <annevk>
for a whole lot of objects

[07:44:51.0000] <annevk>
I'm not too worried about this one right now

[07:45:01.0000] <Domenic_>
fair

[07:45:13.0000] <Domenic_>
i think the this.constructor thing would be nice to get in soon though

[07:46:23.0000] <annevk>
yeah, have to see what heycam|away has to say to the IDL bugs, and bz

[07:46:41.0000] <annevk>
Domenic_: I guess I could indicate the intent for now

[07:51:09.0000] <annevk>
TabAtkins: emailed www-style, figured I didn't need to add you in To: since it's kinda the same thing :p

[07:51:34.0000] <TabAtkins>
Yes, it's actually preferable that you don't, so I get the list version of the mail and can get at the archived-at header if necessary.

[07:54:50.0000] <annevk>
TabAtkins: in replies, it's preferable you copy me, as I'm not on the list

[07:54:56.0000] <TabAtkins>
kk

[07:55:05.0000] <TabAtkins>
gmail does that automatically, so that's fine.

[08:02:53.0000] <TabAtkins>
Domenic_: Yeah, the "black box" clause is always in effect - you can do whatever you like, as long as it's not observably different from what the spec requires.

[09:29:08.0000] <smaug____>
wycats: I assume http://w3ctag.github.io/jsidl/jsidl.html isn't updated actively anymore?

[09:29:45.0000] <wycats>
It will be shortly

[09:30:06.0000] <wycats>
Domenic_ is working on it

[09:30:31.0000] <wycats>
ES6 deadlines are consuming my available time atm

[09:30:45.0000] <Domenic_>
indeed. sidetracked by promises-unwrapping but that has quieted.

[09:31:04.0000] <wycats>
same with dherman, who is also helping

[09:31:22.0000] <wycats>
Domenic_: psyched that you'll be at TC39

[09:31:44.0000] <annevk>
Domenic_: I feel like Streams would be a more effective use of your time ^_^

[09:31:59.0000] <Domenic_>
annevk: oh right, hrmmmm

[09:32:03.0000] <Domenic_>
dammit i need a standards job

[09:32:15.0000] <Domenic_>
basically i need annevk's job

[09:33:51.0000] <smaug____>
Domenic_: some reasoning in the spec would be nice

[09:33:58.0000] <smaug____>
in the spec or elsewhere

[09:34:09.0000] <smaug____>
would be easier to understand why that is needed when we have webidl spec too

[09:34:16.0000] <Domenic_>
smaug____: yeah definitely.

[09:34:49.0000] <Domenic_>
smaug____: I do like annevk's idea of nudging WebIDL more JS-ward though in the meantime.

[09:35:19.0000] <annevk>
smaug____: basically, there's an ever growing mismatch between IDL and JS; I don't really care how we fix that gap, but we need to fix it

[09:35:43.0000] <smaug____>
(currently I think some people just don't like some aspects of WebIDL, so another idl spec is need. But I could be very wrong , since I don't know where to read the reasoning. )

[09:36:19.0000] <smaug____>
annevk: that "ever growing mismatch between IDL and JS" is not clear to me

[09:36:19.0000] <annevk>
My bet is that fixing IDL is better, because IDL is implemented so the implications of changes are more apparent, but I'm not opposed to a dual strategy.

[09:36:35.0000] <smaug____>
I mean, is there a list of mismatches somewhere

[09:36:38.0000] <Domenic_>
i think people don't realize how far off WebIDL is from JS

[09:36:43.0000] <smaug____>
and reasoning why something is a mismatch

[09:36:44.0000] <Domenic_>
smaug____: that would be a good idea

[09:36:52.0000] <annevk>
smaug____: e.g. subclassing of JavaScript types is not possible, defining reusable prototype methods as JavaScript does is not really possible

[09:37:33.0000] <annevk>
smaug____: a bunch of it is mostly due to changes in ES6, granted

[09:39:10.0000] <Domenic_>
well, before ES6, subclassing JS types was impossible :)

[09:39:40.0000] <Domenic_>
but yeah other things like argument defaulting semantics were clarified in ES6 whereas there were only 5 or 10 examples in the ES5 spec.

[09:41:39.0000] <smaug____>
I assume these idl changes would be still backwards compatible

[09:43:01.0000] <annevk>
smaug____: right

[09:43:33.0000] <annevk>
smaug____: potentially marking existing constructs "legacy" as we've done in the past if we really want something else and it's breaking

[09:43:55.0000] <Domenic_>
my hope would be to make all the backward-compat exceptions to ES semantics move to prose, but that might not be palatable by implementers, so a bevvy of [LegacyDefaultingSemantics] etc. annotations might be the way to go.

[09:43:56.0000] <annevk>
smaug____: not breaking the web is something TC39 shares

[09:44:39.0000] <Domenic_>
it's unclear though what's breaking, e.g. WebIDL is continually debating changing their function .length algorithm, so i guess they are assuming that doesn't break anything.

[09:44:39.0000] <annevk>
Domenic_: also consider people writing the specs, it'd be a lot of work to rewrite all those algorithms

[09:44:56.0000] <Domenic_>
annevk: for sure. it has to be usable to be useful.

[09:44:59.0000] <annevk>
Domenic_: breaking is measured by testing

[09:45:11.0000] <annevk>
Domenic_: ship and back out and such

[09:45:30.0000] <Domenic_>
annevk: yeah but deciding whether it's worth the time to try shipping is the step i'm talking about

[09:46:14.0000] <annevk>
Ah, that's cost benefit analysis

[09:46:16.0000] <Domenic_>
e.g. .length changes are presumed unlikely to break so they'll probably try it. Whereas I'm not so sure about switching from `null` to `undefined` as default-triggerer, that seems like it might not be possible.

[09:46:33.0000] <annevk>
A lot of people use null

[09:46:41.0000] <smaug____>
but how much of the old stuff would  be "[legacy]"? It would be rather bad to end up to a situation where the platform has rather inconsistent semantics because of lots stuff  is legacy and new stuff uses some other setup

[09:47:28.0000] <annevk>
smaug____: I think that's largely an unknown at this point

[09:47:32.0000] <Domenic_>
smaug____: unclear. but, is inconsistent with ES/consistent with itself better than the other way around?

[09:47:40.0000] <smaug____>
right, that is what I expected :)

[09:47:59.0000] <annevk>
If everything outside ES is consistent, maybe ES should change

[09:48:21.0000] <annevk>
I doubt that though

[09:48:22.0000] <Domenic_>
nah user-space libraries and ES are generally consistent

[09:49:49.0000] <bradleymeck>
ok, so, who do I talk to about host objects having getters/setters/properties and DOM attributes not matching up for various fun stuff like MutationObservers and tabIndex. spent some time a couple months back writing to the mailing list and basically got aback a  "thats the way it works" so, onto round 2

[09:50:37.0000] <smaug____>
bradleymeck: you mean stuff like inputelement.value vs. <input value=""> ?

[09:51:11.0000] <bradleymeck>
the controls not matching up with change events is a big one, yes

[09:52:41.0000] <smaug____>
well, .value handling can't be changed, and MutationObserver is about changes to DOM...so I'm not sure there is much to discuss there, unless you have some great proposal :)

[09:53:32.0000] <Domenic_>
bradleymeck: the problem is "don't break the web"; we can't change the value attribute to suddenly not be retarded.

[09:53:50.0000] <Domenic_>
bradleymeck: but most new attributes seem to work fine, e.g. <details> open attribute and .open property stay in sync.

[09:54:12.0000] <Domenic_>
this kind of sucks though since you can use MutationObserver on <details> but not on <input> :(

[09:59:54.0000] <bradleymeck>
well I don't want to change it from a getter, but setting does already tie into a change event, so I am looking more towards having a way for events hook into mutation observers

[10:00:34.0000] <bradleymeck>
cause the JS side notifying the DOM tree that something important has happened seems an ok use case

[10:01:35.0000] <Domenic_>
i am not sure i get it... you're talking about firing synthetic events on DOM elements?

[10:03:35.0000] <bradleymeck>
Domenic_: i guess you could say it that way, notification for MutationObservers only, not quite full events

[10:04:05.0000] <Domenic_>
oh i think i see, so, artificially trigger a mutation observer callback?

[10:04:33.0000] <bradleymeck>
yes

[10:04:38.0000] <smaug____>
well, for now you could just call the callback manually

[10:04:49.0000] <smaug____>
but we could add a getter for the callback

[10:04:58.0000] <bradleymeck>
but detecting which mutation observers are observing a node?

[10:05:37.0000] <smaug____>
bradleymeck: you want something like https://bugzilla.mozilla.org/show_bug.cgi?id=912874 ?

[10:06:01.0000] <smaug____>
(in Gecko that is available for chrome code only, not for web pages)

[10:07:11.0000] <smaug____>
(the API in bug 912874 isn't super pretty but gives what devtools needed)

[10:08:13.0000] <bradleymeck>
you could perform this using MutationObserver enumeration, but I am hesitant about exposing what mutation observers are looking at a node, just sending a new MutationRecord to any observer listening to a node would seem less scope creep

[10:08:54.0000] <smaug____>
bradleymeck: the additions to MutationObserver let's one to get the callback

[10:09:07.0000] <smaug____>
you can skip the change to Node :)

[10:09:29.0000] <bradleymeck>
something akin to EventTarget.dispatchEvent(VirtualMutationEvent) was what I was thinking

[10:10:00.0000] <smaug____>
oh, you want virtual MutationRecords

[10:10:01.0000] <bradleymeck>
cause telling people to iterate when a scripting property is the authority for mutation might be ugly

[10:12:02.0000] <bradleymeck>
it does not need to have bubble / propagation / etc, so I am unsure it should be an event even

[10:12:09.0000] <smaug____>
bradleymeck: something like somenode.notifyMutationObservers(new MutationRecord({type: "attributes", target: somenode, attributeName: "value"}))

[10:12:24.0000] <bradleymeck>
yes

[10:12:50.0000] <smaug____>
or, perhaps no need for MutationRecord ctor, dictionary would be enough

[10:12:59.0000] <bradleymeck>
but since it is virtual I would constrain type, this should only be talking about the host object not the DOM side

[10:13:34.0000] <bradleymeck>
then we don't have to confuse attributes on host vs attributes on dom itself

[10:15:26.0000] <bradleymeck>
and we only really need this since history about change events and value attributes sigh

[10:16:39.0000] <Domenic_>
bradleymeck: right, sounds like your use case is firing artificial changes for `attributeName: "value"` from the `"input"` event, so that value behaves like everything else. opt-in fixing of `value` with respect to MutationObserver.

[10:17:14.0000] <bradleymeck>
thats the basic idea

[10:19:05.0000] <Domenic_>
seems great, now we just need to get the attention of whoever's in charge of mutationobservers. I think they're in DOM now, so maybe annevk?

[10:19:15.0000] <Domenic_>
(gtg, rejectjs afterparty.)

[10:38:23.0000] <annevk>
Domenic_: they've always been in DOM, I thought we were going to wait for Object.observe()?

[10:39:15.0000] <bradleymeck>
annevk: are you talking about mutation observers?

[10:40:08.0000] <annevk>
bradleymeck: yeah

[10:41:01.0000] <annevk>
bradleymeck: just read scrollback, I suppose we could consider synthetic changes, not sure exactly what the best way forward is

[10:41:22.0000] <annevk>
bradleymeck: would you mind filing a bug against http://dom.spec.whatwg.org/ (link at the top) with some more detail? Emailing is fine too

[10:44:03.0000] <bradleymeck>
I can write up the history reasoning etc. tonight

[10:45:08.0000] <bradleymeck>
thanks annevk

[10:45:37.0000] <annevk>
bradleymeck: cool

[10:46:14.0000] <Hixie_>
annevk: what i meant by referencing SVG was e.g. http://hixie.ch/tests/adhoc/svg/use/001-with-base.html

[10:46:40.0000] <Hixie_>
annevk: chrome in particular is interesting on that test, since it does what we're talking about doing for everything _but_ hyperlinks

[10:46:44.0000] <Hixie_>
[24~in svg

[10:46:58.0000] <annevk>
Hixie_: ah, bz mentioned that too

[10:47:02.0000] <annevk>
my bad

[10:47:10.0000] <Hixie_>
anyway, i would imagine that anything we do here would happen for everything, not just links in one place

[10:47:24.0000] <Hixie_>
but i guess this is a url spec thing, so i'll leave you that thread :-)

[10:47:37.0000] <annevk>
potentially affects all callers

[10:47:41.0000] <annevk>
but yeah

[10:47:53.0000] <annevk>
I mostly feel inertia is like "meh"

[10:47:56.0000] <annevk>
fear*

[10:49:07.0000] <Hixie_>
yeah i admit i don't really care about what happens with <base>

[10:49:39.0000] <Hixie_>
what we're doing is pretty obviously bad, but i don't know what one would do about it

[10:49:56.0000] <Hixie_>
the alternative is pretty magical, and not in the ooooh shiny way

[10:50:59.0000] <Hixie_>
as to your other thread... i guess if resolving a url punycodes it already, then every address would already by punycoded, so it's a moot point

[10:51:20.0000] <Hixie_>
so i'll leave that as is for now

[10:52:56.0000] <annevk>
I did the thing you suggested btw and picked IDNA2003

[10:53:05.0000] <annevk>
turns out most people didn't like that, even though it's the most compatible

[10:53:32.0000] <annevk>
but then there's no real agreement on a replacement other than some variant of UTS #46 that might change over time

[10:54:25.0000] <Hixie_>
what do browsers do?

[10:55:00.0000] <Hixie_>
if they do what you specced, then people like it, by definition :-)

[11:02:18.0000] <annevk>
Hixie_: turns out no

[11:03:08.0000] <Hixie_>
they don't do what you specced? what do they do?

[11:04:23.0000] <annevk>
Hixie_: browsers do IDNA2003, except for IE11, which does some variant of UTS #46; Gerv from Mozilla is pushing another variant of UTS #46; Jungshik and Mark from Google want some variant of UTS #46, potentially more restrictive over time

[11:04:55.0000] <annevk>
Hixie_: nobody is being very specific about the exact details of UTS #46 and clarifying the issues it has now

[11:05:07.0000] <annevk>
Hixie_: thread might revive in a bit once people are back from vacation, we'll see

[11:05:07.0000] <Hixie_>
all i heard there is "browsers do IDNA2003", and that's what matters. :-)

[11:05:29.0000] <Hixie_>
people can "push" anything they want, but if it doesn't get implemented, it's entirely academic

[11:05:37.0000] <Hixie_>
the IETF "pushed" IDNA2008 or whatever it's called

[11:06:22.0000] <annevk>
yeah, UTS #46 is an IDNA2003-compatible variant of IDNA2008

[11:06:56.0000] <annevk>
registrars are adopting IDNA2008 too, it's a mess

[11:07:47.0000] <Hixie_>
that just changes what you can put in a second-level domain label, right?

[11:13:34.0000] <Hixie_>
annevk: is the "iterators intead of live NodeLists" thread one you can deal with? looks like DOM Core stuff

[11:14:23.0000] <dglazkov>
good morning, Whatwg!

[11:17:47.0000] <Hixie_>
i'm assuming the thread "BinaryEncoding for Typed Arrays using window.btoa and window.atob" is feedback on http://encoding.spec.whatwg.org/#textencoder and am therefore not responding to that either

[11:26:58.0000] <annevk>
Hixie_: apparently they're considering obsoleting your portal domain too

[11:27:02.0000] <annevk>
Hixie_: they don't care

[11:27:23.0000] <Hixie_>
i don't think any browsers actually show the smiley anyway

[11:27:28.0000] <Hixie_>
but yeah, i know. they're lame.

[11:27:30.0000] <Hixie_>
boo.

[11:27:39.0000] <annevk>
Hixie_: and seemingly inmume to http://www.w3.org/Provider/Style/URI.html

[11:28:12.0000] <annevk>
Hixie_: yeah, both of those are on my radar

[11:31:34.0000] <Hixie_>
who specs window.devicePixelRatio these days?

[11:33:57.0000] <annevk>
/me nominates zcorpan

[11:34:49.0000] <Hixie_>
makes sense

[12:00:20.0000] <bkardell__>
Hixie: 140 characters is hard ... moving question over here

[12:01:23.0000] <bkardell__>
Hixie_: page A is in example.com, it contains an iframe to page B in example.org - that page (B) has a manifest

[12:02:01.0000] <bkardell__>
Hixie_: B's manifest lists file X.js (in example.org) in both CACHE: and NETWORK:

[12:04:09.0000] <Hixie_>
what's the question?

[12:04:14.0000] <bkardell__>
Hixie_: now page B requests X.js via xhr.  What should happen?

[12:04:27.0000] <Hixie_>
it gets it from the cache, like i said on twitter :-)

[12:04:37.0000] <Hixie_>
is the spec not clear?

[12:04:40.0000] <bkardell__>
Hixie_: but origin is null?

[12:04:44.0000] <Hixie_>
origin?

[12:06:15.0000] <bkardell__>
Hixie_: So there is no problem with page B xmlhttprequest acessing cache when it is in iframe from another page/diff domain?

[12:06:40.0000] <Hixie_>
i don't understand how the iframe changes anything. what in the spec makes you think it might?

[12:07:33.0000] <bkardell__>
/me tries to find logical response

[12:08:34.0000] <bkardell__>
Hixie_: In figuring something out, I thought I understood some things

[12:08:47.0000] <bkardell__>
Hixie_: Browsers in some cases aren't cooperating

[12:09:05.0000] <bkardell__>
Hixie_: Basically trying to figure out which is bug and which is me misunderstanding

[12:09:10.0000] <Hixie_>
heh

[12:09:20.0000] <Hixie_>
if there's a test case i can look at, that might bmake this easier :-)

[12:09:25.0000] <bkardell__>
ah!

[12:09:42.0000] <bkardell__>
Hixie_: I forgot to mention it was sandboxed?

[12:09:56.0000] <Hixie_>
oh! well

[12:10:02.0000] <Hixie_>
if it's sandboxed

[12:10:05.0000] <Hixie_>
all bets are off

[12:10:06.0000] <bkardell__>
haha!

[12:10:08.0000] <Hixie_>
what's the sandbox="" value?

[12:10:13.0000] <bkardell__>
right!

[12:10:27.0000] <Hixie_>
just allow-scripts?

[12:10:30.0000] <bkardell__>
no

[12:10:34.0000] <bkardell__>
allow-same-origin too

[12:10:58.0000] <Hixie_>
sandbox="allow-scripts allow-same-origin"?

[12:11:02.0000] <Hixie_>
that's generally a foot gun, but ok

[12:11:12.0000] <Hixie_>
i guess if you're loading a cross-origin file you're probably ok

[12:11:22.0000] <bkardell__>
hmm

[12:11:50.0000] <bkardell__>
just checked to make sure I didn't lie with all of the changes I made trying to figure this out

[12:12:01.0000] <bkardell__>
indeed, this iframe is not even sandboxed!

[12:12:25.0000] <Hixie_>
if you have allow-scripts allow-same-origin, or if you're not sandboxed at all, i don't see why there'd be a problem

[12:12:28.0000] <bkardell__>
ok, I will make a way stripped down test case with nothing but that and see if I can illustrate

[12:12:41.0000] <Hixie_>
if you're not allow-same-origin, then i think it's likely appcache will just fail

[12:12:49.0000] <bkardell__>
how much have you played with actual implementations of this?

[12:12:52.0000] <Hixie_>
but i'd have to audit the spec to be sure one way or the other on that

[12:12:57.0000] <Hixie_>
not... as much as you'd expect

[12:13:00.0000] <bkardell__>
;)

[12:13:23.0000] <Hixie_>
in particular, not the combination of both

[12:13:50.0000] <bkardell__>
so like, mozilla is currently blocking idb access in all iframes in a diff origin regardless of any of this

[12:13:59.0000] <Hixie_>
i don't have many uses for sandboxing in my apps, and while appcache would be perfect for my projects, it's something i avoid doing until my apps are done, and, well, my apps are never done

[12:14:13.0000] <bkardell__>
basically, it works just like being sandboxed without the allow-same-origin in that respect

[12:14:24.0000] <Hixie_>
that's probably due to third-party cookie blocking

[12:14:29.0000] <bkardell__>
it is

[12:14:35.0000] <bkardell__>
but localStorage works..?

[12:15:05.0000] <bkardell__>
there is a bug, they'll address... it made more sense when they did it, but in retrospect, no

[12:15:33.0000] <bkardell__>
ok, let me see if I can make a simple stupid test to get to the bottom of this

[12:15:53.0000] <bkardell__>
I think when you combine these + browsers - there is incompat at the edges

[12:16:06.0000] <bkardell__>
significant in some cases

[12:16:19.0000] <bkardell__>
thx

[12:18:01.0000] <Hixie_>
good luck

[13:13:06.0000] <zcorpan>
TabAtkins: i've been confused about the order argument because as far as i recall the discussion in both email and f2f was like "the set is unordered, this doesn't work for margin-start." "the set is ordered already." "yes." "..."

[13:13:52.0000] <TabAtkins>
I see why you're confused.  The underlying declaration block is ordered, yes.  The API exposed by gCS's return value, though, looks unordered.

[13:14:08.0000] <TabAtkins>
Since it's just an object map, iterated in alphabetical order.

[13:14:32.0000] <zcorpan>
the return value of getComputedStyle is not relevant since it's readonly so setProperty throws

[13:15:25.0000] <TabAtkins>
Sure, but the same is true of el.style.

[13:15:31.0000] <zcorpan>
no

[13:16:31.0000] <zcorpan>
el.style uses what cssom calls 'specified order', and setProperty either appends a new declaration to the end or updates a declaration's value without moving it in the list

[13:17:11.0000] <TabAtkins>
You can only observe that by iteration, though.

[13:17:17.0000] <TabAtkins>
That's a very weak form of ordering.

[13:17:30.0000] <TabAtkins>
The normal interaction mode with it is as an object map, which is effectively unordered.

[13:18:31.0000] <zcorpan>
yes? i'm still confused

[13:19:00.0000] <zcorpan>
does setProperty need to move an existing declaration to the end, or not? and why?

[13:21:41.0000] <TabAtkins>
My point is just that things like Arrays are strongly, observably ordered.  Maps are weakly ordered at best, with the order only observable through iteration.

[13:22:06.0000] <zcorpan>
ok

[13:22:23.0000] <TabAtkins>
Basing semantics on a strongly-ordered set when it's usually exposed as a weakly-ordered thing isn't a great idea.  That's why I still don't really like the resolution from the f2f, but I got something usable (setPropertyValue), so I can accept it.

[13:23:02.0000] <TabAtkins>
So to answer your question, I dunno.

[13:23:34.0000] <zcorpan>
k

[13:25:43.0000] <Hixie_>
bummer, i paged the parser out already and now i don't understand why we have "template" end tag entries everywhere

[13:26:04.0000] <Hixie_>
and why "template"'s end tag is handled in "in head" and not in "in template".

[13:47:58.0000] <krit>
Hixie_: [CORS] says it references Cross-origin Resource Sharing but references Anne's fetch spec. The fetch spec does not describe terms like "omit credentials flag" as noted in http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#omit-credentials-flag (just as one example)

[13:48:18.0000] <Hixie_>
odd

[13:48:24.0000] <Hixie_>
why would anne drop the term

[13:48:38.0000] <Hixie_>
oh i don't use it anyway

[13:48:53.0000] <Hixie_>
any other examples?

[13:49:13.0000] <Hixie_>
looks like all those terms aren't used

[13:49:24.0000] <Hixie_>
wait wait wait

[13:49:33.0000] <Hixie_>
i was looking at a subset of the spec

[13:49:34.0000] <Hixie_>
duh

[13:49:39.0000] <Hixie_>
/me tries again

[13:50:12.0000] <krit>
Hixie_: hm, looks like the names are just slighlt off. cmd+f searched for the whole term

[13:50:23.0000] <Hixie_>
oh i'm guessing this is all gonna change once we reference his Fetch algorithm instead of defining our own

[13:50:26.0000] <bkardell__>
/me is happy hixie made a similar mistake just now to the one he made earlier

[13:50:38.0000] <Hixie_>
hehe

[13:51:00.0000] <Hixie_>
krit: the plan is to completely revamp how HTML does fetch once anne's spec is ready to take over

[13:51:08.0000] <Hixie_>
krit: so i'm ignoring this problem for now

[13:51:12.0000] <krit>
:)

[13:52:11.0000] <krit>
Hixie_: Question to SVG image fetching. SVG images can have resources them self (like references to other images)

[13:52:20.0000] <Hixie_>
TabAtkins: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22118

[13:52:23.0000] <krit>
Hixie_: is there a defined restriction?

[13:52:38.0000] <Hixie_>
krit: i don't understand the question

[13:53:19.0000] <krit>
<img src="image.svg"> -> <svg><image xlink:href="image2.svg"/></svg>

[13:53:50.0000] <krit>
Hixie_: is image.svg allowed to fetch image2.svg?

[13:54:37.0000] <Hixie_>
that seems like an SVG question?

[13:54:41.0000] <krit>
Hixie_: or the following <img src="image.svg"> -> <svg><foreignObject><iframe src="index.html"/></foreignObject></svg>

[13:54:50.0000] <Hixie_>
i think <img> stops scripts in SVG, but that's all

[13:55:00.0000] <Hixie_>
check the spec

[13:55:15.0000] <krit>
Hixie_: I know that it is not specified in SVG :)

[13:55:36.0000] <krit>
Hixie_: but sounds like it wouldn't be anywhere else

[13:56:57.0000] <Hixie_>
check HTML's <img> section

[14:02:06.0000] <krit>
Hixie_: "the img element's crossorigin attribute's mode, and, if that mode is not http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#attr-crossorigin-none" but I can not find the initial value of 'crossorigin' attribute. Just the defintion for this attribute

[14:02:21.0000] <Hixie_>
"initial value"?

[14:02:57.0000] <krit>
well, if it is not set, I assume it is No CORS, right?

[14:03:32.0000] <krit>
Hixie_: the algorithm for resolving states that it needs to identify an image by a topple

[14:03:33.0000] <Hixie_>
don't assume :-)

[14:03:55.0000] <krit>
Hixie_: and one part of the toople is the value of crossorigin attribtue

[14:03:56.0000] <Hixie_>
"The crossorigin attribute is a CORS settings attribute." => http://www.whatwg.org/specs/web-apps/current-work/#cors-settings-attribute

[14:04:16.0000] <Hixie_>
"A CORS settings attribute is an enumerated attribute." => http://www.whatwg.org/specs/web-apps/current-work/#enumerated-attribute

[14:04:37.0000] <krit>
Hixie_: ok, thanks

[14:04:40.0000] <Hixie_>
"When the attribute is not specified, if there is a missing value default state defined, then that is the state represented by the (missing) attribute."

[14:04:54.0000] <Hixie_>
then back to CORS setting attribute: "The missing value default, used when the attribute is omitted, is the No CORS state."

[14:16:43.0000] <krit>
Hixie_: yes, it is defined. Couldn't find it on the first try. But didn't see that there is another link to "CORS settings attribute"

[14:30:35.0000] <zcorpan>
krit: crossorigin="" seems unrelated to the question you asked

[14:31:40.0000] <krit>
zcorpan: to the SVG example? yes. But I was trying to understand the algorithm for fetching. And this was a requirement.

[14:31:52.0000] <zcorpan>
ah, ok

[14:32:40.0000] <zcorpan>
i think the svg spec should define what the behavior should be when loaded via <img> or css background-image and similar

[14:34:30.0000] <krit>
zcorpan: I do not disagree. I wanted to check what already is defined and what isn't.

[14:43:51.0000] <jamesr_`>
Hixie_: when does invoking the parser spin the event loop?

[14:57:09.0000] <Hixie_>
jamesr_`: when parsing scripts

[14:57:11.0000] <gsnedders>
GPHemsley: https://github.com/html5lib/html5lib-tests/tree/master/sniffer may be of interest to you

[14:57:35.0000] <gsnedders>
GPHemsley: I may well remove that from html5lib-tests soon. It's been unused for years and miles off the spec nowadays.

[14:57:43.0000] <zcorpan>
Hixie_: i didn't file https://www.w3.org/Bugs/Public/show_bug.cgi?id=22488

[14:57:48.0000] <Yuhong>
annevk: Fortunately, I don't think legacy encodings are something that changes much once it is specced.

[14:58:05.0000] <Hixie_>
zcorpan: yeah, that's why i removed the whiteboard thing

[14:58:26.0000] <zcorpan>
oh, ok

[14:58:35.0000] <Hixie_>
instead of pinging you here

[14:58:47.0000] <Hixie_>
/me hopes anne checks his bugmail

[14:58:52.0000] <Hixie_>
(i marked several of his bugs NEEDSINFO)

[15:20:50.0000] <zcorpan>
re devicePixelRatio, filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23228

[16:10:34.0000] <GPHemsley>
gsnedders: It doesn't look like there's much there

[16:10:52.0000] <gsnedders>
GPHemsley: There isn't. :)

[16:13:29.0000] <jamesr_`>
Hixie_: just for the wait-for-blocking-stylesheets behavior?

[16:13:50.0000] <jamesr_`>
i don't think we implement that as the text is written, but i think it only matters when doc.writing() from somewhere not in a <script>

[16:14:01.0000] <jamesr_`>
will have to ponder how to actually test that


2013-09-13
[00:48:20.0000] <annevk>
WHATWG has more followers than commits again

[00:54:04.0000] <annevk>
Hixie_: fwiw, it's fine to call something delete()

[01:03:49.0000] <zcorpan>
are css variables scoped to the stylesheet they're declared in?

[02:05:06.0000] <annevk>
zcorpan: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23234 on the XMLHttpRequest issue you found btw

[02:05:41.0000] <zcorpan>
annevk: ok. didn't know whether it was intentional

[02:05:41.0000] <annevk>
zcorpan: hah, entire spec doesn't include the word "scope"

[02:06:33.0000] <annevk>
zcorpan: it seems I expect HTML to take care of that, but parsing algorithm there doesn't actually return a Document or take a Document to modify

[02:06:41.0000] <annevk>
zcorpan: which might be a bug in HTML...

[02:06:59.0000] <zcorpan>
fantasai said they're scoped to all stylesheets that apply to a particular document, but are also scoped to elements, due to being defined as acting like normal properties that cascade and inherit

[02:08:53.0000] <MikeSmith>
from reading the parsing algorithm, I find that the HTML parser never does any special conversion of U+000C, right?

[02:09:11.0000] <MikeSmith>
I mean as far as normalizing it into a newline or whatever

[02:09:45.0000] <zcorpan>
MikeSmith: i think that's right

[02:10:16.0000] <MikeSmith>
zcorpan: OK, thanks

[02:10:48.0000] <zcorpan>
the preprocessor doesn't do anything with it, the tokenizer lets it through

[02:10:54.0000] <MikeSmith>
OK

[02:11:53.0000] <MikeSmith>
I notice in contrast that the CSS Syntax spec requires CSS parsers to change it to newline

[02:11:55.0000] <zcorpan>
and http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inbody inserts it

[02:12:04.0000] <zcorpan>
yeah

[02:12:16.0000] <MikeSmith>
/me reads

[02:16:43.0000] <zcorpan>
MikeSmith: so in CSS a newline isn't exposed in any way, so whether the preprocessor converts it or the the tokenizer handles it is purely an impl choice, and the spec picks one of them

[02:17:12.0000] <MikeSmith>
ah, OK

[02:17:27.0000] <MikeSmith>
makes sense

[02:22:36.0000] <annevk>
"I visited the top 10 websites according to https://en.wikipedia.org/wiki/List_of_most_popular_websites. For each page, if I could locate a searchbox, I typed "cats". I'm more of a dog person but we're trying to simulate a typical internet user."

[02:22:59.0000] <annevk>
<3

[02:27:29.0000] <MikeSmith>
heh

[02:30:38.0000] <hober>
heh

[02:36:44.0000] <zcorpan>
annevk: where's that quote from?

[02:36:52.0000] <annevk>
zcorpan: blink-dev

[02:41:03.0000] <darobin_>
/me wonders if searching for dogs breaks the web

[02:42:49.0000] <annevk>
zcorpan: how do setProperty et al interact with shorthands?

[02:44:05.0000] <annevk>
Hixie_: I read my bug email, not planning on reopening for now as I don't have the info

[02:44:24.0000] <MikeSmith>
zcorpan: r? https://critic.hoppipolla.co.uk/r/309 https://github.com/w3c/web-platform-tests/pull/328

[02:45:07.0000] <annevk>
Btw, I wrote up http://wiki.whatwg.org/wiki/Zip#URLs yesterday. I would appreciate some feedback as to what other topics are worthy of consideration given these alternatives.

[02:51:58.0000] <MikeSmith>
jgraham: if I push the "Prepare Rebase" button at https://critic.hoppipolla.co.uk/r/308 does it do a squash first?

[02:54:19.0000] <MikeSmith>
hmm from reading https://critic.hoppipolla.co.uk/tutorial?item=rebase I guess not

[02:55:41.0000] <zcorpan>
annevk: setProperty with a shorthand runs setProperty for each longhand with the appropriate value for each

[02:57:52.0000] <annevk>
zcorpan: internal algorithm or actually invokes?

[02:59:04.0000] <zcorpan>
annevk: internal algorithm. "When a method or an attribute is said to call another method or attribute, the user agent must invoke its internal API for that attribute or method so that e.g. the author can't change the behavior by overriding attributes or methods with custom properties or functions in ECMAScript."

[02:59:25.0000] <zcorpan>
annevk: i'll change the spec to separate the algorithms so this is clearer

[03:00:50.0000] <zcorpan>
filed a bug

[04:16:48.0000] <annevk>
krit: I can explain more here if you want, but it sounds like you got the model backwards

[04:31:42.0000] <krit>
annevk: sure, yes please do!

[04:32:14.0000] <annevk>
krit: well, I guess I'd have to know what was unclear in my last email

[04:32:52.0000] <krit>
annevk: well, first when do you do fetching? From your last mail, it is just when you have external resources?

[04:33:58.0000] <zcorpan>
does anyone have a pointer to the spec that defines Navigation Controller, if it exists (publicly)?

[04:34:30.0000] <hober>
zcorpan: there isn't one

[04:34:39.0000] <zcorpan>
ok, thanks

[04:34:39.0000] <hober>
zcorpan: at least, not at w3c or whatwg

[04:34:42.0000] <annevk>
krit: fetching happens when the spec says to do fetching

[04:34:59.0000] <annevk>
krit: e.g. for <img> it happens when the element is inserted into the document

[04:35:28.0000] <krit>
annevk: ok, sure. Fetch itself is passive and needs to be triggered

[04:36:01.0000] <annevk>
krit: it's not really clear to me how the fragment stuff works in SVG, I'd have thought you'd know

[04:36:29.0000] <annevk>
zcorpan: https://github.com/slightlyoff/EventWorker/

[04:36:32.0000] <krit>
annevk: lets keep it at images first

[04:36:57.0000] <krit>
annevk: You fetch an SVG. Fetching is invoked by <img> tag

[04:37:21.0000] <krit>
annevk: this SVG has "references" to other images

[04:37:21.0000] <annevk>
krit: that's kinda backwards thinking already

[04:37:29.0000] <annevk>
krit: you fetch something, turns out it's SVG

[04:37:38.0000] <annevk>
krit: is how it works

[04:37:40.0000] <zcorpan>
annevk: thx

[04:37:45.0000] <krit>
annevk: k

[04:38:26.0000] <annevk>
krit: you get SVG back so then the browser starts processing the SVG

[04:38:33.0000] <krit>
annevk: So this SVG would be marked as SVG image (for instance by flagging). Not by Fetch, but byt the algorithm of <img>

[04:38:46.0000] <krit>
annevk: and this would happen after recognizing it is an image

[04:38:46.0000] <annevk>
krit: yeah, I think that would be the way to do it

[04:39:29.0000] <krit>
annevk: k. So this SVG document has a flag now that it should not load further images

[04:39:32.0000] <annevk>
krit: you get a resource back, check if the MIME type is "image/svg+xml", then if it is you pass it to the SVG subsystem with an "image mode" flag which hands you back pixels

[04:40:02.0000] <krit>
annevk: yes. Getting into what SVG image does internally now

[04:40:27.0000] <krit>
annevk: Internally it is still an Document, which just happens to return pixels

[04:40:37.0000] <krit>
annevk: and this document is marked as "image mode"

[04:40:56.0000] <annevk>
krit: so the SVG processing model needs to account for this "image mode" flag, e.g. it does not execute script, does not iterate its event loop, does not fetch resources

[04:41:10.0000] <krit>
annevk: I agree

[04:41:26.0000] <krit>
annevk: now we have an SVG <image> element inside this "image" makred SVG document

[04:41:41.0000] <krit>
annevk: <image> now needs to check this flag

[04:42:00.0000] <krit>
annevk: it is "image" mode, so we have a restriction on fetching

[04:42:16.0000] <krit>
annevk: now the URL needs to be parsed

[04:42:36.0000] <krit>
annevk: and it happens to be an http URL

[04:42:58.0000] <krit>
annevk: in this case SVG needs to specify that we get a network error, right?

[04:43:16.0000] <annevk>
krit: yeah, I imagine SVG would define "SVG fetch"

[04:43:51.0000] <krit>
annevk: lets come back to SVG fetch after understanding the concept… because if you don't write the spec for it it is sadly me :D

[04:44:14.0000] <annevk>
which has these steps: 1. If mode is "document mode", return the result of fetch with the same arguments. 2. Magic.

[04:44:39.0000] <krit>
annevk: exactly step 2: magic...

[04:44:51.0000] <krit>
annevk: network error on htttp requests

[04:44:57.0000] <krit>
annevk: is that about right?

[04:45:01.0000] <krit>
(so far)

[04:45:27.0000] <annevk>
Well, I guess the interesting case is fragment identifiers when there's no <base> getting in the way.

[04:46:06.0000] <krit>
annevk: ah right, first we need to resolve the absolute URL, right?

[04:46:20.0000] <annevk>
Apart from the fragment identifer case. Step 2 would be to termine if URL's scheme is not "about" or "data".

[04:46:22.0000] <krit>
annevk: so if http request, create absolute URL

[04:46:35.0000] <annevk>
Parsing the URL happens before Fetch.

[04:46:44.0000] <krit>
annevk: right, ok

[04:47:28.0000] <krit>
annevk: so lets exclude blob for now, we just have about, data and http ?

[04:47:52.0000] <krit>
annevk: or better, just allow these three and reject all others.

[04:47:57.0000] <annevk>
krit: there's also file and ftp

[04:48:15.0000] <annevk>
krit: why would you allow http?

[04:48:24.0000] <annevk>
krit: I thought the whole point was to not have network requests?

[04:48:54.0000] <krit>
annevk: oh, you already do special casing during parsing?

[04:49:06.0000] <krit>
annevk: so you do not transform all URLs to absolute URLs?

[04:49:17.0000] <annevk>
krit: yes you do

[04:49:27.0000] <krit>
annevk: means you really check for about, data, or #

[04:49:34.0000] <krit>
annevk: and reject everything else

[04:50:31.0000] <krit>
annevk: I am not sure how useful "about" is, but I'll keep that in mind for later. Lets concentrate on the later two

[04:50:35.0000] <annevk>
Okay. So I need to know if the fragment case roundtrips through the network layer or not.

[04:51:21.0000] <krit>
annevk: # (if not resolved to absolute URL which would make sense in this case) should not go through the network layer

[04:51:29.0000] <krit>
annevk: at least it doesn't in implementations

[04:51:39.0000] <annevk>
I suspect this would be a better setup: 1. Parse /input/ against /base/ into /url/. 2. If /url/ has same-document fragments, deal. 3. Otherwise, SVG fetch /url/

[04:51:49.0000] <krit>
annevk: clarification, it doesn't for WebKit and Blink

[04:52:12.0000] <annevk>
I'm surprised SVG gets away with not defining critical infrastructure like this.

[04:52:17.0000] <annevk>
But I shouldn't be

[04:52:18.0000] <krit>
Ancil: as a general setup, ok makes sense

[04:52:39.0000] <annevk>
Back in an hour or so, lunch!

[04:52:42.0000] <krit>
annevk: no you shouldn't be. I think we rely that IRI specifies it for us

[04:52:47.0000] <krit>
annevk: k

[04:52:53.0000] <annevk>
No it doesn't

[04:52:57.0000] <krit>
:)

[05:24:43.0000] <darobin>
/me wonders if simply mentioning widgets counts as trolling

[05:33:15.0000] <TabAtkins>
zcorpan: No, css custom properties are properties.  They scope exactly the same way that any other property does.

[05:34:07.0000] <TabAtkins>
(That is, not at all.)

[05:34:16.0000] <TabAtkins>
(scoped stylesheets dont' scope properties, they scope selectors)

[05:39:28.0000] <annevk>
krit: FWIW, IRI (which is obsolete these days) defines no more than URL, i.e. parsing of a string

[05:42:49.0000] <krit>
annevk: I checked, So we define that certain attributes take an IRI (RFC3987) or an FuncIRI (special case of IRI) for many element xlink:href is referenced

[05:43:07.0000] <krit>
annevk: couldn't find another reference yet

[05:43:37.0000] <annevk>
krit: yeah, that's about the level of detail I would expect, which is to say nothing at all

[05:46:29.0000] <krit>
annevk: to come back to your parsing, you have 1. Parse /input/ against /base/ into /url/

[05:46:41.0000] <krit>
annevk: is that something that can be referenced?

[05:46:53.0000] <krit>
annevk: is it in url.spec.whatwg.org?

[05:48:52.0000] <annevk>
krit: http://url.spec.whatwg.org/#concept-url-parser

[05:50:40.0000] <krit>
annevk: k, SVG fetch: /data/

[05:51:14.0000] <annevk>
krit: you fetch a URL, it returns data

[05:54:25.0000] <krit>
annevk: ok, and from here it can be recursive…. if the data is an SVG interpreted as image, I set the "image" mode. This again just allows the current algorihtm on parsing and possibly fetching

[05:56:16.0000] <krit>
annevk: Now the case we do not have a dataURL and not a fragment in the same document

[05:56:27.0000] <krit>
annevk: in this case we do not fetch

[05:56:30.0000] <annevk>
krit: are you talking about <svg:image> referencing a data URL or some such?

[05:56:38.0000] <krit>
annevk: yes

[05:57:14.0000] <annevk>
krit: it's not really recursive, for <svg:image> you need to define what to do with the returned data, and I suppose you might want to vary that based on the "image mode"

[05:58:11.0000] <annevk>
krit: try to think specs the same way the code works; you need the same abstractions and concepts

[06:00:18.0000] <krit>
annevk: I am usually working on CSS, if you are not defining the Syntax, then you possibly justw want to specify the behavior, not the implementation :P

[06:00:25.0000] <krit>
annevk: but I get your point

[06:01:03.0000] <annevk>
krit: CSS has lot of these issues actually

[06:01:15.0000] <annevk>
krit: maybe it's epidemic

[06:01:54.0000] <krit>
annevk: hehe, possibly :)

[06:02:13.0000] <annevk>
(Though TabAtkins seems to fix it up, bit by bit.)

[06:02:28.0000] <krit>
annevk: thank you very much for your help so far. I'll work on the draft next week and will definitely poke you a lot then ;)

[06:02:49.0000] <krit>
annevk: yeah, Tab is fixing the web :)

[06:03:05.0000] <annevk>
krit: no worries, I'll be in Boston next week for TC39, so times will be a bit different

[06:03:32.0000] <krit>
annevk: I am back in europe. So no improvement :)

[06:04:24.0000] <annevk>
krit: you stay in France for a bit after the CSS WG? I thought you were based in SF for some reason...

[06:04:54.0000] <krit>
annevk: not based in SF anymore. Working from Germany now

[06:05:07.0000] <krit>
annevk: still working for the same team, just remotely :)

[06:05:15.0000] <annevk>
Ah I see, nice

[07:10:44.0000] <annevk>
So, did anyone take a look at this yet:

[07:10:45.0000] <annevk>
http://wiki.whatwg.org/wiki/Zip#URLs

[07:11:30.0000] <annevk>
I think zip-path is a clear winner. Incidentally I also once again had to became wiki-syntax master :/

[07:13:53.0000] <TabAtkins>
annevk: Have any guidance over what kinds of switches we would need to expose in a CSS "fetch(<url-string> <stuff-goes-here>)" function?

[07:14:49.0000] <annevk>
TabAtkins: I think that depends on how you solve that SVG thing I discussed a while back with roc and I think krit too

[07:15:12.0000] <TabAtkins>
Okay, so I'll need to read that.  Too many interesting discussion that happen while I'm minuting. :/

[07:15:22.0000] <annevk>
TabAtkins: http://lists.w3.org/Archives/Public/public-fx/2013AprJun/thread.html#msg17

[07:18:16.0000] <annevk>
TabAtkins: I think you want a way to opt into CORS, a way to opt out of credentials, and maybe a way to opt into CORS and credentials, not sure about this one (by default if someone opts into CORS you want him to opt out of credentials)

[07:19:31.0000] <annevk>
TabAtkins: but that above discussion is relevant, @font-face already opts into CORS so doesn't need this (other than maybe opting out of same-origin credentials)

[07:26:34.0000] <krit>
annevk: Wouldn't it be enough to have the same values as the crossorigin attribute on <img>? Or should it be more detailed?

[07:27:02.0000] <annevk>
krit: yeah, kinda depends on the use cases you have

[07:27:14.0000] <krit>
annevk: probably

[07:27:38.0000] <annevk>
krit: people have been asking about ways to opt out of credentials also for normal requests though

[07:28:15.0000] <annevk>
krit: it seems there's a few constructs in CSS where it would've been good to always do CORS, but e.g. for background-image I don't really know what the benefit would be

[07:28:55.0000] <annevk>
krit: well, maybe once we have that drawElement() API, then background-image would taint stuff cross-origin I suppose

[07:34:24.0000] <espadrine>
is there a test suite for css3-values?

[07:34:33.0000] <krit>
annevk: with drawElement() you mean element() ?

[07:35:37.0000] <annevk>
krit: no I meant for <canvas>

[07:36:06.0000] <annevk>
krit: don't think element() is a problem as it doesn't allow for reading

[07:36:07.0000] <krit>
annevk: oh, you want to draw an abritary element to a canvas?

[07:36:31.0000] <krit>
annevk: then you would need to taint the canvas

[07:36:38.0000] <annevk>
krit: I don't really, but there've been requests, Gecko supports drawing a document's canvas on a <canvas> etc.

[07:36:42.0000] <krit>
annevk: but I suppose that is why you want CORS

[07:37:07.0000] <krit>
what do you mean with document's canvas on a <canvas> ?

[07:37:26.0000] <krit>
annevk: oh, you mean the whole surface

[07:37:37.0000] <krit>
annevk: Gecko supports that?

[07:38:21.0000] <annevk>
krit: for extensions only

[07:38:44.0000] <krit>
annevk: ok

[07:39:06.0000] <krit>
annevk: Blink supports drawing ot SVG onto a canvas without tainting

[07:39:13.0000] <annevk>
krit: but yeah, otherwise I'm not sure what the point is to have fetch() for background-image, it seems that thread I referenced from public-fx has the only use case for it thus far

[07:39:41.0000] <annevk>
krit: yeah, that mostly requires SVG to define when it's clean and such

[07:39:42.0000] <krit>
annevk: yeah, I think so.

[07:40:09.0000] <annevk>
(plus the places that do "fetch()" implicitly already, such as @font-face)

[07:40:13.0000] <krit>
annevk: right, this is one reason I asked you all these questions. It must be defined for SVG now

[07:40:26.0000] <krit>
annevk: right

[07:40:41.0000] <annevk>
Yeah, drawImage(SVGElement) would be nice

[07:40:48.0000] <annevk>
Well, SVGSvgElement I suppose

[07:41:18.0000] <krit>
annevk: at the moment it is a whole SVG document that you need to load with ImageElement

[07:41:34.0000] <krit>
annevk: but there have been discussion about SVG subtrees

[07:42:17.0000] <krit>
annevk: but it was easier to estimate security concerns for the  former

[07:42:31.0000] <krit>
s/concerns/requirements.

[07:42:50.0000] <darobin>
actually, drawImage(SVGElement) would be nice

[07:43:10.0000] <darobin>
either infer the context from its parent <svg>, or maybe use the canvas to set up a viewport

[07:43:41.0000] <krit>
dbaron: right. But IIRC we still had some issues we need to work on. But am not sure anymore.

[07:44:06.0000] <krit>
darobin: —^ :)

[07:44:11.0000] <darobin>
yeah I figured :)

[07:59:49.0000] <annevk>
krit: well yeah, the former is "image mode" which is already locked down

[08:01:26.0000] <hober>
/me checks "meet ms2ger irl" off of the todo list

[08:01:33.0000] <krit>
annevk: was still a chalange :)

[08:02:52.0000] <wilhelm_>
hober: Any resemblance? http://en.wikipedia.org/wiki/Krang

[08:03:57.0000] <krit>
annevk: the problem is maybe that there is a spec missing explaining how to do it. So you end up in traps that are easier to find if you already have some text

[08:05:34.0000] <annevk>
yeah, SVG/CSS is pretty poor processing model wise :/

[08:05:46.0000] <hober>
wilhelm_: wow, that's eerily close :)

[08:26:26.0000] <TabAtkins>
I can at least cross "saw ms2ger from a distance" off the list.

[08:26:40.0000] <darobin>
TabAtkins: in Paris?

[08:26:55.0000] <TabAtkins>
darobin: ...somewhere.

[08:27:10.0000] <darobin>
TabAtkins: c'mon

[08:34:18.0000] <annevk>
Seems Hallvord dropped some initials since he joined us.

[08:48:16.0000] <bkardell__>
Hixie_: https://gist.github.com/bkardell/6552215

[08:48:57.0000] <bkardell__>
says listing in network and cache sections prevents cache...

[08:49:13.0000] <bkardell__>
is that at odds with what I (think) you said yesterday?

[08:51:20.0000] <bkardell__>
sent something to the dev tools team for clarification, but... it's confusing

[08:58:39.0000] <dglazkov>
good morning, Whatwg!

[08:59:42.0000] <bkardell__>
Hixie_: nm, seems to actually *do* as you described despite validator - still not my problem yet :-\

[09:01:17.0000] <TabAtkins>
Good evening, dglazkov!

[10:21:16.0000] <annevk>
Hixie_: I emailed es-discuss long about the global this / global object mismatch, I filed https://bugs.ecmascript.org/show_bug.cgi?id=1898 now so it's actually tracked

[10:21:44.0000] <annevk>
Hixie_: fwiw, it'll be fixed, just unclear what timeframe...

[10:22:23.0000] <matjas>
abusing WebRTC to read local IPs: https://dl.dropboxusercontent.com/u/1878671/enumhosts.html TIL HTML5 has a built-in `nmap`

[10:23:27.0000] <Hixie_>
annevk: oh, excellent, thanks

[10:23:39.0000] <annevk>
matjas: :/

[10:24:20.0000] <Hixie_>
you can do an intranet scan using <img> and <meta refresh>, that's not new

[10:24:47.0000] <Hixie_>
getting the local IP is new, but that's something that's pretty much a prereq of doing NAT traversal, as i understand it

[10:45:47.0000] <rillian>
Hixie_: I wonder if you could measure the response time accurately enough to distinguish the local ip in an <img> portscan

[11:17:31.0000] <Hixie_>
rillian: the problem is more that you don't know where to start

[11:22:02.0000] <reyre>
i've been working on implementing the processing model of WebVTT and it seems to me like the positioning for alignments is reversed, has anyone else encountered this as well?

[11:22:07.0000] <reyre>
i need a sanity check

[11:27:16.0000] <Hixie_>
there's a bug open on it

[11:27:28.0000] <Hixie_>
i think nessy has a plan for it

[11:27:31.0000] <Hixie_>
check the VTT bugs

[11:27:35.0000] <rillian>
reyre: the wiki points to https://dvcs.w3.org/hg/text-tracks/ for the webvtt spec

[11:27:36.0000] <reyre>
Hixie_: okay thanks

[11:27:50.0000] <rillian>
last change Aug 12

[11:28:10.0000] <reyre>
/me bookmarking it

[11:28:12.0000] <reyre>
thanks rillian

[11:28:30.0000] <rillian>
oh, there's a link at the top of http://dev.w3.org/html5/webvtt/

[11:28:31.0000] <rillian>
duh

[11:28:40.0000] <rillian>
just truncate the url to get the hg repo

[11:29:12.0000] <Hixie_>
oh no, there's not multiple copies of this now are there? sigh

[11:31:48.0000] <rillian>
Hixie_: yeah :/

[11:32:09.0000] <rillian>
not a living document

[11:34:02.0000] <rillian>
reyre: the repo has no useful history on the overscan line

[11:34:24.0000] <rillian>
maybe look in the whatwg repo

[11:34:39.0000] <reyre>
rillian: okay sounds good

[11:36:39.0000] <rillian>
matjas: local people no involved with webrtc were appropriately appalled by your link

[12:15:13.0000] <zewt>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23240: "browsers do lots of bizarre things here, so let's just spec the nice simple thing"

[12:30:18.0000] <annevk>
UI events :/

[12:30:37.0000] <annevk>
I wish someone would just step up and fix them

[12:35:54.0000] <zewt>
dear google: i searched for OOM, not "zoom", thanks anyway

[13:26:28.0000] <Hixie_>
annevk: i thought the dom3 events guys were doing that, aren't they?

[13:27:58.0000] <annevk>
Hixie_: I don't see anything in terms of hit testing, defining the model, defining things in terms of tasks, etc.

[13:28:20.0000] <annevk>
Hixie_: it's mostly still the old Events spec afaict, nothing "new-style"

[13:30:43.0000] <Hixie_>
yeah, i think GPHemsley filed bugs about this

[16:17:09.0000] <Hixie_>
is there a way to make an element with a semi-transparent background blur the stuff it overlaps?

[16:17:16.0000] <Hixie_>
aero-style? or mac menu style?

[16:18:54.0000] <zewt>
you can do that with css filters, i think

[16:19:47.0000] <zewt>
iirc it's catastrophically slow in some implementations (not all are hardware-accelerated)

[16:24:51.0000] <Hixie_>
doesn't 'filter' apply to the element itself, rather than its background?

[16:26:02.0000] <Hixie_>
or i should say, rather than what is behind it

[16:26:05.0000] <Hixie_>
not its background in a CSS sense

[16:29:34.0000] <Hixie_>
cabanier: ping

[16:34:51.0000] <zewt>
hmm true

[16:36:16.0000] <rillian>
Hixie_: you'd have to hack it I think. css filters blur before compositing

[16:36:16.0000] <zewt>
wonder how that could be done in general ... first thought is a way to create an element whose contents is whatever's composited underneath it, but alpha would break that

[16:36:24.0000] <rillian>
http://jsfiddle.net/3asZC/539/

[16:37:24.0000] <Hixie_>
doesn't seem to affect the backdrop...

[16:37:43.0000] <zewt>
unless it's just a flat, completely precomposited copy of whatever's under it (thus with no transparency)

[16:39:06.0000] <zewt>
personally there are few things in UIs i hate more than blurring (hurts my eyes), so I'm okay with it being hard to do :)

[16:41:23.0000] <Hixie_>
mac menus use it to good effect

[16:41:49.0000] <zewt>
i don't remember it (and don't see it on my mbp), maybe I turned it off somewhere

[16:42:35.0000] <Hixie_>
look through a context menu

[16:42:58.0000] <Hixie_>
or a top-level menu from the menu bar

[16:43:01.0000] <Hixie_>
it's extremely subtle

[16:43:08.0000] <Hixie_>
bbl

[16:43:45.0000] <zewt>
nope


2013-09-14
[17:00:39.0000] <Domenic_>
+1, we have wanted this background-blurring ourselves

[17:00:53.0000] <Domenic_>
I might try breaking out the old ::before, putting the background in there, and blurring the ::before?

[17:01:10.0000] <Domenic_>
Bet it doesn't work though, everyone forgets poor pseudo-elements when implementing cool features like filters.

[18:23:10.0000] <zewt>
Domenic_: not really fair to expect that, heh (and if there was a way to do it, ::before doesn't seem right anyway)

[18:27:15.0000] <cabanier>
Hixie_: pong

[18:30:22.0000] <cabanier>
Domenic_: why would a filter not work on a pseudo?

[19:11:27.0000] <MikeSmith>
I'm running IE10 in virtualbox on my Mac. Anybody know if there's a way I can copy the generated DOM from IE to the clipboard?

[19:12:11.0000] <MikeSmith>
like "Copy InnerHTML" in Firefox devtools or "Copy HTML" in Chrome devtools

[19:12:31.0000] <MikeSmith>
I can't even figure out how to to do "View source"..

[19:23:39.0000] <cabanier>
MikeSmith: hit F12, select the node and say copy innterHTML

[19:24:27.0000] <cabanier>
MikeSmith: "view source" is right-click

[19:27:56.0000] <MikeSmith>
cabanier: thanks but for some reason I can't even get a context menu with right-click -- nothing happens. And for F12 also, nothing happens

[19:28:20.0000] <MikeSmith>
but I did manage to to get the Developer Tools UI to display

[19:28:44.0000] <MikeSmith>
and there's  Save HTML button there

[19:30:00.0000] <MikeSmith>
now I don't don't how to move the file between the VirtualBox environment and my Mac filesystem but I guess it's just easier to send it to myself by Gmail

[19:30:46.0000] <MikeSmith>
cabanier: btw what I'm working is canvas-related

[19:31:33.0000] <MikeSmith>
preparing a report on browser results for the 2dcontext test sute

[19:32:08.0000] <cabanier>
MikeSmith: ah.

[19:32:51.0000] <cabanier>
MikeSmith: is it so we know to go to the next stage and cut the at-risk features?

[19:33:06.0000] <MikeSmith>
yeah

[19:35:35.0000] <MikeSmith>
cabanier: results so far at at http://w3c-test.org/testrunner/2dcontext/results.html

[19:35:37.0000] <cabanier>
I thought someone already did that a couple of months ago.

[19:35:44.0000] <MikeSmith>
probably they did

[19:36:29.0000] <MikeSmith>
but if so I don't recall where or if they produced an actual report of some kind

[19:36:53.0000] <MikeSmith>
the above results are generated using a test-runner that Ms2ger put together

[19:37:06.0000] <cabanier>
I remember seeing it. They used the same test suite from philip

[19:37:10.0000] <MikeSmith>
(general test-runner, not specific to canvas)a

[19:37:15.0000] <MikeSmith>
OK

[19:38:04.0000] <MikeSmith>
you don't remember who it was?

[19:48:04.0000] <cabanier>
Let me check my email

[19:52:49.0000] <MikeSmith>
cabanier: thanks -- I appreciate it

[19:53:28.0000] <cabanier>
MikeSmith: Jay created a report: https://github.com/w3c/html/commit/e39702df26606c248e4446f4371ca5ce739

[19:53:36.0000] <cabanier>
MikeSmith: I don't know how extensive it is

[19:54:02.0000] <MikeSmith>
/me looks

[19:54:43.0000] <cabanier>
http://dev.w3.org/cvsweb/~checkout~/html5/2dcontext/canvas2d-implemtation.html?rev=1.3;content-type=text%2Fhtml

[19:54:47.0000] <MikeSmith>
cabanier: not so bad for what it is I guess

[19:54:48.0000] <MikeSmith>
https://rawgithub.com/w3c/html/e39702df26606c248e4446f4371ca5ce73912e61/CR_canvas_Status-6-20-2013.html

[19:54:55.0000] <MikeSmith>
cabanier: thanks

[19:55:06.0000] <MikeSmith>
yeah but not so extensive

[19:55:17.0000] <cabanier>
no. I think he mentioned that

[19:55:39.0000] <MikeSmith>
we need to granularity

[19:56:02.0000] <cabanier>
more granularity?

[19:56:15.0000] <MikeSmith>
I mean, we all already know that that we don't have implementations of Path object and hit testing

[19:56:34.0000] <MikeSmith>
granularity as in, exactly which tests fail

[19:56:46.0000] <MikeSmith>
and do they fail in more than one browser

[19:56:52.0000] <cabanier>
yes

[19:57:08.0000] <cabanier>
sometimes the spec is wrong but all the browser agree anyway

[19:57:15.0000] <cabanier>
ie stroking

[19:57:20.0000] <MikeSmith>
or to put it in other terms, for any given test, do we have a least 2 engines that pass it

[19:57:24.0000] <MikeSmith>
yeah

[19:58:24.0000] <MikeSmith>
cabanier: or if you look at the first failure in http://w3c-test.org/testrunner/2dcontext/results.html

[19:58:36.0000] <MikeSmith>
fill-and-stroke-styles/2d.pattern.image.incomplete.immediate.html

[19:58:46.0000] <MikeSmith>
fails in all UAs

[19:59:39.0000] <MikeSmith>
http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.image.incomplete.immediate.html

[20:01:16.0000] <cabanier>
2d.pattern.image.incomplete.immediate.html is part of the blink/webkit testsuite and passes there

[20:01:34.0000] <MikeSmith>
really?

[20:01:49.0000] <MikeSmith>
not passing for me when I run it in Chromium 31

[20:02:00.0000] <cabanier>
This is the script:

[20:02:02.0000] <cabanier>
_addTest(function(canvas, ctx) {

[20:02:02.0000] <cabanier>
var img = new Image();

[20:02:02.0000] <cabanier>
img.src = "NotARealFileName.png";

[20:02:02.0000] <cabanier>
_assertSame(img.complete, false, "img.complete", "false");

[20:02:02.0000] <cabanier>
_assertSame(ctx.createPattern(img, 'repeat'), null, "ctx.createPattern(img, 'repeat')", "null");

[20:02:04.0000] <cabanier>
});

[20:02:10.0000] <MikeSmith>
http://w3c-test.org/testrunner/2dcontext/results-chrome31.html

[20:02:48.0000] <MikeSmith>
I get "Failed assertion ctx.createPattern(img, 'repeat') === null (got [object CanvasPattern][object], expected [object])"

[20:03:06.0000] <MikeSmith>
assert_equals: ctx.createPattern(img, 'repeat') === null (got [object CanvasPattern][object], expected [object]) expected null but got object "[object CanvasPattern]"

[20:03:47.0000] <cabanier>
the code looks the same

[20:03:58.0000] <MikeSmith>
I get tht same failure in Firefox 26

[20:04:16.0000] <cabanier>
ah, in your case it's finding the image

[20:07:50.0000] <cabanier>
this is testing image fetching from the main HTML spec: http://www.whatwg.org/specs/web-apps/current-work/#update-the-image-data

[20:08:46.0000] <cabanier>
and I'm not sure if it's asserting on something correct

[20:09:36.0000] <MikeSmith>
so maybe there's something wrong with the test

[20:10:15.0000] <MikeSmith>
by my count we have about 40 tests from thw 2dcontext test suite that aren't passing in any UA

[20:10:58.0000] <cabanier>
I'm not 100% sure that the test is wrong, but it's not failing on something that's part of canvas

[20:11:19.0000] <MikeSmith>
ok

[20:11:46.0000] <MikeSmith>
so that's the kind of thing we need to isolate, and change the test or drop it or whatever if it's not valid

[20:12:44.0000] <cabanier>
yes

[20:14:02.0000] <MikeSmith>
to me the main real utility of the http://w3c-test.org/testrunner/2dcontext/results.html report is, we go through all the fails-in-two-or-more-browsers cases and figure out why they're failing, then either make changes to the tests as needed, or if it's a real conformance failure with the current spec, then we either change the spec or list it as a known issue or whatever

[20:15:16.0000] <cabanier>
2d.pattern.repeat.null.html is actually something where the whatwg is diverging from the w3c one

[20:16:01.0000] <cabanier>
MikeSmith: yes, let's go through them and see if we find spec bugs

[20:17:58.0000] <MikeSmith>
cabanier: if/when you have time on your own, and you see some low-hanging fruit, please make some notes and send them to the public-html-testsuite list or even to public-html

[20:18:24.0000] <MikeSmith>
in the meantime, plh is going to be talking about the results with Kris Kruger

[20:19:09.0000] <cabanier>
ok

[20:19:10.0000] <MikeSmith>
myself after this weekend I'm going to be away for two weeks at some Web events in Inida

[20:21:32.0000] <cabanier>
I assume that you will add all results to http://w3c-test.org/testrunner/2dcontext/results.html ?

[20:22:37.0000] <MikeSmith>
cabanier: which other results are needed?

[20:23:03.0000] <MikeSmith>
plh and I are only testing the latest versions of each UA

[20:23:06.0000] <cabanier>
MikeSmith: ah. I thought you were still adding test results

[20:23:08.0000] <cabanier>
ok

[20:23:59.0000] <MikeSmith>
no, those are complete results for all the http://w3c-test.org/web-platform-tests/master/2dcontext/ tests at least

[20:25:11.0000] <MikeSmith>
I know we have other canvas tests in http://w3c-test.org/web-platform-tests/master/html/semantics/embedded-content-0/the-canvas-element/ but I'm not doing any reporting on those yet at this point

[20:38:23.0000] <Hixie_>
cabanier: is 2d.pattern.repeat.null.html assuming the whatwg spec or the w3c one? and what do browsers do?

[20:38:53.0000] <cabanier>
the one mike ran assumes w3c

[20:38:55.0000] <Hixie_>
cabanier: the reason i pinged you earlier was wondering if you were aware of any css plans to do blurring during composition, of the content you're being composited on

[20:39:28.0000] <cabanier>
s/w3c/whatwg

[20:39:37.0000] <cabanier>
the one from webkit/blink assumes w3c

[20:39:54.0000] <cabanier>
blurring of the element? that's already in

[20:40:00.0000] <Hixie_>
not of the element

[20:40:03.0000] <Hixie_>
of the stuff behind the element

[20:40:08.0000] <cabanier>
ah

[20:40:26.0000] <cabanier>
like blurring your backdrop?

[20:40:49.0000] <cabanier>
we've talked about that but it's not in a spec yet

[20:40:53.0000] <Hixie_>
k

[20:41:07.0000] <Hixie_>
had a need for it in a personal project recently, so, consider this a +1 :-)

[20:41:44.0000] <Hixie_>
looks like the whatwg spec is just wrong about the createPattern() call.

[20:42:01.0000] <cabanier>
http://lists.w3.org/Archives/Public/public-fx/2012AprJun/0003.html

[20:42:19.0000] <Hixie_>
w3c spec seems wrong too though

[20:42:22.0000] <cabanier>
we've had a bug on createPattern

[20:43:08.0000] <cabanier>
"If the empty string or null is specified, repeat must be assumed"

[20:43:20.0000] <Hixie_>
that's not the bug

[20:43:26.0000] <Hixie_>
the bug is the idl is wrong

[20:43:32.0000] <Hixie_>
it says first argument isn't nullable

[20:43:36.0000] <Hixie_>
(both specs say that)

[20:45:13.0000] <cabanier>
yes. the idl is wrong

[20:47:24.0000] <Hixie_>
man, the w3c one is way out of date

[20:47:29.0000] <Hixie_>
either that or i'm looking at the wrong spec

[20:48:52.0000] <Hixie_>
wait

[20:49:00.0000] <Hixie_>
i'm getting different results here

[20:49:14.0000] <Hixie_>
oh, i misread the test

[20:49:36.0000] <cabanier>
I might have been looking at a different test. several failed

[20:49:42.0000] <cabanier>
which one are you looking at?

[20:49:56.0000] <Hixie_>
http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.repeat.null.html, but i was misreading it

[20:49:59.0000] <Hixie_>
testing again now.

[20:52:08.0000] <cabanier>
ok. the test you run assumes that 'null' will throw, but the same test in blink assumes that it will work

[20:57:41.0000] <Hixie_>
i wonder (a) why the browsers do this, given that it's so inconsistent with everything else, and (b) why the specs forked on this

[20:58:31.0000] <cabanier>
it was an accidental change by Cameron when he updated everything to webidl

[20:58:57.0000] <Hixie_>
what was?

[20:59:06.0000] <cabanier>
no longer allowing null

[20:59:11.0000] <cabanier>
for createPattern

[20:59:32.0000] <Hixie_>
ah

[20:59:36.0000] <Hixie_>
that doesn't explain the forking though

[21:00:42.0000] <cabanier>
I'm trying to find the bug

[21:00:49.0000] <Hixie_>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17891

[21:00:57.0000] <Hixie_>
that's where we decided to make the whatwg version make more sense

[21:01:12.0000] <Hixie_>
but the w3c one forking apparently sowed confusion and led to implementations staying with the old behaviour

[21:01:15.0000] <Hixie_>
ffs

[21:01:22.0000] <Hixie_>
this forking crap keeps causing stuff like this

[21:01:32.0000] <Hixie_>
i wish the htmlwg would stop doing this

[21:01:59.0000] <cabanier>
the browsers all agreed that null was ok

[21:02:10.0000] <Hixie_>
because of the fork

[21:02:13.0000] <Hixie_>
they wouldn't have otherwise

[21:02:20.0000] <Hixie_>
see e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=784809

[21:02:26.0000] <cabanier>
no, the old canvas spec said it was ok

[21:02:36.0000] <Hixie_>
yeah, and we tried to fix it

[21:02:41.0000] <Hixie_>
but the w3c spec didn't

[21:02:44.0000] <cabanier>
why?

[21:02:54.0000] <cabanier>
what needed fixing?

[21:03:04.0000] <Hixie_>
why the w3c didn't? beats the heck out of me

[21:03:28.0000] <Hixie_>
what needs fixing is "null" being treated as empty string is not normal behaviour

[21:03:32.0000] <cabanier>
this is when the test was changed to disallow null: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17141

[21:05:02.0000] <cabanier>
https://bugzilla.mozilla.org/show_bug.cgi?id=784809 was to undo the change that ms2ger made shortly after he changed the test

[21:09:19.0000] <cabanier>
so, as far as I can tell:

[21:09:32.0000] <cabanier>
1. everyone allowed null (and the tests verified this)

[21:10:15.0000] <cabanier>
2. you integrated cameron's change

[21:10:31.0000] <cabanier>
3. ms2ger changed mozilla and the test

[21:11:26.0000] <cabanier>
4. Boris did not agree with the change, someone filed a bug against the w3c spec and the whatwg

[21:11:43.0000] <cabanier>
5. the w3c version was changed back and mozilla reverted its change

[21:12:54.0000] <cabanier>
I don't remember why I changed the IDL back...

[21:13:39.0000] <cabanier>
I had a domstring? there at one point

[21:13:59.0000] <Hixie_>
re 1, pretty sure opera didn't.

[21:14:24.0000] <Hixie_>
re 4, the mozilla bug makes it clear that it was because the specs forked that bz felt he should pick something

[21:14:28.0000] <cabanier>
yes, they were the odd one out

[21:14:47.0000] <Hixie_>
the net result is, the web gets one more crazy quirk. yay us.

[21:15:37.0000] <cabanier>
I don't think so. I remember that bz wanted the old behavior. see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=17891#c8

[21:17:41.0000] <cabanier>
fwiw, I think the canvas api's should be more lax.

[21:18:28.0000] <Hixie_>
https://bugzilla.mozilla.org/show_bug.cgi?id=784809 was filed by bz specifically with the reason "the spec changed" which he later clarified to mean your fork

[21:18:47.0000] <Hixie_>
so step 4 happened after the w3c spec changed, and because of it

[21:19:21.0000] <Hixie_>
anyway, the specifics are water under the bridge. i just find it irritating that we once again have inconsistency in the platform, especially since this time it's specifically because the w3c is forking specs that we have it.

[21:20:16.0000] <cabanier>
I'm not sure if you can blame forking here. I agree forking is bad!

[21:20:41.0000] <cabanier>
boris would have objected to this even if there was no w3c spec

[21:21:44.0000] <cabanier>
https://bugzilla.mozilla.org/show_bug.cgi?id=784809#c2: "The user impact is that createPattern calls that used to work and should work per the updated spec throw on m-c and aurora right now."

[21:22:03.0000] <cabanier>
some websites broke with this change

[21:22:25.0000] <Hixie_>
which?

[21:23:39.0000] <cabanier>
I don't remember but there was a popular library that stopped working

[21:23:53.0000] <Hixie_>
i don't see that documented anywhere

[21:25:23.0000] <cabanier>
yes, I can only find that aurora is throwing

[21:26:03.0000] <cabanier>
I think that was really the divergence  :-P

[21:26:15.0000] <cabanier>
the only divergence

[21:27:21.0000] <Hixie_>
there's like half a dozen different versions of the canvas spec on the w3c site, but the ones i found were all very divergent when it comes to createPattern. For example, they don't have ImageBitmap.

[21:27:27.0000] <Hixie_>
or CanvasImageSource or whatever it's called.

[21:27:57.0000] <Hixie_>
(i really don't understand why the w3c insists on forking when they keep talking, as you just did, about how forking is bad)

[21:28:16.0000] <Hixie_>
anyway, i gotta go. bbl.

[21:29:04.0000] <cabanier>
ok!

[21:31:56.0000] <cabanier>
canvasimagesource should be there

[21:32:24.0000] <cabanier>
and imageBitmap is imageData. weird

[21:32:32.0000] <cabanier>
some integration must have gone bad

[22:01:57.0000] <MikeSmith>
cabanier: do you know offhand which test cases correspond to the changes Hixie just made to the canvas spec?

[22:02:29.0000] <MikeSmith>
if not, no worries, I'll go in and try to match them up so I can annotate the report

[22:43:29.0000] <cabanier>
MikeSmith: I think it's the one with 'pattern.repeat.null'

[22:44:17.0000] <cabanier>
It does seem like the latest canvas spec is out of sync with the whatwg one. I will find out why that happend

[22:54:15.0000] <MikeSmith>
cabanier: ok

[22:56:41.0000] <MikeSmith>
btw I don't think there's any tests in the canvas test suite that have ever intentionally been changed to assume the W3C spec and to not conform to the upstream spec

[22:57:54.0000] <MikeSmith>
if there are cases where they match the w3c spec but not the whatwg spec, I would thikn that's due to the whatwg spec having made a change and that change not getting ported to the w3c spec

[22:59:17.0000] <MikeSmith>
that is, the test is matching outdated behavior and needs to be updated

[00:01:40.0000] <cabanier>
MikeSmith: we should test what the browsers implemented. If all (or most) of them converge on a certain behavior, then that is what should be in the spec and what we should test

[00:02:34.0000] <cabanier>
MikeSmith: the createPattern issue is a good example of that

[00:02:46.0000] <MikeSmith>
yeah

[00:03:21.0000] <MikeSmith>
well, in that specific case, the test did originally match what was implemented

[00:04:08.0000] <cabanier>
yes. so most of them converged (except opera) and then it became impossible to change it to something more sane

[00:04:20.0000] <MikeSmith>
but then Mozilla changed to implement what the spec says, and at that time Ms2ger also changed the test, to match the spec and to match what Mozilla (and Opera) had implemented

[00:04:25.0000] <MikeSmith>
yeah

[05:54:02.0000] <Domenic_>
annevk: `class Elements extends Array` got spontaneous applause about an hour ago at JSConf EU :D

[07:54:31.0000] <xvzf>
hi there, I started to read Mark Pilgrim's book and he had written that WhatWG wanted to describe how popular browsers had provided fallback modes for erroneous html. Which documents should I read if I'm interested in this?

[07:58:23.0000] <Philip`>
xvzf: Probably http://whatwg.org/html

[08:08:19.0000] <xvzf>
Philip`, : especially http://www.whatwg.org/specs/web-apps/current-work/multipage/#auto-toc-14 I guess

[08:12:06.0000] <Philip`>
xvzf: The "Writing HTML documents" vs "Parsing HTML documents" sections might be the most obvious example - the first section defines what is correct/erroneous syntax, and the second section defines how to parse HTML regardless of its correctness (with the handling of erroneous content being compatible with what browsers have done historically, because there is content that relies on that)

[13:36:45.0000] <annevk>
bkardell__: I don't follow your question on Twitter

[14:55:33.0000] <Hixie_>
is there a way to make opacity:0 elements transparent for event targetting purposes also?

[14:55:59.0000] <Hixie_>
i'm using opacity to fade them out in a transition instead of marking them display:none, but they're still there so clicks still go to them...

[14:56:59.0000] <zewt>
pointer-events: none?

[14:57:47.0000] <Hixie_>
does that work these days?

[14:58:03.0000] <zewt>
might not be in IE

[15:00:28.0000] <Hixie_>
pointer-events doesn't seem to work in chrome either

[15:00:48.0000] <Hixie_>
or firefox

[15:01:07.0000] <Hixie_>
oh wait, typo

[15:01:11.0000] <zewt>
i've used it a ton in webkit-specific stuff, at least

[15:02:50.0000] <Hixie_>
nope, can't get pointer-events: none to work

[15:03:07.0000] <Hixie_>
/me tries in a test case

[15:03:55.0000] <Hixie_>
works in my test...

[15:03:56.0000] <Hixie_>
wtf

[15:06:47.0000] <zewt>
it also doesn't prevent non-pointer stuff, like tab navigation, which can take some extra work

[15:08:14.0000] <Hixie_>
oh, it was working i just missed an element

[15:08:15.0000] <Hixie_>
duh

[15:10:43.0000] <Hixie_>
man i wish specificity didn't exist

[15:14:46.0000] <annevk>
I wonder if last matching selector wins would've been a better rule


2013-09-15
[06:50:54.0000] <Domenic_>
annevk's offhand comment has launched me into a topsy-turvy what-if world where every time i see some CSS selectors juxtaposed I contemplate what could have been, and whether it would have been better.

[07:29:33.0000] <annevk>
Hah, sorry Domenic_!

[08:13:11.0000] <Jasper>
Is there a standard test suite for <canvas>?

[08:14:44.0000] <Jasper>
I found http://philip.html5.org/tests/canvas/suite/tests/ but it seems to be really outdated.

[08:16:48.0000] <annevk>
http://w3c-test.org/html/tests/approved/canvas/ I suspect

[08:17:27.0000] <Jasper>
Aha, thanks.

[08:22:24.0000] <Jasper>
annevk, yeah, that doesn't seem to test what I'm looking for. Is there a way to submit new tests to that?

[08:22:49.0000] <annevk>
Jasper: pull requests to https://github.com/w3c/web-platform-tests I suspect

[08:23:12.0000] <annevk>
Jasper: seems there's a 2dcontext directory too...

[08:24:01.0000] <annevk>
Probably has something to do with the W3C making the silly decision to publish them as distinct documents while there's still only one person writing them...

[08:27:11.0000] <Jasper>
OK, yeah. Every browser that I can test with does not seem to use the clipping path when rendering text.

[08:27:30.0000] <Jasper>
even though: "These shapes are painted without affecting the current path, and are subject to shadow effects, global alpha, the clipping region, and global composition operators."

[08:28:19.0000] <Jasper>
I wonder if we should just remove "clipping path" from that sentence, since fixing that bug might cause backwards compatibility issues. But then in order to clip text I'd need to create a new scratch canvas and copy pixels over

[08:30:10.0000] <annevk>
Jasper: I guess you're familiar with posting issues to whatwg⊙wo?

[08:30:19.0000] <Jasper>
I'm not, actually.

[08:30:40.0000] <annevk>
Jasper: http://www.whatwg.org/mailing-list#specs

[08:31:06.0000] <annevk>
Jasper: you can also file a bug, but emailing will give other implementers a better heads up, generally

[08:31:32.0000] <Jasper>
annevk, do I need to subscribe to the list, or can I just send one email?

[08:32:00.0000] <annevk>
Jasper: need to subscribe unfortunately, we're bad at handling spam :/

[08:38:42.0000] <Jasper>
annevk, sent http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-September/040835.html

[08:38:52.0000] <Jasper>
sorry if I broke some etiquette or didn't explain myself clearly enough

[08:39:15.0000] <annevk>
Jasper: seems fine

[08:39:27.0000] <annevk>
Jasper: might take a while for people to get back to you, mind

[08:39:32.0000] <Jasper>
Yep.

[08:39:35.0000] <Jasper>
It's a weekend, too.

[08:39:40.0000] <Jasper>
annevk, thanks!

[11:16:18.0000] <gsnedders>
Hixie_: So your change about lone surrogates is still a change from the old html5lib tests and what the spec used to say. Lone surrogates used to get converted to U+FFFD. Now, is that desirable or not? Dunno.

[13:24:27.0000] <annevk>
That's what they do in CSS. I think we should be consistent at least... Rationale for one ought to apply to the other...

[13:41:10.0000] <Hixie_>
gsnedders: i tried to do that and people screamed at me that DOM APIs shouldn't do unicode sanitising... *shrug*

[14:04:51.0000] <gsnedders>
Oh well. Anyone feel like updating a ton of tests?

[14:36:49.0000] <zcorpan>
annevk: CSS doesn't U+FFFD lone surrogates, i think

[14:37:11.0000] <annevk>
zcorpan: per recent changes to css3-syntax it does, not at the CSSOM level though

[14:37:40.0000] <annevk>
I thought this discussion was about the parser because html5lib tests were mentioned...

[14:38:18.0000] <Hixie_>
it's at the parser level but only for document.write() and innerHTML

[14:38:23.0000] <annevk>
Fucking lone surrogates. We should really make up a set of principles and start applying them everywhere.

[14:38:41.0000] <zcorpan>
annevk: css-syntax only U+FFFDs lone surrogates in css escapes

[14:38:49.0000] <zcorpan>
annevk: which html does also

[14:39:04.0000] <annevk>
zcorpan: okay, and you can't get them in the input stream, so I guess that's consistent then

[14:39:32.0000] <zcorpan>
yeah. except when the input stream comes from cssom i guess

[14:40:15.0000] <annevk>
So it seems the principles are what I thought they'd be. Script is 16-bit code units and includes lone surrogates. Just parsing from network guarantees Unicode scalar values, including if you use escapes...

[14:40:30.0000] <zcorpan>
yep

[14:40:55.0000] <annevk>
I think I'd prefer to just use 16-bit code units everywhere, but oh well...

[14:41:57.0000] <annevk>
I guess it's somewhat nicer if you don't have JavaScript and still want to interpret some HTML and use non-browser strings... But the difference seems marginal and if you want code sharing you'll end up with browser strings anyway.

[14:45:04.0000] <Hixie_>
i'd be nicer if javascript was unicode scalar values and you never saw utf-16 anywhere ever ever ever

[14:46:59.0000] <gsnedders>
Well, that'd be easier if JS didn't predate UTF-16.

[14:49:14.0000] <Hixie_>
UTF-16 predates the web, let alone JS

[14:49:58.0000] <Hixie_>
though i guess teh surrogates don't predate the web

[14:50:19.0000] <Hixie_>
so practically you're right

[14:50:20.0000] <gsnedders>
UCS-2 predates the web, no?

[14:50:27.0000] <gsnedders>
UTF-16 comes later.

[14:50:28.0000] <zewt>
err, surrogates define utf-16

[14:50:37.0000] <annevk>
Well we can't change JavaScript. I'm not sure JavaScript predated utf-16

[14:50:55.0000] <Hixie_>
surrogates are 1996

[14:51:04.0000] <gsnedders>
UTF-16 was Unicode 2.0, 1996.

[14:51:17.0000] <Hixie_>
and livescript was 1995

[14:51:24.0000] <Hixie_>
so there we go

[14:51:25.0000] <gsnedders>
Superseding UCS-2.

[14:51:35.0000] <zewt>
(is this a conversation about how powerful we need to build our time machine)

[14:51:42.0000] <Hixie_>
yes

[14:51:42.0000] <annevk>
Yeah, copying Java :/

[14:52:04.0000] <Hixie_>
well, before utf-16, ucs2 made a lot of sense

[14:52:16.0000] <gsnedders>
It could map the entire Unicode codespace.

[14:52:22.0000] <gsnedders>
The problem is the codespace got expanded.

[14:52:25.0000] <annevk>
Sure, when 16-bit was enough for all code points...

[14:52:35.0000] <gsnedders>
annevk: Which it was when JS was created.

[14:52:45.0000] <annevk>
Now it's 21-bit, hopefully that'll last

[14:52:55.0000] <annevk>
gsnedders: yeah I know

[14:53:00.0000] <zewt>
ucs-2 makes a lot more sense than utf-16, now and then, it's just limited

[14:53:54.0000] <gsnedders>
annevk: Well, given we're still at a point of most things being unassigned, it probably depends mostly on the rate of language change. Which I'm dubious about, given everything is typed nowadays.

[14:54:05.0000] <annevk>
Anyway, this keeps coming up. We should sort it out somehow...

[14:54:12.0000] <gsnedders>
Language change insofar as it changes alphabets, that is

[14:54:27.0000] <gsnedders>
/me votes lone surrogates always map to U+FFFD

[14:54:43.0000] <annevk>
gsnedders: that's not gonna happen

[14:54:59.0000] <gsnedders>
annevk: Why not?

[14:55:10.0000] <annevk>
gsnedders: we can't change the nature of strings in JavaScript

[14:55:22.0000] <gsnedders>
annevk: Oh, no, at that level it makes sense.

[14:55:27.0000] <annevk>
gsnedders: and we don't want the perf impact for every API

[14:55:43.0000] <gsnedders>
Then do we want to never convert them?

[14:56:05.0000] <annevk>
I think accepting 16-bit code units everywhere is the logical outcome, yes

[14:56:12.0000] <gsnedders>
Then we should probably change what &#xd800; does. But maybe we can't?

[14:56:21.0000] <zcorpan>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Nov/0020.html

[14:56:52.0000] <annevk>
But it depends on what other arguments are put forward. E.g. I can see compatibility with clients that don't want 16-bit code units to be seen as important. Although I'm not sure how important that is...

[14:57:03.0000] <Hixie_>
can we please not change this stuff? it's irrelevant to the wider world and just wastes implementer time.

[14:57:49.0000] <zcorpan>
i agree with Hixie_. we have interop on this now iirc

[14:57:52.0000] <annevk>
Hixie_: the thing is, but this still being in flux it's still wasting time

[14:58:02.0000] <annevk>
Hixie_: e.g. for Rust / Servo

[14:58:14.0000] <annevk>
Hixie_: and the design of encoders/decoders

[14:58:47.0000] <Hixie_>
just, don't change what's implemented, that's all i ask

[14:58:50.0000] <annevk>
Hixie_: see recent thread on whatwg⊙wo, see thread on www-international⊙wo about text rendering, etc.

[15:01:04.0000] <Hixie_>
do mutation observers not provide a simple way to just detect when an element is removed from the DOM?

[15:01:38.0000] <Hixie_>
i just want to observe an element until it's removed from its parent

[15:04:57.0000] <annevk>
You can observe the parent changes to its children.

[15:05:21.0000] <Hixie_>
yeah but that means i have to filter out all the other children and then disconnect when i finally see what i care about

[15:05:35.0000] <Hixie_>
which is like twenty times more code than i want

[15:09:02.0000] <annevk>
File a bug? Could look into new mutation observer features at some point... I wonder if we should do that before or after MVC stuff is done.

[15:10:23.0000] <annevk>
I need to get some sleep. If anyone here has feedback for TC39, please let me know. W3C TAG feedback welcome too... Will be in Boston / NY for a couple of weeks starting next week to talk to those guys.

[15:11:22.0000] <Hixie_>
so here's a problem

[15:11:27.0000] <Hixie_>
i need to follow the node's parent

[15:11:31.0000] <Hixie_>
before i know what it is

[15:11:38.0000] <Hixie_>
since the element hasn't been added to the dom yet

[15:11:48.0000] <Hixie_>
at the point where i want to set up observing its parent going away

[15:16:11.0000] <Hixie_>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23250

[15:25:47.0000] <Hixie_>
is there a way to do "instanceof Document" that actually works? i.e. won't only be true for the current browsing context's Document?

[15:26:36.0000] <Hixie_>
o.ownerDocument == o, i guess...

[15:26:58.0000] <Hixie_>
oh, crap, that returns null for documents

[15:27:09.0000] <Hixie_>
well, o.ownerDocument == null, then, if i know it's a Node


2013-09-16
[18:35:32.0000] <MikeSmith>
how do I check whether http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.repeat.nullsuffix.html is passing or not?

[18:35:37.0000] <MikeSmith>
(manual test)

[18:51:57.0000] <MikeSmith>
hmm I see it's not actually a manual test; it passes automaticaly at http://philip.html5.org/tests/canvas/suite/tests/2d.pattern.repeat.nullsuffix.html

[18:52:06.0000] <MikeSmith>
so what's different..

[18:54:43.0000] <Philip`>
MikeSmith: It probably should be calling _assert_throws, not assert_throws

[18:55:00.0000] <Philip`>
because (per http://w3c-test.org/common/canvas-tests.js) that's what sets _asserted = true

[18:55:09.0000] <MikeSmith>
hey Philip`

[18:55:11.0000] <MikeSmith>
ah

[18:55:36.0000] <Philip`>
and _asserted is what the thing uses to tell if any assertions actually ran (because if there were none, it assumes the test requires manual verification)

[18:56:28.0000] <MikeSmith>
Philip`: voila http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.repeat.nullsuffix.html

[18:56:52.0000] <MikeSmith>
thanks

[18:57:53.0000] <Philip`>
That test only really existed to annoy Opera developers though, and now their browser is dead so it doesn't matter much

[18:59:37.0000] <MikeSmith>
Philip`: well I got a bunch of tests with that problem actually

[19:00:58.0000] <Philip`>
That was the goal of every one of the tests that has a \0 in it

[19:01:40.0000] <MikeSmith>
ok

[19:01:52.0000] <Philip`>
I hope nobody at Opera actually spent any time trying to fix that bug

[19:03:55.0000] <MikeSmith>
Philip`: should we just drop those test from the test suite?

[19:05:21.0000] <Philip`>
MikeSmith: No, because it finds real spec violations in real implementations, so it's exactly the kind of thing a thorough test suite should be testing

[19:05:28.0000] <MikeSmith>
ok

[19:05:53.0000] <Philip`>
But you shouldn't expect anyone to get a 100% pass rate, because the cost/benefit is totally not worthwhile

[19:09:40.0000] <MikeSmith>
ok

[19:10:16.0000] <MikeSmith>
Philip`: btw you have any idea why http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.image.incomplete.immediate.html is failing?

[19:12:51.0000] <Philip`>
MikeSmith: I assume you're testing in a browser that considers the image to be loaded as soon as img.src was set (at least when the image was in cache), but (if I was reading the spec correctly, and if it hasn't changed since then) the image shouldn't be loaded until after the script has returned

[19:14:07.0000] <Philip`>
/me goes to sleep

[19:25:05.0000] <MikeSmith>
Philip`: I'm testing in Firefox and IE and Chrome ..

[19:25:08.0000] <MikeSmith>
nn

[19:25:40.0000] <MikeSmith>
(oh I guess you didn't meant that sleep literally)

[19:27:02.0000] <MikeSmith>
http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.image.incomplete.emptysrc.html seems to failing in the same way maybe (except in IE)

[19:27:05.0000] <MikeSmith>
anyway

[04:07:22.0000] <MikeSmith>
http://w3c-test.org/testrunner/2dcontext/failures.html

[04:12:30.0000] <jgraham>
Those UA strings are super-easy to read

[04:13:20.0000] <MikeSmith>
jgraham: I guess I should trim them down

[04:13:31.0000] <jgraham>
MikeSmith: Might be interesting to cross-check against http://hoppipolla.co.uk/410/results.html

[04:13:44.0000] <MikeSmith>
/me looks

[04:13:59.0000] <jgraham>
Although if you fixed some tests recently I haven't run with the newe tests yet

[04:14:39.0000] <MikeSmith>
I haven't checked in any fixes

[04:15:05.0000] <jgraham>
You have local fixes?

[04:15:48.0000] <MikeSmith>
yeah the only changes I made were locally and then only to change some assert* to _assert

[04:16:46.0000] <MikeSmith>
jgraham: so I see fill-and-stroke-styles/2d.pattern.image.incomplete.immediate.html is failing at http://hoppipolla.co.uk/410/results.html too

[04:16:58.0000] <MikeSmith>
what UA are those results for?

[04:17:02.0000] <MikeSmith>
Gecko?

[04:17:54.0000] <jgraham>
MikeSmith: Yeah, some recentish nightly

[04:18:20.0000] <MikeSmith>
from what I've checked at http://hoppipolla.co.uk/410/results.html it does seem the results pretty much match

[04:18:40.0000] <MikeSmith>
except for the _assert* change, which fixed some of them in all UAs

[04:19:12.0000] <MikeSmith>
and which fixed some in Gecko only but not in Trident or Blink

[04:20:03.0000] <jgraham>
That's encouraging :)

[04:20:19.0000] <jgraham>
A PR for the _assert change would be nice btw :)

[04:20:25.0000] <jgraham>
Also

[04:21:03.0000] <jgraham>
Jasper: The latest canvas tests are at http://w3c-test.org/web-platform-tests/master, not under html/

[04:21:26.0000] <jgraham>
and the repo is at https://github.com/w3c/web-platform-tests

[04:21:37.0000] <jgraham>
Contributions via pull requests are welcome

[04:22:52.0000] <MikeSmith>
I'd make a PR for the changes but last I talked to Ms2ger he suggested changes should be made to the test sources from Philip` and we regenerate the WPT versions

[04:23:27.0000] <MikeSmith>
and the problem with that is, Robin changed the WPT directory structure, which broke Ms2ger's script

[04:23:44.0000] <MikeSmith>
jgraham: I'm curious about http://w3c-test.org/testrunner/2dcontext/failures.html#gecko-passes

[04:32:21.0000] <jgraham>
Sigh

[04:32:37.0000] <jgraham>
I might have to fix the script then

[04:32:51.0000] <jgraham>
But I don't know where it is

[04:33:12.0000] <MikeSmith>
jgraham: it's in the repo

[04:33:17.0000] <MikeSmith>
right?

[04:33:37.0000] <MikeSmith>
https://github.com/w3c/web-platform-tests/tree/master/2dcontext/tools

[04:38:30.0000] <jgraham>
Probably

[04:38:52.0000] <jgraham>
I don't really remember what I knew about these tests and what I knew wasn't all that much

[04:40:24.0000] <MikeSmith>
jgraham: still I reckon that's way more than I know. I just been pushing buttons to make that report which I promised plh two months ago I'd do

[04:41:17.0000] <MikeSmith>
anyway, very glad at least to have Ms2ger's test runner. That makes the basis grunt work automatic.

[04:43:20.0000] <zcorpan>
Philip`: i think \0 was fixed in some places but not everywhere, and yes, developers were annoyed. i was annoying them with such tests as well. :-)

[04:43:45.0000] <jgraham>
Well they always said that it wasn't worth the time to fix in general

[04:44:17.0000] <jgraham>
So it's not like you killed Presto by making us fix null bugs rather than implement features

[04:52:38.0000] <zcorpan>
right

[05:08:30.0000] <gsnedders>
It was basically fixed for new APIs, not old, and occasionally when some real site hit NULL-truncation in old APIs, but that was rare.

[07:11:35.0000] <zcorpan>
i wonder if the custom element guys have discussed with the SVG WG about SVG not introducing new elements with dashes in the name

[07:15:12.0000] <hsivonen>
/me sure hopes so

[07:16:21.0000] <jgraham>
They probably couldn't think of a humourous thread title for it

[07:16:47.0000] <zcorpan>
All your dashed names are belong to us.

[07:19:18.0000] <MikeSmith>
heh

[07:21:39.0000] <MikeSmith>
I don't remember anybody asking whether the rest of the everybody figured reserving dash exclusively for web components was a good idea

[07:22:16.0000] <MikeSmith>
or, say, maybe even asking Hixie_

[07:26:19.0000] <zcorpan>
filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23256

[07:27:28.0000] <zcorpan>
hmm, html suggests x-vendor-foo as element name for vendor extensions

[07:28:08.0000] <zcorpan>
but maybe browsers are moving away from prefixing stuff in general anyway

[07:28:58.0000] <zcorpan>
or maybe that was attributes, not elements

[07:35:12.0000] <zewt>
prefixing elements sounds even more of a pain in the ass to authors than prefixing css (which is more of a pain in the ass than prefixing APIs)

[08:37:18.0000] <Hixie_>
MikeSmith: i think it was partially my idea, as a way to get rid of the ugly x- prefixes :-)

[09:32:32.0000] <TabAtkins>
zcorpan: Yes, SVG isn't going to make any elements with dashes in their name.

[10:51:10.0000] <Hixie_>
people who care about multipart/form-data, please see https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909

[15:02:57.0000] <zewt>
nothing quite as futuristic as sites rejecting a form because i didn't put dashes in my phone number

[15:37:12.0000] <heycam>
zcorpan, yeah the only reason dashes are in the names of some elements is that they were reflecting CSS at-rules (like font-face) in elements

[15:37:19.0000] <heycam>
zcorpan, and that was a bad idea :)

[15:40:09.0000] <zcorpan>
missing-glyph is an at-rule? :-)

[15:40:22.0000] <heycam>
zcorpan, you got me there!

[15:40:58.0000] <zcorpan>
/me -> sleep


2013-09-17
[17:11:19.0000] <TabAtkins>
Worse for me (rachel doesn't get home until late on fridays)

[17:11:22.0000] <MikeSmith>
what exactly is https://www.w3.org/Bugs/Public/show_bug.cgi?id=23254 asking for?

[17:11:28.0000] <TabAtkins>
whoops, wrong window

[17:11:55.0000] <MikeSmith>
is it asking that any arbitrary element that has a hype in it should be considered valid/conformant?

[17:12:06.0000] <MikeSmith>
*has a hypen in it

[17:12:30.0000] <MikeSmith>
only about document conformance?

[17:15:38.0000] <MikeSmith>
Hixie_: any clue about https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/qcDiw-QP4RE ?

[17:16:17.0000] <MikeSmith>
I already pointed out to him (off list) that he should be reading the whatwg spec, not the TR link he cited

[17:16:42.0000] <MikeSmith>
but in this case the TR and whatwg source don't have any difference

[17:17:59.0000] <Hixie_>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23254 looks to be rather premature, since until we merge in web components, it's only applicable to web components...

[17:18:06.0000] <Hixie_>
(presumably only elements that are bound would be conforming)

[17:18:23.0000] <MikeSmith>
Hixie_: ok

[17:18:57.0000] <Hixie_>
(dglazkov and i chat about this stuff occasionally to keep in sync re what should be merged into html)

[17:19:13.0000] <MikeSmith>
yeah, I figured

[17:19:35.0000] <Hixie_>
as far as that chromium-dev post is concerned -- would have to see the output to comment

[17:20:28.0000] <MikeSmith>
he seems to be saying the blink requires the length to be specified in the headers, but he can't find any spec that requires that

[17:20:45.0000] <Hixie_>
HTTP headers?

[17:22:20.0000] <MikeSmith>
I assume so

[17:22:30.0000] <MikeSmith>
dunno what else he'd mean

[17:22:37.0000] <MikeSmith>
hex-encoded

[17:24:16.0000] <MikeSmith>
seems like he's saying he can't even figure out what chromium expects

[17:24:48.0000] <MikeSmith>
anyway, I just figured there might be something he was missing as far his reading of the specs

[17:24:52.0000] <MikeSmith>
but it seems not

[17:25:09.0000] <Hixie_>
"to each message" is what confuses me

[17:25:26.0000] <MikeSmith>
yeah that too

[17:25:36.0000] <Hixie_>
so i dunno

[17:25:36.0000] <Hixie_>
would have to see the output

[17:26:18.0000] <dev11>
What is wrong with chrome

[17:26:24.0000] <dev11>
all have problems or just me

[17:26:29.0000] <MikeSmith>
but if he's running into problems implementing server support compatible with Chrome's SSE implementation,  it makes me wonder how others manage to implement it without running into the same problem

[17:27:32.0000] <dev11>
someone that works in chrome project here

[17:27:34.0000] <dev11>
?

[17:28:41.0000] <Hixie_>
dev11: what's up?

[17:28:49.0000] <Hixie_>
MikeSmith: yeah, i dunno

[17:28:59.0000] <Hixie_>
MikeSmith: i have to admit that i just do websockets now, for pretty much everything

[17:29:00.0000] <dev11>
something is very bad right now

[17:29:12.0000] <dev11>
I am not sure if its just me or all thats why I though to ask sorry

[17:29:15.0000] <dev11>
that I ask here Hixie..

[17:29:23.0000] <Hixie_>
MikeSmith: anything that's not just static file serving, i do over web sockets

[17:29:29.0000] <Hixie_>
MikeSmith: so i never actually used sse :-)

[17:29:41.0000] <dev11>
youtube videos don't open and pages don't open, I am doing 112412 thingsright now so I am not sure whats goin on

[17:29:56.0000] <Hixie_>
dev11: are you on a dev build?

[17:30:01.0000] <dev11>
no

[17:30:03.0000] <dev11>
normal

[17:30:12.0000] <Hixie_>
weird

[17:30:15.0000] <dev11>
wait ill try on other pc lol I forgot that I have 6 pcs :D

[17:30:25.0000] <MikeSmith>
Hixie_: yeah I kind of wonder why at this point somebody would put work into implementing SSE support in a server rather than just providing websocket support

[17:30:28.0000] <Hixie_>
dev11: if you can't get any help here, try #chromium

[17:30:36.0000] <dev11>
yeah

[17:30:39.0000] <dev11>
it chrome

[17:30:43.0000] <dev11>
laptop is same

[17:31:03.0000] <dev11>
hm let me recheck

[17:31:45.0000] <dev11>
damn its my pc, sorry for annoying

[17:55:06.0000] <inaimathi>
Hi; I've been asking questions about SSE server implementations.

[17:55:27.0000] <inaimathi>
Someone wanted to see some output? :D

[17:55:54.0000] <MikeSmith>
hi inaimathi yeah Hixie_ might be able to provide some insights

[17:56:08.0000] <MikeSmith>
since he's the one who wrote the spec

[17:56:13.0000] <MikeSmith>
way back when..

[17:57:10.0000] <inaimathi>
Ok. Let me get my notes in order and I'll try to summarize.

[18:07:11.0000] <inaimathi>
So.

[18:07:23.0000] <inaimathi>
The server implementation I worked up is here (I don't have a repo up on Github yet): http://langnostic.blogspot.ca/2013/09/deal-journal-interlude-one-treatise-on.html

[18:07:33.0000] <inaimathi>
As written, the stream it generates for one message looks like this: http://pastebin.com/KPBS7egD

[18:07:53.0000] <inaimathi>
which doesn't conform to the spec as far as I understand, because it contains two lines that have no colons, but aren't ignored.

[18:08:04.0000] <inaimathi>
If I change that stream output so that it instead looks like this: http://pastebin.com/A57URpnK

[18:08:21.0000] <inaimathi>
it stops working with Firefox/Iceweasel/Conkeror/etc and Chromium.

[18:08:47.0000] <inaimathi>
Firefox+friends eat the first message, correctly process the second, and choke on the third (tripping the `onerror` event). Chromium chokes on the first message, immediately tries to reconnect and continues that cycle for each message you send.

[18:09:00.0000] <inaimathi>
My question boils down to: why?

[18:10:16.0000] <inaimathi>
My best theory at this point is that those lines represent length headers which the named browsers use to allocate space for incoming messages (either the full stream, or on a message by-message basis), but I don't understand what the benefit is, and I can't find a specification for how exactly they're supposed to work.

[18:17:13.0000] <inaimathi>
Any hints in the right direction would be appreciated.

[18:22:33.0000] <inaimathi>
Huh

[18:22:43.0000] <inaimathi>
I guess I should have checked if Hixie

[18:22:51.0000] <inaimathi>
was online before dumping that.

[18:23:07.0000] <inaimathi>
Will he appear if I type his name three times?

[18:23:15.0000] <inaimathi>
Hixie_ Hixie_ Hixie_

[18:24:37.0000] <Hixie_>
here

[18:24:40.0000] <Hixie_>
sorry, was having dinner

[18:24:51.0000] <Hixie_>
so the hex length stuff you're outputting is HTTP's chunked encoding

[18:24:57.0000] <Hixie_>
has nothing to do with Event Source per e

[18:25:00.0000] <Hixie_>
per s

[18:25:02.0000] <Hixie_>
per SE

[18:25:18.0000] <Hixie_>
i am not familiar with it enough to tell you if it's right

[18:25:20.0000] <Hixie_>
but

[18:25:40.0000] <Hixie_>
if you just load the file regularly in a browser, not in EventSource, what does it look like?

[18:25:51.0000] <Hixie_>
inaimathi: ^

[18:27:07.0000] <inaimathi>
1e

[18:27:08.0000] <inaimathi>
data: Got a message! G1064

[18:27:25.0000] <Hixie_>
you shouldn't be seeing the "1e" if you are doing the chuncked encoding correctly

[18:27:30.0000] <inaimathi>
That's as written, connecting directly to the event-stream handler and publishing one message

[18:27:33.0000] <Hixie_>
it should get processed at the HTTP layer

[18:27:54.0000] <Hixie_>
so my guess is that you're mangling the http chunked transfer encoding stuff

[18:28:28.0000] <inaimathi>
High probability.

[18:28:37.0000] <inaimathi>
Ok, I'm off to read up on HTTP chunked transfer encoding

[18:28:47.0000] <inaimathi>
Thanks for your help, Hixie_

[18:29:11.0000] <Hixie_>
good luck...

[18:29:26.0000] <inaimathi>
Heh. I get the feeling I'll need it.

[18:29:39.0000] <inaimathi>
Anywhere you think I should start?

[18:31:41.0000] <Hixie_>
what's your web server?

[18:32:13.0000] <inaimathi>
I'm writing one (which is more or less the problem).

[18:32:28.0000] <Hixie_>
oh, in that case, i recommend writing a websocket server instead.

[18:32:34.0000] <Hixie_>
it's i zillion times easier, and gets you more.

[18:32:39.0000] <inaimathi>
Huh.

[18:33:02.0000] <Hixie_>
(and then serve the static resources from that off-the-shelf http server like apache or something)

[18:33:11.0000] <Hixie_>
s/that/an/

[18:33:46.0000] <inaimathi>
I'll give it a shot. My impression was that websocket support wasn't as consistent across browsers as SSEs.

[18:34:19.0000] <Hixie_>
what browsers do you care about?

[18:34:58.0000] <Hixie_>
caniuse.com suggest websocket is actually better supported than SSE

[18:35:03.0000] <Hixie_>
dunno how reliable that is

[18:35:29.0000] <inaimathi>
FF, Chrome and their Debian counterparts (although my pet browser is Conkeror, so I'd like to support it if I can at all manage). I take your point I guess.

[18:35:51.0000] <Hixie_>
ff and chrome definitely support websockets

[18:35:57.0000] <Hixie_>
no idea about conkeror

[18:36:32.0000] <Hixie_>
if you were using apache then i'd say use sse, because it's trivial to output sse messages from a CGI script

[18:36:50.0000] <Hixie_>
but if you're about to write your own HTTP server, then that changes the calculus a lot

[18:37:08.0000] <Hixie_>
web sockets is a couple hundred lines of code on the server in most languages at most

[18:37:27.0000] <Hixie_>
http takes thousands to do a half-decent implementation

[18:41:11.0000] <inaimathi>
Ok, I'll look into it.

[18:41:35.0000] <inaimathi>
You're right, from what I'm reading here, it's not high effort at all.

[18:41:54.0000] <inaimathi>
Thanks again

[19:11:04.0000] <zewt>
help, SSE means http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions to me and my parser keeps having to backtrack

[19:34:07.0000] <TabAtkins>
On the other hand, every time someone mentions SIMD stuff, I get confused and think they're talking about HTML.

[00:50:18.0000] <matjas>
http://isup.me/whatwg.org http://isup.me/software.hixie.ch

[02:08:13.0000] <jgraham>
zewt: I have the same issue whenever someone mentions NFC and doesn't mean "Normal Form C"

[02:09:26.0000] <hsivonen>
jgraham: me, too

[02:40:29.0000] <zcorpan>
when people talk about HTML i think of High Temperature Materials Laboratory

[03:56:22.0000] <jgraham>
zcorpan: Are you happy with the whole timeout=normal/long idea, rather than giving more precision?

[03:57:20.0000] <jgraham>
(for the overall harness, not for individual tests)

[03:57:38.0000] <zcorpan>
jgraham: what was the idea?

[03:58:23.0000] <jgraham>
By default you get a short timeout, say 10s. You can opt in to a longer timeout, say 60s. There are no more choices.

[03:59:23.0000] <jgraham>
(obviously the actual values there would be adjusted in autoimation scenarios so that all non-brokwn tests would actually complete)

[04:00:16.0000] <jgraham>
The theory seems to be that letting authors specify a number of ms doesn't make much sense because in many cases it totally depends on the nature of the system that the test is running on

[04:06:47.0000] <jgraham>
(for individual tests, I think a number-of-ms makes more sense because particular tests often do things like setTimeout that will take a known amount of time to complete)

[04:51:45.0000] <zcorpan>
<http://www.w3.org/mid/5238389B.7010701⊙nc> ... i wonder why they don't use critic

[04:52:40.0000] <zcorpan>
jgraham: i'm OK with that

[04:52:55.0000] <jgraham>
Why use one convenient, integrated system, when you can spread it out over email, wikis, github and notes on bits of paper passed under the door

[04:53:11.0000] <jgraham>
zcorpan: OK, I will have a got at implementing it then

[04:53:20.0000] <jgraham>
Well, I already started;)

[04:54:02.0000] <zcorpan>
would it make sense for the harness to be smart about the timeout if tests declare their timeout?

[04:54:12.0000] <jgraham>
Define "smart"?

[04:54:48.0000] <jgraham>
It is a common bug that people set test timeouts that are longer than the harness timeout

[04:54:54.0000] <zcorpan>
so for instance if a test has 15s timeout, the file's timeout could be e.g. 15+normal

[04:55:20.0000] <jgraham>
But I don't really know how to deal with that because I don't know the test timeout when the overall timeout is set

[04:55:36.0000] <zcorpan>
just increase the overall timeout dynamically

[04:55:44.0000] <jgraham>
And, moreover, for automation I plan to set the overall timeout externally before I even load the test

[04:55:55.0000] <jgraham>
and diable the in-harness timeout

[04:57:26.0000] <jgraham>
(of course it is *possible* to pass a message about that back to the automation. But it's not exactly easy)

[04:57:50.0000] <zcorpan>
ok

[09:37:36.0000] <JakeA>
Is there any spec reason browser couldn't allow a video as the src for an <img>

[09:37:54.0000] <JakeA>
Maybe play it without sound

[09:39:11.0000] <Hixie_>
the spec talks about that, iirc

[09:43:22.0000] <JakeA>
There's mention of gif/apng

[09:43:41.0000] <JakeA>
It doesn't explicitly disallow, say, webm

[09:43:59.0000] <JakeA>
No mention of audio

[09:44:04.0000] <JakeA>
Basically, animated webp needs to die

[09:44:09.0000] <JakeA>
such a silly idea

[09:44:40.0000] <Hixie_>
it just says that you can't have scripted content, right?

[09:44:42.0000] <Hixie_>
says you can't use HTML

[09:44:47.0000] <Hixie_>
and doesn't disallow video

[09:55:05.0000] <jgraham>
If you want video, what's wrong with a video element?

[10:01:11.0000] <JakeA>
I guess the question is, why do people use gif?

[10:03:29.0000] <miketaylr>
because it just works™

[10:04:16.0000] <jgraham>
I don't know, but I wish they wouldn't :p

[10:04:48.0000] <JakeA>
Just works, as in autoplays everywhere?

[10:05:32.0000] <JakeA>
animated webp sounds like the wrong answer for a question no one's asking

[10:05:43.0000] <miketaylr>
pretty much. and you can host them basically anywhere.

[10:06:05.0000] <miketaylr>
without needing to know about servers and content type and formats, etc

[10:06:31.0000] <zewt>
... there aren't exactly any alternatives, if you want something that works everywhere, supports transparency (even if bad transparency), and is computationally cheap

[10:06:50.0000] <Hixie_>
apng?

[10:06:59.0000] <zewt>
does that actually work?

[10:07:02.0000] <Hixie_>
sure

[10:07:21.0000] <zewt>
i don't have any software that can output it, so i haven't tried it

[10:07:25.0000] <miketaylr>
http://caniuse.com/apng

[10:07:28.0000] <Hixie_>
(in firefox)

[10:07:38.0000] <zewt>
(in firefox) != actually works :P

[10:08:15.0000] <Hixie_>
well, same as webp :-)

[10:08:24.0000] <miketaylr>
there's been a few articles about using animated gifs to get around certain mobile browsers not being able to play inline

[10:08:40.0000] <zewt>
miketaylr: :|

[10:09:26.0000] <jgraham>
In unrelated questions, if I have a scatter graph with an axis that looks like ' 4 ' 5 ' 6 ', what is the correct way to vent my frustration?

[10:09:52.0000] <miketaylr>
similar hack, zewt https://docs.google.com/document/pub?id=1GWTMLjqQsQS45FWwqNG9ztQTdGF48hQYpjQHR_d1WsI

[10:10:11.0000] <Hixie_>
jgraham: are you complaining about the origin, or the postioning of the grid?

[10:10:28.0000] <jgraham>
Hixie_: The psoitioning of the grid

[10:10:44.0000] <Hixie_>
then i recommend venting on twitter.

[10:10:50.0000] <jgraham>
Haha

[10:11:42.0000] <jgraham>
(although the fact that the origin isn't 0 makes the positioning of the grid harder to deal)

[10:12:21.0000] <zewt>
miketaylr: at least there's some justice in them having to use gross hacks to work around limitations of ... their own platform

[10:12:58.0000] <miketaylr>
:)~

[10:13:47.0000] <Hixie_>
jgraham: (if the number represent periods of time, e.g. days, months, years, then i think that alignment makes sense. if they represent specific moments, then yeah, that's dumb and annoying.

[10:14:03.0000] <Domenic_>
Hixie_: what would you have recommended if he was complaining about the origin? :P

[10:15:46.0000] <Hixie_>
facebook.

[10:16:05.0000] <jgraham>
Hixie_: Well, it's times of day.

[10:16:26.0000] <jgraham>
So looking closely, the tickmarks are totally misleading

[10:16:29.0000] <Hixie_>
oh no, i didn't close my brackets.)

[10:16:59.0000] <jgraham>
Assuming that the data is sampled on the hour, they are half-hour tick marks

[10:17:24.0000] <jgraham>
OTOH, it's possible that the data is sampled on the half hour and I still have mu original problem

[10:17:41.0000] <jgraham>
Basically this chart is rubbish

[10:17:58.0000] <jgraham>
I wonder how people who deal with this sort of thing ever day manage to get anything done

[10:18:03.0000] <jgraham>
*every

[10:18:30.0000] <zewt>
there's a question everyone, of every walk of life, asks themselves periodically

[10:19:09.0000] <zewt>
one of those little things we all share, as carlin put it

[10:27:36.0000] <bradleymeck>
is there any spec working on improving keyboard accessibility, looked in the DOM groups on w3c but didn't see too much activity for keyboard accessibility

[10:28:22.0000] <Hixie_>
HTML has done some work in that area, e.g. by providing new types in form controls

[10:28:27.0000] <Hixie_>
what specific problem are you thinking about?

[10:30:26.0000] <bradleymeck>
Hixie_: dialogs/modals/3rd party widgets need a little bit finer control over focus. IE modals should be where iteration starts/stops when iterating on a document. 3rd party widgets may want to have slightly better control over tab index if you mix tabindex=0 and tabindex=number

[10:31:04.0000] <bradleymeck>
I've written up the basics of what we did at BV as a spec, but am inclined to port it to existing stuff if it exists

[10:33:18.0000] <bradleymeck>
the big use cases are modals, and <form>s that are positioned with CSS rather than dom tree due to nesting problems and supporting older browsers

[10:37:01.0000] <Hixie_>
ah, yes. HTML has addressed that. Look for the inert="" attribute in the spec. http://whatwg.org/html#inert

[10:38:25.0000] <bradleymeck>
mmm could do a crawl when popping up a modal i guess and that fixes modals, anything about <form>s that are inlined for CSS?

[10:39:05.0000] <Hixie_>
"modals" are handled in HTML by the new <dialog> element

[10:39:10.0000] <Hixie_>
http://whatwg.org/html#dialog

[10:39:23.0000] <Hixie_>
makes it all work basically automatically, including making the other parts of the spec inert

[10:39:28.0000] <Hixie_>
er

[10:39:30.0000] <Hixie_>
parts of the doc

[10:39:46.0000] <Hixie_>
not sure what you mean by "<form>s that are inlined for CSS"

[10:41:56.0000] <bradleymeck>
we have submission forms that are appended to the bottom of the body (we provide 3rd party widgets), these are inlined for display / keyboard purposes to places higher in the dom tree since our customers may have wrapped the area of the 3rd party widget in a <form>. we cannot use form="x" due to supporting older browsers and not wanting to "infect" client <forms>.

[10:42:34.0000] <bradleymeck>
dialog might work if we can polyfill it properly as well

[10:42:49.0000] <Hixie_>
i have no idea what that means, sorry. what is the difference between "appended to the bottom of the body" and "inlined for display / keyboard purposes" ?

[10:42:58.0000] <bradleymeck>
ill make a jsfiddle

[10:43:08.0000] <Hixie_>
do you mean "positioned" rather than "inlined"?

[10:43:54.0000] <Hixie_>
i think the solution is probably form="".

[10:44:06.0000] <Hixie_>
anything we add to the spec will naturally take some time to be usable, though

[10:44:10.0000] <Hixie_>
but that's true of anything

[10:46:30.0000] <bradleymeck>
positioned, yes

[10:47:03.0000] <bradleymeck>
http://jsfiddle.net/6WchK/

[10:47:28.0000] <bradleymeck>
either way if form="" is the way to do it I guess we can't move to that for quite a while

[10:47:59.0000] <bradleymeck>
thanks for the <dialog> info, will try and see if we can make that work

[10:50:26.0000] <Hixie_>
web components are probably the even better long-term solution to that

[10:50:55.0000] <Hixie_>
so i guess, to answer your original question, HTML and Web Components are indeed fixing the accessibility issues you're worried about. :-)

[10:51:30.0000] <bradleymeck>
yep, just can't use form= ever until it is supported everywhere

[10:54:26.0000] <Jasper>
Hixie_, how are the two path examples you gave in http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0186.html different?

[10:54:33.0000] <Jasper>
erm, wrong link

[10:54:53.0000] <Jasper>
Hixie_, how are the two examples in http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0185.html different?

[10:55:42.0000] <Jasper>
Hixie_, the only thing I can imagine is that you'll double-paint the arc and get some fringes around the edges

[10:57:35.0000] <Hixie_>
oh, i meant to put beginPath() after hte first fill(), my bad

[10:58:15.0000] <Jasper>
Hixie_, so I'm not the only one who makes that mistake.

[10:58:18.0000] <Jasper>
good to know

[10:58:34.0000] <Hixie_>
i make that mistake all the freaking time

[10:59:11.0000] <Jasper>
it's the biggest mistake in the canvas API. doing an operation should really clear the working path

[10:59:26.0000] <Jasper>
and it would be nice if save()/restore() saved and cleared the path as well

[10:59:33.0000] <Jasper>
but oh well

[11:01:07.0000] <Hixie_>
well, you sometimes want to both stroke and fill a path

[11:01:08.0000] <Hixie_>
but yeah, that's one thing hte Path API is supposed to fix

[11:01:39.0000] <Jasper>
Hixie_, yeah, cairo has fill_preserve(); stroke_preserve(); for this use case

[11:32:22.0000] <Hixie_>
TabAtkins: (further to my e-mail just now) but really i just wish we had real type checking.

[12:20:27.0000] <matjas>
annevk: thanks for filing that ES identifier bug and CCing me

[12:21:36.0000] <annevk>
matjas: figured you'd be interested

[12:21:36.0000] <annevk>
matjas: everyone basically agreed that since IE throws and ES having magic lists was not desirable, relying on Unicode would be better for this


2013-09-18
[02:38:29.0000] <krit>
Are there static versions of the WHAWG specs that can be used for referencing? So a version of the spec to a specific commit that can be referenced and viewed in the browser?

[02:45:59.0000] <zcorpan>
krit: https://github.com/whatwg/html-mirror - you could use rawgithub.com on a specific commit of complete.html. no multipage though afaik

[02:47:05.0000] <krit>
zcorpan: so no hosted version?

[02:47:29.0000] <krit>
zcorpan: just the source itself is in a repository

[02:48:10.0000] <zcorpan>
krit: https://rawgithub.com/whatwg/html-mirror/f0225ebc726f806502bf85905b40be7f9d4e1311/complete.html

[02:49:07.0000] <krit>
zcorpan: thanks. Is there a similar option for the other specs like URL or Fetch?

[02:49:13.0000] <zcorpan>
http: instead of https: to get the style sheet to work

[02:49:36.0000] <zcorpan>
krit: yeah they are in github so the same trick should work for those

[02:50:38.0000] <zcorpan>
why do you want to point to a specific commit?

[02:50:43.0000] <krit>
zcorpan: ok, thanks will take a look

[02:51:33.0000] <krit>
zcorpan: The specification text changes from time to time as do some definitions. For quoting it is desirable to reference s specific version.

[02:52:03.0000] <krit>
zcorpan: This can get more important if the W3C has an official statement on normative references to WHAT

[02:52:07.0000] <krit>
WG specs

[02:52:41.0000] <zcorpan>
i mean in what context do you want to put the reference?

[02:53:50.0000] <krit>
zcorpan: in a context of another specification that references a WHATWG spec

[02:55:15.0000] <zcorpan>
krit: ok. i'm not sure that's a good idea. but my experience with discussing this in the past hasn't been productive so i'll leave it at that :-)

[03:02:15.0000] <jgraham>
I wont:

[03:02:19.0000] <jgraham>
That isn't a good idea

[03:02:23.0000] <jgraham>
Please don't do it

[03:02:33.0000] <jgraham>
It just means that your reference won't match reality

[03:02:37.0000] <jgraham>
+'

[04:20:15.0000] <tobie_>
marcosc: there still seems to be some weird issues with specref. Not sure what gives but the latest release crashes when restarting the application.

[04:21:48.0000] <tobie_>
marcosc: could there possibly be a file encoding issue (https://github.com/tobie/specref/commit/b30cb27) that wasn't rolled back properly?

[04:37:11.0000] <jgraham>
zcorpan_: So based on some discussion last night in #testing, I have the idea of making most tests in testharness.js not timeout until the overall harness times out. This means that you wouldn't get the pattern of doing setup({timeout:10100}); async_test("foo", {timeout:10000})

[04:37:44.0000] <jgraham>
People would just set timeouts for specific tests in cases where the tests are run in sequence

[04:38:01.0000] <jgraham>
So that the next test doesn't start before the previous one finished

[04:38:30.0000] <jgraham>
Does that sound at all sensible?

[04:39:48.0000] <zcorpan_>
so by default, tests don't have a timeout, but get a TIMEOUT result if the harness times out?

[04:40:13.0000] <zcorpan_>
and you can still set specific timeout for certain tests in ms?

[04:40:21.0000] <jgraham>
Yes

[04:40:38.0000] <zcorpan_>
sounds OK

[04:41:23.0000] <jgraham>
Makes it harder to integreate with automation since you really want the harness to time out if possible, but that's OK, I think

[04:41:55.0000] <zcorpan_>
s//don't/ ?

[04:42:33.0000] <jgraham>
No, I mean you can't just kill the whole browser at the timeout because then you will get 0 results if any test timed out

[04:43:06.0000] <zcorpan_>
oh

[04:46:19.0000] <zcorpan_>
so can't you report the result for each test when it's ready?

[04:47:47.0000] <jgraham>
I could do that I guess

[04:48:01.0000] <jgraham>
YOu still wouldn't get any result at all for the tests that timed out though

[04:48:57.0000] <zcorpan_>
right. but you can signal that the test exists when it is created, and consider it to be a TIMEOUT if you don't get anything, maybe?

[04:49:17.0000] <jgraham>
Yeah. It makes the wire protocol pretty verbose though

[04:49:31.0000] <zcorpan_>
true

[04:49:51.0000] <jgraham>
It's probably easier just to add a timeout in js

[04:50:13.0000] <jgraham>
which will cause all the results to be reported

[04:51:21.0000] <jgraham>
(this is the setup I originally had, but I moved to the simpler system of just having a single timeout that dealt with all harness timed out / browser hung / etc. scenarios)

[06:02:37.0000] <marcosc>
tobie_: looks like the encoding broke

[06:03:18.0000] <tobie_>
Thought so.

[06:03:38.0000] <tobie_>
No idea how to fix that (outside of a forced update).

[06:03:59.0000] <marcosc>
tobie_: did you merge in Addison's stuff?

[06:04:14.0000] <tobie_>
I didn't touch anything.

[06:04:38.0000] <marcosc>
hmm... ok, looking

[06:04:58.0000] <tobie_>
Seems that your rollback didn't fix everything.

[06:05:10.0000] <marcosc>
stupid rollback :)

[06:05:17.0000] <tobie_>
yeah.

[06:05:21.0000] <tobie_>
Stupid encoding.

[06:05:30.0000] <marcosc>
heh, strange because Travis said it was all cool

[06:06:07.0000] <marcosc>
tobie_: I think I didn't roll back far enough

[06:06:14.0000] <marcosc>
I needed to go one more

[06:06:43.0000] <tobie_>
It is possible that the test suite doesn't catch these encoding issues.

[06:06:59.0000] <tobie_>
(if encoding issues are the problem.)

[06:17:49.0000] <jgraham>
Wait, what? Service Workers? Is this happening in secret again?

[06:18:31.0000] <annevk>
jgraham: nah

[06:18:38.0000] <annevk>
jgraham: stuff just got renamed

[06:18:45.0000] <jgraham>
Where?

[06:18:59.0000] <annevk>
jgraham: same place, https://github.com/slightlyoff/ServiceWorker/

[06:19:13.0000] <annevk>
jgraham: (old URL https://github.com/slightlyoff/NavigationController/ redirects there)

[06:19:17.0000] <jgraham>
Well that's clearly a different place

[06:20:15.0000] <annevk>
*shrug*

[06:20:37.0000] <jgraham>
Would be nice if all this github stuff didn't take whatwg/webapps entirely out of the loop

[06:42:50.0000] <krit>
annevk: ping

[06:48:44.0000] <marcosc>
Encoding question ... we have a JSON file on GH and a pull request we got seems to have changed the encoding. To prevent that from happening, would it be a good idea to at a BOM to the file?

[06:51:08.0000] <marcosc>
See: https://github.com/tobie/specref/commit/b30cb27

[06:52:09.0000] <jgraham>
Aren't JSON files utf8 by definition?

[06:52:22.0000] <jgraham>
Someone might have given you non-utf8

[06:52:37.0000] <hasather_>
marcosc: wouldn't the best thing be to just not accept the pull request, and ask the committer to fix it?

[06:52:41.0000] <jgraham>
But then you don't have a JSON file...

[06:52:42.0000] <SimonSapin>
marcosc: who know what broken tool is responsible. I don’t think a BOM would help much

[06:52:54.0000] <jgraham>
Right, just reject the PR

[06:52:58.0000] <gsnedders>
"JSON text SHALL be encoded in Unicode. The default encoding is UTF-8"

[06:53:15.0000] <gsnedders>
(What counts as "encoded in Unicode"?)

[06:53:48.0000] <jgraham>
Oh

[06:53:55.0000] <jgraham>
Unicode isn't an encoding

[06:53:55.0000] <marcosc>
hasather_: the problem is that we didn't spot the problem until after

[06:53:59.0000] <jgraham>
Crockford is an idiot

[06:54:03.0000] <gsnedders>
(I can encode into Unicode, as an abstract model, and then serialize it as ISO-8859-1?)

[06:54:04.0000] <jgraham>
News at 11

[06:54:18.0000] <marcosc>
heh

[06:54:19.0000] <SimonSapin>
"JSON may be represented using UTF-8, UTF-16, or UTF-32."

[06:54:35.0000] <annevk>
krit: yo

[06:54:47.0000] <zcorpan_>
UTF-32? Why not UTF-9?

[06:54:58.0000] <krit>
annevk: hi. The URL spec does not handle data URL's yet. Is that intended?

[06:55:05.0000] <gsnedders>
SimonSapin: That's different to what it says above!

[06:55:09.0000] <gsnedders>
SimonSapin: Bloody hell.

[06:55:14.0000] <jgraham>
(isn't the guy that made the PR in the i18n WG?)

[06:55:27.0000] <marcosc>
SimonSapin: I was thinking that if we get a PR with the missing BOM, at least we could easily spot that

[06:55:27.0000] <jgraham>
(if you are American and don't understand irony, that is is)

[06:55:30.0000] <jgraham>
*it

[06:55:40.0000] <annevk>
zcorpan_: so I learned yesterday that UTF-9 and UTF-18 are not that crazy: http://en.wikipedia.org/wiki/36-bit

[06:55:45.0000] <jgraham>
(if you are American and do understand irony, good for you)

[06:56:08.0000] <annevk>
krit: it does

[06:56:08.0000] <jgraham>
(if you are some other nationality and don't understand irony, sorry I can't help)

[06:56:12.0000] <hasather_>
marcosc: wasn't it easy enough to spot that something was broken there? :)

[06:56:34.0000] <marcosc>
hasather: no, not when we got the request

[06:56:38.0000] <marcosc>
it looked fine :(

[06:56:39.0000] <SimonSapin>
marcosc: given that some tool is broken enough to do this in the first place, can you rely on it removing the BOM?

[06:56:42.0000] <krit>
annevk: so data is not a scheme?

[06:56:47.0000] <krit>
"data"

[06:56:51.0000] <marcosc>
SimonSapin: yeah you are probably right

[06:57:25.0000] <SimonSapin>
krit: I have http://simonsapin.github.io/data-urls/ , but it’s more a collection of issues that anything

[06:57:31.0000] <SimonSapin>
than*

[06:57:45.0000] <marcosc>
hasather: see here: https://github.com/tobie/specref/pull/44/files

[06:57:54.0000] <annevk>
krit: it's a scheme, sure

[06:57:57.0000] <marcosc>
hasather: that's the original PR - as you can see, it all looks good

[06:58:05.0000] <marcosc>
but once it merged, it all went bad

[06:58:14.0000] <annevk>
krit: it's not a relative scheme if that's what you mean

[06:58:28.0000] <krit>
annevk: ah, that explains

[06:58:29.0000] <krit>
it

[06:58:38.0000] <krit>
SimonSapin: still a bit red :)

[06:59:32.0000] <SimonSapin>
krit: as soon as you poke in the corner cases, nobody knows what should really happen.

[06:59:56.0000] <krit>
SimonSapin: non-deterministic specs!

[06:59:57.0000] <jgraham>
marcosc: Uh, no the original PR looks broken

[07:00:04.0000] <jgraham>
https://github.com/addison/specref/commit/b30cb27ef8eb6356a77f96ceb998d6d4b5386d98

[07:00:20.0000] <SimonSapin>
krit: just plain boring undefined

[07:00:50.0000] <marcosc>
jgraham: strange, because what I reviewed was  https://github.com/tobie/specref/pull/44/files

[07:01:35.0000] <jgraham>
marcosc: There seem to be two commits

[07:01:46.0000] <jgraham>
One that introduces the error and one that reverts it

[07:01:58.0000] <marcosc>
ah, that's why I didn't see it

[07:02:14.0000] <jgraham>
Although it is pretty fricking hard to tell because github is a pile of shit

[07:02:33.0000] <marcosc>
... coming to a sad realization too :(

[07:04:46.0000] <jgraham>
Sometimes I think I should start my own company doing something technically interesting just so that I can have a blog, which would then attract a large readership, finally allowing me to post "github considered slightly crappy" in front of a massive audience, whereupon I would disband the whole enterprise and go back to quietly testing the web

[07:05:41.0000] <SimonSapin>
jgraham: that’s some yak shaving

[07:06:02.0000] <annevk>
Domenic_: https://gist.github.com/annevk/6609620

[07:07:55.0000] <krit>
annevk: just to make sure. if the URL is "#fragment", than the URL does not have a scheme?

[07:08:15.0000] <Domenic_>
annevk: https://gist.github.com/domenic/0c47ae300608341f3d7f (but that was before the { done, value } idea)

[07:08:28.0000] <annevk>
krit: it does after you parse it, or it turns into failure if there's no base URL...

[07:09:14.0000] <krit>
annevk: ah ok. So after parsing you have an absolute path with a scheme "http" or "frp" for example

[07:09:24.0000] <krit>
ftp

[07:09:48.0000] <krit>
(just to name two :P was not meant to be exclusive)

[07:11:04.0000] <annevk>
depends on the base URL

[07:12:32.0000] <slightlyoff>
jgraham: there's absolutely a plan to bring this all back to webapps

[07:12:55.0000] <slightlyoff>
jgraham: the goal isn't to sideline the standards process, but to build consensus slowly among people who are heavily invested in the area

[07:14:36.0000] <Domenic_>
GitHub is *way* more open, from a developers on the ground perspective, than these mailing lists.

[07:14:57.0000] <Domenic_>
This is #1 piece of feedback from developers when I give talks on extensible web etc.

[07:17:11.0000] <krit>
annevk: the spec explains that a URL is either a abs or rel URL which can be followed by a fragemnt. rel URL is a URL w/o scheme but must be relative to base URL… base URL is an absolute URL with relative scheme

[07:17:34.0000] <annevk>
krit: sure, at the writing level

[07:17:42.0000] <annevk>
krit: at the spec level you only deal with parsed URLs

[07:17:44.0000] <krit>
annevk: so how do you get to the base URL

[07:18:05.0000] <krit>
annevk: … from a relative URL

[07:18:12.0000] <annevk>
krit: you can parse with a null base (although maybe that ought to be about:blank as a base URL always...)

[07:18:41.0000] <annevk>
krit: not sure I parse that question

[07:19:10.0000] <krit>
annevk: the term relative URL is explained with the relation to the base URL

[07:19:35.0000] <krit>
annevk: and it is not clear to me how the base URL looks like for a base URL from resding the first paragraph

[07:19:50.0000] <krit>
annevk: (I am at section 5)

[07:20:26.0000] <krit>
annevk: an introducing example how a URL does look like could help as well

[07:20:28.0000] <annevk>
krit: the base URL is derived from the URL of the resource, or e.g. <base>

[07:20:43.0000] <krit>
annevk: I took this as reference :P http://en.wikipedia.org/wiki/URI_scheme#Examples

[07:21:06.0000] <annevk>
yeah, at some point we should include that I suppose

[07:21:12.0000] <annevk>
once there's some implementations

[07:22:01.0000] <krit>
annevk: what is a <base>? according to the spec: optionally with a base URL base

[07:22:09.0000] <krit>
annevk: which doesn't explain it :)

[07:22:51.0000] <krit>
annevk: as you noticed, I am no expert at all on URL and try to understand it from just reading the spec

[07:23:11.0000] <annevk>
krit: <base> is an HTML element

[07:23:28.0000] <krit>
you mean like <img>

[07:23:36.0000] <annevk>
krit: yes

[07:24:24.0000] <annevk>
krit: if there's no base URL, parsing "/test.html" will return failure

[07:25:09.0000] <annevk>
krit: also if the base URL does not have a relative scheme

[07:25:31.0000] <jgraham>
I don't really see how github is "more open". I could perhaps buy "more familiar".

[07:26:25.0000] <annevk>
It's not more open if you use private gists, Domenic_ ;)

[07:26:32.0000] <krit>
annevk: "the base URL is derived from the URL of the resource, or e.g. <base>" so if <img> is from file://test.html, then base URL is derived from  file://test.html

[07:26:50.0000] <annevk>
krit: no, <base> is an element to override the base URL of a resource

[07:28:44.0000] <krit>
annevk: how does <img src="image.png"> override the base URL if <img> is in the document at file://test.html?

[07:28:55.0000] <annevk>
krit: <img> doesn't override the base URL

[07:29:05.0000] <krit>
Ancil: you said <base> does

[07:29:07.0000] <annevk>
krit: <base> does

[07:29:16.0000] <krit>
annevk: and <img> is <base>

[07:29:23.0000] <annevk>
krit: no, <img> is an element, just like <base> is

[07:29:45.0000] <krit>
annevk: oh you really mean there is a <base> element?

[07:29:52.0000] <annevk>
krit: dude

[07:30:07.0000] <SimonSapin>
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-base-element

[07:30:12.0000] <krit>
/me is obviously confused

[07:31:13.0000] <zcorpan_>
hmm. data--="" seems borked in the dataset api

[07:31:32.0000] <Domenic_>
hah nice zcorpan_

[07:32:47.0000] <annevk>
zcorpan_: should be dataset["-"]

[07:33:17.0000] <zcorpan_>
annevk: yeah. but setting "-" throws

[07:33:40.0000] <annevk>
zcorpan_: no

[07:34:00.0000] <zcorpan_>
oh, right

[07:34:01.0000] <krit>
annevk: ok, got the purpose of <base> :P however, this is HTML specific. So say the example does not have a base element… then the document URL of <img> is used for base URL ?

[07:34:14.0000] <annevk>
krit: yes

[07:34:35.0000] <annevk>
krit: <base> also affects SVG, just use the correct namespace

[07:35:05.0000] <krit>
annevk: ok, thanks

[07:40:13.0000] <zcorpan_>
wonder if svg should allow <base> in its content model

[07:43:53.0000] <annevk>
zcorpan_: <base> is terrible, let's not encourage it

[10:11:20.0000] <TabAtkins>
Hixie_: But we don't have type checking, and it's not likely to happen soon, and when it does it will be completely opt-in, so you should stop trying to design things around the assumption of "this is how a type-checked language would do it".

[10:13:31.0000] <TabAtkins>
JakeA: There's no reason video can't be in an <img>, and I've suggested that very thing in blink-dev. We're waiting for it to be technically *possible* on our end before seriously considering it. (Right now, spinning up videos is unnecessarily expensive. Doing lots of small git-style videos would kill your page at the moment. We're fixing this.)

[10:13:47.0000] <TabAtkins>
JakeA: But yeah, basically exposing a Vine-like interface for video-in-<img> would be wonderful.

[10:14:08.0000] <TabAtkins>
autoplaying and muted, with the only control being an unmute button

[10:17:28.0000] <jgraham>
Wow, we have very different visions of utopia

[10:18:15.0000] <TabAtkins>
jgraham: Yeah, you hate gifs, while I enjoy tumblr.

[10:18:29.0000] <TabAtkins>
Presumably it's related to you being crotchety. ^_^

[10:50:36.0000] <JakeA>
TabAtkins: Yeah, although I'm not convinced what problems it solves that <video> with autoplay & no controls doesn't

[10:55:12.0000] <zewt>
seems better to treat gifs in img as a weird backwards-compatibility thing, and instead optimize <video> to be lighter-weight, but as for how practical or annoying that is to actually implement I don't know

[10:57:43.0000] <zewt>
(rather than having two ways to do the same thing, and making authors have to pick between "features and expensive" or "no features and cheap")

[11:00:18.0000] <TabAtkins>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2527 In anything but webkit/blink, could someone try click-dragging some text down to try to force the div to scroll, then try it again starting from the input?

[11:03:07.0000] <zewt>
no scrolling

[11:03:16.0000] <zewt>
(in FF, IE9)

[11:03:23.0000] <TabAtkins>
Okay, cool.

[11:03:36.0000] <TabAtkins>
chrome scrolls if you start the drag from inside the <input>, which seems like a bug.

[11:43:32.0000] <JakeA>
zewt: agree about the gif thing. Although is there a good reason to support video content as CSS imagery?

[11:53:52.0000] <annevk>
matjas: yt?

[11:57:23.0000] <annevk>
matjas: are you saying https://bugs.ecmascript.org/show_bug.cgi?id=1802 is invalid?

[12:00:09.0000] <SimonSapin>
TabAtkins: no scrolling in Presto either

[12:00:12.0000] <SimonSapin>
fwiw

[12:05:02.0000] <bradleymeck>
Getting people to comment on spec is hard. Still having trouble getting implementors/consumers of MutationObservers to make any comments about them good or bad. Most just acknowledgement of their use/implementation or ask if it causes a bug in their code.

[12:07:15.0000] <annevk>
bradleymeck: reviewing is hard

[12:07:49.0000] <annevk>
FWIW: http://wiki.ecmascript.org/doku.php?id=strawman:embracing_workers

[12:07:52.0000] <bradleymeck>
all of the spec is hard. I gain more respect about specification issues the more I try to talk to people

[12:08:25.0000] <bradleymeck>
[[transfer]] makes me zoo happy

[12:08:29.0000] <bradleymeck>
soo*

[12:08:55.0000] <annevk>
it's non-extensible though

[12:09:04.0000] <annevk>
mostly much needed refactoring

[12:09:49.0000] <bradleymeck>
its a proposal for now, just talk about it is encouraging :). I actually had a twitter comment about this topic the other day

[12:10:23.0000] <annevk>
I know it's a proposal, I just wrote it

[12:11:28.0000] <jamesr__>
gah respec

[12:12:41.0000] <bradleymeck>
annevk: Then I forgot to thank you. So thanks on that and on my issues :)

[12:32:22.0000] <TabAtkins>
jamesr__: What about respec?

[12:32:41.0000] <zewt>
gah

[12:32:44.0000] <zewt>
i think he was pretty clear on that point

[12:58:19.0000] <TabAtkins>
zewt: Yeah, I was wondering *why* he was gah'ing.

[13:01:01.0000] <annevk>
respec messes up IDL and method definitions generally

[13:01:17.0000] <annevk>
very much old-style, it's configurable, but nobody does that

[13:03:17.0000] <TabAtkins>
yeah, it's all kinds of weird.

[13:03:32.0000] <TabAtkins>
happy with what me and plinss have come up with for Bikeshed.

[13:04:01.0000] <TabAtkins>
A resilient parser (so it won't die as new features are added to IDL) that we just use to decorate <pre class=idl> contents with <dfn>/<a> markup automatically.

[13:04:14.0000] <zewt>
TabAtkins: because of respec. duh

[13:04:24.0000] <TabAtkins>
zewt: Thanks. So helpful. ^_^

[13:04:26.0000] <zewt>
i'm helping, i'm helping

[13:04:28.0000] <annevk>
TabAtkins: Anolis-style compatible?

[13:04:49.0000] <annevk>
TabAtkins: is Bikeshed open source?

[13:05:19.0000] <TabAtkins>
annevk: I dunno what Anolis-style is, because it's not documented in the current docs.  But I do plan on eventually adding an Anolis compat-mode.

[13:05:30.0000] <TabAtkins>
annevk: Yes, it's in my github: http://github.com/tabatkins/bikeshed

[13:06:03.0000] <annevk>
interface <dfn>trololol</dfn> { boolean attribute <span title=dom-trololol-member>member</span>; };

[13:06:10.0000] <TabAtkins>
Someone actually documenting Anolis' features would be greatly appreciated, and would bring the compat-switch closer.

[13:06:38.0000] <TabAtkins>
Why mark anything up?  Bikeshed just needs plain IDL text, and adds all the markup automatically for you.

[13:06:47.0000] <TabAtkins>
But it is marked up in that style, yes.

[13:06:55.0000] <annevk>
I'm just illustrating what we do now :)

[13:09:42.0000] <TabAtkins>
http://dev.w3.org/csswg/css-font-load-events/#FontFaceSet-interface shows off the current idl stuff.

[13:11:38.0000] <TabAtkins>
From this source: http://dev.w3.org/csswg/css-font-load-events/Overview.src.html#FontFaceSet-interface

[13:20:07.0000] <annevk>
Domenic_: fwiw, I recommend a new thread for the alternative Stream proposal

[13:20:17.0000] <annevk>
Domenic_: current thread seems lost

[13:20:28.0000] <Domenic_>
annevk: sounds good. plan to do so by end of weekend probably.

[13:21:12.0000] <TabAtkins>
Yeah, I lost track of what was going on for the Stream stuff a long time ago.  A fresh thread with the proposal would be great.

[13:28:41.0000] <jamesr__>
TabAtkins: FOUC

[13:29:03.0000] <jamesr__>
it feels like a system designed by someone who doesn't understand the web

[13:29:33.0000] <jamesr__>
which is awful for something that's supposed to define the web

[13:31:04.0000] <TabAtkins>
I think it's just "hey, JS is easy to work with, so let's do the spec generation in it".

[13:31:10.0000] <TabAtkins>
And then it's accidentally really painful and bad.

[13:33:57.0000] <matjas>
annevk: no, https://bugs.ecmascript.org/show_bug.cgi?id=1802 is valid

[13:34:36.0000] <matjas>
unless I misunderstood TR31 (which may very well be the case)

[13:35:20.0000] <annevk>
matjas: did you see my email?

[13:35:32.0000] <annevk>
matjas: following the dots it seems 2E2F is fine as ID_Start

[13:38:51.0000] <matjas>
annevk: Pattern_Syntax, though

[13:39:00.0000] <matjas>
annevk: just replied

[13:40:37.0000] <annevk>
matjas: okay, so you're wrong in https://code.google.com/p/v8/issues/detail?id=2892 ?

[13:42:24.0000] <matjas>
annevk: ES5 doesn’t use ID_Start, it just lists the Unicode categories directly, hence the difference

[13:42:52.0000] <matjas>
see my old blog post if you’re interested

[13:43:21.0000] <matjas>
ES6 simplifies the whole thing by just deferring to TR31 (more or less)

[13:43:38.0000] <annevk>
matjas: okay, so the comment you're making there is about ES5, while I filed a bug about ES6

[13:43:56.0000] <annevk>
matjas: actually, you filed that bug, that's just confusing

[13:44:46.0000] <matjas>
i think your comment #2 on that page is incorrect

[13:46:30.0000] <matjas>
annevk: V8 currently implements ES5 rules for identifiers, so it allows 2E2F

[13:47:07.0000] <matjas>
but it shouldn't since it won't be allowed anymore in ES6

[13:47:12.0000] <annevk>
I see what you mean, however, saying to blacklist 2E2F does not seem appropriate either

[13:47:27.0000] <annevk>
The list needs to be generated based on ID_Start

[13:48:34.0000] <matjas>
i see. so in your comment you meant to say "generate the list based on TR31 as per ES6 rather than hardcoding the categories as per ES5"

[13:49:22.0000] <matjas>
simply using a different Unicode version would not make a difference for 2E2F afaict

[13:50:40.0000] <annevk>
yes (to both)

[13:51:41.0000] <matjas>
then we're in agreement

[14:18:54.0000] <Hixie_>
krit|zZz: i try to discourage referencing old versions, because they tend to end up in google search, and then you end up with the kind of mess the w3c has, where people are always ending up looking at obsolete specs without realising it

[14:19:30.0000] <Hixie_>
krit|zZz: other specs should _definitely_ never refer to a version of the spec with bugs that have since been fixed

[14:22:08.0000] <Hixie_>
zcorpan: did you conclude data--="" worked ok with the API, or is there a bug in the spec?

[14:22:20.0000] <annevk>
Hixie_: works ok

[14:22:27.0000] <Hixie_>
TabAtkins: i don't design things around the assumption of "this is how a type-checked language would do it".

[14:22:37.0000] <zcorpan>
Hixie_: i think the spec is ok

[14:22:54.0000] <Hixie_>
k

[16:08:58.0000] <Hixie_>
teehee, anne keeps saying "plan of record"

[16:09:08.0000] <Hixie_>
/me wonders where this record is :-)

[16:11:56.0000] <jgraham>
Doesn't "plan of record" just mean "what TC39 are thinking this week"?

[16:12:04.0000] <jgraham>
</rimshot>

[16:12:45.0000] <Hixie_>
one of them was about javascript: and navigation, which i think is just the fetch spec, not anything to do with js

[16:14:18.0000] <jgraham>
I wasn't being serious :)

[16:20:06.0000] <reyre>
how does the positioning in the webvtt processing model with 'vw' and 'vh' CSS units make sense? these will mostly always be relative to the page viewport

[16:22:13.0000] <Hixie_>
the viewport is redefined for vtt purposes

[16:22:19.0000] <Hixie_>
or at least, it used to be, i assume that's still there

[16:22:23.0000] <Hixie_>
search for "viewport"

[16:24:14.0000] <reyre>
Hixie_: i'm not seeing anything, but i see a lot of references to 'video viewport' so i guess it's implicit

[16:24:28.0000] <Hixie_>
file a bug to make it explicit :-)

[16:24:29.0000] <reyre>
but why not just use %

[16:24:40.0000] <reyre>
it's the same in practice, no? if we just use %

[16:24:42.0000] <Hixie_>
(but i'm pretty sure it was explicit)

[16:24:49.0000] <reyre>
Hixie_: i'll take a closer look

[16:24:57.0000] <Hixie_>
i don't think it's the same, but i don't have it paged in

[16:26:17.0000] <reyre>
Hixie_: ah "The viewport (and initial containing block) is video's rendering area."


2013-09-19
[17:23:00.0000] <rniwa>
wycats: hi, I just landed the initial version of the new DoYouEvenBench in http://trac.webkit.org/changeset/156073

[17:23:06.0000] <rniwa>
wycats: you can open benchmark.html to run it

[17:23:16.0000] <rniwa>
wycats: thanks for the help again!

[17:58:43.0000] <MikeSmith>
so NavigationController is now ServiceWorker

[17:59:24.0000] <MikeSmith>
with a short stop at EventWorker for a while on the way ServiceWorker

[00:32:57.0000] <hsivonen>
Is Singaporean Chinese written using simplified or traditional characters?

[00:34:40.0000] <heycam>
simplified, looks like

[00:34:42.0000] <heycam>
https://en.wikipedia.org/wiki/Singapore_Chinese_Characters

[00:35:17.0000] <heycam>
interesting that the simplification is not exactly the same as mainland china

[00:35:41.0000] <heycam>
(oh that's just the earlier 1969 simplification which isn't exactly the same)

[00:37:27.0000] <hsivonen>
http://en.wikipedia.org/wiki/Singaporean_Mandarin#Writing_system is more ambiguous

[00:38:37.0000] <heycam>
I wouldn't be surprised if there was a mix used on shopfronts etc.

[00:39:21.0000] <hsivonen>
Yeah, looks like Windows has the same legacy code page for  Singapore and the PRC

[00:40:18.0000] <hsivonen>
Macao, however, seems to use traditional characters

[00:42:57.0000] <heycam>
makes sense, having a similar history of return to China as HK, only in the last 20 years

[00:43:10.0000] <zcorpan>
<http://www.w3.org/mid/F9A196AC-1C94-407C-86CB-83553D9F8897⊙ac>

[00:44:01.0000] <heycam>
zcorpan, is that really the CSS WG policy?

[00:44:44.0000] <zcorpan>
heycam: afaik the WG policy hasn't changed (yet)

[00:44:49.0000] <hsivonen>
It's sad that the CSS WG sticks to non-bad policy.

[00:45:06.0000] <heycam>
yeah, just found http://wiki.csswg.org/spec/vendor-prefixes#working-draft-features :\

[00:45:23.0000] <heycam>
"MAY use a prefix specific to the issuing WG or to the specification, e.g. -svg-" really? :)

[00:46:09.0000] <hsivonen>
With Blink, Gecko and, if Pointer Events are any indication, Trident moving on, maybe the CSS/WebKit policy will end up hurting WebKit enough for WebKit to defect from the CSS policy

[00:47:17.0000] <heycam>
maybe

[00:48:56.0000] <zcorpan>
hsivonen: can you reply to the email?

[01:50:45.0000] <hsivonen>
zcorpan: replied

[01:50:55.0000] <zcorpan>
hsivonen: thanks!

[01:59:27.0000] <SimonSapin>
has Microsoft commented on prefixing?

[02:26:54.0000] <hsivonen>
SimonSapin: dunno. I didn't mention Microsoft on the mailing list, because I noticed that Pointer Events has progressed to CR

[02:28:47.0000] <jgraham>
Why does ubuntu randomly shuffle all my windows whenever I plug in an external monitor?

[02:29:09.0000] <jgraham>
And then why are the window management controls buggy?

[02:29:36.0000] <jgraham>
This doesn't seem like stuff that has changed much recently so you wouldn't have thought it would get worse

[07:26:19.0000] <jgraham>
How bad is https://pastebin.mozilla.org/3096559 as a replacement for https://github.com/w3c/web-platform-tests/blob/master/dom/nodes/encoding.php ?

[07:26:37.0000] <jgraham>
Obviously the import is not ideal. Can probably fix that with some magic

[07:27:20.0000] <jgraham>
tobie_ darobin zcorpan annevk ^

[07:28:31.0000] <annevk>
jgraham: what does escape do?

[07:28:47.0000] <jgraham>
Same as htmlspecialcharacters more or less

[07:28:59.0000] <annevk>
seems fine to me

[07:29:04.0000] <tobie_>
same here

[07:29:04.0000] <annevk>
why is the import bad?

[07:29:06.0000] <zcorpan>
yeah

[07:29:59.0000] <jgraham>
Well having to know to import stuff from e.g. cgi seems bad

[07:30:12.0000] <zcorpan>
you only need to escape " right?

[07:30:16.0000] <jgraham>
Could just make a "utils" module that you can import

[07:30:40.0000] <annevk>
jgraham: given that cgi is included by default, seems better than making something new...

[07:30:46.0000] <annevk>
jgraham: but maybe I don't understand the cost

[07:32:54.0000] <darobin>
jgraham: what the others have said

[07:34:49.0000] <zcorpan>
darobin: you're supposed to violently disagree with the change on the basis of the choice of indentation or something

[07:36:41.0000] <gsnedders>
zcorpan: Can you dump t/resources/slice-and-dice.cgi somewhere?

[07:37:05.0000] <zcorpan>
gsnedders: send me an email and i can do it tomorrow

[07:38:27.0000] <gsnedders>
zcorpan: simonp?

[07:38:33.0000] <zcorpan>
yep

[07:38:51.0000] <gsnedders>
(I just relied on LDAP before. :P)

[07:38:57.0000] <darobin>
zcorpan: it's Python man, there is nothing bad I can say about its indentation that hasn't been said many times over already :)

[07:40:17.0000] <zcorpan>
bah

[07:40:23.0000] <darobin>
does anyone recall where the discussion that made elements that contain a hyphen reserved for extensions (as described in Web Components) happen?

[07:40:33.0000] <darobin>
I can't seem to track it down, I guess I'm looking for the wrong thing

[07:41:22.0000] <annevk>
look for a bug

[07:41:23.0000] <darobin>
I'm thinking we could extend that to attributes as well

[07:43:07.0000] <zcorpan>
darobin: why would it make sense for attributes?

[07:43:44.0000] <darobin>
zcorpan: well, people also want to add their own attributes, and the current theory is that data-* is only for specific hacks

[07:44:14.0000] <darobin>
e.g. the epub people could add their own epub-whatever and it would just be valid

[07:44:25.0000] <darobin>
it would save us from data-epub-* and epub:*

[07:44:33.0000] <darobin>
that's a win in my book

[07:44:37.0000] <darobin>
ah!

[07:44:50.0000] <darobin>
the trick was to look for dash instead of hyphen

[07:44:50.0000] <zcorpan>
or they could standardise whatever="" ?

[07:45:06.0000] <darobin>
zcorpan: yeah, I'd like that too

[07:45:07.0000] <annevk>
yeah, epub can extend HTML within their community...

[07:45:18.0000] <annevk>
I don't think epub will succeed long term, but who knows

[07:45:43.0000] <darobin>
annevk: I'd like to 1) bring it onto the web and 2) avoid ever having to grandfather their decisions in HTML

[07:45:58.0000] <annevk>
I think the only thing we need for books on the web is better CSS

[07:46:10.0000] <annevk>
and maybe zip packaging, but definitely not the mess that is epub

[07:46:11.0000] <darobin>
if zip becomes first-class citizen, all of a sudden we have lots of epub content that's just there

[07:46:50.0000] <annevk>
so yeah

[07:46:53.0000] <annevk>
about that

[07:47:10.0000] <annevk>
anyone a suggestion for generalizing "$zip="?

[07:47:22.0000] <darobin>
generalising to?

[07:47:43.0000] <annevk>
a name or identifer we could reuse in the future for other things, may similar needs arise

[07:48:04.0000] <jgraham>
annevk: I think I just mean that utils.escape would be an alias for cgi.escape, or something. So you would have a bunch of useful features all in the same module

[07:48:07.0000] <annevk>
if we're going to fork the basic URL syntax, including data URLs etc. tying it to zip seems ugly

[07:48:48.0000] <annevk>
jgraham: maybe if you really start needing that, seems like premature refactoring at this point

[07:49:01.0000] <jgraham>
annevk: It wasn't going to be the first thing I did :)

[07:49:04.0000] <darobin>
what are the other use cases?

[07:49:20.0000] <annevk>
darobin: other archive formats maybe

[07:49:23.0000] <darobin>
I mean, if this is just generalising to packaging then $pack works

[07:49:32.0000] <darobin>
annevk: yeah, but I was wondering beyond that

[07:50:10.0000] <darobin>
and, well, if it's just for other packaging formats then honestly $zip still works :)

[07:50:17.0000] <jgraham>
Something to do with media where there are lots of things muxed into a single file? That's effectively packaging too, I guess

[07:50:33.0000] <darobin>
yeah

[07:50:46.0000] <annevk>
darobin: I don't know, it's just a bit different from the separators URLs have thus far

[07:50:50.0000] <jgraham>
But it seems weird to use $zip if it's a webm file

[07:51:10.0000] <darobin>
jgraham: I was joking — see XMLHttpRequest for precedent

[07:51:22.0000] <darobin>
I'd paint that shed with $pack

[07:51:52.0000] <annevk>
or maybe $= is unique enough?

[07:52:16.0000] <darobin>
it could be

[07:52:45.0000] <darobin>
= and $ are used in paths a fair bit, but both together I don't recall

[07:52:51.0000] <annevk>
$sub=

[07:53:01.0000] <darobin>
I'm not sure classic corpora would catch that though

[07:53:18.0000] <darobin>
a lot of that stuff is in session URLs and the such

[07:54:00.0000] <annevk>
yeah

[07:54:00.0000] <darobin>
it almost looks like a sub, too, if you see the $ as the propeller and the = as the pointy front

[07:54:13.0000] <annevk>
:)

[07:54:20.0000] <darobin>
that said, breaking people who do horrible session URLs would likely be a service rendered to the Web

[07:55:41.0000] <darobin>
even safer: $␚=

[07:55:45.0000] <jgraham>
Said like someone who has never needed to book airline tickets

[07:56:10.0000] <darobin>
or $⟃=

[07:56:37.0000] <darobin>
jgraham: you mean you wouldn't want to wreck their services and make their lives miserable for a little while?

[07:58:52.0000] <jgraham>
I quite like the idea of $𝌤

[07:59:12.0000] <annevk>
no

[07:59:14.0000] <annevk>
http://wiki.whatwg.org/wiki/Zip#URLs

[08:01:57.0000] <jgraham>
You just hate plane 1

[08:04:27.0000] <darobin>
that's an excellent choice jgraham

[10:11:23.0000] <nimbu>
annevk: you there

[10:11:25.0000] <nimbu>
are you alive

[10:11:32.0000] <nimbu>
annevk: can I use & in a url path

[10:11:41.0000] <nimbu>
e.g. example.com/benson&hedges/

[10:11:47.0000] <nimbu>
or anyone

[10:12:08.0000] <nimbu>
cc beverloo jgraham

[10:12:14.0000] <annevk>
nimbu: yeah

[10:12:31.0000] <nimbu>
annevk: THANKS

[10:12:36.0000] <nimbu>
now to box people in their faces

[10:12:40.0000] <nimbu>
annevk: is there like a reference

[10:12:43.0000] <nimbu>
i can throw

[10:12:49.0000] <nimbu>
my google is failing

[10:13:09.0000] <annevk>
nimbu: path segment: http://url.spec.whatwg.org/#path-segment

[10:13:24.0000] <annevk>
nimbu: from there you go to URL code points, which include "&"

[10:13:57.0000] <nimbu>
annevk: SWEEEEEEEEEEEEEEET THANKS SO MUCH

[10:14:45.0000] <annevk>
nimbu: enjoy 386'ing the interwebs

[10:15:13.0000] <miketaylr>
also drink less caffeine maybe

[10:15:53.0000] <annevk>
or less sugar, would make it less sweet

[10:16:05.0000] <miketaylr>
:)

[10:16:08.0000] <nimbu>
ahahahahha

[10:16:38.0000] <nimbu>
omg annevk nerdiest joak

[10:16:42.0000] <nimbu>
i had to look up xkcd

[10:19:15.0000] <jgraham>
https://github.com/w3c/web-platform-tests/blob/master/old-tests/submission/Microsoft/async/delay.php

[10:19:19.0000] <jsbell>
I should write an HTTP server where resources requests must be made in unary: http://example.com/????????????????

[10:19:44.0000] <nimbu>
i like the idea of making requests exclusively in ?!

[10:19:59.0000] <nimbu>
example.com/?!¡????!!!¡¡¡¡

[10:20:53.0000] <jgraham>
Make it redirect so that you can encode the domain part as well

[10:21:01.0000] <jsbell>
jgraham: going back a few weeks... you'd mentioned test submissions directly via membership in the w3c group (?) on github rather than fork/pull requests; how do I go about getting group membership?

[10:21:24.0000] <jsbell>
Apologies if I'm misremembering

[10:22:50.0000] <jgraham>
jsbell: I don't remember mentioning that

[10:22:54.0000] <jgraham>
I mean it is possible

[10:23:03.0000] <jgraham>
But it isn't a good idea

[10:23:49.0000] <jgraham>
(it is a better idea to create a branch in the W3C repo and then make a PR from that, since it allowd multiple people to collaborate on the PR)

[10:24:09.0000] <jsbell>
Ah, yes, that's the workflow that was mentioned.

[10:24:10.0000] <jgraham>
But bypassing the PR part is bypassing code review which is A Bad Thing

[10:24:48.0000] <jgraham>
So I can add you to the group if you give me your username

[10:25:08.0000] <jgraham>
I suggest that you choose some "unique" prefix for any branch that you create

[10:25:16.0000] <jgraham>
Like "jsbell/"

[10:26:05.0000] <jsbell>
jgraham: go with 'jsbell' as the username (insert rant about "work" vs. "play" identities here)

[10:26:33.0000] <jsbell>
jgraham: noted, and thanks!

[10:26:36.0000] <jgraham>
That's your github username?

[10:26:39.0000] <jsbell>
yep

[10:28:37.0000] <jgraham>
Oh, it looks like I can't do that anymore :(

[10:28:50.0000] <jgraham>
YOu need to ask MikeSmith or darobin or tobie_

[10:29:48.0000] <jsbell>
Thanks for trying and the pointer.

[10:34:03.0000] <tobie_>
jgraham: really?

[10:34:16.0000] <tobie_>
mmm

[10:34:38.0000] <jgraham>
tobie_: As far as I can tell

[10:34:40.0000] <jsbell>
FTR, my slightly more interesting github identity is 'inexorabletash' and that's a whatwg org member on github.

[10:35:10.0000] <tobie_>
so which one should I use?

[10:36:41.0000] <tobie_>
jsbell: ^

[10:36:43.0000] <jsbell>
tobie_: (waffling...) let's go with inexorabletash to keep things simple, until someone spanks me.

[10:38:05.0000] <jgraham>
/me thinks the discipline policy at Google is a bit extreme

[10:39:18.0000] <tobie_>
done

[10:40:15.0000] <jsbell>
tobie_: thanks!

[10:40:25.0000] <tobie_>
:)

[10:41:11.0000] <jsbell>
and confirmed/"publicized"/I have the org badge on the page.

[10:43:02.0000] <zcorpan_>
MikeSmith: is it a good idea to put the -isvalid etc in the filename? i figure the valid status of a test can change over time. isn't it annoying to have tests change names when that happens?

[11:03:42.0000] <zcorpan_>
jgraham: "Closed with unmerged commits " https://github.com/w3c/web-platform-tests/pull/1

[11:04:20.0000] <jgraham>
zcorpan_: Github is annoying

[11:04:53.0000] <zcorpan_>
jgraham: also, any idea why critic doesn't close reviews automatically? :-)

[11:05:07.0000] <jgraham>
I strongly suspect that just means "you rebased and squashed rather than merging a whole pile of fixups directly"

[11:05:37.0000] <jgraham>
zcorpan_: Seriously none. Sometimes it does, I think. But I need to add some logging to see if I'm even getting the messages

[11:06:14.0000] <zcorpan_>
ok

[11:07:26.0000] <zcorpan_>
i'll merge https://critic.hoppipolla.co.uk/r/101 now, let's see if the review closes

[11:08:36.0000] <zcorpan_>
...nope?

[11:13:59.0000] <zcorpan_>
(closed it manually now)

[11:17:39.0000] <zcorpan_>
-_- i clicked 'raise issue' but read it as 'resolve issue'. And now there's an issue without a title so there's no link to click to resolve it

[11:20:50.0000] <jgraham>
zcorpan_: Link?

[11:21:23.0000] <zcorpan_>
dunno, i've fixed it and navigated away

[11:24:49.0000] <jgraham>
OK

[11:25:00.0000] <jgraham>
I thought I had to fix it

[11:25:10.0000] <jgraham>
I think it might be time to go home


2013-09-20
[01:35:32.0000] <zcorpan>
test

[04:49:45.0000] <zcorpan>
SimonSapin: i'll assign you the responsibility for this offsetParent gecko bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=15430#c11 :-)

[05:27:05.0000] <jgraham>
krijnh: krijn: Can you rejoin #testing on the W3C server, please?

[06:21:53.0000] <zcorpan>
does someone care about https://www.w3.org/Bugs/Public/show_bug.cgi?id=23173 ?

[06:27:24.0000] <SimonSapin>
zcorpan: ?

[06:30:32.0000] <annevk>
zcorpan: ID lookup within a subtree should work

[06:30:47.0000] <annevk>
zcorpan: browsers could always resort to the selector slow path

[06:30:51.0000] <annevk>
"slow"

[06:31:57.0000] <zcorpan>
annevk: yeah

[06:32:59.0000] <zcorpan>
SimonSapin: i found a gecko bug in that comment. i care enough to bring it to your attention, but i don't care enough to file the bug myself. :-P

[06:33:32.0000] <zcorpan>
SimonSapin: (i just picked you at random)

[06:59:15.0000] <SimonSapin>
/me sighs

[07:32:08.0000] <darobin>
TabAtkins: have you considered using specref for bikeshed?

[08:38:54.0000] <rniwa>
slightlyoff: yt?

[08:39:06.0000] <rniwa>
arv: ?

[09:16:24.0000] <jgraham>
zcorpan: Do you know the requirements for pywebsockets in web-platform-tests offhand? Which port(s) should it run on?

[09:16:54.0000] <jgraham>
If it has to be the same as the HTTP server, I guess I have a slight problem to solve

[09:36:14.0000] <jgraham>
So, it looks like hopefully not

[09:36:34.0000] <jgraham>
Although

[09:36:46.0000] <jgraham>
I suspect those are the Jetty ones

[09:36:57.0000] <jgraham>
:}

[09:36:58.0000] <jgraham>
|

[09:37:15.0000] <jgraham>
Oh, that was return, not backspace

[09:38:22.0000] <jgraham>
These jetty tests are going to have to die

[09:38:29.0000] <jgraham>
Art won't like me :(

[09:59:06.0000] <TabAtkins>
darobin: I'm planning to add in specref support, yeah.  It's kinda tricky, since specref links are untyped.

[10:05:29.0000] <zcorpan>
jgraham: the port is configurable in a single .js file iirc

[10:05:57.0000] <zcorpan>
at least for the opera tests

[10:15:10.0000] <TabAtkins>
zcorpan, hsivonen: That CSS wiki page is outdated.  The CSSWG adopted better policies in line with Blink and Firefox's current behavior.

[10:46:37.0000] <dglazkov>
good morning, Whatwg!

[10:52:21.0000] <marcosc_>
dglazkov: can Web components interact with the browser's preloader?

[10:53:22.0000] <marcosc_>
dglazkov: for instance, we want to make a <x-picture> thing that wraps img tags. But we want the images to load like they were inlined in the markup.

[11:07:58.0000] <joelcox>
Hey everyone.

[11:09:06.0000] <joelcox>
I'm new at this, so I'm trying to follow http://wiki.whatwg.org/wiki/What_you_can_do as close as possible and wrote up a user-centric description of a problem, namely allowing browsers to bind to multimedia buttons.

[11:09:34.0000] <joelcox>
I wrote it up in a Gist. Any feedback is much appreciated. - https://gist.github.com/joelcox/6641424

[11:16:05.0000] <arv>
rniwa: Do you still have a question for me?

[11:24:51.0000] <rniwa_>
arv: yeah

[11:24:58.0000] <rniwa_>
arv: have you looked into IndieUI spec?

[11:24:59.0000] <rniwa_>
arv: https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html

[11:25:10.0000] <rniwa_>
arv: it defines a whole bunch of things to expose JS-defined UI behaviors

[11:25:11.0000] <arv>
rniwa_: nope... looking now

[11:31:08.0000] <rniwa_>
arv: it looks very similar to command stuff in html5 and editing commands

[11:31:26.0000] <arv>
rniwa_: yeah, that was my first thought too

[11:31:58.0000] <arv>
rniwa_: The only thing that this brings to the table afaict is the predefined list of commands/actions

[11:32:28.0000] <arv>
rniwa_: it is trivial to polyfill which is a good thing

[11:39:59.0000] <arv>
rniwa_: The list of actions is a bit thin

[11:40:15.0000] <rniwa_>
arv: yeah

[11:40:39.0000] <arv>
rniwa_: Just looking at random UI toolkit will give you a large list of common actions

[11:41:06.0000] <arv>
rniwa_: (no place to file bugs but here is one such random list: http://msdn.microsoft.com/en-us/library/System.Windows.Input.ApplicationCommands_properties.aspx)

[11:48:00.0000] <Domenic_>
joelcox: this is a good thing to work on, +1. I think there is already some work in DOM3 events to make those keys exposed with standard key codes though

[11:49:02.0000] <Domenic_>
joelcox: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent?redirectlocale=en-US&redirectslug=DOM%2FKeyboardEvent#Key_names_and_Char_values search for MEDIA_

[11:51:16.0000] <joelcox>
Good to hear Domenic_. I'll add that to the document :)

[11:51:22.0000] <annevk>
joelcox: I recommend asking on www-dom⊙wo

[11:51:41.0000] <annevk>
joelcox: work on UI Events is mostly there

[11:52:31.0000] <rniwa_>
arv: i wonder if we should be discussing it in WebApps instead

[11:52:37.0000] <zewt>
dom3 events key stuff is a mystery to me

[11:52:37.0000] <rniwa_>
arv: it seems like a bunch of stuff in here can get annevk's help

[11:52:44.0000] <rniwa_>
arv: like all the enums :/

[11:53:01.0000] <rniwa_>
annevk: ^

[11:53:01.0000] <zewt>
like, talking about a ton of totally device-specific buttons

[11:53:11.0000] <annevk>
rniwa_: the IndieUI stuff?

[11:53:17.0000] <rniwa_>
annevk: yeah

[11:54:33.0000] <Domenic_>
aren't enums supposed to be lowercase these days?

[11:54:44.0000] <Domenic_>
no idea what you do for multi-word values though (camelCase?)

[11:55:12.0000] <rniwa_>
Domenic_: there shouldn't be any enums.

[11:57:43.0000] <arv>
Domenic_, rniwa_: The question regarding multi word is still valid

[11:57:48.0000] <annevk>
String enumerations are fine, but yeah, convention is lowercase.

[11:58:11.0000] <Domenic_>
(it's *non*-string enums that are evil...)

[11:58:14.0000] <annevk>
With String.prototype.normalize() as notable exception...

[11:58:27.0000] <Domenic_>
meh, I thought Norbert's argument for that was reasonable

[11:58:44.0000] <Domenic_>
they're like standard acronyms from other documents or similar, not words

[11:59:01.0000] <joelcox>
annevk: Thanks for the suggestion, will look into the proper procedures to do that.

[11:59:03.0000] <annevk>
We use "arraybuffer" in XMLHttpRequest

[11:59:19.0000] <zewt>
(err, acronyms are words)

[12:00:07.0000] <annevk>
joelcox: see http://lists.w3.org/Archives/Public/www-dom/ for instructions of subscribing

[12:00:21.0000] <annevk>
joelcox: there's no procedures for posting other than sending email

[12:00:57.0000] <joelcox>
annevk: Ah ok, thanks.

[12:16:55.0000] <rniwa_>
arv, annevk: so palettefocus/toolbarfocus requests for example are trying to solve the problem of

[12:16:55.0000] <rniwa_>
creating a document editor

[12:16:55.0000] <rniwa_>
where we don't currently have a way of focusing on a toolbar/palette button without clearing focus/selection on the main document view

[12:16:59.0000] <rniwa_>
there are a whole bunch of other things this spec tries to address

[12:17:06.0000] <rniwa_>
sicking: hi sicking!

[12:17:32.0000] <annevk>
rniwa_: it seems kinda premature to solve those things without fixing the architecture layer

[12:17:38.0000] <rniwa_>
annevk: yeah

[12:17:48.0000] <rniwa_>
annevk: I think we need to fix the architecture

[12:18:16.0000] <annevk>
rniwa_: but then I said that too when they added ARAI rather than getting to a place where <input> et al were fixed and it seems ARIA happened and the latter is still not done...

[12:18:47.0000] <annevk>
rniwa_: the hard problems are left unsolved and paved over by hacks or some such

[12:18:53.0000] <rniwa>
annevk: web component model might be replacing ARAI to some extent but yeah.

[12:18:56.0000] <zewt>
bandaiding problems seems to have a way of ensuring real fixes never happen

[12:19:09.0000] <rniwa>
annevk: we should fix the problem now before we add this accessibility feature to the Web

[12:19:15.0000] <annevk>
I wish I had more bandwidth

[12:19:30.0000] <rniwa>
annevk: haha, you need to recruit!

[12:59:20.0000] <dglazkov>
marcosc_: we probably should get on the same page terminology-wise :) What's a browser preloader? And what do you mean by "inlined in the markup"?

[13:12:35.0000] <marcosc_>
dglazkov: sorry, back...

[13:13:12.0000] <dglazkov>
marcosc_: np. There's also a twitter convo

[13:13:25.0000] <marcosc_>
dglazkov: I'll take a look

[13:13:36.0000] <dglazkov>
marcosc_: it's all very confusing.

[13:14:06.0000] <marcosc_>
dglazkov: I'll try to find some code examples... it's pretty simple once you see it

[13:15:31.0000] <marcosc_>
dglazkov: take a look at this markup pattern: https://github.com/scottjehl/picturefill#markup-pattern-and-explanation

[13:15:47.0000] <marcosc_>
we basically want to replicate that as a web component

[13:16:21.0000] <marcosc_>
the problem with the markup pattern is that images are not loaded until _after_ DOMContentLoaded

[13:17:19.0000] <marcosc_>
What we want to do is make a <x-picture> element, that would ideally work the same as <img> (the browser loads images as it finds them in markup )

[13:19:41.0000] <dglazkov>
marcosc_: you can do slightly better with custom elements. Basically, you're tied to the createdCallback timing, which will be at the microtask checkpoint. The createdCallback is what will create a shadow tree for <x-picture>

[13:20:24.0000] <marcosc_>
dglazkov: ok, I'll investigate that

[13:21:25.0000] <marcosc_>
/me runs off to have dinner 

[14:04:35.0000] <zcorpan>
i wonder if people would have a different opinion on critic if it didn't have "opera" in the name

[14:11:34.0000] <zcorpan>
hmm. i enabled review.dropAnyReview but the button doesn't show

[14:13:07.0000] <joelcox>
Domenic_: Just send an email to www-dom like you and anne suggested, thanks again.

[14:35:06.0000] <zcorpan>
jgraham: ping https://critic.hoppipolla.co.uk/r/9

[14:38:46.0000] <zcorpan>
web-platform-tests has a sad number of open PRs, and some can't be automatically merged anymore

[14:42:19.0000] <zewt>
nothing discourages me from contributing to something more than sending a patch and nothing happening, heh

[14:54:48.0000] <zcorpan>
yeah :-(

[15:27:27.0000] <zcorpan>
marcosc: you can use <img is="x-picture"> or some such i think

[15:27:42.0000] <marcosc>
zcorpan: thanks for the tip

[15:28:00.0000] <marcosc>
still a Web Components noob

[15:36:01.0000] <zcorpan>
marcosc: so by 'preloader' i thought you meant the speculative scanner. but i guess you don't want the browser to fetch anything, you want to run some JS "asap" when the element is parsed, right?

[15:45:31.0000] <zcorpan>
/me wonders if the web legacy has already poisoned <picture> such that a native impl would break the web

[15:45:44.0000] <zcorpan>
e.g. http://www.vogue.es/

[15:47:58.0000] <zcorpan>
heh, http://24ways.org/ escaping angle brackets is hard, let's go shopping

[15:48:18.0000] <marcosc>
:)

[15:48:41.0000] <marcosc>
heh

[15:48:48.0000] <marcosc>
our <picture>-perfect response

[15:49:09.0000] <marcosc>
zcorpan: you looking at the latest webdevdata?

[15:49:23.0000] <marcosc>
I don't think it's too late... we've been telling people not to use it

[15:49:55.0000] <marcosc>
Anyway, wish I could stay and chat, but I gotta pack :(

[15:50:20.0000] <zcorpan>
webdevdata yeah

[15:50:51.0000] <marcosc>
zcorpan: if you can, can you paste in some of the searches you are doing as examples into the GH repo for that

[15:50:55.0000] <marcosc>
there is an open bug

[15:51:04.0000] <marcosc>
we are collecting examples to create better docs

[15:51:10.0000] <marcosc>
for how to grep the data

[15:51:17.0000] <marcosc>
etc

[15:51:31.0000] <marcosc>
grepping is actauly hard... even if you go shoppin

[15:53:18.0000] <zcorpan>
hf365.com uses <picture><img ...></picture>. cato.org showed up but doesn't seem to use <picture> anymore

[15:53:34.0000] <zcorpan>
i just did grep -rIE "<picture(\s|>)" .

[15:55:15.0000] <zcorpan>
so now i just found one site that would break, that seems OK

[16:00:41.0000] <zcorpan>
well, depending on how it gets defined... not showing fallback if no <source> matches would break hf365.com

[16:43:13.0000] <dreamdust>
Is there a way to find out the history of a given tag in the html spec? For example, *who* is the person who decided that <header> should be added to the spec.

[16:44:38.0000] <dreamdust>
I assume I have to grep archives of the mailing list?

[16:48:07.0000] <TabAtkins>
Asking here often works.  For example, <header> was added by Hixie, along with the other sectioning elements, due to research on common class names using the Google corpus.

[16:51:44.0000] <dreamdust>
Is there any criteria for why a tag is added, or is it pretty much "we talk about it and decide to add tags." Seems like adding tags based on common class names is… arbitrary to put it nicely.

[16:55:57.0000] <TabAtkins>
The research was for common landmark class names.  If a large percentage of the internet uses <div class="header">, that suggests that a <header> element would be useful for cleaning up that code.

[16:56:11.0000] <Philip`>
TabAtkins: It was added because of that, but then it was renamed to <hgroup>, so that doesn't explan the current <header>, as far as I'm awae

[16:56:15.0000] <Philip`>
*aware

[16:56:40.0000] <TabAtkins>
Philip`: Hm? Iirc, <header> has always been <header>.

[16:57:05.0000] <Philip`>
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-April/019538.html - "I've renamed the old <header> to <hgroup>."

[16:57:42.0000] <Philip`>
coincident with http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2009/002212.html - "Introduce a new <header> element."

[16:57:44.0000] <TabAtkins>
Huh, all right.

[16:59:39.0000] <Philip`>
dreamdust: What method would be less arbitrary than doing research into current practices and extending the language to more naturally express those practices?


2013-09-21
[17:01:49.0000] <Philip`>
dreamdust: ("we talk about it and decide to add tags" without any prior research would be much more arbitrary, but hopefully that didn't happen very often)

[17:04:01.0000] <dreamdust>
Well, like what the purpose of tags serve in HTML? Is there any consensus on that? I'm not saying I disagree with the process just trying to understand the reasoning behind it. To me, the fact that a bunch of people add a "article" class to things doesn't mean a tag should be made for it.

[17:08:11.0000] <TabAtkins>
The purpose of tags is to communicate meaning between the page authors and machines reading the page, and to organize the page in a meaningful way so it's easy to edit and maintain.

[17:08:31.0000] <TabAtkins>
And incidentally to provide convenient hooks to hang certain types of styles off of.

[17:08:32.0000] <Philip`>
dreamdust: If I remember correctly (I probably don't), the main thoughts were that a document's elements should semantically describe the document's structure in a way that is meaningful to humans who are writing HTML (and semantics is a good thing and is what HTML has always been about); and that the set of elements should be designed so tools could automatically generate outlines and tables of contents

[17:08:36.0000] <dreamdust>
Like the header tag for example… what's the point? It doesn't enable me to accomplish anything I could accomplish before. There's no rules on what goes inside it, as browsers render everything inside it. There can be multiple header tags… I mean I can't even read the spec and determine how to use it properly.

[17:08:55.0000] <TabAtkins>
dreamdust: If the examples don't help you use it correctly, file bugs please.

[17:09:10.0000] <TabAtkins>
But yes, all the sectioning elements are like you describe.  They're lightly-flavored <div>s.

[17:09:33.0000] <dreamdust>
lightly-flavored!? they seem completely pointless

[17:10:54.0000] <Philip`>
In the end I think it comes down to the personal taste of the people who were defining HTML5 at that time

[17:11:08.0000] <dreamdust>
yeah seriously

[17:11:11.0000] <Philip`>
since there are arguments for many possible directions, and that one was chosen

[17:11:20.0000] <dreamdust>
but not the case with all tags, there is no ambiguity about what a <a> tag is and means and does. Same with something like <li> or <p>. <section>, <header>, <nav> seem so loosely defined I just don't see what we gain from having them.

[17:11:46.0000] <Philip`>
and it wasn't a particularly problematic direction for anyone, so it was never worth changing again

[17:12:52.0000] <Philip`>
and then the more technical features of HTML5 became very popular, so it took off, and the bits that nobody really cares about (like semantic elements) got dragged along with the rest

[17:14:40.0000] <Philip`>
dreamdust: About your original question: I don't think any of the history is documented anywhere, except in the spec's commit log and the WHATWG mailing list and the HTML WG list and the IRC logs

[17:14:58.0000] <Philip`>
(i.e. there's a huge amount of documentation and the problem is filtering it)

[17:20:40.0000] <dreamdust>
Yeah… I'm finding that out now. It's very problematic because there's no way to track the history of a change. Why the header tag is added is essentially lost to time and left for people to deconstruct from searching through hundreds of emails. I suggest moving the spec to github, using a branching model, and having the official spec live there in a master branch. I see it's been put on github but there's no point for anyone to use it because t

[17:21:23.0000] <TabAtkins>
The spec is version-controlled, though not by git.  I'm not sure how switching to git would help this particular issue.

[17:26:03.0000] <Philip`>
I think the fundamental difficulty is that an enormous amount of thought and discussion goes into each change

[17:26:30.0000] <Philip`>
and it would take a large amount of effort to summarise it into an easy-to-read form, so nobody does that

[17:26:31.0000] <dreamdust>
github not so much git… because of the public link between discussion and spec changes. Requests for changes are formalized with pull requests, and discussion is more linked to the actual git changes.

[17:27:19.0000] <TabAtkins>
Spec discussion happens on email and/or bugzilla bugs.  Moving the discussion forum won't make things any easier, and it would disrupt the existing workflow substantially.

[17:27:35.0000] <dreamdust>
fair enough

[17:28:22.0000] <Philip`>
Spec changes should usually be motivated by someone expressing a problem that they would like to be solved, and then people analyse various possible solutions, and might end up with a solution that involves a change to the HTML spec

[17:28:39.0000] <dreamdust>
right… so how would I go about finding what problem the header tag solved?

[17:28:42.0000] <Philip`>
Pull requests seem like the opposite model, since they start with someone proposing a change to the spec

[17:39:43.0000] <a-ja>
iirc, <header> had some XHTML2 baggage

[20:39:06.0000] <Hixie_>
TabAtkins, Philip`: in case dreamdust comes back (or anyone else asks), there's also http://wiki.whatwg.org/wiki/Rationale


2013-09-22
[00:15:25.0000] <Ms2ger>
Just 2000 new mails? Slackers

[04:50:30.0000] <WesleyMcClane_>
there will be an updated HTML-DOM spec or it will be part of the HTML spec?

[04:51:34.0000] <Ms2ger>
What used to be specified in DOM2HTML is now defined in the HTML spec


2013-09-23
[00:20:42.0000] <Ms2ger>
"I have an insane, complex use case, and you'd laugh at me if I told you what it was, but trust me when I say I need an immediate mode drawing API like <canvas> instead of a retained scene graph like SVG."

[00:21:12.0000] <heycam>
lucky for them such a thing exists

[05:12:20.0000] <hsivonen>
annevk: if a document's encoding is the replacement encoding, what should document.characterSet return when "replacement" isn't one of the encoding's labels?

[06:27:13.0000] <jgraham>
Ms2ger: 74s

[06:28:14.0000] <Ms2ger>
?

[06:28:29.0000] <jgraham>
For the review

[06:29:59.0000] <Ms2ger>
Ah

[06:30:05.0000] <Ms2ger>
Next: under 60s :)

[06:30:33.0000] <jgraham>
Well now you have something to beat ;)

[06:30:46.0000] <Ms2ger>
Heh

[06:30:53.0000] <Ms2ger>
/me reruns his importing script

[07:00:10.0000] <zcorpan_>
if one doesn't want to get emails about comments https://github.com/hoppipolla-critic-bot makes, does it work to block that user?

[07:01:10.0000] <jgraham>
Perhaps?

[07:01:22.0000] <jgraham>
In the future it could potentially send more useful comments

[07:01:51.0000] <jgraham>
Like it could be an easy way to do merges directly from critic

[07:02:12.0000] <zcorpan_>
apparently art wants to pretend that critic doesn't exist

[07:02:41.0000] <zcorpan_>
or at least doesn't want to use it and doesn't want to get emails about it

[07:04:11.0000] <jgraham>
Well it's not clear if he is in principle opposed to all mail it sends or just that mail in particular

[07:04:26.0000] <jgraham>
I guess it's hard to tell at the moment since that's the only mail it sends

[07:04:41.0000] <jgraham>
Or, rather, that it causes GH to send

[07:05:29.0000] <annevk>
hsivonen: you return the name of the encoding, so "replacement"

[07:41:58.0000] <Ms2ger>
"See the whole threat on public-fx [1]."

[07:53:34.0000] <zcorpan_>
i wonder if public-fx is a list i should subscribe ot

[07:54:28.0000] <zcorpan_>
the only thread this month i care about is cross-posted to www-style, so i guess no

[08:07:13.0000] <Hixie_>
zcorpan_: i'm subscribed to it, but every few days i just do "select all recipient fx delete expunge", so...

[08:09:36.0000] <annevk>
zcorpan_: you should I think (I'm not)

[08:09:58.0000] <annevk>
zcorpan_: object model for CSS and SVG should be somewhat coordinated and similar

[08:10:07.0000] <zcorpan_>
k

[08:10:58.0000] <annevk>
At some point I thought the latter should be mostly obsoleted by the former... Not sure how true that is these days

[08:11:45.0000] <zcorpan_>
/me *poof*

[08:21:56.0000] <hsivonen>
annevk: but if the label "replacement" appears in, say Content-Type, it's unknown and doesn't map to "replacement"?

[08:22:04.0000] <annevk>
hsivonen: correct

[08:22:28.0000] <hsivonen>
annevk: :-( I wonder if your APIs are prepared to deal with this kind of thing

[08:22:44.0000] <hsivonen>
I'll try to implement this and will report back

[08:22:45.0000] <annevk>
hsivonen: it's kind of an odd exception, would you prefer an explicit label?

[08:23:04.0000] <annevk>
hsivonen: I had the feeling we didn't really want to expose replacement more than required

[08:23:09.0000] <hsivonen>
possibly. I'll have to try how annoying the current state of the spec is

[08:23:40.0000] <annevk>
per spec architecture it makes perfect sense, but I can imagine it might be annoying elsewhere yeah

[08:45:06.0000] <Ms2ger>
A new css-ruby draft? Hear, hear

[08:48:55.0000] <annevk>
is it finally simplified or does it still try to cover all the potential use cases?

[09:25:00.0000] <dglazkov>
good morning, Whatwg!

[09:26:50.0000] <annevk>
This conference is pretty interesting. I didn't know that people put <iframe> inside <iframe> to circumvent people relying on window.onload before initializing a bunch of stuff (in the context of third party widgets).

[09:28:15.0000] <annevk>
Maybe there should be something like "I don't care about body's load event"

[09:28:35.0000] <annevk>
Or people should just generally not use it for larger setups...

[09:50:25.0000] <annevk>
Cookieless requests came up again too...

[10:12:48.0000] <annevk>
hsivonen: why does document.write() not throw for async scripts?

[10:12:59.0000] <annevk>
hsivonen: it's apparently annoying

[10:29:50.0000] <jgraham>
annevk left

[10:30:00.0000] <jgraham>
Seems like an odd thing to be annoyed about

[10:30:52.0000] <jgraham>
But didn't implementations lead here? Also I guess the script probably doesn't know that it's async at the moment

[11:08:57.0000] <zcorpan>
document.write() from createElement()ed scripts didn't throw before async=""

[11:15:58.0000] <Domenic_>
cookieless requests seem great, wouldn't they let you do cors-less cross-domain stuff?

[11:18:28.0000] <TabAtkins>
No, cookies aren't the only source of ambient authority.

[11:19:19.0000] <Domenic_>
:( what else is there

[11:20:07.0000] <TabAtkins>
Being on a given network, for example.

[11:20:21.0000] <Domenic_>
ugggh

[11:20:39.0000] <TabAtkins>
Yeah, the web's design sucks. :/

[11:20:41.0000] <Domenic_>
it's just so silly to have to set up a proxy endpoint on one's server to do any cross-domain requests

[11:24:00.0000] <TabAtkins>
Agreed, but security is hard, and the web screwed it up super-bad early enough that we can only patch it now, not actually fix it.

[11:30:52.0000] <annevk>
Domenic_: opting out of HTTP authentication and something TLS user certificates would pave the way to that

[11:31:41.0000] <annevk>
Domenic_: I think we should have the ability to do those kinds of things same-origin, but requires more work figuring out the right hooks and getting implementations aligned with the new architecture

[11:32:32.0000] <Domenic_>
annevk: +1, building fetch from the ground-up by layering cookies etc. on top of a raw HTTP request seems sensible. But in terms of actual use cases my most prominent is cross-origin.

[11:33:17.0000] <annevk>
You mean tainted cross-origin?

[11:33:32.0000] <Domenic_>
no i mean just letting me see the damn data :P

[11:33:44.0000] <Domenic_>
in the same way i would see it if i set up a server-side proxy and went through that

[11:33:50.0000] <annevk>
You won't get cross-origin requests without CORS.

[11:34:31.0000] <annevk>
Except for tainted, but then you can't see the data (apart from height/width in case of images).

[11:34:32.0000] <Domenic_>
yeah, I guess that's what TabAtkins was explaining to me. Sad times.

[11:34:35.0000] <TabAtkins>
Proxying through your server wipes out all the ambient auth, which is why it's kosher.  It's ugly, but it's not actually a hack - it has the desired security characterics.

[11:35:22.0000] <annevk>
Well, we should never have given the illusion from the start that intranets are protected. If security was thought through, it could've been the same...

[11:35:41.0000] <annevk>
It's IP-based intranet security that's biting us here...

[11:36:02.0000] <TabAtkins>
Yup.

[13:36:42.0000] <hallvors>
'evening, annevk

[13:36:47.0000] <hallvors>
yt?

[13:36:54.0000] <annevk>
hallvors: good afternoon

[13:37:41.0000] <hallvors>
still somewhat confused about those serialize doc/encoding issues

[13:38:12.0000] <hallvors>
but seeing that the spec is sort of undecided too, it's not entirely my fault :)

[13:39:57.0000] <darobin>
heh

[13:40:31.0000] <hallvors>
annevk: any "current" thoughts on this? (If the rest of you would like context it's https://github.com/w3c/web-platform-tests/pull/343#issuecomment-24906702 onwards)

[13:41:22.0000] <annevk>
hallvors: Chrome doesn't support sending documents at all?

[13:41:33.0000] <annevk>
hallvors: do you get [object Document] or some such at least?

[13:41:39.0000] <hallvors>
nope

[13:41:55.0000] <hallvors>
it sends "Content-length: 0" , no content-type, no content

[13:42:01.0000] <annevk>
hallvors: if we can get away with serializing and then encoding to utf-8 bytes that'd be preferred

[13:42:12.0000] <darobin>
hallvors: is that the same for HTML and XML documents?

[13:42:13.0000] <annevk>
hallvors: seems like we can if Chrome doesn't even support stuff

[13:42:24.0000] <hallvors>
OK - that's what my rewritten test currently asserts ;-)

[13:42:46.0000] <darobin>
/me not entirely surprised, people get documents but rarely send them, and then likely as strings

[13:43:12.0000] <hallvors>
We could of course also make the test accept either behaviour as legal (with some real checks that the encoding label matches the on-the-wire bytes)

[13:43:51.0000] <Ms2ger>
/me does not approve of that

[13:44:09.0000] <annevk>
/me utters a Darth Vader noooo in silence

[13:44:27.0000] <hallvors>
(BTW Ms2ger - since you're around - consider the issues you raised about the exceptions tests fixed ;-))

[13:45:04.0000] <Ms2ger>
/me tries to remember

[13:45:09.0000] <Ms2ger>
The one about the ByteString

[13:45:12.0000] <hallvors>
(And I'm glad you don't approve of that although it means more work for Gecko devs if you vote it down :-))

[13:45:18.0000] <Ms2ger>
And what was the other?

[13:45:21.0000] <hallvors>
Some TypeError -

[13:45:32.0000] <hallvors>
tests are apparently slightly out of sync with spec :-/

[13:45:35.0000] <Ms2ger>
Oh, the Blob

[13:45:42.0000] <hallvors>
oh yes, that one too

[13:45:48.0000] <Ms2ger>
No problem, thanks for filing the bugs

[13:45:53.0000] <hallvors>
will fix :)

[13:46:22.0000] <hallvors>
(sort of hoping all the errors are Anne's fault :-p)

[13:46:48.0000] <hallvors>
nah, sorry Anne ;-)

[13:47:10.0000] <Ms2ger>
/me has been dealing with twelve days of backlog :)

[13:48:49.0000] <Ms2ger>
hallvors, and just as a general comment, I find small, focused PRs easier to deal with than "fix all the bugs" ones

[13:49:08.0000] <Ms2ger>
(Not saying that I would be reviewing the smaller ones ;))

[13:49:31.0000] <hallvors>
OK, I might consider that..

[13:52:15.0000] <hallvors>
It's a bit hard to find nice ways to slice those assorted bugs into PRs..

[14:05:23.0000] <annevk>
hallvors: hah, I'm sure they are

[14:05:49.0000] <annevk>
hallvors: I wrote those tests long ago, on the couch in richt's old apartment in Oslo

[14:05:59.0000] <annevk>
hallvors: no doubt things have changed

[14:06:16.0000] <darobin>
that plus remanent substances embedded in the couch

[14:06:25.0000] <hallvors>
/me will forever blame Rich's couch

[14:12:28.0000] <hallvors>
annevk; Ms2ger: http://xhr.spec.whatwg.org/#interface-formdata doesn't say that formdata.append() should throw any exceptions?

[14:12:42.0000] <annevk>
hallvors: IDL-level exceptions?

[14:12:45.0000] <Ms2ger>
Yeah

[14:12:53.0000] <Ms2ger>
You can't convert a string to a Blob

[14:13:00.0000] <hallvors>
OK

[14:13:51.0000] <Hixie_>
sweet kittens, the web makes no sense

[14:14:06.0000] <jgraham>
Woah, you only just realised?

[14:14:39.0000] <hallvors>
It merely reflects humanity. Humans don't make much sense either.

[14:14:43.0000] <jgraham>
/me is worried that Hixie_ has been asleep at the wheel

[14:14:46.0000] <jgraham>
:)

[14:14:57.0000] <jgraham>
hallvors: Now you sound like karl

[14:15:09.0000] <Hixie_>
i'm trying to figure out something about history.back()

[14:15:23.0000] <Ms2ger>
jgraham, if it'd been in the form of a haiku...

[14:15:28.0000] <Hixie_>
this API is on window.history

[14:15:34.0000] <Hixie_>
so you'd think it would affect window

[14:15:36.0000] <Hixie_>
but no!

[14:15:42.0000] <hallvors>
My new goal in life is to out-Karl Karl some day :)

[14:15:47.0000] <Hixie_>
it can affect some random other window, if it feels like it

[14:16:07.0000] <hallvors>
sub-frames that were navigated?

[14:16:13.0000] <Hixie_>
or parent frames

[14:16:17.0000] <Hixie_>
or sibling frames

[14:16:22.0000] <jgraham>
Well yeah, it changes the position in the global session history

[14:16:22.0000] <Hixie_>
or cousin frames

[14:16:30.0000] <Hixie_>
that makes precisely no sense.

[14:16:54.0000] <hallvors>
or third cousin frames. or grandparent frames.

[14:17:12.0000] <jgraham>
The global session history makes no sense?

[14:17:56.0000] <darobin>
the many joys of designing functionality in world where nested framesets are all the rage

[14:17:57.0000] <Hixie_>
i go back to: the web makes no sense.

[14:18:15.0000] <annevk>
Hixie_: many things you can access through the global are not limited to it

[14:18:18.0000] <jgraham>
Well the global session history is no fun to implement at least

[14:18:21.0000] <hallvors>
Hixie_.back()

[14:19:15.0000] <jgraham>
Oh, you did document.open/document.write during load. Pretend the load didn't happen"

[14:19:54.0000] <jgraham>
(iirc)

[14:22:44.0000] <Hixie_>
hmmmm

[14:23:32.0000] <Hixie_>
history.back() provides an interesting difficulty in situations where several browsing contexts with the same top-level browsing context have different event loops

[14:24:25.0000] <annevk>
good point

[14:24:32.0000] <annevk>
also UX vs API

[14:24:56.0000] <annevk>
as in UX innovation is made harder because we expose an API to control the functionality

[14:25:20.0000] <annevk>
although I suppose the back button doesn't have to be implemented in terms of the API (would make the API less useful)

[14:26:01.0000] <Hixie_>
what do you think are the odds that one of the htmlwg editors would fix this bug if i filed it on the htmlwg

[14:26:10.0000] <Ms2ger>
Ahahahahaha

[14:26:12.0000] <Hixie_>
it _should_ be a 5.0 blocker, since it's implemented functionality

[14:26:15.0000] <Ms2ger>
Ahem

[14:26:21.0000] <Hixie_>
right darobin?

[14:26:27.0000] <darobin>
:)

[14:26:44.0000] <darobin>
I dunno, do you just want it fixed or do you want it fixed right?

[14:26:50.0000] <Hixie_>
fixed right

[14:27:06.0000] <darobin>
that said, I don't know of any rule that would make it a 5.0 blocker

[14:27:22.0000] <darobin>
but then again there seems to have been process rules invented just for you

[14:27:31.0000] <Hixie_>
well you couldn't exit CR unless it was interoperably implemented, unless the w3c's ignoring its process again

[14:27:43.0000] <Hixie_>
or using one of its many "oh we don't really mean it" clauses

[14:27:46.0000] <darobin>
which is why I doubt it would make its way into there

[14:28:01.0000] <Ms2ger>
No, no

[14:28:05.0000] <Ms2ger>
Browsers work

[14:28:18.0000] <Ms2ger>
Hence, the spec is correct and interoperably implemented

[14:28:26.0000] <Ms2ger>
Thus we can go to rec

[14:28:28.0000] <darobin>
right! so it's fine :) we have, what's it called? "demonstrated interoperability"

[14:28:30.0000] <Hixie_>
oh right, i forgot, we proved the spec was right

[14:28:42.0000] <darobin>
/me has his process work done by Ms2ger, usually works out well

[14:29:13.0000] <Hixie_>
sigh

[14:29:53.0000] <annevk>
W3C shipping "good enough" makes sense given the patent policy

[14:30:08.0000] <darobin>
well yeah

[14:30:10.0000] <Hixie_>
yeah, we wouldn't want to have the patent protection cover what's actually implemented

[14:30:14.0000] <annevk>
It's kinda useless for all other things though and for "good enough" there's way too much politics

[14:31:03.0000] <darobin>
it's good to have patent protection cover what's reasonably well defined

[14:31:25.0000] <annevk>
Hixie_: it'd be better sure, but with limited time something has got to give

[14:31:30.0000] <Hixie_>
well if anyone has a patent on how history.back() works, the spec won't cover it

[14:31:35.0000] <annevk>
Hixie_: and with infinite time you don't get protection

[14:31:47.0000] <Hixie_>
annevk: if there was limited time, we could have gone to REC five years ago

[14:31:53.0000] <annevk>
Hixie_: right, but you'd get the other features covered

[14:31:58.0000] <Hixie_>
/me long ago proposed going to REC every year

[14:31:59.0000] <annevk>
Hixie_: agreed

[14:32:05.0000] <Hixie_>
so clearly that's not it either

[14:32:06.0000] <Hixie_>
anyway

[14:32:12.0000] <darobin>
Hixie_: if someone has a patent that accurately describes how history.back() works, they deserve the money

[14:32:20.0000] <Hixie_>
anyone got an idea on this history.back() thing?

[14:32:30.0000] <annevk>
Hixie_: smaug____ does

[14:32:34.0000] <annevk>
and jgraham I suppose

[14:32:49.0000] <Hixie_>
given that presto and gecko both just have one event loop...

[14:32:57.0000] <darobin>
/me wants to go to Rec every year, not sure why people hesitate about it

[14:33:01.0000] <smaug____>
yes, didn't jgraham promise to write a spec about session history :)

[14:33:37.0000] <Ms2ger>
Hixie_, it's quite simple, people still want to make it seem like the process is followed

[14:33:48.0000] <Ms2ger>
Hixie_, that may be silly, but that's how it works

[14:33:59.0000] <Hixie_>
w3c sucks, news at 11. about this event loop problem...

[14:34:22.0000] <Hixie_>
do we need some sort of cross-event-loop synchronisation primitive?

[14:34:25.0000] <Hixie_>
that would suck the big one

[14:35:08.0000] <Ms2ger>
Or define a single event loop? :)

[14:35:20.0000] <Hixie_>
that wouldn't be compatible with per-origin process isolation

[14:37:51.0000] <annevk>
Hixie_: I recommend asking abarth

[14:39:51.0000] <annevk>
Hixie_: per http://www.chromium.org/developers/design-documents/oop-iframes they will track history globally

[14:40:09.0000] <annevk>
Hixie_: see "Navigation"

[14:43:28.0000] <Hixie_>
"We will also change the representation of a tab's session history to more closely match the HTML5 spec"

[14:43:31.0000] <Hixie_>
:-o

[14:43:50.0000] <Hixie_>
ok so basically they're planning on having a master event loop

[14:44:00.0000] <Hixie_>
just for navigation

[14:44:03.0000] <Hixie_>
that's interesting

[14:44:06.0000] <Hixie_>
makes sense

[14:45:02.0000] <Hixie_>
bbiab

[15:01:18.0000] <abarth>
Hixie_, annevk: happy to answer questions

[15:01:21.0000] <jamesr__>
any parser folks around? i'm fairly certain that the "spin-the-event-loop" step in http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-incdata isn't actually implemented

[15:01:35.0000] <annevk>
abarth: seems the whitepaper answered them :)

[15:01:40.0000] <annevk>
ta

[15:01:43.0000] <abarth>
great :)

[15:01:45.0000] <jamesr__>
but it seems a bit tricky to test

[15:02:33.0000] <jamesr__>
if i understand correctly, to test this i'd need to insert a </script> into the document with a pending stylesheet and with a current script nesting level of zero

[15:03:24.0000] <annevk>
<link href=test rel=stylesheet><script> ... </script>

[15:03:44.0000] <annevk>
jamesr__: it might be implemented in a different way, e.g. by only pausing once you hit .offsetWidth or some such

[15:04:13.0000] <annevk>
(unless I'm not following this particular requirement at all)

[15:04:18.0000] <jamesr__>
well that example wouldn't be observably different

[15:05:33.0000] <jamesr__>
if you did setTimeout(foo); doc.write("</scr"+"ipt>"); bar(); with a pending stylesheet load, the spec appears to be saying that foo() could execute before bar()

[15:06:49.0000] <jamesr__>
so long as the script was running at nesting level zero

[16:03:25.0000] <Hixie_>
http://news.netcraft.com/archives/2013/09/23/certificate-authorities-struggle-to-comply-with-baseline-requirements.html - the web is indeed a mess.

[16:03:28.0000] <Hixie_>
jamesr__: looking...

[16:04:16.0000] <Hixie_>
jamesr__: it has to be implemented, because if you don't spin the event loop there, the style sheet can never load, since the networking tasks that load the style sheet are also queued on the event loop :-)

[16:06:30.0000] <Hixie_>
jamesr__: it might be that certain task sources are blocked, though (the same way the tokeniser is blocked in that case)

[16:16:44.0000] <gsnedders>
Hixie_: /Something/ needs to replace CAs. Badly.

[16:16:49.0000] <jamesr__>
d'oh, finally made a test case with a server component to delay the end of DOMContentLoaded and it just crashes chrome

[16:17:23.0000] <jamesr__>
Hixie_: what do you mean "the sheet can never load"? won't it load after executing the script?

[16:17:40.0000] <Hixie_>
the script is blocked on the style sheet loading

[16:18:01.0000] <jamesr__>
executing the script, or parsing the </script> ?

[16:19:12.0000] <Hixie_>
you're talking about "An end tag whose tag name is "script"", "if there is a pending parsing-blocking script", script nesting level is zero, step 3, right?

[16:19:54.0000] <Hixie_>
there's a script that is waiting to run, but it's blocked on a style sheet being loaded. the parser blocks, waiting for the style sheet to load; once it's loaded, the parser continues, which executes the script.

[16:20:27.0000] <jamesr__>
right, with you so far

[16:20:40.0000] <Hixie_>
so what's the question?

[16:20:48.0000] <jamesr__>
but that algorithm could be running due to document.write(), correct?

[16:21:21.0000] <Hixie_>
not re-entrantly, or the script nesting level wouldn't be zero, but sure, document.write() could be involved somewhere, i guess

[16:21:34.0000] <Hixie_>
probably would have to be, actually

[16:21:51.0000] <Hixie_>
i don't know how else you get a pending parsing-blocking script

[16:21:54.0000] <jamesr__>
in my test case i'm executing document.write() from a img onload

[16:22:00.0000] <jamesr__>
sorry, onerror

[16:22:04.0000] <jamesr__>
(not that it matters)

[16:22:31.0000] <Hixie_>
you wouldn't be in the parser then

[16:22:33.0000] <Hixie_>
so none of this would apply

[16:22:43.0000] <jamesr__>
what do you mean "you wouldn't be in the parser"?

[16:23:34.0000] <Hixie_>
you wouldn't have a pending parsing-blocking script

[16:23:44.0000] <Hixie_>
(i will have to disappear for 30 minutes or so in about 3 minutes)

[16:24:09.0000] <jamesr__>
hmm, but i have a <link rel=stylesheet ...> pending load and i'm doc.writing() a <script> tag in

[16:24:32.0000] <Hixie_>
to test this iirc you need something like <script>document.write('<link ...><script src=...><\/script>');</script>

[16:24:49.0000] <jamesr__>
ah, but the parser-inserted bit won't be set?

[16:24:53.0000] <Hixie_>
gotta go

[16:24:54.0000] <Hixie_>
bbiab

[16:24:54.0000] <Hixie_>
sorry

[16:24:57.0000] <jamesr__>
np

[16:25:45.0000] <gsnedders>
Can the various event loops in theory run in parallel?

[16:26:03.0000] <jamesr__>
gsnedders: not sure what you mean. tasks have to be run serially

[16:26:20.0000] <gsnedders>
Well, there are three (four?) event loops in the HTML spec.

[16:28:10.0000] <gsnedders>
Oh, I'm mixing up event loops with their task queues. nvm.

[16:28:35.0000] <jamesr__>
there are many task queues but only one event loop AFAIK. you can't run tasks in parallel

[16:28:42.0000] <gsnedders>
Yeah, indeed.

[16:28:46.0000] <jamesr__>
although some are re-entrant or have asynchronous sections that you can run in parallel


2013-09-24
[17:03:22.0000] <Hixie_>
jamesr__: back

[17:03:42.0000] <Hixie_>
jamesr__: you still around?

[17:04:05.0000] <Hixie_>
gsnedders is gone, bummer.

[17:04:40.0000] <Hixie_>
there can be many event loops. they run in parallel. for example, if you have firefox and chrome both running on your machine, you'll have at least two event loops.

[17:04:44.0000] <Hixie_>
also each worker has its own event loop.

[17:04:57.0000] <Hixie_>
multiprocess event loops have one loop per process.

[17:04:58.0000] <Hixie_>
etc

[17:06:14.0000] <Hixie_>
gsnedders: see logs

[17:52:37.0000] <leo_33>
 in your opinion why would a headhunter continue sending you info about a job after a  job interview?

[17:55:00.0000] <jamesr__>
Hixie_: i'm around, but not for super long

[17:55:17.0000] <jamesr__>
Hixie_: i got distracted by finding a 3-month old crash bug in our parser

[17:55:37.0000] <leo_33>
 in your opinion why would a headhunter continue sending you info about a job after a  job interview?

[17:57:17.0000] <jamesr__>
Hixie_: if you had <script>document.write('<link ...><script src=...><\/script>');</script>, wouldn't the nesting level be non-zero when parsing the inner </script>, thus bypassing that section of the algorithm?

[18:20:09.0000] <Hixie_>
jamesr__: hm.

[18:20:33.0000] <Hixie_>
jamesr__: no

[18:21:25.0000] <Hixie_>
jamesr__: it's 1 while the document.write() runs, but the inner script doesn't execute until the outer script has ended, when it's zero again.

[01:01:17.0000] <hallvors>
jgraham: yt? time for a testharness.js question?

[01:08:17.0000] <darobin>
hallvors: you're doing it wrong

[01:08:29.0000] <darobin>
jgraham: hey man! We've got some cookies over here!

[01:08:41.0000] <hallvors>
:)

[01:09:05.0000] <Ms2ger>
What's up?

[01:11:05.0000] <hallvors>
Ms2ger: well, busy responding to you in bug 918764 :)

[01:11:52.0000] <hallvors>
I'm also curious what the best way to use testharness.js's assert_throws() for a TypeError is

[01:12:07.0000] <Ms2ger>
assert_throws(new TypeError(), fn)

[01:12:11.0000] <hallvors>
assert_throws("TypeError", ... doesn't work

[01:12:16.0000] <hallvors>
OK

[01:12:42.0000] <Ms2ger>
It's a bit strange :)

[01:12:45.0000] <hallvors>
I was trying to decide between new TypeError() and passing in {name:'TypeError' ..

[01:13:32.0000] <hallvors>
It's strange mainly because it's somewhat inconsistent with the assert_throws("FooError" style for the DOM exceptions..

[01:14:41.0000] <zcorpan>
Hixie_: http://www.whatwg.org/specs/web-apps/current-work/multipage/fragment-links.js seems broken

[01:14:51.0000] <hallvors>
I would prefer adding more known strings so that us poor test authors don't have to figure out what syntax to use for the error we're after..

[01:15:19.0000] <hallvors>
ah, zcorpan - perhaps I should have bothered you and not James about this ;-)

[01:17:03.0000] <hallvors>
anyway Ms2ger, if you have a moment please reply in bug 918764 - thx :)

[01:17:07.0000] <zcorpan>
hallvors: if you can construct the real thing, do that, if not (DOMException), use a custom object

[01:18:15.0000] <zcorpan>
or a string for DOMException...

[01:18:46.0000] <zcorpan>
not super obvious, i agree

[01:19:46.0000] <zcorpan>
Philip`: do you know anything about why http://www.whatwg.org/specs/web-apps/current-work/multipage/fragment-links.js is broken?

[01:19:58.0000] <Ms2ger>
Don't the docs say all that, though?

[01:20:13.0000] <zcorpan>
yeah

[01:23:31.0000] <Philip`>
zcorpan: It worked when I last looked at it, so someone must have changed something in the past five years

[01:24:04.0000] <zcorpan>
helpful!

[01:24:55.0000] <zcorpan>
xref relies on it in html.py so now i can't generate html-differences

[01:26:05.0000] <Philip`>
zcorpan: The file looks truncated, so I guess either the upload was incomplete or the script aborted halfway through

[01:26:18.0000] <Philip`>
zcorpan: but I don't know where the script is run now, or how to see what errors it might have emitted

[01:26:20.0000] <hsivonen>
I wonder if these seriously bad idea encodings are truly needed for email

[01:26:33.0000] <hsivonen>
UTF-7 and its friends

[01:26:55.0000] <zcorpan>
yeah failed upload seems plausible, i'll wait a bit and see if it fixes itself

[01:28:17.0000] <zcorpan>
hsivonen: maybe first step towards making them not truly needed is to identify clients that send utf-7 by default, and second clients that support sending utf-7

[01:29:10.0000] <zcorpan>
although i can imagine the problem isn't just with clients but with scripts that send email (like newsletters)

[01:31:44.0000] <hsivonen>
encodings are fractally wrong

[01:31:56.0000] <hsivonen>
every time I try to fix a bug, I find another bug that I should fix

[01:32:49.0000] <zcorpan>
http://programmers.stackexchange.com/questions/163930/how-relevant-is-utf-7-when-it-comes-to-parsing-emails

[01:34:43.0000] <hsivonen>
oh programmers.stackexchange is for conceptual questions and StackOverflow for non-conceptual ones?

[01:35:48.0000] <hsivonen>
Developing a browser engine would be easier if it wasn't used for email also.

[01:35:58.0000] <zcorpan>
so hotmail bounces is utf-7 (unless they've changed it), that's something users actually get

[01:36:06.0000] <hsivonen>
sad

[01:39:06.0000] <darobin>
maybe it'd help if we added the list of errors from http://www.ecma-international.org/ecma-262/5.1/#sec-15.11 to testharness?

[01:40:03.0000] <Ms2ger>
gsnedders, merge https://github.com/html5lib/html5lib-tests/pull/4 already :)

[01:41:45.0000] <zcorpan>
Hixie_: is fragment-links.js regenned every commit?

[01:46:19.0000] <Philip`>
zcorpan: It's generated by http://html5.googlecode.com/svn/trunk/spec-splitter/spec-splitter.py which ought to be run every commit

[01:47:53.0000] <zcorpan>
ok

[01:49:23.0000] <zcorpan>
the multipage version is up to date so that part still works

[01:55:21.0000] <hsivonen>
\o/ Thunderbird always sends UTF-8 to the HTML parser, so I can rip out support for mail-only encodings out of the parser

[01:55:46.0000] <Ms2ger>
\o/

[03:05:36.0000] <hsivonen>
annevk: do you happen to already have test cases for the replacement encoding?

[03:08:20.0000] <jgraham>
hallvors: Sorry, missed the question earlier. Did you sort things out?

[03:08:24.0000] <hsivonen>
annevk: can you remind me why the spec doesn't map UTF-7 and HZ to the replacement encoding?

[03:08:44.0000] <jgraham>
We could probably add support for assert_throws("TypeError", function(){})

[03:38:21.0000] <aleray>
hi, I'm having problems with html5lib and lxml.etree. I don't know exactly what happens but I get a "'unicode' object has no attribute 'tag'" AttributeError. I wrote my own serializer to tranform HTML into ConText (LaTex-like language). I have a bunch of database entries that have some fields with HTML in them. It seems to happen when the fragment of HTML I pass in is text only (not enclosed by any tag). Any Idea?

[03:38:28.0000] <aleray>
http://dpaste.com/1394167/

[04:06:58.0000] <aleray>
ok more info: http://dpaste.com/1394200/

[04:07:41.0000] <aleray>
I somehow end up with a tree that contains a unicode object, and not an Element

[04:47:02.0000] <jgraham>
aleray: Do you have a small testcase that demonstrates the problem?

[04:57:40.0000] <aleray>
jgraham, trying to make on

[04:57:42.0000] <aleray>
one

[04:57:46.0000] <aleray>
just a moment

[05:06:27.0000] <aleray>
jgraham, here it is: http://dpaste.com/1394268/

[05:09:09.0000] <aleray>
jgraham, works when I remove the the unicode entities

[05:17:49.0000] <aleray>
jgraham, seems to be caused by lxmletree.py

[05:18:00.0000] <jgraham>
aleray: That seems like a bug in html5lib. Can you file an issue on github?

[05:18:12.0000] <aleray>
jgraham, yes

[05:18:29.0000] <jgraham>
Oh, unless you have time towork out what's wrong and fix it, in which case an issue and a PR would be great ;)

[05:18:33.0000] <aleray>
the FragmentWrapper.isstring method doesn't play nice with unicode

[05:18:58.0000] <aleray>
jgraham, I can try, but I'm always a mess with unicode stuff :)

[05:19:49.0000] <jgraham>
Ah, you could be right

[05:20:18.0000] <jgraham>
the isstring attribute looks quite python 3 ish

[05:20:23.0000] <jgraham>
gsnedders: &

[05:20:31.0000] <jgraham>
s/&/^/

[05:20:49.0000] <aleray>
jgraham, basically: "self.isstring = isinstance(obj, str) or isinstance(obj, bytes)" should be valid for unicode type

[05:22:59.0000] <jgraham>
self.isstring = isinstance(obj, six.string_types)

[05:23:08.0000] <jgraham>
Perhaps

[05:29:26.0000] <aleray>
jgraham, here is the relevant part of the thing: http://dpaste.com/1394290/

[05:31:59.0000] <aleray>
sl I guess it should become "self.isstring = isinstance(obj, str) or isinstance(obj, bytes) or isinstance(obj, six.text_type)"

[06:18:49.0000] <annevk>
hsivonen: no tests, a bunch of encodings are not listed yet because I wanted to see if this was the direction we were heading

[06:20:28.0000] <annevk>
hsivonen: looking for the bug...

[06:21:15.0000] <annevk>
hsivonen: per https://www.w3.org/Bugs/Public/show_bug.cgi?id=21057 you thought utf-7 and utf-32 might be relying on fallback

[06:21:41.0000] <annevk>
hsivonen: I think hz-gb-2312 is still in use

[06:34:49.0000] <aleray>
here we go: https://github.com/html5lib/html5lib-python/issues/115

[06:35:04.0000] <jgraham>
aleray: Thatnks

[06:35:08.0000] <jgraham>
*Thanks

[06:35:58.0000] <aleray>
jgraham, happy to help :) I'm quite in love with html5lib. I didn't wrtie any test I don't know exactly how it should be done

[07:13:32.0000] <Ms2ger>
Hrm, idlharness doesn't seem to like variadic arguments

[07:20:00.0000] <darobin>
Ms2ger: is this from an existing IDL?

[07:20:13.0000] <Ms2ger>
DOMTokenList

[07:21:48.0000] <Ms2ger>
annevk, r? https://critic.hoppipolla.co.uk/r/288

[07:22:55.0000] <annevk>
r+

[07:23:39.0000] <Ms2ger>
Ta

[07:31:41.0000] <jgraham>
gsnedders: I think the point is that in this case lxml gives unicode on py2

[07:32:08.0000] <jgraham>
zcorpan: I think I accidentially fixed the bug that caused reviews to not get closed on critic

[07:32:20.0000] <zcorpan>
jgraham: nice

[07:32:42.0000] <jgraham>
In other news, I now have pywebsockets tests running on localhost :)

[07:33:02.0000] <zcorpan>
jgraham: i guess it won't close the reviews currently open with a closed PR though?

[07:33:02.0000] <jgraham>
Well I mean pywebsockets-based tests for the websockets api

[07:33:12.0000] <jgraham>
zcorpan: No

[08:27:29.0000] <jgraham>
hallvors: So you are working on XMLHttpRequest tests, right? :)

[08:28:03.0000] <Ms2ger>
/me sees outstanding xhr reviews

[08:28:21.0000] <hallvors>
jgraham: yes. A little bit :)

[08:28:33.0000] <hallvors>
Found some issues during a Gecko test run, will fix them

[08:29:03.0000] <jgraham>
hallvors: You don't have some hidden desire to rewrite the PHP in python so that we can run them in automation, do you?

[08:29:32.0000] <hallvors>
Those PHP files are pretty simple, no?

[08:29:51.0000] <hallvors>
should be easy enough

[08:30:03.0000] <hallvors>
(aka "famous last words" I guess :-))

[08:30:27.0000] <jgraham>
I don't know, I just know that they are taking up a lot of my screen :)

[08:30:54.0000] <jgraham>
I haven't really looked

[08:32:08.0000] <hallvors>
well, some of them might be tricky if they try to do corner case stuff. On the other hand, some of those corner cases might be easier to trigger in a less hacky language ;-)

[08:32:45.0000] <hallvors>
although I think supporting PHP in whatever test framework you're aiming for might lower the bar to participation ;-)

[08:33:39.0000] <hallvors>
/me thinks PHP is a great language for beginners because of the excellent docs, and is prepared for being flamed & lynched for saying so

[08:35:39.0000] <jgraham>
/me wonders where these excellent docs are, only found the slightly rubbish built-in ones

[08:35:46.0000] <jgraham>
:p

[08:36:25.0000] <annevk>
if you know how PHP works, it's pretty great for small stuff, otherwise many pitfalls

[08:45:28.0000] <zewt>
probably python's biggest flaw is that its syntax sucks for php-style templating

[09:11:40.0000] <gsnedders>
jgraham: WTF. It shouldn't ever, I believe.

[09:11:47.0000] <gsnedders>
jgraham: Well, will look later.

[09:12:20.0000] <Ms2ger>
/me pokes gsnedders about that PR

[09:13:38.0000] <gsnedders>
Ms2ger: Which?

[09:13:47.0000] <Ms2ger>
https://github.com/html5lib/html5lib-tests/pull/4

[09:28:00.0000] <jgraham>
So, should I consider the possibility of browsers sending multiple headers with the same name?

[09:39:03.0000] <gsnedders>
Ms2ger: Oh, okay. Then sure.

[13:20:12.0000] <gsnedders>
Ms2ger: if you read logs, dealt with that PR

[13:27:01.0000] <gsnedders>
Ms2ger: If you deal with https://github.com/html5lib/html5lib-tests/pull/21 we're even. ;P

[13:39:19.0000] <Hixie_>
oh man

[13:39:27.0000] <Hixie_>
setting up a new event loop is gonna suck

[13:40:00.0000] <Hixie_>
(a per-tab event loop for session history, independent of the event loops of any actual tabs)

[13:40:07.0000] <Hixie_>
(er, of any actual browsing contexts)

[13:45:41.0000] <gsnedders>
Who deals with parser stuff at WebKit nowadays?

[13:58:26.0000] <zcorpan>
heycam|away: "The following extended attribute is applicable to dictionaries: [Constructor]." is that right?

[15:01:52.0000] <Hixie_>
tantek: microformats just honours dir="" transparently, right? there's no special magic?

[15:06:54.0000] <tantek>
Hixie - that's right

[15:07:13.0000] <tantek>
did someone raise an issue about dir?

[15:07:41.0000] <Hixie_>
only tangentially. not an issue on microformats.

[15:44:15.0000] <annevk>
I could also change *|*:fullscreen::backdrop to ::backdrop...

[15:44:37.0000] <annevk>
I don't think you'd be able to observe the difference

[15:44:41.0000] <Hixie_>
too late :-)

[15:44:45.0000] <Hixie_>
well, not too late i guess

[15:44:52.0000] <Hixie_>
but i've taken care of it

[15:44:59.0000] <Hixie_>
for <dialog>

[15:45:17.0000] <Hixie_>
i originally thought it was just defined to cover the background

[15:45:23.0000] <Hixie_>
that's why i hadn't positioned it

[15:45:25.0000] <Hixie_>
but it's fine

[15:46:56.0000] <annevk>
fair enough, no need to touch both specs at this point indeed


2013-09-25
[19:10:32.0000] <bholley>
Hixie_: maybe we should IRC for a bit?

[19:10:51.0000] <bholley>
Hixie_: (though I understand if now isn't a good time)

[20:15:20.0000] <Hixie_>
hopefully i'll catch him tomorrow

[20:34:35.0000] <TabAtkins>
annevk: Why have *|* at all in there?  It doesn't add anything.

[20:35:12.0000] <TabAtkins>
zewt: Yeah, the lack of good templating is the sole reason I still use PHP for most of my personal projects, which are usually just dead-simple CRUD applications.

[20:35:35.0000] <annevk>
TabAtkins: yes it does

[20:35:38.0000] <zewt>
i wrote a thing that pulled off inverted-templates with python once; it worked, but it was pretty unintuivie

[20:35:41.0000] <zewt>
... unintuitive

[20:35:47.0000] <zewt>
(much like the qwerty keyboard layout)

[20:35:50.0000] <TabAtkins>
annevk: What does it do?

[20:36:04.0000] <annevk>
TabAtkins: it selects elements outside the default namespace

[20:36:34.0000] <TabAtkins>
Hm, I thought that an unspecified namespace would do that too.

[20:36:48.0000] <TabAtkins>
Does that mean that "rect" in an HTML document won't find my SVG <rect> elements?

[20:37:16.0000] <annevk>
TabAtkins: the CSS declares a default namespace and therefore I use *|* to get out of that

[20:37:29.0000] <annevk>
TabAtkins: CSS namespaces are not related to the document

[20:37:32.0000] <TabAtkins>
Oh, the UA sheet does.  I see.

[20:37:41.0000] <TabAtkins>
Yeah, nm then.

[20:37:59.0000] <TabAtkins>
Anyway, that means you still need it in the just-a-::backdrop case, too.

[20:40:04.0000] <annevk>
I'm not sure what you mean

[20:40:41.0000] <TabAtkins>
You said: "I could also change *|*:fullscreen::backdrop to ::backdrop..."

[20:40:56.0000] <TabAtkins>
You'd have to change it to *|*::backdrop to maintain that "every namespace" feature.

[20:40:56.0000] <annevk>
Ah right

[20:41:26.0000] <TabAtkins>
anyway, home now. nn

[20:41:38.0000] <annevk>
Since it's only :fullscreen and :dialog that need, it won't be changed for now... Maybe once CSS defines its box model and stacking context better and moves this there...

[20:41:49.0000] <annevk>
TabAtkins: have a good one

[20:44:46.0000] <Hixie_>
do we have a blog.whatwg.org admin (that is, someone who can update the actual software, not just someone who has admin rights on the blog itself) around?

[20:45:31.0000] <Hixie_>
do we even know who that is?

[20:45:32.0000] <annevk>
Hixie_: I think that's Lachy, not sure

[20:45:46.0000] <Hixie_>
yeah, you might be right

[20:46:05.0000] <Hixie_>
anyone know what's up with him?

[20:46:37.0000] <annevk>
Hixie_: and maybe Ben Millard? I remember him doing some work on the markup

[20:47:11.0000] <annevk>
Hixie_: I think he's doing less standards these days and more coding, somewhere in Oslo

[20:48:15.0000] <Hixie_>
well if anyone wants to volunteer to take over blog admin work from lachy, let me know

[20:48:32.0000] <Hixie_>
probably need someone to do the wiki too, since aryeh has been gone for a while

[20:49:09.0000] <Hixie_>
it's not much ongoing work, just the occasional software upgrade so we don't get owned

[20:49:31.0000] <Hixie_>
oh wait, GPHemsley took over the wiki, didn't he

[20:49:48.0000] <Hixie_>
zcorpan: are you doing the forums?

[22:27:49.0000] <TabAtkins>
Oh man, caught the "but preventing people from *choosing* to use DRM is anti-Open Web" in one.

[00:11:53.0000] <zcorpan>
Hixie_: Xdega updated the forums last time. it's not up to date now it seems. i'll ask if he can update it again

[01:20:21.0000] <ondras>
Domenic_: hi, you around?

[02:45:44.0000] <zcorpan>
MikeSmith: yt? csswg hg is timing out

[03:09:31.0000] <MikeSmith>
zcorpan: working on it

[03:10:00.0000] <MikeSmith>
but it seems the systems team may have cut me off from root on that hosta

[03:10:54.0000] <MikeSmith>
the fix for the hg problem is just for the apache server on that host to be restarted

[03:11:26.0000] <MikeSmith>
actually the fix for it is really for the CSS WG to pull its head out of its ass and move everything to github instead

[03:12:59.0000] <Ms2ger>
Ehehehehe

[04:46:44.0000] <GPHemsley>
Hixie_: Yes. Yes, I did. :P

[04:49:31.0000] <GPHemsley>
/me seconds hallvors1's praise for PHP's docs

[04:49:43.0000] <GPHemsley>
/me wishes Python's docs were as good

[04:51:18.0000] <MikeSmith>
zcorpan: csswg hg should be working again

[04:52:50.0000] <zcorpan>
MikeSmith: thanks!

[04:52:58.0000] <MikeSmith>
thanks for the heads-up

[04:55:25.0000] <zcorpan>
MikeSmith: new problem: hg push gives abort: HTTP Error 500: Internal Server Error

[04:55:31.0000] <zcorpan>
should i just try again?

[04:56:38.0000] <zcorpan>
hmm, but my changes seem to have gone through. https://dvcs.w3.org/hg/csswg

[04:57:40.0000] <zcorpan>
so i guess it's fine

[05:03:14.0000] <MikeSmith>
zcorpan: I just now re-restarted apache there. Not sure if it had actually be restarted when the previous problem was fixed. But it should be 100% back to normal now.

[05:03:47.0000] <zcorpan>
ok

[05:14:23.0000] <MikeSmith>
zcorpan: btw about the 00N.isvalid.html and 00N.novalid.html naming conventions, I've figured it was worth trying out as a way to use the filename to easily store the metadata about the core way the test document are distinguished from each other

[05:14:45.0000] <MikeSmith>
and to tell a test runner what to expect when checking the document

[05:15:43.0000] <MikeSmith>
I've also added some documents with 00N.haswarn.html names to indicate they should only generate warnings

[05:16:22.0000] <MikeSmith>
which is another case that's useful to distinguish separately for errors -- at least as far as testing validator.nu goes

[05:16:39.0000] <MikeSmith>
I don't expect that the names are going to change very often

[05:17:24.0000] <MikeSmith>
oh and of course it means the cases can be distinguished without needing to have a manifest

[05:18:24.0000] <MikeSmith>
but anyway I have since implemented support in the validator.nu test runner for checking what specific message the validator is expected to report when it checks the document

[05:18:29.0000] <MikeSmith>
if any

[05:18:51.0000] <MikeSmith>
and that kind of obviates the need for the naming convention a bit

[05:19:58.0000] <MikeSmith>
but I'd still like to keep that naming convention for now, because I think it could be useful to anybody else who might be making another conformance checker and wanting to test it

[05:20:05.0000] <zcorpan>
ok

[05:55:23.0000] <ondras>
Domenic_: you around?

[06:07:42.0000] <jgraham>
annevk: So, there are unclear things in URL

[06:08:11.0000] <annevk>
jgraham: no doubt

[06:08:41.0000] <jgraham>
When you are parsing a URL, in several places it says "terminate this algorithm". But it's not really clear if that means the overall algorithm and, if so, whether anything is returned

[06:08:53.0000] <jgraham>
And if not, what you are supposed to do next

[06:09:31.0000] <jgraham>
Also, it talks about a pointer into input that can't go past the end of input, but then also talks about a nominal EOF character

[06:09:46.0000] <jgraham>
It's not really clear if the EOF concept is needed

[06:11:21.0000] <annevk>
jgraham: the parser doesn't have to return anything when state override is given

[06:12:11.0000] <jgraham>
So it can return Nothing | Error | ParsedURL ?

[06:13:36.0000] <annevk>
jgraham: yeah, it either attempts to modify a URL or attempts to construct a new one

[06:14:18.0000] <jgraham>
So I think it would be easier to follow if that was explicit

[06:14:45.0000] <annevk>
The EOF-handling might be buggy...

[06:16:06.0000] <jgraham>
So I think at the moment, if the pointer reaches the end of the input you break out of the loop.

[06:16:32.0000] <jgraham>
So the EOF case can only happen if the pointer is incremented somewhere other than at the end of the loop

[06:17:25.0000] <annevk>
Yeah that seems wrong...

[06:18:01.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23351 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23352

[06:18:31.0000] <jgraham>
Thanks

[06:21:44.0000] <jgraham>
/me ended up in a testharness.js-in-servo rabbithole that bottomed out with implementing URL

[06:41:09.0000] <MikeSmith>
jgraham: should I use the "Prepare Rebase" button in Critic, or should I just manually rebase onto master from my fork

[06:41:23.0000] <MikeSmith>
or how do I rebase onto master in Critic?

[06:41:49.0000] <jgraham>
MikeSmith: "Prepare Rebase" doesn't really work for tracked branches and should probably be hidden

[06:42:19.0000] <jgraham>
MikeSmith: You want to do the rebase and then use "Rebase Review"

[06:42:30.0000] <jgraham>
(near the top)

[06:43:05.0000] <jgraham>
MikeSmith: Which review, so I can help you out if there's a problem?

[06:43:13.0000] <MikeSmith>
jgraham: https://critic.hoppipolla.co.uk/r/310

[06:43:53.0000] <jgraham>
OK, so rebase onto master locally

[06:44:01.0000] <jgraham>
Push the rebase to github

[06:44:14.0000] <jgraham>
and click "rebase review" in critic

[06:44:27.0000] <jgraham>
One day I will get around to automating this

[06:44:45.0000] <jgraham>
Since I *think* GH sends enough information to work out that a rebase occurred

[07:00:33.0000] <annevk>
jgraham: yay for implementing URL

[07:01:09.0000] <Domenic_>
ondras: what's up

[07:05:25.0000] <jgraham>
annevk: Well let's see hoe far I get

[07:06:29.0000] <jgraham>
I need to read the borrowed pointer tutorial so that I don't always end up with the compiler saying "error: cannot move out of dereference of & pointer"

[07:10:14.0000] <Ms2ger>
jgraham, heh, that's a nice rabbithole

[07:14:10.0000] <MikeSmith>
jgraham: so does https://critic.hoppipolla.co.uk/r/310 look OK now for me to do Rebase Review?

[07:14:20.0000] <MikeSmith>
what does Update Now do?

[07:17:29.0000] <jgraham>
Update Now just tries to pull the latest code

[07:17:59.0000] <jgraham>
So yeah, just try Rebase Review

[07:20:51.0000] <MikeSmith>
ok done

[07:21:17.0000] <MikeSmith>
So I can do Close Review? and will that actually push the change?

[07:21:58.0000] <Ms2ger>
MikeSmith, no

[07:22:06.0000] <Ms2ger>
MikeSmith, you manually merge, then close

[07:22:20.0000] <MikeSmith>
ah OK

[07:22:23.0000] <jgraham>
Closing should happen automatically if you merge

[07:22:45.0000] <jgraham>
But I agree we need a "Merge PR" button on critic

[07:23:07.0000] <Ms2ger>
jgraham, should as in "is expected to" or as in "feature request"?

[07:23:32.0000] <MikeSmith>
hmm I got an e-mail message saying "The automatic update of the branch... failed and has been disabled. Manual intervention is required to resume the automatic updating."

[07:23:45.0000] <MikeSmith>
so I musta muffed up something

[07:24:05.0000] <MikeSmith>
"Rejecting non-fast-forward update of review branch."

[07:24:23.0000] <jgraham>
MikeSmith: In this case I wouldn't worry much about it

[07:24:30.0000] <jgraham>
Since you are about to merge anyway

[07:25:09.0000] <MikeSmith>
ok

[07:25:54.0000] <jgraham>
Ms2ger: "should" as in "is expected to" in this case

[07:25:59.0000] <jgraham>
I fixed it yesterday, I think

[07:26:02.0000] <Ms2ger>
Ah

[07:26:14.0000] <Ms2ger>
Review one of my patches so I can test? :)

[07:26:40.0000] <jgraham>
Heh

[07:26:52.0000] <jgraham>
Well MikeSmith's review got closed

[07:27:00.0000] <jgraham>
(also the rebase worked for me)

[07:27:22.0000] <MikeSmith>
I just closed it manually

[07:27:30.0000] <jgraham>
Oh

[07:27:35.0000] <jgraham>
Well that's no fun

[07:27:38.0000] <MikeSmith>
heh

[07:28:06.0000] <MikeSmith>
should I have kept it open for some reason?

[07:28:46.0000] <jgraham>
MikeSmith: No, but it should close itself

[07:28:51.0000] <jgraham>
Ms2ger: From the logs

[07:28:53.0000] <jgraham>
[Tue Sep 24 16:17:59 2013] [error] Review <dbutils.review.Review object at 0xa8a565ec>, user User(2, 'Ms2ger', 'Ms2ger⊙gc', 'Ms2ger')

[07:28:56.0000] <jgraham>
[Tue Sep 24 16:17:59 2013] [error] Review accepted, closing

[07:28:58.0000] <jgraham>
[Tue Sep 24 16:17:59 2013] [error] Disabling tracking

[07:29:05.0000] <jgraham>
(ignore the [error] part)

[07:29:23.0000] <Ms2ger>
[err... Ah

[07:29:38.0000] <jgraham>
So it looks like it worked for one of your reviews at least

[07:35:42.0000] <Ms2ger>
/me wonders if anyone is fixing comments on https://critic.hoppipolla.co.uk/r/74

[07:47:51.0000] <gsnedders>
Ms2ger: Did you see what I said in logs to you?

[07:48:45.0000] <Ms2ger>
Yeah, I'll look at that docs thing

[07:49:32.0000] <gsnedders>
It is like literally the same as the wiki page. :P

[09:15:16.0000] <ondras>
Domenic_: so, I am here now. You too? :-)

[09:34:39.0000] <Ms2ger>
/me finds "SUCCESS: did not release a single REC or PR between '98 and '08"

[09:40:07.0000] <jgraham>
CSS?

[09:40:18.0000] <Ms2ger>
Yep

[09:45:52.0000] <Domenic_>
ondras: well, now i am

[09:46:49.0000] <ondras>
Domenic_: cool. first of all, thanks for your nice talk at jsconf.eu!

[09:46:58.0000] <Domenic_>
:)

[09:47:30.0000] <ondras>
Domenic_: second, I wanted to ask another question about Promises - specifically, about the value Promise is resolved with

[09:47:57.0000] <ondras>
Domenic_: is there some reason Promises are designed with only *one* fulfillment/rejection value? When compared to a callback function that can typically accept multiple arguments...

[09:48:12.0000] <ondras>
(which is, of course, domain-specific)

[09:48:20.0000] <Domenic_>
ondras: because they parallel synchronous functions, which can only return one return value or throw one exception.

[09:48:30.0000] <ondras>
yeah, I thought so.

[09:48:35.0000] <Domenic_>
this allows powerful things like task.js http://taskjs.org/

[09:49:20.0000] <ondras>
well, I am in a process of rewriting a callback-based code into a promise-based impl of XHR

[09:49:28.0000] <ondras>
not sure what the fullfillment value shall be

[09:49:43.0000] <ondras>
originally, the signature was callback(data, status, headers) or so

[09:49:57.0000] <ondras>
I guess the common approach is to wrap it into an object, right?

[09:50:07.0000] <ondras>
because non-200 http status shall not imply promise rejection?

[09:50:22.0000] <ondras>
*fulfillment, probably. please excuse my poor english.

[09:52:19.0000] <Domenic_>
yeah, object seems reasonable. it depends on the API IMO whether non-2xx/3xx status implies rejection

[09:52:58.0000] <Domenic_>
just think how you would write the function if you were in a language where I/O was normally synchronous :)

[09:57:54.0000] <ondras>
Domenic_: okay, thanks

[11:09:19.0000] <joelcox>
I wrote a use case for allowing HTML documents to bind to multimedia buttons a week ago. Annevk recommended me to send to www-dom⊙wo, but I've yet to see any response.

[11:09:42.0000] <joelcox>
Are there other ways I should pursue to get more eyeballs on this, or assume people are not interested?

[11:10:02.0000] <Ms2ger>
Patience :)

[11:10:54.0000] <Domenic_>
the problem is getting implementers interested...

[11:11:53.0000] <joelcox>
Ms2ger: thanks, I'm just curious about the w3 way of doing things, WHATWG has a nice set by step process

[11:12:46.0000] <Domenic_>
Oh, I don't think the w3.org means W3C... it's just where the mailing list is hosted.

[11:13:05.0000] <Ms2ger>
Well, multimedia buttons sounds like D3E

[11:13:10.0000] <joelcox>
Domenic_: oh, my bad..

[11:13:22.0000] <joelcox>
Ms2ger: that's how I tagged it in the subject :)

[11:13:55.0000] <joelcox>
Ms2ger: if that's an abbreviation for Dom Level 3 events

[11:14:09.0000] <Ms2ger>
yep

[11:14:58.0000] <Domenic_>
most of the people doing actual work are in whatwg, but they just use the w3c mailing lists because they don't want to host their own mail servers...

[11:15:37.0000] <joelcox>
thanks for the clarification Domenic_

[11:19:47.0000] <Domenic_>
fwiw i think your email lays out a great missing feature of the web and agree it should be addressed... the problem is now finding more people with real power, i.e. implementers or maybe certain spec writers, that also care.

[11:21:30.0000] <joelcox>
Domenic_: Cool, I guess I'll start knocking on some doors

[11:28:34.0000] <joelcox>
Hmm, maybe I should look into how FirefoxOS handles this

[11:30:45.0000] <Hixie_>
Domenic_: if we need mailing lists, we can add some easily enough, but generally i'd recommend we stick to just whatwg⊙wo

[11:30:55.0000] <Hixie_>
the way the w3c has a zillion lists causes nothing but troubles

[11:31:07.0000] <Hixie_>
bholley: here now

[11:48:32.0000] <joelcox>
Hixie_: I scrolled through their list of mailing lists the other day, trying to find www-dom. Never doing that again :)

[12:20:40.0000] <Hixie_>
joelcox: you are aware of "find in page", right? :-)

[12:22:24.0000] <joelcox>
Hixie_: of course, I was just curious about the lists they had and how long the list of lists was

[12:22:28.0000] <Hixie_>
hehe

[12:22:32.0000] <joelcox>
spoiler alert: long

[12:22:33.0000] <Hixie_>
most of those lists are dead

[12:22:39.0000] <Hixie_>
but there's no real way to know

[12:22:47.0000] <Hixie_>
also, there's three lists

[12:23:00.0000] <Hixie_>
that's just one of them

[12:23:20.0000] <joelcox>
yeah, and some are prefixed with public-, some are not

[12:23:58.0000] <Hixie_>
at some point, for reasons i don't understand, they changed from "www-" and "w3c-" and "w3t-" prefixes to "public-", "member-", and "team-" prefixes.

[12:23:59.0000] <joelcox>
(btw, thanks for your work on the web!)

[12:24:20.0000] <joelcox>
Didn't they write a spec for that?

[12:24:25.0000] <joelcox>
Sorry, couldn't resist :)

[12:28:00.0000] <Hixie_>
oh, bummer.

[12:28:07.0000] <Hixie_>
the following statement is now a lie: "Since all these browsing contexts by definition share an event loop, there is always a well-defined sequential order in which their session histories had their entries added."

[12:28:23.0000] <Ms2ger>
Eh, well-defined

[12:29:37.0000] <Hixie_>
they don't share an event loop.

[12:31:21.0000] <Hixie_>
i wonder how we fix this

[12:31:40.0000] <Hixie_>
i guess we post a message to a master event loop

[12:34:02.0000] <Hixie_>
abarth: help

[12:35:23.0000] <Hixie_>
abarth: window.history.length in a multi-process world

[12:35:23.0000] <Hixie_>
abarth: do we just return our best guess?

[13:50:31.0000] <bholley>
Hixie_: I've got an hour before my flight boards if you want to talk

[13:50:39.0000] <Hixie_>
sure

[13:51:03.0000] <bholley>
\o/

[13:51:17.0000] <bholley>
Hixie_: so, let's start with prototypes

[13:51:54.0000] <bholley>
Hixie_: everyone agrees that each origin should get its own view of xowin.location

[13:51:58.0000] <bholley>
Hixie_: so that part's settled

[13:52:12.0000] <Hixie_>
"view"?

[13:52:23.0000] <bholley>
Hixie_: I'm just trying to be general

[13:52:26.0000] <Hixie_>
k

[13:52:30.0000] <bholley>
Hixie_: in webkit, you get a separate object

[13:52:34.0000] <bholley>
Hixie_: in Gecko, you get an Xray wrapper

[13:52:41.0000] <bholley>
Hixie_: but it's indistinguishable from script

[13:53:02.0000] <bholley>
Hixie_: you and I both agree that a single origin should see a consistent value for Object.getPrototype(xowin.location), even if scripts from two same-origin globals are inspecting the same location

[13:53:22.0000] <bholley>
Hixie_: the above rules out (2)

[13:53:44.0000] <bholley>
Hixie_: and IIUC neither of us wants it to depend on whichever script touches the object first

[13:53:56.0000] <bholley>
Hixie_: which rules out (1)

[13:54:00.0000] <Hixie_>
yeah that wouldn't make sense at all

[13:54:11.0000] <bholley>
Hixie_: right. So we're left with (3) and (4)

[13:54:25.0000] <bholley>
Hixie_: (3) being a unique prototype to go along with the unique location object

[13:54:35.0000] <bholley>
Hixie_: (4) being null or undefined or throw or somesuch

[13:55:28.0000] <bholley>
Hixie_: (3) is roughly what Gecko does, (4) is what everyone else does

[13:55:42.0000] <Hixie_>
4 would be fine by me

[13:55:52.0000] <Hixie_>
i think if we don't do 4 then we want something like:

[13:56:14.0000] <Hixie_>
(5) each origin-Location pair gets a unique prototype object for that Location object

[13:56:31.0000] <Hixie_>
just like each origin-Location pair gets a unique Location object for that Location object, essentially

[13:56:38.0000] <bholley>
Hixie_: isn't that (3)?

[13:57:02.0000] <Hixie_>
if it is, then that sounds fine to me too. your description of (3) confused me a bit.

[13:57:26.0000] <Hixie_>
(5) is what i think the spec says today, though apparently not clearly enough

[13:57:45.0000] <bholley>
Hixie_: ok, that's fine with me. The only issue is whether the prototype does security checks, and what that all looks like

[13:57:57.0000] <Hixie_>
what security checks would it do?

[13:58:24.0000] <bholley>
Hixie_: any range of things. In Gecko today, for example, the prototype is an opaque object that throws if you try to do anything to it

[13:58:31.0000] <bholley>
Hixie_: though I consider that a bug

[13:58:50.0000] <Hixie_>
seems to me like it should just be a regular prototype object as defined in WebIDL?

[13:59:25.0000] <bholley>
Hixie_: that's the direction I'd like to move (or rather, making our Xray Wrappers behave that way)

[13:59:36.0000] <bholley>
Hixie_: what about polyfill methods on the prototype?

[13:59:46.0000] <bholley>
Hixie_: should those have any effect?

[14:00:01.0000] <bholley>
Hixie_: I'm assuming so, just checking

[14:00:41.0000] <Hixie_>
cross-origin? you can't add any, and you don't see the original origin's.

[14:01:23.0000] <bholley>
Hixie_: so the Location object isn't a totally normal WebIDL prototype then

[14:01:33.0000] <bholley>
Hixie_: er, the prototype of xo location objects

[14:01:59.0000] <bholley>
Hixie_: because you're suggesting that we perform some sort of security check when I try to monkeypatch Object.getPrototypeOf(xowin.location)

[14:02:01.0000] <Hixie_>
true. that's what the part of the spec says currently says "the user agent must act as if any changes to that Location object's properties, getters, setters, etc, were not present, and as if all the properties of that Location object had their [[Enumerable]] attribute set to false" is trying to say

[14:02:27.0000] <Hixie_>
i think that was added for bz

[14:03:00.0000] <Hixie_>
personally i like being able to monkey-patch them, if it's only visible same-origin

[14:03:02.0000] <Hixie_>
(then again, personally i think we shouldn't expose this cross-origin at all, but that ship has sailed.)

[14:03:44.0000] <bholley>
Hixie_: monkey-patching them introduces a fair amount of implementation complexity. I'm open to it because it's a feature I want in our platform anyway, but we should tread carefully here

[14:04:19.0000] <Hixie_>
at the point where you have origin-unique prototypes, isn't it easier to do monkey-patching than not?

[14:04:55.0000] <Hixie_>
(the other thing to consider is what happens when your effective origin changes but you already have a reference to the cross-origin Location object.)

[14:05:17.0000] <bholley>
Hixie_: not in Gecko, no. Because the our origin-unique prototypes are actually XrayWrappers. Currently those XrayWrappers forward directly to the underlying DOM object, so we'd need some sort of mechanism to say "check the Xray prototype chain"

[14:05:59.0000] <Hixie_>
right, but that's because they're not "real" prototypes

[14:06:24.0000] <bholley>
Hixie_: sure. And they never will be

[14:06:27.0000] <Hixie_>
oh

[14:06:29.0000] <Hixie_>
why?

[14:06:40.0000] <Hixie_>
if that's what we're trying to fake, why not just do it?

[14:06:52.0000] <bholley>
Hixie_: because it would require re-designing our engine to do what webkit does

[14:07:17.0000] <Hixie_>
you'd rather they redesigned their engine to do what you do? :-)

[14:07:31.0000] <bholley>
Hixie_: no. I'm saying that we should spec something that we can both implement easily

[14:07:49.0000] <bholley>
Hixie_: which is why I want the spec to be implementable with either XrayWrappers or Webkit-style separate worlds

[14:08:31.0000] <bholley>
Hixie_: I'm just saying that's why we're not going to "just do it"

[14:09:08.0000] <Hixie_>
ah, ok, if the additional constraint is "implementable with either XrayWrappers or Webkit-style separate worlds", then what would be best for authors kinda goes out of the window

[14:09:17.0000] <Hixie_>
what is implementable by both?

[14:10:55.0000] <bholley>
Hixie_: I mean, authors are a consideration too. But it doesn't serve authors to spec something Gecko-like that webkit won't implement and vice-versa

[14:11:11.0000] <bholley>
Hixie_: especially when it comes to edge cases like this that nobody (currently) relies on anyway

[14:11:12.0000] <Hixie_>
sure

[14:11:28.0000] <Hixie_>
i just wasn't considering that constraint before

[14:12:03.0000] <Hixie_>
i don't know what options we have, with that constraint (i don't mean i don't think we have any, i mean literally, i don't know what they are)

[14:12:26.0000] <bholley>
Hixie_: so, in terms of prototypes, we could implement either (3) or (4)

[14:12:39.0000] <bholley>
Hixie_: so the first step is to check with abarth and see if he's willing to do something other than (4)

[14:12:55.0000] <bholley>
Hixie_: if we decide to do something along the lines of (3)

[14:12:56.0000] <Hixie_>
where (3) is (5) with teh additional restriction that you can't touch it, right?

[14:13:08.0000] <Hixie_>
as in, can't mutate it. unless you're the "original" owner

[14:13:18.0000] <bholley>
Hixie_: no. I'm considering (3) and (5) the same at this point

[14:13:24.0000] <Hixie_>
the one whose origin matches the document for which Location was created

[14:13:28.0000] <bholley>
Hixie_: _if_ we go that option, then we need to figure out the details

[14:13:47.0000] <bholley>
Hixie_: the details including "whether you can monkeypatch"

[14:14:10.0000] <bholley>
Hixie_: what works best for that depends largely on how each implementation implements its security checks on |location|

[14:14:56.0000] <Hixie_>
let's assume we pick 3, for the sake of this conversation: you'd rather we didn't allow the object or its prototype(s) to be mutatable at all by origins that aren't the origin of the Document for which the Location exists, right?

[14:15:33.0000] <bholley>
Hixie_: correct

[14:15:41.0000] <bholley>
Hixie_: but I'm open to doing it differently

[14:15:55.0000] <bholley>
Hixie_: just note that it adds complexity, and there might be snakes in the grass that make it harder than I'm predicting

[14:16:28.0000] <Hixie_>
the less complexity we add, the happier i am

[14:16:46.0000] <Hixie_>
so, as far as i can tell, the spec right now describes exactly what we're saying here. just not very well.

[14:17:01.0000] <bholley>
Hixie_: ok, great

[14:17:26.0000] <bholley>
Hixie_: so if that's settled, we can get back to the original issue of security checks on location. Are you ready to discuss that?

[14:17:39.0000] <Hixie_>
as ready as i'll ever be

[14:18:27.0000] <bholley>
Hixie_: ok, so

[14:19:44.0000] <bholley>
Hixie_: my reasoning was in comment 34 and comment 36, until comment 37 took us on the prototype chain digression

[14:20:30.0000] <bholley>
Hixie_: I can resummarize here if you want - not sure if you prefer depth or brevity

[14:21:42.0000] <Hixie_>
bholley: i'm agnostic on depth vs brevity, it's just an area i find incredibly hard to wrap my head around.

[14:21:51.0000] <Hixie_>
bholley: (so, sorry if i'm being so slow in general with this)

[14:22:15.0000] <bholley>
Hixie_: don't worry about it - I spend all day on this, and you have to deal with the whole web :-)

[14:23:00.0000] <Hixie_>
ok, just reread 34 and 36

[14:23:03.0000] <bholley>
Hixie_: so, we've got 2 origins of interest (bc origin and doc origin), and 2 places security checks can be performed (ES-level property access, and method invocation)

[14:23:16.0000] <Hixie_>
my response now, as then, was 35 and 37. ;-)

[14:23:22.0000] <bholley>
Hixie_: lol

[14:23:59.0000] <Hixie_>
we have at least 2 origins of interest, maybe more

[14:24:12.0000] <Hixie_>
we have several places security checks can be performed, i agree those are two of them

[14:26:53.0000] <Hixie_>
(on a side note, if anyone has a recent IE, can you tell me what it does with http://www.hixie.ch/tests/adhoc/dom/level0/history/cross-origin/001.html ? thanks)

[14:27:33.0000] <Hixie_>
bholley: (i have to bail in about 15 minutes)

[14:27:41.0000] <bholley>
Hixie_: great, me too

[14:27:52.0000] <bholley>
Hixie_: so, do we agree about the method-call checks against bc origin?

[14:28:03.0000] <bholley>
(that they are necessary)

[14:29:26.0000] <Hixie_>
hmm

[14:30:42.0000] <Hixie_>
yes, because we don't want to be able to use our location object's methods on thir location object and thus bypass the property get check

[14:30:48.0000] <Hixie_>
(that's bug 22346)

[14:31:35.0000] <Hixie_>
(except for location.replace(), which we always want to allow)

[14:31:38.0000] <bholley>
Hixie_: right

[14:31:58.0000] <Hixie_>
(well, except in the additional case we want to disallow, bullet 4 in comment 32)

[14:32:38.0000] <bholley>
Hixie_: ok, great

[14:32:48.0000] <Hixie_>
(the fact that this discussion involves terms like "the Location object's associated Document's browsing context's active document's effective script origin" is not helping my sanity score)

[14:33:04.0000] <bholley>
Hixie_: hey, you designed this stuff :-)

[14:33:13.0000] <Hixie_>
"designed"

[14:33:34.0000] <bholley>
Hixie_: so. I argue that we need an additional mechanism to prevent multiple third-party origins from seeing each others expandos on a given location object

[14:33:35.0000] <Hixie_>
(this job has far more in common with my physics background than it has any right to have)

[14:34:03.0000] <Hixie_>
bholley: right, but if we just disallow "expandos", that is, setting properties, that's a non-issue, right?

[14:34:12.0000] <Hixie_>
setting properties cross-origin

[14:34:15.0000] <bholley>
Hixie_: but we can't disallow expandos. The web depends on it

[14:34:16.0000] <ebollens>
(but physics teaches entropy only increases)

[14:34:45.0000] <bholley>
Hixie_: the web depends on script being able to set expandos on the Location object associated with its Document

[14:34:45.0000] <Hixie_>
bholley: it doesn't depend on it for cross-origin Location object access, does it?

[14:34:52.0000] <Hixie_>
sure, on your own is fine

[14:34:54.0000] <bholley>
Hixie_: it depends how we define "cross-origin"

[14:34:58.0000] <bholley>
Hixie_: that's the whole issue here

[14:35:05.0000] <Hixie_>
(by "expando" you just mean a non-IDL-defined property, right?)

[14:35:08.0000] <bholley>
Hixie_: yes

[14:35:11.0000] <bholley>
Hixie_: sorry for the Geckoism

[14:35:24.0000] <Hixie_>
i think it's actually an IEism originally :-)

[14:35:28.0000] <Hixie_>
just making sure

[14:35:55.0000] <bholley>
Hixie_: so, I  totally agree with what you're saying, assuming "cross-origin" in this case is defined in terms of the Document origin, not the BC origin

[14:36:04.0000] <bholley>
Hixie_: which is what I'm advocating for in this bug

[14:36:13.0000] <Hixie_>
browsing contexts don't have origins

[14:36:26.0000] <bholley>
Hixie_: I know. But I'm using the shorthand I proposed

[14:36:49.0000] <bholley>
Hixie_: BC origin = "the origin associated with the document whose window is the active window in the browsing context"

[14:36:54.0000] <Hixie_>
by "cross-origin" i mean that a script whose effective origin is different than the Location object's associated Document's effective script origin

[14:37:04.0000] <bholley>
Hixie_: great

[14:37:10.0000] <bholley>
Hixie_: that's how I think of it too

[14:37:21.0000] <bholley>
Hixie_: which is what I'm pushing for here

[14:37:26.0000] <Hixie_>
wait. i don't think the origin of the active document of the browsing context of the Document of the Location object is relevant here.

[14:37:30.0000] <Hixie_>
what i said was different than what you said.

[14:37:44.0000] <bholley>
:-)

[14:38:39.0000] <bholley>
Hixie_: so, 10 minutes ago, we agreed that we need to do a security check against bc origin at method call time

[14:38:41.0000] <bholley>
Hixie_: right?

[14:38:52.0000] <bholley>
Hixie_: that's how I'm defining bc origin

[14:39:09.0000] <Ms2ger>
r? https://critic.hoppipolla.co.uk/r/208

[14:39:18.0000] <Hixie_>
oh i assumed you mean the origin of the calling script

[14:39:58.0000] <Hixie_>
the Location object's "native origin" is the origin of the Document with which it's associated, right?

[14:40:14.0000] <Hixie_>
that's the one that should be allowed to extend the Location object

[14:40:18.0000] <bholley>
Hixie_: sure. "native origin" is a good term

[14:40:20.0000] <bholley>
Hixie_: yes

[14:40:41.0000] <Hixie_>
if that document's browsing context's active document happens to get hold of the Location object of an earlier document, it shouldn't see those extensions, and shouldn't be able to add any itself.

[14:40:47.0000] <Hixie_>
it has its own Location object to mess with.

[14:41:06.0000] <bholley>
Hixie_: righto

[14:41:17.0000] <Hixie_>
(it has its own family of Location objects)

[14:41:22.0000] <Hixie_>
(one for each origin)

[14:41:28.0000] <Hixie_>
(but we'll pretend they're one for now)

[14:41:42.0000] <Hixie_>
(or i guess, it has one Location object with a family of prototypes)

[14:41:49.0000] <Hixie_>
(or some crazy thing. what we discussed before.)

[14:42:17.0000] <bholley>
(I think there was only one prototype in what we discussed before. but whatever. let's finish this thing here)

[14:42:39.0000] <bholley>
Hixie_: hence, my proposal is that property-access checks use the "native origin"

[14:43:07.0000] <Hixie_>
ok, i agree with that. it's not the "bc origin", though.

[14:43:22.0000] <bholley>
Hixie_: agreed. I didn't mean to imply otherwise

[14:43:27.0000] <Hixie_>
(that is, it might not be the origin of any of the active documents)

[14:43:33.0000] <bholley>
Hixie_: sure

[14:43:42.0000] <Hixie_>
ok so i'm confusd by "we need to do a security check against bc origin" then

[14:44:03.0000] <Hixie_>
during method calls

[14:44:16.0000] <Hixie_>
why would method call checks use something different than the property checks?

[14:44:28.0000] <bholley>
Hixie_: because of what you said: "Hixie_: yes, because we don't want to be able to use our location object's methods on thir location object and thus bypass the property get check"

[14:44:50.0000] <bholley>
Hixie_: or maybe I didn't fully understand you

[14:45:00.0000] <bholley>
Hixie_: but let's step back

[14:45:08.0000] <bholley>
Hixie_: the reason for the bc method-call checks

[14:45:52.0000] <Hixie_>
we don't want a script in origin B to call a method on a Location object whose native origin is A using the method from one of B's Location objects

[14:46:07.0000] <bholley>
Hixie_: ok, that's a different issue. Sorry

[14:46:16.0000] <bholley>
Hixie_: the reason for the bc method-calls checks

[14:46:43.0000] <bholley>
Hixie_: is that, per-spec, the Location object describes the URL of the active document in the BC

[14:47:39.0000] <bholley>
Hixie_: which means that, if evil.com navigates itself to bank.com, evil.com's window.location describes the URL of bank.com's document

[14:48:01.0000] <Hixie_>
sure, so the _properties_ need to do a check against the active document

[14:48:07.0000] <Hixie_>
but you said the methods

[14:48:30.0000] <bholley>
Hixie_: are you making a distinction between .toString() and .href?

[14:48:49.0000] <bholley>
Hixie_: I'm using 'method' to refer to 'methods, getters, and setters'

[14:49:37.0000] <Hixie_>
oh, well, that's confusing :-)

[14:49:42.0000] <Hixie_>
i'd actually forgotten about toString()

[14:49:54.0000] <Hixie_>
but in any case, looks like comment 32 agrees with you

[14:49:58.0000] <bholley>
Hixie_: I'm trying to distinguish between ES-level property access - Object.getOwnPropertyDescriptor()

[14:50:14.0000] <bholley>
Hixie_: and DOM-level code, which is what happens when you invoke methods or getters or setters

[14:51:16.0000] <Hixie_>
oh, ok. that wasn't clear.

[14:51:30.0000] <bholley>
Hixie_: my apologies

[14:51:34.0000] <Hixie_>
why do we need to do any checks at the property descriptor level?

[14:51:48.0000] <bholley>
Hixie_: because of the expando thing

[14:51:50.0000] <Hixie_>
if all Location objects pretend to be virgin objects cross-origin, you can't get anthing interesting that way

[14:52:22.0000] <Hixie_>
i have to bail again, sorry. let me know when you're back on the ground and we can continue this?

[14:52:32.0000] <bholley>
Hixie_: yeah, sounds good. Note that I'll be in France

[14:52:42.0000] <Hixie_>
k

[14:52:44.0000] <bholley>
Hixie_: but some evening-for-me-morning-for-you we can get back to this

[14:52:48.0000] <bholley>
Hixie_: and thanks for taking the time here

[14:52:59.0000] <Hixie_>
keep pinging me, my schedule is all out of wack these days

[14:53:12.0000] <Hixie_>
thank _you_ for putting up with my difficultis :-)

[14:53:17.0000] <Hixie_>
we'll figure it out

[14:53:18.0000] <Hixie_>
bbl

[14:53:24.0000] <Hixie_>
have a good flight

[14:53:32.0000] <bholley>
Hixie_: thanks

[15:01:06.0000] <annevk>
So from what I read on http://asciiwwdc.com/2013/sessions/614 it seems like "Safari push notifications" are wildly different from http://www.w3.org/TR/push-api/

[15:01:37.0000] <annevk>
The former actually creates an end-user notification and the latter uses a service worker to decide what to do next...

[15:02:30.0000] <zewt>
probably modelled around iOS push notifications

[15:03:41.0000] <zewt>
i think there are two different things that get called "push notifications": for pushing a message to a user (like SMS popups), and for pushing a message to a running app...

[15:04:06.0000] <zewt>
(which is to say, they may be targetting different things and not be at odds, other than using the same name)

[15:35:17.0000] <Hixie_>
can someone tell me what IE does on http://www.hixie.ch/tests/adhoc/dom/level0/history/cross-origin/001.html ?

[15:53:41.0000] <Hixie_>
or http://www.hixie.ch/tests/adhoc/dom/level0/history/cross-origin/000.html for that matter

[15:53:42.0000] <zewt>
the heck? firefox's download page won't tell me what version of Firefox it's about to send me--I have to actually start the download and look at the filename

[15:53:57.0000] <Hixie_>
shouldn't you always just get the latest version?

[15:54:08.0000] <Hixie_>
"versions" are so last decade

[15:54:32.0000] <zewt>
... the whole reason I'm at the page is to find out if I'm on the latest version or not

[15:54:44.0000] <annevk>
Hixie_: says "Ok, calling back() on our old History object..."

[15:55:10.0000] <annevk>
Hixie_: in both

[15:55:11.0000] <Hixie_>
annevk: thanks

[15:55:35.0000] <annevk>
Hixie_: 001 has damowmow and 000 has www.hixie.ch in colors

[15:55:43.0000] <Hixie_>
cool ok

[15:55:47.0000] <Hixie_>
thanks

[15:56:12.0000] <Hixie_>
so basically History objects from inactive Documents don't do anything

[15:56:15.0000] <Hixie_>
and throw

[15:56:28.0000] <Hixie_>
which makes sense

[15:56:34.0000] <Hixie_>
maybe we should define this at the WebIDL level though

[15:57:27.0000] <Hixie_>
heycam|away: would it make sense to have some sort of WebIDL attribute I can put on interfaces that says "anything on this that gets called should throw if it is not [magic hook]"

[15:58:29.0000] <Hixie_>
heycam|away: so i can put this on History (and maybe others), where [magic hook] in this case would be "it's Document is the active document of its Document's browsing context"

[15:58:47.0000] <Hixie_>
s/it's/its/

[16:00:06.0000] <Hixie_>
i guess i'll file a bug

[16:08:30.0000] <Hixie_>
/me wonders wtf @@unscopable is

[16:14:08.0000] <zewt>
that's pretty incredible: IE10's network console lies about response headers

[16:14:26.0000] <zewt>
(it's getting a response with Content-Encoding: gzip, and it's not listed at all)

[16:14:32.0000] <zewt>
<- trusts ngrep more than IE10

[16:15:38.0000] <Hixie_>
tcpdump is the only reliable source

[16:15:40.0000] <Hixie_>
:-P

[16:15:46.0000] <zewt>
easier to get raw data with ngrep

[16:15:54.0000] <zewt>
tcpdump is better for squinting at packet headers

[16:16:18.0000] <Hixie_>
(though tcpdump lies about what it does right in its name, so i guess it starts from a poor position in the race to "not lying")

[16:16:51.0000] <zewt>
i rarely grep with ngrep, I guess

[16:17:07.0000] <Hixie_>
ngrep and tcpdump both use pcap, so they're basically the same thing, anyway

[16:18:08.0000] <zewt>
i don't know though, i know i shouldn't be surprised by stupid crap IE does, but missing headers in the network tab in the developer console? seriously?

[16:18:32.0000] <zewt>
that's just mean

[16:19:15.0000] <Hixie_>
probably a side-effect of their network library trying to transparently support gzip

[16:19:36.0000] <Hixie_>
i mean, mozilla's view source lied about the source for a long time

[16:19:41.0000] <Hixie_>
it's not unheard of

[16:20:43.0000] <zewt>
lies, damn lies and debuggers

[16:23:33.0000] <Hixie_>
(filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23358 for the above)

[16:44:47.0000] <vitalia>
Hi. Before update to html-lib 0.99 I do sanitize in such way: "def sanitize(value):


2013-09-26
[17:31:17.0000] <annevk>
Hixie_: @@unscopeable is a temporary name for a property that is used to hide other properties from with() lookup

[17:32:11.0000] <annevk>
Hixie_: @@unscopeable will be become Symbol.unscopeables or some such and then you'd have Array.prototype[Symbel.unscopeables] = ["find", ...] predefined to not run into compatibility bugs

[17:33:03.0000] <annevk>
Hixie_: similarly we could have Element.prototype[Symbol.unscopeables] = ["after", "before", ...] to hide certain common names, assuming event handlers are similarly defined to with

[17:41:28.0000] <Hixie_>
annevk: isn't with supposed to be dead?

[17:53:23.0000] <heycam>
are we going to make all new things on nodes unscopeable? or just do it for names that are likely to be problematic?

[17:55:58.0000] <annevk>
Hixie_: the web uses it and prevents extending Array.prototype due to the way it is used

[17:56:10.0000] <heycam>
annevk, are we going to make all new things on nodes unscopeable? or just do it for names that are likely to be problematic?

[17:56:28.0000] <heycam>
this is for onclick="barename" right?

[17:56:35.0000] <annevk>
heycam: case-by-case, if unscopeable makes it through

[17:56:37.0000] <annevk>
heycam: yeah

[17:56:44.0000] <heycam>
hmm

[17:57:01.0000] <heycam>
tbh I would prefer to draw a line and say only existing things are in scope automatically

[17:58:25.0000] <Hixie_>
annevk: k

[17:59:44.0000] <Hixie_>
heycam: while you're here, any comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=23358 ?

[18:00:10.0000] <heycam>
/me looks

[18:01:01.0000] <heycam>
Hixie_, so this sounds a little similar to what WebGL is doing for annotating methods that should throw if the context has been lost

[18:01:12.0000] <Hixie_>
similar, yeah

[18:01:34.0000] <heycam>
Hixie_, I suggested to them that they define that extended attribute in WebGL itself. how HTML-specific is this one you need?

[18:01:59.0000] <Hixie_>
i don't know. right now i only want it for History

[18:02:04.0000] <Hixie_>
which is just HTML

[18:02:10.0000] <Hixie_>
but i wouldn't be surprised to see it used elsewhere

[18:02:24.0000] <Hixie_>
really my ulterior motive is getting out of defining what it means exactly

[18:02:28.0000] <Hixie_>
otherwise i'd have just done it in prose :-)

[18:02:57.0000] <heycam>
heh

[18:03:04.0000] <heycam>
well, if you don't know exactly how it's meant to be defined...

[18:03:37.0000] <Hixie_>
i mean, i know what i want it to do: throw an exception on method and property accesses

[18:03:53.0000] <Hixie_>
but ES is getting more and more complicated and has gone over my head

[18:04:06.0000] <Hixie_>
such that i no longer know how to define this, let alone in a language-agnostic way.

[18:04:09.0000] <heycam>
ok

[18:05:10.0000] <heycam>
I think then it makes sense to have something defined in Web IDL, to do the check at all the right points

[18:07:55.0000] <heycam>
[Poisonable] on the History interface, where then you define in HTML when a History object is poisoned

[18:07:57.0000] <heycam>
something like that

[18:08:26.0000] <Hixie_>
lgtm

[18:08:31.0000] <heycam>
/me comments in the bug

[18:08:40.0000] <Hixie_>
or actually

[18:08:43.0000] <Hixie_>
we don't even need an annotation

[18:09:02.0000] <heycam>
I guess not

[18:09:05.0000] <Hixie_>
just have it possible for objects to be in a poisoned state (note, it should be possible for this to revert out of it), and by default, it never gets set

[18:09:50.0000] <heycam>
just like now we have the security check hook in various places

[18:11:04.0000] <Hixie_>
yeah

[18:11:44.0000] <heycam>
any particular exception you think would be good to throw?

[18:12:09.0000] <Hixie_>
there's a test in the dependant bug

[18:12:18.0000] <Hixie_>
i didn't check what the exception type is

[18:12:30.0000] <Hixie_>
but it triggers it

[18:12:37.0000] <Hixie_>
i don't remember in what browsers

[18:12:42.0000] <Hixie_>
(some just do no-ops instead of throwing)

[18:13:45.0000] <heycam>
I see a SecurityError in the console for the second test

[18:13:48.0000] <heycam>
but nothing for the first

[18:14:20.0000] <heycam>
is the need for this History object poisoning because of document origin changing or something?

[18:14:29.0000] <heycam>
does it make sense to handle it as part of the security check hook?

[18:16:29.0000] <Hixie_>
000.html is a same-origin cas

[18:16:31.0000] <Hixie_>
case

[18:16:44.0000] <Hixie_>
(sorry can't talk much or do testing right now)

[18:16:50.0000] <heycam>
ok, will take discussion to bug

[18:17:02.0000] <Hixie_>
pretty sure that some of the browsers throw for both

[18:17:06.0000] <Hixie_>
if they don't then it might change things

[18:17:22.0000] <Hixie_>
also note that some browsers report SecurityError but not other exceptions, iirc

[18:17:28.0000] <heycam>
mm

[18:17:31.0000] <Hixie_>
so you might have to change the test to catch it or something

[18:17:36.0000] <heycam>
ah ok

[18:17:59.0000] <heycam>
I might punt it back to you in the bug to check what behaviour we ultimately need

[18:19:23.0000] <Hixie_>
sure thing. make sure it's assigned to me, bugs that aren't assigned to me have month-long lag cos i only read the bugmail every few months

[18:37:51.0000] <annevk>
http://store.steampowered.com/livingroom/SteamMachines/

[18:40:49.0000] <annevk>
heycam: not sure if my email mentioned it, but having [Global] and [Exposed] annotations would be welcome

[18:41:21.0000] <heycam>
annevk, yeah, would be good to solve those together

[18:41:25.0000] <heycam>
I think we can do it

[18:43:26.0000] <annevk>
I hope this Valve thing takes off

[22:29:38.0000] <ondras>
morning

[22:29:47.0000] <ondras>
anyone suitable for discussion re. <dialog> ?

[22:31:12.0000] <falken>
hi ondras, i'd be interested in such a discussion. i'm implementing it in chromium

[22:38:41.0000] <ondras>
falken: I am intrigued by the naming inconsistency in the JS API, namely the "show/close" methods

[22:38:50.0000] <ondras>
i.e. no "show/hide" nor "open/close"

[22:39:21.0000] <ondras>
but as a non-native speaker, I might be missing some language subtleties

[22:39:41.0000] <ondras>
I always try to create the naming pairs as mentioned above, for the sake of consistency

[22:39:52.0000] <falken>
ondras: yes there was discussion on the list about that... one sec

[22:40:11.0000] <falken>
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-August/040593.html

[22:40:36.0000] <falken>
it was named to be consistent with the existing window.showModalDialog(), window.close()

[22:42:04.0000] <ondras>
ah

[22:42:07.0000] <ondras>
thanks for the link

[22:42:30.0000] <ondras>
from the short discussion fragment, it looks like the majority is voting towards a open/close change, right?

[22:42:39.0000] <Hixie_>
we don't base decisions on votes

[22:42:49.0000] <ondras>
yeah, well, of course

[22:42:54.0000] <Hixie_>
but if there's a stronger argument to do it one way or another that hasn't yet been discussed, please do bring it up :-)

[22:42:59.0000] <ondras>
I just wanted to grasp the general attitude

[22:43:37.0000] <ondras>
well, I do not bring any new insights. as a web developer who creates similar windows with existing APIs, I always stick to open/close or show/hide

[22:43:42.0000] <Hixie_>
(it's still being implemented, so now's the last chance to get the names pinned down)

[22:44:01.0000] <ondras>
but my voice has a zero weight, I guess

[22:44:08.0000] <ondras>
all the relevant arguments were mentioned

[22:44:11.0000] <Hixie_>
ondras: do you use openModal() or showModal() though?

[22:44:36.0000] <Hixie_>
for modal dialogs, close() seems to be uniformaly the right terminology, but the question is how do you open it

[22:44:47.0000] <Hixie_>
and a lot of APIs do seem to use show*() for modals

[22:45:07.0000] <Hixie_>
like showModalDialog(), MessageBox::Show(), etc

[22:45:21.0000] <ondras>
Hixie_: exactly as you said; "close" being the more natural versions, which implies - because of consistency - that the second method must be "open"

[22:45:29.0000] <ondras>
*version

[22:45:53.0000] <ondras>
the openModal()/showModal() are some existing standardized APIs? I was thinking more of a proprietary application/widget-specific methods

[22:46:06.0000] <Hixie_>
showModalDialog() is in HTML already, takes close()

[22:46:18.0000] <Hixie_>
MessageBox is win32

[22:46:46.0000] <Hixie_>
something that would be useful is an objective look at what other APIs do

[22:46:53.0000] <Hixie_>
e.g. win32, jQuery, delphi, etc

[22:47:50.0000] <ondras>
I see. I was somewhat aware of a showModalDialog, but always as a MS-only non-widely-implemented extension

[22:51:12.0000] <ondras>
http://qt-project.org/doc/qt-4.7/qwidget.html

[22:51:14.0000] <ondras>
this is interesting

[22:51:21.0000] <ondras>
they have show, hide and close

[22:52:05.0000] <ondras>
show and hide being equal to setVisibility(1/0)

[23:25:41.0000] <ondras>
Hixie_: are you still around?

[23:25:52.0000] <Hixie_>
sort of

[23:27:54.0000] <ondras>
Hixie_: I have this weird behavior of querySelectorAll in a particular case

[23:27:55.0000] <ondras>
Hixie_: http://jsfiddle.net/fwJrp/

[23:28:03.0000] <ondras>
basically, a table inside a table

[23:28:13.0000] <ondras>
but the behavior is consistent across browsers

[23:28:30.0000] <ondras>
looks incorrect, but there is probably some stuff in the spec that I am missing

[23:28:46.0000] <Hixie_>
why is it wrong?

[23:28:50.0000] <ondras>
shall be 1?

[23:28:59.0000] <ondras>
rows in tbody inside the second table

[23:29:05.0000] <Hixie_>
the tr is in a tbody, so it should be selecting the thead's row

[23:29:12.0000] <Hixie_>
the thead's tr i mean

[23:29:47.0000] <ondras>
oh right, my bad

[23:30:00.0000] <ondras>
no

[23:30:02.0000] <ondras>
damn.

[23:30:09.0000] <ondras>
the querySelectorAll

[23:30:13.0000] <ondras>
is executed on the second table

[23:30:45.0000] <ondras>
so I thought that the expression takes that node as a root for evaluating the selector

[23:31:14.0000] <Hixie_>
there's some scoping mechanism, but i forget what it is

[23:31:16.0000] <Hixie_>
:scope or something

[23:32:43.0000] <ondras>
Hixie_: http://updates.html5rocks.com/2013/03/What-s-the-CSS-scope-pseudo-class-for

[23:32:47.0000] <ondras>
found it

[23:32:49.0000] <ondras>
thanks

[00:39:12.0000] <zcorpan>
jgraham: MikeSmith: why isn't https://critic.hoppipolla.co.uk/r/309 tracking the PR anymore?

[00:54:15.0000] <zcorpan>
jgraham: btw, it might be useful to try to get plinns on board with the testing thing. i recall from the css f2f that he hadn't integrated css's testing thing with your thing because the goals are different (getting spec to rec vs. improving interop). but he also said he didn't mind having different tests for the different goals

[00:56:34.0000] <zcorpan>
(or something along those lines)

[01:09:47.0000] <zcorpan>
Hixie_: http://www.whatwg.org/specs/web-apps/current-work/multipage/fragment-links.js is still broken. can you look at it, please? it blocks me generating html-differences with anolis+xref.

[03:02:26.0000] <jgraham>
zcorpan: Because MikeSmith rebased the branch

[03:02:43.0000] <jgraham>
It doesn't (yet) deal with that automagically

[03:03:04.0000] <jgraham>
YOu have to click "Rebase Review", follow the steps, and then reenable tracking

[03:10:04.0000] <zcorpan>
jgraham: ah

[03:10:07.0000] <zcorpan>
thx

[03:12:41.0000] <jgraham>
(I did it for that review)

[07:07:47.0000] <annevk>
So should TextDecoder and XMLHttpRequest also accept ArrayBuffer in addition to ArrayBufferView?

[07:08:54.0000] <annevk>
Also, where is ArrayBufferView defined these days?

[07:09:25.0000] <annevk>
Did they rename that to DataView in ES6? Is that compatible?

[07:11:53.0000] <annevk>
Oh, it was never exposed...

[07:12:24.0000] <annevk>
The ES6-equivalent is %TypedArray%

[07:25:54.0000] <zcorpan>
annevk: i think we should allow both as input for consistency with WebSocket

[07:26:14.0000] <annevk>
Yeah, filed a bug on IDL

[07:26:44.0000] <annevk>
Now they're ES types IDL needs fixing

[07:46:35.0000] <MikeSmith>
jgraham, zcorpan - so, clearly there is something I'm doing wrong as far as what Critic expects

[07:46:42.0000] <MikeSmith>
but I don't know exactly what

[07:47:11.0000] <MikeSmith>
I don't understand how to rebase without getting that error e-mail from Critic

[07:47:22.0000] <zcorpan>
do you need to rebase?

[07:47:46.0000] <MikeSmith>
I had thought I did because Critic expected it for some reason

[07:48:24.0000] <MikeSmith>
but I assume now that all I need to do is a simple commit and push to the branch

[07:48:55.0000] <zcorpan>
yeah

[07:49:00.0000] <MikeSmith>
OK

[07:49:01.0000] <jgraham>
MikeSmith: So, I don't know what you're *doing*, much less what you're doing wrong

[07:49:23.0000] <MikeSmith>
what I did was just a "git rebase master" on the branch

[07:49:39.0000] <MikeSmith>
and then "git push -f" to push it to the branch

[07:49:41.0000] <MikeSmith>
my branch

[07:50:23.0000] <MikeSmith>
and.. that's it, really

[07:51:52.0000] <jgraham>
So did you do anything with critic?

[07:52:19.0000] <MikeSmith>
yeah, responded to review feedback from zcorpan

[07:52:34.0000] <MikeSmith>
manually, through the Critic ui

[07:52:41.0000] <jgraham>
But you didn't interact with the rebase feature?

[07:53:31.0000] <MikeSmith>
yeah, well, I pushed the button for "Update" whatever

[07:53:40.0000] <MikeSmith>
the one next to "Rebase Review"

[07:53:54.0000] <MikeSmith>
because... I thought I had to do that for some reason

[07:53:56.0000] <jgraham>
If you push "Update" at that point, you will get an error

[07:54:01.0000] <MikeSmith>
aha

[07:54:17.0000] <MikeSmith>
so ok then, what exactly should I do at that point?

[07:54:19.0000] <MikeSmith>
nothing?

[07:54:20.0000] <jgraham>
Because it needs to be told about the rebase

[07:54:25.0000] <MikeSmith>
ah

[07:54:35.0000] <MikeSmith>
so how do I do that?

[07:55:00.0000] <jgraham>
At the moment you push "Rebase Review"

[07:55:05.0000] <jgraham>
And then follow the steps

[07:55:17.0000] <jgraham>
Clearly this needs to be more automated if possible

[07:55:46.0000] <MikeSmith>
well mostly it's probably just pilot error on my part

[07:55:55.0000] <MikeSmith>
I just like to push buttons to see what will happen

[07:56:07.0000] <zcorpan>
automate and remove the buttons by default :-)

[07:56:23.0000] <MikeSmith>
so anyway, right now I will push "Rebase Review" and see what I break next :)

[07:56:42.0000] <jgraham>
Well, like I say, I think there is probably enough information in the github API to do this automatically

[07:56:52.0000] <jgraham>
But I am not sure until I try to implement

[07:57:32.0000] <zcorpan>
MikeSmith: jgraham already rebased review 309

[07:57:37.0000] <MikeSmith>
oh

[07:57:45.0000] <MikeSmith>
well, the commits don't show up there

[07:58:38.0000] <zcorpan>
it shows up as a single commit. and i've reviewed it

[07:58:57.0000] <jgraham>
Right

[07:58:58.0000] <jgraham>
So

[07:59:32.0000] <jgraham>
Critic can't, in general, tell the difference between changes that happened because of the rebase, and extra commits that you pushed

[07:59:32.0000] <MikeSmith>
ok

[07:59:38.0000] <MikeSmith>
ah yeah

[07:59:50.0000] <MikeSmith>
so I understand why that's the case

[08:01:04.0000] <MikeSmith>
zcorpan: so you saw/reviewed https://github.com/sideshowbarker/web-platform-tests/commit/8532cf210959b36c2d3f877da508754ee0646cda ?

[08:01:52.0000] <MikeSmith>
which is, I just dropped the CRs from that test document completely

[08:02:04.0000] <zcorpan>
MikeSmith: yes. and there's currently 1 open issue. :-)

[08:02:40.0000] <MikeSmith>
/me tries to find where the issue is listed

[08:02:43.0000] <jgraham>
Basically when you push a rebase, it looks at the whole branch history before the rebase, the whole branch history after the rebase, and calls the difference between these two the "equivalent merge commit"

[08:03:01.0000] <zcorpan>
MikeSmith: under "Open Issues" in https://critic.hoppipolla.co.uk/r/309

[08:03:01.0000] <MikeSmith>
I see that the UI says there's an issue but as yet I don't find right away where the issue is listed

[08:03:19.0000] <MikeSmith>
jgraham: right yeah, understood

[08:03:53.0000] <MikeSmith>
zcorpan: OK I see the Open Issues head there again now

[08:04:07.0000] <MikeSmith>
ah OK

[08:05:17.0000] <zcorpan>
gotta go

[08:05:37.0000] <MikeSmith>
zcorpan: ok, thanks

[08:05:47.0000] <MikeSmith>
thanks for your patience :)

[08:09:19.0000] <jgraham>
In more examples of aresome PHP documentation, it doesn't say if echo (or print) implicity adds a line break

[08:09:26.0000] <jgraham>
*awesome

[08:09:44.0000] <jgraham>
Although arse-some would be more right

[08:11:13.0000] <jgraham>
Anyone want to enlighten me?

[08:11:50.0000] <zewt>
isn't that a pretty trivial thing to just find out :P

[08:12:00.0000] <zewt>
> php

[08:12:00.0000] <zewt>
<? print "x"; print "x"; ?>

[08:12:00.0000] <zewt>
xx

[08:12:43.0000] <darobin>
jgraham: it probably depends on something in php.ini :)

[08:12:58.0000] <jgraham>
zewt: I don't have PHP installed…

[08:13:25.0000] <jgraham>
zewt: So, is echo the same or is it different?

[08:13:44.0000] <zewt>
same

[08:14:10.0000] <jgraham>
zewt: Thanks

[08:15:00.0000] <jgraham>
I wonder why they thought that three ways to spell the same feature were needed

[10:10:58.0000] <jsbell>
annevk: Thanks for kicking off the "byte sequence" bug/discussion.

[10:23:07.0000] <annevk>
jsbell: was trying to fix bugs in XHR and ran into that basically :)

[10:35:59.0000] <annevk>
jsbell: DataView is just another ArrayBufferView right?

[10:37:28.0000] <zewt>
... what the fuck?

[10:37:33.0000] <zewt>
DataView defaults ... to big endian?

[10:37:39.0000] <zewt>
who is smoking what, and in what quantities?

[10:40:21.0000] <Jasper>
zewt, networking is typically big-endian

[10:41:13.0000] <zewt>
nothing in javascript ever touches low-level network data

[10:41:25.0000] <jsbell>
annevk: Yeah, DataView is an ArrayBufferView

[10:41:39.0000] <annevk>
jsbell: not entirely clear whether that's still the case in ES6 btw

[10:42:30.0000] <jsbell>
I didn't see "ArrayBufferView" at all in the ES6 draft.

[10:43:08.0000] <jsbell>
So depends what you mean by "just" I guess

[10:43:43.0000] <annevk>
jsbell: the common ancestor is %TypedArray% for Uint8Array and friends

[10:44:10.0000] <annevk>
jsbell: which is not exposed

[10:44:20.0000] <annevk>
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-22.2

[10:44:38.0000] <annevk>
DataView is defined elsewhere http://people.mozilla.org/~jorendorff/es6-draft.html#sec-24.2 and seems somewhat unrelated

[10:44:51.0000] <jsbell>
annevk: %TypedArray% is more of a macro parameter in the spec than a type, if I read it correctly.

[10:44:54.0000] <zewt>
DataView is pointless, should just be rolled in as methods on the base class of all views

[10:45:01.0000] <annevk>
jsbell: yeah

[10:45:30.0000] <Ms2ger>
<zcorpan> jgraham: btw, it might be useful to try to get plinns on board with the testing thing. i recall from the css f2f that he hadn't integrated css's testing thing with your thing because the goals are different (getting spec to rec vs. improving interop). but he also said he didn't mind having different tests for the different goals

[10:45:41.0000] <Ms2ger>
Sounds like we get to put css tests in wpt, then?

[10:45:42.0000] <jsbell>
zewt: Use case for DataView is you get a buffer off the wire and then you are parsing it... you can do unaligned access which the array types don't let you do w/o copying.

[10:46:58.0000] <jsbell>
Ah, missed the "base class of all views". Well, if there was one. :)

[10:48:29.0000] <zewt>
sorry, I mean having the methods on a separate object you have to create is pointless; the methods should just be available on the other views

[10:48:40.0000] <zewt>
afk, work

[10:53:31.0000] <annevk>
jsbell: added a comment with what I think we can use as strategy

[10:53:43.0000] <annevk>
jsbell: well, apart from return value...

[10:53:46.0000] <jsbell>
:)

[10:55:45.0000] <annevk>
jsbell: is there a reason we went with returning a view in TextEncoder?

[10:57:05.0000] <jsbell>
annevk: I don't recall off the top of my head, will poke around in the threads. Possibly because a raw ArrayBuffer is pretty useless and you're probably going to wrap it with a Uint8Array anyway

[10:57:58.0000] <jsbell>
We need sicking to weigh in. I share his concern that for APIs that accept and emit binary (like indexeddb), passing in one type and getting another out is wierd.

[10:58:00.0000] <Jasper>
zewt, the even more fun thing is that if you use a Uint32Buffer or something, the endianness is completely undefined

[10:58:06.0000] <Jasper>
zewt, which I think is absolutely broke

[10:58:08.0000] <Jasper>
n

[10:58:31.0000] <sicking>
jsbell: especially when that API is a storage API :) You generally expect to get back what you store :)

[10:59:06.0000] <jsbell>
... which would be true for IDB values but not "I just want binary" keys.

[10:59:46.0000] <Ms2ger>
jgraham, ping

[11:00:25.0000] <sicking>
jsbell: is there a problem with limiting to Uint8Array as type? Should be pretty cheap and easy to always wrap a Uint8Array around whatever type you have

[11:00:55.0000] <sicking>
brb

[11:00:56.0000] <annevk>
sicking: is there a problem with supporting all the different types?

[11:00:59.0000] <jsbell>
sicking: See the discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

[11:01:13.0000] <jsbell>
... for the other side of the argument so far

[11:01:23.0000] <annevk>
jsbell: seems that for Indexed DB you might want something more complicated

[11:01:56.0000] <annevk>
jsbell: platform APIs I was thinking of were XMLHttpRequest, WebSocket, TextDecoder, Blob, File, etc.

[11:02:10.0000] <annevk>
jsbell: for those normalization makes sense, dunno about Indexed DB

[11:02:37.0000] <jsbell>
annevk: For this particular bit of IDB we really do just want a ByteSequence (it's a proposed addition, BTW, not a shipping feature)

[11:02:54.0000] <annevk>
Oh okay

[11:03:06.0000] <jsbell>
We could mandate Uint8Array in/out but platform alignment seem like a good thing

[11:04:08.0000] <jgraham>
Ms2ger: pong

[11:04:54.0000] <sicking>
annevk: remember that we're talking about keys here. IDB already supports storing all types of binary arrays

[11:05:03.0000] <Ms2ger>
jgraham, https://critic.hoppipolla.co.uk/r/303 doesn't seem to be closed

[11:05:45.0000] <annevk>
sicking: aight

[11:06:56.0000] <annevk>
sicking: https://gist.github.com/domenic/0c47ae300608341f3d7f is Domenic_'s sketch on streams btw, it's not done or anything, but at least a lot less complex than what's going on over at public-webapps...

[11:07:26.0000] <jgraham>
Ms2ger: Weird. It looks like the code ran, although I can't tell if it was for that PR

[11:07:35.0000] <sicking>
annevk: yeah, what's on webapps is all wrong. I've been very slowly sketching something different. Getting performance right is one of the tricky bits

[11:07:57.0000] <jgraham>
Ms2ger: Thanks for the bug report

[11:08:13.0000] <Ms2ger>
jgraham, np

[11:08:42.0000] <Ms2ger>
jgraham, you can test with https://critic.hoppipolla.co.uk/r/216 if necessary

[11:08:46.0000] <sicking>
annevk: hrm.. i don't think dominic's sketch is right. You want a synchronous read() function I think

[11:10:23.0000] <annevk>
sicking: hmm

[11:10:42.0000] <Domenic_>
sicking: i am not sure either, but, from what i understood of isaac's concerns, he wanted sync read only to avoid the microtask delay

[11:10:53.0000] <Domenic_>
but microtask delay should in theory be non-noticable

[11:11:07.0000] <Hixie_>
Ms2ger: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=23356

[11:11:29.0000] <Ms2ger>
Hixie_, yes?

[11:11:36.0000] <Domenic_>
but the correct design might indeed be some kind of poll-like function of the type isaac outlined, and you build promise-returning read() on top of it.

[11:11:40.0000] <sicking>
Domenic_: i don't think it's just that. But I'll reread his latest email.

[11:12:01.0000] <Hixie_>
Ms2ger: yes in answer to the question, or?

[11:12:01.0000] <Domenic_>
annevk: returning ArrayBuffer, generally, seems best. lets people choose the view they want

[11:12:08.0000] <sicking>
Domenic_: right. My thinking so far is that that is the right approach.

[11:12:17.0000] <Ms2ger>
Hixie_, "yes" as in "ack"

[11:12:21.0000] <Hixie_>
Ms2ger: ah ok

[11:12:43.0000] <Hixie_>
heycam|away: i don't have a satisfactory answer to give re: styling widgets. i tried to fix it with xbl2, but that didn't go anywhere.

[11:12:54.0000] <Domenic_>
sicking: cool, let me know what you deduce. he's on vacation which is why i haven't tried floating this anywhere; i want his stamp of approval, or at least approval-modulo-get-off-my-lawn-promise-users, before actually floating it.

[11:13:25.0000] <Ms2ger>
Hixie_, I have no dog in this fight; I just wanted to have something on file so I could point to it in a test

[11:13:33.0000] <sicking>
Domenic_: sounds good. I was planning on simply replying to his email once i had something

[11:13:44.0000] <sicking>
Domenic_: sorry it's taking so long. This isn't my day job these days

[11:14:11.0000] <Domenic_>
sicking: heh, mine neither! :P

[11:14:23.0000] <sicking>
Domenic_: :)

[11:16:16.0000] <Hixie_>
Ms2ger: sorry for being unclear; my question in the bug is just trying to figure out what your proposal would involve, not trying to see your opinion of it :-)

[11:17:38.0000] <Ms2ger>
Hixie_, my proposal is to do whatever document.images and friends do

[11:17:53.0000] <jsbell>
annevk: re: Encoding - looks like the early sketches of the API had it encode into a passed ArrayBufferView; that flipped to a return value, then the type was made concrete as Uint8Array. There were suggestions along the way to make it just return ArrayBuffer, but looks like those were ignored.

[11:18:48.0000] <annevk>
jsbell: I guess it's too late to change now

[11:25:05.0000] <annevk>
jsbell: btw, %TypedArray% is a common object, /TypedArray/ is not

[11:25:14.0000] <annevk>
jsbell: the italics matter afaict

[11:25:55.0000] <annevk>
hmm maybe not

[11:26:29.0000] <annevk>
hmm maybe yes

[11:30:32.0000] <jsbell>
hmm +1 - "The %TypedArray% intrinsic function object is designed to act as the superclass of the various /TypedArray/

[11:30:33.0000] <jsbell>
constructors." - yeah, more concrete than I thought.

[11:31:26.0000] <Hixie_>
Ms2ger: roger

[11:37:22.0000] <jsbell>
Hrm. Does having IDL specify  operation(SomeType foo) preclude passing ES6 subclasses of SomeType to operation?

[11:45:09.0000] <Ms2ger>
jsbell, yes

[11:46:42.0000] <annevk>
IDL needs fixing so badly

[11:46:45.0000] <jsbell>
That seems rather unfortunate.

[11:47:14.0000] <Ms2ger>
Why?

[11:47:24.0000] <annevk>
I don't even see why that would be true... If something accepts Node, it accepts Element...

[11:47:32.0000] <annevk>
Same should be true for ES6-style subclasses.

[11:47:47.0000] <Ms2ger>
Why?

[11:47:53.0000] <Ms2ger>
They're not trustworthy

[11:48:22.0000] <Ms2ger>
Something that takes Node should never accept an object that isn't a browser-implemented Node

[11:48:48.0000] <annevk>
Ms2ger: @@create gives it the same data model on which the browser can operate

[11:48:53.0000] <Jasper>
key events in browsers are so terrible

[11:49:01.0000] <Jasper>
we really need to fix this mess: https://github.com/kanaka/noVNC/blob/master/include/input.js

[11:49:15.0000] <annevk>
Jasper: are you volunteering?

[11:51:40.0000] <jsbell>
Jasper: do you have feedback on the key events part of https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm since it's starting to be implemented?

[11:56:08.0000] <Jasper>
annevk, depends what "volunteering" means

[11:57:39.0000] <Jasper>
jsbell, a big thing to think about is IM support, like pre-edit.

[11:58:30.0000] <jsbell>
hrm, I was sitting next to someone working on an IME+browser spec the other day...

[11:58:59.0000] <Jasper>
jsbell, it would be nice to see a full set of events for making robust input controls without having to have a hidden <textarea>

[11:59:21.0000] <annevk>
jsbell: one of the bad things with that document is it being a superset, though I think they plan on merging at some point

[11:59:38.0000] <jsbell>
Do note that I'm not working on that spec, just aware of it since I agree the current events are a mess :)

[12:00:01.0000] <annevk>
Jasper: mostly writing test cases I suppose and defining a model around your findings and then defining the events on top of that model

[12:00:18.0000] <Jasper>
annevk, have you seen http://unixpapa.com/js/key.html ?

[12:00:35.0000] <jsbell>
Jasper: Ah, yes: https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html

[12:00:51.0000] <annevk>
Jasper: looks like a start

[12:01:42.0000] <Jasper>
jsbell, is this for people that want to write IMs, or for people who want to write controls that interface with IMs?

[12:02:14.0000] <jsbell>
Jasper: "This specification defines an �IME API� that provides Web applications with scripted access to an IME (input-method editor) associated with a hosting user agent."

[12:02:39.0000] <Jasper>
OK.

[12:03:04.0000] <Jasper>
I also don't know what we want to do about keymapping. Most toolkits have just relegated to client-side keymaps, but that's really difficult to do on the web.

[12:03:46.0000] <jsbell>
Jasper: Who's "we", out of curiosity?

[12:04:13.0000] <Jasper>
"we" = specification authors

[12:04:42.0000] <Jasper>
I mainly work on GTK+, but that's not who I was referring to in the above sentence.

[12:07:05.0000] <jsbell>
Jasper: anyway, yeah, feel your pain. I bodged together https://github.com/inexorabletash/polyfill/blob/master/keyboard.js for my own use. I know the authors of the above specs want feedback.

[12:17:31.0000] <zcorpan_>
JS doesn't support a way to set properties of an object from properties of another object without enumerating, does it?

[12:18:18.0000] <Domenic_>
depends on what you mean by enumerating...

[12:18:41.0000] <gsnedders>
zcorpan_: ES5 doesn't, no

[12:19:06.0000] <zcorpan_>
what about ES>5?

[12:19:21.0000] <gsnedders>
Object.assign

[12:19:37.0000] <gsnedders>
I think?

[12:19:54.0000] <annevk>
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-19.1.3.1 TODO

[12:20:05.0000] <annevk>
zcorpan_: what do you want?

[12:20:08.0000] <gsnedders>
Someone remind me what the diff. between the proposed assign and mixin is?

[12:20:35.0000] <Domenic_>
Object.assign is entirely implementable in ES5, there's nothing new

[12:20:42.0000] <gsnedders>
Right, sure.

[12:21:06.0000] <Domenic_>
same for Object.mixin, modulo the fact that it uses Object.getOwnSymbols() which doesn't exist in ES5

[12:21:12.0000] <zcorpan_>
context is http://lists.w3.org/Archives/Public/www-style/2013Sep/0732.html

[12:21:15.0000] <Domenic_>
zcorpan_: what do you mean by enumerating?

[12:21:30.0000] <zcorpan_>
Domenic_: i mean e.g. for in

[12:21:49.0000] <Domenic_>
well e.g. is kind of what i was hoping to pin down

[12:21:53.0000] <gsnedders>
zcorpan_: But Object.assign and Object.mixin do enumerate… in the built-in classes.

[12:21:59.0000] <Domenic_>
you can avoid for-in by using e.g. Object.getOwnPropertyDescriptors

[12:22:05.0000] <gsnedders>
s/classes/objects/

[12:22:33.0000] <annevk>
zcorpan_: overload the setter

[12:22:40.0000] <zcorpan_>
ok so i guess my question was badly phrased. i don't mind if enumeration actually happens, i'm just looking for convenience for the author

[12:22:44.0000] <annevk>
zcorpan_: there's an outstanding feature request for that

[12:22:57.0000] <Domenic_>
can i suggest writing these things as a JS library first, then figuring out the appropriate WebIDL afterward

[12:23:06.0000] <annevk>
zcorpan_: so you always return DOMPoint, but you accept setting to either DOMPoint or DOMPointInit

[12:24:49.0000] <zcorpan_>
annevk: so is that (a) or (c) ?

[12:25:41.0000] <annevk>
zcorpan_: dunno, the IDL says stuff is readonly

[12:25:49.0000] <annevk>
zcorpan_: maybe writing this as a library is not such a bad idea

[12:26:39.0000] <zcorpan_>
annevk: the idea would be to change it to not be readonly, hence the question what setting should do :-)

[12:27:28.0000] <annevk>
zcorpan_: (c)

[12:27:52.0000] <zcorpan_>
(what i'm looking for now is a reason to keep it as readonly, if ES6 makes it convenient anyway)

[12:27:55.0000] <zcorpan_>
annevk: ok. why?

[12:27:58.0000] <annevk>
zcorpan_: calling it a literal is somewhat confusing btw

[12:28:52.0000] <Domenic_>
yeah a literal would be something like pt`(1, 2)`

[12:29:16.0000] <Domenic_>
or quad`((1, 2), (2, 3), (3, 4), (4, 5))`

[12:29:34.0000] <zcorpan_>
ok, thanks. what should it be called instead? Dict?

[12:30:10.0000] <annevk>
zcorpan_: Init

[12:30:17.0000] <Domenic_>
WebIDLArtifact? :P Dict or Init seems fine...

[12:31:46.0000] <zcorpan_>
can you explain how DOMPointInit makes sense? just consistency with events?

[12:32:14.0000] <annevk>
zcorpan_: it serves to initialize a new DOMPoint

[12:32:24.0000] <annevk>
zcorpan_: and yes

[12:32:40.0000] <zcorpan_>
ok

[12:32:42.0000] <annevk>
Domenic_: less jokes, more work on actually making it an artefact?

[12:32:54.0000] <annevk>
;)

[12:33:16.0000] <Domenic_>
annevk: fair...

[12:33:19.0000] <Domenic_>
/me goes back to real job

[12:34:01.0000] <zcorpan_>
Object.assign says "Only enumerable own properties of source" which wouldn't work for DOMPoint since the properties are on the prototype per WebIDL

[12:35:16.0000] <zcorpan_>
annevk: did you answer the why (c) ?

[12:35:52.0000] <annevk>
zcorpan_: no, but it seems convenient, though thinking a bit more for URLQuery I only support new URLQuery objects at the moment

[12:36:01.0000] <annevk>
zcorpan_: when assigning to url.query that is

[12:36:32.0000] <zcorpan_>
annevk: i mean why (c) over (a)?

[12:36:36.0000] <annevk>
well fuck, my train back to Boston is cancelled

[12:36:45.0000] <zcorpan_>
:-|

[12:37:08.0000] <annevk>
(I have some time to reschedule, but it's annoying)

[12:37:48.0000] <annevk>
zcorpan_: (a) seems weird, but I don't really have a good reason

[12:38:40.0000] <annevk>
zcorpan_: I guess if you do obj.x = y and then further mutate y, you'd expect that to affect obj.x

[12:39:17.0000] <Domenic_>
^ yeah, that

[12:39:30.0000] <Domenic_>
but that won't work without rethinking a lot, I think..

[12:39:42.0000] <Domenic_>
making it do no validation until consumption time

[12:39:45.0000] <zcorpan_>
that fails if it's an {x, y}

[12:40:53.0000] <annevk>
zcorpan_: I think if you pass in something that the property does not return you can expect that

[12:41:05.0000] <annevk>
zcorpan_: similar to setting location to a string

[12:41:12.0000] <zcorpan_>
on the flip side, if you have a quad and store its points as local variables, do you expect them to suddenly not be associated with the quad anymore?

[12:41:37.0000] <Domenic_>
if a JS library was doing this, it would do no validation in any of the setters, it would just accept anything. then the internal code that actually uses this.somePoint.x, this.somePoint.y would get those properties, and if they weren't there might throw (or might coerce ToNumber)

[12:42:18.0000] <Domenic_>
that way you could do things like quad.p1 = { x: 10, y: 20, extraStuff: "foo" }

[12:42:31.0000] <Domenic_>
and not disturb the internal algorithms at all, but still be able to access quad.p1.extraStuff later

[12:43:01.0000] <Domenic_>
that is probably too much re-thinking though

[12:43:23.0000] <annevk>
you prolly do want to coerce here at some point to pass things to the rendering subsystem

[12:43:36.0000] <Domenic_>
annevk: right but you'd do that at rendering time, no sooner

[12:44:05.0000] <annevk>
no you'd do it sooner because rendering can be on a separate thread and you don't want that to be observable

[12:44:17.0000] <Domenic_>
heh :). well JS libraries don't have access to separate threads

[12:44:29.0000] <Domenic_>
so it becomes a question of how un-idiomatic do you need to make things to fit into a multithreaded model.

[12:45:03.0000] <annevk>
coercion doesn't seem un-idiomatic, ToString() is used, Array.slice is used

[12:45:12.0000] <annevk>
turning an argument into an object seems fine

[12:45:25.0000] <Domenic_>
sure but you coerce when you use them, not when you set the property

[12:45:55.0000] <Domenic_>
if you were designing a JS library that took in points and quads you would not have this object hierarchy

[12:46:15.0000] <annevk>
I think bz mentioned quite a few libraries coerce right at the entry point of the function

[12:46:16.0000] <Domenic_>
you would just take as input an object and do `+obj.p1.x` and pass that to the rendering system

[12:46:22.0000] <Domenic_>
oh interesting

[12:46:28.0000] <Domenic_>
i guess i'm mostly thinking of jQuery and d3

[12:46:38.0000] <Domenic_>
and ES spec algorithms of course

[12:47:27.0000] <Domenic_>
anyway i need to pack up my crazy ideas and head elsewhere before people flip the bozo bit on me :). sorry zcorpan_ for derailing your well-meaning quest for practical advice.

[12:47:56.0000] <zcorpan_>
Domenic_: np, thanks for the feedback

[12:58:27.0000] <zcorpan_>
renamed to Init

[13:03:56.0000] <zcorpan_>
http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0159.html suggests using a method instead of a magic setter

[13:19:39.0000] <Ms2ger>
/me never realized that the IE10 logo is closer it IE6's than to IE7/8/9's

[13:29:32.0000] <Domenic_>
TabAtkins: is there a plan to make it possible to style a label for a checkbox differently, depending on whether or not its checked? I know the magic selectors 4 would make it work if those applied to stylesheets, but they don't. Any other plans?

[13:32:48.0000] <zewt>
jsbell: there is a base class (or at least a base interface) for all views, ArrayBufferView

[13:32:53.0000] <zewt>
err, Jasper

[13:33:19.0000] <zewt>
Jasper: yeah, we've tried to get them to fix that and they just don't "get" the web and why that's unacceptable

[13:34:28.0000] <jsbell>
zewt: You probably do mean me, and: yes, but not in the ES6 spec.

[13:34:58.0000] <zewt>
probably both (the latter was Jasper)

[13:35:10.0000] <jsbell>
(yep)

[13:35:12.0000] <zewt>
and ... why would they remove the base class? taking a bad API and making it worse

[13:35:28.0000] <Jasper>
zewt, who is "them"? Khronos?

[13:35:29.0000] <Ms2ger>
Is that TC39's tagline?

[13:35:49.0000] <zewt>
whoever's taking the typed array spec, putting it in another spec and taking out the base class

[13:36:00.0000] <Jasper>
hey TC39, don't be afraid. take a bad API and make it wooorse

[13:36:07.0000] <zewt>
anyway, it already has a base class in browsers, so that probably can't go away anyway

[13:36:29.0000] <zewt>
(window.ArrayBufferView exists in Chrome, at least)

[13:36:32.0000] <Jasper>
zewt, your answer was to my question about undefined endianness, right?

[13:36:35.0000] <zewt>
yeah

[13:36:44.0000] <Ms2ger>
Why would they spec things that work in browsers?

[13:36:44.0000] <Jasper>
zewt, I don't understand who is "them" in that case. TC39?

[13:36:59.0000] <zewt>
that's khronos, iirc, the typed array spec

[13:37:12.0000] <zewt>
(an offshoot of webgl)

[13:37:21.0000] <zewt>
i know why they did it the way they did; it's just wrong

[13:37:49.0000] <zewt>
Jasper/jsbell: i think your nicks have a hash collision in my brain at this point

[13:38:04.0000] <Jasper>
update from MD5?

[13:38:39.0000] <zewt>
i guess my hash is nick[0]

[13:38:56.0000] <zewt>
j.*s.*e

[13:40:22.0000] <Jasper>
zewt, I'm just concerned that people will load little endian files into Float32Array

[13:40:35.0000] <Jasper>
and then it will break when somebody plays it on a PowerPC or something

[13:40:40.0000] <zewt>
Jasper: oh, they will

[13:41:03.0000] <zewt>
the typed array editor(s) are under a misapprehension, heh

[13:41:04.0000] <TabAtkins>
Domenic_: No, but given that subject indicators are going to be part of the slow profile, we should indeed solve that issue for normal stylesheets.

[13:41:27.0000] <zewt>
they think that if they spec "this is platform-endian-dependent", browsers will implement that even if it causes big endian systems to not work on the web

[13:41:58.0000] <zewt>
the reality is that browsers will ignore the spec and make them always little-endian so that pages actually work (and take a performance hit, possibly a large one, for some WebGL cases)

[13:42:16.0000] <zewt>
(the real reality seems to be that big endian is essentially dead, and nobody even cares if it's broken)

[13:42:41.0000] <zewt>
iirc, the latter of those is why I stopped trying to convince them

[13:43:04.0000] <Domenic_>
TabAtkins: ok cool, yeah.

[13:43:05.0000] <Domenic_>
(I'm still secretly hoping someone implements the slow profile for normal stylesheets anyway and browser game theory forces it to become widespread.)

[13:45:28.0000] <TabAtkins>
Domenic_: Heh. You say that, but you'll be sad if putting one of them in your page drastically slows down all your selector matching.

[13:46:15.0000] <zewt>
Jasper: also, the alignment requirement of views is nonsense and should be removed (but I don't have the energy to try to get them to change things currently)

[13:46:48.0000] <zewt>
Jasper: however, the DataView interfaces are useful regardless of that, for parsing binary data structures (eg. to pull apart a ZIP header) without having to create tons of temporary views

[13:46:52.0000] <Jasper>
zewt, it would be nice if everything standardized to little-endian by default, but you could create a Float32Array that explicitly had host requirements because you know you won't be shipping this data anywhere

[13:47:10.0000] <Jasper>
had host endianness rather

[13:47:18.0000] <zewt>
yeah, I suggested at *least* adding explicit Int32LEArray/Int32BEArray (i don't remember the response, but it clearly hasn't happened)

[13:47:40.0000] <Jasper>
but what's likely to happens is that people will discover One Weird Trick To Speed Up Your Game By 200%

[13:47:45.0000] <Jasper>
and then everything's back to broken

[13:48:37.0000] <Jasper>
zewt, yeah, I'm more than familiar with the crazy things you can do with this

[13:48:40.0000] <Philip`>
zewt: I'm aware of some people using big-endian MIPS for new set-top box type things, with OpenGL support, who would probably try to disagree that it's dead

[13:48:47.0000] <Jasper>
https://github.com/magcius/img.js/blob/gh-pages/gif.js

[13:48:50.0000] <Jasper>
among other things

[13:48:55.0000] <zewt>
Philip`: they're fools and need to be shot into the sun

[13:49:22.0000] <Jasper>
zewt, I ran into the alignment requirements in that file I think

[13:49:42.0000] <Jasper>
also, I wrote a WebGL app that to this day still crashes Firefox

[13:49:48.0000] <Philip`>
zewt: (I think they're using essentially a little-endian GPU but with some hardware/software wrappers to make it cope with big-endian data)

[13:50:02.0000] <zewt>
basically, systems that need host-endian access to buffers (or else be really slow) are fundamentally incompatible with the Web (on one or the other endianness)

[13:50:26.0000] <zewt>
as far as I can tell, at least

[13:50:55.0000] <Jasper>
zewt, well, not entirely

[13:51:34.0000] <zewt>
maybe you could come up with some set of restrictions to only allow host-endian buffers to be used with WebGL, and not for general-purpose use ... but i'm not sure how possible that is

[13:51:54.0000] <Jasper>
zewt, what could make sense as a middleground is to prevent anybody from using a host-endian buffer to be used on array buffers returned from XHR or similar

[13:52:20.0000] <Jasper>
zewt, and if you touch an array buffer with a host-endian buffer, you can't send it back through a WebSocket without reconversion or something.

[13:52:37.0000] <Jasper>
basically ensure that host endianness is only kept in host memory

[13:52:38.0000] <zewt>
their argument would probably be that games will want to serve big-endian data to big-endian systems, pre-byte-flipped

[13:52:43.0000] <zewt>
that sort of thing

[13:53:23.0000] <Jasper>
zewt, then they will write: if (hostEndianness == "BE") return new Float32ArrayBE(buffer); else ...

[13:53:24.0000] <zewt>
also, you'd want to be able to take XHR data, write it to disk (indexeddb, local files), read it back later and then into webgl

[13:53:34.0000] <zewt>
hard to maintain an "endian tainted" state through all that

[13:53:35.0000] <Jasper>
zewt, as long as you're explicit, you should be fine

[13:53:38.0000] <annevk>
zewt: ArrayBufferView is [NoInterfaceObject]

[13:53:44.0000] <annevk>
zewt: so that seems like a bug in Chrome

[13:54:32.0000] <zcorpan_>
annevk: in other news you failed to convince anyone to remove "DOM" prefix

[13:54:39.0000] <Jasper>
/me wonders if his old WebGL app still crashes Firefox

[13:55:57.0000] <annevk>
zcorpan_: if people are happy with wildly inconsistent naming practices there's not much I can do

[13:56:26.0000] <Jasper>
[16:56:09.713] Error: WebGL: texParameteri: pname 2800 and param 0 (decimal 0) are mutually incompatible

[13:56:32.0000] <Jasper>
huh so it doesn't crash anymore but it errors out

[13:56:46.0000] <Jasper>
chrome seems to enjoy it fine. so that's strange

[13:57:19.0000] <TabAtkins>
While I'm not happy with inconsistency, I *am* happy with it being hard to stomp on the browser-provided names.

[13:58:18.0000] <Jasper>
i always wondered why we didn't just namespace the DOM APIs

[13:58:22.0000] <Jasper>
should we start doing that?

[13:58:30.0000] <Domenic_>
we need modules :(

[13:59:12.0000] <Jasper>
clearly what we want is: new org.w3.canvaswg.canvas.impl.Path();

[14:00:21.0000] <annevk>
o_O

[14:01:20.0000] <Hixie_>
falken: do you still think open() and openModal() is better for <dialog>?

[14:01:50.0000] <Hixie_>
ohhhh, here's another problem with renaming it

[14:02:02.0000] <Hixie_>
if we call it dialog.open(), we can't have the attribute dialog.open

[14:02:07.0000] <zcorpan_>
/me thinks of http://discuss.joelonsoftware.com/?joel.3.219431.12

[14:09:31.0000] <annevk>
Hixie_: so why show? showModalDialog is really something we should not be concerned with imo

[14:09:45.0000] <Hixie_>
well what would you call it instead?

[14:09:54.0000] <annevk>
Hixie_: window.open() / window.close() seems like a better precedent

[14:09:59.0000] <Hixie_>
open() would clash with .open

[14:10:37.0000] <annevk>
show() also clashes with .open in them not having similar names, due to window.open() you might end up being confused all the time which is which

[14:11:07.0000] <annevk>
.state == "open"

[14:11:25.0000] <Domenic_>
there's an [open] attribute though right? so .open property should match... this is a tough one.

[14:11:26.0000] <Hixie_>
that would make the IDL attribute that reflects <dialog open> not match the content attribute's name.

[14:11:48.0000] <Domenic_>
yeah and we know how much people like [value] vs. defaultValue.

[14:11:50.0000] <Hixie_>
note that window.open() creates a new window, dialog.show() doesn't create the dialog, it just shows it.

[14:12:15.0000] <Domenic_>
maybe the attribute should be [shown]

[14:12:19.0000] <annevk>
but dialog[open] selects an open dialog?

[14:12:23.0000] <Hixie_>
then it wouldn't match <details open>

[14:12:27.0000] <Hixie_>
annevk: yes

[14:12:40.0000] <Domenic_>
details is different, it's still shown when it's closed

[14:13:29.0000] <Hixie_>
the contents aren't

[14:14:01.0000] <Domenic_>
sure. but the <details> itself is... kinda sorta... i dunno, it makes sense in my head.

[14:14:49.0000] <annevk>
if you try to match tense though shown doesn't make sense

[14:18:07.0000] <zcorpan_>
<details> is unique with the attribute reflecting the state, iirc

[14:21:38.0000] <Hixie_>
<dialog> does the same thing

[14:22:58.0000] <Jasper>
zcorpan_, http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory

[14:40:34.0000] <Hixie_>
cocoa, .net, delphi, gtk, win32... any other APIs anyone can think of that i should research dialogs in?

[14:45:46.0000] <Philip`>
Hixie_: Android?

[14:45:56.0000] <Hixie_>
was just doign that one

[14:46:12.0000] <Hixie_>
i tried figuring out the x11 api but gave up

[14:48:16.0000] <zewt>
android ui apis D:

[14:50:36.0000] <Jasper>
Hixie_, X11 doesn't have native dialogs.

[14:50:49.0000] <Hixie_>
or windows?

[14:51:07.0000] <Jasper>
Hixie_, does Windows have native checkbox widgets?

[14:51:31.0000] <Jasper>
Hixie_, the Win32 toolkit has a checkbox implementation built on top of the Windows primitives, so it depends on how you count it.

[14:52:12.0000] <Hixie_>
win32 has native checkboxes, sure

[14:52:40.0000] <Jasper>
Right, but Win32 controls is not quite the same as the underlying window-based API.

[14:53:12.0000] <Jasper>
Hixie_, if you're talking about modal dialogs, the primitive you have is spinning the event loop for a different window, where the windowing system will queue up events for all other windows behind you. This allows you to basically build a dialog as a synchronous call.

[14:55:16.0000] <Hixie_>
i don't really mind which layer we want to look at, i'm happy to look at any or all of them :-)

[14:55:33.0000] <Hixie_>
just looking for apis that have "open/close/show/hide"-analogues for windows/dialogs/etc

[14:58:29.0000] <Jasper>
Hixie_, gtk_dialog_run / gtk_window_show are what you want to look at in GTK+

[14:58:54.0000] <Jasper>
Hixie_, X11 allows you to show a window with XMapWindow, and hide with XUnmapWindow

[14:59:19.0000] <Hixie_>
yup, got gtk already

[14:59:26.0000] <Hixie_>
ah, thanks for x11

[15:00:05.0000] <Jasper>
map/unmap is quite old terminology, so it's not what you want to copy.

[15:00:32.0000] <Hixie_>
no kidding :-)

[15:01:05.0000] <Hixie_>
any JS libraries have dialog APIs?

[15:01:14.0000] <Jasper>
ext.js has one I believe.

[15:01:20.0000] <Jasper>
Google Closure Toolkit has another.

[15:01:28.0000] <Hixie_>
jquery seems to have one

[15:01:55.0000] <Jasper>
http://docs.closure-library.googlecode.com/git/class_goog_ui_Dialog.html

[15:02:07.0000] <Hixie_>
woot, jquery has open(). finally found one that uses open().

[15:02:20.0000] <Jasper>
though I'm not sure if Google still uses Closure Toolkit

[15:05:53.0000] <Hixie_>
closure seems to use setVisible(), ew

[15:06:16.0000] <gsnedders>
Hixie_: And a lot of really weird UA sniffing.

[15:12:17.0000] <Hixie_>
 Android uses show() and dismiss()

[15:12:17.0000] <Hixie_>
 Closure uses setVisible()

[15:12:17.0000] <Hixie_>
 Cocoa uses makeKeyAndOrderFront:, orderOut:, close, and performClose:.

[15:12:17.0000] <Hixie_>
 Delphi uses Show(), ShowModal(), Hide(), and Close().

[15:12:17.0000] <Hixie_>
 Ext JS uses show(), hide(), and close().

[15:12:19.0000] <Hixie_>
 jQuery uses "open" and "close".

[15:12:21.0000] <Hixie_>
 Gtk uses gtk_widget_show(), gtk_dialog_run(), gtk_window_close().

[15:12:24.0000] <Hixie_>
 .NET uses Show(), ShowDialog(), Hide(), and Close().

[15:12:26.0000] <Hixie_>
 Win32 uses ShowWindow() and CloseWindow().

[15:12:29.0000] <Hixie_>
 X11 uses XMapWindow() and XUnmapWindow()

[15:12:35.0000] <Hixie_>
any others i should look at?

[15:15:43.0000] <Hixie_>
ok, sending e-mail.

[15:34:21.0000] <crocket>
Is there a channel for W3C?

[15:34:27.0000] <crocket>
#w3c is not the one.

[15:34:41.0000] <jsbell>
crocket: any specific part?

[15:34:49.0000] <crocket>
just w3c

[15:34:54.0000] <crocket>
W3C consortium

[15:36:30.0000] <TabAtkins>
You want irc.w3.org

[15:36:40.0000] <jsbell>
crocket: http://www.w3.org/Project/IRC/ may be useful

[15:37:56.0000] <crocket>
They left freenode.

[15:38:54.0000] <crocket>
Does HTML5 define browser object model?

[15:39:29.0000] <Hixie_>
kind of

[15:39:35.0000] <Hixie_>
depends on what you mean by that

[15:40:07.0000] <Hixie_>
http://dom.spec.whatwg.org/ may be what you mean, or http://whatwg.org/html#document maybe

[15:41:20.0000] <crocket>
Hixie_: BOM isn't DOM.

[15:41:26.0000] <Hixie_>
not sure what you mean then

[15:41:29.0000] <Hixie_>
can you elaborate?

[15:42:09.0000] <Hixie_>
GPHemsley: you still working on mimesniff?

[15:42:29.0000] <Hixie_>
GPHemsley: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0276.html

[15:43:07.0000] <crocket>
Hixie_: DOM == document

[15:43:11.0000] <crocket>
BOM == a subset of window

[15:43:27.0000] <Hixie_>
http://whatwg.org/html#window ?

[15:43:27.0000] <gsnedders>
crocket: The Window interface is in HTML

[15:43:54.0000] <crocket>
Does HTML5 define the entirety of BOM?

[15:44:05.0000] <Hixie_>
i don't know what BOM is exactly, so i can't say

[15:44:25.0000] <Hixie_>
describe the entirety of it, and I'll tell you whether any of it is missing :-)

[15:45:48.0000] <crocket>
Hixie_: "Object oriented javascript", a book, defines BOM as "The Browser Object Model (BOM) is a collection of objects that give you access to the browser and the computer screen. These objects are accessible through the global object window."

[15:46:19.0000] <Hixie_>
ah, then no, that's not all in HTML. There's also a bunch of it in CSSOM, CSSOM Views, and various other specs.

[15:46:57.0000] <crocket>
CSSOM?

[15:47:02.0000] <Hixie_>
CSS Object Model

[15:47:10.0000] <Hixie_>
CSS is Cascading Stylesheets

[15:47:22.0000] <crocket>
How does CSS define it?

[15:47:28.0000] <Hixie_>
http://dev.w3.org/csswg/cssom/

[15:47:41.0000] <Hixie_>
and http://dev.w3.org/csswg/cssom-view/

[15:47:44.0000] <crocket>
Does CSS have any API accessible from javascript?

[15:47:52.0000] <Hixie_>
those two specs define that api

[15:58:10.0000] <Domenic_>
Hixie_: I think the most important thing is consistency between the attribute/property and the method name. (Assume the attribute and property are the same; anything else is insanity) If the method changes the attribute, it should be connected.

[15:58:41.0000] <Domenic_>
Hixie_: thus I feel like show() + open is not so good. show() + shown is good. Maybe open() + isOpen/opened or similar

[16:00:30.0000] <Hixie_>
"isopen" reads like "iso pen". "opened" is past tense, which is inconsistent with basically everything.

[16:01:07.0000] <Domenic_>
yeah not sure there's any good answers

[16:01:17.0000] <Domenic_>
for a counterpart to open() at least

[16:01:19.0000] <Hixie_>
i don't think it's a problem to have .show() set .open to true. it's not that confusing.

[16:01:32.0000] <Domenic_>
isindex reads let isin dex? :P

[16:01:37.0000] <Domenic_>
i think that's pretty confusing

[16:01:40.0000] <Domenic_>
is it open or is it shown?

[16:01:53.0000] <Domenic_>
what's the difference?

[16:01:58.0000] <Hixie_>
"isin" and "dex" aren't words

[16:02:07.0000] <Hixie_>
when you open the dialog, it is shown

[16:02:15.0000] <Hixie_>
when you show the dialog, it opens

[16:02:16.0000] <Domenic_>
but it's not open?

[16:02:17.0000] <Hixie_>
it's fine

[16:02:37.0000] <Domenic_>
meh. i disagree it's fine. but that's my 2cents, not much more to say.

[16:03:04.0000] <Hixie_>
i think in practice people won't use open="" much anyway

[16:03:12.0000] <Hixie_>
so it won't be an issue even if people are confused by it

[16:03:13.0000] <Hixie_>
bbiab

[16:03:34.0000] <Domenic_>
People will use it in CSS a lot I think

[16:04:09.0000] <Domenic_>
transitions/animations between dialog:not([open]) and dialog[open]

[16:05:44.0000] <crocket>
Hixie_: Do you think BOM is split between HTML and CSS?

[16:07:22.0000] <Domenic_>
crocket: BOM is just something the author of that book made up; it is not a real concept

[16:07:30.0000] <Domenic_>
it has no meaning in terms of implementations or specs

[16:07:34.0000] <crocket>
Domenic_: What the hell

[16:08:05.0000] <Domenic_>
I know, bad book, right?

[16:09:49.0000] <crocket>
Domenic_: not sure it's a bad book

[16:12:42.0000] <Domenic_>
i dunno, maybe just the number of recruiters using the term "object oriented javascript" has given it bad associations in my mind.

[16:13:48.0000] <crocket>
Domenic_: you mean employers?

[16:14:17.0000] <crocket>
Domenic_: object orientation in smalltalk is a good thing.

[16:14:30.0000] <jarek>
are you talking about "Object Oriented JavaScript" by Zakas?

[16:14:45.0000] <jarek>
it's terrible book by todays standards

[16:15:17.0000] <jarek>
I would rather stick with the terms in the spec, even if they are confusing

[16:16:31.0000] <crocket>
jarek: I mean http://www.amazon.com/Object-Oriented-JavaScript-Edition-Stoyan-Stefanov/dp/1849693129/ref=sr_1_1?ie=UTF8&qid=1380237353&sr=8-1&keywords=object+oriented+javascript

[16:16:51.0000] <crocket>
Authors sent an early draft of the book, and it was published without correction.

[16:16:58.0000] <crocket>
So code examples aren't indented at all!!!

[16:17:03.0000] <jarek>
crocket: ahh, that's the best JS book for beginners I have read

[16:17:03.0000] <crocket>
But overall, its content is fine.

[16:17:17.0000] <crocket>
jarek: How many JS books have you read?

[16:17:45.0000] <jarek>
crocket: I read Crockford, Zakas and few others

[16:18:27.0000] <crocket>
How about "JavaScript: The Good Parts"?

[16:19:04.0000] <jarek>
crocket: it feels more like an academic paper than a book :P

[16:19:56.0000] <crocket>
jarek: Does it teach how to avoid bad parts?

[16:20:17.0000] <jarek>
crocket: yes, I guess it was the first book to teach JS the right way

[16:20:32.0000] <crocket>
So far, I've read elequent javascript, and I'm reading object oriented javascript.

[16:21:50.0000] <jarek>
crocket: if I were to learn JS now, I wouldn't bother reading more than one book

[16:22:03.0000] <jarek>
crocket: the most valuable information is on the web now

[16:22:08.0000] <crocket>
What is the one book?

[16:22:11.0000] <jarek>
crocket: e.g. check http://killdream.github.io/2011/10/09/understanding-javascript-oop.html

[16:22:25.0000] <jarek>
there is no book that would discuss JS object system in such detail ^

[16:22:50.0000] <jarek>
crocket: I would pick Stefanov

[16:23:12.0000] <jarek>
crocket: Eloquent JS seems to be biased towards functional programming

[16:23:37.0000] <crocket>
jarek: functional programming was good.

[16:23:43.0000] <crocket>
Stefanov?

[16:24:07.0000] <jarek>
crocket: yeah, the one you have linked earlier

[16:24:16.0000] <crocket>
object oriented javascript?

[16:24:59.0000] <jarek>
crocket: yes, though if you are already experienced programmer (in other language) then I would jump right into Crockford

[16:25:17.0000] <crocket>
jarek: I'm confused.

[16:25:29.0000] <crocket>
Referring to books by authors is confusing.

[16:25:51.0000] <crocket>
I don't remember author names.

[16:26:03.0000] <jarek>
crocket: I don't remember book names :P

[16:26:17.0000] <jarek>
crocket: Crockford == JS Good parts (or something like this)

[16:26:29.0000] <jarek>
I mean ===

[16:26:39.0000] <crocket>
jarek: One author could have written various books.

[16:27:19.0000] <jarek>
crocket: several authors could have written books with the same title

[16:27:39.0000] <Philip`>
All you need to remember is the ISBN


2013-09-27
[18:07:27.0000] <Domenic_>
crocket: no I mean recruiters. "HTML5/CSS3, Object oriented JavaScript, and jQuery experience preferred."

[18:08:32.0000] <zewt>
heh, well, being able to use JS in an OO-fashion is actually probably a pretty decent metric of someone who can actually write sensible JS

[20:48:23.0000] <crocket>
zewt, not very

[20:48:47.0000] <crocket>
A recruiter has to actually read codes.

[20:48:53.0000] <crocket>
A recruiter has to actually read codes written by applicants.

[21:25:02.0000] <zewt>
(that doesn't seem to have anything to do with what I said)

[03:21:52.0000] <jgraham>
anyone know anything about http://w3c-test.org/web-platform-tests/master/eventsource/eventsource-cross-origin.htm ?

[03:24:50.0000] <Ms2ger>
Mmm

[03:24:54.0000] <Ms2ger>
Blame says you

[03:25:12.0000] <Ms2ger>
The <--/*--> hack says zcorpan

[03:27:36.0000] <jgraham>
It wasn't me!

[03:28:41.0000] <zcorpan>
i don't see <!--/*--> there

[03:29:03.0000] <zcorpan>
but i think odinho wrote the eventsource+cors tests

[03:29:08.0000] <Ms2ger>
Oh

[03:29:15.0000] <zcorpan>
and annevk wrote the initial set of eventsource tests

[03:29:17.0000] <Ms2ger>
That was in another file

[03:29:37.0000] <zcorpan>
ondinho might have copied my hack for all i know :-)

[03:31:24.0000] <zcorpan>
i have probably reviewed the eventsource tests so i might know something about them. what's the question?

[03:33:22.0000] <jgraham>
The second test always times out afaict

[03:33:30.0000] <jgraham>
Any idea why?

[03:33:59.0000] <jgraham>
I mean, is it a broken test or a correct test that doesn't match implementations

[04:14:44.0000] <zcorpan>
jgraham: the test seems correct from what i can tell. "HTTP 301 Moved Permanently, 302 Found, 303 See Other, and 307 Temporary Redirect responses are handled by the fetching and CORS algorithms." http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#processing-model-7

[04:15:43.0000] <zcorpan>
but i don't have the cors stuff paged in

[04:17:53.0000] <jgraham>
So

[04:18:28.0000] <jgraham>
Chrome and Firefox fail "EventSource: cross-origin redirect use"

[04:18:56.0000] <zcorpan>
hmm, i think the redirect script needs CORS headers for the redirect to succeed

[04:19:27.0000] <jgraham>
Opera 12 and Firefox fail "EventSource: cross-origin redirect use recon" on localhost, but not on w3c-test.org

[04:19:40.0000] <jgraham>
Chrome passes

[04:20:38.0000] <jgraham>
I can't tell if this is because I have broken things in my conversion, but they utterly refuse to send cookies with the cross-origin event source request

[04:20:44.0000] <jgraham>
(on localhost)

[04:20:59.0000] <Ms2ger>
r? https://critic.hoppipolla.co.uk/r/208

[04:21:04.0000] <zcorpan>
but message.php also doesn't use CORS headers, which it should have i think

[04:21:16.0000] <zcorpan>
i'll ask odin

[04:21:32.0000] <jgraham>
cors.php adds CORS headers to everything

[04:21:50.0000] <jgraham>
So maybe it should redirect to cors.php with message as the handler?

[04:22:11.0000] <zcorpan>
aha

[04:22:16.0000] <zcorpan>
that's the thing

[04:22:31.0000] <jgraham>
Oh and Opera doesn't show Event Source in the network tab

[04:22:32.0000] <zcorpan>
the redirect works, but message.php fails the cors check

[04:22:44.0000] <zcorpan>
so the test is broken

[04:22:47.0000] <jgraham>
and Firefox won't let me copy the response

[04:25:05.0000] <jgraham>
zcorpan: OK, fixed that test

[04:25:09.0000] <jgraham>
One left

[04:26:50.0000] <zcorpan>
Ms2ger: btw it seems i wrote the eventsource+worker tests

[04:28:46.0000] <jgraham>
Is there anything special I should know wrt CORS and cookies on localhost or non-default ports? I don't see anything, but I am not a CORS expert

[04:29:33.0000] <jgraham>
Oh awesome, the test works on reload in Opera

[04:29:43.0000] <jgraham>
So there is obviously something stateful there

[04:30:20.0000] <Oliver_>
Hi

[04:32:35.0000] <MikeSmith>
I don't think /win 21

[04:32:40.0000] <MikeSmith>
oofs

[04:33:50.0000] <jgraham>
Was that "oofs" the "Descartes pop" as MikeSmith vanished?

[04:37:14.0000] <MikeSmith>
heheh

[04:50:47.0000] <darobin>
Descartes pop?

[04:52:32.0000] <MikeSmith>
those were actually my Kirby krackle

[05:02:30.0000] <MikeSmith>
in the "why o god why" department, on a chance visit to #developers to offer my condolences to bz on becoming a W3C editor, I discover that virtualbox is using xpcom

[05:02:56.0000] <MikeSmith>
proof that mental illness is contagious?

[05:11:56.0000] <MikeSmith>
oh god a "srcN attribute"

[05:12:09.0000] <MikeSmith>
(speaking of mental illness)

[05:12:37.0000] <MikeSmith>
sorry I meant to write, What a great idea!!

[05:14:13.0000] <MikeSmith>
I want whatever hippy crack all the responsive images folks are smoking

[05:23:48.0000] <Ms2ger>
Ask TabAtkins :)

[05:27:18.0000] <jgraham>
Yeah, numbered attributes are kind of ugly

[05:27:34.0000] <jgraham>
Makes you wish HTML had more than just string types really

[05:28:16.0000] <Ms2ger>
I should deal with those File API tests

[05:29:39.0000] <zcorpan>
TabAtkins: is www-style the right list for the respimg proposal?

[05:30:38.0000] <Ms2ger>
Didn't they hide in a CG with its own ML?

[05:37:02.0000] <zcorpan>
there's a separate mailing list, but tab's draft says to send feedback to www-style

[05:37:49.0000] <jgraham>
Yeah, but it also seems rather likely to just be because all his other drafts say that

[05:44:29.0000] <MikeSmith>
I don't think we'd be able to implement microsyntax checking of srcN values without some ugly hack

[05:46:02.0000] <darobin>
yeah, I don't reckon that www-style is the right place, I reckon TabAtkins just pasted his usual Bikeshed empty draft or whatever

[05:47:34.0000] <MikeSmith>
I think what we'd need to do is to add a filter that changes all the srcN attributes in memory to some other arbitrary single attribute name to which we could actually bind some syntax-checking. I think I'd go with "TabAtkins" is that attribute name. Either that or "xpcom".

[05:49:42.0000] <darobin>
/me wonders why MikeSmith would have to do that...

[05:49:49.0000] <zcorpan>
/me too

[05:50:57.0000] <jgraham>
Presumably because the code assumes that each microsyntax is bound to a finite set of attributes

[05:52:46.0000] <MikeSmith>
because the validator backend by default considers any attribute invalid unless it's explicitly told that it's valid

[05:53:18.0000] <darobin>
ah

[05:53:26.0000] <MikeSmith>
and there is no way to tell that core part of the validator that a pattern or wildcard for an attribute name is valid

[05:53:47.0000] <darobin>
but since you're going to have to add support for matching on patterns for the hyphen-attributes anyway, you can also do src\d+ at the same time

[05:53:51.0000] <darobin>
/me giggles and hides

[05:53:55.0000] <MikeSmith>
so if as src1000 attribute is exposed to that part of the validator as-is, it will emit an error

[05:54:00.0000] <MikeSmith>
hah

[05:54:32.0000] <darobin>
how do you handle data-*?

[05:55:00.0000] <MikeSmith>
well in the case of hyphen-attributes there are many more reasons what that's plainly a bad idea that have nothing to do with the validator

[05:57:01.0000] <darobin>
yeah yeah, but how do you have data-*? does the same trick not work with srcN?

[05:57:03.0000] <MikeSmith>
darobin: I'll send a reply on the list but as far as validation, consider what happens when an author misttypes aria-described-by as aria-descibes-by

[05:57:35.0000] <darobin>
MikeSmith: I was thinking it would be more of a problem if the author mistyped aira-described-by

[05:57:36.0000] <MikeSmith>
I'm pretty sure we just completely drop the data-* attributes and don't do any checking on their values

[05:57:53.0000] <MikeSmith>
expect that the parser checks the values for parse errors

[05:57:56.0000] <darobin>
since I'd expect the validator to look at the prefix of attributes it knows about

[05:58:09.0000] <darobin>
ah, so you drop them before, makes sense

[05:58:26.0000] <darobin>
/me looks forward to the TabAtkins attribute then

[05:59:24.0000] <MikeSmith>
darobin: the validator does not have any concept of what a prefix is

[05:59:43.0000] <darobin>
MikeSmith: I'd guess, but that's a SMOP :)

[05:59:49.0000] <MikeSmith>
it only understands explicit names

[05:59:58.0000] <MikeSmith>
darobin: sure

[06:01:36.0000] <MikeSmith>
but like most SMOP it would simple only to the people who don't have to SMOP it and maintain it

[06:36:24.0000] <GPHemsley>
Hixie_: I was discussing the issue with bz off-list at the time. (Mozila IRC, IIRC.)

[06:37:00.0000] <GPHemsley>
Hixie_: As I told him then, I was waiting for others to respond before I said/did anything. The main problem with mimesniff is that no one pays any attention to it.

[06:37:43.0000] <GPHemsley>
Hixie_: I never get any feedback from anybody unless I specifically go and request it (or else do something that offends someone's sensibilities wrt spec writing).

[06:39:43.0000] <hallvors>
Hixie_: if you've got a moment, comments on https://bugzilla.mozilla.org/show_bug.cgi?id=881072#c44 would be welcome.. (Sorry to interrupt, GPHemsley)

[06:39:57.0000] <GPHemsley>
hallvors: No worries. I imagine Hixie_ is sleeping anyway.

[06:41:59.0000] <hallvors>
You mean you're trying to interfere with his dreams, asking questions on IRC? Do spec writers dream in chat channels? ;-)

[06:42:22.0000] <GPHemsley>
I think Hixie_ dreams in cat channels

[06:45:26.0000] <jgraham>
hallvors: !

[06:45:49.0000] <jgraham>
Did the cors tests ever work properly? Do you in fact know about those or only the XHR ones?

[06:47:18.0000] <hallvors>
jgraham: haven't looked much at the CORS tests (but there are a handful of CORS tests in the XHR suite now)

[06:48:06.0000] <jgraham>
hallvors: I remember you poking at getting cors headers working on w3c-test.org

[06:48:38.0000] <hallvors>
yes, but that was probably to get the XHR suite working :-p

[06:49:08.0000] <jgraham>
Oh, OK

[06:49:22.0000] <hallvors>
who worked on the CORS suite? Odin?

[06:49:28.0000] <jgraham>
/me wonders what PHP does if you send it mutliple request headers with the same name

[06:49:32.0000] <jgraham>
hallvors: Yeah

[06:49:38.0000] <jgraham>
He is MIA though

[06:49:51.0000] <jgraham>
Or at least not in the channel, which is more or less the same thing

[06:51:27.0000] <jgraham>
(the documentation doesn't say. It doesn't even say that all headers end up in $_SERVER)

[07:16:18.0000] <annevk>
hallvors: I recommend getting zcorpan to look at https://bugzilla.mozilla.org/show_bug.cgi?id=881072#c44

[07:19:13.0000] <annevk>
hallvors: in any event, stable states are provided all the time

[07:19:48.0000] <hallvors>
I would expect a "stable state" after parsing and before DOMContentLoaded

[07:20:22.0000] <hallvors>
(and I would expect the "synchronous parts" of the resource selection to run when the implementation reaches the *first* stable state)

[07:20:56.0000] <hallvors>
- so why doesn't that seem to happen in the Webkit - based browsers?

[07:26:40.0000] <jgraham>
You get a stable state after each event on the event loop afaict

[07:30:18.0000] <annevk>
hallvors: you get "stable state" before </script> too, and during each task in the event loop it seems

[07:30:42.0000] <annevk>
hallvors: and a number of other places, load the full page spec and click "provide a stable state" to find the various places

[07:32:22.0000] <hallvors>
right - makes those other browsers' behaviour seem even weirder.. :-/

[07:32:25.0000] <jgraham>
Oh, so sending a HTTPS request to a non-https server doesn't work so well

[07:33:02.0000] <annevk>
jgraham: Firefox blocks "intranet" stuff with CORS as well

[07:33:56.0000] <jgraham>
annevk: So localhost doesn't work?

[07:35:37.0000] <annevk>
jgraham: might not I suppose, sicking gave some details once long ago

[07:35:56.0000] <jgraham>
OK

[07:36:08.0000] <jgraham>
Well it would be consistent with my observations I guess

[07:36:34.0000] <jgraham>
On the other hand, so would "there is a vindictive God who is out to ruin my day"

[07:36:50.0000] <jgraham>
So I don't think that my observations in isolation can prove much

[07:38:54.0000] <Ms2ger>
/me denies being that vindictive God

[07:40:03.0000] <annevk>
jgraham: if there's nothing logged in console that might be worth complaining about

[08:39:00.0000] <Domenic_>
annevk: http://w3cmemes.tumblr.com/post/49409867666/and-if-you-dont-have-an-api-you-might-as-well-set

[08:44:04.0000] <annevk>
Domenic_: given the super long reply I think this argument is over

[08:44:30.0000] <Domenic_>
annevk: as in, he's made up his mind and not going to change it?

[08:44:57.0000] <annevk>
Domenic_: combined with the fact that he's not gonna decide what lands in browsers, yes

[08:45:41.0000] <Domenic_>
he seems open to adding both

[08:46:07.0000] <Domenic_>
maybe get both in and then later, feedback comes in that the events are redundant and error-prone.

[08:46:34.0000] <annevk>
I'd rather not waste precious engineering and specification writing time on an exercise in futility

[08:46:42.0000] <Domenic_>
sounds good

[09:16:04.0000] <jgraham>
annevk: Looks like you were right

[10:37:52.0000] <TabAtkins>
zcorpan: If possible, send feedback to the respimg cg.

[10:38:11.0000] <TabAtkins>
It is indeed a failure of bikeshed at the moment that it always says to send feedback to www-style.

[10:40:05.0000] <TabAtkins>
MikeSmith: Hey, it's either separate attrs (numbered for uniqueness+ordering), separate elements (implementors hate them), or a big mashed together syntax with 5 levels of separator characters.

[10:40:44.0000] <astearns>
that last one sounds intriguing :)

[11:16:13.0000] <Hixie_>
hallvors: re https://bugzilla.mozilla.org/show_bug.cgi?id=881072#c44 - which test case are we talking about?

[11:20:44.0000] <Ms2ger>
Hixie_, https://bug881072.bugzilla.mozilla.org/attachment.cgi?id=803768 ?

[11:31:12.0000] <Hixie_>
oh duh

[11:31:20.0000] <Hixie_>
my brain totally ignored the grayed out stuff

[11:44:22.0000] <Ms2ger>
http://lists.w3.org/Archives/Public/public-test-infra/2013JulSep/0272.html

[11:44:23.0000] <Ms2ger>
Wut

[11:45:01.0000] <miketaylr>
E N E R G I Z E

[12:02:03.0000] <annevk>
Hixie_: thanks for adding a comment there

[12:02:24.0000] <Hixie_>
np

[12:26:01.0000] <hallvors>
Hixie_: +1 thanks - now, I guess the harder part is to get WebKit devs to fix the bug and break vine.co and video.js like Mozilla does :-p

[12:44:31.0000] <TabAtkins>
annevk, Domenic_: What's the super-long argument about?

[12:45:08.0000] <annevk>
TabAtkins: public-webapps thread on whether or not to use promises for something

[12:45:16.0000] <annevk>
TabAtkins: it wasn't super long

[12:45:41.0000] <Domenic_>
thread wasn't, but the message saying "no events are better" was pretty long.

[12:50:45.0000] <dglazkov>
fwiw, there aren't any events in Web Components specs defined so far.

[12:50:54.0000] <dglazkov>
I should respond to this thread, I guess

[13:08:28.0000] <annevk>
Domenic_: if something is enumerable and visible to for-in, does that mean you can also test for it using "in"?

[13:09:07.0000] <Domenic_>
annevk: "in" always works, enumerable doesn't matter for that

[13:09:36.0000] <annevk>
Domenic_: aight

[13:11:55.0000] <annevk>
It seems symbols are better for e.g. HTMLCollection:

[13:12:01.0000] <annevk>
<div id=@iterator></div>

[13:12:01.0000] <annevk>
<script>alert(document.getElementsByTagName("div")["@iterator"])</script>

[13:12:43.0000] <Domenic_>
good one, use that

[13:12:47.0000] <Domenic_>
except, functions

[13:13:16.0000] <Domenic_>
counterexamples work better when you can manage to create a spurious @iterator function

[13:13:58.0000] <annevk>
how would that work better?

[13:15:57.0000] <Domenic_>
because then it's a real hazard, concretely demonstrating that "@iterator" the string will screw things up

[13:16:24.0000] <Domenic_>
if it's not a function, he can just argue that the test for iterability (or any similar protocol) should be "@iterator" in obj && typeof obj["@iterator"] === "function"

[13:18:07.0000] <annevk>
oh my point is that we want to make HTMLCollection iterable

[13:19:47.0000] <Domenic_>
ah right that makes sense, pages could break iterability with such an element.

[13:39:25.0000] <annevk>
Hixie_: why is transferring not inlined with structured cloning?

[13:39:41.0000] <Hixie_>
it used to be separate

[13:39:56.0000] <Hixie_>
like, unrelated

[13:40:05.0000] <annevk>
Hixie_: structured cloning is abstracted at the top of the spec, but then postMessage() details transferring around it

[13:40:07.0000] <annevk>
Hixie_: k

[13:40:21.0000] <Hixie_>
i should probably clean it up but i have much bigger fish to fry right now

[13:40:27.0000] <Hixie_>
same reason i haven't deferred to fetch yet

[13:40:40.0000] <annevk>
Hixie_: I'm trying to get TC39 to take over structured cloning

[13:40:45.0000] <annevk>
Hixie_: so don't worry too much about it

[13:44:34.0000] <hober>
/me is looking forward to structured clone handling Map & Set

[13:46:16.0000] <annevk>
Hixie_: also don't worry too much about Fetch

[13:46:28.0000] <Hixie_>
k

[13:46:35.0000] <annevk>
Hixie_: I'm going to land it for XMLHttpRequest first as a guinea pig, and there's a couple of things I need to change for that

[13:46:40.0000] <Hixie_>
lgtm

[14:30:58.0000] <annevk>
Hixie_: you can neuter a Blob via Blob.close(), but then it can still be cloned, is that useful?

[14:31:17.0000] <Hixie_>
you can't clone neutered things, by definiton

[14:31:19.0000] <Hixie_>
definition

[14:31:21.0000] <Hixie_>
no?

[14:33:23.0000] <Hixie_>
hm, i guess the check of whether a neutered thing can be cloned is done each time by the cloning steps for that thing

[14:33:31.0000] <Hixie_>
maybe the blob cloning steps are missing that?

[14:35:46.0000] <annevk>
yeah, prolly because a Blob is not neutered as side-effect of being transfered, it's a distinct operation

[14:36:11.0000] <annevk>
(Blob always clone and don't transfer, as they're readonly)

[14:36:24.0000] <Hixie_>
oh then the neutering is something else entirely

[14:36:31.0000] <Hixie_>
i thought you meant "neuter" in the trasfer sense

[14:37:36.0000] <Hixie_>
createImageBitmap() throws InvalidStateError if a Blob "has been neutered through the close method"

[14:37:52.0000] <Hixie_>
i would be happy to add the same clause to the structured clone stuff

[14:37:58.0000] <Hixie_>
if you think we should

[14:37:59.0000] <Hixie_>
file a bug

[14:38:22.0000] <annevk>
File API uses the same definition of neutering so I guess

[14:39:39.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23385

[14:40:29.0000] <Hixie_>
same definition as what?

[14:40:42.0000] <Hixie_>
i don't understand the second part of that bug

[14:41:55.0000] <annevk>
I.e. as step 2 of the internal structured cloning algorithm have "if input is neutered, throw ..."

[14:46:18.0000] <Hixie_>
annevk: you can't get that far if an input is neutered in the transfer sense.

[14:46:35.0000] <Hixie_>
annevk: and blob shouldn't be using the transfer sense if it's no transferable.

[14:46:53.0000] <annevk>
Hixie_: why does ArrayBuffer do the check there?

[14:47:45.0000] <Hixie_>
interesting question

[14:48:24.0000] <Hixie_>
that entire entry shouldn't be there

[14:48:28.0000] <Hixie_>
it'll never get invoked

[14:48:31.0000] <annevk>
Hixie_: I think it's because it's recursive

[14:48:47.0000] <annevk>
Hixie_: and ArrayBuffer can be cloned as well as transfered

[14:48:54.0000] <Hixie_>
oh, oh, right.

[14:48:56.0000] <Hixie_>
that's why.

[14:49:10.0000] <Hixie_>
it's because you can clone as well as transfer.

[14:49:54.0000] <Hixie_>
anyway. you can't transfer a blob. so it shouldn't use the transfer notion of 'neuter'.

[14:50:02.0000] <Hixie_>
it can have its own notion of neutering

[14:50:18.0000] <annevk>
and although Blob cannot be in the transferMap, it can be neutered so just checking for neutering there makes sense

[14:50:18.0000] <annevk>
mah

[14:50:18.0000] <Hixie_>
but it's unrelated to transfering.

[14:50:19.0000] <annevk>
I suppose

[14:50:35.0000] <Hixie_>
just like if it had a computed value, it wouldn't be the CSS sense of "computed value"

[15:39:48.0000] <jamesr__>
/me would appreciate if y'all parser folks would take a look at his recent whatwg@ email

[15:42:01.0000] <jamesr__>
it's possible that there is more magic in some of these algorithms that mean my proposal isn't an actual change in behavior, but if so then i think my proposed text will be a lot easier to understand

[15:54:19.0000] <annevk>
Domenic_: man I hope it's not that complicated

[15:54:25.0000] <annevk>
Domenic_: /tc39 should just be community space

[15:55:30.0000] <Domenic_>
annevk: hmm dunno that feels weird, seems like it should have some air of legitimacy at least...

[15:55:46.0000] <Domenic_>
I think it's really about GitHub's access model though, i.e. can i edit something in the tc39 org without being in the tc39 org.

[15:55:52.0000] <Domenic_>
Pretty sure I can.

[15:57:02.0000] <annevk>
Well if you need to pay in order to be legit, I don't think it's good for the web


2013-09-28
[19:10:45.0000] <ericandrewlewis>
I notice the example on the WHATWG for asides uses h1's in nearly every structural element - http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-aside-element

[19:11:17.0000] <ericandrewlewis>
if that blogroll had 15 articles shown per page, that would make about 20 h1 elements on a page

[19:11:58.0000] <ericandrewlewis>
is that "fine"?

[19:13:04.0000] <ericandrewlewis>
that kinda goes against what is said here - https://www.youtube.com/watch?v=GIn5qJKU8VM

[20:58:00.0000] <Hixie_>
ericandrewlewis: matt's response is talking about pages that don't use sectioning elements

[20:58:25.0000] <ericandrewlewis>
ah, that makes more sense.

[20:58:41.0000] <Hixie_>
(his post is from 2009, when those elements were still very new)

[20:59:01.0000] <ericandrewlewis>
so we're officially over the "one h1 on a page" thang

[21:09:27.0000] <Hixie_>
"officialy"?

[21:09:36.0000] <Hixie_>
"officially" even

[22:54:10.0000] <annevk_>
FWIW: http://wiki.ecmascript.org/doku.php?id=strawman:structured_clone

[13:06:39.0000] <sedovsek>
Hey. What's the W3C state on CSS Reflection? Are there any standardized ways to achieve it?

[13:07:17.0000] <sedovsek>
I'm only aware of webkit-box-reflect - which is unofficial…

[13:49:34.0000] <TabAtkins>
-webkit-box-reflect is terribad, and it'll never be standardized.  It shows up with anomolously high usage stats in Blink's use tracker, but once we figure out what's wrong with that, we plan to kill it.

[13:50:10.0000] <TabAtkins>
sedovsek: If you want to achieve that effect, combine ::before/::after with element() and 'mask'.


2013-09-29
[20:58:08.0000] <crocket>
Will browser vendors implement native sockets in their web browsers?

[20:58:15.0000] <crocket>
WebSocket is not a native socket.

[21:28:27.0000] <crocket>
Oh, chrome supports an experimental TCP/UDP socket API.

[01:11:41.0000] <MikeSmith>
TabAtkins: for responsive images I thought the proposed algorithm that p0rnel came up with was possibily some progress toward getting implementor support for separate elements

[02:56:59.0000] <MikeSmith>
TabAtkins: plus I don't think think most people would consider the syntax of <img src1="100% 640 50% 960 33%; xxs.jpg 160, xs.jpg 320, s.jpg 480, m.jpg 640, l.jpg 960, xl.jpg 1280, xxl.jpg 1920"> to be a huge improvement over srcset syntax

[06:18:18.0000] <MikeSmith>
so I see it looks like IDNA 2008 support will be landing in Blink soon

[06:18:27.0000] <MikeSmith>
along with TR46

[08:02:10.0000] <annevk>
MikeSmith: seems it landed per https://codereview.chromium.org/23642003

[08:02:53.0000] <annevk>
The exact algorithm is still a bit unclear to me and it seems they want to tweak it further still :/

[08:26:06.0000] <MikeSmith>
annevk: ok

[08:27:30.0000] <MikeSmith>
anyway, with that and the comments in the mozilla bug, seems likes the wind is blowing in the IDNA 2008 direction now

[08:27:36.0000] <MikeSmith>
for better or worse

[08:30:07.0000] <MikeSmith>
annevk: btw I was watching the video about offline at Edge and when it got to a certain part Nao overheard it and said, "Who just said 'bullshit'?" and I said, "Take a guess".

[08:30:20.0000] <MikeSmith>
so congrats on that

[08:30:42.0000] <annevk>
heh

[09:42:50.0000] <MikeSmith>
about https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c48 "Browsing contexts don't have origins.", doesn't window.location contain an origin?

[13:31:27.0000] <zcorpan>
MikeSmith: window.location isn't a browsing context...

[16:18:50.0000] <cabanier>
MikeSmith: ping

[16:52:12.0000] <cabanier>
Hixie_: ping


2013-09-30
[18:38:56.0000] <cabanier>
Hixie_: what can you tell me about the history of hit regions in canvas?

[19:13:28.0000] <MikeSmith>
cabanier: here now

[19:37:21.0000] <zewt>
grr @ sites that try to keep you from f5-refreshing forcing me to focus the address bar first (twitter)

[19:37:45.0000] <zewt>
very not understanding browsers allowing pages to preventDefault browser hotkeys

[20:07:50.0000] <cabanier>
MikeSmith: things are getting confusing with hit regions

[20:08:24.0000] <cabanier>
MikeSmith: I'm not sure where to go from here

[20:09:14.0000] <MikeSmith>
cabanier: me neither

[20:09:38.0000] <MikeSmith>
and now it appears Rich is going to be on vacation for quite some time

[20:09:54.0000] <cabanier>
MikeSmith: yes. I was hoping someone else could chime in

[20:10:26.0000] <MikeSmith>
I think at this point what's most important is what you and Dominic have to say

[20:10:42.0000] <cabanier>
MikeSmith: Well, I implemented what the spec said

[20:11:13.0000] <cabanier>
MikeSmith: I don't know enough about accessibility to know if it's useful

[20:11:30.0000] <MikeSmith>
well, Dominic does for sure

[20:12:00.0000] <cabanier>
If it's just the API call, that's relatively easy to change

[20:13:07.0000] <cabanier>
I was trying to find more history but I could only find a posting from 2011 where they split the calls

[20:13:25.0000] <cabanier>
It sounds like Hixie wanted that split

[20:13:46.0000] <MikeSmith>
that sounds vaguely familiar

[20:13:47.0000] <cabanier>
There was also a blog post from Steve Faulkner

[20:14:06.0000] <cabanier>
I tried to ping him to see if he remembers

[20:14:09.0000] <MikeSmith>
Steve may remember more of the history at this point

[20:14:26.0000] <cabanier>
he's probably asleep now

[20:14:45.0000] <MikeSmith>
yeah

[20:15:02.0000] <MikeSmith>
there's this guy Charles Pritchard who was involved somewhat

[20:15:07.0000] <MikeSmith>
dunno where he is now

[20:15:36.0000] <cabanier>
I found some posts from him as well, but it sounds like he wanted some sort of DOM

[20:15:37.0000] <MikeSmith>
or whether it's be worthwhile to ask him about the background

[20:15:41.0000] <MikeSmith>
yeah

[20:16:57.0000] <MikeSmith>
from what I recall there were a lot of unfounded assertions about the way things had to be for accessibility reasons, without any real evidence

[20:17:40.0000] <MikeSmith>
one use case that was behind a lot of it was the case of creating a text editor in canvas

[20:17:51.0000] <MikeSmith>
which we all universally agree is a bad idea

[20:18:10.0000] <cabanier>
yes

[20:18:26.0000] <cabanier>
it would be good if that was documented somewhere

[20:18:32.0000] <MikeSmith>
but they kept asserting that people are going to create text editors in canvas anyway, so we have to provide for it

[20:18:49.0000] <cabanier>
it seems that it could work with the current approach

[20:19:09.0000] <cabanier>
Not sure if authors will bother though

[20:19:18.0000] <MikeSmith>
I think they sort of preferred that it not be documented or even would have preferred not discussing it publicly

[20:19:25.0000] <MikeSmith>
yeah

[20:19:29.0000] <cabanier>
argh

[20:20:30.0000] <cabanier>
I'm inclined to say that if the a11y people signed off on this API, we should just implement it as-is

[20:21:19.0000] <cabanier>
I'm sure there were many discussions and I don't want to start from zero again

[20:22:07.0000] <cabanier>
Hopefully Hixie and Steve can enlighten me

[20:39:39.0000] <MikeSmith>
cabanier: I think the attitudie of "if the a11y people signed off on this API, we should just implement it as-is" is the wrong attitude to have

[20:39:47.0000] <MikeSmith>
that's what got us here to begin with

[20:40:15.0000] <MikeSmith>
first off there is no monolithic block of a11y people

[20:41:17.0000] <MikeSmith>
for example, there are many a11y people like James Craig who think that longdesc is actually bad for accessibility, but we now have it anyway

[20:43:03.0000] <MikeSmith>
there are some within the community who don't have enough technical insight into the details, so they just go along with what the party line is on it

[20:43:49.0000] <cabanier>
well, someone proposed this API and got it in the spec

[20:44:01.0000] <cabanier>
I must assume that they knew what they were doing

[20:44:19.0000] <MikeSmith>
I think you must now assume that

[20:44:32.0000] <cabanier>
that's why it would be great to see the discussion

[20:44:51.0000] <cabanier>
the current APIs seem very useful

[20:44:58.0000] <MikeSmith>
we are talking about basically 2 people who proposed that API and got it into the spec

[20:45:12.0000] <MikeSmith>
the rest of the people were along for the rid

[20:45:18.0000] <MikeSmith>
*ride

[20:46:03.0000] <cabanier>
brb

[20:46:38.0000] <MikeSmith>
*must not assume they knew what they were doing

[20:47:14.0000] <MikeSmith>
cabanier: when you're back I suggest you try to get some of Hixie's time to discuss this

[21:11:07.0000] <cabanier>
MikeSmith: who are the 2 people?

[21:27:39.0000] <MikeSmith>
Rich and Charles Pritchard

[21:27:51.0000] <MikeSmith>
cabanier: ↑

[21:29:05.0000] <MikeSmith>
cabanier: I think if you are implementing things based on ane "I must assume that they knew what they were doing" principle, you are not helping anybody.

[21:29:15.0000] <cabanier>
Rich said that Hixie wanted the split

[21:29:30.0000] <cabanier>
:-)

[21:29:51.0000] <MikeSmith>
yeah I don't recall in this particular case

[21:30:05.0000] <MikeSmith>
which is another reason you really should talk Hixie

[21:30:27.0000] <cabanier>
yes

[21:30:34.0000] <MikeSmith>
but I think Hixie will be the first to tell you that you should not just assume that he knew what he was doing

[21:31:23.0000] <cabanier>
drawSystemFocusRing looks OK and Dominic is fine with it

[21:31:45.0000] <cabanier>
drawCustomFocusRing is OK too (I think), just that the name is confusing

[21:32:21.0000] <cabanier>
Maybe I should land it as an experimental feature in firefox and keep the API at risk

[23:05:09.0000] <Hixie_>
cabanier1: i'm briefly here now if you are around, otherwise i'll be back online tomorrow morning

[23:07:31.0000] <Hixie_>
afk. will be back tomorrow morning.

[02:51:08.0000] <jgraham>
Hmm, Monday morning, 118 emails from github over the weekend

[07:40:29.0000] <annevk>
arv: did you end up investigating hasAttributes() removal?

[07:40:37.0000] <annevk>
arv: I can't find an issue number

[07:41:22.0000] <arv>
annevk: I added a use counter. It will take time to get useful data

[07:41:36.0000] <annevk>
arv: aight, cool

[07:45:50.0000] <jgraham>
Ms2ger: Huh? What am I missing?

[07:45:55.0000] <Ms2ger>
?

[07:46:04.0000] <jgraham>
Your review request

[07:46:33.0000] <jgraham>
I don't see where WebIDLParser.js would come from

[07:47:02.0000] <jgraham>
/me forwards review to darobin 

[07:47:08.0000] <Ms2ger>
jgraham, should be symlinked or something, I think

[07:47:19.0000] <Ms2ger>
There definitely isn't a http://www.w3c-test.org/resources/webidl2.js

[07:47:42.0000] <jgraham>
No, it looks like it should be resources/webidl2/lib/webidl2.js

[07:49:03.0000] <Ms2ger>
I think we didn't want to require changing all files that use idlharness

[07:49:31.0000] <jgraham>
darobin: ^?

[07:49:40.0000] <jgraham>
I have no idea, really

[07:49:50.0000] <jgraham>
But I at least don't see how what you wrote works

[07:50:32.0000] <Ms2ger>
http://www.w3c-test.org/resources/WebIDLParser.js exists

[07:50:47.0000] <darobin>
yeah but it's symlinked

[07:51:00.0000] <darobin>
it would be better to change all the files that use idlharness, there aren't that many

[07:51:13.0000] <Ms2ger>
I'd rather not

[07:51:32.0000] <darobin>
well, either that or we might need something better than symlinking

[07:51:35.0000] <jgraham>
OK, "it's symlinked" isn't a good enough solution

[07:51:46.0000] <darobin>
because symlinking just won't work everywhere

[07:51:57.0000] <darobin>
I reckon the alternative is to have wptserve know about this

[07:52:05.0000] <Ms2ger>
"Not use this submodule crap" is one :)

[07:52:12.0000] <jgraham>
I think the alternative is just to make the change

[07:52:20.0000] <darobin>
Ms2ger: any reason not to change those files?

[07:52:29.0000] <darobin>
feel free to replace this with something better

[07:52:39.0000] <darobin>
one other option is an install script of some sort

[07:52:47.0000] <Ms2ger>
Cool URIs, and stuff

[07:52:48.0000] <jgraham>
Which it kind of seems like Aryeh is doing whilst we chat about it

[07:52:59.0000] <darobin>
webidl2 can be found on npm, or if not should

[07:53:16.0000] <jgraham>
/me isn't introducing a node dependency :)

[07:53:18.0000] <Ms2ger>
How does that help?

[07:54:05.0000] <jgraham>
Anyway, I think people should just have to write /resources/webidl2/lib/webidl2.js

[07:54:29.0000] <jgraham>
If this is just a sed-level change let's just fix up everything

[07:54:52.0000] <Ms2ger>
As long as you update m-c too :)

[07:55:38.0000] <jgraham>
What's the problem updating m-c?

[07:55:50.0000] <jgraham>
It doesn't seem harder than any other kind of update

[07:56:02.0000] <jgraham>
(but you are the expert)

[07:57:23.0000] <Ms2ger>
I'm lazy :)

[07:58:19.0000] <darobin>
/me gives Ms2ger a cookie to get him working

[07:58:32.0000] <Ms2ger>
/me eats the cookie, is still lazy

[09:20:13.0000] <dglazkov>
good morning, Whatwg!

[10:08:26.0000] <cabanier>
Hixie_: ping

[10:14:14.0000] <smaug____>
Hixie_: ping

[10:19:51.0000] <zewt>
it's like a radar testing facility in here

[10:20:59.0000] <jgraham>
Hixie_: I represent the silent majority who have no need of your attention right now

[10:24:15.0000] <zewt>
but are highlighting his window anyway

[10:25:04.0000] <jgraham>
That's only a minority of the aforementioned majority

[10:39:50.0000] <TabAtkins>
MikeSmith: Actually, that particular example is a *huge* improvement over srcset, for equivalent functionality.  Check out Example 4 in my draft, which shows a similar example in both viewport-style and MQ-and-Nx style.  The latter one is *much* worse, and it's not even as correct - getting it closer would make it even more horrible.

[10:40:24.0000] <TabAtkins>
If you're complaining that it's not as simple as a single, simple srcset, well duh - you're invoking much more powerful stuff.  If you want equal power, it's *exactly identical to srcset's syntax*.

[10:42:42.0000] <TabAtkins>
jgraham: I'm just skimming the discussion, but if you're using Python and need a webidl parser, maybe try Peter Linss'? I'm using it in bikeshed.  https://github.com/plinss/widlparser

[10:43:11.0000] <jgraham>
/me doesn't need a WebIDL parser

[10:43:30.0000] <TabAtkins>
jgraham: Okay, I just see y'all talking about webidlparser.js

[10:43:48.0000] <jgraham>
idlharness.js needs a javascript WebIDL parser. Which we have. But not in a convenient location

[10:43:56.0000] <TabAtkins>
Ah, never mind then.

[10:44:05.0000] <jgraham>
Thanks for the suggestion anyway :)

[11:01:51.0000] <smaug____>
Hixie_: nm

[11:02:47.0000] <Hixie_>
smaug____, cabanier, jgraham: pong

[11:02:52.0000] <Hixie_>
wait, not jgraham and not smaug____ any more

[11:02:56.0000] <Hixie_>
just cabanier

[11:03:14.0000] <annevk>
srcN looks even uglier

[11:06:24.0000] <cabanier>
Hixie_: hi

[11:06:46.0000] <cabanier>
Hixie_: can you tell me the history of the canvas focus rings?

[11:07:11.0000] <Hixie_>
not off the top of my head, no

[11:07:17.0000] <Hixie_>
anything in particular?

[11:07:37.0000] <cabanier>
Well, Dominc seems to have doubts about drawSystemFocusRing

[11:07:48.0000] <cabanier>
I think the name is very confusing...

[11:08:10.0000] <TabAtkins>
annevk: Try it, dude.  For anything that srcset can do by itself, just do a s/srcset/src-1/ and you have converted it into my proposal.  For anything that <picture>-with-MQ-and-srcset can do, srcN does more compactly and imo not any uglier, if you format well (similar to how you'd format the child elements of <picture>).  For the things that srcN's viewport

[11:08:11.0000] <TabAtkins>
syntax does, <picture>-with-MQ-and-srcset is *way* longer and uglier.

[11:08:13.0000] <cabanier>
why was it split up in 2 methods?

[11:08:41.0000] <Hixie_>
cabanier: there's two use cases. Some people want to get whatever the system focus ring is, and some people want to draw their own focus rings.

[11:08:45.0000] <TabAtkins>
That last isn't something you can reasonably argue, unless you've just never actually seen the comparison and are arguing from a mistaken assumption of what each would look like.

[11:08:55.0000] <cabanier>
yeah.

[11:09:06.0000] <TabAtkins>
<picture> just ends up *way* longer, with loads of duplication.

[11:09:17.0000] <Hixie_>
isn't <picture> dead yet?

[11:09:24.0000] <annevk>
TabAtkins: I'm no fan of <picture> btw, that seems crazy

[11:09:28.0000] <cabanier>
but they both start with 'draw' so it's unclear that one of them doesn't draw

[11:09:30.0000] <Hixie_>
<picture> is a non-starter

[11:09:35.0000] <TabAtkins>
Hixie_: Practically, yes, since no implementor wants <source> elements.

[11:09:40.0000] <Hixie_>
TabAtkins: right

[11:09:50.0000] <Hixie_>
TabAtkins: that's what i told the <picture> advocates many times...

[11:09:52.0000] <annevk>
Using <video>-style markup (which was a disaster to begin with) but with way different semantics is ...

[11:09:57.0000] <Hixie_>
and srcset="" does everything <picture> does, anyway

[11:10:02.0000] <Hixie_>
cabanier: well, they both can draw

[11:10:21.0000] <Hixie_>
cabanier: i'm open to better names if there are any proposals on the table, though

[11:10:53.0000] <TabAtkins>
Hixie_: It doesn't, not quite, though for the common MQs you'd use with <picture>, it's fine.  But both of them are horrible when you have a variable-width image that you want to deliver an appropriate-density image to.

[11:11:07.0000] <cabanier>
Hixie_: true that it could draw. I guess it's confusing either way

[11:11:16.0000] <Hixie_>
TabAtkins: what doesn't srcset handle?

[11:11:46.0000] <Hixie_>
TabAtkins: srcset="" is pretty much as terse as you can get it, i think. hard to see how you'd get the same information any more tersely.

[11:11:49.0000] <cabanier>
Hixie_: I thought src-set requires ugly complex syntax

[11:11:58.0000] <TabAtkins>
Say you have a header image meant to be 100% of the viewport wide.  "100%" can translate to anywhere from ~300px to ~2000px (or more).

[11:11:59.0000] <cabanier>
Hixie_: srcN just pulls it apart

[11:12:12.0000] <Hixie_>
i don't know what srcn is

[11:12:24.0000] <TabAtkins>
A 1000px-wide source image functions as both a 1x image at 1000px viewport size, and a 2x iamge at 500px viewport size.

[11:12:56.0000] <TabAtkins>
And so to get that all to work correctly, you've got to write the same urls over and over again with different density descriptors, at different viewport widths that you have to kind of guess at.

[11:13:12.0000] <cabanier>
http://tabatkins.github.io/specs/respimg/Overview.html

[11:13:16.0000] <Hixie_>
that's pretty rare. you don't generally want an image to be half as big in the same space, surely.

[11:13:38.0000] <TabAtkins>
Hixie_: I... just described to you a case where you'd want that, and it's not rare at all.

[11:14:28.0000] <Hixie_>
show me a page that does this.

[11:15:16.0000] <TabAtkins>
I'm not going to go find you a page with a header image that fills the viewport.  They're everywhere.  If they're responsive rather than fixed-width, they're exactly the case I describe.

[11:15:21.0000] <SimonSapin>
http://lesgarsdelamarine.org/

[11:15:37.0000] <TabAtkins>
SimonSapin: Hahaha

[11:16:03.0000] <Hixie_>
there's no art direction on that page, it's just a pixel density thing

[11:16:10.0000] <Hixie_>
so that's not a useful example

[11:16:13.0000] <TabAtkins>
...yes, exactly.

[11:16:15.0000] <Hixie_>
srcset handles that one fine

[11:16:17.0000] <TabAtkins>
This isn't an art-direction case.

[11:16:36.0000] <TabAtkins>
It's a pixel-density case, where you can't describe the pixel density of each url once, because you dont' know what the target size will be.

[11:16:44.0000] <TabAtkins>
You have to describe it multiple times, at multiple target sizes.

[11:17:37.0000] <TabAtkins>
In that page Simon just provided, if you wanted to actually optimize your delivery, you'd want multiple version of the image at various sizes, and then you want to let the browser choose whether to download one that close to 1x, or close to 2x, or whatever.

[11:18:27.0000] <Hixie_>
sure. srcset handles that fine.

[11:18:33.0000] <TabAtkins>
No. No it doesn't.

[11:18:39.0000] <TabAtkins>
It handles it *extremely verbosely*.

[11:19:17.0000] <TabAtkins>
And with a lot of unnecessary work on the author's side, figuring out best guesses at where to cut the breakpoints for classifying a given image as 1x or 2x.

[11:19:39.0000] <TabAtkins>
Check example 3 here: http://tabatkins.github.io/specs/respimg/Overview.html#viewport

[11:19:58.0000] <TabAtkins>
Doing something equivalent in srcset would be really long and frustrating to read/write/edit.

[11:21:05.0000] <TabAtkins>
This precise case has been argued well by John Mellor regarding the CSS image-set() function, and applies equally to srcset (since MQ+image-set() is roughly equivalent to the full srcset syntax).

[11:22:11.0000] <Hixie_>
isn't it just <img style="width: 100%" src="big.jpeg" srcset="small.jpeg 500w, big.jpeg 500w 2x">

[11:22:14.0000] <Hixie_>
...?

[11:22:17.0000] <Hixie_>
http://damowmow.com/playground/demos/img/001.html

[11:22:28.0000] <TabAtkins>
Oh good lord not.

[11:22:52.0000] <Hixie_>
why not? what doesn't that do?

[11:23:14.0000] <Hixie_>
i'm trying to do the example you gave above. A 1000px-wide source image functions as both a 1x image at 1000px viewport size, and a 2x iamge at 500px viewport size.

[11:23:17.0000] <TabAtkins>
Only providing two images means that you're either sending *way* too many pixels to small screens, or way too few to large screens.

[11:23:26.0000] <Hixie_>
that's the example you gave

[11:23:45.0000] <Hixie_>
SimonSapin: (thanks, btw)

[11:24:11.0000] <TabAtkins>
That was an example of the wider problem.  You want a 500px wide iamge as well, for a small-screen 1x version.  And a 2000px wide image, for a large-screen 2x version.

[11:24:40.0000] <Hixie_>
please specify a specific problem that we can compare

[11:25:14.0000] <TabAtkins>
I dont' see why you can't trivially extrapolate this to the full problem.  Do you not understand the problem I'm laying out?

[11:25:49.0000] <Hixie_>
if i did i wouldn't be pretending i didn't...

[11:26:00.0000] <TabAtkins>
It's honestly hard to tell sometimes... ^_^

[11:26:08.0000] <Hixie_>
o_O

[11:26:31.0000] <SimonSapin>
TabAtkins: just give an example of the super verbose thing

[11:26:33.0000] <TabAtkins>
You sometimes do a really good impression of someone being intentionally obtuse, is all.

[11:26:39.0000] <TabAtkins>
SimonSapin: Yeah, writing that up.

[11:27:08.0000] <Hixie_>
i am never intentionally obtuse. i try to ask questions that will get me to a point of understanding a problem asap.

[11:27:45.0000] <TabAtkins>
Hixie_: Okay, so problem statement: You want to deliver an appropriate-density image regardless of what screen size the user has.  You have to cover screens as small as 320px, and as large as 2000px.

[11:28:04.0000] <Hixie_>
how many images?

[11:28:40.0000] <Hixie_>
and what densities are we trying to support?

[11:28:50.0000] <TabAtkins>
You need to deliver a images that are approximately 1x and 2x for each screen, and it woudl be nice to also deliver .5x (for low-bandwidth situations).

[11:28:53.0000] <TabAtkins>
I'm getting there!

[11:29:07.0000] <Hixie_>
no rush, just asking questiosn to understand the situation :-)

[11:29:39.0000] <TabAtkins>
So, given those constraints, figure out how many breakpoints you need in srcset to cover all screens with those densities, and then write it out.

[11:30:05.0000] <TabAtkins>
I think you need at least 4 breakpoints, with each delivering 3 images.

[11:30:19.0000] <Hixie_>
what are we trying to optimise here? i'm confused

[11:30:32.0000] <Hixie_>
this is an underconstrained problem

[11:30:56.0000] <TabAtkins>
You're trying to display an image that is viewport-width, delivering an appropriately-sized image (in terms of number of pixels sent down).

[11:31:11.0000] <Hixie_>
what is "appropriate"?

[11:31:14.0000] <TabAtkins>
You dont' want to send a 1000px-wide image to a 320px viewport, for example, because that's at least a 3x.

[11:31:33.0000] <TabAtkins>
Close to 1x, 2x, and optimally .5x density.

[11:31:52.0000] <TabAtkins>
So for a 320px viewport seeking a 1x image, you should be able to deliver something that is approximately 320px wide.

[11:31:53.0000] <TabAtkins>
Etc.

[11:31:56.0000] <Hixie_>
(for the record, i don't think anyone ever wants to send .5x density images, but i'll ignore that for now)

[11:32:12.0000] <Hixie_>
3x needed pixels is too much; is 2x too much? 1.5x?

[11:32:43.0000] <TabAtkins>
2x is too much unless the device is *looking* for a 2x image, because it's a 200dpi screen or whatever.  That's four times as many pixels, after all!

[11:33:07.0000] <TabAtkins>
You can make a reasonable choice as to exactly where the breakpoint is - I suggest either the additive or multiplicative average.

[11:35:10.0000] <Hixie_>
TabAtkins: dude whatever i pick you'll be like "well that's inappropriate, and with _this_ choice, srcN is better!", hence my wanting to pin it down

[11:35:41.0000] <TabAtkins>
I will be like that, because anything that's anywhere near close to the right behavior will be horrible as hell to write with srcset.

[11:35:57.0000] <TabAtkins>
I already know this, because I've been through this argument on your side of the table already.

[11:36:04.0000] <Hixie_>
TabAtkins: ok that's great but i'd like to know this also

[11:36:14.0000] <TabAtkins>
(While trying to argue against addressing this in image-set().)

[11:36:22.0000] <Hixie_>
TabAtkins: so what is the appropriate additional overhead?

[11:36:28.0000] <Hixie_>
maximum overhead

[11:36:34.0000] <Hixie_>
1.25?

[11:36:35.0000] <Hixie_>
1.5?

[11:36:37.0000] <Hixie_>
1?

[11:36:53.0000] <TabAtkins>
Just go with 1.5.  That's fine.

[11:36:56.0000] <Hixie_>
(1 being "never send an image bigger than needed)

[11:36:56.0000] <Hixie_>
ok

[11:37:22.0000] <TabAtkins>
More than that is definitely bad. 1.5 isn't ideal for optimality, but whatever, it's simple and not too far off.

[11:37:40.0000] <Hixie_>
(what's ideal?)

[11:37:51.0000] <Hixie_>
and these images are all the same image, just resized?

[11:37:53.0000] <TabAtkins>
Dunno, but probably the multiplicative average.

[11:37:55.0000] <TabAtkins>
Yeah.

[11:38:02.0000] <Hixie_>
with the master being 2000 * 2x?

[11:38:10.0000] <Hixie_>
(i've no idea what "the multiplicative average" means here)

[11:38:19.0000] <TabAtkins>
About 1.3.

[11:38:29.0000] <TabAtkins>
sqrt of 2

[11:38:32.0000] <Hixie_>
ok, i can do 1.3

[11:38:59.0000] <TabAtkins>
You can have a master of whatever size you want, but it should be appropriate to deliver at 2x density to a 2000px wide viewport, yeah.

[11:39:12.0000] <TabAtkins>
(If a different number would be easier, because it has more factors of 2 in it, that's fine.)

[11:39:31.0000] <SimonSapin>
Isn’t “ideal” approached asymptotically with infinitely many breakpoints? :)

[11:40:15.0000] <Philip`>
Surely ideal would be when the server has pre-generated an image that is precisely the same number of pixels as it will be displayed as, while also taking account of the screen's sub-pixel layout and orientation and the distance of the user's eyes

[11:40:30.0000] <Hixie_>
that's why i'm trying to find tab's definition

[11:41:28.0000] <TabAtkins>
This is a fair definition of ideal that lets you space things as far apart as possible without being silly.

[11:42:31.0000] <TabAtkins>
Btw, going to lunch now.  Be back in an hour.  My solution is Example 3 in my spec, which has been linked already.

[11:45:44.0000] <Hixie_>
(example 3 doesn't have enough images to satisfy your constraints)

[11:48:09.0000] <zewt>
"You have to cover screens as small as 320px, and as large as 2000px." newer monitors are 2560x1440

[11:49:50.0000] <SimonSapin>
there is at least one 2560x1600 tablet

[11:49:52.0000] <Hixie_>
he said 2000px at 2x

[11:49:55.0000] <Hixie_>
so that's 4000px

[11:50:10.0000] <SimonSapin>
oh, CSS px

[11:50:11.0000] <Hixie_>
also, i don't have any photos that are 4000px wide in my albums, bummer.

[11:50:16.0000] <zewt>
ah

[11:50:18.0000] <Hixie_>
/me goes to google image search

[11:52:24.0000] <zewt>
Hixie_: http://blogs.getty.edu/iris/open-content-an-idea-whose-time-has-come/

[11:53:32.0000] <Hixie_>
that would also have worked, probably :-)

[11:53:44.0000] <zewt>
probably would take a bit longer, heh

[11:55:06.0000] <Philip`>
SimonSapin: There's at least one 3840x2560 tablet too

[11:55:19.0000] <SimonSapin>
cool

[11:55:30.0000] <Philip`>
4K video is the hot thing now that everyone wants to support

[11:55:47.0000] <Philip`>
(Everyone who makes money from selling expensive technology, at least)

[11:55:47.0000] <zewt>
how long until 4k video at 2x

[11:57:22.0000] <Philip`>
HEVC apparently supports 8192x4320, but I guess you'll have to wait for another generation to codecs to go any higher

[11:58:50.0000] <Philip`>
(and I think almost all current hardware implementations are limited to 4K)

[12:01:53.0000] <zewt>
i wonder what the pixels-per-degree-of-vision is comparing 4k at 10' to iPad resolution at handheld distance

[12:02:14.0000] <Hixie_>
didn't Red make a camera that was 8K or something?

[12:02:26.0000] <Hixie_>
just recently

[12:02:53.0000] <zewt>
wouldn't be surprised if they want higher resolution than the final resolution, to allow for loss during postprocessing

[12:04:14.0000] <Hixie_>
TabAtkins: it's actually not anywhere near as bad as i thought it would be, with srcset="". I'm curious to see what your proposal would look like for this, fitting the same actual constraints (the one in the spec doesn't): http://damowmow.com/playground/demos/img/002/test.html

[12:04:18.0000] <Hixie_>
bbiab, lunch

[12:11:42.0000] <Philip`>
Camera resolutions are arguably cheating a bit since they only capture a single colour component per pixel, so they're not able to resolve as much detail as you might hope for

[12:27:59.0000] <annevk>
Hixie_: RED has 6K, with a little over 19MP, there's others that have 8K

[12:28:16.0000] <TabAtkins>
Hixie_: Right, to fully satisfy my requirements, I'd have to add one more image to the Example 3 syntax in my spec.

[12:30:29.0000] <TabAtkins>
Hixie_: But basically, under my proposal it requires almost 1/3 the urls, because you never have to duplicate them, and no real math to find breakpoints.

[12:33:11.0000] <annevk>
These examples seem crazy... I wonder what percentage of sites will ever use more than the 2x variant...

[12:33:43.0000] <annevk>
Over engineering like it's '95

[12:34:57.0000] <TabAtkins>
annevk: Probably a smallish percentage, but when you need it, it's terrible any other way.  In any case, just doing the Nx stuff is fine in my spec.

[12:40:14.0000] <zewt>
1.5 is unfortunately common now too, Amazon needs to be deposited into the sun for that one

[12:41:44.0000] <TabAtkins>
zewt: What do you mean?

[12:42:05.0000] <TabAtkins>
Android devices span a remarkable spectrum of numbers from 1 to 2.

[12:42:48.0000] <zewt>
most of them are too uncommon to care about

[12:43:11.0000] <zewt>
to optimize for, at least

[12:57:39.0000] <zcorpan>
can a sequence use a union type in webidl?

[12:57:53.0000] <Ms2ger>
Sure

[13:04:29.0000] <jsbell>
Anyone know if any async APIs have been hooked up to window.onerror?

[13:04:48.0000] <Ms2ger>
The promise error reporting?

[13:04:55.0000] <Ms2ger>
If that's specced yet

[13:06:52.0000] <annevk>
jsbell: in what sense?

[13:08:08.0000] <jsbell>
annevk: in concrete terms, there's a "indexeddb should integrate with window.onerror" on my list of things to follow up on. Digging into window.onerror it's unclear that makes sense, so looking for precedent

[13:08:42.0000] <annevk>
jsbell: only exceptions bubble up there at the moment

[13:08:54.0000] <jsbell>
i.e. window.onerror is set up for giving you message/url/line number, so document parse errors and exceptions, yeah

[13:09:33.0000] <jsbell>
IDB would be uncaught error events; unhandled promise failures would be another plausible case (as Ms2ger points out)

[13:10:40.0000] <annevk>
Promises won't end up on window.onerror per current design

[13:10:51.0000] <annevk>
(and it was considered)

[13:11:06.0000] <jsbell>
IDB already has a place for apps to catch otherwise-unhandled errors, so it's not a huge win; may make more sense to wait for a hypothetical IDB-on-Promises and unify with whatever is figured out for Promises

[13:11:07.0000] <annevk>
They can't because that would expose garbage collection

[13:11:43.0000] <annevk>
The plan is to let the console handle it...

[13:20:27.0000] <zcorpan>
TabAtkins: the example still wouldn't satisfy the 1.3 constraint

[13:20:30.0000] <dglazkov>
Hixie_:  https://code.google.com/p/chromium/issues/detail?id=301937?

[13:21:01.0000] <TabAtkins>
zcorpan: It'll satisfy the sqrt(2) that I said immediately afterwards, since it's doubling each time.

[13:21:26.0000] <TabAtkins>
1.3 was my bad estimate of sqrt(2), because I was remembering sqrt(10), which is 3.1.

[13:21:33.0000] <TabAtkins>
approximately

[13:23:52.0000] <zcorpan>
it's doubling the width, but hixie's example has the widths 1.3x apart

[13:24:15.0000] <TabAtkins>
Yes?  That's not actually necessary.

[13:24:56.0000] <TabAtkins>
If you have a 100px image and a 200px image, then a viewport at 141px wide downloading the 200px image as a 1x is overloading by a factor of sqrt(2).

[13:42:15.0000] <zcorpan>
so hixie's example should be more like http://pastebin.com/gVawS2dX

[13:45:14.0000] <zcorpan>
maybe with the x'es corrected for 1280.jpeg 2000w 0.5x, etc

[13:45:50.0000] <zcorpan>
1.5625x

[13:46:00.0000] <zcorpan>
er

[13:46:06.0000] <TabAtkins>
Yeah, sure.

[13:46:12.0000] <TabAtkins>
Whatever, close enough. ^_^

[13:47:01.0000] <zcorpan>
0.64x

[13:47:34.0000] <TabAtkins>
Or just change the final breakpoint to 2560 and call it good enough.

[13:52:50.0000] <TabAtkins>
zcorpan, Hixie_: Here's Hixie's changed over to the same breakpoints as I do, just for easier comparison: http://pastebin.com/izF8GaF8

[13:52:59.0000] <TabAtkins>
+ what it would look like in my syntax.

[13:55:40.0000] <zcorpan>
i love that Hixie_ got the syntax wrong for srcset and TabAtkins got the syntax wrong for src1 (the attribute name) :-P

[13:55:55.0000] <TabAtkins>
No I didn't - I changed the spec over the weekend to ahve a dash.

[13:56:02.0000] <zcorpan>
oh

[13:56:43.0000] <TabAtkins>
At Yoav's request, to make it better match data-* mentally, and make it easier to super-quickly scan the attributes to see if there are any candidate attributes (so that if not, we can just fast-path the src attribute).

[13:57:14.0000] <TabAtkins>
A single check for any attributes starting with "src-" case-insensitively is apparently easier than checking for "src[1-9]".

[13:57:16.0000] <zcorpan>
i don't see that in http://tabatkins.github.io/specs/respimg/Overview.html

[13:57:40.0000] <TabAtkins>
Hrm.  I thought I pushed that.

[13:58:34.0000] <zcorpan>
the check shouldn't be case-insensitive

[13:59:35.0000] <TabAtkins>
Duh, didn't regen the spec before pushing.  Fixing now.

[13:59:44.0000] <TabAtkins>
zcorpan: Oh?  I thought that HTML attributes were case-insensitive.

[14:00:24.0000] <zcorpan>
the html parser case-folds to lowercase, so checks in the DOM should look for lowercase

[14:01:09.0000] <TabAtkins>
Ah, ok.

[14:01:20.0000] <zcorpan>
img.setAttributeNS('', 'SRC', 'foo.jpg'); will be an unknown attribute

[14:01:33.0000] <TabAtkins>
Well anyway, still eaiser to do a search for "starts with src-" than "starts with src[1-9]".

[14:01:53.0000] <zcorpan>
yeah

[14:04:23.0000] <TabAtkins>
Note that the Hixie syntax falls back to some tiny image for screens greater than 2560 - you want another line in there to provide the 5120 image to arbitrary viewports, I think.

[14:07:31.0000] <Hixie_>
i think http://pastebin.com/izF8GaF8 is very misleading, because the srcset="" stuff doesn't get any more complicated at all, while srcN does

[14:07:45.0000] <Hixie_>
given that, the fact that they are so similar is kinda surprising to me

[14:07:57.0000] <Hixie_>
zcorpan: what syntax did i get wrong?

[14:08:20.0000] <Hixie_>
oh lol the x is in the wrong place

[14:08:24.0000] <zcorpan>
Hixie_: px instead of w, x before instead of after the number

[14:08:27.0000] <Hixie_>
that'll teach me to not look at my script's output

[14:08:46.0000] <TabAtkins>
Hixie_: I dont' understand your comment.  What do you mean "doesn't get any more complicated at all"?

[14:09:12.0000] <Hixie_>
TabAtkins: there's no more features than that. this is literally as bad as srcset="" can get.

[14:09:18.0000] <Hixie_>
if you understand this, you understand it all.

[14:09:29.0000] <TabAtkins>
Yes, correct.  And it's pretty bad when it gets that far.

[14:09:29.0000] <Hixie_>
zcorpan: (i didn't actually proofread the output of my script before going to lunch)

[14:09:38.0000] <Hixie_>
come now, it's almost the same as the srcN case

[14:09:47.0000] <TabAtkins>
But outside of this case, srcN and srcset are basically identical.

[14:09:54.0000] <Hixie_>
clearer, imho, since you can tell what image is going to be used for any particular width/density combination

[14:09:57.0000] <Hixie_>
at a glance

[14:09:59.0000] <TabAtkins>
It's twice as many lines, Hixie, and confusing both to read and write.

[14:10:23.0000] <Hixie_>
(updated damowmow.com/playground/demos/img/002/test.html to be correct)

[14:11:19.0000] <Hixie_>
verbose doesn't mean complex. complexity is also a measure of many axes there are to control things.

[14:11:29.0000] <Hixie_>
you can be really terse and more complex, or really verbose and more complex

[14:11:58.0000] <Hixie_>
the measure of complexity is how much you have to know to understand it

[14:13:00.0000] <TabAtkins>
Yes, of course.  I think that, when addressing this case, srcset hits the "verbose and more complex" part.  Less overall concepts to understand, but more *stuff* to comprehend in the individual instance.  (Analogy - binary is simpler because it has less digits than decimal, but it's still harder to read and write because of the increased lengths of numbers.)

[14:14:14.0000] <zcorpan>
i think the nice thing about src-N's viewport thing is that the author doesn't need to think as much, nor pull up the calculator; just state the breakpoints and put in the images you want and give their actual widths, and the browser figures out the rest

[14:14:24.0000] <TabAtkins>
Yup, that's precisely it.

[14:15:18.0000] <TabAtkins>
I didn't like that I have two separate syntaxes embedded in srcN, but the viewport-stuff is too much and kinda inflexible when you just want to deliver a simple known-size image at different densities.

[14:15:39.0000] <Hixie_>
"harder to read and write" and "more complex" are orthogonal concerns, imho

[14:15:59.0000] <TabAtkins>
They both fall into the "bad" bucket, though.

[14:16:20.0000] <Hixie_>
maybe. but they trade off each other.

[14:16:22.0000] <TabAtkins>
(Though of course increased complexity's badness can be balanced by the utility of whatever additional stuff it grants.)

[14:17:38.0000] <Hixie_>
the multiple-attribute proposal imho makes the wrong trade-off.

[14:17:56.0000] <Hixie_>
but honestly, part of the problem is that we're talking about solutions again before talking about problems.

[14:18:00.0000] <Hixie_>
so it's hard to evaluate

[14:18:13.0000] <Hixie_>
i'm evaluating it based on the problems srcset="" was designed to address

[14:18:27.0000] <TabAtkins>
The problems are well-known.  We've known them for a long time.  We're only faffing about the solution-space to find a good syntax to address the problem.

[14:18:43.0000] <TabAtkins>
(And my spec does have a section describing the problems.)

[14:18:57.0000] <Hixie_>
the problems described at http://tabatkins.github.io/specs/respimg/Overview.html#problem are much better solved by srcset="" IMHO.

[14:19:07.0000] <Hixie_>
to start with, there's only one attribute. secondly, it's got less power.

[14:19:25.0000] <TabAtkins>
srcset *covers* the solution space adequately.  It just doesn't do so with a great syntax in some not-too-corner cases.

[14:19:35.0000] <Hixie_>
yes, it's slightly more verbose if you're doing dozens of widths and densities, but i don't think that's something that's gonna happen in reality, as anne said above.

[14:20:22.0000] <TabAtkins>
srcN covers the same solution space (*slightly* wider, but nothing to write home about), is identical in syntax with srcset for the simpler cases (where srcset does well), and in many people's opinions has a more usable/convenient syntax outside of the simpler cases.

[14:20:31.0000] <Hixie_>
come on, you don't think multiple attributes with a complex media-query-based microsyntax is a _good_ syntax do you? i mean, i'll grant you maybe that srcset="" is as bad, but that's about it. it's definitely not better.

[14:21:41.0000] <TabAtkins>
The MQ part is the simplest part, to be honest.  MQs are already well-known and familiar, as opposed to "300w", which is brand new and doesn't indicate what the width *is* - max or min?  Yes, you just have to learn it, but it's one more new thing to learn when there is already a syntax for expressing these things.

[14:22:01.0000] <TabAtkins>
There's a reason that Blink's srcset implementation does *not* do the w/h stuff yet - people don't really like it.

[14:22:02.0000] <Hixie_>
"MQs are already well-known and familiar" is soooo not true

[14:22:07.0000] <Hixie_>
(adsly)

[14:22:10.0000] <Hixie_>
(sadly, evne)

[14:22:11.0000] <Hixie_>
even

[14:22:14.0000] <Hixie_>
jesus, can't type today

[14:22:32.0000] <TabAtkins>
Among the set of people who care enough about their craft to do this kind of thing in the first place, they are.

[14:22:34.0000] <zcorpan>
TabAtkins: is there a good reason to support all of MQ?

[14:22:53.0000] <Hixie_>
(btw, looks like you have a typo in 3.2 example 2, |src-1="pic.png,| presumably is missing something after the file name)

[14:23:33.0000] <TabAtkins>
Hixie_: No, that's right.  Omitting the density defaults it to 1x.

[14:23:46.0000] <Hixie_>
then you have a parser problem; "," is a valid URL character

[14:23:50.0000] <Hixie_>
I have _no_ idea what this does, at a glance:

[14:23:51.0000] <Hixie_>
  <img src-1="100 30em 400 70em 50%;

[14:23:51.0000] <Hixie_>
             pic50.png 50, pic100.png 100, pic200.png 200,

[14:23:51.0000] <Hixie_>
             pic400.png 400, pic800.png 800, pic1600.png 1600,

[14:23:51.0000] <Hixie_>
             pic3200.png 3200">

[14:24:03.0000] <Hixie_>
i mean that's SVG-like in its obscurity :-)

[14:24:16.0000] <zewt>
(zing)

[14:24:24.0000] <TabAtkins>
Hixie_: No, the parser specifically describes that the <url> production can't end in comma or semicolon.  You have to escape them at the end if you want to do that.

[14:24:41.0000] <TabAtkins>
Hixie_: Uh, yes.  That's the most complex possible example.

[14:24:47.0000] <Hixie_>
ugh, don't special-case URL syntax dude

[14:24:49.0000] <Hixie_>
that's crazytown

[14:25:01.0000] <TabAtkins>
It's that or complicate the syntax. :/

[14:25:10.0000] <TabAtkins>
URLs are the devil.

[14:25:11.0000] <Hixie_>
TabAtkins: according to the spec, it's not the most complex example...

[14:25:18.0000] <TabAtkins>
Huh?

[14:25:36.0000] <Hixie_>
TabAtkins: it's the example before another example that's described as "more verbose" and "not even as correct"

[14:25:49.0000] <TabAtkins>
zcorpan: I don't know of a strong argument, no.  Reusing the MQ syntax for breaking on viewport sizes is just a big win by itself for learning/understandability, and once you do that, allowing the rest of MQ is easy.

[14:26:06.0000] <TabAtkins>
Hixie_: Ok, you win a pedant point.

[14:26:18.0000] <TabAtkins>
For pointing out an anti-example specifically used as something to not do.

[14:26:30.0000] <Hixie_>
actually the next one looks clearer to me

[14:26:37.0000] <Hixie_>
though apparently it's wrong somehow

[14:26:56.0000] <TabAtkins>
The very next paragraph explains the somehow.

[14:27:01.0000] <Hixie_>
but i don't see why srcset="" wouldn't do that example better

[14:27:09.0000] <Hixie_>
it'd be just the one attribute

[14:27:34.0000] <TabAtkins>
In srcset you'd collapse them to one attribute, and distribute the MQs across each of the urls as NNNw descriptors, yes.

[14:27:39.0000] <TabAtkins>
Roughly equivalent.

[14:27:48.0000] <Hixie_>
yeah i don't understand the paragraph that explains why it's wrong

[14:28:26.0000] <TabAtkins>
Did you read the whole example, and understand the reason why the <size-viewport-list> is what it is in that example?

[14:28:40.0000] <Hixie_>
i read the whole example, can't say i fully understand it.

[14:29:00.0000] <TabAtkins>
The first paragraph attempts to explain it.  I'm open to clarifying it, if you can tell me what you didn't understand.

[14:29:17.0000] <Hixie_>
i rarely know what i didn't understand, kind of by virtue of not understanding it :-)

[14:29:33.0000] <TabAtkins>
And I don't know what you didn't understand either, so shrug.

[14:29:49.0000] <zcorpan>
Hixie_: the key is that the image is 50% of the viewport in the widest layout, but the wrong example assumes it's 800px (at 1x)

[14:30:22.0000] <Hixie_>
surely the width of the image is decided by CSS

[14:31:03.0000] <TabAtkins>
Yes.  But the image-loading code needs to make a decision before CSS starts applying.

[14:31:19.0000] <TabAtkins>
Or wait, no, that doen't even answer your question.

[14:31:32.0000] <TabAtkins>
Because I'm not sure what your statement even means, or how it's a reaction to zcorpan's.

[14:32:21.0000] <Hixie_>
does "the image" mean the file from the server, or the <img> element?

[14:32:26.0000] <TabAtkins>
In order to avoid *even more* verbosity, I stopped at three breakpoints there.  But, much like the previous example I had you work through, to be really accurate you'd want more.

[14:32:45.0000] <TabAtkins>
You get that "more" super cheaply and easily under srcN.

[14:33:01.0000] <Hixie_>
i'm not convinced this is a real problem.

[14:33:19.0000] <TabAtkins>
Okay.  Clueful people have said it is, and have offered arguments that were convincing to me.

[14:34:37.0000] <Hixie_>
what are those arguments?

[14:34:39.0000] <TabAtkins>
To directly answer your question - the <img> element will be 100px, 400px, or 50% wide.  The code provided assumes that, in the last case, that 50% will resolve to 800px (that is, it assumes a viewport width of 1600px).

[14:34:54.0000] <Hixie_>
why would you assume a viewport width?

[14:34:57.0000] <TabAtkins>
I gave them earlier today.  We spent like an hour discussing a use-case about this.

[14:35:14.0000] <TabAtkins>
Hixie_: Because you have to, under srcset or MQ+Nx syntax?

[14:35:37.0000] <TabAtkins>
Declaring that a given source is a given density presupposes that it's being displayed at a given size.

[14:35:41.0000] <Hixie_>
with srcset="" you specify the max viewport widths for each image, you don't assume anything

[14:36:00.0000] <TabAtkins>
When the final size will be a percentage of a viewport, you must thus translate this into an assumed size (or multiple assumed sizes).

[14:36:27.0000] <Hixie_>
i didn't see any arguments earlier that would convince me that people are going to actually provide 4x images, 0.5x images, nor that they would provide 7 different images (without art direction) per <img>. 2, 4 maybe. not 7.

[14:37:47.0000] <TabAtkins>
4x screens are something we should prepare for in a few years.  .5x images are something very nice to provide for low-bandwidth scenarios - I'd *love* if images downloaded at .5x when I was on an edge connection, even though I have a high-dpi phone.

[14:38:12.0000] <TabAtkins>
Both of these edge cases are things that come *for free* in the viewport-based half of srcN's syntax.

[14:38:41.0000] <TabAtkins>
It's future-friendly for things that we *know* will come up, or already exist, without the author having to do almost any additional work.

[14:39:53.0000] <TabAtkins>
I'm frustrated that you don't seem to understand the terribleness, to a normal author, of having to repeat the same url multiple times.  People just won't do that - they'll ignore it, and only offer a few things, and produce a worse user experience.

[14:40:48.0000] <Hixie_>
as people keep telling me, what we personally might want shouldn't affect the spec :-)

[14:41:01.0000] <Hixie_>
in practice, i see no evidence that authors want to provide half-res images in low-bandwidth situations

[14:41:39.0000] <Hixie_>
and i'm not at all convinced 4x displays will exist coincident with 1x displays, let alone 1x displays that you want 0.5x images for

[14:41:53.0000] <Hixie_>
we can barely make 2x displays at any high resolution these days

[14:42:15.0000] <Hixie_>
people repeat urls all the time, why do you think they wouldn't?

[14:42:59.0000] <TabAtkins>
I *just* said that I have a 2x device that I would want .5x images for some times.  Claiming that it would only be for 1x devices is disingenuous.

[14:43:18.0000] <Hixie_>
the srcset="" version of your "Example 4" in section 3.3, supporting just 1x and 2x, would be:

[14:43:21.0000] <Hixie_>
<img srcset="pic100.png 480w 1x, pic200.png 480w 2x,                                                                                                                                                    pic400.png 960w 1x, pic800.png 960w 2x,

[14:43:27.0000] <Hixie_>
 pic00.png 160 0w 1x, pic1600.png 3200w 1x, pic3200.png 1x,                                                                                                                                 pic1600.png 1600w 2x, pic3200.png 2x">

[14:43:31.0000] <Hixie_>
woah, bad spacing paste

[14:43:36.0000] <TabAtkins>
And I suspect we'll have quite a spectrum of densities for some time, supporting 3x and 4x alongside 1x and 2x.

[14:43:44.0000] <Hixie_>
http://damowmow.com/playground/demos/img/003.html

[14:44:11.0000] <Hixie_>
what _you_ want isn't really the point dude. i want a ton of stuff that we're not gonna get.

[14:44:48.0000] <TabAtkins>
Uh, yes, I understand.  What I'm saying, though, is that this is a useful thing that UAs can deliver to their users, and my syntax happens to give it for free in many cases, which is a good thing.

[14:45:05.0000] <TabAtkins>
The whole point of resolution discrimination is that bandwidth factors into things too.

[14:45:13.0000] <TabAtkins>
Otherwise this would be much easier.

[14:46:02.0000] <zewt>
("resolution discrimination"? seriously?)

[14:46:23.0000] <Hixie_>
*shrug*. i gotta go. bbiab. if you can convince authors and implementors to do this, then i guess i'll update the spec. but i think it's more complex, not especially less verbose, and doesn't solve compelling problems that aren't solved by the simpler srcset.

[14:47:17.0000] <TabAtkins>
zewt: You don't like the phrase?

[14:49:41.0000] <zewt>
sounds like "associate something I don't with something much worse, to make it sounds more important than it really is" (racial discrimination! sexual discrimination! resolution discrimination!)

[14:51:52.0000] <TabAtkins>
That sentence doesn't parse, so I'm not quite sure what you're trying to say.

[15:00:05.0000] <TabAtkins>
zewt: Can you fill in the missing word in your sentence?  Is it "like"?

[15:06:27.0000] <zewt>
... yes

[15:06:31.0000] <zewt>
(sorry, work)

[15:06:55.0000] <TabAtkins>
Oh.  In that case, I don't understand, because resolution discrimination is a good thing. ^_^

[15:07:27.0000] <zewt>
oh. sorry, I read it as "bandwidth discrimination" (work or irc: pick one)

[15:07:58.0000] <zewt>
okay, that does make more sense :P

[16:31:49.0000] <Hixie_>
anyone got IE? need to test http://www.hixie.ch/tests/adhoc/dom/level0/window/showModalDialog/005.html