2016-05-01
[20:42:43.0000] <Domenic>
Did https://philip.html5.org/tests/canvas/suite/tests/ ever make it into web platform tests?

[20:44:18.0000] <Domenic>
I guess https://github.com/w3c/web-platform-tests/tree/master/2dcontext seems pretty similar if you squint

[00:47:47.0000] <MikeSmith>
Domenic: yeah the wpt 2dcontext tests are the same Philip`’s

[00:48:06.0000] <MikeSmith>
there’s a build script to (re)generate them

[00:49:26.0000] <MikeSmith>
it’s one of the parts of the wpt suite where the process for revising the tests is not to edit the (generated) HTML files but instead edit the python sources and data files from whiche they’re generated

[00:58:26.0000] <Philip`>
Writing code is boring, it's much better to write code that writes code

[01:27:44.0000] <jgraham>
I like the pseudo-archaic "whiche"

[09:19:44.0000] <daFonseca>
hi, i have found a bot chanserv in some channels... is that a service from freenod? who can i acess this boot? to request @ for exemple?

[09:30:52.0000] <daFonseca>
-ChanServ- You are not authorized to (de)op daFonseca on #RPG.

[12:31:15.0000] <zcorpan>
MikeSmith: \o/


2016-05-02
[18:55:59.0000] <rniwa>
kochi: yt?

[18:56:02.0000] <rniwa>
hayato: yt?

[19:13:28.0000] <MikeSmith>
does anybody know if bloomberg and zdnet use the same technique or library to implement navigation transitions?

[19:16:08.0000] <rniwa>
ugh... what a shit show :( wordpress.com breaks if we make deepPath a method because they assume it's an attribute :(

[19:16:17.0000] <rniwa>
annevk: ^

[19:16:18.0000] <rniwa>
hayato: ^

[19:16:30.0000] <MikeSmith>
what I mean is if you go to http://www.zdnet.com/article/xerox-scanners-alter-numbers-in-scanned-documents/ and scroll past the end of that story to the next, the navigation seamlessly transitions to http://www.zdnet.com/article/ai-selfie-drone-takes-13mp-photos-and-4k-video-wows-gmic-beijing-2016/

[19:17:03.0000] <MikeSmith>
and if you scroll back up it navigates back to the URL of the first story

[19:17:54.0000] <MikeSmith>
rniwa: nice stuff, bravo once again for wordpress

[19:18:02.0000] <rniwa>
MikeSmith: yup :(

[19:18:19.0000] <MikeSmith>
rniwa: btw you are back in the US now right?

[19:18:28.0000] <rniwa>
MikeSmith: it's great that all these web devs are rushing to adopt the latest stuff without ever considering the possibility of it ever changing...

[19:18:30.0000] <MikeSmith>
I’m in Matsumoto this week

[19:18:34.0000] <MikeSmith>
yup

[19:18:35.0000] <rniwa>
MikeSmith: I am

[19:18:37.0000] <rniwa>
MikeSmith: oh enjoy!

[19:18:40.0000] <MikeSmith>
ah OK

[19:18:44.0000] <rniwa>
MikeSmith: oh, right, your wife is from Matsumoto, right?

[19:18:52.0000] <rniwa>
MikeSmith: enjoy your stay there :)

[19:18:57.0000] <MikeSmith>
thanks yeah it’s nice up here

[19:19:03.0000] <rniwa>
MikeSmith: I wanted to go to Matsumoto castle while I was in Japan but I didn't have a time

[19:19:11.0000] <MikeSmith>
yeah we are at her parents’ place

[19:19:25.0000] <rniwa>
MikeSmith: have you been to わさび農園?

[19:19:30.0000] <MikeSmith>
yeah Matsumoto castle is one of the nicest in Japan

[19:19:33.0000] <rniwa>
in 安曇野?

[19:20:14.0000] <MikeSmith>
I know 安曇野 but not わさび農園

[19:20:28.0000] <MikeSmith>
it is very close and my wife has a friend in that town

[19:20:34.0000] <MikeSmith>
so we will go

[19:21:28.0000] <rniwa>
MikeSmith: https://ja.wikipedia.org/wiki/大王わさび農場

[19:21:32.0000] <MikeSmith>
it’s a park or 牧場?

[19:21:38.0000] <MikeSmith>
/me looks

[19:21:42.0000] <rniwa>
MikeSmith: you can eat fresh Wasabi!

[19:21:47.0000] <MikeSmith>
oh

[19:21:48.0000] <MikeSmith>
nice

[19:21:52.0000] <rniwa>
It's pretty chill there

[19:21:54.0000] <MikeSmith>
yeah, will go for sure

[19:22:07.0000] <rniwa>
you can even make some わさび漬け there

[19:22:19.0000] <rniwa>
picking vegetables and wasabhi stems with nuka

[19:22:25.0000] <rniwa>
this is such a local topic LOL

[19:22:38.0000] <rniwa>
I feel bad for spamming #whatwg with it but whatever

[19:22:39.0000] <MikeSmith>
heh

[19:22:58.0000] <MikeSmith>
well it’s off-hours here anyway

[19:23:10.0000] <MikeSmith>
not sure hayato and kochi are the office today

[19:23:23.0000] <MikeSmith>
most people taking it as a holiday I think

[19:23:54.0000] <rniwa>
MikeSmith: oh that's right, it's golden week!

[19:24:10.0000] <rniwa>
this whole web components related new DOM feature has been such a mess!

[19:24:43.0000] <rniwa>
MikeSmith: e.g. s://github.com/whatwg/dom/issues/241

[19:24:53.0000] <MikeSmith>
no pain, no gain 😄

[19:25:20.0000] <MikeSmith>
/me looks at https://github.com/whatwg/dom/issues/241

[19:25:25.0000] <MikeSmith>
ah yeah saw that

[19:25:50.0000] <MikeSmith>
I hope hayato changes his mind on that one

[19:27:07.0000] <MikeSmith>
mailchimp.com is pretty widely used, and I think it is clear there are likely to be more

[19:27:20.0000] <rniwa>
MikeSmith: yup

[19:27:25.0000] <rniwa>
MikeSmith

[19:27:41.0000] <rniwa>
MikeSmith: the fact such a popular website got broken is a good indication that there are a lot more to come

[19:28:05.0000] <rniwa>
I don't really understand this whole discussion of wait & see if it's bad enough thing

[19:28:10.0000] <rniwa>
breaking any websites is bad :(

[19:28:33.0000] <rniwa>
the idea of "insignificant" number of websites being broken due to a new feature seems like an entirely misguided concept

[19:29:18.0000] <MikeSmith>
yeah, agreed

[19:29:36.0000] <MikeSmith>
wrong priorities

[19:30:34.0000] <rniwa>
it's one thing if the existing feature is broken between browsers but breaking a website with a brand new feature seems completely unwarrented

[19:33:24.0000] <rniwa>
MikeSmith: there's also: https://github.com/whatwg/dom/issues/23

[19:55:08.0000] <MikeSmith>
rniwa: yeah gotta agree with wycats there

[19:56:17.0000] <MikeSmith>
hoping this thing of google pushing through with changes that break web compat over of objections from web developers and other browser projects is not a trend

[20:00:12.0000] <Domenic>
That one's different, because timeStamp never worked cross-browser anyway

[20:01:09.0000] <rniwa>
Domenic: indeed, it's a little bit more nuanced but I don't think breaking existing code doesn't make much sense IMO

[20:01:23.0000] <rniwa>
there are a plenty of APIs we keep around even though we added a new thing

[20:01:25.0000] <Domenic>
rniwa: well, it was existing code that was already broken in Firefox and in some cases other browsers

[20:01:46.0000] <rniwa>
Domenic: that's just a bug in Firefox.

[20:02:02.0000] <Domenic>
sure, but it gives us room to upgrade the DOM into something better

[20:02:08.0000] <rniwa>
Domenic: we can't use one broken browser as an excuse to break code that was working in many other browses

[20:02:20.0000] <Domenic>
Hmm, I guess I disagree

[20:02:25.0000] <rniwa>
Domenic: I don't like the whole idea of "upgrading DOM"

[20:02:37.0000] <rniwa>
Domenic: that's just a synonym for breaking code that was working just fine.

[20:02:42.0000] <rniwa>
Domenic: it's quite ridiculous IMO.

[20:03:05.0000] <Domenic>
Well, as I said, I disagree

[20:03:09.0000] <rniwa>
Domenic: one of the reasons Web succeeded so well is because it kept backwards compatibility unlike other platforms

[20:03:19.0000] <Domenic>
I think taking something that didn't work the same everywhere, and making it better, is a good idea.

[20:03:20.0000] <rniwa>
Domenic: yeah i guess we agree to disagree there.

[23:10:22.0000] <rniwa>
MikeSmith, Domenic: sorry, I had to get out of a cafe in Berkeley earlier.

[23:10:54.0000] <rniwa>
MikeSmith, Domenic: FYI, https://github.com/whatwg/dom/issues/242

[00:07:30.0000] <smaug____>
which spec defines load event's special case for propagation these days?

[00:09:37.0000] <annevk>
smaug____: DOM

[00:10:11.0000] <annevk>
smaug____: 'A document’s get the parent algorithm, given an event, returns null if event’s type attribute value is "load" or document does not have a browsing context, and the document’s associated Window object otherwise.'

[00:11:32.0000] <smaug____>
thanks

[00:19:26.0000] <rniwa>
@annevk: it would be really useful to have cross-linking across HTML & DOM

[00:19:42.0000] <annevk>
rniwa: there generally is

[00:19:56.0000] <annevk>
rniwa: what's not linked?

[00:19:58.0000] <rniwa>
@annevk: or some sort of cross searching feature?

[00:20:33.0000] <rniwa>
@annevk: like... that question could easily be answered if load event's definition in HTML spec had all references including that one in DOM

[00:20:43.0000] <rniwa>
(or maybe it already has such a hyperlink?)

[00:21:03.0000] <annevk>
Well, the problem with events is that event names get reused

[00:21:10.0000] <annevk>
So there's no such thing as a "load" event

[00:21:15.0000] <annevk>
There's dozens

[00:21:21.0000] <annevk>
All with different semantics

[00:21:41.0000] <rniwa>
oh I see

[00:21:52.0000] <annevk>
And the special case in DOM applies to all of them, not just a particular one

[00:21:53.0000] <rniwa>
@annevk: what if we had full text search on specs?

[00:22:12.0000] <annevk>
rniwa: isn't that what a browser provides?

[00:22:23.0000] <rniwa>
@annevk: I can't do that across DOM & HTML though

[00:22:34.0000] <rniwa>
@annevk: as well as seemingly hundreads of CSS modules :(

[00:22:50.0000] <annevk>
Ah I see, a search engine solely for specs

[00:22:54.0000] <rniwa>
yea

[00:22:56.0000] <rniwa>
something like that

[00:23:11.0000] <rniwa>
@annevk: google kind of works but it finds all sorts of irrelevant stuff

[00:23:36.0000] <annevk>
I think with TabAtkins and plinss's linking infrastructure there could be something that finds all the terms and where they are defined

[00:23:51.0000] <annevk>
Still wouldn't really solve this case though

[00:25:08.0000] <rniwa>
@annevk: yeah, it would be super useful to have a W3C spec search engine

[01:37:28.0000] <rniwa>
annevk: yt?

[01:37:37.0000] <rniwa>
Ms2ger: yt?

[01:38:20.0000] <Ms2ger>
Ack

[01:38:34.0000] <annevk>
rniwa: yeah, I'm around

[01:38:59.0000] <rniwa>
@annevk, Ms2ger: I'm not sure if I'm reading the spec right but it looks like the new HTML spec text seems to indicate that document.currentScript is null

[01:39:15.0000] <rniwa>
if the script element happens to have been removed from the tree at the time of the script execution

[01:39:35.0000] <rniwa>
@annevk, Ms2ger: this is problematic for a script that gets momentarily inserted into a document and then removed

[01:39:47.0000] <rniwa>
because all browsers currently returns the "right" script element in this case.

[01:39:51.0000] <Ms2ger>
Do you have a test for it? :)

[01:40:36.0000] <Ms2ger>
I suspect this was intentional

[01:40:51.0000] <rniwa>
Ms2ger: can I send you a zip?

[01:40:57.0000] <rniwa>
Ms2ger: or would you prefer gist posts?

[01:41:15.0000] <annevk>
rniwa: I don't think that's true

[01:41:37.0000] <rniwa>
@annevk: https://html.spec.whatwg.org/multipage/scripting.html#execute-the-script-block

[01:41:37.0000] <annevk>
rniwa: currentScript is set to the script element, then the script is executed, then after it's executed it's set to its old value

[01:41:55.0000] <rniwa>
@annevk: well, the problem is that an async script could be inserted to a document

[01:41:56.0000] <rniwa>
then removed

[01:41:59.0000] <rniwa>
and then get executed

[01:42:14.0000] <rniwa>
@annevk: in that case, browsers currently return the script element while that async script executes

[01:42:28.0000] <annevk>
I see

[01:42:43.0000] <Ms2ger>
I prefer wpt PR

[01:43:00.0000] <rniwa>
Ms2ger: I don't have a cleaned up test case yet.

[01:43:06.0000] <annevk>
rniwa: so instead of "in a document" we want to test "whose root is not a shadow root"

[01:43:19.0000] <Ms2ger>
No hurry, but it would be nice to have one at some point

[01:43:26.0000] <annevk>
rniwa: file an issue?

[01:43:26.0000] <rniwa>
Ms2ger: definitely

[01:43:32.0000] <rniwa>
@annevk: will do

[01:43:40.0000] <annevk>
ta

[01:43:42.0000] <rniwa>
Ms2ger, @annevk: there is a subtle issue with that approach

[01:44:48.0000] <rniwa>
Ms2ger, @annevk: which is that then those script element that gets inserted and then removed before it gets executed will be running like an ordinary script element outside the shadow tree

[01:45:27.0000] <rniwa>
Ms2ger: I guess I can upload a PR anyway

[01:45:43.0000] <annevk>
rniwa: yeah, but since they can't leak shadow trees it seems okayish

[01:45:52.0000] <rniwa>
@annevk: hm...

[01:46:28.0000] <rniwa>
@annevk: but what if a script element was initally inserted into a document tree, then re-inserted into a shadow tree?

[01:46:33.0000] <rniwa>
(before it was executed)

[01:46:46.0000] <rniwa>
@annevk: would we then return null in document.currentScript?

[01:46:51.0000] <annevk>
rniwa: yeah

[01:46:57.0000] <annevk>
rniwa: it's root would be a shadow root

[01:47:24.0000] <rniwa>
@annevk: i guess that kind of makes sense

[01:47:36.0000] <rniwa>
you don't want to be exposing the script element in that case.

[01:47:55.0000] <annevk>
Yeah, otherwise it has all the problems of a normal script element in a shadow tree

[01:53:31.0000] <rniwa>
@annevk: https://github.com/whatwg/html/issues/1161

[01:54:04.0000] <rniwa>
@annevk, Ms2ger: right, okay, I'll adjust my test & code and put a PR up for wpt.

[01:55:01.0000] <Ms2ger>
Thanks!

[02:07:52.0000] <rniwa>
Ms2ger: here's a PR: https://github.com/w3c/web-platform-tests/pull/2934

[02:08:23.0000] <Ms2ger>
Thanks, will try to look later

[02:09:29.0000] <rniwa>
meanwhile I'm gonna sleep like a cat.

[05:19:14.0000] <annevk>
Can someone explain to me why in Firefox and Chrome, removing "overflow:hidden" removes the gap between the Test boxes and the red border: https://dump.testsuite.org/css/annevk-mobile-nav.html?

[05:19:38.0000] <annevk>
Seems like a bug of sorts

[05:23:28.0000] <iffy>
i am new in this channel

[05:24:21.0000] <iffy>
Anyone is new in web development

[05:24:40.0000] <iffy>
and wanna build website

[07:19:43.0000] <annevk>
jochen__: bit curious about https://github.com/w3c/webappsec-referrer-policy/pull/42

[07:19:52.0000] <annevk>
jochen__: afaik all implementers have to implement from WHATWG HTML

[07:20:35.0000] <annevk>
jochen__: why put effort into a fork that's a disaster from the get-go? https://annevankesteren.nl/2016/01/film-at-11

[07:21:04.0000] <annevk>
jochen__: seems like a waste of engineering resources

[10:38:43.0000] <Jasper>
Are there any other elements in HTML that can have link href behavior, other than a and area?\

[10:39:09.0000] <Jasper>
People always forget area, so I don't know if there are any more. I couldn't find anything with a quick look in the standard.

[10:39:14.0000] <annevk>
Jasper: what kind of behavior are you looking for?

[10:39:37.0000] <Jasper>
annevk, the link behavior. Gets a pointing cursor, and when you click on it, you navigate to the href in question.

[10:39:54.0000] <Jasper>
Can style it with :link, :visited, etc.

[10:39:55.0000] <annevk>
Jasper: <link>, in some UAs, iirc

[10:40:02.0000] <Jasper>
Hm, really?

[10:40:07.0000] <annevk>
(also per spec iirc)

[10:40:09.0000] <Jasper>
I thought that was for stylesheet and icon references...

[10:40:24.0000] <annevk>
It's certainly not just for that

[10:40:43.0000] <Jasper>
I guess I don't know what the <link> element is for then.

[10:41:31.0000] <annevk>
Works fine in Firefox

[10:41:40.0000] <annevk>
<style>link { display:block; width:10px; height:10px; background:red }</style>.<link href=image>

[10:41:44.0000] <Jasper>
Huh.

[10:53:21.0000] <gsnedders>
annevk: that's pretty weird, but I guess unsurprising if you style link with :link

[10:54:26.0000] <Jasper>
I'm genuinely surprised it gets the click-y behavior too.

[10:55:12.0000] <annevk>
Anyway, those and svg:a are the elements that have this kind of behavior

[10:57:54.0000] <MikeSmith>
annevk: https://lists.w3.org/Archives/Public/public-webappsec/2016May/0002.html

[10:58:13.0000] <MikeSmith>
> Accordingly, I believe it is appropriate to make normative reference[6]to Fetch as the SRI spec goes to Proposed Recommendation.

[11:02:15.0000] <annevk>
Wendy should not have to work on shit like that

[11:02:23.0000] <annevk>
I'm really surprised she puts up with it

[11:03:54.0000] <MikeSmith>
she has to put up with worse than that :)

[11:04:02.0000] <MikeSmith>
I do too

[11:04:16.0000] <MikeSmith>
as far as our job responsibilities go

[11:04:32.0000] <MikeSmith>
but that one certainly affected a lot more people

[11:04:39.0000] <MikeSmith>
and held up a lot more things

[11:05:06.0000] <annevk>
If you've done amazing things like Chilling Effects, I'm having a hard time seeing how you can be comfortable doing this

[11:05:21.0000] <annevk>
I guess I should ask if I make it to Lisbon

[11:05:23.0000] <MikeSmith>
yeah, that does put it into perspective

[11:06:44.0000] <MikeSmith>
but glad she finds a way, because she is a major asset to have on the team

[11:14:43.0000] <Domenic>
this isn't exactly a ringing precedent; it looks like this will have to continue to be fought for every spec, based on examining what terms are xrefed

[11:49:16.0000] <annevk>
It is rather strange


2016-05-03
[19:15:30.0000] <MikeSmith>
do any UAs support the as= attribute in e.g. <link rel=preload as=video href=...> ?

[19:15:59.0000] <MikeSmith>
and does anybody know the point of that attribute?

[19:16:23.0000] <MikeSmith>
it basically just seems to repeat the element name

[19:16:51.0000] <MikeSmith>
<link rel=preload as=script href=...>, <link rel=preload as=style href=...> etc

[19:16:56.0000] <MikeSmith>
http://w3c.github.io/preload/#attributes

[19:17:45.0000] <MikeSmith>
igrigorik_:

[19:17:59.0000] <MikeSmith>
igrigorik_: ⬆

[19:18:38.0000] <MikeSmith>
I am trying to decide whether to add support for as= to the HTML checker

[19:19:08.0000] <MikeSmith>
https://github.com/validator/validator/issues/276#issuecomment-216287257

[00:31:23.0000] <mkwst>
MikeSmith: Chrome supports that to some extent. yoav will have details.

[00:35:32.0000] <yoav>
MikeSmith: Yeah, Chrome supports it and the point is to start a Fetch for that resource with the proper destination so that it could be matched when later requested by an element uses that resource, fetched while taking the proper CSP directives into account, and with the right request headers (e.g. Accept)

[00:36:22.0000] <yoav>
`as` is the main difference between preload and its (not-very-useful) predecessor subresource

[00:41:13.0000] <zewt>
what happend to the whole "browsers try not to break pages" thing

[00:43:56.0000] <zewt>
(re: Object.observe suddenly going away in a chrome update and now android systrace is broken, and now I get to do the extra hazardous thing of updating Android tools near the end of a project and hoping everything doesn't explode)

[00:48:09.0000] <annevk>
zewt: they try, but not always succeed?

[00:48:34.0000] <annevk>
zewt: I think Object.observe() had a deprecation period of several releases

[00:48:48.0000] <annevk>
zewt: and it was never implemented by more than one browser, another sign it was rather unstable

[00:49:12.0000] <zewt>
all I care about at the moment is that a tool I was using regularly just stopped working, and as far as I can tell I'm just screwed

[01:04:21.0000] <annevk>
MikeSmith: spam at https://www.w3.org/Bugs/Public/show_bug.cgi?id=12845#c39

[01:12:21.0000] <zewt>
google sure is going to a lot of effort to make sure I can't do my job

[01:18:24.0000] <Cablegunmaster>
whats wrong zewt?

[02:15:02.0000] <Ms2ger>
annevk, yt?

[02:48:23.0000] <annevk>
Ms2ger: what's up?

[02:48:54.0000] <Ms2ger>
I was stupid enough to look into about:blank

[02:50:56.0000] <Ms2ger>
Do you think it would make sense to defined Document's "ready for post-load tasks" and "completely loaded" flag in DOM? Then we could set then explicitly for createDocument/createHTMLDocument/new Document()

[02:51:06.0000] <Ms2ger>
HTML seems to miss new Document() right now

[02:58:24.0000] <jochen__>
annevk: a) it's a W3C WG for better or worse

[02:58:48.0000] <Ms2ger>
w3c specs can reference whatwg specs

[02:58:50.0000] <jochen__>
annevk: and b) I think documenting all the places where the W3C html spec doesn't even satisfy the requirements of other W3C specs is a worthwhile execise

[02:59:13.0000] <jochen__>
it's problematic once you want to move beyond WD

[02:59:17.0000] <annevk>
Ms2ger: sounds reasonable

[02:59:23.0000] <jochen__>
see the SRI stuff currently going on

[02:59:57.0000] <jochen__>
https://lists.w3.org/Archives/Public/public-webappsec/2016May/0002.html

[03:00:30.0000] <Ms2ger>
Seems like it's not problematic?

[03:00:47.0000] <Ms2ger>
Anyway

[03:02:45.0000] <jochen__>
i'm not saying you're wrong

[03:02:51.0000] <jochen__>
i'm saying you're having the discussion with the wrong person

[03:03:12.0000] <jochen__>
you should totally bring this up on the mailing list

[03:06:39.0000] <Ms2ger>
I don't have time for that

[03:07:01.0000] <Ms2ger>
Also, the mailing list post you linked seemed to completely disprove your point

[04:57:18.0000] <smaug____>
whaat, browsers supporting focusin/out seem to dispatch them at really odd time

[04:57:26.0000] <smaug____>
totally against the spec

[05:00:30.0000] <annevk>
Is that the kind of specification where you have to read between the lines? Because last I checked they were not really defined... There's an open issue against HTML for them.

[05:02:26.0000] <smaug____>
it is defined

[05:03:25.0000] <smaug____>
but I'm seeing focusin dispatched after focus

[05:03:53.0000] <smaug____>
am I on crack here

[05:04:01.0000] <smaug____>
http://mozilla.pettay.fi/moztests/focusin_focusout.html is my testcase

[05:05:23.0000] <annevk>
Defined where?

[05:05:56.0000] <annevk>
That resource doesn't load for me by the way

[05:06:47.0000] <smaug____>
annevk: defined in UI events spec

[05:06:54.0000] <smaug____>
oh, what happened to pettay.fi

[05:07:41.0000] <annevk>
smaug____: that is rather hand wavy, e.g., it doesn't define the interaction with focus()/blur(), presumably not with autofocus="" either, or click(), etc.

[05:08:00.0000] <smaug____>
oh, sure, but at least it defines whether focusin should happen before focus etc

[05:08:21.0000] <annevk>
I guess that is something...

[05:23:05.0000] <annevk>
smaug____: any ideas for an alternative name for rootNode? Are you fine with the suggested alternatives? E.g., treeTop?

[05:23:53.0000] <smaug____>
treeTop would be ok

[05:24:31.0000] <smaug____>
not very great, but I don't think we can really find anything much better

[05:28:16.0000] <jgraham>
/me wonders what's wrong with rootNode

[05:28:26.0000] <jgraham>
(treeTop sounds very strange to me)

[05:28:50.0000] <jgraham>
/me isn't following wherever this discussion is happening

[05:29:36.0000] <smaug____>
jgraham: rootNode isn't compatible with the web

[05:29:51.0000] <smaug____>
it is being used by script libraries, apparently

[05:30:34.0000] <annevk>
jgraham: it's rather sad, https://github.com/whatwg/dom/issues/241

[05:30:44.0000] <Ms2ger>
Doh

[05:34:11.0000] <gsnedders>
when did the prescan move to being 1024? I remember it being 512, and that's what html5lib implements.

[05:34:13.0000] <jgraham>
FWIW I think the reason that treeTop doesn't match is because it's a screwy mental model were the top of the tree and the root of the tree are the same point

[05:37:17.0000] <annevk>
jgraham: interesting, why is that the wrong model?

[05:37:48.0000] <annevk>
jgraham: note that furthestAncestor doesn't work for the root itself

[05:38:06.0000] <jgraham>
annevk: Why doesn't it work for the root iself?

[05:38:30.0000] <annevk>
jgraham: you want root.rootNode === root

[05:38:52.0000] <jgraham>
annevk: I'm comfortable with the root being its own furtestAncestor

[05:39:07.0000] <annevk>
jgraham: hmm, the spec calls those inclusive ancestors

[05:39:15.0000] <jgraham>
More comfortable than I am with the top and the bottom of the tree being the same point

[05:39:45.0000] <jgraham>
annevk: Well no one reads the spec (apart from like a dozen implementors and language lawyers), so that doesn't seem like a very strong argument ;)

[05:40:57.0000] <annevk>
I suppose, but if ancestor is used elsewhere and means something different it'll be confusing

[05:41:14.0000] <jgraham>
Is it used elsewhere?

[05:41:58.0000] <jgraham>
(apart from XPath)

[05:44:12.0000] <annevk>
jgraham: I don't know

[05:48:10.0000] <jochen__>
anybody got an opinion about disallowing alert and friends in microtasks?

[05:48:24.0000] <mkwst>
jochen__: How about disallowing them in macrotasks too?

[05:48:34.0000] <jochen__>
the reasoning is that while an alert is displayed, if you e.g. resize the browser windows, all browser dispatch events at the web page

[05:48:48.0000] <jochen__>
which kinda violates the idea of microtasks being ran outside of the main message loop

[05:48:52.0000] <jochen__>
mkwst: working on that :)

[05:49:23.0000] <annevk>
jochen__: what kind of events?

[05:49:54.0000] <annevk>
jochen__: oh, I see what you mean

[05:50:45.0000] <jochen__>
resize for example

[05:50:52.0000] <jochen__>
or whatever happens to come in on the message loop

[05:51:23.0000] <jochen__>
i'm toying with the idea of blanked disallowing those apis: https://codereview.chromium.org/1940253002

[05:54:00.0000] <jgraham>
/me can't imagine much opposition to that

[05:54:09.0000] <jgraham>
Well unless it's already a compat issue

[05:54:51.0000] <Ms2ger>
Of course it is

[05:55:21.0000] <jgraham>
Ms2ger: In microtasks?

[05:55:33.0000] <jgraham>
I mean removing alert entirely is a huge compat issue ofc

[05:55:34.0000] <Ms2ger>
/me points at the topic

[06:08:48.0000] <gsnedders>
To answer my own question: https://github.com/whatwg/html/commit/51babfe760a1dbe28c4521b2070e692ac872550a

[06:17:55.0000] <MikeSmith>
annevk: thanks, banned that bugzilla spammer

[06:18:43.0000] <MikeSmith>
yoav, mkwst thanks I guess I’ll go ahead and add as= support to the HTML checker

[06:19:19.0000] <mkwst>
MikeSmith: Sorry. I told yoav  to stop being awesome and implementing new things, but he never listens to me. :(

[06:20:11.0000] <MikeSmith>
hahah

[06:20:33.0000] <MikeSmith>
you two are keeping the W3C in business

[06:21:30.0000] <mkwst>
I'm not sure that's a good thing?

[06:50:43.0000] <MikeSmith>
mkwst: I’ll leave that up to you to decide for yourself :)

[06:51:14.0000] <MikeSmith>
mkwst: by the way, have y’all moved to autopublishing for your specs yet?

[06:51:19.0000] <MikeSmith>
CSP, tc.

[08:05:45.0000] <yoav>
annevk: Hey! Is there a particular reason that "Accept-Encoding" is in the forbidden headers list in Fetch?

[08:06:10.0000] <yoav>
Are there security risks involved with SW changing it to add support to new codecs, etc?

[08:07:47.0000] <annevk>
yoav: I think one of the problems is that the browser handles that entire layer in principle

[08:08:15.0000] <yoav>
Oh, so content encoding gets decoded before the bytes get to SW?

[08:08:18.0000] <annevk>
yoav: we don't expose the content before content codings have been handled, and there's a number of schemes for which that would not even make sense, as I understand it

[08:08:21.0000] <annevk>
yoav: yes

[08:08:35.0000] <yoav>
got it! Thanks! :)

[08:08:49.0000] <annevk>
yoav: see "handle content codings"

[08:09:44.0000] <annevk>
invoked as "handling content codings" (though you can also click the definition to find where it's invoked)

[08:49:18.0000] <SimonSapin>
https://w3c.github.io/unicode-xml/#Bidi recommends browsers ignore Bidi Embedding control characters (since users are supposed to use markup instead), but they apparently don’t: data:text/html,&%23x202e;Test renders as tseT in both Firefox and Chromium

[08:50:49.0000] <SimonSapin>
so there’s probably content out there that rely on these code points

[08:57:34.0000] <MikeSmith>
zcorpan: (and others) Do we seriously really want to have the HTML checker emit a warning for every single document that’s missing a lang attribute on the HTML element?

[08:57:59.0000] <MikeSmith>
because once I add that is it going to instantly become the #1 most common error

[08:58:36.0000] <MikeSmith>
and I think some authors/developers are going to see it as noise

[08:59:29.0000] <MikeSmith>
on the other hand, if we think it is that important that every single document on the Web really should have a lang attribute on the html element, then I guess this would be a good way to help make that happen

[08:59:47.0000] <MikeSmith>
so maybe my question is, just how important is this to us?

[09:00:00.0000] <MikeSmith>
or how important is it for the Web

[09:00:20.0000] <MikeSmith>
what real problems does it solve for users in practice

[09:00:36.0000] <MikeSmith>
context is https://github.com/validator/validator/issues/284

[09:00:40.0000] <zcorpan>
MikeSmith: it affects users of AT primarily, when reading content that is in a different language than their system language

[09:00:55.0000] <MikeSmith>
and https://www.w3.org/Bugs/Public/show_bug.cgi?id=26942#c13

[09:01:03.0000] <MikeSmith>
zcorpan: OK

[09:01:09.0000] <zcorpan>
MikeSmith: i suppose that may be a smaller set of people than the people who will be annoyed about validator errors, i dunno

[09:01:25.0000] <MikeSmith>
/me reads recent comments at https://www.w3.org/Bugs/Public/show_bug.cgi?id=26942

[09:01:41.0000] <MikeSmith>
I hope this is just not another table@summary

[09:03:11.0000] <zcorpan>
i think what would be best for users is probably for ATs to do language analysis themselves, but that's not the situation today

[09:04:59.0000] <MikeSmith>
yeah, doing language analysis over an entire doc when you load it is a pretty big deal

[09:05:34.0000] <MikeSmith>
or even trying to programatically determine some subset to analyze

[09:05:49.0000] <zcorpan>
don't need to run it over the whole document, just a few words is typically enough to get a confident answer

[09:05:56.0000] <zcorpan>
iirc

[09:06:04.0000] <MikeSmith>
yeah but which words do you choose?

[09:06:34.0000] <zcorpan>
the words you're about to read next? :-)

[09:07:24.0000] <zcorpan>
imho this should also work if the user types into a textarea

[09:07:36.0000] <zcorpan>
MS Word deals with it

[09:08:11.0000] <zcorpan>
for spell checking, i mean

[09:09:04.0000] <zcorpan>
OS X has language detection for spell checking in general also

[09:12:17.0000] <jyasskin>
Chrome already detects languages to see if it should show the Translate prompt, and it has an extension API to do it (https://developer.chrome.com/extensions/tabs#method-detectLanguage). I wonder if we should synthesize lang attributes, or an equivalent aria attribute...

[09:13:03.0000] <MikeSmith>
zcorpan: it is a lot easier to do in that case than in the case of trying to analyze text nodes in document order in real time as I parse a document

[09:13:29.0000] <MikeSmith>
do I just check the first text node? or the first 10 text nodes? or what

[09:23:24.0000] <MikeSmith>
I feel like this should be a separate tool

[09:23:51.0000] <jgraham>
It totally seems like the AT should try to do the linguistic analysis here

[09:23:53.0000] <MikeSmith>
that users could opt into

[09:24:31.0000] <MikeSmith>
jgraham: yeah well as we know the vendor of the most widely used AT is not going to add it

[09:25:05.0000] <MikeSmith>
I now am wondering if Richard Ishida has not already implemented a tool for doing this

[09:25:13.0000] <jgraham>
Would be nice if eventually the most widely used AT wasn't any more due to others implementing better features

[09:35:33.0000] <MikeSmith>
NVDA devs are trying

[09:57:40.0000] <MikeSmith>
jyasskin: do you have any idea how much of the text of a document Chrome checks before showing the Translate prompt?

[09:57:50.0000] <MikeSmith>
or what it checks?

[09:58:15.0000] <MikeSmith>
I am wondering if there is some existing literature on how best to do this for HTML documents

[10:00:45.0000] <jyasskin>
MikeSmith: I haven't worked on the system, but it is open source. ;)

[10:00:56.0000] <MikeSmith>
OK

[10:01:11.0000] <MikeSmith>
will look at the sources

[10:05:34.0000] <gsnedders>
language detection of single-language strings is pretty much solved by now, and it's certainly practical to run over the entire doc, cost isn't that high

[10:07:07.0000] <gsnedders>
the problem is you can't guarantee a single HTML page is a single language

[10:09:36.0000] <Mek>
https://sites.google.com/a/chromium.org/dev/developers/design-documents/translate doesn't seem to have been updated since it's initial version, so no idea if that still bears any resemblance to the implementation

[10:10:31.0000] <MikeSmith>
gsnedders: it is not practical for me if I am not building a DOM or any other in-memory representation

[10:12:22.0000] <MikeSmith>
the checker only does anything with text nodes at all just for particular elements that the spec puts requirements on the text content of

[10:13:44.0000] <MikeSmith>
and the checker is currently extremely fast and it is hard to see how doing this is any form is not going to add a measurable performance cost

[10:14:08.0000] <MikeSmith>
Mek: thanks will look at it anyway

[10:14:44.0000] <MikeSmith>
hmm, “The renderer already extracts the text from each loaded page for indexing purpose”

[10:16:05.0000] <gsnedders>
MikeSmith: there's some silly fast and accurate langid tools out there, but maybe not practical

[10:49:36.0000] <Domenic>
yoav: up for reviewing https://github.com/whatwg/html/pull/1141? :)

[10:59:07.0000] <yoav>
Domenic: will review later tonight. Seems like the email fell through my mail filters... :/

[11:01:21.0000] <Domenic>
\o/

[12:06:17.0000] <Domenic>
I wonder why IDL has so many special cases for RegExp objects

[12:18:21.0000] <caitp>
you mean like `If V is a native RegExp object, then throw a TypeError.`

[12:18:22.0000] <caitp>
?

[12:19:27.0000] <SimonSapin>
TabAtkins: which SVG spec should I look at for a new implementation?

[12:20:37.0000] <SimonSapin>
or, is the SVG 2 draft mostly additive or does it rewrite the basic stuff?

[12:23:06.0000] <gsnedders>
SimonSapin: it drops some of the stuff nobody really supports and makes optional stuff that people want to get rid of, mostly

[12:23:12.0000] <gsnedders>
SimonSapin: I /think/ it's probably the best reference

[12:24:56.0000] <SimonSapin>
(I’m thinking of making a toy implementation to play/experiment with some stuff. Nothing that’s gonna ship :))

[12:42:58.0000] <jyasskin>
MikeSmith: I'd read your initial discussion as wanting to decide whether your checker should check for a lang= attribute, and was arguing for not-checking because browsers can fairly straightforwardly infer the language without that attribute. Later it looks like you're trying to make the checker infer the lang= attribute, which my and Mek's comments don't

[12:42:58.0000] <jyasskin>
help as much with.

[12:57:04.0000] <gsnedders>
annevk: URL spec doesn't allow fatal handling of errors? :(

[12:58:20.0000] <Domenic>
caitp: yeah, it's everywhere. Any object is allowed to be treated as an implementation of a callback interface.... except RegExps.

[13:07:20.0000] <caitp>
webidl seems to distinguish between "a native RegExp" and a RegExp type

[13:07:32.0000] <caitp>
for some reason

[13:07:42.0000] <caitp>
I dunno, interesting

[13:36:46.0000] <Domenic>
I think one is the Web IDL type corresponding to the JS type

[13:36:55.0000] <Domenic>
Just like there is a Web IDL boolean type with two possible values, true and false

[13:37:01.0000] <Domenic>
Guess how you convert a Web IDL boolean to a JavaScript value

[13:37:03.0000] <Domenic>
Guess

[13:37:08.0000] <Domenic>
I bet you can't guess

[13:37:27.0000] <Domenic>
(sorry, I am being weird)

[13:49:02.0000] <caitp>
is it not the ToBoolean internal op because webidl thinks it has to be able to support non-JS languages too?

[13:52:35.0000] <Domenic>
it is: if the value is the IDL boolean value true, return the JavaScript value true. If the value is the IDL boolean value false, return the JavaScript value false.

[13:52:57.0000] <Domenic>
ToBoolean is for the other direction, JS values -> IDL boolean values.

[13:53:26.0000] <caitp>
ah

[13:53:52.0000] <Domenic>
Basically, the separate type system seems pretty silly sometimes. But I am not sure I have a principled alternative.

[13:54:20.0000] <Domenic>
Something about it all being JavaScript values and just doing conversions between them (like ToBoolean) when necessary

[14:03:07.0000] <rniwa>
annevk: yt?

[14:34:13.0000] <jyasskin>
Do we have any patterns yet for events that you might want to register for from the foreground but receive in a designated Worker? I see http://w3c.github.io/push-api/#the-push-event, which is done with a dedicated manager on ServiceWorkerRegistration, but that doesn't give the page much flexibility.

[15:29:45.0000] <Domenic>
jyasskin: I don't think we have any patterns that have received wide review and approval. The service worker specs and maybe some houdini specs are probably leading the way here. A survey of what all they're doing would be nice.

[16:09:01.0000] <gsnedders>
uhhhh

[16:09:10.0000] <gsnedders>
so it turns out that reparsing to change the encoding never actually worked in html5lib

[16:09:13.0000] <gsnedders>
o_O


2016-05-04
[21:12:08.0000] <MikeSmith>
jyasskin: while browsers can infer the language without lang=, accessibility software / screen readers like JAWS do not, which leads to a lot of problems for users who do their browsing with those

[21:14:14.0000] <MikeSmith>
jyasskin: one common problem is that the lang value does not actually match the language of the content of the page (due to authors cargo-cult copy/pasting the html element and attributes from, e.g., a lang=en page into a page whose contents are actually in Chinese or whatever

[21:16:16.0000] <MikeSmith>
jyasskin: so in order to help authors catch those kinds of mistakes, and help users of screen readers, the proposal is that the HTML checker would do language detection on the content of each document, and warn if the lang value does not match the detected language

[21:19:03.0000] <jyasskin>
Oh, it doesn't use the browser's accessibility tree? That would break my suggestion, yeah.

[21:19:51.0000] <MikeSmith>
I don’t know that the detected lang information gets into the accessibility tree from the browser

[21:20:29.0000] <MikeSmith>
but anyway the best solution to the problem for screen-reader users would be if screen readers also did language detection the way that browsers do

[21:20:49.0000] <MikeSmith>
because of course they operate on content other than Web content

[21:20:56.0000] <jyasskin>
But second-best might be the browsers putting detected information into the tree.

[21:21:01.0000] <MikeSmith>
yeah

[21:27:10.0000] <MikeSmith>
jyasskin: btw do you know what Chrome does in cases where the lang value does not match the detected language? I mean as far as the Translate prompt or any other user interaction? Does it just ignore the lang value?

[21:27:47.0000] <jyasskin>
I don't know offhand. I'd guess it ignores the lang value, especially if it's 'en', but would have to check.

[21:27:53.0000] <MikeSmith>
OK

[21:28:56.0000] <MikeSmith>
well if it does just ignore it, that suggests the presence of top-level html@lang is not actually very useful in practice on the Web (though having lang values on other sections of the document that are in other languages would be)

[21:35:24.0000] <MikeSmith>
it is sad that so many of our discussions about making user experience better for screen-reader users come down to, “Vendors of screen readers can’t or won’t make their products smarter, so let’s all do a bunch of extra work in N different browsers and other tools to work around all the longstanding deficiencies in screen readers.”

[21:41:33.0000] <jyasskin>
MikeSmith: After searching, the code to detect the page's language does use the declared lang attribute and Content-Language HTTP header: https://code.google.com/p/chromium/codesearch/#chromium/src/components/translate/core/language_detection/language_detection_util.cc&l=184. Once the language is detected, the rest of Chrome appears to only use the return

[21:41:34.0000] <jyasskin>
value of DeterminePageLanguage() to drive the actual translation.

[21:42:37.0000] <MikeSmith>
jyasskin: OK, thanks

[21:43:14.0000] <MikeSmith>
yeah that makes sense, given that the lang value and header really should not be trusted

[21:44:52.0000] <MikeSmith>
but that makes me really wary about having the HTML checker warn about a missing html@lang value. Given the circumstances, Not sure how helpful that will actually be for end users in practice

[21:45:33.0000] <MikeSmith>
I mean without having the checker also implement language detection

[21:48:00.0000] <MikeSmith>
I think I should probably only have the checker emit a warning for missing lang if it is able to detect the language, so the warning would be of the form, “The contente of this document appears to be in Chinese, consider putting an lang=zh value on the html element.”

[22:00:56.0000] <tantek>
MikeSmith: that seems reasonable

[22:04:47.0000] <MikeSmith>
just wish I had a streaming langague-detection library

[22:05:32.0000] <MikeSmith>
I guess I could write a streaming implementation on top of an existing library

[22:52:15.0000] <annevk>
rniwa: am now...

[23:20:49.0000] <annevk>
Ugh, Permissions API going straight for the API instead of figuring out the model is biting us now 😟

[23:22:17.0000] <annevk>
I wonder when we'll learn that in order to make a good API you first need to figure out how the system works

[23:32:22.0000] <rniwa_>
@annevk: I was gonna ask you about this: https://github.com/w3c/webcomponents/issues/494

[23:33:52.0000] <rniwa_>
:( why are we keep finding all these new problems

[23:35:12.0000] <annevk>
rniwa_: because monkey patching doesn't really work in engineering...

[23:35:49.0000] <rniwa_>
@annevk: huh, we do monkey patching all the time and it works

[23:36:11.0000] <rniwa_>
@annevk: I think the problem here was that Google for the longest time worked on these specs on their own & also implemented things

[23:36:25.0000] <annevk>
rniwa_: we do?

[23:36:29.0000] <rniwa_>
@annevk: and they didn't benefit from having other vendors reading & verifying specs & implementations

[23:36:45.0000] <rniwa_>
@annevk: at my work that is re: monkey patching

[23:36:49.0000] <annevk>
rniwa_: sure, that's part of it too

[23:37:21.0000] <annevk>
rniwa_: maybe the definition we use in standards https://annevankesteren.nl/2014/02/monkey-patch differs from the definition Apple uses?

[23:40:55.0000] <MikeSmith>
TabAtkins or astearns or somebody, where is @supports defined?

[23:41:29.0000] <rniwa_>
@annevk: we run scripts after applying a patch to the script

[23:41:35.0000] <MikeSmith>
nm found https://drafts.csswg.org/css-conditional-3/#at-supports

[23:41:41.0000] <rniwa_>
@annevk: or at runtime, we override some other class's selectors in objective-c LOL

[23:41:57.0000] <annevk>
MikeSmith: aww, just found it too

[23:43:00.0000] <annevk>
rniwa_: yeah, I guess I'm saying that if you write standards that way, it's gonna suck

[23:43:25.0000] <MikeSmith>
annevk: yeah @supports seems like a handy feature

[05:17:01.0000] <Ms2ger>
annevk, you make a good point; thoughts on where to put it?

[05:20:04.0000] <annevk>
Ms2ger: I usually put it above the first instance if there's no good place

[05:20:34.0000] <annevk>
Ms2ger: also, use ", then ..." after if statements

[05:20:45.0000] <annevk>
Ms2ger: looked good to me otherwise

[05:22:15.0000] <Ms2ger>
Will do in a bit

[09:17:52.0000] <TabAtkins>
MikeSmith: For future help in finding where things are defined: https://drafts.csswg.org/indexes/

[09:18:15.0000] <MikeSmith>
/me looks at https://drafts.csswg.org/indexes/

[09:18:17.0000] <MikeSmith>
w00t

[09:18:21.0000] <MikeSmith>
TabAtkins: much thanks

[09:21:44.0000] <TabAtkins>
SimonSapin: Yes, SVG2 is the best reference. It's SVG1 plus new things minus dumb things and with some stuff rewritten to be better.

[09:54:06.0000] <AutomatedTester>
so Trump is the last GOP candidate...

[10:25:46.0000] <boogyman>
AutomatedTester: wrong channel

[10:25:59.0000] <AutomatedTester>
boogyman: so it is...

[10:26:02.0000] <AutomatedTester>
my bad

[10:26:06.0000] <AutomatedTester>
sorry all

[13:43:45.0000] <rniwa>
annevk: yt?

[13:44:57.0000] <rniwa>
Domenic: yt?

[13:45:06.0000] <Domenic>
rniwa: yep

[13:45:15.0000] <rniwa>
Domenic: what a shit show we're in :(

[13:45:19.0000] <Domenic>
yeah :(

[13:45:24.0000] <rniwa>
Domenic: TinyMCE 4.3.10 shipped with a wrong use of rootNode

[13:45:34.0000] <Domenic>
it's hard for me to understand why everything is breaking because of rootNode/deepPath

[13:45:38.0000] <Domenic>
what coding patterns are causing this

[13:45:42.0000] <Domenic>
ugh

[13:45:48.0000] <Domenic>
(i don't really want to know)

[13:45:59.0000] <rniwa>
Domenic: oh, doing if (event.deepPath) event.target = event.deepPath[0]

[13:46:10.0000] <rniwa>
Domenic: which is obviously undefined :(

[13:46:19.0000] <Domenic>
oh right the attribute to function switch

[13:46:23.0000] <Domenic>
i guess that's not completely crazy

[13:46:29.0000] <Domenic>
they're trying to feature test

[13:46:32.0000] <rniwa>
Domenic: I don't even know the point of that code because event.target would have that value anyway

[13:46:38.0000] <Domenic>
lol true

[13:46:43.0000] <rniwa>
Domenic: except nobody supported deepPath with v1

[13:46:51.0000] <rniwa>
Domenic: as an attribute :(

[13:47:06.0000] <Domenic>
but in general code in the form `if (something.chromeSpecificAttribute) { use(something.chromeSpecificAttribute); }` is not crazy

[13:47:09.0000] <rniwa>
Domenic: so it seems that they were speculatively using the feature...

[13:47:13.0000] <rniwa>
Domenic: oh sure

[13:47:18.0000] <Domenic>
Ideally nobody writes chrome-specific code, but in the real world, people do

[13:47:42.0000] <Domenic>
flatPath or flattenedPath or whatever seems reasonable...

[13:48:10.0000] <Domenic>
or we just declare that from now on all new platform properties have to be symbols

[13:48:20.0000] <rniwa>
Domenic: I like piercingPath though

[13:48:33.0000] <Domenic>
hmm yeah that's pretty good.

[13:48:45.0000] <rniwa>
Domenic: flat is a bit misleading in the sense that it could contain unslotted contents for events.

[13:48:51.0000] <Domenic>
ah, i see

[13:49:15.0000] <rniwa>
Domenic: composedPath has the same issue I pose

[13:49:26.0000] <rniwa>
and I don't think we refer to "composition" anywhere else so that's also somewhat misleading

[13:49:36.0000] <Domenic>
introducing a new "piercing" concept is a bit annoying but if it's truly a new concept then it makes sense

[13:52:43.0000] <rniwa>
Domenic: well, we do still have shadow piercing combinators in dynamic profile of CSS selectors

[13:52:55.0000] <Domenic>
oh, true!

[13:52:58.0000] <Domenic>
that's nice

[13:53:02.0000] <rniwa>
Domenic: regardless of our opposition to the feature

[13:53:15.0000] <rniwa>
Domenic: the terminology seems to exist elsewhere

[14:22:05.0000] <Domenic>
terinjokes: robertkowalski: one of you want to fix https://github.com/whatwg/console/issues/54 ? should be a pretty simple IDL change :)

[14:24:21.0000] <terinjokes>
Domenic: making it now, was just revieiwng my GH notifications for today

[14:24:28.0000] <Domenic>
\o/

[14:24:47.0000] <Domenic>
It's pretty sweet how this spec is actually making implementers start wanting to converge

[14:24:54.0000] <terinjokes>
yay!

[14:24:55.0000] <Domenic>
Not to mention getting unbound console methods

[14:25:02.0000] <Domenic>
i didn't think that was going to happen

[14:25:18.0000] <Domenic>
then all of a sudden chrome and webkit both are like 'yes let's do it, look at this long issue where people are asking if we can. we totally can.'

[14:27:59.0000] <terinjokes>
merged the PR for CoC. Forgot I had left that opened

[14:31:19.0000] <Domenic>
https://github.com/whatwg/console/issues/56 might make sense to fix too

[14:33:37.0000] <terinjokes>
i agree

[14:34:44.0000] <terinjokes>
Domenic: think i should open a PR for the IDL namespace change to, or hold off for now?

[14:34:58.0000] <Domenic>
terinjokes: so I think if you actually change the IDL it will break Bikeshed -_-

[14:35:22.0000] <terinjokes>
i meant add the note

[14:35:23.0000] <Domenic>
terinjokes: that was why I was thinking of a warning or something while I update IDL and then someone will update the Web IDL parser bikeshed uses and then bikeshed will update

[14:35:25.0000] <Domenic>
ah yeah

[14:35:33.0000] <Domenic>
go for it

[14:35:53.0000] <terinjokes>
wonder what various UAs do for missing labels in count

[14:36:57.0000] <Domenic>
good question


2016-05-05
[21:02:51.0000] <rniwa>
dglazkov: https://github.com/whatwg/dom/issues/241 is where we track rootNode regression

[21:38:06.0000] <MikeSmith>
rniwa: oh, so blink did revert it?

[21:38:28.0000] <MikeSmith>
ah yeah

[21:38:32.0000] <MikeSmith>
/me sees https://github.com/whatwg/dom/issues/241#issuecomment-217072501

[21:41:24.0000] <annevk>
I like radicle

[21:43:05.0000] <annevk>
I have the feeling though that without root folks will just iterate the parent chain

[21:56:10.0000] <rniwa>
MikeSmith: yup

[21:56:35.0000] <rniwa>
@annevk: radicle?

[21:58:12.0000] <MikeSmith>
what is radicle?

[21:58:30.0000] <rniwa>
@annevk: I think radicle is a sufficiently unusual word that people outside the English speaking wouldn't even find it

[21:58:39.0000] <rniwa>
speaking world*

[21:58:40.0000] <MikeSmith>
and rniwa how come you put @ in front of nicks sometimes?

[21:59:03.0000] <rniwa>
MikeSmith: I don't know that's how annevk's name show up

[21:59:12.0000] <rniwa>
oh, wait... I think that's a quirk in my IRC client :(

[21:59:13.0000] <MikeSmith>
rniwa: I think even people in the English-speaking world do not know what radicle is

[21:59:14.0000] <rniwa>
ugh...

[21:59:31.0000] <MikeSmith>
rniwa: ah yeah I think it is just because annevk is an op

[21:59:43.0000] <MikeSmith>
I thought you were doing it on purpose

[22:00:06.0000] <MikeSmith>
is radicle some CS term

[22:00:18.0000] <MikeSmith>
is it not the way the math term is spelled, right?

[22:00:35.0000] <MikeSmith>
botany wtf

[22:02:59.0000] <annevk>
I am not seriously suggesting it, I just like the word

[22:03:06.0000] <annevk>
Blame miketaylr

[22:05:53.0000] <MikeSmith>
rhizome

[22:05:59.0000] <rniwa>
annevk: I think we should pick either treeTop or highestNode

[22:06:16.0000] <MikeSmith>
crux

[22:07:22.0000] <MikeSmith>
rniwa: the problem with treeTop is that tops of (real) trees are... leaves

[22:07:38.0000] <MikeSmith>
why not treeRoot

[22:08:01.0000] <rniwa>
MikeSmith: unfortunately, that name is also quite popular in Github

[22:08:19.0000] <MikeSmith>
ah OK

[22:08:30.0000] <MikeSmith>
I guess baseNode probably is too

[22:08:52.0000] <MikeSmith>
or deepestNode

[22:08:54.0000] <rniwa>
MikeSmith: 24,242 hits

[22:09:03.0000] <rniwa>
MikeSmith: deepestNode sounds like a leaf

[22:09:25.0000] <rniwa>
MikeSmith: we usually say going up a tree to mean going to the root in ADT sense

[22:09:26.0000] <MikeSmith>
rniwa: I guess I think more in terms of real trees

[22:10:20.0000] <MikeSmith>
yeah but that is teh opposite of what how we normally look at trees intuitievly, so it is ambiguous

[22:10:44.0000] <MikeSmith>
anyway, I give up because it seems like all the right terms are already in use

[22:10:54.0000] <rniwa>
MikeSmith: https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminologies_used_in_Trees

[22:11:03.0000] <rniwa>
MikeSmith: root is the top node

[22:11:08.0000] <rniwa>
MikeSmith: but I can understand your sentiment

[22:11:43.0000] <MikeSmith>
yeah they should call ADT trees upsideDownTrees

[22:11:45.0000] <miketaylr>
annevk: radical is even better

[22:12:35.0000] <MikeSmith>
oldestNode

[22:12:57.0000] <rniwa>
MikeSmith: that sounds like the oldest node in the creation order

[22:13:06.0000] <MikeSmith>
but I guess that doesn’t work either

[22:13:08.0000] <MikeSmith>
rniwa: yeah

[22:13:17.0000] <rniwa>
how about nodeAtRoot!

[22:14:36.0000] <MikeSmith>
oh

[22:15:11.0000] <MikeSmith>
yeah

[22:15:37.0000] <MikeSmith>
Google is nearly completely unaware of that string

[22:16:10.0000] <MikeSmith>
https://github.com/search?q=%22nodeAtRoot%22&type=Code&utf8=%E2%9C%93 shows only 1 hit

[22:16:33.0000] <rniwa>
same thing as treeTop

[22:16:37.0000] <rniwa>
and highestNode

[22:17:16.0000] <MikeSmith>
I like nodeAtRoot better than those

[22:17:26.0000] <rniwa>
or treeTopNode?

[22:18:15.0000] <MikeSmith>
Tree Top sounds like the name of a blues piano player

[22:18:46.0000] <MikeSmith>
Mike "Tree Top" Taylor at the piano

[22:21:41.0000] <rniwa>
MikeSmith, annevk: another option is to make a method and rename it to findRootNode or something

[22:22:05.0000] <rniwa>
MikeSmith, annevk: since this attribute needs to the work of walking up the ancestor chain in many cases, it's not O(1) operation anyway

[22:22:16.0000] <rniwa>
unlike things like .shadowRoot and .document

[22:22:48.0000] <annevk>
With a method we could add pierces:true at some point…

[22:23:02.0000] <rniwa>
annevk: indeed.

[22:23:14.0000] <annevk>
Not a bad idea

[22:26:09.0000] <rniwa>
annevk: oh, better yet, we can even find the highest node that matches a given criteria

[22:26:30.0000] <rniwa>
annevk: like... findRootNode('div .foo')

[22:26:55.0000] <rniwa>
annevk: or findRootNode(function (node) { return node.contentEditable; })

[22:29:12.0000] <rniwa>
annevk: btw, could you update https://github.com/w3c/webcomponents/issues/495 if you know of any other issues we need to resolve for v1?

[22:29:37.0000] <rniwa>
annevk: it's getting harder to track all the issues related to shadow DOM and I don't want to forget fix things in WebKit / write tests

[22:30:39.0000] <annevk>
rniwa: yeah, will do later today

[22:30:46.0000] <rniwa>
annevk: thanks

[22:31:05.0000] <rniwa>
ttyl, guys

[22:31:07.0000] <annevk>
.closest() exists

[22:31:38.0000] <annevk>
Maybe .closest(":root") is the way to get root

[23:58:32.0000] <annevk>
It's not

[00:24:27.0000] <smaug____>
annevk: https://github.com/whatwg/dom/issues/242#issuecomment-216115262

[00:24:39.0000] <smaug____>
so I'm missing now where someone objects 'composed'

[00:25:16.0000] <annevk>
earlier today on IRC rniwa mentioned he didn't like composed

[00:25:35.0000] <smaug____>
aha

[00:25:52.0000] <annevk>
smaug____: http://logs.glob.uno/?c=freenode%23whatwg&s=4+May+2016&e=5+May+2016#c994215

[00:26:36.0000] <smaug____>
I know composed and composition is all a buzz-wordy thing

[00:26:44.0000] <annevk>
I'm at the point where I have stopped caring and am just getting annoyed, so I should probably take a break

[00:33:01.0000] <smaug____>
(we should have just used 'composed' consistently everywhere. isInComposedDocument, composedPath ...)

[00:33:04.0000] <smaug____>
oh well

[00:36:50.0000] <heycam>
annevk: saw the comment on open ended dictionary but didn't get a chance to think about it properly. commented on the issue, but will see if I get a chance to think about it more tomorrow.

[00:37:33.0000] <annevk>
heycam: kk

[00:38:15.0000] <annevk>
smaug____: yeah, naming is hard. Naming when reasonable names break the web is nigh impossible.

[00:39:12.0000] <annevk>
smaug____: with that naming scheme we would have had composedDocumentInsertedCallback?

[00:45:32.0000] <smaug____>
why would there need to be such

[00:45:59.0000] <smaug____>
connectedCallback should have deal with all the ancestor changes, not just binding to document

[00:46:25.0000] <annevk>
smaug____: that's not how it's defined and agreed upon...

[00:46:33.0000] <annevk>
smaug____: you were at the meeting

[00:47:00.0000] <smaug____>
I disagreed wit the resolution, but gave up with fighting

[00:47:34.0000] <annevk>
Except when we're discussing hypothetical names?

[00:50:05.0000] <smaug____>
hypothetical names? annevk is cranky today ? :)

[00:51:01.0000] <annevk>
ding ding ding

[00:51:40.0000] <smaug____>
though, I can totally see web components making people cranky. After 15 years of web components, we're still in progress to figure out how it all should work.

[04:22:45.0000] <gsnedders>
does the meta encoding prescan work correctly for ISO-2022-JP?

[04:29:23.0000] <annevk>
gsnedders: it doesn't account for it, right?

[04:33:26.0000] <gsnedders>
annevk: no, it doesn't. but ASCII bytes are encoded as ASCII, right? or can they be encoded in other ways too? so it should always pick up a <meta charset>, but it might pick up something bogus too?

[04:34:28.0000] <gsnedders>
/me doesn't have a good memory as to how ISO-2022-JP works

[04:34:31.0000] <annevk>
gsnedders: it might pick up something bogus, but I haven't verified whether that is the case and I'm not aware of anyone else researching it either

[04:34:45.0000] <annevk>
gsnedders: https://encoding.spec.whatwg.org/#iso-2022-jp

[04:36:30.0000] <gsnedders>
annevk: okay, I'll look into this at some point

[04:37:00.0000] <gsnedders>
annevk: just wondering about how well encoding detection works; UTF-16 can safely be dealt with by BOMs leaving only ISO-2022-JP as the interesting case

[04:37:21.0000] <annevk>
gsnedders: since 0x20 is required and not a thing for non-ASCII ISO-2022-JP I suspect you cannot really pick up something bogus

[04:39:02.0000] <MikeSmith>
annevk: http://stackoverflow.com/questions/37048440/what-is-the-explanation-for-this-inconsistent-behavior-related-to-document-domai

[04:39:05.0000] <gsnedders>
annevk: ok, therefore it works fine? good to know.

[04:40:28.0000] <annevk>
gsnedders: I suspect so, you can only have incorrectly identified ASCII bytes in the 0x21-0x5F range for ISO-2022-JP

[04:42:38.0000] <gsnedders>
annevk: thx!

[04:43:57.0000] <annevk>
MikeSmith: answered

[04:44:30.0000] <annevk>
MikeSmith: I've also answered some CORS questions at some point, folks are still upvoting those...

[04:44:43.0000] <annevk>
MikeSmith: mainly why I now have over a thousand points on stackoverflow I think

[04:48:35.0000] <MikeSmith>
good

[04:48:52.0000] <MikeSmith>
people need the help

[04:49:03.0000] <MikeSmith>
so it’s a measure of real gratitude

[04:50:50.0000] <MikeSmith>
but yeah in this case I guess part of the answer is just “Don’t use document.domain”

[05:25:26.0000] <annevk>
MikeSmith: I've clarified the credentials case around CORS a bit btw and just submitted a PR for more examples (based on a contribution by Rory from Akamai)

[05:27:07.0000] <MikeSmith>
yeah, saw that

[05:27:25.0000] <MikeSmith>
I think that will really help

[05:29:17.0000] <MikeSmith>
the biggest problems people actually have on SO with CORS is not CORS itself, but just specific to whatever server-side environment/CMS/whatever they are using, and trying to figure out how to get that send the right headers under the right conditions

[05:29:37.0000] <annevk>
yeah

[05:29:42.0000] <annevk>
That was my impression too

[05:29:49.0000] <annevk>
And sometimes subtle browser bugs

[05:30:33.0000] <MikeSmith>
yes that too

[07:24:39.0000] <dglazkov>
\o/

[07:46:09.0000] <annevk>
hey dglazkov, I can see now why you quit pushing the components wagon for a bit

[07:46:18.0000] <annevk>
dglazkov: it can get rather frustrating

[07:48:27.0000] <annevk>
dglazkov: having said that, we're closer than ever before I think

[07:49:50.0000] <dglazkov>
😀

[07:50:10.0000] <dglazkov>
Thank you for pushing the train!

[08:16:31.0000] <TabAtkins>
Domenic: "All new platform properties have to be symbols" yes plz thx

[08:18:13.0000] <TabAtkins>
Domenic: What IDL change will break Bikeshed?

[08:20:53.0000] <TabAtkins>
annevk, rniwa: "radicle" is sufficiently unusual *in* the English-speaking world that it shouldn't be used.  It's also far too close to "radical", an actually common word.

[08:24:23.0000] <Domenic>
TabAtkins: if we updated the Console Standard to use new speculative IDL syntax like `namespace Console { ... }` instead of interface, I imagine Bikeshed would barf. We need to update the IDL spec first then the IDL parser Bikeshed uses, then Bikeshed.

[10:48:08.0000] <TabAtkins>
Domenic: Ah, yes, it would indeed barf.  Parser is based on the IDL spec, so update that first. ^_^  My parser is plinss/widlparser

[11:21:02.0000] <jyasskin>
Domenic: Here's my survey of how we register events that get dispatched to workers. I didn't find many: https://gist.github.com/jyasskin/b44ae6d1cf6c209e063447babee8a764

[11:21:53.0000] <Mek>
jyasskin: you're at least missing background sync from that

[11:22:57.0000] <Mek>
(although it's pretty much the same as push/notifications; by adding stuff to SWRegistration)

[11:28:37.0000] <Mek>
also SW events aren't generally send to a particular global/service worker, but instead to whatever the active worker is for a particular registration (the "Handle Funcitional Event" algorithm takes a SW registration, not a specific worker)

[11:31:39.0000] <jyasskin>
Mek: Thanks; I'll add that. And yeah, there's a handle in the main world that's used to identify a set of workers. That'll be true for Worklets too.

[12:39:57.0000] <rniwa>
smaug____: yt?

[12:42:14.0000] <smaug____>
rniwa: not really. holiday in Finland like in many other countries. but ask.

[12:42:23.0000] <rniwa>
smaug____: oh I see

[12:42:34.0000] <rniwa>
smaug____: https://github.com/whatwg/dom/issues/242

[12:42:54.0000] <rniwa>
smaug____: how about escapingPath, leakingPath, emanatingPath, or exitingPath?

[12:44:11.0000] <smaug____>
I don't know what escapingPath would mean in this context... or definitely not what emanatingPath means

[12:44:18.0000] <smaug____>
/me looks for dictionary

[12:57:03.0000] <rniwa>
smaug____: or we could call it dispatchPath, propagationTargets (can't use path)

[12:58:16.0000] <smaug____>
rniwa: why not path there?

[12:58:44.0000] <smaug____>
is propagationPath being used elsewhere?

[12:58:56.0000] <rniwa>
smaug____: yup, it's quite popular

[12:59:30.0000] <rniwa>
smaug____: another one i had along that line of naming was bubblingPath

[13:00:03.0000] <smaug____>
makes no sense, unfortunately

[13:00:20.0000] <smaug____>
since bubbling is just one phase

[13:00:31.0000] <smaug____>
which not all the events even have

[13:04:17.0000] <smaug____>
in Gecko we call the thing eventTargetChain, but I doubt people like that too much

[13:08:36.0000] <smaug____>
rniwa: ok, perhaps dispatchPath then


2016-05-06
[23:44:17.0000] <smaug____>
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/O9_XnDQh3Yk is about https://html.spec.whatwg.org/#dom-form-requestautocomplete right?

[23:50:36.0000] <MikeSmith>
smaug____: Yeah

[23:51:29.0000] <MikeSmith>
smaug____: https://w3c.github.io/browser-payment-api/specs/paymentrequest.html

[23:51:46.0000] <MikeSmith>
is intended as the replacement for it

[23:54:45.0000] <smaug____>
ok, https://github.com/whatwg/html/issues/1207 filed

[23:58:34.0000] <boogyman>
MikeSmith: that assumes a physical address for the shipping address, correct? That means e-fulfilment has a lower/incomplete priority

[00:04:54.0000] <smaug____>
/me hopes PaymentRequest will work with all sorts of payment options, since those vary quite a bit from country to country, I think.

[02:18:35.0000] <hsivonen>
Hixie: it would be useful if https://software.hixie.ch/utilities/js/live-dom-viewer/ visualized template contents

[02:18:42.0000] <hsivonen>
is there a similar tool that does?

[02:23:53.0000] <Ms2ger>
annevk, could you have a look at https://github.com/w3c/web-platform-tests/pull/2925?

[03:03:34.0000] <hsivonen>
/me sent Hixie a patch to add template contents visualization to the Live DOM Viewer

[03:07:16.0000] <hsivonen>
I now realize that my patch doesn't visualize nested templates very well

[03:07:25.0000] <hsivonen>
/me should have used border instead of background-color

[05:59:37.0000] <annevk>
Ms2ger: likely not before Monday

[05:59:59.0000] <annevk>
Ms2ger: walking around a bit

[06:00:27.0000] <Ms2ger>
Ok

[10:37:59.0000] <terinjokes>
Domenic: just realizing my PR didn't update the method sections :(

[10:38:33.0000] <Domenic>
terinjokes: IIRC it doesn't need to

[10:38:56.0000] <terinjokes>
oh, you're right. still waiting for the coffee to start working

[10:39:01.0000] <Domenic>
The algorithm will act on the post-IDL result, so it will always receive a string.

[10:39:07.0000] <Domenic>
:)


2016-05-07
[15:03:28.0000] <Huvet>
I just read this note from csv-conf (yes, the format has a conf) and they suggest a rather nice use of CSV: <table src="uk-local-election-summary-2015.csv">

[15:03:37.0000] <Huvet>
has this been talked about before?

[15:04:49.0000] <gsnedders>
Huvet: pretty sure, yes

[15:05:46.0000] <Huvet>
looks like a great idea, could maybe make some scraping unnessesary as you could just right-click as "save as" instead

[15:08:47.0000] <Huvet>
ah, seems w3 has some docs about it here: https://www.w3.org/standards/techs/csv#w3c_all


2016-05-08
[00:02:48.0000] <zcorpan>
annevk: the dom tree in https://dom.spec.whatwg.org/#ranges looks a bit weird (compare p vs. <em>)

[00:30:56.0000] <annevk>
zcorpan: hmm, maybe bikeshed conversion regressed that

[02:36:29.0000] <rohanthacker>
+i


2016-05-09
[00:08:05.0000] <annevk>
hayato: we also need your feedback for https://github.com/whatwg/dom/issues/242#issuecomment-217281317

[00:08:42.0000] <annevk>
hayato: in case you missed it, in https://github.com/whatwg/html/issues/1160 we concluded we should flip the default for scoped

[00:11:14.0000] <hayato>
annevk: Thanks! Let me take a look soon. I am catching up. Thank you for your patience.

[00:11:43.0000] <annevk>
hayato: no worries, hope you had a nice break

[09:13:07.0000] <Yst>
I'm trying to build some code that renders XHTML, but I'm having trouble with <table/>s. In the Web browsers I've used, unless told to do otherwise, set table column widths in such a way that it minimizes table height. Does anyone have any advice as to how I'd calculate the optimum column widths to implement that? The best that I can come up with is a guess/check method that renders the table with every

[09:13:08.0000] <Yst>
possible combination of widths and chooses the shortest table, but that seems highly inefficient.

[09:17:08.0000] <TabAtkins>
Yst: Table layout is still heavily unspecified, but someone's finally starting to spec it out in https://drafts.csswg.org/css-tables/

[09:22:07.0000] <Yst>
Thank you TabAtkins! I'll read over that.

[10:37:46.0000] <rniwa>
annevk: so the problem here is that your statement is inconsistent

[10:38:07.0000] <rniwa>
annevk: if we didn't care about styling of elements at all, then flatten: true option shouldn't be needed

[10:38:17.0000] <rniwa>
annevk: because there is nothing special about slots that are assigned to another slot

[10:39:00.0000] <rniwa>
annevk: if, on the other hand, we cared about slots being assigned to another slot because those assigned nodes would appear as if they're direct children of the outer slot, then that's about us caring about the styling of the inner slots which are display: contents by default

[12:28:59.0000] <annevk>
rniwa: perhaps it's confusing that we call it flatten and we should call it composed there too, and only the layout tree cares about flattening

[12:29:16.0000] <rniwa>
@annevk: yea

[12:30:04.0000] <annevk>
I mostly see it as getting assigned nodes recursively and taking care of fallback, not really getting the layout tree results

[12:30:24.0000] <annevk>
We wouldn't exclude display:none elements, for instance, either

[12:30:47.0000] <annevk>
So yeah, maybe getAssignedNodes({composed:true}) would be a better API and draw the boundary more clearly

[12:32:11.0000] <annevk>
We wouldn't exclude display:none elements, for instance, either

[12:32:23.0000] <annevk>
So yeah, maybe getAssignedNodes({composed:true}) would be a better API and draw the boundary more clearly

[12:32:54.0000] <annevk>
Ugh

[12:58:17.0000] <aklein>
Domenic: where does HTML set the [[HostDefined]] of the module record returned from ParseModule? I see it read at https://html.spec.whatwg.org/#hostresolveimportedmodule(referencingmodule,-specifier), but not set anywhere

[12:58:34.0000] <aklein>
oh, duh

[12:58:47.0000] <aklein>
ES sets it for you

[12:58:48.0000] <aklein>
nm

[12:58:54.0000] <Domenic>
:)

[13:08:43.0000] <zewt>
looks like the change that screwed up the android tracer was making the second argument to History.pushState required

[13:09:48.0000] <zewt>
which seems like an obviously bad change--no point in breaking pages and forcing people to pass an unneeded argument instead of just working

[13:17:22.0000] <zewt>
oh, that's from a previous time chrome broke systrace (last may, not this may) ... too bad, might have been able to monkey patch around that one

[14:00:29.0000] <rniwa>
annevk: are you still there??

[14:01:36.0000] <hober>
rniwa: it's pretty late in .ch

[14:03:07.0000] <rniwa>
hober: it's only 10PM there, right?

[14:03:37.0000] <rniwa>
oh I guess 11PM?

[14:03:47.0000] <rniwa>
nah, I'd consider it mid-day still :P

[14:03:54.0000] <hober>
rniwa: hahahaha, i suppose you would

[14:04:11.0000] <hober>
/me would be in bed already if he were in europe


2016-05-10
[23:40:10.0000] <annevk>
/me goes to bed early too

[00:06:31.0000] <annevk>
hayato: does the change to DOM to go from scoped to composed look okay?

[00:09:22.0000] <hayato>
annevk: Let me take a look..

[00:10:05.0000] <hayato>
annevk: LGTM-ed in https://github.com/whatwg/dom/pull/244 :)

[00:13:22.0000] <annevk>
ta

[02:09:40.0000] <smaug____>
annevk: I don't quite understand what https://github.com/w3c/webcomponents/issues/432 is about, but aren't we still mixing Nodes and other event targets since Window object is in the path

[02:12:14.0000] <annevk>
smaug____: the problem is only when we start with a non-node event target I think

[02:35:47.0000] <annevk>
hayato: https://github.com/whatwg/dom/pull/247

[02:35:59.0000] <annevk>
smaug____: I tried to explain the reasoning why we can revert it in https://github.com/whatwg/dom/pull/247

[02:53:07.0000] <smaug____>
has anyone reviewed PerformanceObserver API?

[02:55:53.0000] <annevk>
Small aspects of it

[02:55:57.0000] <annevk>
iirc

[03:05:04.0000] <jgraham>
smaug____: Want to review https://github.com/w3c/web-platform-tests/pull/2920 ?

[03:05:39.0000] <jgraham>
(should be v quick I think, and you made the other test changes in the gecko repo)

[03:38:33.0000] <Munter>
annevk: I'm trying to understand the vulnerability in content addressable caching (https://github.com/whatwg/fetch/issues/301#event-654674683). So, I can do a timing attack by measuring the response time of an asset based on it's integrity hash to check if this asset is already in the cache. First of all, timing attacks usually require multiple roundtrips, and after the first try the asset would ba cached, so the attack only gets one reliable data point.

[03:39:40.0000] <Munter>
And is it really a problem at all? With content addressable caching the asset could come from anywhere. It's not nessesarily possible to relate that back to a specific domain. Or am I wrong here?

[03:39:40.0000] <annevk>
Munter: that might be enough

[03:40:29.0000] <annevk>
Munter: if the content is widespread it's not necessarily possible, but if it's not it is

[03:43:12.0000] <annevk>
Munter: and I think you could do multiple attempts if your version ends up erroring somehow or doesn't permit itself being cached

[03:43:31.0000] <Munter>
But I'm not really getting a lot of information from this. It this much different that checking Element.matches(':visited') for an anchor to the same asset?

[03:44:05.0000] <annevk>
Munter: some browsers go out of their way to protect the :visited leak

[03:46:07.0000] <Munter>
annevk: So content addresable caching could potentially be used to detect users browsing habits?

[03:46:25.0000] <annevk>
Munter: yeah

[03:46:34.0000] <Munter>
:(

[03:55:46.0000] <annevk>
Munter: https://lists.w3.org/Archives/Public/public-webappsec/2014Oct/thread.html#msg0 has a bit of past ramblings, not all coherent

[04:10:38.0000] <Munter>
Thanks

[08:33:54.0000] <wanderview>
JakeA: ping

[08:34:04.0000] <JakeA>
hey!

[08:34:34.0000] <wanderview>
JakeA: hi!  so how strongly do you feel about throwing in the fetch event handler not triggering a network error?

[08:34:42.0000] <wanderview>
was that a carefully planned spec detail?

[08:37:06.0000] <JakeA>
wanderview: I can't remember how carefully planned it was, but it feels platform consistent. If an error is thrown in a click listener, it doesn't prevent the default click action

[08:37:51.0000] <wanderview>
JakeA: but we do fail the sw install if the install event handler throws

[08:38:54.0000] <wanderview>
I guess I don't have strong feeling... just trying to figure out if I should fix gecko to not fail the network request while we figure out our long term navigation handling questions

[08:39:52.0000] <JakeA>
wanderview: good point. I'm leaning towards not breaking navigations that error (unless say, devtools are open), so I think it's worth fixing

[08:40:26.0000] <wanderview>
JakeA: ok... what about if evt.respondWith() is called and then it throws?

[08:40:56.0000] <JakeA>
wanderview: then it's down to whatever respondWith resolves with I think

[08:41:28.0000] <wanderview>
JakeA: but if the throwing code results in the respondWith() promise never resolving (maybe its IDB code or something), then you hang the network request for a long time

[08:42:53.0000] <wanderview>
I guess I can just make it ignore thrown exceptions in fetch event for now

[08:43:03.0000] <JakeA>
wanderview: my hunch is that'd be rare. respondWith seems to be the last thing called in fetch listeners

[08:43:42.0000] <wanderview>
well, it might do some waitUntil() background caching... but that would not break the respondWith() I guess

[08:45:53.0000] <wanderview>
JakeA: I'll do that... and write a spec issue since I think spec currently says to fail the network request if you respondWith() is called and the handler throws

[08:46:22.0000] <TabAtkins>
Munter: imo (I've discussed this with others in security), the history leak from content-hashes is minimal and ignorable. As you say, it's a *destructive* timing leak; after the first attempt (by *anyone*), it's ruined for everyone until it drops from cache.  And anyone conducting a history attack pollutes the cache for any subsequent history attacks.

[08:46:42.0000] <JakeA>
Cheers!

[08:47:09.0000] <wanderview>
thanks for clarifying for me... sometimes I can't tell whats intentional or not in the spec :-)

[08:47:20.0000] <TabAtkins>
And a single-attempt timing attack is mostly useless anyway; timing attacks are rarely reliable in a single hit; you have to repeat the attack to minimize noise.

[08:52:29.0000] <halindrome>
botie, ask heycam|away to ping me about webidl and sequences

[08:52:29.0000] <botie>
will do

[08:53:10.0000] <Ms2ger>
halindrome, what's up?

[08:54:07.0000] <halindrome>
Ms2ger: Tab asked me to ping about expressing sdequences in WebIDL

[08:54:17.0000] <halindrome>
'cause I dont know how and someone here does

[08:54:39.0000] <Ms2ger>
Ask away

[08:55:35.0000] <halindrome>
lets say I have an attribute foo.  and foo is a sequence of DOMStrings...

[08:55:49.0000] <halindrome>
an array

[08:56:02.0000] <halindrome>
what is the proper WebIDL syntax for that, and will ReSpec grok it

[08:56:12.0000] <Ms2ger>
No

[08:56:25.0000] <Ms2ger>
Attributes can't be sequences

[08:56:40.0000] <halindrome>
yeah... read that in the WebIDL spec.

[08:57:06.0000] <Ms2ger>
More likely, you want https://heycam.github.io/webidl/#idl-frozen-array

[08:57:07.0000] <halindrome>
but.... the data structure in question works that way.  I think the real answer is "dont use webidl" for this

[08:57:16.0000] <Ms2ger>
That's not the answer

[08:57:55.0000] <Ms2ger>
If you have a data structure where you have to return a new array object on every access, you should make it a method, not an attribute

[08:59:39.0000] <halindrome>
I appreciate that if there were any interface.  This is literally a data structure.  There will never be any "API" to it.  At least, thats what I think.

[09:00:05.0000] <Ms2ger>
I don't know what that means

[09:00:27.0000] <halindrome>
Think JS. It's just an Object.

[09:01:20.0000] <halindrome>
part of a message that gets passed around between methods.  also in JS.  Sometimes among different systems, but if so via JSON.

[09:02:15.0000] <halindrome>
anywya - thansk for the FrozenArray pointer.  I will see about adding FrozenArray to respec

[09:09:27.0000] <wanderview>
JakeA: https://github.com/slightlyoff/ServiceWorker/issues/896

[09:10:06.0000] <JakeA>
ohh, good detail, cheers

[09:12:22.0000] <TabAtkins>
halindrome: I strongly suggest you run this stuff thru implementors. We describe everything on the platform in WebIDL. Something being passed between methods means it's a data structure that can get checked.

[09:13:03.0000] <TabAtkins>
At the bare minimum you can just WebIDL it as an "object" and do every operation in prose, but that's fragile and silly and you'll get things wrong.

[09:14:49.0000] <halindrome>
TabAtkins: thanks.

[09:19:18.0000] <halindrome>
also, fwiw, this is nothing I would ever envision a browser implementor putting in an api.  but I digress.

[09:35:06.0000] <Ms2ger>
/me wonders why service workers uses [Unforgeable] so much

[09:38:10.0000] <Domenic>
Woah, that is bizarre

[09:40:10.0000] <Domenic>
Ms2ger: filed https://github.com/slightlyoff/ServiceWorker/issues/897

[10:06:28.0000] <annevk>
TabAtkins: Google's security team said something else last time around

[10:06:39.0000] <TabAtkins>
We disagree internally.

[10:07:00.0000] <annevk>
TabAtkins: I see

[10:52:38.0000] <TabAtkins>
Domenic: How are you managing to get such weird markup in your PR messages?

[10:52:45.0000] <Domenic>
?

[10:52:50.0000] <Domenic>
Oh

[10:52:55.0000] <Domenic>
I forgot to edit the commit message

[10:53:21.0000] <Domenic>
GitHub gets confused by <style> elements

[10:53:56.0000] <TabAtkins>
how bizarre

[12:30:58.0000] <smaug____>
any hints where tests for table.rows might be in https://github.com/w3c/web-platform-tests/tree/master/html

[12:31:45.0000] <smaug____>
nm, https://github.com/w3c/web-platform-tests/blob/master/html/semantics/tabular-data/the-table-element/table-rows.html

[12:52:21.0000] <smaug____>
jgraham: I lost the link how to run wpt tests easily

[12:54:40.0000] <smaug____>
hmm, but now I found another way. http://w3c-test.org/*

[12:57:58.0000] <Domenic>
there's some magic runner in a subdirectory there

[12:59:12.0000] <Domenic>
can't find it

[12:59:22.0000] <smaug____>
yeah, there was some web app -like runner somewhere

[13:41:10.0000] <jgraham>
smaug____: tools/runner/index.html

[13:41:29.0000] <jgraham>
smaug____: But also |mach web-platform-tests| if you just want to run ones that are in a gecko tree

[13:41:53.0000] <smaug____>
sure, but I was comparing different browsers

[13:42:09.0000] <smaug____>
and thanks

[13:42:22.0000] <jgraham>
Yeah, unfortunately other browsers aren't quite sophisicated enough ;)

[13:49:36.0000] <wanderview>
Domenic: thanks... sorry for messing those script references up

[13:50:16.0000] <Domenic>
wanderview: no problem. running the real web platform tests against the reference impl now so should be able to catch things :)


2016-05-11
[17:34:49.0000] <Domenic>
TabAtkins: if I were to write a piece of software that took (propName, value) pairs and parsed value according to the grammar for the CSS propName (e.g. given propName = "margin", parsed value according to `<margin-width>{1,4} | inherit`), where would I find an index of propName => grammar productions?

[17:35:15.0000] <TabAtkins>
Nowhere yet. It's something we plan to add to Shepherd.

[17:35:40.0000] <Domenic>
dang, ok

[17:51:23.0000] <JohnMH>
https://url.spec.whatwg.org/

[17:51:32.0000] <JohnMH>
Specifically, "The URL Standard defines URLs, domains, IP addresses, the application/x-www-form-urlencoded format, and their API."

[17:51:47.0000] <JohnMH>
What does the URL Standard have to do with domains or IP addresses?

[17:52:21.0000] <JohnMH>
I understand that these are possible inputs for the host field of a URL, but what do they have to do with a URL itself?

[18:02:10.0000] <Domenic>
JohnMH: https://url.spec.whatwg.org/#hosts-%28domains-and-ip-addresses%29

[18:23:11.0000] <JohnMH>
Domenic: That's not defining domains and IPs, that's using them

[19:24:39.0000] <Domenic>
Sure look like definitions to me.

[19:27:07.0000] <JohnMH>
Domenic: You're referencing RFCs, not defining what a domain or IP is.

[19:28:03.0000] <Domenic>
It does both.

[19:29:30.0000] <JohnMH>
Domenic: If you were to define a domain or IP, you would need to talk about what is and is not valid, why, and best practices.

[19:29:44.0000] <JohnMH>
And, where it says domains, I assume it means hosts?

[20:00:32.0000] <Domenic>
No a host is a distinct definition; scroll down a bit.

[20:01:46.0000] <Domenic>
(In general it seems like a lot of the things you're asking about are answered after scrolling down.)

[21:15:25.0000] <JohnMH>
Domenic: Are you referring to Section 3?

[21:16:49.0000] <JohnMH>
That doesn't define a host, it incorrectly references RFCs and reiterates information one would find in those RFCs. A host isn't "a domain, an IPv4 address, or an IPv6 address."

[21:17:10.0000] <JohnMH>
A host is any hostname or address, not specifically a domain or IP address

[21:17:35.0000] <JohnMH>
protocol://myhost/ is a valid URL

[21:18:00.0000] <JohnMH>
protocol:///myhost/ is not, for example

[21:20:34.0000] <Domenic>
You keep stating what things "are". It's very curious to me why you think your definitions of these terms are more interesting than the definitions in the URL standard.

[21:21:09.0000] <JohnMH>
These aren't my definitions.

[21:22:11.0000] <JohnMH>
Domenic: Hostnames are first defined here: https://tools.ietf.org/html/rfc952

[21:22:30.0000] <JohnMH>
You may follow from there to other RFCs

[21:22:43.0000] <Domenic>
But why would I want to?

[21:23:08.0000] <JohnMH>
To have a proper definition of a hostname, which the "URL Standard" shouldn't include in the first place

[21:23:41.0000] <Domenic>
You keep making statements about how the world "should" be, and what is "proper". Can you perhaps envision other people might disagree with you on those "should"s and "proper"s?

[21:24:27.0000] <JohnMH>
RFCs which everyone has based their definitions on for more than 30 years

[21:24:44.0000] <Domenic>
Well, clearly not everyone, including some of the most widely-used software on the planet.

[21:25:30.0000] <JohnMH>
That's not true, and you're simply ignoring that fact

[21:26:10.0000] <Domenic>
I guess I can't do much more to argue against such assertions than say "no, you're the one saying untrue things and ignoring facts"

[21:26:12.0000] <JohnMH>
For example, wget, curl, WinHTTP

[21:26:23.0000] <Domenic>
For example, Netscape, IE, Firefox, Edge, Chrome, Safari

[21:26:34.0000] <Domenic>
(Opera!)

[21:26:52.0000] <JohnMH>
Opera is just based on Chromium, why should it even be considered its' own browser?

[21:26:57.0000] <Domenic>
I meant Presto Opera

[21:27:25.0000] <Domenic>
Anyway, bedtime for me; night-night. Can discuss more tomorrow, but hopefully you can see how people might have different perspectives than yours.

[21:27:47.0000] <JohnMH>
I don't see how supporting malformatted URLs is actually something you'd want in any document.

[21:28:22.0000] <JohnMH>
Instead of supporting malformatted URLs, it'd be best to either throw an error at the user or just transparently rewrite it

[21:28:35.0000] <JohnMH>
I don't know why you're only using browsers for these examples, though.

[21:28:44.0000] <JohnMH>
Browsers are far from the only software which use URLs.

[21:34:50.0000] <Domenic>
tranparently rewriting it is exactly what is done!

[21:34:54.0000] <Domenic>
that is what the process of parsing does

[21:35:08.0000] <Domenic>
For example! http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4182

[21:35:25.0000] <Domenic>
(look at the "log:" output)

[21:36:17.0000] <Domenic>
As for why I am using browsers, well, we are in the channel of an organization focused on making browsers better. But it's true that if you had software that did not want to interoperate with browsers at all, then it could use different algorithms for URL processing

[21:36:29.0000] <Domenic>
I would assume you would not discuss that algorithm in this channel though

[21:38:13.0000] <Domenic>
I am excited to discover that we may be more in alignment than previously thought, though, with your "transparent rewrite" idea.

[21:38:17.0000] <Domenic>
But I really should sleep.

[21:39:25.0000] <JohnMH>
Domenic: But it shouldn't be in any spec to do so

[21:39:34.0000] <JohnMH>
It shouldn't be done, in all honesty

[21:39:39.0000] <JohnMH>
It's only even seen as a good idea for UX

[21:39:50.0000] <JohnMH>
Which is a horrible reason, to do anything.

[21:40:11.0000] <Domenic>
Ah, now, again, hopefully you can see how there are people in the world---some of them working on very popular software---who disagree with the idea that UX is a horrible reason to do things

[21:40:34.0000] <Domenic>
And it might be a good idea for those people to all agree on the details of how to do things, while valuing UX

[21:40:40.0000] <JohnMH>
Those people are, more than likely, working in UX fields

[21:40:43.0000] <Domenic>
Thus, those people might start writing a standard

[21:40:51.0000] <Domenic>
No, sorry, those people are browser engineers!

[21:41:02.0000] <JohnMH>
Yes, browser UX?

[21:41:07.0000] <Domenic>
No, browser code

[21:41:17.0000] <JohnMH>
That can easily be the same thing.

[21:41:19.0000] <Domenic>
Everyone on a browser values UX. The browser is the user's agent, after all

[21:41:31.0000] <JohnMH>
In any case, browsers need to follow the already defined standards for URLs, it's already well done.

[21:41:56.0000] <Domenic>
Hmm, well, that would have been a good argument to make in 1985 when timbl was working on Mosaic

[21:42:05.0000] <Domenic>
(1985 = probably not accurate)

[21:42:23.0000] <JohnMH>
If any changes need to be made to the actual URL standard, which I'm absolutely agreeing to, then that's entirely different

[21:42:37.0000] <JohnMH>
but having two different standards for URLs is ridiculous

[21:42:47.0000] <Domenic>
But he chose a different path, as did all the others following him. And so it turns out that the former "standards" became obsolete, as real-world software was not interested in following them.

[21:42:50.0000] <JohnMH>
Why should browsers follow a different definition of a URL than any other software?

[21:43:07.0000] <Domenic>
Yeah, that's why the URL standard obsoletes the many (U/I)R(I/N/L) RFCs

[21:43:10.0000] <Domenic>
They don't!

[21:43:30.0000] <Domenic>
Much other software also follows the URL standard, as other software often wants to interoperate with browsers.

[21:43:44.0000] <JohnMH>
But you're using only browsers for examples, and you're saying that other software should just use a "different algorithm for URL processing"?

[21:44:01.0000] <Domenic>
I'm not saying that. I'm saying that, maybe software you write, that doesn't want to interoperate with browsers, could do that

[21:44:11.0000] <Domenic>
But in general, the software most people write wants to interoperate with browsers, so it follows the URL standard

[21:44:30.0000] <Domenic>
We have some pretty extensive test results on this from a while back (URL parsing libraries in various languages stdlibs), let me dig them up for you...

[21:44:30.0000] <JohnMH>
I don't see how the ability to use git://user@host/repo.git as a URL has to do with that software wanting to interoperate with browsers.

[21:44:33.0000] <JohnMH>
It's just another URL.

[21:45:19.0000] <Domenic>
Right, I think most people want to be able to say "it's just another URL" when writing their software, and use a generic URL processing library that works the same in all scenarios. That will be one following the URL standard.

[21:45:33.0000] <JohnMH>
It's the same with ssh://user@host or sftp://user@host, or any other protocol.

[21:45:36.0000] <JohnMH>
Exactly!

[21:45:54.0000] <JohnMH>
So it's important not to prioritize browsers in this case, as all software should definitely be using the same standard.

[21:46:08.0000] <JohnMH>
Browsers aren't different than any other software, in this regard

[21:46:54.0000] <Domenic>
Well, we want to prioritize interoperability with browsers, as they are some of the most widely-used URL-consuming software on the planet.

[21:47:10.0000] <Domenic>
But let me phrase it another way for you:

[21:47:18.0000] <Domenic>
We want all software to agree on a single URL definition

[21:47:34.0000] <Domenic>
All software is afraid of losing users by making things that used to work, stop working

[21:47:49.0000] <Domenic>
(Some software might be written by people who think that this is not a big problem.)

[21:48:01.0000] <Domenic>
How are we going to get to this world, while still accounting for the fact that nobody wants to lose users?

[21:48:08.0000] <Domenic>
Probably, by converging on union semantics.

[21:48:10.0000] <JohnMH>
Browsers may be 50% of all URL usage, but that's not important.

[21:48:17.0000] <Domenic>
I'd guess 95%

[21:48:27.0000] <JohnMH>
I'd definitely say less than 60%.

[21:48:39.0000] <JohnMH>
But that's not the point,

[21:48:44.0000] <Domenic>
Well, it kind of is

[21:48:52.0000] <JohnMH>
Browsers definitely aren't special here.

[21:48:53.0000] <Domenic>
How are we going to reach interop? What is the shortest path? Changing 95% or changing 5%?

[21:49:04.0000] <JohnMH>
Neither

[21:49:28.0000] <JohnMH>
Define a standard. Everyone should follow that standard. Those who don't will either define their own standard, or will fade away.

[21:49:34.0000] <Domenic>
(Remember the prevalence of mobile devices, usage of which heavily outweighs that of computers. There it may be more obvious that most URL-processing software is a browser or web view.)

[21:49:42.0000] <Domenic>
Ah, see, no, that does not work.

[21:49:47.0000] <Domenic>
Nothing "fades away"

[21:49:52.0000] <Domenic>
Standards are not in and of themselves a good thing

[21:49:59.0000] <JohnMH>
URL processing on Android devices is usually intent-based, not used by the browser at all

[21:50:03.0000] <Domenic>
They are good to the extent they *add value for users*

[21:50:20.0000] <JohnMH>
For example, the Facebook application abuses "internal" protocols

[21:50:54.0000] <Domenic>
If you define a standard that does not add value for users (for example, by increasing interop) it will not be followed.

[21:51:59.0000] <JohnMH>
Increasing interoperability isn't an issue anymore. URLs have already been defined.

[21:52:13.0000] <Domenic>
Those two statements are entirely unrelated

[21:52:15.0000] <Domenic>
And the first is just not true

[21:52:16.0000] <JohnMH>
There is no reason not to follow the existing definition of a URL, as we have been for quite a while.

[21:52:21.0000] <Domenic>
Ah, but there is

[21:52:27.0000] <Domenic>
Because doing so does not increase value for users

[21:52:38.0000] <Domenic>
It in fact decreases value in many cases, by making their websites stop working

[21:52:50.0000] <JohnMH>
No, but you aren't adding anything useful to URLs in the first place.

[21:53:08.0000] <Domenic>
Sure we are. We're "adding" the ability to process URLs that occur in the wild.

[21:53:31.0000] <JohnMH>
That's an implementation issue, not an issue of standardization.

[21:53:45.0000] <JohnMH>
It should return an error, when the URL is erroneous.

[21:53:55.0000] <JohnMH>
There is no useful data on websites which use multiple forward slashes after protocols, for example.

[21:54:12.0000] <Domenic>
Hmm, another fundamental disconnect.

[21:54:16.0000] <JohnMH>
That is an invalid URL at that point, so a browser should tell the user that it is invalid.

[21:54:20.0000] <Domenic>
Implementations need to be interoperable, thus we write standards.

[21:54:27.0000] <Domenic>
Whereas you seem to think we write standards to define how things "should" be.

[21:54:39.0000] <Domenic>
Telling the user "this web page is invalid" does not add value.

[21:54:48.0000] <Domenic>
Do you remember the 90s when you would get a popup for every JavaScript error?

[21:54:57.0000] <JohnMH>
I miss those

[21:55:02.0000] <JohnMH>
They told me what sites were trash

[21:55:19.0000] <Domenic>
But hopefully you can see how people don't generally think they add user value

[21:55:24.0000] <Domenic>
Maybe they would to you

[21:55:34.0000] <JohnMH>
That is what a standard is. See: https://www.ietf.org/rfc/rfc1738.txt

[21:55:42.0000] <Domenic>
In which case I suggest writing a browser extension that enforces your personal standards on all the websites you visit, so you can find "trash"

[21:55:49.0000] <Domenic>
Yeah, as I said, a fundamental disconnect.

[21:56:01.0000] <JohnMH>
Why write a browser extension? My browser of choice doesn't run JavaScript to begin with.

[21:56:15.0000] <Domenic>
So that you can detect URLs that you don't like

[21:56:20.0000] <Domenic>
Those pages are presumably trash too

[21:56:22.0000] <JohnMH>
I can already see the URLs

[21:56:31.0000] <Domenic>
fair enough

[21:56:57.0000] <Domenic>
Anyway, I think we've discovered our fundamental disconnects here: adding user value and increasing interoperability, versus defining how the world should be.

[21:57:19.0000] <Domenic>
Hopefully you can see that a lot of software values the former, and thus standards organizations work to accomodate that software in some cases.

[21:57:40.0000] <JohnMH>
And I suppose this is the difference between this spec and a real standard definition?

[21:57:42.0000] <Domenic>
I can understand if you value the latter more.

[21:57:58.0000] <Domenic>
Well, between the URL Standard and a JohnMH "real standard", sure.

[21:58:29.0000] <JohnMH>
No, I'm talking about RFC 1738

[21:58:36.0000] <Domenic>
As I said.

[21:58:44.0000] <JohnMH>
I definitely didn't write it

[21:58:49.0000] <JohnMH>
I definitely didn't write iti

[21:59:05.0000] <Domenic>
Yeah, but you're the one making up categories

[21:59:05.0000] <JohnMH>
* It's not my definition, it's the generally accepted definition of a URL.

[21:59:13.0000] <Domenic>
That's just false

[21:59:29.0000] <JohnMH>
Not at all, Firefox followed it pretty closely until recently

[21:59:36.0000] <JohnMH>
Lynx still does

[21:59:44.0000] <JohnMH>
EWW does as well, w3m too

[21:59:57.0000] <Domenic>
None of those examples has convinced me that it is "generally accepted"

[22:00:20.0000] <Domenic>
It's definitely accepted by JohnMH and software he likes, though. That I'll grant.

[22:00:23.0000] <JohnMH>
Firefox is one of the most popular browsers, easily comparable to Chrome or other Chromium based things.

[22:00:39.0000] <Domenic>
Yes, and Firefox follows the URL Standard (and is in fact getting closer and closer to a 100% implementation based on Rust!)

[22:01:05.0000] <JohnMH>
Yes, Servo..

[22:01:31.0000] <Domenic>
Right, but they're going to be porting the Servo URL parser into Firefox; very exciting!

[22:01:38.0000] <JohnMH>
That's silly

[22:01:46.0000] <JohnMH>
In any case

[22:02:32.0000] <JohnMH>
Domenic: You also have popular software such as cURL, wget and even browsers such as w3m, eww and lynx which don't follow this "standard", but follow RFC 1738 instead

[22:03:24.0000] <Domenic>
It's true! Some software doesn't follow the URL Standard, especially software JohnMH likes to cite in his arguments on the internet! I do not contest this!

[22:03:55.0000] <JohnMH>
No, instead this software follows the defined standard since 1994, RFC 1738

[23:12:12.0000] <annevk>
That RFC has been obsoleted several times over

[23:26:54.0000] <MikeSmith>
It didn't seen like JohnMH had any actual problem he was trying to solve

[23:28:50.0000] <annevk>
He was just doing some 386'ing to pass the time I guess

[04:54:01.0000] <annevk>
I started writing a reply to some of the URL stuff going on on Twitter but it reads very much like https://annevankesteren.nl/2016/04/network-effects so far

[04:58:44.0000] <annevk>
/me finally found a good reference for when folks say something is "(in)sane": http://whatprivilege.com/replacing-crazy-for-ableism-and-preciseness-of-language/

[04:58:58.0000] <jgraham>
I haven't read twitter, but I read Daniel's blog post and it seemed like the whole HTML parsing thing again with s/HTML/URL/

[05:00:19.0000] <annevk>
It's always a variant on that

[05:46:43.0000] <JohnMH>
annevk: Perhaps "obsoleted", but every revision was based on 1738, and didn't change much. It definitely didn't change to allow https:///google.com/ to be valid

[06:14:58.0000] <MikeSmith>
JohnMH: I agree with you that it's not important to care about what browsers do and other tools should strictly follow 20-year old RFCs and pretend that browsers don't exist

[06:15:17.0000] <MikeSmith>
because that's clearly better for users

[06:17:04.0000] <Ms2ger>
MikeSmith, why would you care about interoperating with browsers?

[06:17:13.0000] <Ms2ger>
MikeSmith, the future is in the Semantic Web anyway

[06:19:35.0000] <JohnMH>
MikeSmith: What you describe is a UX issue, which shouldn't have anything to do with what a URL is.

[06:22:28.0000] <hsivonen>
which spec does insertAdjacentHTML live in these days?

[06:22:55.0000] <JohnMH>
URLs go far beyond the context of browsers, and while I understand that WHATWG is solely browsers, you're presenting a specification which many tools and programs other than browsers have to follow.

[06:24:35.0000] <hsivonen>
ooh. domparsing.spec.whatwg.org redirects but is not listed on spec.whatwg.org

[06:24:41.0000] <hsivonen>
confusing

[06:25:53.0000] <Ms2ger>
JohnMH, I don't think this discussion is going to go anywherew

[06:30:25.0000] <hsivonen>
Ms2ger: Looks like I've never replied to say whether I was OK with https://bitbucket.org/ms2ger/dom-parsing-and-serialization/commits/a5d7da5a4f86 . I think I am.

[06:31:13.0000] <Ms2ger>
That's good, I suppose :)

[06:31:23.0000] <JohnMH>
Ms2ger: Why not? There is definitely a good reason to discuss this, and change would definitely be for the better.

[06:43:18.0000] <jgraham>
I think that people are going to have a hard time believing that "change would definitely be for the better" if you don't consider interoperability amongst implementations, including browsers, to be the goal

[06:46:12.0000] <JohnMH>
Interoperability is definitely a goal; that's the point of standardizing something.

[06:48:01.0000] <jgraham>
OK, so the URL spec describes, to the best of our knowledge, what browsers must implement to interoperate with existing content, and with each other

[06:49:02.0000] <jgraham>
Changes to the URL spec therefore have to meet the bar of "this change does not reduce the ability to interoperate with existing content or reduce the chance for browsers to interoperate with each other"

[06:59:33.0000] <hsivonen>
Why might moving Gecko's mapped attributes to show up after non-mapped attributes in the iteration order make the iteration order closer to WebKit/Blink/spec?

[07:00:11.0000] <hsivonen>
I reviewed a patch that changed that but now I can't articulate why that bit of the patch was an improvement

[07:10:37.0000] <Ms2ger>
hsivonen, I don't know why that part was in there either

[07:11:57.0000] <JohnMH>
jgraham: If it refers only to browsers, perhaps the name shouldn't be URL, but BRL

[07:12:35.0000] <Ms2ger>
And HTML should be BTML?

[07:12:55.0000] <halindrome>
Ms2ger: lol

[07:13:12.0000] <Ms2ger>
No, seriously

[07:13:15.0000] <JohnMH>
No, as HTML is rendered primarily by browsers

[07:13:26.0000] <Ms2ger>
URLs are used primarily by browsers too

[07:13:36.0000] <JohnMH>
No, and that seems to be a common misconception here.

[07:13:37.0000] <halindrome>
Ms2ger: well... no.

[07:14:30.0000] <Ms2ger>
I guess that's where the discussion ends, then

[07:21:00.0000] <jgraham>
I don't understand why other tools wouldn't want to interoperate with browsers here. For example any kind of web scraper will need to have the same handling of URLs as a browser. If such a scraper wanted to be cURL based it would therefore benefit from cURL and browsers having compatible URL handling.

[07:24:43.0000] <hsivonen>
Ms2ger: thanks. Maybe I should revert the reordering of mapped and non-mapped, then.

[07:36:34.0000] <annevk>
hsivonen: insertion order, pretty please

[07:38:36.0000] <annevk>
jgraham: I tried to have that discussion with bagder in Mozilla's #necko

[07:39:47.0000] <annevk>
jgraham: not entirely sure I convinced him, but close enough

[07:48:00.0000] <hsivonen>
annevk: we aren't getting rid of mapped attributes in this iteration

[07:48:12.0000] <hsivonen>
annevk: non-mapped attributes changed to insertion order

[07:48:28.0000] <hsivonen>
annevk: and the mapped ones

[07:48:56.0000] <hsivonen>
annevk: but all mapped ones have to come before all the non-mapped ones or all the non-mapped ones have to come before all the mapped ones

[07:49:44.0000] <hsivonen>
annevk: we used to have mapped before non-mapped. Now we have non-mapped before mapped, and a bug report that this broke at least one JS program.

[07:51:00.0000] <hsivonen>
It's kinda disappointing that there's still another round of complaining about how the WHATWG does specs.

[07:51:26.0000] <hsivonen>
After all, the track record should be pretty good by now.

[07:51:55.0000] <annevk>
hsivonen: complaining will continue until morale improves

[07:56:51.0000] <JohnMH>
jgraham: Yes, but you're saying that as if browsers are the only things that use URLs, and as if browsers are authoritative over other software.

[07:57:36.0000] <jgraham>
No I'm not

[07:58:05.0000] <jgraham>
I'm saying that browsers have hard compat requirements dictated by two decades of legacy web content

[07:59:58.0000] <jgraham>
Those contraints tend to be more stringent than for other pieces of software, so naturally browsers have to have more say in standards that apply to both them and other application classes without the same constraints

[08:00:35.0000] <jgraham>
Plus, as I pointed out, it's often necessary for applications in other classes to directly interop with web content, so they actually have the same compat constraints

[08:07:11.0000] <hsivonen>
JohnMH: curl is an example of a non-browser piece of software that tries to be compatible with the Web as written for browsers

[08:07:42.0000] <hsivonen>
it seems to me that it would make sense to implement an URL Standard-conforming URL parser in curl instead of patching things piecemeal

[08:56:36.0000] <JohnMH>
hsivonen: curl doesn't try to be compatible with the "Web as written for browsers", curl reluctantly changes to these non-standard implementations

[08:56:54.0000] <JohnMH>
curl is not just for HTTP, curl also supports GOPHER, FTP, SFTP and more

[09:06:51.0000] <jgraham>
I am guenuinely bemused by idea that you would prefer to have a URL implement a weird nonstandard behaviour to get compatibility because the compatible standard wasn't the standard that you had to break to make your implementation useful

[09:23:35.0000] <JohnMH>
The implementation is useful without nonstandard parsing, which should be done by a pre-formatting library, not part of the URL itself

[09:28:50.0000] <jgraham>
I think the difference between a "preformatting library + a url parser" and a "url parser" where the aggregate behaviour of both is identical, is one made entirely of self delusion

[09:30:17.0000] <caitp>
this looks like a productive topic

[09:31:14.0000] <JohnMH>
Well, no. It's silly to say that it can't be done properly in practice. It's not hard to just create a function for formatting which is defined separately from something which is meant to define a URL, not the handling of malformed URLs and guessing what the user wants.

[09:31:46.0000] <annevk>
There's no guessing, it's all deterministic

[09:31:56.0000] <jgraham>
JohnMH: Your problem is that you have a broken definition of what it means to do something properly

[09:32:27.0000] <JohnMH>
jgraham: To do something properly is to follow the defined standards, not to change the standards based on implementations.

[09:32:39.0000] <jgraham>
Nope

[09:32:49.0000] <JohnMH>
Because an implementation decides to do something silly doesn't mean that the standards should be changed to accommodate.

[09:33:21.0000] <jgraham>
This isn't *an implementation*. We have been through this. It's what's required to work with two decades of legacy content.

[09:33:30.0000] <JohnMH>
That's literally the opposite of a standard, and it's more like something Microsoft would try to do. (See Microsoft Office "standards" and the history behind that for why it doesn't work, even for Microsoft)

[09:33:52.0000] <annevk>
It's not "an implementation", it's the clients making up 90% of the web

[09:33:55.0000] <jgraham>
Now I feel we reached the unproductive part of the conversation

[09:34:03.0000] <JohnMH>
90% of the web isn't HTTP

[09:34:11.0000] <annevk>
Wut?

[09:34:33.0000] <jgraham>
I suppose it won't help if I mention that we went through this exact discussion in 2007 with the HTML parser and the result doesn't look good for your position

[09:34:36.0000] <JohnMH>
Accepting any number of forward slashes isn't going to fix any anything, it's just going to mean that now clients can "acceptably" add any given number of forward slashes.

[09:34:52.0000] <JohnMH>
HTML is different, only browsers use HTML for the most part.

[09:34:54.0000] <annevk>
I don't think it means that at all

[09:35:00.0000] <JohnMH>
99% of HTML use is in browsers

[09:35:21.0000] <JohnMH>
With URLs, less than 20% of usage is browser based

[09:35:30.0000] <jgraham>
[citation needed]

[09:35:50.0000] <JohnMH>
Android, and other platforms, internally use URLs to communicate between applications or processes

[09:36:04.0000] <jgraham>
But if it helps we had exactly the same arguments put forward that we weren't considering non-browser implementations for HTML parsing

[09:36:18.0000] <JohnMH>
Yeah, but those are edge cases

[09:36:40.0000] <JohnMH>
When it comes to URLs, less than 60% (and that's a very liberal guess) of usage is from browsers

[09:36:58.0000] <JohnMH>
There's even an operating system where literally everything is a URL.

[09:37:05.0000] <jgraham>
Redox?

[09:37:21.0000] <jgraham>
I would be interested to know what it uses to parse urls

[09:37:27.0000] <JohnMH>
Yes, Redox

[09:39:00.0000] <jgraham>
Because it seems totally reasonable that e.g. Android should be able to use the same url parsing library for the browser component and for other components

[09:39:20.0000] <nox>
jgraham: I died on the inside a bit.

[09:39:24.0000] <nox>
jgraham: https://github.com/redox-os/redox/blob/master/kernel/fs/url.rs#L31-L43

[09:39:44.0000] <jgraham>
nox: haha

[09:40:24.0000] <jgraham>
Fair to say it uses something that looks almost, but not quite entirely, unlike urls

[09:42:17.0000] <JohnMH>
jgraham: A URL is universal, it isn't specific to browsers.

[09:42:29.0000] <jgraham>
Anyway, a scheme where you have to have multiple URL libraries just so that some applications can reject a subset of inputs for not corresponding to some standard written before we understood the process for achieving compatibility is more complex for everyone

[09:43:55.0000] <jgraham>
It's hard to understand how you would advocate it from an engineering point of view rather than a "religious" point of view ("RFCs MUST be followed")

[09:44:07.0000] <JohnMH>
The processing of achieving compatibility is not hard, you just have to agree on a standard and have everyone follow it. From a development standpoint, that's simple. If any party believes anything should be added, write an RFC and see what people think of it

[09:44:19.0000] <JohnMH>
If people approve of it, sweet! You've got a new standard.

[09:44:46.0000] <nox>
So what's the problem, given there is the URL standard?

[09:45:05.0000] <JohnMH>
The URL standard doesn't define a URL, it defines something specific to browsers.

[09:45:18.0000] <smaug____>
annevk: I'm trying to understand the process here. Perhaps there isn't any process. But why are we discussing about rootnode issue (https://github.com/whatwg/dom/issues/241) in https://github.com/whatwg/dom/pull/248 ?

[09:45:21.0000] <JohnMH>
It should either not claim to be about URLs, or should include more broad input than just browsers.

[09:45:28.0000] <nox>
The RFCs don't define a URL, they define something that nobody uses.

[09:45:56.0000] <annevk>
smaug____: the discussion seemed concluded, so I just want a final okay for the change

[09:46:15.0000] <smaug____>
annevk: and why that final ok should happen in that pull ?

[09:46:18.0000] <nox>
How did you quantify that "with URLs, less than 20% of usage is browser based", btw?

[09:46:22.0000] <smaug____>
and not in the issue

[09:46:34.0000] <smaug____>
it is really confusing to have the same conversation happening in multiple places

[09:46:37.0000] <annevk>
smaug____: generally that is how it works when reviewing changes

[09:47:54.0000] <smaug____>
well, I'm not reviewing anything here

[09:48:03.0000] <smaug____>
anyhow comments somewhere

[09:48:08.0000] <smaug____>
getRootNode() is ok to me

[09:48:14.0000] <smaug____>
s/comments/commented/

[09:48:17.0000] <JohnMH>
Starting with RFC 1738 and ending with RFC 3986, we have the definition of a URL as followed by Java SE, and other platforms.

[09:48:29.0000] <TabAtkins>
Like... there are over a trillion web pages in existence.

[09:48:41.0000] <annevk>
smaug____: sorry for the confusion

[09:48:45.0000] <TabAtkins>
So there are presumably 5 trillion, what, RDF databases?

[09:48:55.0000] <smaug____>
annevk: I blame github :)

[09:49:02.0000] <smaug____>
it is a confusing tool

[09:49:07.0000] <nox>
JohnMH: Where is protocol:///myhost/ valid in the URL standard?

[09:49:16.0000] <annevk>
smaug____: shout it from the rooftops

[09:49:29.0000] <JohnMH>
nox: Anywhere, but the third / would be part of the host

[09:49:36.0000] <JohnMH>
Which is correct, by the way

[09:49:41.0000] <nox>
lolwat

[09:49:46.0000] <JohnMH>
See the file protocol for the only example where you'd want that, though

[09:49:48.0000] <nox>
In which RFC?

[09:50:28.0000] <JohnMH>
nox: It says, nowhere, that multiple forward slashes are valid, which is fine because they shouldn't be in the sense you're bringing up.

[09:50:35.0000] <smaug____>
has cabanier been here recently

[09:50:54.0000] <nox>
I don't parse that sentence.

[09:51:06.0000] <annevk>
smaug____: haven't seen him

[09:51:25.0000] <annevk>
smaug____: he's been somewhat active though on GitHub and I think there was an email too some days ago

[09:51:42.0000] <JohnMH>
nox: Multiple forward slashes = not valid, if parsed everything past the first or second forward slash, depending on the protocol, should be part of the next field in the URL

[09:51:52.0000] <nox>
Where is that stated?

[09:51:59.0000] <smaug____>
annevk: yeah, would be better to chat here about the hit region stuff than in github

[09:52:11.0000] <JohnMH>
nox: It's only stated that it's not valid

[09:52:28.0000] <nox>
/me yawns.

[09:52:39.0000] <annevk>
smaug____: guess you'll have to email him

[09:52:40.0000] <JohnMH>
If you have https://googol///t?b#s

[09:52:46.0000] <JohnMH>
what do you expect that to be parsed as?

[09:52:55.0000] <nox>
That's not the same at all as what you said before.

[09:52:59.0000] <annevk>
smaug____: I told Domenic I'm willing to work on it, but not this month, too many things going on

[09:53:01.0000] <JohnMH>
It's not, but I'm proving the point

[09:53:05.0000] <nox>
No you are not.

[09:53:14.0000] <JohnMH>
I'd expect the server at googol to receive a request with the path ///t

[09:53:19.0000] <nox>
You are just talking of something else which is completely unrelated.

[09:53:22.0000] <JohnMH>
which can be a real path, but it isn't likely

[09:53:32.0000] <JohnMH>
So, that considered, what's keeping the same from being true of the host field

[09:54:00.0000] <smaug____>
annevk: totally understand. I'm somewhat worried that most of hit region stuff in the spec will need to be rewritten, though hopefully simplified significantly

[09:54:46.0000] <JohnMH>
nox: For example, under similar circumstances let's say we have the url https:////googol/t

[09:54:59.0000] <smaug____>
but I could be wrong here. Which is why I'm still trying to figure out why we current design is what it is.

[09:55:08.0000] <smaug____>
s/we/the/

[09:55:11.0000] <JohnMH>
I would expect the server at "/googol" to receive a request on the path "t"

[09:55:15.0000] <JohnMH>
or "/t"

[09:55:19.0000] <nox>
That's an empty host as per the rules of the HTTPS scheme. So even if you want to use RFC 1738 you are just wrong.

[09:55:38.0000] <JohnMH>
Exactly

[09:55:45.0000] <annevk>
smaug____: you saw https://lists.w3.org/Archives/Public/www-archive/2016Apr/0001.html, right?

[09:55:45.0000] <JohnMH>
So if that's not valid, why do you want to make it valid?

[09:55:59.0000] <nox>
Where is it valid?

[09:56:15.0000] <JohnMH>
That's exactly what this spec is trying to do, make parsing of /// become valid

[09:56:20.0000] <smaug____>
annevk: I did

[09:56:24.0000] <nox>
Where?

[09:57:57.0000] <smaug____>
annevk: but still wondering why someone ended up as complicated setup as it is now. I hope if the ID stuff is just removed, it all becomes good enough.

[10:00:35.0000] <JohnMH>
nox: https://url.spec.whatwg.org/#special-authority-ignore-slashes-state

[10:01:10.0000] <JohnMH>
This is suggesting that any given number of slashes should be accepted, or that a backslash is even a possible character

[10:01:42.0000] <nox>
"syntax violation"

[10:02:17.0000] <nox>
"06:28 <JohnMH> Instead of supporting malformatted URLs, it'd be best to either throw an error at the user or just transparently rewrite it"

[10:02:25.0000] <JohnMH>
That is a UX issue, though

[10:02:28.0000] <nox>
lol

[10:02:30.0000] <JohnMH>
not an issue of the definition of a URL

[10:02:33.0000] <nox>
/me is out of that discussion.

[10:02:57.0000] <JohnMH>
The definition of a URL has nothing to do with how address bars parse input

[10:03:05.0000] <annevk>
correct

[10:03:25.0000] <annevk>
Anyone who states otherwise is wrong

[10:04:08.0000] <JohnMH>
So, perhaps, the entire malformed URL parsing section of this spec should be dropped.

[10:04:33.0000] <annevk>
If it was about address bars, certainly

[10:04:38.0000] <nox>
You do realise that it does exactly what you said in my quote, right?

[10:04:53.0000] <annevk>
Fortunately however we know not to define UX

[10:05:14.0000] <JohnMH>
Right, but UX has nothing to do with URLs.

[10:05:24.0000] <annevk>
As I said

[10:05:49.0000] <JohnMH>
Parsing malformed URLs is entirely UX,

[10:05:49.0000] <annevk>
I sense agreement, yay, time to eat some soup

[10:06:09.0000] <annevk>
Ah no, that's where you're wrong, but still, gotta eat soup

[10:06:15.0000] <nox>
JohnMH: How so?

[10:07:17.0000] <nox>
And as I said, the URL standard says that "https:///" is a syntax violation, btw.

[10:22:01.0000] <JohnMH>
nox: Yes, but it also specifies that it is parsed

[10:22:19.0000] <jyasskin>
JohnMH: The users are the people writing web pages, and the spec describes how to give them a consistent UX.

[10:22:34.0000] <JohnMH>
URLs have absolutely nothing to do with UX

[10:22:39.0000] <nox>
You are free to report an error.

[10:24:19.0000] <jyasskin>
JohnMH: If a website author writes <a href="https:///my-server.com/">, that's parsed according to the URL spec, which defines how to give them and the people browsing their site a consistent experience.

[10:25:07.0000] <annevk>
/me has been reading https://twitter.com/sarahjeong/status/730407790112464897 over dinner, wtf

[10:25:14.0000] <JohnMH>
That consistent experience should include an error message for malformed URLs?

[10:25:23.0000] <annevk>
(the whole thread)

[10:28:33.0000] <gsnedders>
JohnMH: but that isn't what browsers do today or what browsers did a decade ago, and any change would likely break sites

[10:33:33.0000] <JohnMH>
gsnedders: It's not an issue if that breaks sites, it will bring better development to the table and websites which don't fix it will just have errors, like NetScape and IE7 would show for them.

[10:33:58.0000] <jgraham>
ding ding, we have a loser

[10:34:40.0000] <jgraham>
"compatibility doesn't matter" in a didscussion about web browsers immediately shows that your ideas aren't based on the real world

[10:35:58.0000] <gsnedders>
it's an issue if it breaks sites because users simply move to a browser where the site still works, therefore changing behaviour doesn't help

[10:36:17.0000] <annevk>
JohnMH: what's your objective? I wonder if there's some meaningful progress we can make or whether we're just wasting each other's time

[10:37:22.0000] <nox>
Btw it's not like cURL reject https:///google.com/

[10:37:32.0000] <nox>
It just misparses it in a silly way: curl: (6) Could not resolve host: https

[10:38:02.0000] <nox>
So cURL's argument isn't really an URL either, it's like a fancy address bar with its own idiosyncrasies.

[10:38:53.0000] <JohnMH>
curl accepts a valid URL, nothing more

[10:39:19.0000] <JohnMH>
jgraham: I didn't say "compatibility doesn't matter"

[10:39:27.0000] <nox>
It considered https:///google.com/ to be a valid URL then.

[10:39:29.0000] <JohnMH>
In fact, I said they should all give an error when they run into.. an error.

[10:39:43.0000] <JohnMH>
nox: No, it expects it to be a valid URL and attempts to process it

[10:39:58.0000] <nox>
"curl accepts a valid URL"

[10:40:04.0000] <nox>
It accepted https:///google.com/

[10:40:16.0000] <nox>
If I had https as a valid host on my computer, it would have fetched who knows what.

[10:40:22.0000] <jgraham>
http://webcache.googleusercontent.com/search?q=cache:https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/&num=1&strip=1&vwsrc=0 says curl accepts non-RFC things in nonstandard ways

[10:40:28.0000] <nox>
It was a DNS error, not cURL yelling about it not being an URL.

[10:40:37.0000] <JohnMH>
It expects a valid URL, it only does extremely basic URL validation

[10:40:37.0000] <jgraham>
So it doesn't actually meet any standard

[10:41:07.0000] <nox>
lol

[10:41:19.0000] <jgraham>
JohnMH: Compatability in this case being compatibility with content

[10:41:19.0000] <JohnMH>
jgraham: Yes, unfortunately curl has been following browsers in the past few years, that's another issue and I do have an open issue on the curl project

[10:42:00.0000] <annevk>
JohnMH: you're not going to state your objective?

[10:42:01.0000] <JohnMH>
jgraham: Compatibility is not an excuse to accept extremely malformed URLs, in fact, those people should be punished in the best way we can punish them: Simply not parsing their malformed URLs.

[10:42:23.0000] <jyasskin>
JohnMH: I'm interested in annevk's question. Do you have a concrete objective here? Complaining about a lack of purity in WHATWG's specifications really is a waste of time.

[10:42:47.0000] <nox>
See topic.

[10:43:28.0000] <JohnMH>
I'm complaining that WHATWG's URL specification isn't a URL specification at all, but that it is describing what browsers incorrectly call a URL. Either this form should not be dealt with at all, or should be dealt with separately from URLs as I have suggested.

[10:43:51.0000] <jgraham>
That "objective" is pure theoretical purity

[10:43:53.0000] <annevk>
I see, I think I can safely say that neither of those two things will happen

[10:43:59.0000] <jgraham>
It holds little weight here

[10:44:08.0000] <nox>
For as long as I remember, URLs have always been a wild wild west.

[10:44:40.0000] <JohnMH>
jgraham: There is no theoretical purity to it. You define it, you follow it. Any changes go through an acceptance process, and then other people can follow them

[10:44:52.0000] <JohnMH>
If software doesn't follow the standards, that's an issue

[10:45:05.0000] <nox>
If they don't for decades, you just change the standard.

[10:45:30.0000] <jgraham>
JohnMH: Thought experiment. You are a release manager for a browser. An engineer comes to you and proposes changing your URL parser to match the RFCs exactly. After doing some research you find this will break 10% of sites, which will continue to work in competing implementations. What do you do>

[10:45:36.0000] <jgraham>
s/>/?/

[10:45:45.0000] <JohnMH>
That isn't necessarily true. There is nothing that needs changing since RFC 3986

[10:46:17.0000] <nox>
How do you know that?

[10:46:27.0000] <JohnMH>
jgraham: I would accept the properly done URL parser, and suggest that the address bar handle weird input you expect from users.

[10:46:57.0000] <nox>
It's not just about the address bar, but about href attributes and whatnot too.

[10:46:58.0000] <jgraham>
JohnMH: Congratulations, your browser just lost most of its users. You went out of business.

[10:47:02.0000] <JohnMH>
nox: It may surprise you, but the curl project fetches content from URLs. No, I don't mean https:// and http://, I mean protocol://scheme

[10:47:05.0000] <JohnMH>
jgraham: Business?

[10:47:11.0000] <JohnMH>
Why was I trying to start a business for a browser?

[10:47:19.0000] <jgraham>
Sure, browser vendors are businesses

[10:47:20.0000] <nox>
JohnMH: It parsed https://google.com/ as https being a host.

[10:47:38.0000] <nox>
Err, sorry,

[10:47:39.0000] <JohnMH>
Why wasn't it a free software project, which properly respects users' freedoms and accepts changes from users?

[10:47:46.0000] <nox>
https:///google.com/

[10:48:03.0000] <jgraham>
Free software projects can also be businesses and certainly don't accept arbitary changes from users

[10:48:05.0000] <JohnMH>
There is also the issue that the URL specification says that it defines "domains, IPv4 addresses and IPv6 addresses" when in reality it simply references RFCs and says "That's what X is"

[10:48:28.0000] <JohnMH>
jgraham: Not arbitrary, sure. But that's another discussion entirely, and not relevant to this.

[10:49:03.0000] <jgraham>
Anyway, you have clarly demonstrated that you are working from such a different worldview from the other people here that this conversation is never going to be productive.

[10:49:08.0000] <JohnMH>
I don't know why you even brought up browsers, the majority of software which uses URLs aren't browsers, it's misc software from operating systems to application IPC.

[10:49:30.0000] <gsnedders>
the majority of software that processes URLs in web pages is web browsers.

[10:49:35.0000] <gsnedders>
s/is/are/

[10:49:38.0000] <JohnMH>
In web pages, yes

[10:49:38.0000] <JohnMH>
Sure

[10:49:45.0000] <nox>
"If you specify URL without protocol:// prefix, curl will attempt to guess what protocol  you  might want.  It will then default to HTTP but try other protocols based on often-used host name prefixes. For example, for host names starting with "ftp." curl will assume you want to speak FTP."

[10:49:48.0000] <JohnMH>
But URLs are definitely not only used in web pages

[10:50:00.0000] <nox>
JohnMH: How did you see that most URLs aren't used in browsers?

[10:50:20.0000] <JohnMH>
nox: The Android operating system, among other pieces of software, use URLs in IPC

[10:50:28.0000] <JohnMH>
*uses

[10:51:02.0000] <nox>
Given the set of whatever URLs are used in any Android version is fixed,

[10:51:18.0000] <nox>
and given users can waste their time as long as they want to on their phone browsing the Web,

[10:51:29.0000] <nox>
aren't they mostly using URLs from the Web even on their Android phone?

[10:52:30.0000] <JohnMH>
No, definitely not

[10:52:43.0000] <JohnMH>
every time an application is launched, a URL has been passed to that application

[10:53:05.0000] <JohnMH>
Every time there's a notification or other event, there's a URL attached to that, which contains the package name and payload

[10:53:19.0000] <JohnMH>
I'm not saying that's a good idea, but it's one of the largest uses of URLs.

[10:53:50.0000] <nox>
Still smaller than users browsing the Web, UAs doing some AJAX crap, and whatever else.

[10:54:54.0000] <jyasskin>
To avoid confusion, it *might* make sense to clarify that url.spec.whatwg.org covers URLs used on the web, and not URLs used for other purposes. That said, it doesn't seem like Android folks are actually getting confused by this.

[10:55:26.0000] <annevk>
jyasskin: Android uses a different URL library from Chrome?

[10:55:42.0000] <annevk>
jyasskin: I thought Google had a Google-wide URL library

[10:56:12.0000] <jyasskin>
annevk: I'm not an authority on this, but I suspect that Intent parsing uses a different library from Chrome. I could be totally wrong though.

[10:56:25.0000] <gsnedders>
I do still wonder if we want to add a strict flag to fail hard on a parse error as with HTML

[10:56:56.0000] <annevk>
gsnedders: yeah, me too, but I haven't really seen it deployed for HTML and I'm not sure what good it does

[10:57:17.0000] <annevk>
jyasskin: it'd also surprise me if switching to a Chrome-like library would be incompatible with what they do today

[10:58:07.0000] <jyasskin>
/me is double-checking my assumption that Intent parsing uses its own library.

[10:58:44.0000] <gsnedders>
annevk: IMO it makes more sense for URL given things like IPC which use it, where you probably do want to require validity and fail hard

[10:58:50.0000] <jgraham>
I suspect that intents use something java based and chrome for android uses something different

[10:59:16.0000] <annevk>
gsnedders: as with markup, it makes more sense to me that any checks are at the model-level, not syntax

[11:00:00.0000] <JohnMH>
jyasskin: If that were the case, the name should be changed from URL to a more fitting name, such as BRL

[11:00:15.0000] <gsnedders>
annevk: IMO in the IPC case you really want to fail hard than end up with the security consequences of a message going somehwere you weren't expecting

[11:06:09.0000] <jyasskin>
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/content/Intent.java#4690 has the intent parsing code. It calls to android.net.Uri to actually parse the URL, which is in https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/net/Uri.java.

[12:33:44.0000] <annevk>
jyasskin: ah right, should have realized since I was reading about the case in court earlier

[12:34:02.0000] <annevk>
lovely Java

[12:34:51.0000] <annevk>
jyasskin: Android might want to look into http://galimatias.mola.io/

[13:06:19.0000] <JohnMH>
annevk: But that uses the "URL Standard", which is not an actual standard but a set of references and instructions for formatting malformed URLs?

[13:07:39.0000] <JohnMH>
In fact, there is an obvious issue with the software, one the developer admits to..

[13:07:57.0000] <JohnMH>
Even if one wanted to use the "URL Standard", it doesn't parse any scheme other than HTTP and HTTPS

[13:08:11.0000] <JohnMH>
With everything else, it's just "scheme data"

[13:09:05.0000] <TabAtkins>
annevk: Chrome reimplements most things that also exist in "Google-wide" code, because we can't have dependencies into the google3 system if we want it to be independently buildable.

[13:38:56.0000] <jyasskin>
annevk: I don't have much leverage with the Android folks, but also I think gsnedders' point is right, that Intents don't intend or need to parse arbitrary URLs from the web, and should prefer to fail fast because they have security implications. That said, I'm not sure the existing implementation ever fails...

[13:40:18.0000] <annevk>
jyasskin: at that point it might be better to pass around URL records directly

[13:40:50.0000] <annevk>
jyasskin: oh well, doesn't really matter

[13:41:55.0000] <jyasskin>
They have their own legacy problem, in that `new Intent("string")` has worked, and they can't break compatibility with old apps using it, but it's a different legacy problem from the web. :-/

[13:42:06.0000] <gsnedders>
annevk: the IPC might not allow arbitrary objects

[13:55:59.0000] <hober>
why are we putting the url standard in scare quotes now

[14:14:01.0000] <zcorpan_>
"URL" "Standard"

[14:15:07.0000] <TabAtkins>
"U" RL

[14:20:47.0000] <JohnMH>
hober: Because the so-called "URL Standard" isn't actually a URL standard, it's a standard which claims to define URLs, but only defines browser usage of URLs.

[14:46:40.0000] <jgraham>
/me puts "hober" in scare quotes

[14:47:11.0000] <gsnedders>
Father "Ted".

[14:48:54.0000] <SimonSapin>
JohnMH: "With everything else, it's just "scheme data"" the spec changed on that point a few months ago

[14:50:21.0000] <JohnMH>
SimonSapin: I was talking about the library, not the spec itself.

[14:50:59.0000] <JohnMH>
SimonSapin: To suggest that library, with such a serious issue, is definitely not the right thing to do, unless an issue has been opened on the project's tracker.

[14:53:15.0000] <SimonSapin>
JohnMH: sorry, I haven’t followed all the discussion. Which library?

[14:53:22.0000] <hober>
hmm.

[14:54:48.0000] <JohnMH>
SimonSapin: http://galimatias.mola.io/

[15:14:32.0000] <gsnedders>
TabAtkins: http://specs.xanthir.com/css-font-display/ doesn't load

[15:14:49.0000] <gsnedders>
TabAtkins: which https://tabatkins.github.io/specs/css-font-display/ redirects too

[15:26:01.0000] <TabAtkins>
gsnedders: lolwut

[15:27:21.0000] <gsnedders>
TabAtkins: am I being stupid?

[15:27:32.0000] <TabAtkins>
no, i dont' remember why this is happening, is all

[15:31:05.0000] <JohnMH>
TabAtkins: Address doesn't resolve

[15:31:27.0000] <JohnMH>
It's just the subdomain

[15:33:30.0000] <TabAtkins>
yes, i know that the link is broken

[15:33:35.0000] <TabAtkins>
dunno why i have things redirecting

[15:34:04.0000] <TabAtkins>
...huh, because I have a cname file and github pays attention to that now

[15:34:19.0000] <TabAtkins>
don't even remember why i have that

[15:36:15.0000] <TabAtkins>
anyway, deleted

[15:37:51.0000] <JohnMH>
GitHub has always "paid attention" to that

[16:37:02.0000] <zcorpan>
Exception marked using <span> rather than <code>:

[16:37:03.0000] <zcorpan>
7344:  throw an <span>"<code>IndexSizeError</code>"</span> <code>DOMException</code>. Otherwise, first,


2016-05-12
[19:33:24.0000] <Jasper>
Yikes, the URL spec blew up today, didn't it :(

[05:45:45.0000] <hallvors>
annevk: around?

[05:54:19.0000] <hallvors>
In the HTML spec - User Interaction - Drag'n'drop, the DataTransfer stuff doesn't say anything about security risks associated with the *data* or the *type string* - not that I can see anyway

[05:55:02.0000] <hallvors>
e.g. the risk that a rogue page can launch an exploit at a native application by making the user drop a data payload that will trigger a security problem on that app

[05:55:32.0000] <hallvors>
or place something on the clipboard that, when pasted, will trigger some security issue in the target

[05:56:55.0000] <hallvors>
In the context of clipboard API work, I was told in no uncertain terms that allowing a random script to place for example JPG binary data on the clipboard is a no-go since it might target exploitable bugs in some local application's JPG support with a malicious payload

[05:59:08.0000] <hallvors>
shouldn't the DataTransfer API handle such stuff? For example whitelist safe types? Transcode image files for safety?

[05:59:25.0000] <hallvors>
/me should perhaps mail the whatwg-list

[06:06:42.0000] <annevk>
hallvors: filing an issue on GitHub might be better, but yeah, it seems like it should

[06:06:49.0000] <annevk>
hallvors: fancy improving that?

[06:11:23.0000] <hallvors>
annevk: well, some of those limitations are already implemented .. so it should be possible to figure out what it needs to say :-o

[06:12:04.0000] <hallvors>
If it's not done in DataTransfer I'll need to add something to Clipboard API - but then DnD would still be vulnerable so that seems silly

[06:12:06.0000] <annevk>
hallvors: even better

[06:12:47.0000] <annevk>
hallvors: another thing we should improve is make it an object that both drag & drop and copy & paste can use, right? Or does copy & paste use a different object these days? Haven't really followed that much

[06:13:22.0000] <hallvors>
it is used in both DnD and Clipb apis

[06:13:37.0000] <annevk>
Hixie wanted them to share the model entirely so there'd be no distinction and users that can't drag wouldn't be disadvantaged, but it seems like that is hard to do at this point

[06:23:13.0000] <hallvors>
I'll need some handhelding by developers though, if I'm going to write some security thingies ;)

[06:29:16.0000] <hallvors>
annevk: regarding the DnD and Clipboard convergence Hixie wanted, I think it's a good goal, and I think if pages make sure they listen to both drop and paste events it should most just work as he intended

[06:29:53.0000] <annevk>
hallvors: yeah, I guess he was hoping to avoid that pages had to do both

[06:33:05.0000] <hallvors>
We could do that if we spec'ed that pasting should fire drop events.. but it would be sort of odd

[06:33:35.0000] <hallvors>
and go against the legacy paste events

[06:35:04.0000] <annevk>
Yeah, probably not possible

[06:35:07.0000] <hallvors>
but it's easy to listen to both and use basically the same code for processing both pastes and drops

[06:35:28.0000] <hallvors>
that seems reasonable to me..

[08:36:55.0000] <wanderview>
annevk: should same-origin-data-url flag be set for either <script> or <link rel=stylesheet>?

[08:37:09.0000] <wanderview>
I have to run, but will check back later...

[08:37:24.0000] <wanderview>
I can't tell if these are intentionally not there if those specs have not been updated to use fetch

[09:26:29.0000] <jwalden>
/me bemuses himself quasi-trolling the latest WHATWG blog post

[09:59:31.0000] <annevk>
wanderview: I'm not sure

[09:59:55.0000] <annevk>
wanderview: maybe for the latter, depends on whether user agents require the MIME type to be correct I suppose

[10:00:54.0000] <annevk>
jwalden: heh

[10:28:05.0000] <zokier`>
hi, is a plain text version of dom idl available somewhere?

[10:32:09.0000] <zcorpan>
zokier`: don't think so. there's https://dom.spec.whatwg.org/#idl-index or you can maybe scrape it from the source https://github.com/whatwg/dom/blob/master/dom.bs

[10:34:17.0000] <annevk>
Copying the index seems most straightforward

[10:36:38.0000] <zokier`>
sure, thanks. kinda odd imho though

[10:38:16.0000] <TabAtkins>
zokier`: Odd how?

[10:39:03.0000] <wanderview>
TabAtkins: do you know if the spec says anywhere if <link rel="stylesheet'> data URLs should be treated same-origin or cross-origin?

[10:39:22.0000] <TabAtkins>
P sure it does *not* say anywhere.

[10:40:22.0000] <wanderview>
thanks

[10:40:58.0000] <zokier`>
TabAtkins, its just something i would have expected to be easily downloadable

[10:42:13.0000] <Mek>
what is same-origin/cross-origin used for in link rel="stylesheet"?

[10:45:09.0000] <wanderview>
Mek: SRI in my particular case... we don't support SRI on no-cors cross-origin... we have a test case that uses SRI for a data URL

[10:47:42.0000] <annevk>
Mek: CSSOM access, and whether you can omit the MIME type

[10:48:37.0000] <Mek>
wanderview: doesn't the SRI spec explicitly say "Since the response type for data URLs will always be “opaque” for script and link elements, such URLs are never eligible for integrity checks."

[10:49:08.0000] <Mek>
(okay, as non-normative text. But that's also how I would interpret the way css/html/fetch specify fetching stylesheets...)

[10:50:10.0000] <wanderview>
Mek: yes, and I think thats bogus :-) https://github.com/w3c/webappsec-subresource-integrity/issues/35

[10:50:55.0000] <Mek>
well, the way I read the css and fetch specs, it leaves the request which its default mode=no-cors and with the same-origin data-URL flag unset, which would indeed result in an opaque response

[10:51:35.0000] <wanderview>
Mek: css spec uses fetch spec?  can you send me the link to that?

[10:51:45.0000] <Mek>
wanderview: https://drafts.csswg.org/cssom/#fetch-a-css-style-sheet

[10:51:46.0000] <wanderview>
sorry, I have to go to a meeting now

[10:51:47.0000] <wanderview>
thanks

[11:04:06.0000] <smaug____>
annevk: I don't understand the blob part of https://url.spec.whatwg.org/#origin

[11:04:20.0000] <smaug____>
what does "Let url be the result of parsing the first string in URL’s path. " mean?

[11:07:44.0000] <Mek>
the url spec defines a path as a list of zero or more ascii strings, and that then parses the first string in that list as if it was a url?

[11:10:42.0000] <smaug____>
I see

[11:11:12.0000] <smaug____>
and (new URL("blob:blob:http://foo.com/bar")).origin should be "http://foo.com", not blob:// what blink gives

[11:11:44.0000] <Mek>
seems like that to me, yes...

[11:42:27.0000] <zcorpan>
i'm behind with github notifications. if there's something i should look at, let me know here pls :-)

[11:55:12.0000] <Domenic>
zcorpan: https://github.com/whatwg/html/pull/1236 is the other PR assigned to you. Seems reasonably small.

[12:06:23.0000] <wanderview>
Mek: bz wrote an issue for the data URL thing as well: https://github.com/whatwg/html/issues/1243

[12:07:49.0000] <Mek>
yeah, I (uninformed) agree that it seems like this might just be an accidental result of how the specs ended up rather than intentional...

[12:25:48.0000] <zcorpan>
annevk: do you want to review https://github.com/w3c/web-platform-tests/pull/2926 ? since you LGTMed the spec change 🙂

[12:27:03.0000] <annevk>
zcorpan: tomorrow I suppose

[12:27:28.0000] <zcorpan>
ok thanks

[16:16:12.0000] <sicking>
jsbell: ping

[16:16:25.0000] <jsbell>
sicking: what's up?

[16:17:06.0000] <sicking>
jsbell: does Chrome support getting a DirectoryEntry from <input type=file>/<input type=directory> or some such?

[16:17:35.0000] <jsbell>
sicking: yes. Edge is not planning to implement that though.

[16:17:53.0000] <sicking>
jsbell: What's the syntax?

[16:18:10.0000] <jsbell>
sicking: https://docs.google.com/document/d/14fCaoRf5GtdhMwJOVjcQSMDm_varTluyMq8RYyHR8vw/edit

[16:18:37.0000] <jsbell>
HTMLInputElement has webkitEntries

[16:18:53.0000] <jsbell>
But only populated by D&D onto an input, not via clicking

[16:19:02.0000] <sicking>
jsbell: oh, "but only populated via drag&drop"??

[16:19:17.0000] <jsbell>
Yeah, we're awesome apparently.

[16:19:17.0000] <sicking>
why does that restriction exist?

[16:20:32.0000] <sicking>
jsbell: that sounds like just a bug? Or is it intentional?

[16:21:10.0000] <jsbell>
sicking: predates me, so I don't know for certain. probably just never implemented, since D&D is a very different code path than selection via dialog

[16:21:11.0000] <sicking>
i suspect that if we go down the DirectoryEntry route, that we'll go all the way and implement it on <input type=file> as well. But fully through click as well

[16:21:26.0000] <sicking>
jsbell: i see

[16:21:41.0000] <jsbell>
sicking: I added use counters to try and see if it's used

[16:21:48.0000] <jsbell>
But data isn't in yet

[16:21:51.0000] <sicking>
ok

[16:22:13.0000] <jsbell>
sicking: if Edge doesn't implement and it isn't used maybe we can remove. Don't know yet

[16:22:33.0000] <sicking>
jsbell: remove what part? input.webkitEntries?

[16:22:36.0000] <jsbell>
yes

[16:22:53.0000] <sicking>
why remove that? If we're going down the DirectoryEntry path, shouldn't we make it work well?

[16:24:17.0000] <jsbell>
just reducing surface area overall; restrict the Entry stuff to D&D, keep input restricted to Files w/ webkitRelativePath and implied structure

[16:24:43.0000] <jsbell>
But I'm not firmly against, just trying to figure out what is *necessary*

[16:25:36.0000] <jsbell>
I'm also just starting on a spec (like, created index.bs yesterday) for the Entry stuff, i.e. a subset of [[file-system-api]]

[16:27:05.0000] <jsbell>
sicking: not pushed anywhere yet, I'll ping when it's more than a skeleton.

[16:28:04.0000] <sicking>
jsbell: i think both microsoft and mozilla want to have an API that doesn't require sync IO and which enables directory picking

[16:28:28.0000] <sicking>
jsbell: i feel like if we go with DirectoryEntry for d'n'd, we should do the same for directory picking as well

[16:29:03.0000] <jsbell>
that's entirely reasonable, and no objection from me

[16:29:11.0000] <sicking>
cool

[16:30:34.0000] <Domenic>
jsbell: does that mean we can assign https://github.com/whatwg/html/issues/217 to you? :)

[16:33:25.0000] <jsbell>
Wheee. :)


2016-05-13
[22:54:10.0000] <annevk>
https://github.com/w3c/html/commit/180c3a639a0b1998596e16907c8c182c82a7f53a "Integrate changes from other location"

[22:54:29.0000] <annevk>
That is so messed up

[01:30:10.0000] <Ms2ger>
Domenic++

[01:31:39.0000] <annevk>
Ms2ger: script cleanup?

[01:32:05.0000] <Ms2ger>
In particular, but also all the horrible js interaction crap he's been doing :)

[02:05:01.0000] <Ms2ger>
annevk, do you think setting this up would be useful: https://travis-ci.org/Ms2ger/dom/builds/128303192

[02:05:18.0000] <Ms2ger>
To make sure PRs don't accidentally break the spec generation

[02:06:02.0000] <annevk>
Ms2ger: yeah maybe, should ask Domenic too

[02:06:24.0000] <Ms2ger>
Domenic, consider yourself asked :)

[02:06:35.0000] <annevk>
Ms2ger: he had some ideas about running bikeshed on the server instead, and also publishing snapshots

[02:06:43.0000] <Ms2ger>
That'd be nice too

[02:07:04.0000] <annevk>
Ms2ger: with this we could presumably also let Travis post a review URL so you can read the generated HTML rather than the diff

[02:07:36.0000] <annevk>
lots of folks don't like to read spec-HTML, and I can't really blame them

[05:42:59.0000] <annevk>
We should maybe rename tuple origin to network origin

[06:07:18.0000] <jgraham>
Got to love @mention spamming

[06:08:57.0000] <annevk>
jgraham: from wpt?

[06:11:42.0000] <jgraham>
w3c/encryptedmedia

[06:12:00.0000] <jgraham>
Someone deciced to @mention everyone in the w3c github org or something

[06:24:13.0000] <JohnMH>
That's just another flaw with GitHub, should honestly be handled with Bugzilla or with a mailing list and a thread per issue

[06:40:51.0000] <caitp>
a mailing list? ...really?

[06:41:10.0000] <JohnMH>
Yes?

[06:41:50.0000] <JohnMH>
A mailing list is the best way to perform threaded communication.

[06:42:29.0000] <JohnMH>
Unless you use the gmail web client, anyway

[06:42:47.0000] <JohnMH>
If you use a real mail client, you'll have a much better experience.

[06:43:22.0000] <JohnMH>
I would suggest Mozilla Thunderbird, and if you use GNU+Linux I would suggest trying Evolution

[08:04:42.0000] <annevk>
jyasskin: I wonder if some kind of non-HTML sketch of the model would make it easier

[08:04:49.0000] <annevk>
jyasskin: since I suspect everyone is getting lost in the weeds

[08:05:20.0000] <annevk>
jyasskin: also, for me personally I'm having a lot of other things at the moment so I haven't really put as much thought into it as I probably should

[08:06:03.0000] <jyasskin>
annevk: I've got https://docs.google.com/document/d/1sdRwvnG3lAk95RNPHXFSuWQeq9Rx8lgMKPvrmjQ-y4I/edit?usp=sharing, but it doesn't have a lot of examples.

[08:06:12.0000] <annevk>
jyasskin: I'm getting that impression from most other participants too, nobody has this really figured out, not sure if that means we should take a step back or some such

[08:07:41.0000] <jyasskin>
annevk: Yeah. We could set up a VC in a week or two, and I could undo the changes to Bluetooth that rely on having permission storage.

[08:08:08.0000] <annevk>
jyasskin: e.g., one thing that was brought up is privacy mode, but I don't think that is worth of consideration here

[08:08:44.0000] <annevk>
jyasskin: if we introduce that as a thing, that would end up splitting a lot of things into two effectively, I think trying to consider it here in isolation is very distracting

[08:09:27.0000] <jyasskin>
I think privacy mode fits into either of the last two models, but their complexity is needed even to capture Firefox and Safari at the same time.

[08:09:36.0000] <jyasskin>
(Firefox's and Safari's non-private modes)

[08:10:53.0000] <annevk>
jyasskin: so one good thing to do I guess would be to write down the requirements for the more complicated permission types, including the requirements coming from various browsers

[08:13:54.0000] <annevk>
jyasskin: it does seem though that a generic permissions API is not super great given that so far it seems a lot of them have very different requirements

[08:14:08.0000] <annevk>
jyasskin: but maybe there's some primitives we can uncover...

[08:15:26.0000] <jyasskin>
annevk: By "permission types", do you mean the values of the PermissionName enum, or the kinds of ways that browsers store permissions?

[08:16:09.0000] <annevk>
jyasskin: former

[08:20:21.0000] <jyasskin>
'k, I'll make a document listing their behavior.

[08:25:47.0000] <annevk>
jyasskin: thanks, I still feel like I'm not really helping you, but I should have more time soon

[08:34:09.0000] <jyasskin>
annevk: Thanks for the help you have been providing.

[13:53:10.0000] <wanderview>
Domenic: is there a description of this spec language using "!" or "?" before calling a function?  for example, "Return ! CreateArrayFromList(branches)."

[13:53:28.0000] <Domenic>
Heh, that's a popular topic today..

[13:53:35.0000] <Domenic>
https://tc39.github.io/ecma262/#sec-algorithm-conventions

[13:53:45.0000] <Domenic>
seems like we should link all !s and ?s to there

[13:54:41.0000] <wanderview>
hmm

[13:54:51.0000] <wanderview>
ecmascript docs hurt my brain

[13:55:23.0000] <wanderview>
seems "?" means that the algorithm may abort depending on the returned result?

[13:55:29.0000] <wanderview>
and "!" are essentially infallible?

[13:55:49.0000] <Domenic>
Yep that's the idea

[13:55:52.0000] <caitp>
? used to be written as ReturnIfAbrupt, basically

[13:56:15.0000] <wanderview>
ok, thanks

[13:56:23.0000] <Domenic>
Sorry for the confusion :-/

[13:56:36.0000] <wanderview>
Domenic: how is a logic not operation written if we are using "!" for this?

[13:56:55.0000] <Domenic>
wanderview: "if true, false. if false, true"

[13:57:13.0000] <Domenic>
Usually you just end up saying "if x is false"

[13:57:13.0000] <wanderview>
ok

[14:13:12.0000] <wanderview>
Domenic: how can "highWaterMark" be undefined in new ReadableStream() step 7a?  It seems to default to 1

[14:13:37.0000] <wanderview>
new ReadableStream(underlyingSource = {}, { size, highWaterMark = 1 } = {})

[14:14:12.0000] <Domenic>
wanderview: good catch, we didn't fix the heading when we introduced the different defaults

[14:14:24.0000] <wanderview>
Domenic: I'll write an issue

[14:15:57.0000] <wanderview>
Domenic: https://github.com/whatwg/streams/issues/447

[14:16:49.0000] <Domenic>
\o/

[14:19:59.0000] <wanderview>
Domenic: is the ReadableStream spec pretty stable now?

[14:20:03.0000] <wanderview>
any more large changes in the works?

[14:20:15.0000] <Domenic>
wanderview: apart from piping, yes, i'd say very stable

[14:20:35.0000] <wanderview>
but we need WritableStream for that, though, right?

[14:20:38.0000] <Domenic>
exactly

[14:20:44.0000] <wanderview>
k

[14:20:49.0000] <Domenic>
writable/transform/piping still unstable, sadly

[14:21:59.0000] <wanderview>
the controller changes seem pretty extensive

[14:28:37.0000] <Domenic>
Yeah... the actual behavior changes were very minor, but Takeshi moved a bunch of stuff into the controller to fit your suggestion as to how to use the revealing constructor pattern to customize one class into doing two jobs

[14:29:29.0000] <wanderview>
yea... I think it will be good to avoid the two types

[14:29:40.0000] <wanderview>
just unwinding what that means for our first cut at streams

[14:29:56.0000] <wanderview>
I think I'm just going to update it all to the new spec language

[14:30:52.0000] <Domenic>
We have something that might be helpful... Takeshi updated the implementation for the new changes, just without any byte stuff yet

[14:31:09.0000] <Domenic>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/streams/ReadableStream.js&q=ReadableStream.js&sq=package:chromium&l=1

[14:34:23.0000] <wanderview>
Domenic: thanks!  although our self-hosting code looks a bit different

[14:34:28.0000] <wanderview>
may not be able to use that too much

[14:34:51.0000] <Domenic>
yeah that's fair

[14:35:09.0000] <wanderview>
for example, our self-hosted code doesn't support constructors directly :-(

[14:35:28.0000] <wanderview>
we have to bounce through c++ the first time to a constructor handle, etc

[14:35:31.0000] <wanderview>
good times

[14:35:40.0000] <wanderview>
anyway, I have to run to dinner

[14:35:44.0000] <wanderview>
thanks for the help!

[14:39:41.0000] <Domenic>
anytime!

[14:45:55.0000] <zcorpan>
still have 1h to answer the #HTMLQuiz y'all 📢 https://twitter.com/zcorpan/status/730891209019822084

[14:49:13.0000] <Domenic>
I checked after my answer; I got it wrong :(


2016-05-14
[22:18:53.0000] <annevk>
I was wrong too

[10:48:34.0000] <zcorpan>
https://github.com/Fyrd/caniuse/pull/2512


2016-05-15
[17:02:55.0000] <Domenic>
Was wondering how to handle that.

[17:04:42.0000] <Domenic>
It looks like caniuse is very responsive to PRs but not very responsive to bugs. Maybe we should be more proactive about adding entries.

[06:24:15.0000] <annevk>
"The semantic web project failed because it didn't have the most influence, even if it was the better idea."

[06:24:31.0000] <annevk>
This URL issue is really going places

[06:54:14.0000] <nox>
XRI? Didn't know that one.

[07:22:39.0000] <nox>
annevk: All these emojis on that ticket.

[07:22:42.0000] <nox>
/me shakes head.

[12:01:20.0000] <timwis>
Hey folks, I'm learning about web components (without polymer). I'd like to use something like <x-profile name="tim"> and access the name attribute from within the <template> that's put into its shadowdom. Any idea how to access attributes from within the template?

[12:38:23.0000] <annevk>
timwis: shadowRoot.host.getAttribute()?

[12:56:10.0000] <timwis>
annevk: looks like shadowRoot is not defined

[12:56:43.0000] <timwis>
http://codepen.io/timwis/pen/mPgozd?editors=1011

[12:57:44.0000] <annevk>
timwis: that's not a global

[12:58:17.0000] <annevk>
timwis: you'll have to get there from some node in the shadow tree


2016-05-16
[18:01:38.0000] <gsnedders>
/me wonders how useful MSR's tooling around contracts is, is the static checker sound?

[18:01:56.0000] <gsnedders>
If it is, it could well be interesting to reimplement the parser.

[18:09:35.0000] <gsnedders>
Can someone hel with <https://github.com/html5lib/html5lib-tests/issues/78>? I don't have the AAA paged in and have come to a completely nonsense conclusion

[23:29:50.0000] <annevk>
http://the-orbit.net/almostdiamonds/2012/02/28/dont-feed-the-trolls-is-bad-science/ interesting

[02:44:19.0000] <zcorpan>
MikeSmith: do you think html-markup/ could get a position:fixed warning?

[02:58:29.0000] <zcorpan>
MikeSmith: seems like checker.html5.org doesn't give an error for <p title="&amp=">, so no change needed for https://github.com/whatwg/html/pull/1220

[03:22:07.0000] <zcorpan>
MikeSmith: found a bug though; &a{491};

[03:22:11.0000] <zcorpan>
er

[03:22:30.0000] <zcorpan>
MikeSmith: found a bug though; &a{941}; is not a parse error

[03:22:48.0000] <zcorpan>
i.e. a very long entity

[03:54:31.0000] <jgraham>
/me wonders if anyone with a b.m.o account fancies doing a quick review of some test changes?

[04:12:57.0000] <nox>
annevk: Were some comments deleted from the URL issue? oO

[04:13:56.0000] <annevk>
nox: not by me

[04:14:08.0000] <nox>
annevk: Oh don't worry, wasn't implying this. :)

[04:14:20.0000] <nox>
annevk: I was trying to show the semantic web thing to a friend but it disappeared. :)

[04:15:40.0000] <annevk>
nox: https://github.com/mark-otaris seems to have disappeared from GitHub

[04:15:57.0000] <nox>
annevk: Hah.

[04:16:46.0000] <nox>
annevk: The weird thing is that usually comments are preserved and appeared as being written by 'ghost'.

[04:16:52.0000] <nox>
appear*

[04:18:23.0000] <annevk>
nox: according to the audit log this person did mutate their comments

[04:18:39.0000] <nox>
annevk: There is such a thing on GH? :O

[04:18:46.0000] <nox>
TIL.

[04:19:13.0000] <annevk>
nox: it's recent, for WHATWG we don't record the details of the events though, think you'd have to manually add something for that

[04:19:27.0000] <nox>
annevk: Oh like, through the webhooks or something like that?

[04:19:46.0000] <annevk>
nox: yeah, but we do have a log that says something happened

[04:19:53.0000] <nox>
Nice.

[04:23:46.0000] <annevk>
tyoshino: when do you think you'll have time to review the CORS change to allow * in more places?

[07:45:58.0000] <wanderview>
annevk: we does the fetch spec seem to say to add the Origin header all the time and not just for cross-origin CORS?  that seems like a change

[07:47:06.0000] <annevk>
wanderview: Origin header is a mess :-/

[07:47:20.0000] <annevk>
wanderview: there's various issues on figuring out when exactly it should be included

[07:47:26.0000] <annevk>
wanderview: sorry

[07:47:27.0000] <wanderview>
annevk: gecko only sets Origin header if CORS is in use and the request goes cross-origin

[07:47:38.0000] <wanderview>
annevk: is there an open spec issue?

[07:47:59.0000] <annevk>
wanderview: the specification attempted to match an additional case where Chrome would transmit the header for XSRF preventive purposes

[07:48:13.0000] <annevk>
but I failed capturing the semantics accurately

[07:48:38.0000] <wanderview>
I see this issue: https://github.com/whatwg/fetch/issues/225

[07:48:42.0000] <annevk>
wanderview: see https://github.com/whatwg/xhr/issues/31 and various Fetch issues linked from there

[07:49:00.0000] <annevk>
wanderview: that works as an entry point too

[07:50:31.0000] <wanderview>
annevk: fwiw, this is the gecko bug I was trying to answer that led me to this stuff: https://bugzilla.mozilla.org/show_bug.cgi?id=1272302

[07:50:53.0000] <annevk>
/me has been postponing opening that

[10:13:04.0000] <Domenic>
Looks like MS implemented a different notifications spec than Chrome and Firefox: https://blogs.windows.com/msedgedev/2016/05/16/web-notifications-microsoft-edge/

[10:13:16.0000] <Domenic>
I guess Safari also implemented the W3C one?

[11:15:13.0000] <smaug____>
rbyers: do you happen to know why chrome is so inconsistent in what kind of mouse events are being dispatched to <select size=1> when opening and selecting some value from the popup?

[11:15:22.0000] <smaug____>
or just some random historical reasons

[11:33:14.0000] <rbyers>
smaug: I didn't know there was an issue but <select> is weird because it creates it's own OS-native window (to support overhanging the contents bounds) so it's probably just bugs as a result of implementation complexity.

[11:34:15.0000] <smaug____>
right. yeah, the dispatched events just depend on the OS

[11:34:34.0000] <smaug____>
Windows vs. Linux vs OSX being all different

[11:34:56.0000] <smaug____>
regarding mousedown/up/click events

[11:35:49.0000] <rbyers>
Yeah.  There's related issues we're looking at for mouse event behavior across browser windows in different OSes - trying to get most consistency between platforms and browsers there.

[11:36:06.0000] <rbyers>
But I haven't personally looked at the <select> case in particular - feel free to file a bug and we can look into details


2016-05-17
[02:18:16.0000] <zcorpan>
can someone check http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4196 in Edge?

[02:21:06.0000] <annevk>
https://irccloud.mozilla.com/file/43yfepoT/edge13.png

[02:21:13.0000] <annevk>
zcorpan: ^^

[02:21:17.0000] <zcorpan>
ty

[03:07:40.0000] <robertkowalski>
Domenic: i was three weeks on cuba, catching up this week

[04:42:59.0000] <zcorpan>
AAA ;_;

[04:43:10.0000] <zcorpan>
https://github.com/html5lib/html5lib-tests/issues/78

[04:49:55.0000] <gsnedders>
I /think/ the test is right. FF nightlies agree with the test, at least.

[04:49:59.0000] <gsnedders>
I could of course be wrong.

[04:51:11.0000] <nox>
gsnedders: I may be dumb,

[04:51:20.0000] <nox>
gsnedders: I don't see anything that contradicts your comment https://github.com/html5lib/html5lib-tests/issues/78#issuecomment-219328831.

[04:51:53.0000] <nox>
gsnedders: Oh btw, my Safari gives <aside><em><b></b><em></aside> for the aside part, hah.

[05:06:06.0000] <gsnedders>
nox: I said the em gets removed from the list of active fomratting elements

[05:06:14.0000] <gsnedders>
nox: which means you don't end up with a em in the new aside

[05:06:48.0000] <nox>
gsnedders: Oooooh, right.

[05:07:24.0000] <nox>
gsnedders: But isn't iabudiab wrong about <em> not being removed as per the spec?

[05:07:34.0000] <gsnedders>
nox: I believe he is

[05:07:38.0000] <gsnedders>
wait

[05:07:42.0000] <gsnedders>
there's too many negatives there

[05:07:58.0000] <nox>
:D

[05:08:07.0000] <nox>
gsnedders: "So in this case the <em> wouldn't be removed via the following step If inner loop counter is greater than three and node is in the list of active formatting elements, then remove node from the list of active formatting elements"

[05:08:10.0000] <nox>
This sounds wrong to me.

[05:08:21.0000] <gsnedders>
That's what I think is wrong.

[05:08:27.0000] <gsnedders>
With his understanding.

[05:10:39.0000] <nox>
And as per the spec in step 13.6, <em> should be removed from the stack of open elements too.

[05:12:09.0000] <nox>
IMO WebKit/Chromium/IE11 don't follow the spec, and the test is consistent with the spec.

[05:12:17.0000] <nox>
But WebKit/Chromium/IE11 not following the spec means the spec needs to change, right?

[05:12:35.0000] <Ms2ger>
Usually

[05:13:10.0000] <nox>
Though <em><b> looks quite insane in that case. :/

[05:14:51.0000] <gsnedders>
I /think/ they don't have the inner loop limit?

[05:15:00.0000] <gsnedders>
Which means you can still end up with O(n^2) behaviour, no?

[05:15:49.0000] <nox>
gsnedders: They being the three UAs I mentioned?

[05:15:59.0000] <nox>
OP seemed to imply that WebKit do limit the inner loop.

[05:16:31.0000] <nox>
Cf. code in https://github.com/html5lib/html5lib-tests/issues/78#issuecomment-219421046

[05:30:01.0000] <gsnedders>
nox: right, I believe WebKit, Blink, and html5lib-python are all wrong here

[05:33:28.0000] <nox>
gsnedders: They should all follow what Servo does obviously!!1!

[05:34:25.0000] <gsnedders>
nox: and gecko

[05:40:01.0000] <gsnedders>
/me is trying to find where this changed

[05:40:08.0000] <gsnedders>
because the spec definitely used to agree with WebKit

[06:37:06.0000] <MikeSmith>
Domenic: about the MS notifications implementation, how can you tell it '

[06:37:37.0000] <MikeSmith>
Domenic: about the MS notifications implementation, how can you tell it’s a different spec? Their blog post has no code

[06:38:42.0000] <MikeSmith>
I was surprised to see them announce they were adding any notifications support at all, so not surprised to find out that they didn’t implement it to spec

[06:43:11.0000] <MikeSmith>
hahah

[06:44:37.0000] <annevk>
MikeSmith: "Microsoft Edge also supports the event model as defined by the W3C spec, including all the show, click, close, and error events."

[06:45:51.0000] <annevk>
MikeSmith: though if they're also going to support them for service workers they'll have some rather inconsistent model

[06:46:45.0000] <MikeSmith>
annevk: yeah I realized that after I typed the above

[06:46:53.0000] <MikeSmith>
this is rich in irony

[06:47:28.0000] <MikeSmith>
for anybody who says what is important to them is interoperability

[06:48:26.0000] <MikeSmith>
and also for the fact that the whole reason we had to create a separate WG for Notifications is because one vendor forced us into it

[06:49:12.0000] <MikeSmith>
anyway, I guess if they don’t yet have service workers implemented then they can’t support the current spec

[06:50:59.0000] <annevk>
MikeSmith: also means a certain vendor never waived their patents

[06:51:42.0000] <MikeSmith>
yup

[06:51:50.0000] <MikeSmith>
free ride

[06:53:29.0000] <MikeSmith>
I wonder if they actually know that “The implementation in Microsoft Edge is based on the W3C Web Notifications specification, now supported broadly across modern desktop browsers.” is not true

[06:53:48.0000] <MikeSmith>
well I mean the part after the commaa

[06:53:57.0000] <MikeSmith>
ah, desktop

[06:54:27.0000] <annevk>
I wonder if Chrome and Firefox have actually unshipped those events

[06:54:32.0000] <MikeSmith>
I guess that’s why they qualified it with the word “desktop”

[06:54:47.0000] <annevk>
Perhaps they implemented those events because implementers never removed support for them

[06:54:54.0000] <MikeSmith>
I don’t know about the events, for the old API does not work on mobile

[06:55:03.0000] <MikeSmith>
yeah maybe so

[06:55:38.0000] <annevk>
It's kind of a shame they have the feeling they can't even say those kind of things in public

[06:56:02.0000] <annevk>
It's not like these blog posts are helping convergence

[06:56:28.0000] <MikeSmith>
yeah

[07:16:09.0000] <annevk>
I think zcorpan might have missed that https://github.com/whatwg/html/pull/1267 is a pull request?

[07:27:22.0000] <Domenic>
The fetch issue on header lowercasing is pretty cool. Good compromise and people working together for a solution that seems to get better each time someone revises it. WHATWG in action.

[07:34:42.0000] <daleharvey>
So got a fun problem with anyone familiar with indexeddb (also know anywhere better to ask about this?)

[07:35:39.0000] <daleharvey>
I have a library (pouchdb), I want to expose the ability for users to define their own indexes at runtime (ie after schema creation)

[07:39:07.0000] <daleharvey>
even without them being defined at runtime and being done at schema creation it is still fairly complex, the user will certainly require the ability to change indexes outwith the versioning of the schema, and pouchdb will still need to track the schema version number for actual data migrations

[07:39:59.0000] <annevk>
daleharvey: when jsbell is around it'd be a good time to ask

[07:40:30.0000] <daleharvey>
ah cool, yeh I have been in touch with him before about chrome idb bugs, will look out for, cheers

[07:44:43.0000] <annevk>
daleharvey: have you looked at persistent storage btw? https://storage.spec.whatwg.org/

[07:45:13.0000] <annevk>
daleharvey: would appreciate feedback in the GitHub repo if you have any, no implementations yet though, still being worked on

[07:45:39.0000] <daleharvey>
oh I havent yet, will definitely take a look, thanks

[07:47:17.0000] <daleharvey>
still reading, but did you manage to get in implicit persistence? ie if a PWA is saved / installed then storage is persistent by default?

[07:49:15.0000] <annevk>
daleharvey: needs some rewording here and there, but the idea is that the permission can be granted in such a way, yes

[07:50:17.0000] <annevk>
daleharvey: probably still best if the developer invokes the method at that point to persist, in case they have a different storage strategy in mind

[08:07:39.0000] <annevk>
Domenic: for browser testing, get Google to buy you a BrowserStack account

[08:07:52.0000] <Domenic>
that's probably a good idea.

[08:08:00.0000] <annevk>
Domenic: it's quite nice, I use that now for Edge since I got tired of running a VM

[09:55:15.0000] <wanderview>
Domenic: do you know the answer to this streams spec notation question? https://bugzilla.mozilla.org/show_bug.cgi?id=1272697#c4

[09:57:11.0000] <Domenic>
wanderview: answered

[09:57:20.0000] <wanderview>
thanks!

[09:57:46.0000] <annevk>
Domenic: why can't we use "." for both?

[09:58:12.0000] <Domenic>
annevk: not really sure...

[09:58:20.0000] <Domenic>
Maybe another ECMA262 issue...

[09:58:32.0000] <annevk>
Domenic: sure

[10:02:31.0000] <annevk>
https://github.com/tc39/ecma262/issues/574

[10:54:58.0000] <Domenic>
TabAtkins: can I have Bikeshed specify a default for when I don't use for=""?

[10:55:09.0000] <TabAtkins>
Domenic: Yeah, link-defaults

[10:55:54.0000] <TabAtkins>
(And remember, if you ever need to *explicitly* refer to a dfn *without* a for='', use for="/".)

[10:55:55.0000] <jyasskin>
TabAtkins: It'd be really nice for terms with both a <dfn>term</dfn> and a <dfn for="parent">term</dfn>, if <a>term</a> would automatically assume for="".

[10:56:31.0000] <TabAtkins>
jyasskin: That's precisely the sort of thing that is *very* commonly an error and I *can't* assume, unfortunately.

[10:56:53.0000] <jyasskin>
:(

[10:57:58.0000] <Domenic>
TabAtkins: oh, the thing jyasskin is asking for is what I was asking for :(

[10:58:09.0000] <TabAtkins>
I was just having this discussion with fantasai - there's a border area where the likelihood of magic hiding errors outweighs the annoyance of having to manually specify things.

[10:58:20.0000] <TabAtkins>
Domenic: Yeah, you can *force* Bikeshed to assume that. I just can't do it automatically.

[10:58:26.0000] <TabAtkins>
Like I said, do a link-defaults line for it.

[10:58:31.0000] <Domenic>
Oh hmm

[10:58:34.0000] <TabAtkins>
with "for: /;" in it

[10:58:44.0000] <jyasskin>
Does a link-defaults of just "for: /; term: the term" do this, or do we also have to say the spec?

[10:58:57.0000] <Domenic>
doesn't seem to be working... spec: FETCH; type: dfn; text: referrer policy; for: /;

[10:59:07.0000] <Domenic>
[1;33mLINK ERROR:[0m Multiple possible 'dfn' local refs for 'referrer policy'.

[10:59:07.0000] <Domenic>
Arbitrarily chose the one with type 'dfn' and for ''.

[10:59:20.0000] <TabAtkins>
Hmmmm, that should work. I'll debug and fix today.

[11:01:02.0000] <TabAtkins>
jyasskin: I think you need the spec.

[11:11:08.0000] <Domenic>
Hmm [WHATWG-DOM] again...

[11:28:58.0000] <jgraham>
zcorpan: Is window.resizeTo expected to be sync?

[11:33:17.0000] <TabAtkins>
Domenic: If you ever refer to [DOM] in the spec, it'll use that in the biblio. It's just [WHATWG-DOM] in the db, so it'll use that if there's nothing else telling it which tag to use (such as if you only picked up that biblio entry indirectly, from an autolink pointing to a term in that spec)

[11:33:46.0000] <Domenic>
TabAtkins: I see. Yeah, all I did was add <a>node document</a>; it doesn't really make sense to put [DOM] there

[11:34:12.0000] <TabAtkins>
K. Fixing that more thoroughly is more effort than I'm willing to put in for something that's still *supposed* to be temporary. ^_^

[11:34:41.0000] <Domenic>
ya tobie, that's supposed to be temporary ;)

[11:35:19.0000] <jgraham>
zcorpan: BTW Iam very much hoping the anser is "no"

[11:35:41.0000] <jgraham>
Because I don't think that's possible to implement in many WMs (and I doubt browsers do it)

[11:37:20.0000] <jgraham>
/me guesses that zcorpan is not really around

[11:40:08.0000] <tobie>
Domenic: heh

[11:46:32.0000] <TabAtkins>
Domenic: "referrer policy" is in HTML. Is that the definition you want to refer to?

[11:46:45.0000] <Domenic>
TabAtkins: nope, I want to refer to the one in Fetch

[11:47:03.0000] <Domenic>
TabAtkins: except for when I do for="Document"

[11:47:06.0000] <TabAtkins>
Oh, that's not in Shepherd.

[11:47:07.0000] <Domenic>
https://github.com/w3c/webappsec-referrer-policy/pull/49 has the problematic code

[11:47:19.0000] <Domenic>
Sure but I put it in the links section

[11:48:51.0000] <TabAtkins>
Domenic: It looks like you just added a link-defaults for it.  Did you add it somewhere else that I'm not seeing?

[11:49:18.0000] <TabAtkins>
Because link defaults just sets up the defaults for links. If the spec in question isn't in the db, it doesn't matter *what* the links specify, obviously. ^_^

[11:49:19.0000] <Domenic>
TabAtkins: line 24

[11:49:59.0000] <TabAtkins>
Ah, kk. (That wasn't changed in the commit, so I didn't see it.)

[11:51:01.0000] <Domenic>
ah right

[11:57:37.0000] <TabAtkins>
Okay, I've reproduced the issue. It's because <pre class=anchors> things are treated as local (so they'll get picked over other collisions, since you presumably *meant* to use them), and locals don't look at as many of the defaulting things. I'll see what I can do to fix this.

[11:59:13.0000] <TabAtkins>
Funky collision of heuristics here, ugh.

[12:14:03.0000] <Domenic>
\o/

[12:15:29.0000] <annevk>
Domenic: https://twitter.com/mpotra/status/732628389065035776

[12:17:04.0000] <gsnedders>
Someone mentioned that the TAG had concluded everyone should just use URL. Any citation?

[12:32:17.0000] <TabAtkins>
plinss mentioned that

[12:39:46.0000] <gsnedders>
TabAtkins: that's not a citation :P

[12:39:58.0000] <TabAtkins>
I know, I was just filling in the hole in your statement.

[12:41:36.0000] <TabAtkins>
Domenic: Your issue will require more work than I can do right now (I'm trying to get Echidna publishing working), so I've filed it as https://github.com/tabatkins/bikeshed/issues/710

[12:41:51.0000] <Domenic>
TabAtkins: OK cool, thanks

[12:41:59.0000] <Domenic>
at least it's "arbitrarily" picking the right version for now

[12:43:14.0000] <TabAtkins>
It really is arbitrary, since it depends on the ordering of Python dicts.

[14:00:34.0000] <jyasskin>
Domenic: Dumb question: why do you need to distinguish internal slots from record fields named like [[something]]?

[14:01:53.0000] <Domenic>
jyasskin: yeah, we're not really clear, upon reflection. I guess it'd be similar to keeping -> and . as separate in C++, even if pointers could never have normal properties; they have different semantics, sure, but maybe we should just consolidate (like, say, C# does, despite having both value and reference objets).

[14:02:19.0000] <Domenic>
jyasskin: annevk opened https://github.com/tc39/ecma262/issues/574 to discuss further

[14:02:42.0000] <jyasskin>
/me subscribes.

[14:05:41.0000] <jyasskin>
IIUC, the difference between an attribute on an interface vs a field on a record is that the attribute is a getter/setter on the prototype of the JS object, but a field is just a field directly on the JS  object. But an internal slot acts like a field on the object, so it actually should be accessed like a record field.

[14:05:50.0000] <jyasskin>
s/record/dictionary

[14:06:28.0000] <Domenic>
agreed. The [[s are enough to make it clear it's internal, now that I think about it

[14:06:43.0000] <jyasskin>
\o/

[15:09:01.0000] <wanderview>
Domenic: how significant is it that the streams spec defines IsReadableStream() as an internal slot check vs essentially an instanceof ReadableStream check?

[15:09:29.0000] <Domenic>
wanderview: pretty significant. Otherwise you could fool it by doing `var o = {}; o.__proto__ = ReadableStream.prototype`

[15:09:43.0000] <Domenic>
Then you'd start asking `o` for a bunch of interesting internal state, and bad things would happen

[15:09:58.0000] <wanderview>
Domenic: so its intended to be more strict, then...

[15:10:03.0000] <Domenic>
yes indeed

[15:10:06.0000] <Domenic>
it's a brand check

[15:10:41.0000] <wanderview>
Domenic: ok, so if we have a way of doing the brand check via an intrinsic, that should be fine to use vs the spec version

[15:10:55.0000] <Domenic>
wanderview: yeah as long as it can't be fooled, it should be fine

[15:13:35.0000] <wanderview>
Domenic: hmm, I guess our intrinsic could be fooled by Reflect.setPrototypeOf()

[15:14:13.0000] <Domenic>
wanderview: right, that was my __proto__ example... seems bad?

[15:14:48.0000] <wanderview>
Domenic: the problem with the slot check for me is that we don't have names for slots... really just indexes that a constant maps to

[15:16:07.0000] <Domenic>
wanderview: I see. I guess you probably need to reserve the 0th-index slot to have a guid or something you can check... I wonder if that's how SpiderMonkey does it for Promise and Map and friends?

[15:16:51.0000] <wanderview>
Domenic: I'll look and see what they do... thanks


2016-05-18
[18:52:22.0000] <miketaylr>
hi hasather

[00:01:23.0000] <zcorpan>
jgraham: i dunno... http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4205 looks like the reported outerWidth is sync in chrome/safari/opera (on mac) but not in firefox?

[00:02:05.0000] <zcorpan>
jgraham: does gecko have a bug reported about this?

[00:37:39.0000] <jgraham>
zcorpan: So we were discussing the implementation of this in Servo and it turns out that X11 doesn't allow you to make this sync. It has a mechanism to ask the WM to set a window size, and a mechanism to get events when the window size changes, but no coordination between the two. So if you ask for a size change you may get ignored at the WM level (consider a tiling WM) and never get an event back, or you may get an animated transition and get multi

[00:37:46.0000] <jgraham>
... might get an event related to some other resize that has happened.

[00:40:54.0000] <zcorpan>
jgraham: you could maintain size information separately, and resizeTo could update that information sync and ask the WM to resize. but i don't have an opinion either way how this should work, really.

[00:41:40.0000] <jgraham>
zcorpan: But that information would be wrong if the resize doesn't actually happen at the WM level

[00:42:34.0000] <zcorpan>
yeah, right.

[00:44:32.0000] <zcorpan>
jgraham: what happens in chrome in such a case?

[00:46:42.0000] <jgraham>
zcorpan: Not sure

[02:03:01.0000] <zcorpan>
i'm happy that i now understand enough of git to be able to work through simple mistakes like forgetting to create a local feature branch and committing to master (locally). when i started using git i'd sigh and remove my working copy and do a fresh clone and start over

[02:08:59.0000] <Ms2ger>
Been there...

[02:18:42.0000] <nox>
zcorpan: Git is the only DVCS that should come with a Remote Desktop Assistant.

[02:19:57.0000] <zcorpan>
is there a git plugin that will warn me if there are unstaged changes when doing git commit --amend?

[02:22:48.0000] <Ms2ger>
  var ltr = new Array(),

[02:22:48.0000] <Ms2ger>
      all = document.querySelectorAll('*');

[02:22:48.0000] <Ms2ger>
  for(var i = all.length; i--; ltr.unshift(all[i]));

[02:34:10.0000] <nox>
zcorpan: No, because that's a feature to be able to leave unstaged changes on amend. Maybe you could do a hook though.

[02:37:19.0000] <davve>
zcorpan: or maybe you can use an alias like: "amend = "!sh -c 'git diff --quiet && git commit --amend || echo Your working directory has unstaged changes.'"" in ~/.gitconfig and then use 'git amend'. (Not well tested...)

[02:47:04.0000] <zcorpan>
davve: thanks! seems to do the trick. just need to learn to type git amend :-)

[02:57:46.0000] <zcorpan>
iirc IE6 did something weird with class in particular https://twitter.com/RReverser/status/732527451973267456

[03:00:26.0000] <zcorpan>
hmm no maybe that was style

[03:01:32.0000] <zcorpan>
yep :-)

[05:06:15.0000] <annevk>
tyoshino: yhirano_: if you're around: https://github.com/whatwg/fetch/pull/298

[07:19:43.0000] <annevk>
so <link rel=stylesheet href=... crossorigin> is fairly useless if that fetches further stylesheets that don't get fetched with CORS

[07:20:00.0000] <annevk>
since then only the initial one can be accessed through CSSOM...

[07:20:13.0000] <annevk>
but I guess nobody uses the CSSOM so it's not a problem?

[07:35:53.0000] <tamird>
Hello folks! Can anyone tell me what a BufferSource is? https://fetch.spec.whatwg.org/#bodyinit

[07:42:48.0000] <annevk>
tamird: https://heycam.github.io/webidl/#common-BufferSource

[07:44:26.0000] <tamird>
thanks

[07:46:23.0000] <annevk>
https://blogs.windows.com/msedgedev/2016/05/17/es6-modules-and-beyond/ seems to rather carefully avoid where <script type=module> is defined

[07:50:27.0000] <tamird>
@annevk thanks! is there a reason BufferSource isn't on MDN?

[07:51:02.0000] <annevk>
tamird: I don't know, do they normally document typedefs?

[07:51:18.0000] <tamird>
looks like it? https://developer.mozilla.org/en-US/docs/Web/API/ArrayBufferView

[07:55:54.0000] <annevk>
tamird: yeah, guess BufferSource should be added then

[07:56:02.0000] <tamird>
https://github.com/whatwg/html/issues/1273

[07:56:43.0000] <annevk>
tamird: ah  thanks, if you want to write a PR for that, instructions are in the README ;-)

[07:57:47.0000] <tamird>
ha, okay fine

[07:58:26.0000] <tamird>
goodness this is a few hundred megs

[07:59:20.0000] <annevk>
tamird: kitchen sink of the web platform

[07:59:35.0000] <annevk>
tamird: pretty heavy kitchen sink, come to think of it

[08:06:56.0000] <tamird>
@annevk https://github.com/whatwg/html/pull/1274

[08:08:06.0000] <annevk>
tamird: thanks, looking at that though I realized that HTML itself doesn't have a dependency on BufferSource just yet

[08:08:22.0000] <tamird>
where'd you discover that?

[08:08:24.0000] <annevk>
tamird: it probably should in some places, but we haven't made those changes yet

[08:08:37.0000] <annevk>
tamird: searching for "BufferSource", basically

[08:09:08.0000] <tamird>
just in the spec?

[08:09:16.0000] <annevk>
tamird: yup

[08:10:46.0000] <tamird>
afaict it's only useful in one place (websocket definition)

[08:13:04.0000] <tamird>
@annevk well i'm not sure where to go from here

[08:14:39.0000] <annevk>
tamird: yeah, I'm sorry I made you go through the PR process for something that's not needed (yet)

[08:15:10.0000] <tamird>
ah, so basically fetch needs to become standard before buffersource is added?

[08:15:11.0000] <annevk>
tamird: we need to update WebSocket's definition, but that requires some other changes too in the prose and ideally IDL is changed a bit further to make it easier to work with BufferSource-like objects (there's an open bug on that against IDL)

[08:15:25.0000] <annevk>
tamird: Fetch and HTML and IDL are all independent

[08:15:38.0000] <annevk>
tamird: Fetch depends on IDL's BufferSource definition, HTML doesn't (yet)

[08:15:55.0000] <annevk>
tamird: does that make sense?

[08:16:15.0000] <tamird>
almost - what would have to happen for HTML to depend on BufferSource? it may never, right?

[08:16:37.0000] <tamird>
AFAIK the introduction of websockets predates BufferSource, so the language never references it

[08:19:37.0000] <tamird>
@annevk well I updated my PR such that BufferSource is mentioned in the WS API. i suppose I'll just leave it for now

[08:31:07.0000] <nox>
annevk: https://johnmh.me/blog/2016/05/16/github-stupidity.html wtf

[08:31:14.0000] <nox>
(Re: the comments that disappeared.)

[08:31:19.0000] <nox>
Must be the illuminati.

[08:32:34.0000] <nox>
annevk: Oh wow, he is right. mark-otaris really got shadowbanned.

[08:32:35.0000] <Domenic>
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS is pretty outdated

[08:32:50.0000] <nox>
I hope that's not because of that URL issue, or the GH people are really weird.

[08:34:30.0000] <nox>
Oh, shadowbanned because Tor.

[08:34:33.0000] <nox>
Weird.

[08:50:07.0000] <annevk>
That is shitty

[08:58:44.0000] <nox>
annevk: Yep.

[08:58:57.0000] <nox>
https://twitter.com/nokusu/status/732959239497523200

[09:01:15.0000] <nox>
gsnedders: Glad I don't have to change AAA in h5e. :)

[09:01:46.0000] <gsnedders>
nox: I still need to update html5lib-python to be up-to-date :)

[09:02:11.0000] <nox>
gsnedders: My sincere condolences. :)

[09:02:20.0000] <gsnedders>
nox: still having implemented all the <template> fun!

[09:03:11.0000] <nox>
gsnedders: I implemented <template> before all the slot stuff landed and shadow roots and who knows what else, I can't say I'm in a hurry to work on that again heh.

[09:03:48.0000] <gsnedders>
nox: probably will also find places where we'd applied specific spec patches without updating the rest

[09:25:18.0000] <Domenic>
zcorpan: so only a, audio, del, ins, map, noscript, and video *dont'

[09:25:23.0000] <Domenic>
* close open <p>s?

[09:26:06.0000] <Domenic>
that can't be right

[09:26:38.0000] <Domenic>
wait no that's not what this is about...

[09:27:12.0000] <Domenic>
maybe those are the only elements allowed to contain <p>s that also don't close <p>s

[10:33:06.0000] <tantek>
HTML(5) > (X)HTML

[10:46:34.0000] <gsnedders>
tantek: but what about XHTML5? *hideS*

[10:58:32.0000] <zcorpan>
Domenic: right. the rules for omitting tags only considers conforming DOM trees

[11:00:53.0000] <Domenic>
Oh good, we don't have to remove BroadcastChannel after all... (blink-dev)

[11:02:14.0000] <tantek>
gsnedders: There is no XHTML5. http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid-html5#losing-xmlns

[11:06:30.0000] <Mek>
Domenic: since you apparently care about BroadcastChannel, do you happen to know if firefox wrote any tests for it I could try running against my future implementation?

[11:07:18.0000] <Domenic>
Mek: no, sorry... I mostly just feel constant existential angst about features that are only implemented in one browser, so I was happy that BroadcastChannel is departing from that list.

[11:07:31.0000] <Mek>
makes sense

[11:07:55.0000] <zcorpan>
annevk: the "plan" is to be able to opt-in to CORS on a per-URL basis in CSS with extra syntax to url("" ...stuff here...)

[11:11:26.0000] <annevk>
zcorpan: yeah I know, though unclear how that’ll work yet

[11:11:57.0000] <annevk>
zcorpan: what’s the origin?

[11:13:42.0000] <zcorpan>
annevk: i haven't given it much thought. but it seems like the origin should be that of the document that included the top-level stylesheet

[11:16:35.0000] <annevk>
Think so too, otherwise you could get weird transitive stuff, hmm

[11:22:35.0000] <wanderview>
Mek: looks like we only have mochitests for BroadcastChannel... I think it was implemented before we had good adoption of wpt in the tree

[11:24:54.0000] <Mek>
wanderview: ah, okay, thanks

[16:45:17.0000] <Mek>
hmm, the firefox implementation of BroadcastChannel doesn't seem to entirely match the spec...


2016-05-19
[17:22:37.0000] <wanderview>
Mek: if you found a spec issue, please file a bug here: https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=dupes|Core|DOM

[20:27:33.0000] <Domenic>
Well, if it's in reasonable ways, we could change the spec

[00:21:34.0000] <annevk>
Ms2ger: do you care about a clean merge for https://github.com/whatwg/html/pull/1181? Some more whitespace nits that I'm happy to fix while merging

[00:21:54.0000] <Ms2ger>
Go for it

[00:59:14.0000] <zcorpan>
hmm, the try/catch thing is something i hadn't considered before. http://blog.getsentry.com/2016/05/17/what-is-script-error.html

[01:00:14.0000] <zcorpan>
i wonder if there's still a good reason to mute runtime script errors

[01:00:23.0000] <ondras>
/me would like to ask the same

[01:02:04.0000] <zcorpan>
maybe if you manage to load a script file that you have no idea what it contains, you could learn things from onerror but not with try/catch (if you don't know what to call)

[01:02:48.0000] <annevk>
zcorpan: indeed, that is what is being protected

[01:03:29.0000] <annevk>
zcorpan: does the try/catch approach reveal line numbers and such though? That might be somewhat problematic

[01:10:32.0000] <Ms2ger>
zcorpan, isn't the point more when loading non-script files in script elements?

[01:15:24.0000] <zcorpan>
Ms2ger: yes, that's when you hit a compile-time script error. but the spec also protects runtime ones

[01:16:43.0000] <zcorpan>
if the external script uses (function() { ... })(); and doesn't expose any functions then there's nothing you can call with try/catch

[01:19:49.0000] <zcorpan>
annevk: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4210

[01:21:45.0000] <annevk>
zcorpan: "@http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4210:5:3" is what I get in Firefox

[01:22:21.0000] <annevk>
zcorpan: so I guess it's not really revealing then or really the same level of detail?

[01:23:05.0000] <zcorpan>
so firefox doesn't include the part of the stack that came from another origin

[01:23:34.0000] <annevk>
Part of the problem might be e.stack not being defined

[01:23:41.0000] <annevk>
But what Firefox does seems good

[01:24:03.0000] <annevk>
I wonder if that code in Firefox is also CORS-aware

[01:24:36.0000] <zcorpan>
i don't get cross-origin stacks in safari/chrome/opera

[01:26:09.0000] <annevk>
Good

[01:27:29.0000] <zcorpan>
CORS seems to reveal the stack (even without crossorigin="") http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4211

[01:28:36.0000] <annevk>
Without crossorigin?!

[01:28:38.0000] <annevk>
Argh

[01:29:13.0000] <annevk>
How does that even make sense? Are you sending both credentials allowed and an explicit origin?

[01:29:30.0000] <annevk>
You are not, whoa

[01:29:40.0000] <annevk>
That is a bug

[01:29:57.0000] <annevk>
Security bug even

[01:30:38.0000] <zcorpan>
why is it a security bug?

[01:31:34.0000] <annevk>
zcorpan: because <script> requests are made with credentials, so if the cookies introduce user-sensitive data in the script, those can now leak

[01:31:54.0000] <annevk>
zcorpan: whereas the publisher of the script only wanted to share the script when it was requested without credentials

[01:32:35.0000] <zcorpan>
hmm ok

[01:32:38.0000] <annevk>
I don't know who did this, but CORS should really remain opt-in so there's one layer responsible for handling the security checks

[01:32:46.0000] <annevk>
This kind of adhoc thing is just dangerous

[01:44:22.0000] <annevk>
zcorpan: do you want to file security bugs or should I?

[01:44:42.0000] <annevk>
zcorpan: I guess I'll file one against Gecko and copy you for credit

[01:45:26.0000] <zcorpan>
annevk: you can file, i should start writing a presentation :-)

[02:31:19.0000] <nox>
Is there any spec that replaces the RFCs for CONNECT and HTTP requests made to proxies, btw?

[03:09:42.0000] <kochi1>
I'd like to have apple's feedback for https://github.com/w3c/webcomponents/issues/184 ...

[03:13:14.0000] <annevk>
kochi1: best to ping rniwa in the issue again

[03:16:18.0000] <annevk>
kochi1: btw, if you can nudge tyoshino to review https://github.com/whatwg/fetch/pull/298 that'd be appreciated

[04:22:40.0000] <hsivonen>
annevk: is the back and forth division and multiplication really the best way to encode a 4-byte gb18030 sequence?

[04:25:10.0000] <annevk>
hsivonen: I think it might depend on whether you care about memory or speed

[04:25:15.0000] <annevk>
hsivonen: but it's been a while

[04:25:52.0000] <annevk>
hsivonen: the algorithm in the specification optimizes for not storing a lot of data

[04:27:15.0000] <hsivonen>
annevk: do you mean it tries to minimize temporary values even if they'd fit in registers on a typical CPU?

[04:27:45.0000] <hsivonen>
(I care about speed as long as memory is "fits in registers")

[04:28:14.0000] <annevk>
hsivonen: I meant that you could have more comprehensive backing tables and less math

[04:28:46.0000] <annevk>
hsivonen: e.g., I don't think ICU's implementation uses the 127 entries trick

[04:29:07.0000] <hsivonen>
127 entries?

[04:29:43.0000] <annevk>
207 it seems, https://encoding.spec.whatwg.org/index-gb18030-ranges.txt

[04:30:17.0000] <hsivonen>
annevk: yeah, that part is fine

[04:30:55.0000] <hsivonen>
annevk: but when you have a ranges pointer, the way you go to 4 bytes looks on the surface like it'd benefit from the % operator

[04:31:03.0000] <hsivonen>
maybe

[04:31:15.0000] <hsivonen>
what I'm asking is if it really needs to be the way it's written

[04:31:39.0000] <annevk>
hsivonen: my bad, that could probably be done differently, yes

[04:32:06.0000] <annevk>
hsivonen: this is from the time when the specification didn't try to use those operators directly

[04:32:11.0000] <hsivonen>
if a pattern a = x / y; b = x % y; is hidden in there, it might be better to use that

[04:33:04.0000] <hsivonen>
ok. I guess I'll just make a note to revisit the math

[04:34:10.0000] <hsivonen>
By stated goals, I shouldn't care about the encoder speed for encoders other than UTF-8 anyway...

[04:36:29.0000] <annevk>
So yeah, http://source.icu-project.org/repos/icu/data/trunk/charset/data/xml/gb-18030-2000.xml has far less ranges, but that doesn't say much about the math of course

[05:02:29.0000] <hsivonen>
I have written code that assumes that gb18030 can encode all of unicode

[05:02:44.0000] <hsivonen>
that's wrong. there's one code point that it can't

[05:03:14.0000] <hsivonen>
looks like I will have to revisit the code where I made the assumption that gb18030 encodes all of Unicode

[05:03:31.0000] <Ms2ger>
Doh

[05:05:37.0000] <Cablegunmaster>
UTF8 does that right? :)

[05:05:58.0000] <jgraham>
Well, unless you are MySQL, yes

[05:06:16.0000] <jgraham>
But for hsivonen that's not really the point :)

[05:07:57.0000] <hsivonen>
Cablegunmaster: UTF-8 is the only encoding in the Encoding Standard whose output encoding can encode all of Unicode.

[05:09:33.0000] <annevk>
hsivonen: yeah, gb18030 was intended to be a UTF, but browsers messed that up

[05:09:39.0000] <hsivonen>
So next time you say that everyone should use Unicode in order to avoid data loss in form submission and a pedant says "What about gb18030?", you can answer "U+E5E5!!!!!"

[05:09:41.0000] <gsnedders>
what one code point can it not?

[05:09:52.0000] <hsivonen>
argh. s/Unicode/UTF-8/

[05:09:52.0000] <gsnedders>
oh, that

[05:15:55.0000] <Cablegunmaster>
hsivonen, I love utf8 =) only one im using for my websites.

[05:16:32.0000] <Cablegunmaster>
always wondered why should there still be other unicodes out there? :o

[05:46:55.0000] <annevk>
Cablegunmaster: no good reason, but at some point the thought was that UTF-16 was going to be it

[05:47:13.0000] <annevk>
Cablegunmaster: not sure why they bothered with UTF-32 though

[05:47:48.0000] <annevk>
Cablegunmaster: anyway, UTF-8 is the only one with good ecosystem support so best to stick with that

[05:58:26.0000] <Cablegunmaster>
that be true as well annevk thanks for the clear answer :)!

[06:02:20.0000] <nox>
annevk: What's wrong with UTF-32?

[06:02:49.0000] <annevk>
nox: doesn't solve an actual problem?

[06:02:52.0000] <nox>
Cablegunmaster: Unicode is least worst encoding we have currently, but it's clearly Latin-centric and kinda bad for CJK.

[06:03:05.0000] <annevk>
Unicode is not an encoding...

[06:03:42.0000] <nox>
annevk: True, s/encoding/standard/

[06:04:36.0000] <nox>
annevk: A friend of mine that lives in China explained to me that for texts with a lot of person names and old ideograms, it gets quite slow to decode UTF-8 and UTF-32 isn't much bigger in memory.

[06:05:32.0000] <annevk>
nox: slow to this day? Seems spurious

[06:05:58.0000] <annevk>
nox: that'd mean emoji slow down stuff too

[06:06:06.0000] <nox>
annevk: It was 3 years ago or so.

[06:06:20.0000] <nox>
annevk: Well they don't make things faster for sure, but yeah, didn't experience that myself.

[06:06:47.0000] <nox>
annevk: Wonder if http://emojitracker.com had to do anything fancy for decoding.

[06:06:52.0000] <annevk>
I can see how Han Unification is bad, but I don't think using four bytes for a code point is really that bad

[06:08:10.0000] <annevk>
nox: it doesn't seem to list emoji that use more than one code point

[06:08:22.0000] <nox>
annevk: That's a thing? ( ._.)

[06:08:27.0000] <nox>
/me cries.

[06:08:48.0000] <annevk>
nox: sure, e.g., all flags use two (and there's proposal for flags that use more)

[06:08:49.0000] <nox>
annevk: Oh, the ones with variant modifiers?

[06:09:02.0000] <annevk>
nox: you can compose families out of half a dozen code points, etc.

[06:09:05.0000] <nox>
Oh right I remember the flag drama.

[06:09:22.0000] <annevk>
I don't think it's a drama? It's a pretty neat design

[06:11:00.0000] <nox>
annevk: I remember that before this neat design,

[06:11:14.0000] <nox>
Taiwan wanted a code point for its flag, and China wasn't amused, or something like that.

[06:35:54.0000] <stennowork>
taiwan isn't really recognized by many countries

[07:38:39.0000] <TabAtkins>
UTF-8 is incredibly fast for something that clever. Slower than UTF-32 of course, because that's no decoding at all.

[07:39:29.0000] <TabAtkins>
But unless the page is *incredibly* text-heavy, UTF-8 gives significant space-savings even over 2-byte chinese-specialized encodings, let alone UTF-32.

[07:43:47.0000] <Ms2ger>
TabAtkins, and UTF-32 gives more memory traffic

[07:49:12.0000] <annevk>
I'd love to see some benchmarks

[07:49:50.0000] <annevk>
Ms2ger: and more IO-traffic too

[07:58:43.0000] <nox>
annevk: "emojitracker does support multiple code point emoji, just hasn't been updated for new emoji added in Unicode 8.0+"

[07:59:15.0000] <annevk>
nox: I didn't spot any flags, and those have been there since 6

[07:59:26.0000] <annevk>
nox: didn't look carefully though

[08:00:03.0000] <annevk>
nox: never mind, spotted a flag just now

[08:00:14.0000] <nox>
:)

[09:37:39.0000] <Jackson_>
Hi, I had a question about `<script type="module">`. I've looked through the spec and saw this question: https://github.com/whatwg/html/pull/443#issuecomment-167904832 but wanted confirmation on something: If I have a `<script type="module" src="a.js">`, where "a.js" will `export` a module, and I also have `<script type="module" src="b.js">`, and "b.js" will `import "./a";`, will the same instance of the module created by the former

[09:37:39.0000] <Jackson_>
`<script type="module" src="a.js">` be used?

[09:38:44.0000] <annevk>
Jackson_: if they're in the same document, yes

[09:40:05.0000] <Jackson_>
annevk: Thanks. Do you know where that is stated in the spec?

[09:40:33.0000] <annevk>
Jackson_: it's part of the "module map" semantics

[09:41:41.0000] <annevk>
Jackson_: https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script makes this quite explicit

[09:42:03.0000] <annevk>
Jackson_: I forgot if there's also an easier summary of this or an example of some sort

[09:43:15.0000] <annevk>
Jackson_: seems like the script element section could use an example that illustrates this... willing to contribute one?

[09:49:35.0000] <Jackson_>
annevk: Yeah, I can contribute one. To clarify further (this is what prompted me to ask this): In https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script, step 18, where "Fetch a module script tree" receives "settings": That is where a per-Document module map is provided to each `<script type="module">`, correct? https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-module-script-tree says the module map is

[09:49:35.0000] <Jackson_>
"optional," so I did know precisely where the module map came from.

[09:50:03.0000] <Jackson_>
* I did not know...

[09:50:56.0000] <annevk>
Jackson_: if "module map settings object" is not given, it uses the "fetch client settings object"

[09:51:07.0000] <annevk>
Jackson_: the settings object holds a reference to the actual "module map"

[09:51:43.0000] <annevk>
Jackson_: this setup is also used by workers, which is why the algorithms are rather abstract

[09:55:02.0000] <Jackson_>
annevk: So, the reason the modules are shared, is because the "fetch client settings object" is per-Document? (I did not see where the "fetch client settings object" was defined.)

[10:42:51.0000] <Domenic>
Jackson_: that will fail since "/.a" is a 404

[10:43:13.0000] <Domenic>
Jackson_: but if you correct it to "./a.js" it will indeed use the memoized module map

[10:43:47.0000] <Domenic>
Jackson_: "fetch client settings object" is an argument to the algorithm, and passed in by all the call sites. It is per-Window.

[10:47:26.0000] <Jackson_>
Domenic: Thanks for these clarifications.

[13:08:10.0000] <jyasskin>
If folks are interested in the future web stuff Google's excited about, https://events.google.com/io2016/ has cwilso and fbeaufort live.

[14:18:36.0000] <wanderview>
Mek: thanks for filing the BroadcastChannel bug!

[14:18:54.0000] <wanderview>
bugs

[14:37:55.0000] <tantek>
LOL: https://twitter.com/shinypb/status/733302396995010561

[14:38:12.0000] <tantek>
"When developers turn their problems into users' problems: AMP, following in XHTML's proud footsteps." cc: gsnedders

[14:38:17.0000] <tantek>
(see photo)


2016-05-20
[00:17:43.0000] <kochi1>
annevk: I pinged tyoshino@, maybe not have responded to the PR he should be looking.

[00:18:18.0000] <annevk>
thank you

[01:03:31.0000] <annevk>
jgraham: I got the "Subproject commit" stuff again on web-platform-tests

[01:04:07.0000] <Ms2ger>
git submodule update --init --recursive

[01:06:17.0000] <annevk>
"Unable to checkout '5a87b02cb86efecc541389704bbc7c555083e65f' in submodule path 'resources'"

[01:07:56.0000] <annevk>
Okay figured it out

[01:08:09.0000] <annevk>
This submodule mess...

[01:10:03.0000] <annevk>
User error, of course

[01:11:25.0000] <Ms2ger>
In the sense that cutting yourself with a knife that doesn't have a handle is user error :)

[01:14:06.0000] <annevk>
https://twitter.com/srl295/status/733315362687614976 is a little worrying

[01:15:43.0000] <annevk>
Has someone written the post yet as to why we need competition? It must be documented somewhere...

[01:38:19.0000] <annevk>
Whoa, due to the extension browserstack.com can even access local URLs, that's pretty nifty

[01:40:47.0000] <annevk>
Ms2ger: so I'm trying to figure out https://github.com/whatwg/html/issues/1130 for bz and I'm wondering about a good web-platform-tests strategy

[01:41:16.0000] <annevk>
Ms2ger: would it be okay to just create a branch + PR and commit my WIP there and then clean it up into actual tests at the end?

[01:42:27.0000] <annevk>
Ms2ger: main problem is that I don't know exactly what we want to require yet so at this point it's mostly just figuring things out across browsers and wanting to share those demos

[01:51:19.0000] <Ms2ger>
annevk, yeah, sure

[02:27:23.0000] <annevk>
Navigation is such a mess

[02:36:56.0000] <Ms2ger>
No kidding

[04:09:10.0000] <annevk>
https://www.schneier.com/blog/archives/2010/12/software_monocu.html and https://cryptome.org/cyberinsecurity.htm are I guess the pieces on software monocultures

[04:11:30.0000] <annevk>
Nothing really from a standards perspective though

[04:46:49.0000] <annevk>
Ms2ger: navigation follows the web platform theme of "the more you learn the less you know"

[04:58:05.0000] <zcorpan>
https://github.com/whatwg/html/commit/7ff5b096d423bf5750463957aed69680368ed99e is there any data about how much prefetching <link rel=next> helps (or doesn't help)?

[05:25:52.0000] <zcorpan>
should origins also be USVString ?

[05:26:20.0000] <annevk>
zcorpan: yeah

[07:35:24.0000] <smaug____>
can an origin contain &

[07:38:22.0000] <wanderview>
smaug____: the domain cannot per spec rfc1034... not sure about other parts of origin

[07:38:57.0000] <wanderview>
I guess that includes host names then

[07:39:10.0000] <wanderview>
page 11 of https://tools.ietf.org/html/rfc1034

[07:39:36.0000] <wanderview>
smaug____: so I guess it depends if the impl allows schemes with & in them...  I hope they don't

[07:39:40.0000] <annevk>
pretty sure browsers are closer to https://url.spec.whatwg.org/#host-parsing which does allow it on a first read

[07:40:22.0000] <wanderview>
annevk: I got to the rfc from the url spec here: https://url.spec.whatwg.org/#hosts-%28domains-and-ip-addresses%29

[07:40:45.0000] <annevk>
wanderview: w(new URL("https://test&test").origin) logs https://test&test

[07:41:21.0000] <smaug____>
aha, thanks

[07:41:22.0000] <annevk>
wanderview: that's not meant as a normative syntax reference

[07:41:39.0000] <annevk>
wanderview: more of a concept reference

[07:41:44.0000] <annevk>
hmm

[07:41:49.0000] <wanderview>
doesn't say its non-normative

[07:41:51.0000] <wanderview>
but ok

[07:42:35.0000] <annevk>
wanderview: file a bug? seems worth addressing

[07:44:08.0000] <wanderview>
annevk: https://github.com/whatwg/url/issues/122

[07:44:57.0000] <annevk>
ta

[08:32:43.0000] <jgraham>
annevk: For future reference it seems fine to push a branch to wpt without making a PR if you just want to experiment for a while

[08:39:51.0000] <Ms2ger>
That doesn't upload to w3c-test though

[08:40:50.0000] <jgraham>
Oh, right, is that the point

[08:41:26.0000] <jgraham>
Would be nice to have some other way of achieving that without a PR that is not ready and getting lots of updates

[09:24:07.0000] <annevk>
jgraham: also want to share and let others push tests in theory

[09:24:41.0000] <jgraham>
annevk: You can make a branch in the wpt repo rather than your local fork without making a PR

[09:26:14.0000] <annevk>
jgraham: I know

[09:26:36.0000] <annevk>
jgraham: PR makes for much easier sharing though, no?

[09:33:13.0000] <jgraham>
I guess?

[09:34:35.0000] <annevk>
jgraham: happy to consider other workflows, you won't get much spam from me either way

[13:32:56.0000] <TabAtkins>
annevk: Submodules aren't user error. They're a deep, obvious design error that should be put to the torch asap.

[14:16:01.0000] <jgraham>
Describing submodules as an "obvious design error" seems uncharitable in the extreme. In practice they are not much fun, but the idea sounds perfectly reasonable and indeed is much like many other dependency management systems.

[14:28:12.0000] <tantek>
hearing Google I/O speakers trash IndexedDB API pretty consistently. What's the replacement?

[14:28:35.0000] <tantek>
and the legacy is pretty bad. Storage API, WebSQL, IndexedDB API

[14:29:01.0000] <tantek>
is it just that standards folks suck at storage API design? How many different attempts are necessary before we get one that doesn't suck?

[14:29:29.0000] <gsnedders>
IMO, the problem is everyone just wants an SQL database in practice, but nobody wants to spec it.

[14:29:34.0000] <tantek>
(e.g. Malte trashed IndexedDB in his AMP talk. Jake Archibald trashed it yesterday in his offlinefirst talk)

[14:30:05.0000] <tantek>
gsnedders: everyone? certainly not Heroku where you can't SQL. You can Postgres however.

[14:30:28.0000] <tantek>
I'm fine with accepting "Storage APIs are hard, let's go hacking" but still

[14:30:30.0000] <gsnedders>
tantek: ? Postgres is just a SQL implementation?

[14:31:43.0000] <tantek>
ah sorry misread as MySQL since that's the common "everyone just wants"

[14:32:54.0000] <gsnedders>
I still hear a fair bit of sadness that WebSQL is practically dead

[14:33:14.0000] <gsnedders>
from web developers, that is

[14:33:34.0000] <gsnedders>
IndexedDB is bad simply because it's a model people aren't used to dealing with, AFAIK?

[14:36:38.0000] <Domenic>
The API also makes it hard to do simple things

[14:36:43.0000] <Domenic>
People mostly want an async version of local storage

[14:36:52.0000] <Domenic>
Using promises or simple callbacks

[14:36:54.0000] <Domenic>
Not IDBRequests

[14:37:24.0000] <tantek>
Domenic: that is a sensible explanation. So ... Storage 2.0?

[14:37:44.0000] <tantek>
(2.0 means you don't have to be compatible, we learned that from XHTML ;) )

[14:37:48.0000] <Domenic>
tantek: the problem is that very few people want to spend time on developing a new API that has no fundamentally new capabilities, and is simply a better API surface

[14:38:31.0000] <tantek>
yes, even standards people have limits of attention span / diminishing returns

[14:39:48.0000] <tantek>
so what's the current answer then? based on

[14:40:05.0000] <tantek>
"The [IndexedDB] API also makes it hard to do simple things" - I'm loathe to recommend it

[14:40:05.0000] <Domenic>
IDB + a library, basically

[14:40:24.0000] <tantek>
and rather suggest minimal use of Local Storage

[14:40:56.0000] <tantek>
Domenic, indeed, Jake suggested using IDB + framework wrapper around it

[14:41:02.0000] <tantek>
in his talk yesterday

[14:41:11.0000] <Domenic>
https://www.npmjs.com/package/localforage for simple cases, maybe https://www.npmjs.com/package/idb for more complicated ones

[14:41:39.0000] <tantek>
ok cool. thanks Domenic

[16:23:54.0000] <TabAtkins>
jgraham: The fact that submodules mean your repo is basically guaranteed to be broken on first clone is a fundamental design flaw. There's an additional non-obvious command you have to run to actually get the repository in a working state, and there's no indication you *need* to do so.

[16:25:25.0000] <TabAtkins>
Like, if after a clone git spit out a message like "hey there's some submodules here, you might want to run `...`to make this shit work"

[16:35:32.0000] <jyasskin>
TabAtkins: If it's just an extra string `git clone` should print, that's not a deep design error. ;)

[16:36:26.0000] <TabAtkins>
I mean "this extra command you absolutely have to run if you don't want things to be broken" is a big design flaw regardless of whether the first command tells you to run it or not.

[16:41:04.0000] <nox>
TabAtkins: Can't be that hard, it's Git after all!!1!


2016-05-21
[17:09:12.0000] <tantek>
TabAtkins: "There's an additional non-obvious command you have to run to actually get [something done]" is the general design philosophy of the Git CLI.

[00:47:18.0000] <jgraham>
TabAtkins: That's a flaw, sure, but it's kind of a dumb surface-level design flaw

[00:47:50.0000] <jgraham>
In theory git clone could be fixed to do the right thing

[09:24:46.0000] <kirillbykov2>
Hello! I'm new at HTML5/CSS3 and I have a question about CSS. Could someone explain me why the text color property's name is "color", but not "text-color"? It confuse me very much :(

[11:59:32.0000] <nox>
https://html.spec.whatwg.org/multipage/browsers.html#the-location-interface:reload-triggered-navigation Shouldn't that reference be the definition, instead of the one in the navigation algorithm?

[12:39:13.0000] <KiChjang>
i need some help understanding the content/IDL attributes of max, min and step on input elements

[12:39:40.0000] <KiChjang>
currently on FF and CR, they both treat them as simply strings

[12:40:26.0000] <KiChjang>
but then on the spec here

[12:40:29.0000] <KiChjang>
https://html.spec.whatwg.org/multipage/forms.html#attr-input-step

[12:40:48.0000] <KiChjang>
it contains the following paragraph

[12:40:49.0000] <KiChjang>
The step attribute, if specified, must either have a value that is a valid floating-point number that parses to a number that is greater than zero, or must have a value that is an ASCII case-insensitive match for the string "any".

[12:42:12.0000] <KiChjang>
does this indicate that user agents are supposed to parse them as floating-point numbers?

[12:43:27.0000] <KiChjang>
further complicating the matter, each input type also contains restrictions on what values that the max, min and step attributes can take

[12:43:45.0000] <KiChjang>
https://html.spec.whatwg.org/multipage/forms.html#date-state-%28type=date%29

[12:43:56.0000] <KiChjang>
"The step attribute is expressed in days. The step scale factor is 86,400,000 (which converts the days to milliseconds, as used in the other algorithms). The default step is 1 day."

[12:45:04.0000] <KiChjang>
and for max and min

[12:45:07.0000] <KiChjang>
"The min attribute, if specified, must have a value that is a valid date string. The max attribute, if specified, must have a value that is a valid date string.

[12:45:08.0000] <KiChjang>
"

[12:45:26.0000] <KiChjang>
"If the element has a min attribute, and the result of applying the algorithm to convert a string to a number to the value of the min attribute is a number, then that number is the element's minimum; otherwise, if the type attribute's current state defines a default minimum, then that is the minimum; otherwise, the element has no minimum."

[12:45:49.0000] <KiChjang>
https://html.spec.whatwg.org/multipage/forms.html#attr-input-min

[12:49:13.0000] <KiChjang>
so are the behaviours observed on FF and CR wrong?

[13:51:51.0000] <Domenic>
KiChjang: that is an authoring conformance requirement

[13:53:02.0000] <KiChjang>
Domenic, what does that mean?

[13:53:17.0000] <Domenic>
KiChjang: that internal "minimum" of an element is obtained by the "If the element has a min attribute, and the result...". That internal minimum value is used in other contexts.

[13:53:28.0000] <Domenic>
KiChjang: everything else you quoted is an authoring conformance requirement, for validators, not web browsers

[13:53:52.0000] <Domenic>
KiChjang: the HTML spec gives instructions on how authors write valid HTML, in addition to giving instructions on how browsers must use any HTML

[13:54:23.0000] <Domenic>
s/for validators/for validators and authors/

[13:54:27.0000] <KiChjang>
Domenic, ah, so there's this notion of an internal attribute as well

[13:54:36.0000] <KiChjang>
likewise, step should also have an internal representation?

[13:55:08.0000] <Domenic>
KiChjang: yes, it's https://html.spec.whatwg.org/multipage/forms.html#concept-input-step

[13:55:47.0000] <Domenic>
It looks like the "internal slots" for the element are "allowed value step" and "step base"

[13:56:19.0000] <Domenic>
those are derived by looking at the content attributes step, multiple, min, and value.

[13:56:25.0000] <Domenic>
per the algorithms in that section

[13:56:36.0000] <KiChjang>
i see, that clears up a lot of my confusion, thanks

[13:57:12.0000] <Domenic>
This is an ongoing problem with everyone getting confused by authoring requirements vs. processing model requirements :(

[14:03:18.0000] <KiChjang>
Domenic, well, one of the reasons is because i wasn't aware that there are internal representations for these values

[14:04:01.0000] <KiChjang>
on other places, the element would have something like "An element has an associated something value"

[14:04:28.0000] <Domenic>
That's true

[14:04:49.0000] <Domenic>
I guess the line is a bit blurry between "an element has an allowed value step" and "an element has an algorithm for getting an allowed value step"

[14:05:03.0000] <Domenic>
You could implement it either way

[14:05:10.0000] <Domenic>
Probably the latter makes more sense actually

[14:07:34.0000] <KiChjang>
Domenic, when i first read that, i interpreted as the latter one

[14:07:45.0000] <Domenic>
Yeah, I think that's how I would implement it

[14:08:26.0000] <KiChjang>
Domenic, also, does this mean that the behaviour in FF and CR are according to spec?

[14:08:41.0000] <Domenic>
KiChjang: I think it is, although I haven't tested in detail.

[14:08:42.0000] <KiChjang>
i.e. all min, max and step values do not need any input validation

[14:08:49.0000] <KiChjang>
and are stored as strings

[14:09:10.0000] <Domenic>
If you mean content vs. IDL attributes, yes, I believe the IDL attributes are defined to reflect the content attributes.

[14:10:35.0000] <KiChjang>
but why does the spec also mention that (e.g. for step) it "must have a value that is a valid floating-point number that is greater than zero, or must have a value that is an ASCII case-insensitive match for the string 'any'"?

[14:11:05.0000] <KiChjang>
it also doesn't list any consequences when the attribute violates this rule

[14:11:11.0000] <KiChjang>
so is that just there for show?

[14:11:34.0000] <KiChjang>
i.e. the strings for step doesn't and isn't validated at all?

[14:13:25.0000] <Domenic>
Those are requirements on authors

[14:13:31.0000] <Domenic>
The spec has multiple audiences

[14:13:47.0000] <Domenic>
Validators will complain if you write `<input step="asdf">`

[14:13:51.0000] <Domenic>
that is the part of the spec that tells them to do so

[14:14:01.0000] <Domenic>
the consequences are that your document will not be conformant

[14:14:27.0000] <Domenic>
https://html.spec.whatwg.org/multipage/introduction.html#restrictions-on-content-models-and-on-attribute-values

[14:16:05.0000] <KiChjang>
Domenic, ah, it took a while for me to get it, it's like a note for spec authors

[14:16:22.0000] <KiChjang>
should that not be in a notes section then?

[14:16:35.0000] <Domenic>
no, it's a normative requirement to those wanting to write valid HTML documents

[14:17:24.0000] <Domenic>
developers.whatwg.org (back in the day when it was updated) was basically a version of the spec with all the "for-implementers" stuff removed... I feel like we need a "implementers.whatwg.org" with all the for-developers stuff removed.

[14:17:34.0000] <Domenic>
(developers = authors, BTW)

[14:18:23.0000] <KiChjang>
Domenic, i see, so basically there are groups of people who are just wondering what the constraints are when using HTML, and there are those who are implementing HTML stuff on the browser itself (that's me)

[14:18:36.0000] <Domenic>
yeah, the spec has normative requirements on both

[14:19:06.0000] <Domenic>
but basically anything that's a restriction on a content model (what an element can contain) or an attribute value is for authors

[14:19:30.0000] <Domenic>
more at https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors ... restrictions on not using certain tags (presentational markup) or not writing invalid HTML (like <table><hr>...)

[14:25:11.0000] <KiChjang>
Domenic, maybe the wording could be a little bit more obvious as to which audience a particular snippet of the spec is intended for

[14:25:47.0000] <KiChjang>
i'm sure there had been discussion about this before though

[14:44:59.0000] <Domenic>
Yeah, it's just such a massive, widespread issue. Nobody's had the time or fortitude to tackle it.


2016-05-22
[12:30:15.0000] <smaug____>
/me wonders what has happened to structured cloning stuff

[12:30:26.0000] <smaug____>
way harder to read than the old version of the spec

[12:33:44.0000] <smaug____>
these days it is totally unclear what should happen when getters throw exceptions

[13:35:39.0000] <gsnedders>
SimonSapin: do you me to just fork python-webencodings or do you want to transfer ownership of the repo? (or add me as an owner; w/e)

[13:36:38.0000] <SimonSapin>
gsnedders: please fork it, I’m thinking of marking a bunch of my repos as unmaintained at some point

[13:37:51.0000] <gsnedders>
SimonSapin: kk. just abandons the single issue there (from me, which is hardly a big deal :))

[13:37:54.0000] <SimonSapin>
gsnedders: I’ve given you PyPI access

[13:37:58.0000] <gsnedders>
SimonSapin: thx!

[15:45:41.0000] <gsnedders>
When do we expect any parser to *not* prescan the byte stream to determine its encoding?

[15:46:21.0000] <gsnedders>
Given per the spec that prescan is "optional"

[15:46:54.0000] <gsnedders>
(This is relatively theoretical, given in practice even with it mandatory the length scanned is unpsecified, and can be zero, for example on a slow network)

[15:47:10.0000] <gsnedders>
(But it's not entirely: should html5lib have an option to turn it off?)


2016-05-23
[22:25:42.0000] <Manishearth>
anyone around?

[22:32:16.0000] <Manishearth>
Hixie_: in https://html.spec.whatwg.org/multipage/forms.html#constructing-form-data-set , are empty names ok?

[22:32:57.0000] <Manishearth>
it seems like most browsers ignore elements with empty names, but the spec seems to allow <input type=text> and <button type=submit> to have empty names

[22:34:58.0000] <Manishearth>
I don't see where that gets filtered out

[02:14:38.0000] <nox>
Manishearth: "The field element is not an input element whose type attribute is in the Image Button state, and either the field element does not have a name attribute specified, or its name attribute's value is the empty string."

[02:14:54.0000] <nox>
Manishearth: Step 3.1., bullet 6.

[02:16:51.0000] <Manishearth>
nox: ... I'm blind

[02:16:59.0000] <nox>
Manishearth: No, you are reading HTML.

[02:17:03.0000] <Manishearth>
:)

[04:22:39.0000] <Ms2ger>
Someone remind me: can two same-origin tabs communicate synchronously?

[04:25:49.0000] <ondras>
as long as they have references to each other

[04:26:05.0000] <ondras>
as in, var w = window.open("...sameorigin", "_blank")

[04:26:07.0000] <ondras>
w.doStuff()

[04:46:30.0000] <annevk>
Oh cool, Chrome and Safari differ in what gets to be the referrer global

[04:46:46.0000] <Domenic>
not even a little surprised

[04:54:08.0000] <annevk>
Chrome and Safari differing is somewhat unusual, but maybe not when it comes to the network stack. Although it still seems weird they'd pass different parameters down

[04:54:34.0000] <annevk>
Firefox and Safari are on the same line and for some reason Edge always has document.referrer as the empty string so is hard to debug...

[05:02:31.0000] <annevk>
Hmm

[05:02:58.0000] <annevk>
Domenic: a navigated <iframe> is not going to really affect things for https://github.com/whatwg/html/issues/1130#issuecomment-220671949 is it?

[05:03:13.0000] <annevk>
Domenic: because whatever pointer I have to the Window is really a pointer to the WindowProxy which remains the same

[05:03:34.0000] <Domenic>
annevk: uhhh hard for me to really grapple with multi-global questions in the middle of TC39 while jetlagged ;P

[05:04:08.0000] <annevk>
Domenic: hehe, I'll pester bz when he wakes up then

[05:28:55.0000] <Domenic>
annevk: how do you make wattsi spit out the dev version?

[05:28:59.0000] <Ms2ger>
ondras, okay, insert "independently opened by the user" :)

[05:29:14.0000] <annevk>
Domenic: I thought that happened automatically

[05:29:26.0000] <Domenic>
oh maybe... i'll go check the output directory

[05:30:52.0000] <Domenic>
hmm i don't see it

[05:30:57.0000] <Domenic>
at least when using build.sh

[05:32:28.0000] <Domenic>
i bet it's in the temp directory

[05:32:56.0000] <annevk>
Domenic: yeah, we might not copy it at the moment

[05:33:14.0000] <Domenic>
yeah found it

[05:55:17.0000] <ondras>
Ms2ger: okay, I am not aware of any way then :)

[08:16:14.0000] <annevk>
Domenic: is anyone from Apple attending the meeting?

[08:16:21.0000] <Domenic>
annevk: yep

[08:16:41.0000] <annevk>
Domenic: it might be interesting to ask them about their global setup and incumbent/current/relevant and such

[08:16:50.0000] <Domenic>
hmmm

[08:17:16.0000] <annevk>
Domenic: basically in my tests it seems like sometimes Apple uses entry and sometimes incumbent, for something where there's really only one answer possible

[08:17:20.0000] <Domenic>
yeah worth checking, although js engine devs and web platform don't always cross over

[08:17:24.0000] <annevk>
Domenic: so it seems like they have at least one concept less

[08:17:31.0000] <annevk>
Domenic: true

[08:17:33.0000] <Domenic>
annevk: you realize we want to get rid of both and use "current" mostly? :)

[08:17:57.0000] <annevk>
Domenic: I'm looking at navigations (through location / window.open)

[08:18:12.0000] <annevk>
Domenic: so while there's some wiggle room, I doubt there's that much

[08:18:17.0000] <Domenic>
mmm yeah

[08:26:23.0000] <annevk>
It was kinda nice once I understood the specification you just wrote, but it turns out not everyone implements it (or has super weird logic elsewhere)

[08:26:53.0000] <annevk>
😟

[10:10:09.0000] <TabAtkins>
gsnedders: A streaming parser won't pre-scan the byte stream. (Or I guess will scan it with a length of 0, if you want to push this into trivialities.)

[10:26:05.0000] <jyasskin>
annevk: In case it helps, I believe Blink's current/entry/incumbent logic is https://code.google.com/p/chromium/codesearch/#chromium/src/third_party/WebKit/Source/bindings/core/v8/V8Binding.cpp&l=672-704.

[10:26:24.0000] <jyasskin>
Only incumbent is used significantly outside of location.

[10:29:30.0000] <annevk>
jyasskin: thanks, it might help, though for what I'm looking at it seems like Blink is an outlier

[12:33:40.0000] <gsnedders>
TabAtkins: duh. ofc, the streaming case.

[13:48:21.0000] <gsnedders>
Probably missing something obvious, but: why can't CSS `background` apply to SVG elements?

[13:50:40.0000] <tantek>
gsnedders: perhaps it's just not defined how it applies?

[13:50:55.0000] <tantek>
and SVG already has 'fill'

[13:56:12.0000] <gsnedders>
tantek: tl;dr: I want to apply a background a dynamically generated text element. fill there alters the colour of the text, not its background.

[13:57:31.0000] <tantek>
gsnedders: I think you have to apply the fill to the parent of the text

[14:00:11.0000] <gsnedders>
tantek: right, which means dynamically hacking around with the tree after the library generated it, which is extra complexity I was hoping to avoid


2016-05-24
[23:54:27.0000] <MikeSmith>
has there been any statement of agreement about deprecating HTML Imports?

[23:54:58.0000] <annevk>
Dunno, I get the impression W3C wants to keep it alive and Google maybe does too?

[23:56:59.0000] <MikeSmith>
do JS module scripts not solve all the problems that HTML Imports was intended for?

[23:57:09.0000] <ondras>
imports are being considered to get deprecated?

[23:57:12.0000] <ondras>
interesting

[23:57:39.0000] <ondras>
MikeSmith: I would say that the goal of having a modularized HTML cannot be solved by module scripts

[23:57:42.0000] <MikeSmith>
ondras: well, just not being prioritized for implementation

[23:57:45.0000] <ondras>
okay

[23:58:28.0000] <ondras>
module scripts can *create* modularized DOM, but as far as the modularized (static) HTML goes, there is no other tech than imports...

[23:59:13.0000] <MikeSmith>
sure

[00:00:02.0000] <MikeSmith>
just not clear that the modularized HTML case is one that browser projects are very keen on supporting

[00:00:07.0000] <MikeSmith>
other than Google

[00:00:26.0000] <annevk>
ondras: the static HTML doesn't go anywhere without script though, so the name is quite deceptive

[00:01:38.0000] <ondras>
annevk: well the script is just a glue; its size can be orders of magnitude smaller than the acutal HTML content

[00:01:56.0000] <ondras>
annevk: also, the JS might be present only in the importing document (=> not inside the import itself) IIRC, right?

[00:02:28.0000] <annevk>
the JS can come from anywhere, sure

[00:02:37.0000] <annevk>
Not sure that makes it better

[00:15:25.0000] <kochi>
MikeSmith: IIRC the agreement about HTML Imports at last year TPAC, was to keep it

[00:16:27.0000] <annevk>
kochi: but only Google wants to implement it? Who were involved in that decision?

[00:17:54.0000] <kochi>
IIRC Travis said no alternative proposed for loading HTML module, which was the reason.

[00:18:11.0000] <Ms2ger>
That's not the best argument I ever heard

[00:18:13.0000] <kochi>
I know Mozilla doesn't have interest in implementing in the current form

[00:19:29.0000] <annevk>
Ms2ger: no kidding

[00:19:35.0000] <MikeSmith>
not sure Apple does either

[00:19:45.0000] <annevk>
Pretty sure they don't

[00:19:47.0000] <kochi>
let me dig the minutes

[00:19:53.0000] <MikeSmith>
kochi: thanks

[00:20:14.0000] <kochi>
yeah, Apple proposed to remove HTML Imports from the charter, then, IIRC

[00:23:44.0000] <annevk>
$%#@%$@#

[00:24:02.0000] <annevk>
Safari differs between location.href and location.assign() what global it picks the referrer from

[00:24:34.0000] <annevk>
Wut wut wut

[00:28:49.0000] <kochi>
hmm... cannot find the minutes (still trying)

[00:32:41.0000] <kochi>
Found!: https://www.w3.org/2015/10/26-webapps-minutes.html

[00:32:55.0000] <MikeSmith>
/me looks at https://www.w3.org/2015/10/26-webapps-minutes.html

[00:33:20.0000] <kochi>
Search for "There are three specs, let's go over their status." in the minutes (from rniwa)

[00:34:59.0000] <MikeSmith>
yup jus read it

[00:35:27.0000] <MikeSmith>
so Microsoft was not opposed, and even actually supportive

[00:36:21.0000] <kochi>
yeah, my memory about Microsoft was somewhat wrong, but they supported to keep it

[00:36:29.0000] <MikeSmith>
and rniwa was not strongly opposed to doing it in the future at some point, after ES modules gets deployed and we have some experience with it

[00:37:26.0000] <annevk>
So there's two things there

[00:37:48.0000] <annevk>
There's support to keep it in the charter and there's support to let Google play with the specification

[00:37:54.0000] <MikeSmith>
yes

[00:37:57.0000] <annevk>
There doesn't seem to be support for the feature as-is

[00:38:19.0000] <MikeSmith>
I guess that’s a fair characterization

[00:38:55.0000] <annevk>
I think dglazkov did come up with a new proposal of sorts, but it wasn't quite flushed out yet

[00:39:05.0000] <annevk>
But I suspect he's also waiting for <script type=module> to land

[00:40:36.0000] <kochi>
probably we have to reiterate on imports on top of ES modules.

[00:41:27.0000] <kochi>
we = google

[00:51:29.0000] <kochi>
btw, I don't really understand the difference whether we keep HTML Imports in W3C charter and turning it into a "note"

[00:52:01.0000] <kochi>
I know the IME API spec turned into a note, though

[00:52:28.0000] <annevk>
kochi: keeping it in the charter means it's something the group can work on

[00:52:42.0000] <Ms2ger>
/me grumbles about charters

[00:53:04.0000] <annevk>
kochi: turning something into a Note is basically a nice gesture towards the community to indicate the work is no longer relevant

[00:53:05.0000] <kochi>
so "note" is just a historical record, no one is actively working on, then?

[00:53:19.0000] <kochi>
crossed the message, yeah,

[00:54:53.0000] <kochi>
so the status of HTML Imports is, that "people recognizes the importance of the feature, though no one except Google has interest in implementing it in the current form"

[00:55:15.0000] <annevk>
kochi: yeah, that seems accurate

[00:59:35.0000] <annevk>
jgraham: finding web-platform test documentation on Google is rather hard

[00:59:45.0000] <annevk>
e.g., "async web-platform test" doesn't give much

[00:59:59.0000] <kochi>
Google just implemented HTML imports in the past, so may not have interested in implementing it, though ;)

[01:00:35.0000] <annevk>
/me finds http://testthewebforward.org/docs/testharness-library.html

[01:00:40.0000] <kochi>
I always end up reading testharness.js doc again

[01:01:09.0000] <kochi>
https://github.com/w3c/testharness.js/blob/master/docs/api.md this is

[01:01:15.0000] <annevk>
I need to write tests every two months or so

[01:01:19.0000] <annevk>
It's not frequent enough

[01:12:01.0000] <annevk>
https://twitter.com/avaragado/status/735014283692630016 is a rather interesting analogy

[01:12:29.0000] <annevk>
But I'm not really qualified to judge its accuracy

[01:35:20.0000] <annevk>
jgraham: you around? Is there a pattern for <iframe onload=somefunc>?

[01:37:20.0000] <annevk>
jgraham: I want to pass an argument

[01:38:40.0000] <annevk>
I guess I can just rewrite how I get hold of the iframe instead

[01:52:20.0000] <jgraham>
annevk: there's not really an iframe onload pattern

[01:52:40.0000] <jgraham>
idk how to make Google love the documentation more

[01:57:00.0000] <gsnedders>
jgraham: I think it's the fact it's all under the heading of TTWF and not wpt that makes it hard

[01:57:28.0000] <jgraham>
I guess we could change that

[01:57:40.0000] <annevk>
Setup webplatformtests.org?

[01:57:47.0000] <annevk>
Maybe get it on HTTPS from the start

[01:57:57.0000] <jgraham>
Test the Web Forward as a larger movement doesn't seem to exist so much any more

[01:58:34.0000] <annevk>
Happy to provide server resources and such

[02:15:16.0000] <MikeSmith>
yeah I think Test the Web Forward as a brand has its day in the sun and we should consider moving on

[02:16:07.0000] <MikeSmith>
jgraham: http://testthewebforward.org/ is just set up through some C record to a github gh-pages repo?

[02:17:58.0000] <MikeSmith>
I would also be happy to have an alternative for https://w3c-test.org/ that was collabortively maintained, so that I don’t have to be the main person to have to fix it when there are problems

[02:36:36.0000] <jgraham>
MikeSmith: I think w3c-test.org at least needs to be a VPS.

[02:37:08.0000] <jgraham>
But I think setting up webplatformtests.org makes some sense

[02:41:52.0000] <MikeSmith>
jgraham: yeah w3c-test.org needs to continue to be a VPS but we could get it hosted as such somewhere else

[02:42:05.0000] <MikeSmith>
IMHO everything needs to be a VPS

[02:46:18.0000] <jgraham>
MikeSmith: I'm totally happy to set it up on linode or whereever

[03:18:08.0000] <MikeSmith>
let’s, when you have time

[03:18:24.0000] <MikeSmith>
it can be set up in parallel to w3c-test.org

[03:19:38.0000] <MikeSmith>
and if it goes well and people use it, then I can just quietly retire from being in the admin business for w3c-test.org and whoever else from w3c cares more can take responsibility instead

[03:19:59.0000] <MikeSmith>
annevk: any clues on http://stackoverflow.com/questions/37409714/does-cors-work-in-ie-11-using-ssl-xmlhttprequest

[03:23:36.0000] <gsnedders>
MikeSmith, jgraham: I promised something like w3c-test's mirroring for PRs for csswg-test, fwiw

[03:23:55.0000] <annevk>
MikeSmith: per http://stackoverflow.com/questions/20198696/cors-request-with-ie11 IE might require P3P?!

[03:24:56.0000] <MikeSmith>
annevk: that would be odd

[03:25:21.0000] <jgraham>
gsnedders: Well they know how to get it for free :)

[03:27:27.0000] <gsnedders>
unrelated to that: I'm close to just rewriting the CSS test harness as something more sane

[03:27:37.0000] <gsnedders>
given, well, you looked at that code.

[03:29:55.0000] <gsnedders>
probably as something that works sanely on top of other things as well (read: wpt)

[03:31:16.0000] <jgraham>
I now seem to own webplatformtests.org

[03:31:50.0000] <jgraham>
Not the ideal domain (with or without an s? with or without hyphens), but something

[03:32:20.0000] <jgraham>
I wonder how to dupe someone into doing some design work for content to live there

[03:35:18.0000] <gsnedders>
no .test? :(

[03:35:29.0000] <gsnedders>
seemingly not

[03:38:03.0000] <jgraham>
.test is reserved I think

[03:38:49.0000] <gsnedders>
it seems to simply not exist

[03:38:58.0000] <gsnedders>
I could be missing it here, though, if it is reserved

[03:39:10.0000] <gsnedders>
.dev is owned by Google

[03:39:47.0000] <jgraham>
https://tools.ietf.org/html/rfc2606#section-2

[03:39:56.0000] <jgraham>
idk if that still applies

[03:41:16.0000] <jgraham>
https://tools.ietf.org/html/rfc6761 updates it but still reserves .test

[03:41:48.0000] <gsnedders>
oh ok

[03:44:08.0000] <annevk>
mathiasbynens: 🎂🎉

[03:56:05.0000] <gsnedders>
https://bugs.chromium.org/p/chromium/issues/detail?id=614171#c2 — I can't believe I'm having to argue that's a problem.

[03:56:08.0000] <mathiasbynens>
annevk: cheers :)

[03:57:47.0000] <jgraham>
gsnedders: Probably that person hasn't used SVG and doesn't realise that the tag names are case sensitive

[04:31:31.0000] <nox>
/me is impressed by <details>.

[04:35:03.0000] <annevk>
jgraham: should testharness.js maybe support some kind of public logging? So those looking at why a test fails have some helpful pointers?

[04:38:56.0000] <gsnedders>
annevk: public logging of what?

[04:42:20.0000] <annevk>
gsnedders: some of the state in scripts

[04:42:26.0000] <annevk>
gsnedders: prolly not too useful though

[04:45:13.0000] <gsnedders>
annevk: how do you know what to dump? I don't see how we can realisitically improve on what's done now?

[04:46:15.0000] <annevk>
gsnedders: never mind

[04:46:38.0000] <gsnedders>
annevk: you're sounding like me, shouting out crazy ideas :)

[05:15:20.0000] <zcorpan>
jgraham: how about wpt.me

[05:33:23.0000] <Ms2ger>
w.pt

[05:46:09.0000] <zcorpan>
test.platform.web

[05:54:50.0000] <zcorpan>
normalize.css is something that shouldn't need to exist

[06:51:52.0000] <nox>
web.technology

[06:52:09.0000] <nox>
/me wonders if there is a longer TLD.

[06:58:15.0000] <MikeSmith>
botie, inform tantek you might want to take a look at https://github.com/w3c/html/issues/160

[06:58:15.0000] <botie>
will do

[07:12:39.0000] <wanderview>
Domenic: remember when I asked you a week or so ago about the ReadableStream slot name brand check?  apparently the spider monkey intrinsic thing is safe and can't be spoofed...  we use an internal class pointer that can't be changed

[07:13:13.0000] <Domenic>
wanderview: yeah i assumed SpiderMonkey would have some intrinsic thing that works... just didn't know what it was.

[07:13:43.0000] <wanderview>
I was confused because the thing that is compared can change... but there is code in place to ensure the class bit remains the same

[07:19:03.0000] <MikeSmith>
for anybody how has time to peruse it, I think https://github.com/w3c/dpub-pwp-ucr/issues/22 does a good job (somewhat unintentionally) of summarizing why the EPUB-inspired “Portable Web Publications” format that some at the W3C are trying to cook up is an accident waiting to happen

[07:21:09.0000] <MikeSmith>
(the “Portable Web Publications” format is a zip package with HTML content that can contain JavaScript, except that it runs not on the Web but instead in an off-Web “reading system” built on a browser engine

[07:23:31.0000] <MikeSmith>
comments at https://github.com/w3c/dpub-pwp-ucr/issues/21 are also worth reading

[07:24:38.0000] <annevk>
Sounds like "widgets" and whatever other names that had

[07:24:44.0000] <annevk>
Also FxOS apps

[07:24:47.0000] <annevk>
And Chrome apps

[07:25:06.0000] <annevk>
None of which are really needed

[07:25:18.0000] <MikeSmith>
yeah

[07:25:40.0000] <MikeSmith>
which I why I think actually it’s never going to go anywhere

[07:26:23.0000] <MikeSmith>
in large part because they’re never going to get browser projects to implement whatever it is they think they need

[07:27:28.0000] <rodneyre_>
is there a separate channel for issues with CSS spec, or is this the place to ask?

[07:27:52.0000] <MikeSmith>
rodneyrehm: you can ask here

[07:28:06.0000] <MikeSmith>
especially when TabAtkins is around

[07:28:13.0000] <MikeSmith>
which he probably is not yet

[07:29:00.0000] <gsnedders>
rodneyrehm: there's #css on irc.w3.org, which probably has a few more CSS people in it, but here is in general okay

[07:29:12.0000] <rodneyrehm>
I'm confused about CSS Transitions and the visibility property. Should these two behave the same in regard to immediate (synchronous) change to "visible"? http://jsbin.com/conecomivo/edit?css,console,output and http://jsbin.com/korituzoqo/1/edit?css,console,output

[07:30:38.0000] <gsnedders>
rodneyrehm: I… think so. (could be wrong, don't trust me, etc.)

[07:31:03.0000] <rodneyrehm>
You mean they should behave the same?

[07:31:50.0000] <gsnedders>
rodneyrehm: Yes.

[07:32:03.0000] <gsnedders>
rodneyrehm: but really, don't trust my answers when it comes to Transitions

[07:35:17.0000] <rodneyrehm>
IE11. Firefox and Chrome disagree - that's why I'm confused…

[07:36:02.0000] <SimonSapin>
gsnedders: wanna take https://github.com/SimonSapin/python-webencodings/pull/4 ?

[07:38:22.0000] <gsnedders>
SimonSapin: kk

[07:38:40.0000] <gsnedders>
SimonSapin: I wish GH handled moving projects in any nice way

[07:39:06.0000] <gsnedders>
SimonSapin: transferring ownership sucks given it leads to no redirects, but at the same time leaving stuff in place doesn't really work that nicely either

[07:43:46.0000] <annevk>
gsnedders: redirects break once ownership tranfers?

[07:45:46.0000] <gsnedders>
annevk: last I knew you just got 404s after an ownership transfer

[07:45:51.0000] <gsnedders>
annevk: maybe they've fixed that now?

[07:46:13.0000] <annevk>
gsnedders: not sure, renames definitely seem to work fine

[07:46:30.0000] <annevk>
gsnedders: ownership transfer seems to work fine too

[07:54:31.0000] <SimonSapin>
gsnedders: I think I could move the repo to you

[07:56:20.0000] <SimonSapin>
gsnedders: … if you remove your fork

[08:01:01.0000] <gsnedders>
SimonSapin: well I've deleted it now

[08:10:21.0000] <SimonSapin>
"Repository transfer to gsnedders requested"

[08:57:20.0000] <botie>
tantek, at 2016-05-24 13:58 UTC, MikeSmith said: you might want to take a look at https://github.com/w3c/html/issues/160

[08:59:30.0000] <tantek>
MikeSmith: what a strange conversation in that issue

[08:59:44.0000] <tantek>
seems like a like of non-implementer hand-waving - or am I missing something?

[09:05:33.0000] <MikeSmith>
tantek: they appear to be planning to change the document-conformance requiremennts for @rel to say that any value for it is allowed

[09:05:54.0000] <tantek>
that part I'm fine with, we had that in HTML4 and before also

[09:06:23.0000] <MikeSmith>
and that went well?

[09:06:45.0000] <tantek>
yes, it went fine because either people made stuff up in isolation and were ignored

[09:07:00.0000] <tantek>
or people collaborated, publicly documented, and got stuff adopted (microformats rel-registry)

[09:07:20.0000] <tantek>
the open web forces there worked pretty fine

[09:07:28.0000] <tantek>
MikeSmith, what's more annoying in some of these github threads are the odd potshots

[09:11:33.0000] <MikeSmith>
tantek: well it’s an embarrassment of riches as far as that goes

[09:17:20.0000] <tantek>
MikeSmith do you know who jribbens is?

[09:17:47.0000] <tantek>
this is the kind of thing I consider a potshot: "it is my view that having the official list of valid values as random content on some wiki page is not at all acceptable."

[09:18:38.0000] <tantek>
to be blunt, I really don't care what some rando opinion considers acceptable or not. if a system has existed and appears to be working (measured by participation, people adding values, bad values getting edited out), then there is no basis for such nonsense "random"

[09:19:14.0000] <tantek>
And frankly, to have a chair of a WG (chaals) then agree with rando opinion without any basis in any evidence, is also not acceptable.

[09:19:41.0000] <Ms2ger>
tantek, I thought "some rando objecting to anything at all" was the intended work mode of the w3c

[09:20:06.0000] <tantek>
Ms2ger, no that's here in #whatwg, or especially mailing list of the week

[09:20:30.0000] <tantek>
W3C has contained randos to Community Groups (for the most part)

[09:20:37.0000] <tantek>
and the "Incubation Process"

[09:22:07.0000] <tantek>
ironically, I don't disagree with halindrome "Conformance checkers should absolutely accept any value for the rel attribute. And, oh by the way, for the role attribute. Same problem."

[09:22:38.0000] <tantek>
does anyone here remember why there was such a push to require (per spec & validator) all rel values and meta names to be registered somewhere?

[09:22:45.0000] <tantek>
I recall that requirement coming from WHATWG community

[09:25:20.0000] <jgraham>
Presumably because it prevents a wource of error (typos are common) and means that the data can usefully be used by multiple clients

[09:25:24.0000] <jgraham>
*source

[09:28:58.0000] <MikeSmith>
tantek: not just chair, but also editor (if not formally at least in practice)

[09:29:27.0000] <MikeSmith>
kind of judge jury and executioner

[09:29:58.0000] <tantek>
Is this happening because no one is watching? Or no one cares step in? Or ... ?

[09:30:23.0000] <gsnedders>
anyone off-hand know when el.localName was first implemented? It's DOM Level 2 stuff, no? So presumably when XML was first implemented with namespaces?

[09:31:13.0000] <MikeSmith>
tantek: not sure what sort of stepping in you can imagine being effective

[09:31:29.0000] <tantek>
MikeSmith, shutting down HTML5.x

[09:32:14.0000] <MikeSmith>
well I wish anybody luck attempting that

[09:34:40.0000] <MikeSmith>
tantek: but anyway the fact that the rel registry was set up at microformats.org would make me think you ought to remember why

[09:35:19.0000] <MikeSmith>
the fact a requirement was added to the spec saying that any new rel values must be registered there

[09:37:27.0000] <tantek>
MikeSmith, the existing-rel-values page predates any formal demand / request for a registry in HTML5

[09:37:44.0000] <tantek>
we set it up to document reality, because turns out documenting reality is useful

[09:37:56.0000] <tantek>
then there was the big hassle with trying to use IANA rel registry

[09:38:25.0000] <MikeSmith>
yeah I know, I do remember this history

[09:39:11.0000] <MikeSmith>
anyway, I would be very happy personally to drop rel checking from the validator, in the same way I unilaterally and happily dropped meta@name checking

[09:40:13.0000] <tantek>
I'm ok with that too. Other than what jgraham said, I have no idea what the motivations were

[09:40:18.0000] <MikeSmith>
because the spec requirements around document-conformancd for both of those have really not done much more than caused me to burn up a lot of time without really helping authors and developers very much

[09:41:37.0000] <MikeSmith>
tantek: up until you said just now that you didn’t know why the requirement was added, I had been naively assumed you wanted it kept

[09:41:56.0000] <MikeSmith>
I am now not sure who actually does want it kept, except maybe Hixie

[09:42:53.0000] <jgraham>
I think the issue is that apart from tantek most people think these things are a waste of time

[09:43:14.0000] <MikeSmith>
well

[09:43:21.0000] <Ms2ger>
MikeSmith, file an issue on HTML?

[09:43:43.0000] <MikeSmith>
jgraham: the RDFa partisans are very fond of rel and rev too

[09:44:10.0000] <MikeSmith>
Ms2ger: I will probably just go straight to making a PR

[09:44:15.0000] <Ms2ger>
wfm

[09:44:38.0000] <tantek>
jgraham, there is limited utility from rel values, so I'm not sure what you mean by "waste of time"

[09:46:04.0000] <MikeSmith>
I think a good rule of thumb is that when you find any RDFa or JSON-LD or whatever aficionado agreeing with you about something, you seriously need to step back and question yourself your carefully

[09:48:25.0000] <tantek>
that's a reasonable rule of thumb, yeah

[09:49:31.0000] <Ms2ger>
Ha

[09:49:50.0000] <tantek>
re: rel, there's a small handful of rel values that are actually implemented and actively supported by browsers and servers to provide user functionality. that's a demonstrable fact.

[09:49:57.0000] <MikeSmith>
yes

[09:50:01.0000] <MikeSmith>
absolutely

[09:50:19.0000] <tantek>
the problem is that there's a lot of markup "fluff" out there that does nothing, has no user functionality, maybe is just used to write a PDF paper for some academic conference

[09:50:30.0000] <tantek>
including perhaps most rel (and meta) values

[09:50:31.0000] <MikeSmith>
those are the ones that matter quite a bit and that I wish I could restrict the conformance requirements to

[09:51:29.0000] <MikeSmith>
as far as the checker goes, if somebody actually accidentally mispells one of those values that really matter, that is something I would like for the checker to catch and report

[09:52:01.0000] <tantek>
the problem is I see no evidence that anyone in that github issue has any actual clue about "the ones that matter quite a bit"

[09:53:05.0000] <MikeSmith>
well you see no evidence because I think they probably have not actually studied it enough to realize that, yeah

[09:55:48.0000] <MikeSmith>
so yeah, the attitude there of being poised to just cavalierly jettison the requirements despite not actually understanding why they were added to begin with, that is depressing

[09:59:13.0000] <MikeSmith>
and it’s really ironic to see this pattern of decision-making coming from some of the same people who’ve hated on the whatwg for years for benevolent-dictator-driven spec development

[10:00:00.0000] <MikeSmith>
at least those decisions were always made carefully and with a solid understanding of the platform and all its complexities

[10:00:44.0000] <MikeSmith>
this in contrast is like decision-making driven by a self-appointed junta with an axe to grind

[10:01:21.0000] <MikeSmith>
or like Pol Pot and the Khmer Rouge

[10:02:48.0000] <tantek>
MikeSmith: yeah, depressing and ironic

[10:04:24.0000] <jgraham>
Sounds like standards work

[10:36:13.0000] <tantek>
and sometimes things actually go well with standards work. Webmention has entered CR (with 27 implementations) https://twitter.com/w3c/status/735108163704348672

[10:36:20.0000] <tantek>
https://www.w3.org/blog/news/archives/5439

[14:33:34.0000] <wanderview>
Domenic: am I correct that stream spec does not currently set tee(shouldClone=true) anywhere?


2016-05-25
[17:42:13.0000] <MikeSmith>
https://github.com/delapuente/service-workers-101/#service-workers-101 is very nic

[18:53:13.0000] <MikeSmith>
https://rawgit.com/delapuente/presentations/eca25220751ae19b5c12edc9ceee2aad075ba7a6/web-platform-when-why/index.html#/ is very nice too

[19:07:46.0000] <Domenic>
wanderview: I believe that's correct. I think Fetch does? It was needed for some browser off-main-thread use case.…

[00:33:13.0000] <annevk>
Domenic: FWIW: https://bugs.webkit.org/show_bug.cgi?id=158061

[02:07:36.0000] <annevk>
Domenic: so that browsing context name thing was slightly easier to fix than anticipated

[02:08:04.0000] <annevk>
Domenic: kinda nice after several days of drowning in source browsing contexts

[02:09:12.0000] <Domenic>
haha yay

[02:09:41.0000] <Domenic>
Will probably not be able to review until Friday annevk, but we'll see

[02:09:57.0000] <annevk>
There's absolutely no rush

[02:10:14.0000] <annevk>
And we should probably get someone to sign off on the exact same origin check and such

[03:17:13.0000] <Ms2ger>
annevk, hey, https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model seems to have a broken link to fullscreen

[03:18:07.0000] <annevk>
Ms2ger: you mean that the concept is not integrated?

[03:18:17.0000] <annevk>
Ms2ger: there's a couple of open issues around that :/

[03:18:48.0000] <Ms2ger>
If it's known, that's good enough for me :)

[04:08:47.0000] <Manishearth>
annevk: ping

[04:09:46.0000] <annevk>
Manishearth: hey

[04:10:32.0000] <Manishearth>
annevk: in the fetch spec, what happens in a redirect where the redirecting page itself has some content?

[04:10:53.0000] <annevk>
Manishearth: nothing much

[04:11:06.0000] <Manishearth>
annevk: I assume the correc thing to do is to ignore that content

[04:11:35.0000] <Manishearth>
annevk: but from the spec POV I don't see that happening, both events will continue to queue process response body

[04:12:16.0000] <annevk>
Manishearth: sure, we can't just cut the connection

[04:12:32.0000] <annevk>
Manishearth: and if we ever expose redirects we'd want to expose the content they have too

[04:12:49.0000] <Manishearth>
annevk: afaict they expose their content *right now*

[04:12:56.0000] <Manishearth>
and conflict with the actual fetch

[04:12:56.0000] <annevk>
Manishearth: how?

[04:13:37.0000] <Manishearth>
or

[04:13:38.0000] <Manishearth>
hm

[04:14:19.0000] <Manishearth>
ah, I see

[04:14:20.0000] <Manishearth>
nvm

[04:24:15.0000] <annevk>
spec wins again :p

[04:24:30.0000] <annevk>
Seriously though if there's something that could be clarified here let me know

[04:52:26.0000] <Domenic>
I thought there was a fourth way of getting the global... window, self, frames, ?

[04:54:02.0000] <jgraham>
Domenic: this

[04:54:09.0000] <Domenic>
right!! :)

[06:16:04.0000] <annevk>
I like how despite that being general knowledge, folks will still type frames[0]

[06:16:27.0000] <annevk>
Including me, though I have tried to correct to use self instead

[06:16:59.0000] <gsnedders>
idk, I kinda prefer frames[0] simply because it's what we've all always used, so we all instantly know what it is

[06:17:08.0000] <gsnedders>
I always end up having to check what "self" is.

[06:22:13.0000] <annevk>
I just found the best way to alert(1)

[06:22:15.0000] <annevk>
https://github.com/whatwg/html/issues/672

[06:26:14.0000] <gsnedders>
so a BOM now overrides the user override encoding? hmmm. not sure I like that.

[07:22:44.0000] <wanderview>
Domenic: ah, yea... fetch() does indeed use shouldClone=true

[07:23:22.0000] <annevk>
redirects \o/

[07:42:22.0000] <wanderview>
anyone have the Window Insider Preview edge builds?

[08:18:13.0000] <halindrome>
weird question - are there any modern user agents that still support "user stylesheets" ?

[08:19:32.0000] <MikeSmith>
Opera does

[08:19:38.0000] <MikeSmith>
I think, still

[08:19:52.0000] <halindrome>
MikeSmith: thanks

[08:20:01.0000] <gsnedders>
halindrome: Firefox does

[08:20:25.0000] <gsnedders>
halindrome: it's a fixed path in the profile folder, IIRC, but the support is there

[08:20:49.0000] <gsnedders>
(of course, from there you can use @import url(); etc.)

[08:23:20.0000] <Ms2ger>
And Stylish

[09:29:21.0000] <TabAtkins>
annevk: née, not nay

[09:33:04.0000] <astearns>
/me marks the day TabAtkins became a spelling prescriptivist

[09:33:42.0000] <gsnedders>
tbf, they are entirely different words, and I don't think common usage is against him

[09:35:59.0000] <tantek>
nor neigh (sound a horse makes)

[09:36:31.0000] <astearns>
Oh, I agree - and it was good feedback for a non-native speaker. I just found it funny tho

[09:38:14.0000] <TabAtkins>
I mean, (nay rust) means something else entirely.

[09:38:46.0000] <TabAtkins>
If we collectively started agreeing that née was spelled "nay", that would be fine. But currently we do distinguish the words.

[09:42:27.0000] <annevk>
TabAtkins: ta

[09:56:30.0000] <annevk>
SimonSapin: you might want to follow https://github.com/whatwg/html/issues/1177 and/or give feedback

[09:59:04.0000] <SimonSapin>
annevk: thanks. Subscribed, but I don’t have more input to this.

[10:00:05.0000] <SimonSapin>
I agree that it sounds like HTML needs to specify a special case

[10:02:52.0000] <gsnedders>
annevk: what happens if we make it introduce an empty fragment? but I'd be curious as to quite what browsers do

[10:03:09.0000] <gsnedders>
I'd be surprised if they had an actual separate state for having a fragment beyond nullability

[11:51:10.0000] <scshunt>
Hello all! I'm trying to look at some XHR behaviours for implementing an API, and I'm a bit confused by which is the most up-to-date spec.

[11:52:11.0000] <TabAtkins>
scshunt: https://xhr.spec.whatwg.org/

[11:59:09.0000] <scshunt>
TabAtkins: That spec lacks a lot of restrictions that browsers seem to implement, though

[12:00:05.0000] <scshunt>
like preventing setting certain headers like Host or Expect

[12:00:12.0000] <TabAtkins>
annevk: ^^^ ?

[12:02:41.0000] <annevk>
scshunt: that is defined…

[12:03:20.0000] <annevk>
scshunt: step 5 of setRequestHeader

[12:04:10.0000] <scshunt>
annevk: thanks! I missed it because it's a separate document :)

[12:05:00.0000] <annevk>
scshunt: XHR is a thin wrapper around Fetch basically

[12:56:56.0000] <wanderview>
Domenic: ping

[12:59:44.0000] <Domenic>
wanderview: on mobile but what's up

[13:00:12.0000] <wanderview>
Domenic: streams question... I can write an issue up if you prefer... you might be able to just set me straight though

[13:02:21.0000] <Domenic>
Happy to try IRC

[13:02:56.0000] <wanderview>
Domenic: ok, in the spec there is a note that while ReadableStreamTee() requires creating 3 functions, an impl could create a class to do it

[13:03:17.0000] <wanderview>
Domenic: I don't see how that could work since pull() is not called with a `this`...

[13:03:44.0000] <wanderview>
Domenic: the impl would have to bind() the `this` which is not too different from creating a closure

[13:03:49.0000] <wanderview>
in costs

[13:04:18.0000] <wanderview>
Domenic: I was wondering if pull() should get called with the underlyingSource set as its `this`

[13:04:25.0000] <Domenic>
I think pull is called with this... PromiseInvokeOrNoop?

[13:06:32.0000] <wanderview>
Domenic: yep, you are correct... thanks!

[13:08:38.0000] <Domenic>
\o/

[13:09:49.0000] <wanderview>
Domenic: if you have specific places in the spec you know that can be optimized... would love to have the list

[13:09:57.0000] <wanderview>
right now just implementing it pretty literally

[13:17:36.0000] <Domenic>
wanderview: the other ones we did in chrome were a bit field for all the booleans and the state, and of course not implementing the queue with sizes by summing every time you ask for the total size

[13:17:39.0000] <Domenic>
I.e. keep a queue and keep a separate running size

[13:19:26.0000] <wanderview>
Domenic: thanks

[13:20:45.0000] <wanderview>
Domenic: is there a defined algorithm for "Append to List"?  I mean, I can use Array.push()

[13:21:51.0000] <Domenic>
That's what it means yeah

[13:22:09.0000] <Domenic>
(Internal array of course.)

[13:24:03.0000] <wanderview>
ok, thanks

[13:38:05.0000] <wanderview>
Domenic: hmm, but we don't call cancel with PromiseInvokeOrNoop?

[13:38:47.0000] <wanderview>
Domenic: oh... @[[Cancel]] is defined as a method

[13:38:57.0000] <wanderview>
nm

[16:22:58.0000] <Mek>
hmm, the Worker and SharedWorker constructor definitions have an informative note saying "Any same-origin URL will do", but I don't see any formal spec language that actually enforces any kind of same origin requirement...

[16:31:17.0000] <Mek>
and firefox and chrome in fact don't agree on behavior for non same-origin urls here either...

[16:40:34.0000] <Mek>
ah, seems this was an intentional change in the html spec (by moving the check to fetch), but not anything that ever got implemented in chrome, and even firefox is inconsitent about it...

[16:46:24.0000] <Mek>
but that also means that now (according to the spec) a "module" shared worker with a cross-origin url will be shared between websites on all origins, as there are no further checks to only match against shared workers created from the same origin...

[16:50:58.0000] <Mek>
actually, it's even worse than that. According the the spec any website can connect to any running shared worker from any other origin, because any kind of origin checks aren't done if an existing worker with the same script url already exists...

[16:51:02.0000] <Mek>
/me files a bug...


2016-05-26
[01:43:58.0000] <hsivonen>
/me could use some CC0 test cases for the Encoding Standard

[01:51:49.0000] <nox>
What does CC0 mean?

[01:55:35.0000] <hallvors>
annevk: see https://bugzilla.mozilla.org/show_bug.cgi?id=918735 - you agree this test is broken?

[01:55:50.0000] <hsivonen>
nox: it means copyright-wise in the Public Domain expressed in a way that's compatible with countries that don't recognize the act of placing something in the Public Domain by means other than dying and waiting for 70 years

[01:56:16.0000] <nox>
hsivonen: Oh that. Right.

[02:03:26.0000] <zcorpan>
hsivonen: https://github.com/search?q=user%3Amathiasbynens+encoding+standard has some tests (MIT though)

[02:46:34.0000] <hsivonen>
zcorpan: thanks. Those are single-byte only. the multibyte ones are more interesting to test

[02:50:37.0000] <zcorpan>
hsivonen: there's https://github.com/mathiasbynens/utf8.js/tree/master/tests and ... i suppose you know about the tests in web-platform-tests :-)

[02:55:09.0000] <zcorpan>
mathiasbynens: utf8.js should have "encoding standard" in its description so it shows up when searching :-)

[02:59:48.0000] <kochi>
I'm wondering what 'window.frames returns window' means.

[02:59:55.0000] <kochi>
https://html.spec.whatwg.org/multipage/browsers.html#dom-frames

[03:00:48.0000] <mathiasbynens>
zcorpan: done, thanks :)

[03:01:18.0000] <kochi>
so `window.frames === window` and `window.frames.length === window.length`

[03:01:31.0000] <zcorpan>
kochi: yeah

[03:01:48.0000] <zcorpan>
window.frames.self.frames.frames.window === self

[03:02:14.0000] <mathiasbynens>
hsivonen: https://github.com/mathiasbynens/utf8.js/blob/master/tests/generate-test-data.py generates reference encodings for literally every code point

[03:04:19.0000] <kochi>
zcorpan: isee, thanks!

[03:05:23.0000] <zcorpan>
except in some versions of IE i think, where frames[0] would work but window[0] would not. don't recall the details

[03:30:32.0000] <hsivonen>
mathiasbynens: thanks.

[03:31:08.0000] <hsivonen>
I guess I'll have to manually write test cases to poke at interesting invalid edge cases in multibyte encodings

[03:31:30.0000] <hsivonen>
for example, with UTF-8, the invalid stuff is more interesting to test than the valid stuff

[03:31:52.0000] <hsivonen>
particularly that the right number of REPLACEMENT CHARACTERs get emitted in the right places

[03:36:20.0000] <annevk>
hallvors: that test gives a 404

[03:36:37.0000] <hallvors>
fix the URL :)

[03:37:01.0000] <annevk>
hallvors: how?

[03:37:27.0000] <annevk>
ah, http://w3c-test.org/XMLHttpRequest/open-url-bogus.htm

[03:37:58.0000] <hallvors>
not my fault that w3c-test.org has forgotten "cool URIs don't change" :-p

[03:38:12.0000] <annevk>
hallvors: fair

[03:38:22.0000] <annevk>
hallvors: we could change it to http://test:test/ instead

[03:39:33.0000] <hallvors>
(It's great to have a public, running instance of web-platform-test though. <3 w3c-test.org except for the changing URLs)

[03:40:44.0000] <hallvors>
annevk: I'm about to push an updated test

[03:43:36.0000] <annevk>
hsivonen: there's a number of webplatformtests written by Richard Ishida

[03:43:54.0000] <annevk>
hsivonen: also with contributions from Joshua Bell and myself

[03:44:32.0000] <annevk>
hsivonen: https://github.com/w3c/web-platform-tests/tree/master/encoding

[03:44:50.0000] <annevk>
hsivonen: there's also at least one PR in progress that I copied you on

[03:48:03.0000] <hallvors>
Ms2ger , annevk: https://github.com/w3c/web-platform-tests/pull/3072 - also added a couple more cases

[03:58:55.0000] <annevk>
hallvors: are you covering https://github.com/whatwg/xhr/issues/54?

[04:00:21.0000] <hallvors>
annevk:  getting to it, I'm planning to add Boris's test to wpt

[04:00:33.0000] <annevk>
<3

[04:00:41.0000] <hallvors>
unless this is a race and someone beats me :)

[04:02:04.0000] <hallvors>
And you risk inflating my ego by saying an invalid URL parsing case I came up with is "rather tricky" :)

[04:22:55.0000] <Ms2ger>
annevk, any reason not to merge?

[04:25:07.0000] <zcorpan>
hallvors: heh, well better than nobody fixing the test right

[04:26:04.0000] <hallvors>
zcorpan: we'll soon do pull request duels at dawn.. ;)

[04:30:33.0000] <zcorpan>
hallvors: maybe we can have an xhr runner for urltestdata.json?

[04:34:36.0000] <hallvors>
I know nothing about urltestdata.json but it sounds like a good resource and a good idea :)

[04:41:59.0000] <annevk>
Ms2ger: no

[05:11:12.0000] <hsivonen>
annevk: thanks. are Web Platform Tests in general CC0 these days?

[05:11:24.0000] <annevk>
hsivonen: no unfortunately not

[05:11:53.0000] <annevk>
hsivonen: https://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html

[05:11:53.0000] <hsivonen>
annevk: some of the tests in the PR are too JavaScripty for my needs

[05:12:03.0000] <hsivonen>
I just wrote https://github.com/hsivonen/encoding-rs/blob/master/src/euc_jp.rs#L201

[05:12:22.0000] <hsivonen>
that's the kind of thing I'm looking for

[05:12:23.0000] <annevk>
ah yeah, they are not written with generic consumers in mind yet

[05:12:54.0000] <hsivonen>
(and licensed such that the license notice at the top of that file doesn't need to become more complex)

[05:22:38.0000] <annevk>
"Stage 1!" nice work Domenic on cancelable promises

[05:23:52.0000] <annevk>
Domenic: plan on tweeting the slides?

[05:37:24.0000] <Ms2ger>
> I think of a URL as...

[05:37:28.0000] <Ms2ger>
/me stops reading

[05:41:03.0000] <jgraham>
A burrito?

[05:41:26.0000] <annevk>
Ms2ger: context?

[05:41:47.0000] <Ms2ger>
Some webkit bug

[05:43:39.0000] <annevk>
Ah yeah, had actually seen that

[05:43:59.0000] <annevk>
Fortunately WebKit engineers ignored that and went on fixing the issue

[06:38:56.0000] <nox>
Where was that? Looks fun.

[06:44:11.0000] <annevk>
nox: https://bugs.webkit.org/show_bug.cgi?id=157153

[06:49:46.0000] <nox>
annevk: At first I googled for "I think of a URL as" and all I found was a HN comment. :)

[08:30:01.0000] <Domenic>
annevk: not a big fan of that being publicized before I had a chance to clean up the message and supporting materials, so no, no further tweets from me.

[08:30:33.0000] <annevk>
Domenic: oh it was already publicized?

[08:30:55.0000] <annevk>
Domenic: I mostly got it from the minutes, which I assume are somewhat confidential

[08:31:21.0000] <Domenic>
annevk: yeah Addy tweeted some screenshot of a slide and now people are all like "new syntax boo I hate new things"

[08:49:34.0000] <annevk>
Domenic: ah, well if you have some free time left before the flight I'd try to enjoy the city there a bit

[08:49:46.0000] <annevk>
Domenic: it's quite lovely

[08:50:27.0000] <Domenic>
annevk: heh, just landed back in NYC. But I'll be back in June for BlinkOn, and yeah, we got to go out to a few places which was fun.

[09:12:23.0000] <annevk>
This US-ASCII thing is far from easy

[09:12:35.0000] <annevk>
Have to rewrite most of form submission...

[11:57:10.0000] <jyasskin>
What's the right way to phrase statements about what code is allowed to do? "X realm is allowed to Y" flows much better than "X global ..." or "X settings object ...", but both annevk and marcosc have objected to using "realm" in web specs.

[13:07:02.0000] <scshunt>
Hello! Do XMLHttpRequests ignore 1XX series status codes

[13:07:03.0000] <scshunt>
?

[14:23:10.0000] <gsnedders>
annevk: https://news.ycombinator.com/item?id=11777450 I presume you've seen


2016-05-27
[22:20:54.0000] <annevk>
jyasskin: not sure what you mean

[22:21:09.0000] <annevk>
scshunt: 1xx doesn't really reach APIs

[22:21:30.0000] <annevk>
gsnedders: I did, thanks; lots of confusion there, but also some good stuff

[22:56:35.0000] <MikeSmith>
tantek: you need some alt text on that sunglasses tweet man

[22:57:22.0000] <tantek>
I don't think twitter has API for that alt text yet - does it?

[22:57:38.0000] <MikeSmith>
alt="the 1990s called me today saying they want their sunglasses back"

[22:57:45.0000] <MikeSmith>
yeah they just added it today

[22:57:49.0000] <tantek>
the API?

[22:58:46.0000] <MikeSmith>
hmm thought the docs said so

[22:58:57.0000] <MikeSmith>
/me looks for the docs

[22:59:32.0000] <MikeSmith>
ah yeah no mention actually in https://support.twitter.com/articles/20174660

[22:59:56.0000] <tantek>
right the lack of API support for the alt is the issue

[23:00:14.0000] <tantek>
but if anyone figures that out / finds it - I can work on getting various indieweb twitter-posting tools updated

[23:16:26.0000] <scshunt>
annevk: that's what I figured. Wanted to check, since there's no explicit handling and Expect: 100-continue would be really convenient for what I'm working on

[23:27:25.0000] <annevk>
scshunt: see issues against Fetch

[23:28:04.0000] <annevk>
scshunt: might want to mention use cases there, maybe we can convince implementers

[23:28:27.0000] <scshunt>
annevk: can you please link?

[23:36:37.0000] <annevk>
scshunt: later, commuting

[23:36:55.0000] <scshunt>
kk

[00:00:04.0000] <annevk>
scshunt: https://github.com/whatwg/fetch/issues/41

[00:00:15.0000] <annevk>
scshunt: I thought there was another issue too, can't find it easily

[01:34:38.0000] <larry1981>
Hi, is there a single document with all the documents and properties that I can use to validate a HTML5 file? Something similar to Doctype DTD for older HTML versions ?

[01:34:59.0000] <larry1981>
Sorry, I meant element and properties.

[01:36:21.0000] <Ms2ger>
No

[01:36:22.0000] <annevk>
larry1981: https://html.spec.whatwg.org/multipage/

[01:36:40.0000] <annevk>
larry1981: if you really want single, https://html.spec.whatwg.org/, but that takes a while to load

[01:37:18.0000] <larry1981>
The last link is not working

[01:39:50.0000] <larry1981>
What I want is a file with all the element and properties so I could build a software that allow to create valid HTML5 with all possible element and properties available. I don't want a manual.

[01:40:12.0000] <annevk>
larry1981: maybe your client includes the trailing comma as part of the link?

[01:40:36.0000] <annevk>
larry1981: I see, there's no such thing

[01:41:21.0000] <annevk>
larry1981: there's approximations of that, but no sigar, there's also a thesis that explains why this is the case: https://hsivonen.fi/thesis/html5-conformance-checker

[01:49:55.0000] <larry1981>
What I need is something similar to tables in this page, with all possible element, attributes, events etc...: https://html.spec.whatwg.org/multipage/indices.html#index

[01:57:21.0000] <annevk>
zcorpan: thanks for merging those

[01:57:25.0000] <annevk>
(and reviewing)

[01:57:36.0000] <annevk>
Guess I better fix the rest today

[01:57:41.0000] <zcorpan>
np

[02:00:53.0000] <zcorpan>
larry1981: maybe you can use the RELAXNG schemas from the html checker, but again note that they have holes that are plugged with Schematron or custom Java code

[02:01:18.0000] <zcorpan>
larry1981: they might also be a bit out of date

[02:03:29.0000] <zcorpan>
larry1981: but it'd be cool if you started from a different angle and give checker.html5.org some competition :-)

[02:04:01.0000] <larry1981>
I don't really need to validate HTML. I just need to know which attribute or event is available for each HTML element.

[02:05:35.0000] <larry1981>
I want to build something similar to Bootstrap Studio but I would like to support full HTML5, Bootstrap and Foundation.

[02:15:21.0000] <zcorpan>
larry1981: then the spec's index is probably the best

[02:32:22.0000] <nox>
gsnedders: Who could help you review https://github.com/html5lib/html5lib-tests/pull/65?

[02:44:57.0000] <larry1981>
I guess my best information source would be https://www.w3.org/TR/html5/index.html#index

[02:45:37.0000] <Ms2ger>
No

[02:45:45.0000] <Ms2ger>
TR stands for "TRash"

[02:46:24.0000] <annevk>
larry1981: you might want to read https://annevankesteren.nl/2016/01/film-at-11 before trusting what they publish

[03:37:51.0000] <hsivonen>
annevk: does index-jis0208 have duplicates and that's why "index Shift_JIS pointer" has been defined the way it has?

[03:39:30.0000] <hsivonen>
annevk: if yes, a note to that effect would be good. if no, it would be nice to say that you just filter on the pointer returned after normal index jis0208 lookup

[03:40:29.0000] <annevk>
hsivonen: an issue would be good 😊

[03:40:48.0000] <annevk>
hsivonen: but yeah, pretty sure there are duplicates

[03:41:58.0000] <hsivonen>
annevk: ok. thanks

[03:49:25.0000] <hsivonen>
fun times. the Encoding Standard spec offers math in a sequence that overflows a 16-bit integer but doesn't if reordered.

[03:49:53.0000] <hsivonen>
(the half-width math for EUC-JP and Shift_JIS, specifically)

[03:51:47.0000] <annevk>
hsivonen: 0xFF61 + byte − 0xA1?

[03:52:08.0000] <annevk>
hsivonen: compilers don't help with that?

[04:21:07.0000] <annevk>
zcorpan: time for one more small PR before I do a bigger one or would you prefer I group them?

[04:21:53.0000] <zcorpan>
annevk: i can review a small PR

[04:22:38.0000] <annevk>
zcorpan: hmm never mind, more complicated than I thought

[04:23:41.0000] <annevk>
zcorpan: mailto: doesn't seem to ever use multipart/form-data, but it does use application/x-www-form-urlencoded...

[04:23:50.0000] <annevk>
zcorpan: and text/plain

[04:25:06.0000] <hsivonen>
annevk: yes, that constant plus variable minus constant

[04:25:41.0000] <hsivonen>
annevk: that panics with an integer overflow in debug-mode Rust when doing the math as u16

[04:26:26.0000] <hsivonen>
annevk: when integer overflow is an error, the compiler apparently doesn't do the sort of rearraging and constant folding that would remove the error

[04:26:45.0000] <annevk>
hsivonen: if you don't mind, one more issue? I'll happily change that (and maybe leave a note in the source for myself)

[04:26:56.0000] <hsivonen>
annevk: ok

[04:29:06.0000] <annevk>
zcorpan: I guess I should make multipart/form-data a special case for "Submit as entity body"

[04:29:48.0000] <annevk>
zcorpan: that would also make it easier the remove the weird "multipart/form-data boundary string" and have the algorithm just return that

[04:30:38.0000] <zcorpan>
annevk: ok. i haven't studied this section in detail yet so i don't know if what you say makes sense yet :-)

[04:31:22.0000] <annevk>
zcorpan: this section doesn't make sense

[04:31:37.0000] <annevk>
Oh, I should get some lunch

[04:32:01.0000] <zcorpan>
lunch makes sense

[04:34:29.0000] <hsivonen>
/me filed https://github.com/whatwg/encoding/issues/49

[04:35:14.0000] <hsivonen>
feel free to shock people who prefer BNF specs with that issue report. :-)

[05:16:52.0000] <zcorpan>
annevk: is it intentional that data:,foo bar when parsed and serialized is data:,foo bar rather than data:,foo%20bar ?

[05:18:12.0000] <annevk>
zcorpan: https://url.spec.whatwg.org/#cannot-be-a-base-url-path-state would encode a space, no?

[05:18:32.0000] <annevk>
oh, it would not

[05:19:02.0000] <annevk>
zcorpan: it does look intentional, but it's been a while

[05:21:32.0000] <zcorpan>
annevk: seems like it wouldn't work so well in contexts that assume you can split on spaces, like ping="", srcset="" etc

[05:22:33.0000] <annevk>
zcorpan: something something logic

[05:23:20.0000] <zcorpan>
annevk: i also don't see anything in the syntax section that allows URLs that don't have a slash after the colon. am i missing something there?

[05:24:40.0000] <zcorpan>
i can file issue(s)

[05:25:12.0000] <annevk>
zcorpan: I think you are missing something

[05:25:45.0000] <annevk>
https://url.spec.whatwg.org/#syntax-url-relative -> https://url.spec.whatwg.org/#syntax-url-path-relative-scheme-less -> https://url.spec.whatwg.org/#syntax-url-path-relative

[05:28:55.0000] <zcorpan>
annevk: ah thx

[05:41:12.0000] <zcorpan>
annevk: tracked it back to https://github.com/whatwg/url/commit/ad3660f97132738b6b2ff0020656e4cb87365f00

[05:42:36.0000] <zcorpan>
http://krijnhoetmer.nl/irc-logs/whatwg/20121026#l-573

[05:54:56.0000] <annevk>
zcorpan: PR is up, but no longer trivial

[05:59:00.0000] <nox>
https://news.ycombinator.com/item?id=11785456 Hah.

[06:00:30.0000] <zcorpan>
filed https://github.com/whatwg/url/issues/125

[06:01:35.0000] <annevk>
nox: https://resources.whatwg.org/logo-url.svg is the only right answer

[06:02:02.0000] <nox>
annevk: Neat. :)

[06:03:30.0000] <annevk>
nox: that is actually mostly a joke on https://github.com/nodejs/node-v0.x-archive/pull/1580 which tantek found and put on http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces

[06:03:53.0000] <annevk>
nox: which has funny-at-the-time-memes such as https://camo.githubusercontent.com/bd208bf0093648b4ad23a56faa584596580f76f5/687474703a2f2f692e696d6775722e636f6d2f3163776d352e706e67

[06:10:53.0000] <zcorpan>
https://camo.githubusercontent.com/bd208bf0093648b4ad23a56faa584596580f76f5/687474703a2f2f692e696d6775722e636f6d2f3163776d352e706e67 is the best

[06:33:18.0000] <zcorpan>
heh http://krijnhoetmer.nl/irc-logs/whatwg/20121026#l-964

[06:37:38.0000] <annevk>
zcorpan: couple more months I guess?

[06:38:35.0000] <zcorpan>
yeah. mark your calendars, folks

[06:39:15.0000] <jgraham>
Only if there will be cake

[06:39:46.0000] <zcorpan>
sure why not

[06:40:08.0000] <zcorpan>
we can bikeshed over :

[06:40:33.0000] <jgraham>
I'm pretty sure you will need a : to eat cake

[06:41:15.0000] <zcorpan>
[citation needed]

[07:08:27.0000] <darobin>
do you fine people know if the behaviour of Gecko for document.createElement('p', null) (which will produce <p is="null">) is intentional?

[07:08:59.0000] <darobin>
it doesn't match the spec, but I don't know if it's intentionally different or not

[07:09:26.0000] <darobin>
(it's certainly unhelpful)

[07:14:27.0000] <nox>
zcorpan: Let's make http:://google.fr a valid URL.

[07:23:49.0000] <annevk>
darobin: hmmm Gecko already does custom elements?

[07:24:06.0000] <darobin>
annevk: I don't think so, but it does *something* with that second argument

[07:24:15.0000] <annevk>
darobin: that seems like a bug

[07:24:20.0000] <darobin>
ok, I'll file

[07:24:24.0000] <annevk>
darobin: though the fact that null becomes "null" is quite reasonable

[07:24:36.0000] <darobin>
also, undefined becomes "undefined"

[07:24:36.0000] <annevk>
darobin: if you want to omit arguments, use undefined

[07:24:40.0000] <annevk>
ooh

[07:24:44.0000] <annevk>
darobin: that's pretty bad

[07:24:48.0000] <darobin>
I'm not sure, this came up as a bug in React

[07:25:09.0000] <darobin>
with current React and recent Firefox, *all* elements created through React have is="null"

[07:25:34.0000] <darobin>
because they have code that is like document.createElement(elName, isAttr ? isAttr : null)

[07:25:40.0000] <annevk>
darobin: seems like a React thing

[07:25:53.0000] <darobin>
yeah, I fixed it in React, but Firefox's behaviour is wrong

[07:25:54.0000] <annevk>
darobin: they probably overwrite document.createElement

[07:26:02.0000] <darobin>
no, of course not!

[07:26:07.0000] <darobin>
why would they do that?

[07:26:10.0000] <annevk>
darobin: that is, in Firefox nightly I don't get an is="" attribute

[07:26:26.0000] <annevk>
darobin: reasons?

[07:26:32.0000] <darobin>
I do

[07:26:47.0000] <darobin>
in 48.0a2

[07:27:25.0000] <darobin>
I don't think there's a JS framework out there that has been doing anything to built-in stuff since PrototypeJS went out of fashion

[07:27:44.0000] <annevk>
darobin: have you tested it outside the framework?

[07:27:49.0000] <darobin>
in the console, document.createElement('p', null) -> <p is="null">

[07:28:08.0000] <zcorpan>
no is attribute for me 49.0a1 (2016-05-25)

[07:28:15.0000] <annevk>
on a page that doesn't load the framework darobin?

[07:28:17.0000] <zcorpan>
for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4240

[07:28:19.0000] <darobin>
ah, I guess it got fixed, cool

[07:28:23.0000] <darobin>
yeah, this is Bugzilla

[07:28:39.0000] <annevk>
oh wait

[07:28:44.0000] <annevk>
I do get it in the console

[07:29:00.0000] <annevk>
I wonder if Firefox's developer console has a bug here

[07:29:11.0000] <annevk>
File a bug on that?

[07:29:25.0000] <annevk>
That is broken

[07:29:30.0000] <darobin>
let me update to the latest dev and see if it's still there

[07:29:39.0000] <annevk>
I use Nightly and it's there so

[07:29:50.0000] <darobin>
I don't think it's console-specific, I was also getting it in page

[07:31:40.0000] <darobin>
but indeed I can't repro in the DOM Viewer

[07:33:22.0000] <gsnedders>
nox: where did you get those error strings from? did you just copy html5lib?

[07:33:45.0000] <nox>
gsnedders: Not sure I understand the question.

[07:44:00.0000] <gsnedders>
nox: wrt https://github.com/html5lib/html5lib-tests/pull/65

[07:44:13.0000] <gsnedders>
nox: you have line, column position, and then a string. where does that string come frm?

[07:44:30.0000] <gsnedders>
nox: does html5ever have the same set of strings that html5lib does?

[07:44:56.0000] <nox>
gsnedders: No, I think I didn't know where the strings come from when I did that, it's quite an old PR.

[07:44:57.0000] <darobin>
annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=1276240

[07:45:10.0000] <nox>
gsnedders: I just invented some strings that correspond to the right errors, IIRC.

[07:45:46.0000] <gsnedders>
nox: so they're arbitrarily made up strings in both html5lib and html5ever

[07:45:51.0000] <gsnedders>
nox: which is what I was expecting

[07:46:01.0000] <gsnedders>
/me still thinks we should try and standardise some set of strings

[07:46:30.0000] <gsnedders>
Obviously if your implementation merges a number of the parse errors (because the spec only requires a *number* of parse errors in the right place, not specific types)

[07:46:55.0000] <gsnedders>
then you should either just check the positions or you should have a list of which of your parse errors correspond to what

[07:55:13.0000] <smaug____>
what is module worker?

[07:56:24.0000] <annevk>
darobin: ta

[07:56:26.0000] <smaug____>
in other words, annevk I have no idea what https://github.com/whatwg/html/issues/1322 is about :)

[07:56:38.0000] <darobin>
a pleasure sire annevk

[07:57:02.0000] <annevk>
smaug____: module worker is one that runs module scripts

[07:57:02.0000] <Ms2ger>
smaug____, a worker that's an ES module

[07:57:16.0000] <darobin>
I'm still baffled as to why it does not trigged in either Live DOM or JSBin, but *shrug*

[07:57:27.0000] <smaug____>
and module worker is useful because?

[07:58:03.0000] <annevk>
smaug____: because devs want to use modules

[07:58:51.0000] <smaug____>
ok, not helpful yet. Why do we need special workers for modules?

[07:59:03.0000] <smaug____>
how do they behave differently to normal workers?

[07:59:11.0000] <smaug____>
s/normal/dedicated/

[07:59:15.0000] <annevk>
smaug____: different JS syntax

[08:01:26.0000] <smaug____>
still don't understand. I guess I'm not familiar enough with modules

[08:01:39.0000] <smaug____>
I thought they were useful when integrated with other JS stuff

[08:01:49.0000] <annevk>
smaug____: the JavaScript needs to be parsed differently so need some kind of opt-in

[08:01:52.0000] <smaug____>
so that module could export "API"s

[08:02:20.0000] <smaug____>
annevk: so the export functionality wouldn't be really used in module workers?

[08:02:37.0000] <smaug____>
just ability to load a module in worker, just like in main thread using <script> ?

[08:02:50.0000] <annevk>
smaug____: there's a main script that imports other scripts, which would export functionality

[08:03:03.0000] <annevk>
smaug____: in the main thread you need to use <script type=module>

[08:03:14.0000] <annevk>
smaug____: they're analogous

[08:03:31.0000] <smaug____>
now I'm lost

[08:03:33.0000] <annevk>
smaug____: you cannot use modules without opt-in

[08:04:04.0000] <smaug____>
annevk: you're saying even in module worker there is main script which imports other stuff?

[08:04:13.0000] <annevk>
smaug____: and a module script is something that either imports or exports, there's not much more to it

[08:04:27.0000] <annevk>
smaug____: yes

[08:04:41.0000] <smaug____>
so why do we need module worker

[08:04:47.0000] <annevk>
smaug____: to be able to do that

[08:04:54.0000] <smaug____>
if the main script is just plain normal js

[08:05:00.0000] <annevk>
smaug____: it's not

[08:05:05.0000] <annevk>
smaug____: I just said it's a module script

[08:05:08.0000] <smaug____>
plain normal JS can't import?

[08:05:14.0000] <annevk>
smaug____: indeed

[08:05:16.0000] <smaug____>
even in main thread?

[08:05:19.0000] <annevk>
yes

[08:05:30.0000] <smaug____>
ohhoh, I didn't know the setup is so odd

[08:05:32.0000] <smaug____>
ok

[08:05:47.0000] <annevk>
as I said, main thread needs <script type=module>

[08:06:04.0000] <smaug____>
so if modules are being used, all the script usage will be <script type=module>, pretty much

[08:06:20.0000] <smaug____>
some main module importing other modules

[08:06:23.0000] <annevk>
yeah, unless you want to mix things up I suppose

[08:07:27.0000] <smaug____>
ok, why do we then want to change worker loading depending on whether we're dealing with module worker?

[08:09:32.0000] <annevk>
smaug____: it didn't seem worth the hassle to support CORS for classic workers

[08:17:42.0000] <smaug____>
/me can't find where we do same origin check for workers in the spec.

[08:18:52.0000] <annevk>
smaug____: it happens in Fetch

[08:19:10.0000] <annevk>
smaug____: the request mode is "same-origin" or "cors" (module workers)

[08:19:44.0000] <annevk>
smaug____: though we need to bring one check back: https://github.com/whatwg/html/pull/1332

[08:20:41.0000] <annevk>
Gotta go

[08:20:50.0000] <smaug____>
it is rather error prone that module workers even fetch data so differently

[08:25:52.0000] <annevk>
smaug____: from what perspective would it be "so different"?

[08:26:05.0000] <annevk>
smaug____: same-origin vs CORS is nearly identical for most purposes

[08:26:23.0000] <smaug____>
why do we have different fetch based on the type

[08:27:17.0000] <smaug____>
I would expect fetch type depend on some option passed to ctor, but not on the worker type

[08:28:19.0000] <smaug____>
like WorkerOptions having fetchType or some such. But I totally don't know the background for all this

[09:48:32.0000] <annevk>
TabAtkins: so I think "nay Rust" was actually correct

[09:49:14.0000] <annevk>
TabAtkins: having done some searching, "née" seems to about names, whereas "nay" means "or rather"

[09:49:59.0000] <annevk>
/me changes it back

[09:55:52.0000] <nox>
annevk: Speaking of née/nay, your name is pronounced like "année" right?

[09:56:12.0000] <annevk>
nox: annuh

[09:56:33.0000] <nox>
Mmmh. Is that a "uh" that the French me can never succeed in pronouncing correctly?

[09:57:13.0000] <annevk>
nox: annè

[09:57:27.0000] <nox>
Oh! Ok! That I can do. :D

[09:57:49.0000] <annevk>
personally I think I say it more "uh" but "eh" works

[10:04:51.0000] <annevk>
mounir: I can, I thought you wanted Domenic to sign off

[10:05:22.0000] <jgraham>
annevk: Tiy can't really say either neé or nay in that context

[10:05:33.0000] <jgraham>
I think the word you are looking for is "or"

[10:05:48.0000] <annevk>
jgraham: Tiy?

[10:06:00.0000] <Domenic>
mounir: annevk: still digging myself out of the post-TC39 email pile, but I plan to do Streams and HTML today, so likely to happen...

[10:06:17.0000] <jgraham>
annevk: You, but shifted one key left :)

[10:07:46.0000] <annevk>
jgraham: I'm not looking for "or"

[10:08:15.0000] <annevk>
jgraham: I'm looking for "or rather" or "^H^H^H^H^H" expressed in a word

[10:08:55.0000] <jgraham>
annevk: A nay B, implies not A but B.

[10:09:15.0000] <annevk>
jgraham: yeah

[10:09:21.0000] <annevk>
jgraham: that's good

[10:09:36.0000] <jgraham>
There are still browsers written in C++ though

[10:09:40.0000] <annevk>
I know

[10:09:40.0000] <jgraham>
So it doesn't make sense

[10:09:45.0000] <annevk>
that's why there's parenthesis

[10:09:58.0000] <jgraham>
Right, it still doesn't make sense

[10:11:45.0000] <annevk>
jgraham: I guess I disagree, even though I'm probably wrong

[10:14:06.0000] <annevk>
Domenic: I take that as that you'll merge them

[10:14:13.0000] <Domenic>
annevk: yeah

[10:46:51.0000] <Domenic>
nice! https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests?utm_source=twitter&utm_medium=social&utm_campaign=multiple-assignees

[10:47:53.0000] <Garbee>
Good to see GH finally giving the issue tracker some TLC lately.

[10:48:03.0000] <Garbee>
Thanks for sharing Domenic.

[11:11:38.0000] <TabAtkins>
annevk: "nay" can't be used to mean "other" in *that* way, at least in English as I know it.

[11:11:59.0000] <TabAtkins>
(But as someone correctly pointed out, if née *is* used, it's the wrong way around - it indicates maiden names, old company names, etc.

[11:12:01.0000] <TabAtkins>
)

[11:14:22.0000] <tantek>
nay pretty much means voting "no" http://www.thefreedictionary.com/nay

[11:18:13.0000] <TabAtkins>
Yeah, I'm trying to come up with a usage in my vernacular that isn't implicitly just referring to "yay/nay".

[11:19:57.0000] <Domenic>
smaug____: ping on https://github.com/whatwg/html/pull/1284

[11:20:57.0000] <TabAtkins>
annevk: Anyway, the most reasonable wording my vernacular would be "(or now Rust)" or similar.

[11:27:55.0000] <smaug____>
Domenic: back from sauna. looking...

[11:28:27.0000] <smaug____>
/me always clicks the wrong link when is supposed to review something

[11:37:22.0000] <smaug____>
Domenic: does the patch need some merging

[11:37:37.0000] <Domenic>
smaug____: what do you mean?

[11:38:02.0000] <Domenic>
smaug____: it is unmerged pending review, if that's what you mean

[11:38:45.0000] <smaug____>
Domenic: I mean if I look at the latest spec, there are some steps in the algorithm I don't see in that patch

[11:39:16.0000] <smaug____>
like there should be "Set history.state to state." somewhere there

[11:39:36.0000] <Domenic>
smaug____: that is just GitHub showing insufficient context in the diff :(

[11:39:50.0000] <Domenic>
those "expand" buttons do not work

[11:40:03.0000] <smaug____>
ugh

[11:40:12.0000] <smaug____>
and we really want to use github :/

[11:40:20.0000] <smaug____>
ok, I guess r+

[11:40:47.0000] <smaug____>
can I somehow download raw patch

[11:44:10.0000] <Domenic>
smaug____: yes, https://patch-diff.githubusercontent.com/raw/whatwg/html/pull/1284.patch

[11:44:28.0000] <Domenic>
which is what you get redirected to if you add .patch to the end of the PR URL, i.e. https://github.com/whatwg/html/pull/1284

[11:44:30.0000] <Domenic>
er

[11:44:33.0000] <Domenic>
https://github.com/whatwg/html/pull/1284.patch

[11:48:45.0000] <smaug____>
aha, that is something I've been told many times but I always forget

[11:49:02.0000] <smaug____>
but ok, the raw patch isn't really more useful either

[11:54:49.0000] <Domenic>
yeah, local git client or compiled results is kind of the only way

[11:55:03.0000] <Domenic>
I'd like to get a CI server that automatically serves us the compiled spec, actually

[11:59:27.0000] <jyasskin>
Domenic: For Bikeshed, I think we can hack http://hg.csswg.org/dev/bikeshed-web/ to do the test, and have the 'Details' link be the compiled spec. That server already has URLs that'll serve the output.

[12:09:17.0000] <Domenic>
jyasskin: oh, cool. My plan was to have Travis CI use https://zeit.co/now/#whats-now to stand up a quick static file server with the results that Travis compiled, which if I understand correctly that service will host indefinitely for us.

[12:10:14.0000] <Domenic>
Or we could just ssh the results onto the final server; that's what streams does for PRs that are based on in-repo branches (instead of forks): https://github.com/whatwg/streams/blob/master/deploy.sh#L60-L71 + https://streams.spec.whatwg.org/branch-snapshots/?C=M;O=D

[14:45:33.0000] <jyasskin>
Domenic: The existing URLs are like https://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/jyasskin/permissions/ua-can-return-anything/index.bs, which you can paste into the PR description. The main benefit from having api.csswg.org/bikeshed be the CI server is that it could set a "commit status" into github so the link is accessible even if

[14:45:33.0000] <jyasskin>
you forget to write it in the PR.

[15:02:19.0000] <Domenic>
oh very interesting...

[15:53:03.0000] <jsbell>
Any bikeshed experts know if you can get <ol class=algorithm> from a markdown 1. ... -style list, or should I be regretting removing the markup?

[15:57:51.0000] <jyasskin>
TabAtkins: ^ (but I don't think you can get [class=Algorithm] from markdown.

[15:58:11.0000] <TabAtkins>
Nah, you gotta wrap it in a div

[16:00:27.0000] <jsbell>
TabAtkins: Alas, that doesn't appear to slap the class on the ol (which makes substeps more visible); bs bug?

[16:00:35.0000] <jsbell>
er, should I file a bs issue to suggest this

[16:00:59.0000] <TabAtkins>
The substeps become mroe visible if it's on the ol? Is this a feature I wrote and then forgot about?

[16:02:19.0000] <jsbell>
TabAtkins: It's in W3C's stylesheet... e.g. https://w3c.github.io/IndexedDB/ and (once respec is done its think) jump to e.g. "Object Store Storage Operation"

[16:03:24.0000] <TabAtkins>
Oh! I didn't realize that would happen!

[16:05:35.0000] <jsbell>
In obviously related news, suggestions for https://github.com/w3c/IndexedDB/blob/bikeshed/index.bs welcome before I merge it

[16:10:44.0000] <jyasskin>
Documented at https://w3c.github.io/tr-design/src/sample.html#algorithm

[16:43:03.0000] <TabAtkins>
jyasskin: I fixed the issue in Bikeshed's stylesheet, and opened a PR for it on the W3C's stylesheet.

[16:46:55.0000] <TabAtkins>
jyasskin: So you can use a wrapper div

[16:47:36.0000] <jyasskin>
Tell jsbell when he gets back.


2016-05-28
[18:01:49.0000] <eligrey>
empty xml documents are valid, but it seems that every vendor misread the whatwg domparser spec

[18:02:18.0000] <eligrey>
for some reason all browsers give you a <parsererror> when you do (new DOMParser).parseFromString("", "application/xhtml+xml")

[18:02:45.0000] <eligrey>
but no errors when you do document.implementation.createDocument('','',null) (equivalent empty document)

[21:11:11.0000] <annevk>
eligrey: what makes you say they are well-formed?

[21:11:22.0000] <annevk>
eligrey: pretty sure they're not

[21:20:30.0000] <eligrey>
annevk: go to an empty xml file in chrome firefox ie or edge

[21:20:50.0000] <annevk>
eligrey: yeah, give a parse error

[21:20:54.0000] <annevk>
eligrey: e.g., data:text/xml,

[21:21:02.0000] <eligrey>
what browser?

[21:21:08.0000] <annevk>
Firefox Nightly

[21:21:29.0000] <MikeSmith>
I thought the XML spec says every XML document must have a root element

[21:21:56.0000] <annevk>
eligrey: https://www.w3.org/TR/xml/#sec-well-formed also pretty clearly requires an element

[21:21:58.0000] <eligrey>
oh, weird then

[21:22:06.0000] <annevk>
eligrey: it does seem that Chrome and Safari are buggy

[21:22:07.0000] <eligrey>
that the dom allows xml without an element

[21:22:21.0000] <eligrey>
document.implementation.createDocument('','',null) works in ff/ie/edge/chrome

[21:22:22.0000] <annevk>
eligrey: the DOM allows many things XML doesn't

[21:22:37.0000] <annevk>
eligrey: it's a model, not a syntax

[21:22:52.0000] <annevk>
those are often distinct in capabilities

[21:23:10.0000] <eligrey>
alright

[21:23:21.0000] <eligrey>
makes sense though that 2 dom methods should behave similarly

[21:23:27.0000] <eligrey>
since its domparser, not xmlparser

[21:23:28.0000] <annevk>
please do file a bug on Chrome/Safari though

[21:23:48.0000] <annevk>
eligrey: those APIs have bad names, arguably

[21:29:44.0000] <eligrey>
annevk: speaking of other irregularities, innerHTML=[invalid xml] throws an error and domparser makes an error element thingy

[21:29:45.0000] <eligrey>
so weird

[21:30:00.0000] <eligrey>
would be so much easier to handle if domparser just threw an error as well

[21:30:18.0000] <annevk>
eligrey: I suggest reading the topic of this channel

[21:30:51.0000] <eligrey>
alright, yeah i was just discussing stuff

[21:30:56.0000] <eligrey>
not asking for change

[21:31:13.0000] <annevk>
Yeah, I mean, I don't disagree, but compatibility is a real thing

[21:31:31.0000] <eligrey>
pretty sure domparser used to throw errors in all browsers except chrome

[21:31:38.0000] <eligrey>
and this parsererror thing is only a very recent addition

[21:31:53.0000] <annevk>
We hope of course that our generation designs better APIs and the folks five-fifteen years from now won't scream about the same irregularities

[21:32:06.0000] <annevk>
But they'll probably find lots to be upset about

[21:32:06.0000] <eligrey>
heh yeah

[21:32:41.0000] <annevk>
eligrey: given that <parseerror> has to be in some Mozilla-namespace I suspect it's pretty ancient at least for Firefox

[21:33:03.0000] <annevk>
And I also think the API might have originated there and then slowly copied by others

[21:33:05.0000] <eligrey>
hmm i remember back in 2009 implementing a text/html domparser shim

[21:33:21.0000] <eligrey>
and back then it was just chrome with <html:parsererrror> iirfc

[21:33:23.0000] <eligrey>
iirc*

[21:33:48.0000] <eligrey>
could be wrong though

[21:34:10.0000] <eligrey>
its a pretty cool feature outside of domparser though

[21:34:27.0000] <eligrey>
if you give parsererror a background image in css you can globally log xml well formedness errors on your site!

[21:34:33.0000] <eligrey>
(i did that on mine years ago)


2016-05-29
[18:28:11.0000] <MikeSmith>
https://github.com/w3c/deviceorientation/issues/30 “Malicious use of the phone's Gyroscope”

[20:56:49.0000] <Domenic>
This is an attack that requires physical access to the device... seems not too worrying

[01:13:08.0000] <MikeSmith>
Domenic: I can’t tell from the description but it mentions using a speaker so I assumed it only required proximity to the device, not direct access at least


2016-05-30
[00:15:58.0000] <annevk>
Took me long enough to realize the -N files in html/browsers/browsing-the-web/navigating-across-documents/ are supporting documents

[02:27:22.0000] <annevk>
Oh, git submodule update --init --recursive is listed in the documentation

[02:27:30.0000] <annevk>
I should try to remember that

[03:16:33.0000] <MikeSmith>
annevk: http://stackoverflow.com/questions/37522356/how-to-unify-retrieving-file-slices-supporting-both-file-api-and-xmlhttprequest

[03:19:15.0000] <MikeSmith>
also http://stackoverflow.com/questions/37522181/getting-the-http-status-code-for-a-failed-to-load-web-worker for anybody who might have a ready answer

[03:21:11.0000] <MikeSmith>
also is the answer at http://stackoverflow.com/questions/37521172/is-javascript-location-href-call-is-asynchronous actually correct?

[03:22:39.0000] <Ms2ger>
No

[03:23:40.0000] <MikeSmith>
OK well somebody should take the time to correct the person who posted it :)

[03:24:13.0000] <Ms2ger>
/me goes to find his password

[03:24:51.0000] <MikeSmith>
just have it send you an e-mail message with a reset link

[03:25:22.0000] <MikeSmith>
or actually I thought you could just link it to some other account

[03:26:18.0000] <MikeSmith>
anyway, I don’t remember half the passwords I use. I just reset them to something else every time I need to

[03:27:17.0000] <annevk>
I'm quite happy with 1Password

[05:47:30.0000] <MikeSmith>
zcorpan: please take a look at the error message for https://checker.html5.org/?doc=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%3C%2521doctype%2520html%3E%3Ctitle%3Etest%3C%252Ftitle%3E%3Cbody%3E%3Clink%2520rel%253Dicon%2520href%253Dfoo%3E and lemme know what you think

[05:47:44.0000] <MikeSmith>
e.g., is it too verbose

[05:49:32.0000] <MikeSmith>
or should we instead have it just emit a message like, “A link element with rel attribute whose value is “icon” must not appear as a descendant of a body element.”

[05:50:20.0000] <MikeSmith>
and similarly for other cases of rel in body where the the value is not dns-prefetch, pingback, preconnect, prefetch, prerender, or stylesheet

[05:50:40.0000] <MikeSmith>
I mean, have the message mention that the particular rel value used is not allowed

[05:51:15.0000] <MikeSmith>
vs instead mentioning what is allowed, like the message says now

[05:52:03.0000] <MikeSmith>
it seems to me it’s almost always better for users to mention what is allowed, but the messages can get a bit verbose

[06:06:56.0000] <zcorpan>
MikeSmith: looks good to me. it's not overly long and seems more helpful than just "foo is not allowed here"

[06:08:29.0000] <zcorpan>
MikeSmith: maybe s/must not appear as a descendant of a body element/is not allowed in body/ if you want it shorter

[06:09:16.0000] <MikeSmith>
yeah I was thinking that too (about “is not allowed” instead

[06:09:19.0000] <zcorpan>
MikeSmith: maybe the messages can have different styles for elements, attributes and values?

[06:09:38.0000] <MikeSmith>
no, it cannot currently

[06:09:49.0000] <MikeSmith>
well not without some ugly hackery

[06:10:07.0000] <MikeSmith>
on top of the ugly hackery already behind it

[06:10:26.0000] <zcorpan>
sure, i mean, an idea for better usability :-)

[06:10:35.0000] <MikeSmith>
yeah

[06:12:38.0000] <zcorpan>
is there something post-processing the messages to convert quotes to <code>s etc?

[06:24:38.0000] <zcorpan>
MikeSmith: src/nu/validator/messages/MessageEmitterAdapter.java ? seems like it could set a class attribute on the <code> depending on the text that preceded, if it was "element " or "attribute " (and then massage the messages to use that pattern consistently)?

[06:42:31.0000] <annevk>
wanderview: https://github.com/whatwg/fetch/issues/245#issuecomment-216822526

[06:42:48.0000] <annevk>
wanderview: https://github.com/whatwg/url/pull/123

[06:56:46.0000] <annevk>
zcorpan: maybe you can review https://github.com/whatwg/html/pull/1330 too?

[06:59:25.0000] <zcorpan>
annevk: sure, looking

[07:15:36.0000] <MikeSmith>
zcorpan: so the problem is that the codeString(…) logic that formats the code strings is format-agnostic; it is used for emitting the the gnu-formatted results and the JSON-formatted ones along with the HTML-formatted results

[07:15:47.0000] <MikeSmith>
zcorpan: so the place where I’d need to have it add a class value is https://github.com/validator/validator/blob/master/src/nu/validator/messages/XhtmlMessageTextHandler.java#L132

[07:18:03.0000] <MikeSmith>
so I guess what I would need to do is add a param to that method in the class in inherits from, with a value of the param being the type of code (element, attribute, or value). And the non-HTML emitters would just not do anything with that param

[07:22:15.0000] <MikeSmith>
but still even if I did that I have to do a bunch more to even be able to hook into that, because as far as “depending on the text that preceded”, the logic does not keep state information about what text preceded what. It doesn’t actually even work from normal strings as a unit but instead from character arrays.

[07:23:25.0000] <MikeSmith>
so anyway, would not be straightforward at all to do it in the backend, but I think it might be in the JavaScript frontend code and a vaguely recall I have it doing something similar there already for something

[07:26:09.0000] <zcorpan>
MikeSmith: ok. i'm sure you can figure something out :-)

[07:26:39.0000] <nox>
Did anyone try to specify LenientFloat?

[07:27:08.0000] <zcorpan>
MikeSmith: another option is to use different characters earlier in the pipeline to differentiate

[07:27:34.0000] <nox>
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=19988)

[07:29:53.0000] <zcorpan>
nox: cssom-view uses unrestricted double in some places and converts non-finite values to 0 (for compat with "long")

[07:30:14.0000] <nox>
zcorpan: Well, could have two behaviours like TreatNullAs

[07:30:24.0000] <nox>
(Or whatever is its name, can't remember.)

[07:30:28.0000] <zcorpan>
yeah

[07:30:38.0000] <zcorpan>
i suppose this hasn't happened yet

[07:38:11.0000] <zcorpan>
Should we make this no longer a parse error? <!----------------------->

[09:25:39.0000] <Domenic>
interesting

[09:25:42.0000] <Domenic>
why was it a parse error?

[09:27:11.0000] <annevk>
Presumably the SGML thing?

[09:28:25.0000] <gsnedders>
yeah, the fact it wasn't compatible with legacy UAs post-Acid2, AFAIK

[09:43:27.0000] <Domenic>
like, old browsers would blow up in some way? how old?

[09:45:18.0000] <gsnedders>
Domenic: post-Acid2, pre-HTML5 parser

[09:45:33.0000] <Domenic>
that's not really meaningful to me...

[09:45:52.0000] <gsnedders>
mid-00 to late-00s?

[09:46:03.0000] <Domenic>
hmm hmm

[09:46:18.0000] <Domenic>
so maybe ie8 still blows up or something

[09:46:37.0000] <gsnedders>
Acid2 had an SGML comment parsing test, because Hixie_

[09:47:03.0000] <gsnedders>
http://ln.hixie.ch/?start=1137799947&count=1

[09:50:04.0000] <annevk>
So many lessons in that post we now take for granted

[09:53:42.0000] <tantek>
hah - somehow I totally missed that post

[09:54:17.0000] <tantek>
darn, 404: http://people.bath.ac.uk/py8ieh/internet/eviltests/comments-evil.html

[09:56:39.0000] <annevk>
tantek: http://www.hixie.ch/tests/evil/mixed/comments-evil.html

[09:57:03.0000] <annevk>
tantek: I guess bath.ac.uk finally upgraded Apache and no longer kept Ian's old redirects

[09:59:08.0000] <tantek>
I'm pretty sure we fixed that in Tasman (IE5/Mac) too back in the day, because of the thoroughness of all the rest of Hixie's tests.

[10:00:24.0000] <annevk>
Kinda weird Ian never got an award of sorts for advancing testing and standards practices as much as he has

[10:01:33.0000] <tantek>
annevk: hah, he & I were awarded with organizing a whole panel on best test suite practices at TPAC 2004 where we got to call out so many W3C test suites for being bad (or a few good) examples

[10:02:40.0000] <annevk>
Oh man, W3C is notoriously bad at this

[10:02:49.0000] <annevk>
I got "recognized" twice

[10:02:49.0000] <tantek>
hah - they used to be MUCH worse

[10:03:14.0000] <tantek>
annevk - though I'd say both Hixie and dbaron - their tests for CSS etc. back in that time period were amazingly useful at advancing interop, especially for new/emerging features

[10:03:14.0000] <annevk>
I got a paper signed by timbl et al for being on the W3C TAG, and for being a Chair of the Notifications WG

[10:03:28.0000] <annevk>
A decade of contributing to standards? Meh

[10:03:52.0000] <tantek>
hmm that makes me think

[10:04:46.0000] <annevk>
Yeah, that coupled with the unfortunately belated insight that standards can change, is what really changed the whole game

[10:05:51.0000] <tantek>
annevk: sure. I mean it took long enough to realize that we could actually *fix* CSS2 (in a non-spec-back-compat way)

[10:05:52.0000] <annevk>
If they had figured that out sooner, margin collapsing and inline text layout would be somewhat easier to grok

[10:06:27.0000] <tantek>
I'm not sure there was anything sane we could have done about margin collapsing after CSS1 "shipped".

[10:06:46.0000] <tantek>
(even with hindsight, it seems like an unsolveable mess)

[10:07:05.0000] <tantek>
(and we had zero chance of *eliminating* margin collapsing)

[10:07:30.0000] <annevk>
From talking to Hixie_ the problem was preserving as much as possible of the incompatible CSS2 invariants while also being compatible with browsers

[10:07:44.0000] <annevk>
Rather than just tossing CSS2 out of the window

[10:08:03.0000] <tantek>
um, we actually did toss much (most?) of CSS2 out the window when writing up CSS2.1

[10:08:21.0000] <tantek>
and trying to pick the sane(r) things (most) browsers agreed on

[10:08:43.0000] <tantek>
a lot of the methodologies we take for granted today about evolving specs based on implementations came from that effort

[10:09:30.0000] <tantek>
granted, we could have probably tossed even more out of CSS2(.1) but we were still "new" at this at the time and still learning how far we could push things

[10:12:24.0000] <annevk>
Yeah, that's the story I remember for margin collapsing, that it could have been made much simpler if only Hixie_ and dbaron had realized sooner CSS 2.0 was not holy

[10:13:29.0000] <tantek>
there was no chance of any such realization as long as the creators of CSS1 were firmly re-emphasizing the "correctness" of vertical margin collapsing as an author-friendly model of block flow layout

[10:19:17.0000] <dbaron>
I think we could have eliminated the margins-collapsing-through-blocks thing, which was the biggest mistake there.

[10:21:24.0000] <tantek>
agreed. I really disliked that we kept that in particular. :/

[10:35:31.0000] <gsnedders>
/me got caught out by that again a few days ago…

[10:35:39.0000] <gsnedders>
and it's not like I don't know a lot of this stuff well.

[10:47:35.0000] <annevk>
Enabling Travis has been great

[10:50:47.0000] <Domenic>
:)


2016-05-31
[17:51:21.0000] <MikeSmith>
is “Content-Type:text/html; name="canvas-dashed-line.html"; charset=” valid syntax?

[17:52:30.0000] <scshunt>
MikeSmith: no

[17:52:49.0000] <scshunt>
MikeSmith: you need to have a value for charset=

[17:52:50.0000] <MikeSmith>
scshunt: ok, didn’t think so

[17:52:52.0000] <MikeSmith>
yeah

[17:52:56.0000] <scshunt>
although you shouldn't have a charset on text/html anyway

[17:53:15.0000] <MikeSmith>
eh?

[17:53:30.0000] <scshunt>
and "name" is an invalid parameter

[17:53:38.0000] <MikeSmith>
OK

[17:54:57.0000] <scshunt>
it's now considered bad form to use a charset parameter for types that provide ways to determine the charset from the body

[17:55:10.0000] <scshunt>
text/html does still permit this though

[17:56:09.0000] <MikeSmith>
interesting

[17:56:18.0000] <MikeSmith>
didn’t know that

[17:56:24.0000] <scshunt>
https://tools.ietf.org/html/rfc6657

[17:56:54.0000] <MikeSmith>
text/html needs it for parsing with the right charset, and I would think other types would need it as well

[17:57:09.0000] <MikeSmith>
btw, that header seems to be getting set automatically by bugzilla.mozilla.org

[17:57:20.0000] <MikeSmith>
/me looks at https://tools.ietf.org/html/rfc6657

[17:57:34.0000] <scshunt>
if you need a charset parameter, then use it

[17:57:40.0000] <scshunt>
:)

[17:57:45.0000] <scshunt>
but yeah, charset= is definitely not correct

[17:58:16.0000] <MikeSmith>
ok

[17:58:30.0000] <scshunt>
http://www.iana.org/assignments/media-types/text/html does not allow "name" as a parameter

[17:58:41.0000] <scshunt>
(but it should be ignored rather than treated as an error)

[17:59:04.0000] <MikeSmith>
yeah that header is causing the content-type parser in the HTML checker to fail in an unexpected with (java.lang.StringIndexOutOfBoundsException: String index out of range)

[17:59:15.0000] <MikeSmith>
ok

[19:16:08.0000] <MikeSmith>
wow a rare Dmitry Turin reference https://mailarchive.ietf.org/arch/msg/webpush/Al5xy2qQOBxXMrnE-SCKjUt-SJU

[19:51:16.0000] <MikeSmith>
http://stackoverflow.com/questions/37528006/detecting-that-a-web-worker-has-been-loaded-without-sending-an-explicit-message

[23:20:41.0000] <annevk>
MikeSmith: answered

[23:36:16.0000] <MikeSmith>
annevk: thanks

[23:42:45.0000] <mathiasbynens>
is https://encoding.spec.whatwg.org/ down/flaky for anyone else?

[23:50:17.0000] <annevk>
mathiasbynens: yeah, but others are too...

[23:58:25.0000] <annevk>
mathiasbynens: seems things are back up again

[23:59:31.0000] <mathiasbynens>
hmm, not for me, at least not consistently

[00:01:14.0000] <annevk>
mathiasbynens: hmm, maybe some kind of DDOS?

[00:02:04.0000] <annevk>
Or just DOS, I think Hixie_ pays for computing power, so if there's a spike that might just cause things to grind to a halt

[03:10:47.0000] <daleharvey>
Anyone on the spec side want to talk about the implementation of Notifications actions?

[03:12:00.0000] <daleharvey>
mostly looking around for examples, code or other right now, I am guessing this is trying to do something like what spotify or okta / oauth does with notifications, ie let you play / pause, approve / reject from within the notification?

[03:49:32.0000] <Ms2ger>
annevk, does a Location have an associated Document or Window? (Or WindowProxy?)

[03:53:16.0000] <annevk>
Ms2ger: that is defined, no?

[03:55:10.0000] <annevk>
daleharvey: that's the idea, yes

[03:55:19.0000] <annevk>
daleharvey: basically a notification with a set of buttons

[03:55:48.0000] <annevk>
daleharvey: the buttons representing the actions, which can be activated somehow

[03:56:06.0000] <annevk>
daleharvey: if you'd like an example in the specification I'm afraid you'll have to PR it or file an issue

[04:04:46.0000] <annevk>
Ms2ger: "Each Window object is associated with a unique instance of a Location object, allocated when the Window object is created."

[04:05:38.0000] <annevk>
Ms2ger: "A Location object has an associated relevant Document, which is this Location object's associated Document object's browsing context's active document."

[04:10:14.0000] <Ms2ger>
annevk, hrm, I vaguely remembered that location was hanging off the WindowProxy, but I guess that was wrong, then

[04:12:47.0000] <annevk>
Ms2ger: yeah, that'd make it very hairy

[04:44:52.0000] <Ms2ger>
Anyone who could check http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4244 in any of Edge/IE/Safari?

[04:49:06.0000] <rodneyre_>
Ms2ger anything particular to check for?

[04:49:23.0000] <Ms2ger>
Tell me what's logged :)

[04:49:33.0000] <rodneyre_>
copy to here or a gist?

[04:51:13.0000] <Ms2ger>
Just paste the three first lines here

[04:51:15.0000] <rodneyre_>
https://gist.github.com/rodneyrehm/f64c8de6d2f47c26fc6c129242012afc

[04:51:24.0000] <Ms2ger>
Or that :)

[04:51:49.0000] <Ms2ger>
Three browsers, three results

[04:51:55.0000] <rodneyre_>
I can check edge and ie in a few…

[04:52:05.0000] <Ms2ger>
That would be nice too

[04:52:13.0000] <rodneyre_>
no access to browserstack?

[04:52:46.0000] <Ms2ger>
Nope

[04:52:55.0000] <Ms2ger>
Asking here has worked well enough in the past :)

[04:56:43.0000] <annevk>
Ms2ger: you can ask jst, but I guess the #whatwg proxy works too

[05:02:40.0000] <rodneyre_>
bah, I can't copy from edge in browserstack, hmpf

[05:09:14.0000] <rodneyre_>
Ms2ger updated the gist with IE11 and Edge14

[05:09:44.0000] <annevk>
Ah okay, so that's not just me

[05:09:52.0000] <annevk>
It gives the impression copy & paste works

[05:10:18.0000] <Ms2ger>
Yay, they agree with Fx

[05:12:35.0000] <Ms2ger>
rodneyre_, thanks

[07:53:27.0000] <nox>
Is the interface 'Elements' dead?

[08:00:14.0000] <annevk>
nox: for now

[08:00:28.0000] <nox>
Ah.

[08:00:35.0000] <nox>
annevk: Is it a live collection btw?

[08:01:12.0000] <annevk>
nox: no, Array subclass

[08:01:22.0000] <nox>
annevk: Woooo.

[08:17:24.0000] <nox>
annevk: When can that be integrated back?

[08:17:45.0000] <nox>
annevk: I was wondering with another Servo developer what React uses to build list of elements,

[08:17:50.0000] <nox>
and if it could avoid live collections,

[08:17:54.0000] <nox>
then I remembered about Elements.

[08:18:06.0000] <annevk>
nox: IDL-subclassing support

[08:18:19.0000] <nox>
Couldn't it just be [ArrayClass] or something?

[08:18:37.0000] <annevk>
No

[08:18:47.0000] <nox>
What's the difference?

[08:19:02.0000] <annevk>
Hmm, later/tomorrow

[08:19:06.0000] <nox>
(TIL ArrayClass became LegacyArrayClass.)

[08:19:08.0000] <nox>
annevk: Sure!

[09:45:54.0000] <annevk>
nox: ArrayClass puts Array on the prototype chain, but doesn't make the object an actual Array

[09:46:01.0000] <nox>
Oh ok.

[09:46:38.0000] <annevk>
wanderview: structured cloning the JSON and passing it back and forth sounds a lot slower

[09:46:44.0000] <annevk>
wanderview: since it needs to be serialized and deserialized

[09:47:14.0000] <wanderview>
annevk: we wouldn't actually do this in a real worker... we would make the parse go to an AST representation that gets rehydrated on js thread when done

[09:47:21.0000] <wanderview>
so just deserialize overhead

[09:47:49.0000] <annevk>
wanderview: but deserialize isn't that different from parsing in the first place I'd think

[09:48:40.0000] <wanderview>
annevk: it really depends where the costs come from... parsing the string?  or js object allocation?

[09:48:44.0000] <annevk>
wanderview: in any event, has someone made a convincing case this is important? It seems like we should just wait for async-JSON to be a thing and ride the coattails

[09:49:17.0000] <wanderview>
annevk: did I say we were doing something about it today?

[09:49:37.0000] <annevk>
wanderview: I don't think you did

[09:50:07.0000] <wanderview>
annevk: I think waiting for async json spec would be good as well: https://twitter.com/wanderview/status/737684000613879808

[09:51:19.0000] <annevk>
I wonder why that thread blew up a bit though, maybe just because the real reason it's async wasn't mentioned

[09:55:16.0000] <wanderview>
annevk: yea, I don't know... its not like any browser implements an optimization here

[09:55:56.0000] <annevk>
spec is sync too, though of course blackbox optimizations allowed

[09:56:51.0000] <annevk>
but there's all kinds of rather absurd optimizations possible here

[09:57:15.0000] <annevk>
e.g., you could go from bytes straight to an object structure, decoding the strings in parallel

[09:58:01.0000] <wanderview>
annevk: I'm more excited to learn today that edge has implemented ReadableStream already

[09:58:43.0000] <annevk>
wanderview: nice, hopefully there's tests

[10:37:27.0000] <Domenic>
It seems like a lot of the spam we get on HTML is probably via the "File an issue about the selected text" link. Given that it always contains a random multipage URL with a fragment.

[10:37:47.0000] <Domenic>
I can't understand how this would work though. Some kind of web crawler bot that has a GitHub account and also pushes the submit button?

[10:42:05.0000] <MikeSmith>
Domenic: dunno but yeah I am confused by that as well

[10:44:33.0000] <tantek>
the bots are getting smarter

[14:54:20.0000] <smaug____>
hmm, why BlobPart uses USVString

[14:57:47.0000] <smaug____>
oh, it doesn't work at all how I expected

[14:58:05.0000] <jsbell>
Expecting ByteString behavior perhaps?

[15:01:03.0000] <smaug____>
yeah, something closer to that. I was expecting it to take DOMString

[15:21:18.0000] <Garbee>
Domenic: Sadly the unit testers we have like PhantomJS that run on engine cores also make more capable spam bots all too easy to build as well.

[15:21:38.0000] <Garbee>
And Selenium, et. all.