2014-06-01
[02:12:25.0000] <Ms2ger>
JavaScript error: http://www.whatwg.org/specs/web-apps/current-work/updater.js, line 71: configUI is null

[02:12:26.0000] <Ms2ger>
JavaScript error: http://www.whatwg.org/specs/web-apps/current-work/status.js, line 1155: configUI is null

[03:36:24.0000] <Ms2ger>
Wow

[03:36:32.0000] <Ms2ger>
SVG2 points at http://www.w3.org/TR/Window/#embeddingelt

[03:41:38.0000] <jgraham>
:-o

[09:09:54.0000] <annevk>
I wish there was an @antimattursource account

[09:11:18.0000] <Ms2ger>
Nice explanation of script/async/defer: http://peter.sh/experiments/asynchronous-and-deferred-javascript-execution-explained/

[09:11:36.0000] <annevk>
http://about.monash/#tlds lol

[09:11:47.0000] <annevk>
Ms2ger: yeah, filed a bug on HTML to include it just now

[09:11:54.0000] <Ms2ger>
/me approves

[09:11:55.0000] <Ms2ger>
Btw

[09:11:57.0000] <annevk>
Ms2ger: provided beverloo_ approves

[09:12:20.0000] <Ms2ger>
It seems like data url parsing still needs work?

[09:12:35.0000] <annevk>
Ms2ger: you think?

[09:12:40.0000] <annevk>
;-)

[09:13:02.0000] <annevk>
First thing tomorrow is data URL security boundaries

[09:13:23.0000] <Ms2ger>
Mm

[09:13:26.0000] <Ms2ger>
Rather you than me :)

[09:13:41.0000] <annevk>
Need to get the exchange with sicking into specifications and Gecko

[09:14:02.0000] <annevk>
As for data URL parsing, I still have hopes someone else will pick that up

[09:15:04.0000] <Ms2ger>
There's http://simonsapin.github.io/data-urls/

[09:15:46.0000] <Ms2ger>
/me would like to have another 24 hours a day for spec work

[10:13:22.0000] <SimonSapin>
"For users, it will mean greater security, a better user experience, more useful searches, and improved navigation." New TLDs are magical, it seems.

[10:35:52.0000] <Hixie>
does html5lib support <template>? and if so, does it do anything special with its contents, or does it just put the template contents as children of the <template> itself?

[10:40:40.0000] <Ms2ger>
I'd be somewhat surprised

[11:55:38.0000] <jgraham>
Hixie: Not unless gsnedders landed something I forgot about

[13:26:38.0000] <zewt>
... why do people keep using "```js" forum/tracker markup on mailing lists all of a sudden? are people posting from a broken forum/list gateway or something? heh

[13:29:50.0000] <caitp->
because we know that you're probably familiar with gfm and understand how you're supposed to understand it

[13:30:34.0000] <zewt>
it's markup, you don't write markup with humans as the audience (and we all know how to interpret javascript in an email)

[13:31:17.0000] <caitp->
inboxapp.co might prettify gfm codeblocks in emails on its own some day

[13:32:25.0000] <zewt>
i'd sure hope not, it'd break "email interop" with the rest of the universe

[13:32:44.0000] <caitp->
email interop has already broken

[13:33:10.0000] <zewt>
"the system isn't perfect, therefore it's okay to do anything" no

[13:34:24.0000] <caitp->
nobody is working to improve email really, there aren't very many competing email clients, so people can pretty much do whatever they want with it

[13:40:03.0000] <zewt>
"can" and "should" are very different things

[13:43:41.0000] <caitp>
i'm sure the folks reading email on their 5250 terminals might be less happy about it, but for people who aren't living in the 70s it's great

[13:43:47.0000] <caitp>
nice readable code, beautiful

[13:44:03.0000] <zewt>
...

[13:44:33.0000] <zewt>
itym 'folks using an email client that isn't "inboxapp.co"'

[13:44:56.0000] <caitp>
i'm sure there's a chrome extension to make gmail render gfm, and if there isn't it would be trivial to write

[13:45:05.0000] <zewt>
uhh

[13:45:05.0000] <caitp>
or a thunderbird plugin

[13:45:58.0000] <zewt>
writing emails with the expectation that everyone else is going to install a browser plugin for them to be formatted correctly would be pretty absurd

[13:46:26.0000] <caitp>
even without browser plugins, it's still designating that a block of text is code, and designating the language the code is in

[13:46:33.0000] <caitp>
so I think it's still pretty easy to reason about

[13:52:14.0000] <SamB>
as long as it looks okay in gnus out-of-the-box

[13:56:36.0000] <jgraham>
/me wonders what gfm is

[13:56:57.0000] <caitp>
github's extensions to markdown

[13:57:17.0000] <caitp>
the f is for "flavoured"

[13:57:33.0000] <caitp>
the g and m should be self explanatory

[13:59:04.0000] <jgraham>
Oh right. Their random additions to a poorly-specified markup format. I'm not sure that I would want that as the basis for anything.

[13:59:36.0000] <caitp>
hey, you could always form a w3c community working group for it ;)

[14:00:06.0000] <caitp>
for all that would accomplish --- realistically, it's there, and it's ubiquitous, so people use it

[14:00:34.0000] <jgraham>
It's pretty absurd that you are calling it "ubiquitous" just after you had to explain to me what it was

[14:00:46.0000] <caitp>
ubiquity doesn't mean everyone has heard of it

[14:01:41.0000] <caitp>
but it's used heavily on the most popular public and private repository host, and has found its way into mailing lists, jira, and bugzilla too

[14:01:47.0000] <caitp>
so, it's all over the place

[14:05:59.0000] <jgraham>
I can't see any evidence that bugzilla or Jira have GitHub extensions to markdown.

[14:07:26.0000] <caitp>
I know bugzilla won't render GFM, but GFM is used on bugzilla now and again

[14:07:51.0000] <caitp>
atlassian products support variations on it

[14:07:51.0000] <caitp>
etc

[14:10:32.0000] <jgraham>
That seems like a substantially different claim

[15:00:26.0000] <zewt>
(i certainly don't know what it is, i just assumed "something something markup")

[15:01:14.0000] <zewt>
(gfm are my initials, but that seemed improbable)

[15:21:14.0000] <gsnedders>
Hixie: no, we don't support template. plan was just to put stuff as the children of the template itself

[15:51:48.0000] <Hixie>
gsnedders: k. i guess i'll do the same in my library.

[15:53:20.0000] <SamB>
jgraham: I guess you don't like patched versions of org-mode either ;-P


2014-06-02
[00:29:28.0000] <AxaliaN>
Hi all

[00:29:35.0000] <AxaliaN>
any autoconfirmed member active?

[00:31:16.0000] <AxaliaN>
annevk?

[00:39:40.0000] <AxaliaN>
zcorpan is a confirmed member, right?

[00:40:21.0000] <zcorpan>
member of what?

[00:40:31.0000] <AxaliaN>
thwe wiki :P

[00:40:33.0000] <AxaliaN>
the*

[00:40:43.0000] <zcorpan>
no idea :-)

[00:40:49.0000] <AxaliaN>
:P

[00:41:06.0000] <AxaliaN>
The wiki says it to be so!

[00:41:47.0000] <zcorpan>
then i guess so. how can i hlep?

[00:42:12.0000] <AxaliaN>
Anyhoo; there's a meta extension that needs to be added to the wiki

[00:42:25.0000] <AxaliaN>
hwo does one go about doing that?

[00:42:27.0000] <AxaliaN>
how*

[00:43:40.0000] <zcorpan>
/me looks at http://wiki.whatwg.org/wiki/WHATWG_Wiki:How_to_create_a_user_account

[00:44:03.0000] <AxaliaN>
Ah, I just saw you needed to come on IRC and ask :P

[00:44:38.0000] <zcorpan>
AxaliaN: username? email? (pm if you like)

[00:44:40.0000] <AxaliaN>
Problem 1, I am not an autoconfirmed member :P

[00:44:42.0000] <AxaliaN>
ok

[00:48:20.0000] <zcorpan>
ok created

[00:48:44.0000] <AxaliaN>
Awesome, thanks :)

[00:48:48.0000] <zcorpan>
np

[02:24:14.0000] <annevk>
zcorpan: does Chrome workers deal with data URLs?

[02:24:23.0000] <annevk>
s/does/do/

[02:25:30.0000] <zcorpan>
seems not http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3046

[02:25:52.0000] <zcorpan>
i think blob works though

[02:26:41.0000] <zcorpan>
at least for dedicated, dunno about shared

[02:38:05.0000] <annevk>
blob is fine as they have an origin

[02:38:58.0000] <zcorpan>
do you want to drop data url for workers?

[02:40:52.0000] <annevk>
yes

[02:41:08.0000] <annevk>
zcorpan: see WHATWG list

[02:41:35.0000] <annevk>
zcorpan: we want to make data URLs an opt-in

[02:43:39.0000] <zcorpan>
ok cool, would love to get interop on data urls :-)

[02:43:59.0000] <annevk>
I think we have a plan that works now

[02:44:13.0000] <zcorpan>
i think workers support data urls because blob didn't exist back then

[02:45:14.0000] <annevk>
well back then we didn't have a plan for data URLs that everyone agreed upon

[02:45:33.0000] <annevk>
I wish Google pushed their concerns with regards to them a bit harder at the time

[02:45:37.0000] <annevk>
oh well

[02:45:40.0000] <zcorpan>
do everyone agree on a plan now?

[02:46:57.0000] <annevk>
zcorpan: we're aligning with Chrome on <iframe> and hopefully workers

[02:47:38.0000] <annevk>
zcorpan: I guess I'm hopeful that's the case, haven't actually seen it confirmed

[02:47:49.0000] <zcorpan>
annevk: what about <track>?

[02:48:20.0000] <annevk>
zcorpan: seems like that can work as there are no side effects, right?

[02:49:04.0000] <zcorpan>
annevk: webvtt seems safe enough, but i'm not confident we can keep it to webvtt-only :-(

[02:49:26.0000] <annevk>
bah

[02:50:04.0000] <zcorpan>
there are some tests that use data: for <track> but that's easy to fix

[02:50:42.0000] <annevk>
zcorpan: yeah dunno, it's safe for XHR and <img>

[02:50:52.0000] <annevk>
zcorpan: I would say it should be safe for <track>

[02:51:00.0000] <annevk>
zcorpan: otherwise we might have some issues with that going forward

[02:51:11.0000] <annevk>
zcorpan: whether data URLs are allowed or not

[02:53:17.0000] <zcorpan>
i think chrome doesn't allow data: for <track> but i don't know if that's just a result of the default policy or if it's deliberate

[02:54:37.0000] <annevk>
I'm gonna add a flag to Fetch tomorrow or so and also change the text around data URLs

[02:57:47.0000] <tobie>
annevk: was wondering whether you were aware of https://code.google.com/p/chromium/issues/detail?id=362214 and https://sites.google.com/a/chromium.org/dev/Home/chromium-security/security-faq?pli=1#TOC-Which-origins-are-secure

[02:58:11.0000] <tobie>
annevk: and whether that's something you were considering to add to Url.

[02:58:49.0000] <tobie>
annevk: given there seems to be interest to implement something similar at Mozilla.

[03:01:30.0000] <annevk>
tobie: I have some vague plans on taking over the remaining bits of the Web Origin RFC and stick 'm in some existing spec

[03:01:54.0000] <tobie>
I see.

[03:01:58.0000] <annevk>
tobie: Origin header is already obsoleted by Fetch, URL could define some of the origin serialization algorithms

[03:05:03.0000] <tobie>
makes sense.

[03:08:32.0000] <annevk>
tobie: oh btw, https://w3c.github.io/webappsec/specs/mixedcontent/ will define the secure origin thing most likely

[03:09:02.0000] <annevk>
tobie: Mike West and I have discussed on how to add hooks to Fetch for that and such

[03:09:28.0000] <annevk>
tobie: so that e.g. https to http will return a network error, and other such goodies

[03:09:53.0000] <tobie>
I'll have a look at that. Thanks for the pointer.

[03:32:48.0000] <annevk>
zcorpan: where does <object> pay attention to response's status?

[03:32:59.0000] <annevk>
zcorpan: are you confused with Content-Type?

[03:33:20.0000] <annevk>
zcorpan: although <img> pays attention to that, so maybe I'm missing something

[03:33:39.0000] <zcorpan>
annevk: the spec's default is to pay attention to it (since http requires it)

[03:33:42.0000] <zcorpan>
annevk: <img> opts out

[03:34:06.0000] <annevk>
"HTTP requires it"? What does that even mean?

[03:34:06.0000] <zcorpan>
it's possible that all other features but <object> should be like <img>, i don't know

[03:36:04.0000] <annevk>
E.g. currently 401 requires an authentication dialog for features that opt-in (which due to legacy is all of them, except for a couple new ones)

[03:36:36.0000] <annevk>
But I don't think we've established a list of codes that a response has to treat as if it received a network error unless it opts in/out of that

[03:36:49.0000] <annevk>
s/codes/statuses/

[03:37:14.0000] <zcorpan>
i dunno. i mean the spec in general treats 404 like network error rather than like 200 OK

[03:37:26.0000] <zcorpan>
lunch

[03:42:39.0000] <annevk>
zcorpan: but is that actually true in implementations?

[03:42:44.0000] <annevk>
zcorpan: I seriously doubt it

[03:48:04.0000] <caitp>
it doesn't seem to be true in chromium

[04:12:59.0000] <zcorpan>
caitp: what did you test?

[04:13:18.0000] <beverloo_>
annevk, image is public domain/cc0, go for it :-) (can't find my bugzilla details)

[04:16:59.0000] <caitp>
zcorpan: if you try to load a document which results in a network error, you won't actually have the document opene, instead the browser will render some data:text/html,... to tell you about the network error

[04:17:11.0000] <caitp>
which is not true of 404

[04:18:04.0000] <zcorpan>
caitp: so you tested navigating top-level browsing context?

[04:18:39.0000] <caitp>
yes

[04:18:52.0000] <zcorpan>
ok, well that's not so interesting

[04:19:21.0000] <annevk>
beverloo_: cool

[04:19:22.0000] <zcorpan>
more interesting is what does <embed src> do, what does <link rel=stylesheet href> do, what does <video src> do, what does <script src> do, etc

[04:19:42.0000] <caitp>
i'm interested in an example where a 404 would be treated as a network error, with the exception of weird behaviour of webviews on certain mobile platforms

[04:20:11.0000] <caitp>
or file:// scheme requests

[04:20:32.0000] <zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3047

[04:24:36.0000] <caitp>
> If the load failed (e.g. there was an HTTP 404 error, there was a DNS error), fire a simple event named error at the element, then jump to the step below labeled fallback.

[04:25:00.0000] <caitp>
so that part of the spec is saying treat 404 as the same as a particular network error

[04:25:05.0000] <caitp>
but that's not "http"

[04:26:03.0000] <caitp>
it's a particular behaviour of a particular html tag

[04:28:07.0000] <annevk>
zcorpan: interesting

[04:28:35.0000] <zcorpan>
caitp: yeah

[04:31:03.0000] <zcorpan>
seems <embed> is like <img> per spec

[04:31:46.0000] <annevk>
zcorpan: it would be interesting to know what status codes that was triggered with

[04:32:10.0000] <caitp>
in the cases of these elements it might make sense, because you probably don't want to render some domain's particular fancy 404 response

[04:32:29.0000] <caitp>
but it's not the same as saying "in http, 404 is a network error"

[04:33:11.0000] <caitp>
that's the point I'm making, that's all :>

[04:33:17.0000] <zcorpan>
i said "in html" not "in http" :-P

[04:33:25.0000] <caitp>
i could have sworn you said in http

[04:33:56.0000] <zcorpan>
i said "the spec" but i was referring to the html spec, not the http spec

[04:34:11.0000] <caitp>
  <zcorpan> annevk: the spec's default is to pay attention to it (since http requires it) ... ]  <annevk> "HTTP requires it"? What does that even mean?

[04:34:34.0000] <caitp>
it is very early in the morning here, though

[04:34:42.0000] <caitp>
no coffee yet =)

[04:37:43.0000] <caitp>
  <zcorpan> i dunno. i mean the spec in general treats 404 like network error rather than like 200 OK

[04:37:43.0000] <caitp>
 ok I see what you're saying

[04:38:09.0000] <caitp>
conflated that with the earlier mention of "http requires it"

[04:40:35.0000] <annevk>
Hmm, I find HTML very vague on this subject. Somewhat clear for 404, but there's a ton of other response codes

[04:43:15.0000] <caitp>
it would probably apply to all of the non-200s (with the exception of things like 302)

[04:43:41.0000] <caitp>
and probably not 204 either

[04:44:20.0000] <annevk>
At that point 3xx are already handled

[04:44:33.0000] <annevk>
Maybe not 304, that depends a bit

[04:44:49.0000] <annevk>
But yes, I think that's the approach CORS takes.

[04:45:25.0000] <annevk>
http://fetch.spec.whatwg.org/#cors-preflight-fetch This does not even consider 304

[04:45:44.0000] <annevk>
I guess we should consider that flattened at that point since it's an HTTP cache lookup

[07:08:40.0000] <darobin>
does anyone implement document.origin?

[07:17:05.0000] <annevk>
dunno

[07:17:20.0000] <annevk>
they should

[07:20:12.0000] <darobin>
annevk: apparently, no one at this point

[07:20:18.0000] <darobin>
though I'll admit I haven't checked Servo

[07:20:49.0000] <annevk>
file bugs

[07:21:07.0000] <annevk>
or create a test

[07:40:36.0000] <Ms2ger>
darobin, not Servo either, patch welcome ;)

[09:45:51.0000] <dglazkov>
good morning, Whatwg!

[12:51:05.0000] <zewt>
fascinating bug title: "Specify the Event Loop integration for various non-deprecated events"

[14:13:11.0000] <IZh>
The bug needs to be Hixied. ;-)

[14:15:13.0000] <caitp>
that could be interpreted in so many different ways, hmm

[14:15:50.0000] <IZh>
Fixed :-)

[14:17:10.0000] <caitp>
oscar wilde would have a field day

[15:46:08.0000] <zewt>
does that mean "specify the things that need to be specified and not just the ones I like"

[16:54:31.0000] <slightlyoff>
hey annevk, wanted to  chat about fetch API

[16:54:40.0000] <slightlyoff>
specifically about isSynchronous in the API

[16:54:48.0000] <slightlyoff>
and the body property

[16:55:27.0000] <slightlyoff>
we'd talked about a toBlob() on the response to hand back a promise or similar so that we can get out of the contract that requires synchronous reification


2014-06-03
[17:30:59.0000] <zewt>
dear microsoft: stop deliberately ignoring the vocabulary of the entirely software industry and using your own

[17:31:06.0000] <zewt>
re: calling localization "globalization"

[17:32:36.0000] <a-ja>
g12n

[17:33:00.0000] <zewt>
:|

[17:34:06.0000] <a-ja>
erm...g11n

[22:46:48.0000] <annevk>
hey slightlyoff

[22:47:06.0000] <annevk>
slightlyoff, isSynchronous was mostly about exposing what the main thread was doing

[22:47:17.0000] <annevk>
slightlyoff: e.g. if you want to log synchronous XHR requests

[22:47:28.0000] <annevk>
slightlyoff: it's not mutable

[22:48:10.0000] <annevk>
slightlyoff: and I'm totally with you on asynchronous access to .body, .toBlob() seems a bit ugly though, I wonder if we can do better

[22:49:30.0000] <annevk>
slightlyoff: feel free to file tickets somewhere on me

[23:16:56.0000] <zcorpan>
annevk: allowsameorigindataurl is quite long. any reason allowdataurl doesn't work?

[23:17:46.0000] <annevk>
zcorpan: other than not being quite as clear, can't really think of anything

[23:19:06.0000] <zcorpan>
i'm not convinced it's clear to people what "same-origin data url" means

[23:48:25.0000] <karlcow>
allowsameorigindataurlandreadthespecifyoudontunderstandwhatitmeans

[23:49:34.0000] <annevk>
karlcow: you had to abbreviate specification?

[23:50:01.0000] <karlcow>
hmm good point, this leads to ambiguity. I need to fix that ;)

[00:31:52.0000] <annevk>
tobie: only Map.prototype.set seems to return this

[00:32:03.0000] <annevk>
tobie: in any event, seems like a separate issue from how to represent headers

[00:40:06.0000] <annevk>
Oh, Safari has IndexedDB and SPDY now

[01:07:10.0000] <JakeA>
annevk: slightlyoff: There's a ticket on the toBlob stuff https://github.com/slightlyoff/ServiceWorker/issues/251

[01:07:58.0000] <JakeA>
I still kinda like .to(type)

[01:26:12.0000] <annevk>
JakeA: bodyAs(type) maybe?

[01:26:30.0000] <annevk>
JakeA: seems so weird to not name the member

[01:28:20.0000] <annevk>
JakeA: you back from the protests now?

[01:28:28.0000] <annevk>
JakeA: would be great to nail down this API

[01:28:45.0000] <annevk>
JakeA: headers and body are the main difficulties

[01:34:38.0000] <JakeA>
annevk: yep, back! Got to do a bit of video work at some point, but mostly free

[01:34:55.0000] <annevk>
JakeA: I'll have more time starting 2:30PM or so

[01:35:09.0000] <annevk>
JakeA: which is 1:30PM your time

[01:35:17.0000] <JakeA>
annevk: Works for me. I'll catch up on all the stuff

[01:35:21.0000] <annevk>
cool

[03:25:33.0000] <MikeSmith>
for those who like validation, SteveF made a bookmarklet that lets you validate the serialized DOM for any given document

[03:25:37.0000] <MikeSmith>
http://codepen.io/stevef/full/LasCJ/

[03:27:20.0000] <MikeSmith>
it uses http://validator.w3.org/nu/ but you could change it to use http://html5.validator.nu/ just by changing the URL in the source and everything else will just work the same

[03:27:39.0000] <MikeSmith>
oh

[03:27:56.0000] <MikeSmith>
hsivonen: http://validator.nu/ and http://html5.validator.nu/ both seem to be down still

[05:48:28.0000] <JakeA>
annevk: brace for questions. Number 1: What does headers .getAll return?

[05:48:52.0000] <JakeA>
annevk: I'm guessing [['key', 'val'], ['key', 'val'], ...]?

[05:49:55.0000] <JakeA>
annevk: Whatever it is, having it as a constructor would be nice

[06:02:17.0000] <JakeA>
annevk: Agree with others re lowercase in enums

[06:03:57.0000] <JakeA>
annevk: "CORS-with-forced-preflight" to "cors-force-preflight"

[06:05:18.0000] <darobin>
in the platform's great tradition we could make it CORS-with-Forced-PreFlight

[06:07:56.0000] <JakeA>
annevk: which requests have mode "tainted cross-origin"?

[06:09:31.0000] <JakeA>
darobin: "API security: strong"

[06:13:43.0000] <zcorpan>
JakeA: <img>, <video>, <link rel=stylesheet>... <track> (and maybe webfonts?) use "fail cross-origin" or what it's called

[06:14:49.0000] <Domenic>
JakeA: I think .getAll should return ['val', 'val', 'val', ...] most likely

[06:15:04.0000] <Domenic>
(since it takes a key)

[06:15:48.0000] <JakeA>
Domenic: ah yes, I missed the arg

[06:20:58.0000] <JakeA>
zcorpan: gotcha. Huh, so even with CORS headers, I won't be able able to get at the structure of an other-origin stylesheet? *learning*

[06:21:48.0000] <zcorpan>
JakeA: no, tainting is when you have an other-origin stylesheet without CORS headers

[06:22:27.0000] <zcorpan>
JakeA: the style sheet is applied but you can't access the CSSOM

[06:22:47.0000] <JakeA>
zcorpan: But with CORS headers you can?

[06:23:30.0000] <zcorpan>
yeah. at least that's the intent in the spec, but the spec might be a bit broken there and i don't know what the impl status is now

[06:23:41.0000] <JakeA>
zcorpan: In that case, what's the difference between a "cors" fetch and a "tainted cross-origin" fetch?

[06:27:12.0000] <zcorpan>
JakeA: see step 6 in http://fetch.spec.whatwg.org/#concept-fetch

[06:28:44.0000] <JakeA>
zcorpan: So, assuming a stylesheet is "tainted cross-origin" and on a different origin, wouldn't that make it always tainted?

[06:28:48.0000] <zcorpan>
JakeA: it's possible that i'm out of sync with annevk's terminology

[06:29:09.0000] <JakeA>
More likely that my mental model is broken, there'll be an aha moment soon

[06:30:05.0000] <zcorpan>
JakeA: not if "url's origin is request's origin and the CORS flag is unset"

[06:31:19.0000] <zcorpan>
which is the same-origin case

[06:32:04.0000] <JakeA>
zcorpan: but cross-origin?

[06:32:06.0000] <annevk>
JakeA: getAll takes a header name and returns its values

[06:32:34.0000] <JakeA>
annevk: yeah, Domenic pointed out I'd missed the arg when I read it

[06:32:35.0000] <annevk>
JakeA: <img> has tainted cross-origin unless you set the crossorigin attribute

[06:32:46.0000] <annevk>
seems other people answered questions

[06:33:13.0000] <JakeA>
Currently trying to work out how the tainting happen on stylesheets

[06:35:01.0000] <zcorpan>
JakeA: possibly it would still be tainted unless you used the crossorigin attribute

[06:35:53.0000] <JakeA>
zcorpan: Aha! That's it, didn't realise crossorigin was supported on <link> too

[06:36:08.0000] <annevk>
JakeA: enjoy

[06:37:41.0000] <zcorpan>
JakeA: yep. crossorigin is a planned addition to url() in css also so you can use CORS with e.g. @import

[06:39:33.0000] <GPHemsley>
Hixie: Is it a known difference between Firefox and Chrome that the former will wait on a script that's not resolving before rendering the page while the latter won't?

[06:39:45.0000] <JakeA>
annevk: I guess there's a reason we can't have "give me a non-opaque version of this if it uses simple headers & method and returns Access-Control-Allow-Origin: *, otherwise give me an opaque response"?

[06:39:57.0000] <JakeA>
zcorpan: gotcha

[06:40:05.0000] <GPHemsley>
Hixie: script and/or stylesheet and/or images

[06:41:40.0000] <zcorpan>
JakeA: i think it wasn't compatible to always send an Origin request header, but maybe we can still do something like that

[06:43:19.0000] <annevk>
JakeA: that would be a new type of fetch

[06:43:31.0000] <annevk>
JakeA: which we could do, but would explain nothing about the platform whatsoever

[06:44:14.0000] <JakeA>
annevk: I'm sure there's a reason it wasn't the default for images and stylesheets, was it something to do with Host as zcorpan suggests?

[06:44:45.0000] <annevk>
JakeA: Origin, yes, we could not use it for each fetch

[06:45:19.0000] <JakeA>
annevk: What did it break? (sorry just curious)

[06:45:26.0000] <annevk>
JakeA: ask abarth

[06:45:39.0000] <annevk>
JakeA: and if you find out, let me know, so I can update the comment in the source of Fetch

[06:45:47.0000] <JakeA>
hah

[06:46:23.0000] <annevk>
zcorpan: is someone finally solving the issues from that public-fx thread?

[06:46:45.0000] <annevk>
zcorpan: though maybe not, CORS style sheets did not come up, what's the benefit of that?

[06:50:39.0000] <zcorpan>
annevk: http://krijnhoetmer.nl/irc-logs/css/20140521#l-1296

[06:53:57.0000] <annevk>
zcorpan: CSSOM would've been shorter :p

[06:54:31.0000] <annevk>
zcorpan: or do you like to taunt my poor memory?

[06:54:51.0000] <zcorpan>
annevk: sorry :-)

[06:55:39.0000] <annevk>
JakeA: static method is brilliant

[06:58:29.0000] <JakeA>
annevk: I figured fetch(url) would resolve to an Opaque response for a response that failed a CORS check and didn't need a preflight. Understand why it doesn't do that. Not sure it's an issue yet

[06:58:57.0000] <JakeA>
hah, muscle-memory capitalised Opaque

[07:00:44.0000] <annevk>
aah

[07:02:48.0000] <JakeA>
annevk: So, now I understand it better, "tainted cross-origin" could be "no-cors"?

[07:03:28.0000] <annevk>
JakeA: you think it's clear to developers that it the response will be tainted in that case? I guess...

[07:03:46.0000] <JakeA>
annevk: Well, it won't be tainted if its same-origin, right?

[07:03:58.0000] <annevk>
JakeA: fair

[07:04:05.0000] <annevk>
JakeA: same-origin is a mode too ;-)

[07:04:38.0000] <JakeA>
annevk: I was going to suggest "same-origin-only" but adding chars feels like a step backwards

[07:06:31.0000] <annevk>
I like no-cors

[07:07:08.0000] <JakeA>
annevk: omitCredentialsMode - XHR uses withCredentials, why invert it for fetch?

[07:07:14.0000] <annevk>
JakeA: we could not offer same-origin...

[07:07:26.0000] <annevk>
JakeA: it's mostly there for a couple of APIs that want it

[07:07:39.0000] <zcorpan>
also see http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#attr-crossorigin-none

[07:08:35.0000] <zcorpan>
which apis use "same-origin"?

[07:08:36.0000] <JakeA>
annevk: any serviceworker-visible requests? I can only think of serviceworker requests that are same-origin

[07:08:55.0000] <annevk>
zcorpan: document.load()

[07:09:09.0000] <annevk>
zcorpan: <track> when there's no crossorigin attribute I thought

[07:09:44.0000] <zcorpan>
annevk: ok right yeah

[07:09:52.0000] <zcorpan>
annevk: i hope we can drop document.load() though

[07:09:56.0000] <annevk>
zcorpan: same

[07:10:11.0000] <annevk>
I'll rename tainted cross-origin

[07:10:21.0000] <annevk>
I'm glad people finally care about Fetch, only took me a year

[07:11:22.0000] <JakeA>
zcorpan: Requests for serviceworkers themselves, although I don't know if we'll use same-origin, I think we'll fail on *all* redirects

[07:11:28.0000] <JakeA>
annevk: It's brilliant

[07:11:44.0000] <annevk>
JakeA: so we could invert omit credentials

[07:12:04.0000] <zcorpan>
JakeA: why fail on all redirects?

[07:12:07.0000] <annevk>
credentials is a bit icky, I forgot the exact rationale

[07:12:38.0000] <JakeA>
zcorpan: tbh, I can't remember, maybe same origin redirect is fine

[07:12:41.0000] <annevk>
JakeA: euhm, please copy me on the ticket where service worker fetching is defined

[07:13:10.0000] <annevk>
I'd really like us not to have another API that does not follow redirects

[07:13:46.0000] <JakeA>
annevk: yeah, I think same origin is fine. So yeah, it would be a same-origin request

[07:14:24.0000] <JakeA>
annevk: I guess appcache manifest is too, as are a lot of requests that are under appcache control

[07:14:53.0000] <JakeA>
annevk: There isn't a ticket for SW fetch, I should update the algos now I understand fetch betterer

[07:20:47.0000] <annevk>
JakeA: http://fetch.spec.whatwg.org/#http-fetch step 9 has a SW placeholder now

[07:20:50.0000] <annevk>
jungkees: ^^

[07:21:21.0000] <annevk>
JakeA: I worked out a better .default() handling with jungkees so everything is a lot less magic

[07:21:55.0000] <JakeA>
annevk: ohh, did that happen here or in a ticket?

[07:22:26.0000] <annevk>
JakeA: both and also as comments on diffs

[07:22:30.0000] <annevk>
JakeA: somewhat messy

[07:22:47.0000] <JakeA>
annevk: I'll wait for the spec :D

[07:23:28.0000] <annevk>
JakeA: the spec is basically that SW invokes Fetch with request and a special flag set on the request object noting it comes from the SW (since .client still points to the actual origin)

[07:25:10.0000] <JakeA>
annevk: sounds better

[07:26:38.0000] <JakeA>
annevk: So, the credentials stuff… <img> is always credentials, <img crossorigin> is never with credentials, XHR withCredentials = true is "cors"?

[07:28:24.0000] <annevk>
JakeA: it's unclear how the crossorigin vs crossorigin=use-credentials is actually implemented

[07:28:38.0000] <annevk>
JakeA: it might be that nothing in the platform has the "never" semantics

[07:29:15.0000] <annevk>
(except in the case where you're always cross-origin due to sandboxing, but that's no different from "cors" in that case)

[07:30:10.0000] <JakeA>
annevk: Is new Request({ mode: "cors", withCredentials: "always" }) an invalid combination?

[07:32:03.0000] <annevk>
JakeA: sorry

[07:32:14.0000] <annevk>
JakeA: XHR withCredentials = false is "cors"

[07:32:39.0000] <annevk>
JakeA: it means there's actually credentials for same-origin fetches, but not for cross-origin

[07:35:26.0000] <JakeA>
annevk: Ohhh, would withCredentials: "same-origin" make more sense?

[07:35:41.0000] <caitp>
it's a bit late to change that

[07:36:04.0000] <JakeA>
caitp: Is it?

[07:36:37.0000] <caitp>
well, maybe not

[07:36:57.0000] <JakeA>
caitp: We're talking about Request here, not XHR

[07:39:23.0000] <JakeA>
annevk: btw, bodyAs(type) works for me

[07:41:11.0000] <annevk>
JakeA: cleaned up service worker integration a bit more

[07:41:15.0000] <JakeA>
annevk: I agree with Domenic that allowing headers to be provided as a simple JS object would be nice in Request/Response constructors

[07:41:45.0000] <annevk>
JakeA: with headers I'm awaiting some feedback, ideally from implementers, on how we want to deal with them

[07:42:19.0000] <annevk>
JakeA: currently the spec follows HTTP, but browsers and the web don't always, and it's unclear to me what we want

[07:42:37.0000] <annevk>
JakeA: I like withCredentials: "same-origin"

[07:43:02.0000] <annevk>
JakeA: flipping the credentials flag in meaning again is going to annoy some people, but hopefully it's for the best

[07:43:22.0000] <JakeA>
annevk: spec is looking great. It seems like a crime not to throw Cache into the window as soon as possible, especially if we're going to have Request/Response/fetch

[07:43:44.0000] <JakeA>
annevk: Where else is it "omit"? I've only seen it on XHR

[07:44:13.0000] <annevk>
JakeA: HTML has limited use of Fetch at the moment

[07:44:27.0000] <annevk>
but converting HTML is going to be a pain already :-(

[07:46:10.0000] <JakeA>
annevk: For the body constructor arg, I'm still keen on https://github.com/slightlyoff/ServiceWorker/issues/192#issuecomment-40737493, which means handling body before headers in the construction steps

[07:47:22.0000] <JakeA>
annevk: I guess FormData should be supported too, although only really useful for request body

[07:49:11.0000] <JakeA>
annevk: Also, what do you think to constructed responses having a text/plain content type by default? Would that avoid the browser triggering downloads if the developer forgets to set it to something better?

[07:50:17.0000] <annevk>
JakeA: are we exposing a way to mutate a body?

[07:50:54.0000] <annevk>
JakeA: setting a Content-Type header based on the body makes sense, we should do that

[07:52:34.0000] <annevk>
JakeA: if we call it withCredentials in the API, you don't mind it not having the same type as XHR?

[07:52:45.0000] <annevk>
JakeA: maybe we should call it includeCredentials?

[07:54:31.0000] <JakeA>
annevk: I wondered about the type issue. useCredentials?

[07:57:04.0000] <JakeA>
annevk: stuck on mutating body. I guess it's as useful as mutating headers as they go through the fetch event, but then having it convert type would be weird

[07:58:19.0000] <JakeA>
annevk: request.body = interestingTransformStream(request.body) could be exciting

[07:58:43.0000] <JakeA>
annevk: I guess we don't have to decide until streams are ready

[08:00:50.0000] <JakeA>
annevk: Does fetch(new URL(url, base)) do the right thing (toString it)?

[08:00:59.0000] <JakeA>
(sorry, just going through my notes now)

[08:02:09.0000] <annevk>
JakeA: yes it should

[08:03:08.0000] <annevk>
JakeA: useCredentials = "same-origin" / "never" / "always" works I guess

[08:04:45.0000] <annevk>
JakeA: all I could think of was setBody or some such

[08:04:50.0000] <annevk>
JakeA: I guess we can wait for streams

[08:05:21.0000] <JakeA>
annevk: or throw on set if it's not a stream. Leave the flexibility to the constructor

[08:05:50.0000] <annevk>
well we don't have streams so that'd be pretty useless

[08:05:55.0000] <JakeA>
annevk: I'm still umming between fetch(url) vs new Request(url).send(), although the former is much shorter

[08:07:22.0000] <annevk>
the latter might be more web-compatible

[08:07:51.0000] <annevk>
I like the former as it matches the English prose :-)

[08:08:00.0000] <zewt>
the "people don't understand that you can set stuff synchronously before async stuff starts" problem?

[08:08:08.0000] <zewt>
("web-author-compatible" heh)

[08:11:08.0000] <JakeA>
annevk: why does fetch() reject with TypeError rather than NetworkError?

[08:11:24.0000] <annevk>
JakeA: I tried to keep it ES-compatible

[08:11:29.0000] <annevk>
JakeA: not sure if that's a goal

[08:12:33.0000] <JakeA>
annevk: Feels weird, but don't know how important ES-compatibilitiy is

[08:13:01.0000] <annevk>
JakeA: note that NetworkError is really DOMException whose name is "NetworkError"

[08:13:20.0000] <JakeA>
annevk: Ahhh, I hadn't realised that

[08:13:24.0000] <annevk>
JakeA: and that DOMException is a somewhat frowned upon object by TC39 but they also not have given us something superior so far

[08:14:18.0000] <jgraham>
JS is somewhat frowned on by CSSWG, but they haven't given us anything superior so far

[08:15:13.0000] <JakeA>
annevk: If I get back an "opaque" response, how can I tell it's opaque? Wondering if .type could be "opaque" rather than "error"

[08:15:47.0000] <annevk>
JakeA: basically, the idea is that the filters take effect

[08:16:01.0000] <annevk>
JakeA: I guess we could expose what filter is being used

[08:16:20.0000] <annevk>
JakeA: http://fetch.spec.whatwg.org/#concept-filtered-response

[08:17:52.0000] <JakeA>
annevk: Could type be overloaded for this? "default" "cors" "opaque" "error"?

[08:19:01.0000] <annevk>
JakeA: yeah maybe, is there a use?

[08:19:51.0000] <JakeA>
annevk: Only to stop opaque responses looking like errors

[08:20:09.0000] <JakeA>
annevk: myResponse.type == 'error' when in fact it's a perfectly usable response

[08:20:31.0000] <annevk>
yeah, I guess we sorta expose that difference elsewhere already

[08:21:23.0000] <annevk>
/me is still working on checking whether renaming omit credentials mode can be done

[08:21:55.0000] <JakeA>
annevk: No rush, just braindumping before my evening turns into meeting

[08:21:56.0000] <JakeA>
s

[08:23:02.0000] <JakeA>
annevk: Thinking about myCache.add('//cdn.whatever/stuff.js') - that would fail without CORS headers. This is a case where returning opaque if CORS fails would be useful. I'll try and chase down the history of the Origin: stuff

[08:24:17.0000] <annevk>
JakeA: why can't you store an opaque in that case?

[08:24:23.0000] <annevk>
JakeA: that's what <script> does too

[08:24:57.0000] <JakeA>
annevk: Right, but cache.add uses fetch(), and the default is cors

[08:25:31.0000] <JakeA>
annevk: I'd have to myCache.add(new Request('//cdn.whatever/stuff.js', {mode: 'no-cors'}))

[08:25:48.0000] <annevk>
JakeA: how about .credentials = "omit" / "same-origin" / "include"

[08:26:15.0000] <annevk>
JakeA: hmm yeah dunno what to do there

[08:26:34.0000] <JakeA>
annevk: might have a better idea when I dig out the Origin: stuff

[08:26:56.0000] <JakeA>
annevk: .credentials etc sgtm

[09:32:33.0000] <annevk>
JakeA: I think the only thing that's still lacking is the response.type thingie

[09:32:50.0000] <annevk>
JakeA: I added some sketches around bodyAs()

[09:39:19.0000] <Hixie>
GPHemsley: test case?

[09:39:50.0000] <JakeA>
annevk: What do you think about "cors-force-preflight" vs "cors-with-forced-preflight"

[09:40:04.0000] <annevk>
JakeA: I'd like to get rid of that entirely somehow

[09:40:21.0000] <JakeA>
annevk: What uses it?

[09:40:24.0000] <annevk>
JakeA: the mode makes sense for XHR to request, but makes no sense for authors to request

[09:40:50.0000] <GPHemsley>
Hixie: Try this: http://128.175.170.176/site/

[09:40:52.0000] <annevk>
JakeA: it's a way from XHR to say that there's upload event listeners attached and that therefore a preflight needs to be made

[09:41:16.0000] <Hixie>
hsivonen: validator.nu is down

[09:41:35.0000] <Hixie>
GPHemsley: hangs for me in chrome...

[09:42:46.0000] <IZh>
Hi Hixie. Did you get my messages?

[09:42:58.0000] <Hixie>
IZh: which?

[09:43:28.0000] <IZh>
Hixie: About imagemap's area.

[09:43:30.0000] <JakeA>
annevk: hm didn't realise that needed extra permissions. Will we hit that issue with fetch()? If you provide your own stream you'll see it being consumed.

[09:45:09.0000] <IZh>
Hixie: It was on 31st of May.

[09:45:49.0000] <Hixie>
IZh: on irc, e-mail, bug?

[09:46:00.0000] <IZh>
Hixie: IRC.

[09:46:26.0000] <Hixie>
IZh: don't think so

[09:46:40.0000] <Hixie>
IZh: best place to report minor bugs is using the form on the spec

[09:46:54.0000] <IZh>
Hixie: Okay.

[09:49:12.0000] <IZh>
Hixie: Should I repeat it in the form?

[09:49:40.0000] <Hixie>
yes please

[09:50:30.0000] <annevk>
JakeA: yeah we might have to require it for streams

[09:50:57.0000] <JakeA>
annevk: Is upload progress that much of a security leak? I can't figure out the issue

[09:51:53.0000] <annevk>
JakeA: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20322 has some background on this

[09:52:10.0000] <annevk>
JakeA: I gotta go, continue this tomorrow maybe?

[09:52:54.0000] <GPHemsley>
Hixie: Oh, really? *shrug*

[09:53:14.0000] <IZh>
Hixie: Done. #25964.

[09:53:32.0000] <JakeA>
annevk: certainly! Have a good evening

[09:53:51.0000] <annevk>
JakeA: you too, this was great

[09:54:08.0000] <JakeA>
annevk: I've learned a lot

[09:54:38.0000] <IZh>
Hixie: What you think about adding support for floating-point coordinates for image maps shapes? These coords would be in the interval of 0.0 to 1.0, and this will work for any resolution of image and any zoom level.

[10:00:13.0000] <Hixie>
IZh: image maps are a dead-end technology

[10:04:16.0000] <caitp>
but they gave us marvels of the world wide web, like the spacejam website

[10:05:14.0000] <caitp>
at least, I could have sworn it used to be an imagemap... looks like a table now. either way :>

[10:11:46.0000] <IZh>
Hixie: What's the purpose of allowing circles with zero radius that will be considered empty and eleminated at the later steps of parsing?

[10:13:20.0000] <Hixie>
IZh: no idea

[10:15:17.0000] <IZh>
Hixie: By the way, zero-sized rectangles are not allowed. But for circle's radius the spec says "must be non-negative".

[10:15:46.0000] <Hixie>
IZh: i have long forgotten anything i ever knew about image maps

[10:15:52.0000] <Hixie>
IZh: like i said, it's a dead-end technology

[11:40:12.0000] <hsivonen>
hmm. validator.nu doesn't come back when relaunching...

[12:20:49.0000] <hsivonen>
MikeSmith, Hixie: ack validator.nu brokenness. this is weird and will need more investigation tomorrow. :-(

[16:26:12.0000] <Hixie>
there's no use case for aggressively downloading something but then not using it until the last possible moment, right?

[16:26:40.0000] <Hixie>
like a script that would only be run immediately before any scripts depending on it are run

[16:26:51.0000] <Hixie>
but that is nonetheless downloaded asap


2014-06-04
[19:13:25.0000] <MikeSmith>
hsivonen: I hope the validator.nu instability isn't related to any changes I made to the sources recently

[19:14:15.0000] <MikeSmith>
hsivonen: Please let me know if I can help with troubleshooting

[19:17:07.0000] <MikeSmith>
hsivonen: I'm wondering if validator.nu might be running on a 32-bit system. If so I wonder if with the current validator codebase we might be reaching the point where it doesn't run so well on 32-bit systems.

[19:19:31.0000] <MikeSmith>
hsivonen: All the w3c validator.nu instances I manage are running on 64-bit systems, and my local testing environment is 64 bit, so I haven't been doing much to make sure it still works on 32-bit systems.

[19:21:42.0000] <MikeSmith>
hsivonen: I have observed that jing seems to do a huge amount of recursion in order to process the current schema, and on 32 bit systems that seems to exhaust the default Java thread stack size.

[19:23:34.0000] <MikeSmith>
hsivonen: So on 32 bit systems I think the current validator sources won't even run any longer unless you tell Java to increase the thread stack size to 512K

[19:33:57.0000] <MikeSmith>
Hixie: for some reason http://wiki.whatwg.org/wiki/MicrosyntaxDescriptions is getting served to validator.nu as application/xml

[19:41:38.0000] <a-ja>
Hixie: $RANDOM comment:  <link rel=stylesheet scoped> plays better with CSP than <style scope>@import</style>...avoids all the nonce nonsense...am I missing something here?

[19:42:16.0000] <a-ja>
s/scope/scoped/

[19:43:11.0000] <roc>
a-ja: are you suggesting that <style scoped> should go away?

[19:43:25.0000] <roc>
a-ja: because <style scoped> with an actual inline stylesheet is potentially very useful

[19:43:32.0000] <a-ja>
perhaps an impl experience for https://www.w3.org/Bugs/Public/show_bug.cgi?id=20166

[19:44:01.0000] <a-ja>
roc: just saying it's a PITA with CSP

[19:44:45.0000] <a-ja>
roc: have to use 'unsafe-inine' or a nonce

[19:44:52.0000] <a-ja>
*inline

[19:47:55.0000] <a-ja>
roc: guess i'm arguing for scoped on link in addition to on style

[22:31:54.0000] <JakeA>
Hixie: wasn't this Kyle's "social media button" usecase? Load the script but don't run it until mousedown or something like that

[23:00:41.0000] <Hixie>
JakeA: yeah, i got confused about precaching vs aggressivey loading.

[01:34:02.0000] <zcorpan>
Ms2ger: the Ethiquable Madagascar 85% was really nice :-)

[01:36:04.0000] <Ms2ger>
/me takes note :)

[01:42:50.0000] <zcorpan>
MikeSmith: it seems people are starting to use <picture> markup about now (with picturefill). maybe time to implement it in v.nu (with a warning that it's not shipped in browsers yet)?

[01:43:47.0000] <zcorpan>
MikeSmith: srcset with x descriptor is shipped, but the other stuff not yet

[02:09:55.0000] <jgraham>
Does anyone know where hallvors hangs out these days?

[02:10:18.0000] <odinho>
Maybe the mozilla server.

[02:11:19.0000] <jgraham>
Oh, I was being dumb

[02:48:32.0000] <jgraham>
/me hands out the party hats

[02:56:42.0000] <darobin>
we get party hats?

[02:57:54.0000] <jgraham>
Yes. And there will be cake.

[02:59:07.0000] <jgraham>
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/211753.html)

[03:02:26.0000] <darobin>
oooh

[03:02:34.0000] <darobin>
I'd written that down and then forgot about it

[03:02:46.0000] <darobin>
happy birthday :)

[03:12:01.0000] <annevk>
🎉

[03:13:40.0000] <annevk>
🍰 for jgraham

[03:15:54.0000] <jgraham>
Oh, a U+FFFD, just what I always wanted

[03:24:14.0000] <annevk>
jgraham: it might be displayed as such, but isn't it what's underneath that matters?

[03:26:40.0000] <annevk>
mpt: why the WhatWG casing?

[03:29:17.0000] <mpt>
annevk, long-standing house style — no acronym with pronouncable portions can have more than three capital letters (cf. Pantone, Nasa, Unicef)

[03:29:55.0000] <annevk>
mpt: your house style?

[03:30:24.0000] <mpt>
Yes. :) Otherwise it’s just a cheap way for organizations to grab attention by claiming that their name is entirely capitalized.

[03:56:31.0000] <zcorpan>
i'd prefer all-lowercase if you want less attention-grabbing :-P

[04:27:16.0000] <jgraham>
Haha

[04:27:55.0000] <jgraham>
html-wg chair asks for volunteer to do actual work

[04:28:14.0000] <jgraham>
Only response is "maybe we can look for someone else to do it"

[04:28:51.0000] <annevk>
jgraham: pointer?

[04:29:31.0000] <jgraham>
http://www.w3.org/mid/6f4822f9ac664bd6bdd52ab323882713⊙Bnpoc

[04:29:39.0000] <jgraham>
To be afir he didn't ask all that long ago

[04:29:46.0000] <jgraham>
So maybe someone will step forward

[04:30:28.0000] <jgraham>
But I wouldn't bet on it

[04:52:30.0000] <annevk>
http://www.macrumors.com/2014/06/03/lighting-cable-headphone-mfi/ hmm, headphone jack to become obsolete

[04:53:47.0000] <caitp>
colour me skeptical

[04:53:49.0000] <annevk>
jgraham: I wonder why they don't take guidance from their mode of operation and fork some existing tests

[04:54:40.0000] <jgraham>
annevk: I presume the problem is that there isn't anything to copy

[04:54:47.0000] <jgraham>
So nothing is happening

[04:54:58.0000] <annevk>
jgraham: I doubt they landed without tests

[05:06:14.0000] <jgraham>
annevk: Oh well if you mean like that, it's not a bad suggestion. Except everyone's existing tests are so ghettoised that porting them is also a huge amount of work

[06:27:00.0000] <tobie>
Are there any difference between these two WebIDL fragments: https://gist.github.com/tobie/5e89cd37dd8b819905c4 ?

[06:27:33.0000] <tobie>
(Outside of the fact that the NoInterfaceObject one can be reused in multiple interfaces)

[06:29:31.0000] <annevk>
I think not

[06:29:56.0000] <annevk>
However, this bit of IDL is super tricky and could use clearer wording and such

[06:32:15.0000] <tobie>
Can't that be said pretty much of each bit of idl?

[06:37:21.0000] <annevk>
tobie: a lot is quite clear, it's just that this implements/interface/[NoInterfaceObject]/partial interface/... is a bit of a pain

[06:37:33.0000] <annevk>
tobie: now that we know the requirements we can come up with something better

[06:37:39.0000] <tobie>
:)

[06:37:49.0000] <annevk>
tobie: and there's some suggestions in some bug on how to do that

[06:37:57.0000] <tobie>
k

[06:43:46.0000] <tobie>
I find input types of function extremely unintuitive too.

[06:45:29.0000] <tobie>
I'm still unsure whether foo(DOMString bar) means it'll throw or type coerce when passed say an object.

[06:49:10.0000] <Ms2ger>
Coerce

[06:49:19.0000] <JakeA>
annevk: I've been struck by a mystery food illness, so I've spent the morning lying in bed thinking about preflight requests triggered by the page. Think there's a security issue. Page makes XHR request with fancy headers, SW responds "yeeeep, go ahead" to the preflight, then allows the subsequent CORS request to hit the network.

[06:49:28.0000] <JakeA>
Circumvented CORS preflight

[06:50:23.0000] <JakeA>
Don't think preflight requests should ever go to the SW

[06:50:30.0000] <annevk>
JakeA: agreed

[06:50:48.0000] <JakeA>
but the request should go to the SW before the preflight

[06:51:04.0000] <annevk>
tobie: yeah it's not great

[06:51:28.0000] <annevk>
JakeA: the preflight is only to ensure the server knows about CORS, I think we can assume that in case of SW

[06:52:02.0000] <tobie>
Ms2ger: so when does it coerce and when does it throw?

[06:52:26.0000] <JakeA>
annevk: Which server?

[06:52:42.0000] <annevk>
JakeA: any

[06:53:07.0000] <Ms2ger>
tobie, when there's a sensible coercion, I guess

[06:53:11.0000] <annevk>
JakeA: so we need to alter http://fetch.spec.whatwg.org/#cors-fetch-with-preflight somehow

[06:53:13.0000] <tobie>
Ms2ger: haha

[06:53:49.0000] <JakeA>
annevk: You only need to preflight if SW doesn't handle the request

[06:54:01.0000] <tobie>
Ms2ger: So what exactly does input types tell us?

[06:54:32.0000] <Ms2ger>
tobie, what type you'll get after WebIDL has done its thing

[06:54:58.0000] <annevk>
JakeA: I guess that algorithm needs a step 0 to invoke "handle a fetch"

[06:55:25.0000] <JakeA>
annevk: agreed

[06:55:55.0000] <JakeA>
annevk: and a flag to prevent preflights going into the SW

[06:55:58.0000] <annevk>
JakeA: and then in addition we need to annotate the request object to make sure that in step 3 it does not ask the SW again

[06:56:03.0000] <JakeA>
:D

[06:57:01.0000] <annevk>
Bit unfortunate we need to have separate places for SW integration

[06:57:19.0000] <tobie>
Ms2ger: so when I say foo(DOMString s), what that means implementation wise is: coerce whatever you get into a DOMString.

[06:57:56.0000] <annevk>
tobie: it means ToString(s)

[06:58:39.0000] <annevk>
tobie: see http://heycam.github.io/webidl/#es-DOMString

[06:59:52.0000] <tobie>
Stupid question, but why don't we write:  foo(ToString(s))?

[07:00:20.0000] <annevk>
tobie: because IDL is based on OMGIDL

[07:01:12.0000] <JakeA>
annevk: unless we continue to send preflights to the SW, but if the SW handles the preflight it must also handle the main request. Feels tricky to reason about though.

[07:01:53.0000] <JakeA>
having the SW handle preflights feels too tricky

[07:02:05.0000] <annevk>
JakeA: it doesn't make much sense either

[07:02:29.0000] <JakeA>
Agreed

[07:02:46.0000] <MikeSmith>
zcorpan: I've already implemented the schema support for <picture>/<source> and updated the schema for <img> with @sizes and @srcset

[07:02:49.0000] <MikeSmith>
zcorpan: https://github.com/validator/syntax/compare/picture

[07:03:24.0000] <zcorpan>
MikeSmith: oh. nice!

[07:03:33.0000] <MikeSmith>
zcorpan: well that part was easy. What remains is that I need to implement error-reporting parsing support for @sizes and @srcset

[07:03:49.0000] <zewt>
<picture>? yuck

[07:04:00.0000] <MikeSmith>
zcorpan: I plan to work on that this weekend

[07:04:03.0000] <Ms2ger>
tobie, because you don't have a "ToString" after you're done?

[07:04:53.0000] <zcorpan>
MikeSmith: these should be invalid https://gist.github.com/jeremys/73817e90bc3cf83aa4c5

[07:05:16.0000] <Ms2ger>
tobie, but let's assume foo(ToString(s)) makes sense. What do you do for 'DOMString?'?

[07:05:38.0000] <tobie>
Ms2ger: what do you mean?

[07:05:42.0000] <zcorpan>
MikeSmith: "When a source element is a child of a picture element and has a following sibling source element or img element with a srcset attribute specified, it must have at least one of the following:" http://picture.responsiveimages.org/#the-source-element

[07:05:52.0000] <Ms2ger>
tobie, foo(DOMString? arg)

[07:06:30.0000] <tobie>
Oh, hadn't see the double "?" sorry

[07:06:55.0000] <tobie>
 foo(ToString(s?))

[07:07:40.0000] <tobie>
no sorry: foo(ToString(s)?)

[07:08:15.0000] <MikeSmith>
zcorpan: yeah there are some really unusual doc-conformance contraints in the picture spec. I'll need to write some custom code for those. There's no way to express them in the schema.

[07:08:53.0000] <zcorpan>
MikeSmith: feedback welcome if something is insane

[07:09:50.0000] <MikeSmith>
zcorpan: my feedback for now is, there's no precedent in the HTML for at least one of those constraints

[07:10:09.0000] <MikeSmith>
zcorpan: can't remember which one, but maybe it's the one you quoted above

[07:10:20.0000] <tobie>
Ms2ger: thing is, generally input types described allowed types, while we're using them here to describe transformations to any type.

[07:11:34.0000] <Ms2ger>
foo(ToString(s)?) doesn't make any sense to me

[07:11:37.0000] <zcorpan>
MikeSmith: i guess we can make it slightly simpler like require media to be present regardless of its value

[07:11:52.0000] <Ms2ger>
It's not a type you're converting to, and it's not an algorithm

[07:13:33.0000] <tobie>
Well, ToString() is the shorthand for an algorithm, no?

[07:14:12.0000] <annevk>
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-tostring

[07:15:01.0000] <annevk>
Anyway, until someone maintains IDL chatting about it is rather moot

[07:15:21.0000] <MikeSmith>
zcorpan: well I suspect those contraints are symptoms or consequences indicating that authoring <picture><source> correctly is error-prone, so authors are going to make a lot of mistakes

[07:15:41.0000] <MikeSmith>
zcorpan: so it'll be nice to have validator support to help them catch the mistakes

[07:16:19.0000] <annevk>
JakeA: it's not that simple I think

[07:17:00.0000] <MikeSmith>
zcorpan: one constraint I guess you know we can't practically check is the one that says the specified dimensions have to match the intrinsic dimensions of the image (or whatever case where that's required)

[07:17:02.0000] <zcorpan>
MikeSmith: it's a bit hard to grasp how the stuff works and things have changed from e.g. the current TR/ version so yeah some pointers from the validator would be great

[07:17:25.0000] <annevk>
JakeA: "HTTP fetch" does a bunch of things to a request we would want to do in this case as well before passing it to the SW

[07:17:32.0000] <zcorpan>
MikeSmith: yeah. html has something similar for the width="" attribute

[07:17:59.0000] <zcorpan>
MikeSmith: could be checked for in devtools though when the image is loaded

[07:18:06.0000] <MikeSmith>
yeah

[07:19:01.0000] <MikeSmith>
zcorpan: I mean, we could check it in the validator. it's possible. But I think it would not be a good idea due to the performance cost

[07:19:04.0000] <JakeA>
annevk: hmm, so it needs to prep the final request, send it to the SW, if unhandled or default() do the preflight before making the final request

[07:19:25.0000] <zcorpan>
MikeSmith: agree

[07:21:53.0000] <annevk>
JakeA: and if it's handled, we want the normal "HTTP fetch" handling for the response I think

[07:22:52.0000] <MikeSmith>
zcorpan: anyway, thanks for that URL. I guess you know we're rightly going to need a lot of validator tests for this at some point. Ideally would be nice to have some while I'm implementing the validator support but that would require me to stop and write them first. So I'm going to forge ahead without them for now. I'm sure that's considered a sin, but I'm a sinner already so oh well

[07:22:56.0000] <JakeA>
annevk: agreed

[07:23:18.0000] <zcorpan>
MikeSmith: that's fine :-)

[07:23:36.0000] <annevk>
JakeA: it almost seems this algorithm should be merged into "HTTP fetch" as an additional flag

[07:23:37.0000] <zcorpan>
MikeSmith: i can write some tests tomorrow maybe

[07:24:13.0000] <annevk>
JakeA: which people hate, but it would handle all the cases

[07:24:46.0000] <JakeA>
annevk: Why the hate?

[07:25:15.0000] <JakeA>
I guess it's like one long function rather than a separate one for CORS preflight

[07:25:19.0000] <tobie>
annevk: sure, though, tbh, I'm still at the "trying to figure it out" phase at this point.

[07:25:19.0000] <annevk>
JakeA: not sure if there's much hate, but in general it would be less readable than having nice short functions

[07:25:25.0000] <JakeA>
heh

[07:25:28.0000] <JakeA>
true

[07:25:38.0000] <MikeSmith>
zcorpan: that'd be great if you can make time. I'll be a plane pretty much all day on Sunday so I'm planning to use that time to try to get most of the srcset/sizes parsing+reporting part done

[07:25:48.0000] <annevk>
JakeA: I don't really see a good alternative though

[07:26:29.0000] <zcorpan>
MikeSmith: i hope you'll be able to transform back into MikeSmith afterwards

[07:27:11.0000] <MikeSmith>
heh

[07:28:07.0000] <MikeSmith>
zcorpan: yeah I see I forgot the hyphen, "I'll be a-plane all day"

[07:28:48.0000] <JakeA>
annevk: If I make a cross-origin XHR request, but respondWith a non-opaque response, can we skip the CORS check?

[07:29:12.0000] <JakeA>
annevk: because .respondWith(new Request("Hello!")) would fail at the moment wouldn't it?

[07:29:37.0000] <annevk>
I was wondering why darobin was asking about document.origin rather than the myriad of other features in DOM with poor implementations support. Seems Glenn Adams made a test case

[07:29:38.0000] <zcorpan>
MikeSmith: i don't know what a-plane means :-(

[07:30:23.0000] <darobin>
annevk: indeed

[07:30:52.0000] <darobin>
but more generally I was wondering why something that strikes me as useful and not hard to implement wasn't there

[07:30:53.0000] <annevk>
darobin: exhibit n as to why things are broken over there

[07:31:29.0000] <annevk>
JakeA: yeah, I think it would be great if we made that work

[07:31:30.0000] <darobin>
annevk: I care about solutions — exhibits? *yawn*

[07:32:10.0000] <MikeSmith>
zcorpan: some quaint archaic verb form, like "He was a-horse in battle when he met his end", meaning he was riding a hore

[07:32:30.0000] <zewt>
riding a, err...

[07:32:33.0000] <annevk>
JakeA: I haven't really gotten there yet

[07:32:34.0000] <JakeA>
annevk: I guess step 11 nees to be part of the "if" in step 10

[07:33:01.0000] <zcorpan>
MikeSmith: ok :-)

[07:33:16.0000] <darobin>
riding a hore?

[07:33:28.0000] <darobin>
/me won't presume which letter is missing there

[07:33:41.0000] <JakeA>
annevk: no worries, just spotting stuff as I see it

[07:34:11.0000] <annevk>
JakeA: ah yes, that prolly makes sense, only do CORS checks for network retrieved resources

[07:35:14.0000] <zewt>
am I the only one completely bewildered by bugs like "Define code values for the special keys on Sun keyboard"

[07:35:17.0000] <jgraham>
MikeSmith: Nice try, but your secret identity as transformer and star of a franchise of terrible* films has been revealed (*probably. I haven't ever watched them.)

[07:35:19.0000] <JakeA>
annevk: If the original request has a CORS flag, you'll still want to error on tainted responses from the SW

[07:36:35.0000] <annevk>
JakeA: yeah, wasn't sure if we should do that in the network layer or the API layer, fetch layer prolly makes sense

[07:36:45.0000] <annevk>
s/network/fetch/

[07:38:25.0000] <MikeSmith>
jgraham: terrible in the Ivan the Terrible sense yeah

[07:48:13.0000] <annevk>
JakeA: okay so I guess I need to merge those two algorithms

[07:48:31.0000] <annevk>
JakeA: CORS fetch with preflight and HTTP fetch, unless you see another way

[07:54:22.0000] <annevk>
JakeA: I guess I'll introduce a "CORS preflight flag" that'll be set and it'll take care of the necessary branching

[07:54:49.0000] <JakeA>
annevk: yeah, I can't think of another way, seems like the best plan

[08:19:17.0000] <JakeA>
TabAtkins: https://twitter.com/tabatkins/status/474207822620921856 - tell me more sir

[08:31:43.0000] <JakeA>
TabAtkins: Sounds like what you want is a fetch that uses credentials & become non-tainted if CORS headers are there, but doesn't fail if CORS headers are absent. I don't think this happens anywhere already, but I want it for serviceworkers

[08:35:46.0000] <annevk>
JakeA: https://twitter.com/jaffathecake/status/474212681839575040 use crossorigin=use-credentials

[08:36:05.0000] <annevk>
nooo, not more modes :-(

[08:38:15.0000] <JakeA>
annevk: where's use-credentials mentioned? Makes sense, but I can't find it on http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-link-crossorigin

[08:38:39.0000] <annevk>
JakeA: follow the link from there to http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#cors-settings-attribute

[08:39:04.0000] <JakeA>
annevk: Gotcha!

[08:57:30.0000] <JakeA>
annevk: In terms of the extra mode, I'm concerned about how complicated caching a cross-domain resource is currently. But if anything, I hope to get to the bottom of why img responses with CORS headers (including credentials) must still be tainted

[09:20:11.0000] <annevk>
JakeA: caching those would be hard anyway as that requires more than just using a wildcard

[09:22:27.0000] <JakeA>
annevk: What does it need on top of Access-Control-Allow-Credentials: true?

[09:22:49.0000] <annevk>
JakeA: to make sure the headers are not static

[09:23:08.0000] <annevk>
JakeA: we don't want it to be trivial to expose credentialed resources

[09:26:16.0000] <JakeA>
annevk: what do you mean by "static" headers?

[09:27:01.0000] <annevk>
JakeA: headers which you could include without doing something conditional

[09:28:04.0000] <annevk>
I'm surprised you don't know about CORS

[09:28:12.0000] <annevk>
I wonder how many other developers don't

[09:34:40.0000] <JakeA>
annevk: It's not something I've used a whole lot, so I'm rusty on the headers. However, see http://vimeo.com/77497239#t=48m10s

[09:35:58.0000] <JakeA>
the room on average does really badly in those questions

[09:40:08.0000] <annevk>
JakeA: thanks for that

[09:40:26.0000] <annevk>
JakeA: third question is fun

[09:40:53.0000] <JakeA>
annevk: is that the text/plain one?

[09:41:05.0000] <annevk>
JakeA: yeah, ah, you gave the next one away at the end

[09:41:38.0000] <JakeA>
most people still got it wrong

[09:42:10.0000] <annevk>
heh

[09:42:15.0000] <annevk>
yeah, I guess they needed that tip

[09:53:05.0000] <annevk>
JakeA: https://github.com/whatwg/fetch/commit/7fd1a7a34edf06e230d99523190e0e8c059ebd01

[09:53:48.0000] <annevk>
JakeA: I don't want setting .body to work

[09:54:05.0000] <annevk>
JakeA: not without something that gives guarantees of .body = x; .body == x

[09:57:01.0000] <JakeA>
annevk: agreed, would be nice if you could set body but happy to throw if it isn't a stream

[09:58:42.0000] <JakeA>
annevk: changes look good, will take a closer look tomorrow when I'm (hopefully) not all food poisoned

[10:19:32.0000] <astearns>
Hixie: I think you've been asking for something like this: http://globau.wordpress.com/2014/06/04/bugzilla-can-now-show-bugs-that-have-been-updated-since-you-last-visited-them/

[10:19:39.0000] <astearns>
not exactly what you wanted, but closer

[12:22:02.0000] <Hixie>
jorendorff: so i think what i'm going to try to do is write up a description of how the Loader thing works, first. rather than try to just jump to writing extensions of it.

[12:26:38.0000] <jorendorff>
Hixie: ok. ping me on irc if you need anything, i suck at email

[12:27:07.0000] <jorendorff>
Hixie: description of how the Loader works at a spec level?

[12:27:28.0000] <Hixie>
yeah, like, writing an alternative equivalent spec for what there is now

[12:27:49.0000] <Hixie>
from what i understand, what there is now is literally generated from code

[12:27:58.0000] <Hixie>
which imho makes it hard to understand

[12:28:11.0000] <Hixie>
(might be easier to just read the original code, actually)

[12:32:22.0000] <jorendorff>
well, it's not literally generated from code, but the code did precede the text.

[12:34:51.0000] <jorendorff>
Adhering to ES spec conventions instead of using prose (or, inventing new conventions) is a big part of how awful it is

[12:35:14.0000] <jorendorff>
(I wrote a bunch of that, but don't tell anyone)

[12:35:39.0000] <jorendorff>
(Alan Smithee wrote it)

[12:36:52.0000] <Hixie>
examples and non-normative colour would go a long way :-)

[12:38:50.0000] <jorendorff>
agreed

[12:39:03.0000] <jorendorff>
non-normative what the hell is this thing would go a long way

[12:39:16.0000] <jorendorff>
on the individual parts

[12:39:24.0000] <jorendorff>
indeed many parts of that spec could use that kind of love

[12:45:39.0000] <zewt>
terrible spec style, but at least it tells you what to do instead of describing what the result should be, like way too many specs

[12:57:56.0000] <Hixie>
jorendorff: ok let's start with teh simplest question, i guess. Where do I start? Do I tell the ES system that I want to run a script (not a module) with a particular URL, or do I hand it some source?

[12:58:10.0000] <Hixie>
assuming just regular old <script> for now

[13:21:17.0000] <jorendorff>
Hixie: you want to know how <script> talks to the ES spec? looking

[13:22:01.0000] <jorendorff>
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-scriptevaluation

[13:22:04.0000] <jorendorff>
note the NOTE

[13:24:03.0000] <Hixie>
so the answer to my question is i hand it some source, right?

[13:25:54.0000] <Hixie>
and presumably decided to Unicode? the ES spec doesn't do any character encoding conversion, right?

[13:25:58.0000] <Hixie>
decoded

[13:26:00.0000] <Hixie>
not decided

[13:29:16.0000] <Hixie>
jorendorff: how does http://people.mozilla.org/~jorendorff/es6-draft.html#sec-initialization fit into this?

[13:32:32.0000] <jorendorff>
Hmm. that section is relatively new

[13:32:37.0000] <jorendorff>
I don't know.

[13:33:02.0000] <jorendorff>
Hixie: when I want to understand how this works i look at http://people.mozilla.org/~jorendorff/es6-draft.html#sec-eval-x

[13:33:52.0000] <jorendorff>
Hixie: an indirect call to eval is very much like <script>

[13:38:28.0000] <jorendorff>
Hixie: even though it *looks* like character encoding conversion is happening there, it's really just saying "decode this string of 16-bit code units to unicode, using UTF-16"

[13:41:50.0000] <zewt>
that sounds like a conversion to me :)

[13:42:25.0000] <zewt>
("decode 16-bit units to unicode using utf-16" says "collapse surrogate pairs to single unicode codepoints" to me)

[13:46:18.0000] <jorendorff>
zewt: yes, it is a conversion, but not in the sense hixie meant

[13:46:38.0000] <jorendorff>
the spec wants you to give it unicode, not bytes

[13:47:03.0000] <jorendorff>
confirmed

[13:57:44.0000] <Hixie>
jorendorff: yeah but for eval you don't have to create a realm and so on, right?

[13:58:05.0000] <Hixie>
it seems to me like #sec-initialization is the thing that's trying to define how <script>s work in a web page

[13:58:13.0000] <Hixie>
though it doesn't really map that cleanly

[13:58:26.0000] <jorendorff>
Hixie: you don't create a realm for each <script> either

[13:58:33.0000] <Hixie>
right

[13:58:44.0000] <Hixie>
hence the #sec-initialization step 7

[13:58:58.0000] <Hixie>
though i've no idea what step 8 means

[13:59:11.0000] <Hixie>
and i doubt steps 7 and 8 actually describe what happens on the web

[13:59:16.0000] <jorendorff>
i'm glad you know what step 7 is about because i sure don't

[13:59:25.0000] <jorendorff>
"synchronously obtain source code" wat

[13:59:26.0000] <Hixie>
well i'm just guessing

[13:59:37.0000] <Hixie>
it doesn't say it's synchronous

[13:59:42.0000] <Hixie>
it says "In an implementation dependent manner"

[13:59:49.0000] <Hixie>
i have more of a problem with step 8

[14:00:40.0000] <Hixie>
i wonder how step 5 can be abrupt

[14:01:20.0000] <Hixie>
seems to me that if http://people.mozilla.org/~jorendorff/es6-draft.html#sec-setdefaultglobalbindings fails when no script has yet run, you have a bad situation on your hands...

[14:02:22.0000] <jorendorff>
Hixie: abstractly, the realm and global for a given document are created super early, before parsing really even starts

[14:02:34.0000] <jorendorff>
Hixie: parsing, abstractly, adds DOM objects to the doctree, right?

[14:02:39.0000] <jorendorff>
/me doesn't really know

[14:02:48.0000] <Hixie>
very abstractly, es

[14:02:49.0000] <Hixie>
yes

[14:03:02.0000] <Hixie>
HTML has tons of prose around how <script>s execute

[14:03:07.0000] <Hixie>
but i don't have anything about realms

[14:03:09.0000] <jorendorff>
if so, and those are JS objects, then the realm has to exist first, for those objects to have suitable prototype chains

[14:03:10.0000] <Hixie>
i do create the global

[14:03:23.0000] <Hixie>
one would imagine

[14:03:25.0000] <jorendorff>
the realm is really just the global and all that javascripty stuff

[14:03:34.0000] <jorendorff>
so this initialization happens super early

[14:03:36.0000] <Hixie>
sadly it's not _all_ that javascripty stuff

[14:03:43.0000] <Hixie>
e.g. it doesn't include the script settings object

[14:04:08.0000] <Hixie>
which is critical for certain web apis to be defined accurately

[14:04:10.0000] <Hixie>
but that's another story

[14:04:41.0000] <Hixie>
#sec-initialization really doesn't match the web

[14:04:48.0000] <Hixie>
steps 7 and 8 don't work like that at all

[14:05:02.0000] <jorendorff>
for sure

[14:05:10.0000] <Hixie>
i guess HTML should run steps 1-5 of that algorithm

[14:05:32.0000] <jorendorff>
Hixie: both specs assuming they are in control of the event loop is not really tenable

[14:05:41.0000] <Hixie>
well that's another problem too, yeah

[14:05:44.0000] <Hixie>
one thing at a time though!

[14:06:30.0000] <jorendorff>
well, that's what step 8 signifies to me: this spec thinks it knows how to start processing tasks

[14:07:32.0000] <Hixie>
step 8 is wrong for more reasons than just that

[14:07:41.0000] <Hixie>
this algorithm implies that all the scripts are piled up, then all executed

[14:07:44.0000] <Hixie>
that's simply not how it works

[14:08:09.0000] <Hixie>
for example, in <script></script><script></script>, between the two scripts executing, the DOM is modified.

[14:12:01.0000] <Hixie>
jorendorff: btw where do i report typos? "When the abstract operation CreateIntrinsics with argument realmRec performs the following:" is grammatically dubious

[14:12:52.0000] <Hixie>
also step 12 of CreateIntrinsics has the wrong font

[14:13:32.0000] <Hixie>
and that algorithm references CreateBuildinFunction should seems to not exist

[14:15:02.0000] <jorendorff>
Hixie: bugs.ecmascript.org for typos; wrong font in PDF, same place

[14:15:22.0000] <jorendorff>
wrong font in HTML is most likely my fault and can be reported at https://github.com/jorendorff/es-spec-html/issues

[14:16:18.0000] <Hixie>
one bug per typo, or should i coallesce?

[14:16:51.0000] <jorendorff>
i always coalesce, but then when you find the next thing, file another bug, not a comment on the original

[14:16:55.0000] <Hixie>
sure

[14:24:48.0000] <Hixie>
jorendorff: i sent a mail to es-discuss about #sec-init

[15:18:46.0000] <gsnedders>
/me wonders what the cost of getting telemetry data for lone surrogates in document.write would be

[15:19:12.0000] <gsnedders>
Probably too much. :(

[15:19:29.0000] <gsnedders>
(Say data like "%" of document.write calls containing lone surrogates)


2014-06-05
[17:07:57.0000] <jamesr_>
what happens to those?

[17:08:53.0000] <jamesr_>
ah, generate parse errors

[17:09:13.0000] <jamesr_>
shouldn't be too bad if you're already in the error handling state to check back for what the error was

[17:09:32.0000] <jamesr_>
/me handwaves wildly

[17:24:48.0000] <gsnedders>
jamesr_: But you need to know you're parsing for document.write

[17:25:08.0000] <gsnedders>
jamesr_: On the other hand, they can only occur when you're in the document.write case…

[17:25:11.0000] <gsnedders>
hmmm…

[17:25:16.0000] <gsnedders>
maybe this can be done more reasonably than I thought…

[17:28:32.0000] <zewt>
do you mean real lone surrogates, or temporary lone surrogates that get completed with the next document.write() call (which I thought worked, though I don't think I've tested it myself)

[17:32:19.0000] <gsnedders>
They do work. Really I want stats for both, but if nothing has lone surrogates, then there aren't temporary lone surrogates.

[17:41:45.0000] <SamB>
/me wonders if there's any code out there that works in chunks and would have temporary lone surrogates more-or-less at random

[17:42:01.0000] <zewt>
that's been the theory

[17:44:02.0000] <SamB>
/me wonders what sort of thinking would motivate the sort of code that might split surrogate pairs across chunks on the client-side ...

[17:44:39.0000] <zewt>
pretty easy if you're getting data over the network in fixed-sized blocks, i just don't know why you'd do that with document.write

[17:47:40.0000] <SamB>
zewt: yeah, I thought of that possible motivation

[19:05:40.0000] <karlcow>
wrong test? or bug? http://www.w3c-test.org/html/webappapis/scripting/processing-model-2/compile-error-data-url.html

[19:06:26.0000] <caitp>
probably both

[19:09:31.0000] <caitp>
well nightly comes closer to passing it than chrome stable

[19:12:28.0000] <Hixie>
the answers to your questions lie in the specification :-)

[19:14:55.0000] <caitp>
"the specification"

[19:15:01.0000] <caitp>
"the"

[19:17:16.0000] <caitp>
but, for what it's worth, the DOM specs on the w3c don't seem to cover onerror in any significant detail, and neither the webapps spec nor fetch seem to say anything about the "content" of a data-url being url encoded

[19:18:17.0000] <karlcow>
hm might have found a bug in a test. jgraham where is the best place to report a bug.

[19:18:43.0000] <Hixie>
the whatwg html standard defines onerror.

[19:18:54.0000] <karlcow>
http://www.w3c-test.org/html/semantics/grouping-content/the-blockquote-element/grouping-blockquote.sub.html

[19:18:59.0000] <karlcow>
second test

[19:19:26.0000] <caitp>
i guess the url spec says to percent encode things, maybe

[19:19:32.0000] <karlcow>
{actual: "blehblah", resolved: document.location.protocol + "//" + document.location.host + "/blehblah"},

[19:19:44.0000] <karlcow>
the document.location.path is missing.

[19:23:13.0000] <karlcow>
s/path/pathname/

[19:23:23.0000] <caitp>
the definition in the html spec seems idetical to the webapps definition, which doesn't specify whether or not source should be urlencoded

[19:47:07.0000] <Hixie>
the webapps definition includes how to process a <script> element?!

[20:09:45.0000] <Hixie>
holy cow, i got a tree constructor test all the way through my parser to "stop parsing"

[20:10:02.0000] <Hixie>
of course it promptly crashed because the output verifier isn't implemented yet...

[20:34:12.0000] <Hixie>
hm

[20:34:20.0000] <Hixie>
what order are the attributes in tree constructor tests?

[20:37:38.0000] <Hixie>
ah, it does say "sorted lexicographically"

[20:37:40.0000] <Hixie>
good good

[21:16:59.0000] <MikeSmith>
Hixie: I forgot what reason you're implementing a parse for

[21:17:04.0000] <MikeSmith>
*parser

[21:18:39.0000] <Hixie>
for my new pipeline

[21:19:16.0000] <SamB>
/me pretends to imagine trying to parse HTML in silicon

[21:28:29.0000] <Hixie>
woot, my parser passes one tree constructor test!

[22:31:59.0000] <karlcow>
html5 parsing <font face…><form…> markup </form></font> https://github.com/webcompat/web-bugs/issues/74

[23:09:46.0000] <zcorpan>
intredasting. commented

[23:10:24.0000] <zcorpan>
("<font face…><form…> markup </form></font>" by itself is fine)

[23:10:58.0000] <zcorpan>
Hixie: AAA disassociating form controls broke the above site

[23:32:50.0000] <karlcow>
zcorpan: thanks for the comment

[23:33:39.0000] <karlcow>
I tried with any inline elements and indeed it kicks in every time.

[23:34:11.0000] <zcorpan>
karlcow: my knee-jerk reaction is that this is probably uncommon enough (since it hasn't come up until now) that it's not worth fixing in the spec

[23:34:34.0000] <zcorpan>
karlcow: similar to "<table><form><tr><td><input>" in innerHTML (which has come up but not so often)

[23:35:10.0000] <karlcow>
yeah… I wonder if it's worth fixing instead of trying to convince the Webmaster to fix his Web site.

[23:35:22.0000] <karlcow>
Specifically when it will soon not work anywhere

[23:35:53.0000] <zcorpan>
they maintained the site enough to notice that there was a problem and add big fat warnings about it

[23:36:09.0000] <zcorpan>
they could have fixed the markup instead

[23:36:51.0000] <zcorpan>
(note that AAA doesn't trigger for any inline, just a handful of elements)

[01:13:58.0000] <jgraham>
karlcow: On the web-platform-test github page, perhaps? I'm not really sure

[01:16:30.0000] <annevk>
I have some plans on merging XMLHttpRequest into Fetch as they are intertwined. Is there some way to put all of XMLHttpRequest's history into Fetch whenever I get around to that?

[01:20:19.0000] <jgraham>
annevk: Yes

[01:21:42.0000] <tobie>
annevk: do you intend for the fetch API to replace xhr in devs' toolboxes?

[01:22:10.0000] <annevk>
tobie: yeah I guess

[01:22:32.0000] <annevk>
tobie: at some point I'll stop adding features to XHR

[01:24:22.0000] <annevk>
jgraham: great

[01:24:33.0000] <tobie>
annevk: so I understand the editorial reason for merging the two specs, but my gut reaction is that it's sending the wrong message wrt to the above.

[01:26:26.0000] <annevk>
tobie: I don't think that's going to be a problem

[01:26:39.0000] <annevk>
tobie: we define legacy features in tandem with new features all the time

[01:26:54.0000] <karlcow>
jgraham: thanks. https://github.com/w3c/web-platform-tests/issues/1042

[01:28:43.0000] <tobie>
annevk: yeah, I guess if those are marked clearly.

[01:49:57.0000] <annevk>
tobie: I'd just name the section "Legacy XMLHttpRequest API"

[01:50:14.0000] <tobie>
annevk: <3

[01:50:44.0000] <tobie>
annevk: how polyfillable is fetch?

[01:51:49.0000] <annevk>
tobie: large parts can be polyfilled, but without proxy server you can't do "No CORS"

[02:27:41.0000] <JakeA>
annevk: been chatting to abarth. Seems like we used to still render an <img crossorigin> that failed its CORS check, but it couldn't be used on a canvas. This sounds sensible and the same behaviour we'd want for the SW cache. Apparently Jonas fought for <img crossorigin> to break on CORS failure, any idea why?

[02:27:42.0000] <annevk>
JakeA: dunno

[02:27:58.0000] <JakeA>
annevk: no worries, will bug him about it later

[03:09:03.0000] <annevk>
JakeA: did he say anything about CORS without opt-in?

[03:09:28.0000] <JakeA>
annevk: he said it was a stupid idea and I should be ashamed of myself

[03:09:37.0000] <JakeA>
(he didn't quite put it like that)

[03:11:18.0000] <annevk>
heh

[03:13:43.0000] <annevk>
JakeA: so the remaining issues are Response.prototype.type; a better definition of multipart/form-data so we can go both ways (not high priority for me at the moment); finding out the best representation of headers both close-to-the-metal and high-level API-wise; and actually defining all the various things

[03:14:51.0000] <annevk>
JakeA: and then for service workers we need to figure out what we need to do with Response objects (or their corresponding responses) coming from service workers

[03:34:15.0000] <JakeA>
annevk: I'm still keen on .type reflecting the filtering. So "basic", "cors", "opaque" "error"

[03:34:48.0000] <annevk>
JakeA: yeah I think it makes sense to expose that. Hopefully the security guys are paying attention

[03:36:12.0000] <JakeA>
annevk: we already expose the difference between "opaque" and "error" though the promise resolve/reject

[03:36:40.0000] <JakeA>
annevk: I guess image load events do the same, although only for images

[03:36:43.0000] <annevk>
JakeA: yeah and also through load/onerror in <img> and such

[03:36:48.0000] <JakeA>
SNAP

[03:36:49.0000] <JakeA>
I win

[03:36:56.0000] <annevk>
JakeA: heh

[03:37:54.0000] <annevk>
JakeA: if SW declines to handle a request and that request ends up doing HTTP auth (due to 401) the subsequent request will also not go through SW

[03:38:01.0000] <annevk>
JakeA: see the text under 401 in HTTP fetch

[03:38:12.0000] <annevk>
JakeA: that seems like the right thing

[03:43:05.0000] <JakeA>
annevk: yeah, that feels right

[03:47:35.0000] <annevk>
I would have liked if the people working on HTTP were a bit more opinionated on what a good header representation makes

[03:47:58.0000] <annevk>
You'd think that if you worked on HTTP for a good decade you'd know what you want

[03:50:52.0000] <Ms2ger>
Ask ChrisMorgan in ircmo #rust

[03:58:05.0000] <annevk>
Ms2ger: he's not around

[03:58:22.0000] <Ms2ger>
Oh, right

[03:58:31.0000] <Ms2ger>
He's somewhere in Australia, IIRC

[03:59:43.0000] <annevk>
Just like mnot, that doesn't work

[04:01:12.0000] <smaug____>
/me lost the conversation about making data url handling inconsistent

[04:01:19.0000] <smaug____>
I think it was in webapps

[04:01:34.0000] <annevk>
smaug____: I moved it to WHATWG

[04:01:52.0000] <smaug____>
oh, there it is

[04:07:14.0000] <annevk>
Ms2ger: is he just working on an HTTP library or he has extensive knowledge about the compat issues and why browser and potentially proxy implementations are weird?

[04:46:09.0000] <Witget>
Hi people. Who can help with adding a meta tag in http://wiki.whatwg.org/wiki/MetaExtensions

[04:46:12.0000] <Witget>
?

[05:12:24.0000] <annevk>
Witget: pm me a desired username and email

[05:36:23.0000] <zcorpan_>
MikeSmith: https://critic.hoppipolla.co.uk/r/1739

[06:27:10.0000] <annevk>
JakeA: I guess if you do Response.redirect() the resulting Response object should have a type that's "redirect"? Seems fine to me

[06:27:22.0000] <annevk>
JakeA: just not if it's a network redirect

[06:37:24.0000] <JakeA>
annevk: I don't think it needs it. It'd just be "basic"

[06:38:01.0000] <JakeA>
annevk: it's just a factory that sets the headers

[06:40:46.0000] <annevk>
Hmm, I guess it would be a bit annoying to define it accurately

[06:41:44.0000] <annevk>
I'll kill redirect for now

[06:43:10.0000] <JakeA>
annevk: https://github.com/slightlyoff/ServiceWorker/issues/287 makes me want to kill the * thing again

[06:44:09.0000] <annevk>
JakeA: exact match should win I think

[06:44:23.0000] <annevk>
JakeA: it is somewhat confusing though

[06:45:32.0000] <JakeA>
annevk: so /foo beats /fo* and /foo*? I agree it makes most sense. I just don't know how useful single path matches are vs the complication they bring

[06:46:31.0000] <JakeA>
I've tried to get Alex to drop them in the past

[06:47:49.0000] <annevk>
I don't know

[06:47:57.0000] <annevk>
I was in favor of starting out with origin-only

[06:48:50.0000] <JakeA>
I like scope, it's been useful in github pages during my testing

[06:57:09.0000] <annevk>
JakeA: do you make sure to make a copy of Request/Response when you store them in the database?

[06:57:18.0000] <annevk>
JakeA: seems like we need to support structured clones

[06:58:20.0000] <JakeA>
annevk: Yeah, they should be structured cloneable

[07:11:22.0000] <annevk>
darobin: what specs manipulate JSON?

[07:11:43.0000] <darobin>
JSON forms, JSON-LD, manifest

[07:11:48.0000] <darobin>
just off the top of my head

[07:12:05.0000] <darobin>
I wouldn't be surprised if we saw more showing up now and then

[07:12:07.0000] <annevk>
darobin: oh, mostly vaporware :p

[07:12:11.0000] <darobin>
huhu

[07:12:27.0000] <annevk>
darobin: that bug was about a parsed representation btw, not serialized

[07:12:35.0000] <darobin>
annevk: precisely

[07:29:34.0000] <annevk>
JakeA: defined redirect(), except for one thing, the url of the new object

[07:29:55.0000] <annevk>
JakeA: we haven't really discussed how to handle urls for synthetic responses yet

[07:30:36.0000] <arunranga>
annevk, once we use a parsed URL for scheme data, is the current string-based origin extraction sufficient? It’s what implementations do right now.

[07:31:01.0000] <annevk>
arunranga: is it? afaik Chrome uses a tuple for origin

[07:31:05.0000] <annevk>
arunranga: not a single string

[07:31:36.0000] <annevk>
arunranga: e.g. to determine if something is a secure origin we'd look at the scheme of the origin only, for that you'd need to parse it

[07:32:00.0000] <arunranga>
annevk, but you can extract scheme from the string.

[07:32:20.0000] <arunranga>
Chrome’s implementation seems to “tag” a blob URL with an origin, serialized as a string.

[07:32:26.0000] <annevk>
arunranga: there's an alternative way of doing this of course, which is that I check that windows's associated document's origin serialized + "/" is a substring for the blob URL thingie

[07:32:37.0000] <annevk>
arunranga: then you don't have to extract

[07:32:38.0000] <JakeA>
annevk: What is response.url used for when it comes to constructed responses?

[07:32:50.0000] <annevk>
JakeA: dunno

[07:33:04.0000] <JakeA>
annevk: I think it's redundant so can be null

[07:33:38.0000] <annevk>
JakeA: so I fetch an image with CORS from http://www.google.com/spoofinggoogle

[07:33:54.0000] <annevk>
JakeA: the SW replies with a custom response

[07:34:17.0000] <annevk>
JakeA: is that URL now associated with a safe response somehow? might be bad?

[07:34:21.0000] <annevk>
/me isn't really sure

[07:35:24.0000] <arunranga>
annevk, Chrome uses a string, but tuples are themselves extractable from it: blob:http%3A//www.w3.org/3fb1659b-1352-40b0-a029-ce91536696ea

[07:35:37.0000] <JakeA>
annevk: I think it's fine. The SW could also respondWith(fetch('/local.png'))

[07:35:41.0000] <arunranga>
^ the “/“ separates a UUID from the origin

[07:35:58.0000] <annevk>
arunranga: how do you know it uses a string?

[07:35:58.0000] <arunranga>
So it isn’t quite a tuple.

[07:36:01.0000] <JakeA>
annevk: You can shoot yourself in the foot if you want, but I don't think it's harmful to anyone else

[07:44:43.0000] <arunranga>
annevk: Blob URLs *are* strings; seems like origins were implicit but we’ve now made them explicit by appending them to a string.

[07:45:25.0000] <annevk>
arunranga: I understand that you have a string representation of an origin, we were talking about extracting the origin for internal use

[07:46:08.0000] <annevk>
arunranga: what is the origin of a blob URL you navigate to?

[07:46:31.0000] <arunranga>
annevk: would extracting a string (generated by the Origin Spec’s Unicode Serialization of an Origin algo.) be insufficient? Internally tuples can be generated from the string.

[07:46:59.0000] <ChrisMorgan>
annevk: I’m sorry to say that I don’t have much experience in the practical nastinesses of how proxies and such behave. My background—not a terribly long one either, by the way, I’m only 22, though I’ve worked with the web for just on half my life now—is more in web application development.

[07:47:31.0000] <annevk>
hey ChrisMorgan

[07:47:43.0000] <annevk>
ChrisMorgan: the relevant issue is tracked here https://github.com/slightlyoff/ServiceWorker/issues/300

[07:47:45.0000] <ChrisMorgan>
I just had strong opinions on things like header representation, which led me to working in Rust for the past year or so, doing strongly typed HTTP and such.

[07:48:18.0000] <annevk>
ChrisMorgan: please be sure to read the referenced Gecko code as it might put some constrains on us

[07:48:43.0000] <arunranga>
annevk, the Unicode Serialized Origin is what’s nested in the blob: URL. Extracting it is a matter of string parsing. Tuple generation, if necessary for same origin comparision, can be done safely, since the emiter methods emit a safe string.

[07:49:05.0000] <arunranga>
So I’m not sure recursive parsing is useful.

[07:49:29.0000] <annevk>
arunranga: if "an origin" is a tuple, you can't just set it to a string

[07:49:44.0000] <ChrisMorgan>
annevk: I know of Guile and intarweb, two Scheme things that use strongly typed headers, and Spray for Scala.

[07:50:07.0000] <arunranga>
annevk, would you prefer to do recursive pasing?

[07:50:33.0000] <arunranga>
Which is to parse the blob: URL recursively for an origin?

[07:50:37.0000] <annevk>
arunranga: I'm not sure I fully understand all the implications yet of this

[07:50:44.0000] <annevk>
arunranga: of a blob having an embedded origin that is

[07:51:06.0000] <annevk>
ChrisMorgan: we can't do much strong typing, this is a JS API

[07:51:18.0000] <annevk>
ChrisMorgan: it's mostly about whether this should be a map or a list, ...

[07:51:30.0000] <ChrisMorgan>
annevk: my intent with Teepee is to largely implement the specs as they are and adjust the parsing et al. as necessary, doing large-scale analysis of real life, covering things like the Common Crawl.

[07:51:48.0000] <zewt>
annevk: what's the functional difference?  the origin being anything but a simple string is new to me

[07:51:49.0000] <arunranga>
Thing is, the origin is already that of the incumbent settings object. Fx’s single process means that we never needed to make it explicit. Multi-process UAs can parse strings for sanity checks; not sure why we need to keep the tuple around, but we could.

[07:52:13.0000] <annevk>
zewt: e.g. to see if something is a secure origin you check the scheme

[07:52:22.0000] <annevk>
zewt: see https://w3c.github.io/webappsec/specs/mixedcontent/

[07:52:27.0000] <zewt>
then parse the origin to get the scheme from it

[07:52:53.0000] <annevk>
zewt: yes, either that or origin is already a tuple and setting it to a string is wrong

[07:53:12.0000] <ChrisMorgan>
Go deals with headers as a mapping of header name strings to an array of strings.

[07:53:12.0000] <zewt>
if they're functionally interchangeable than neither is wrong

[07:53:13.0000] <arunranga>
annevk, actually, one thing we can do is parse the origin string and extract a scheme, host, port tuple

[07:53:23.0000] <zewt>
arunranga: i just said that :P

[07:53:42.0000] <annevk>
zewt: just depends on what the model is

[07:53:44.0000] <arunranga>
zewt :) annevk, I’m not sure where the tuple would live.

[07:53:51.0000] <zewt>
if neither is wrong, having the origin mbe a string to line up with document.location.origin seems most natural, at least at first glance

[07:53:52.0000] <annevk>
zewt: which is what I asked

[07:53:53.0000] <arunranga>
Other than being parsed for extraction

[07:54:00.0000] <ChrisMorgan>
annevk: seems to me that getting sense out of HTTP headers without a strongly typed interface is a futile endeavour…

[07:54:05.0000] <ChrisMorgan>
(Alas.)

[07:54:40.0000] <annevk>
ChrisMorgan: the way you described Go does not like super strongly typed, that level of detail works

[07:54:56.0000] <annevk>
ChrisMorgan: although it also depends a bit on how they parse incoming values I guess

[07:54:57.0000] <ChrisMorgan>
Indeed, Go is typically pretty weakly typed.

[07:55:57.0000] <caitp>
indeed.

[07:55:58.0000] <ChrisMorgan>
I’m not certain how it handles things like `Accept: foo, bar\r\nAccept: baz`, whether ['foo', 'bar', 'baz'] or ['foo, bar', 'baz'], but I would expect the latter.

[07:56:28.0000] <annevk>
Hmm

[07:56:33.0000] <ChrisMorgan>
Without knowledge of the grammar of the header, it is impossible to do anything at all.

[07:56:50.0000] <ChrisMorgan>
Because you need to know whether it’s a list type or not.

[07:57:07.0000] <annevk>
Well clearly it is possible to do something hence everyone having a generic abstraction

[07:57:09.0000] <ChrisMorgan>
In RFC 2616-speak, it’s the difference between #(…) and anything else.

[07:57:56.0000] <ChrisMorgan>
If it is a list, then that earlier example would be foo, bar, baz. If it is not a list, the behaviour is undefined. I’m not certain what the typical behaviour is.

[07:58:27.0000] <ChrisMorgan>
/me is not pleased with any HTTP specs, including HTTP/2; they leave *so* much undefined

[07:58:54.0000] <annevk>
Yeah okay, seems you got about as far as I did with this

[07:58:57.0000] <ChrisMorgan>
HTTP/2 even inserts *deliberate* ambiguity of behaviour in a couple of places!

[07:59:05.0000] <annevk>
/me hopes mnot wakes up

[07:59:53.0000] <annevk>
zewt: typically the underlying model is more complex, and the APIs return something serialized

[08:00:04.0000] <annevk>
zewt: I'm not sure why origin would be any different

[08:00:58.0000] <ChrisMorgan>
Header fields `Foo: bar` and `Foo: baz` should NOT be treated as equivalent to `Foo: bar, baz`; only if it is a list is that correect…

[08:01:42.0000] <ChrisMorgan>
And then of course there’s Set-Cookie… *sigh*

[08:02:41.0000] <caitp>
it's gonna be okay dude, we can still get hadfield's tweets to the space station

[08:04:22.0000] <ChrisMorgan>
caitp: sometimes I’d prefer it if it *didn’t* work, because then we’d need to fix it. As it is, “if it ain’t broke, don’t fix it” prevails ☹

[08:04:46.0000] <ChrisMorgan>
/me agrees with the Varnish author on some of the things he’s saying about HTTP/2 and wishing it would break more

[08:06:06.0000] <arunranga>
annevk, seems like you’re right: Fetch should totally shoulder request/response pieces. The fact that File APi does it at all is actually a legacy issue.

[08:07:00.0000] <arunranga>
annevk, but I’m unclear on the bit about URL Parse, namely https://www.w3.org/Bugs/Public/show_bug.cgi?id=25987. Is it assigned to me? If so, what am I missing?

[08:08:28.0000] <ChrisMorgan>
Oh, by the way, I don’t like CORS much. Especially the way that preflight requests hate 3xx, that I really don’t understand (it says to treat it as a network error!). Working around that has cost several days’ work for a team that I was working with a few weeks ago, changing a thing in the API to use a 2xx status code with a Location header, the JS client manually following the redirect… ☹

[08:09:22.0000] <annevk>
ChrisMorgan: seems like you forgot to give feedback somewhere

[08:09:27.0000] <annevk>
ChrisMorgan: at least, I didn't see it

[08:09:41.0000] <annevk>
ChrisMorgan: having said that, not sure how we can do that sanely

[08:10:12.0000] <annevk>
arunranga: it's not clear to me if the current story we have is correct

[08:10:23.0000] <ChrisMorgan>
annevk: research has shown quite a few people really fed up by that. I wasn’t sure who I should complain to when I discovered this 278 inthe code…

[08:10:37.0000] <annevk>
ChrisMorgan: is that research published?

[08:11:02.0000] <annevk>
ChrisMorgan: for starters you can file bugs on the standard: http://fetch.spec.whatwg.org/

[08:11:18.0000] <annevk>
arunranga: I have somewhat limited time now

[08:11:35.0000] <ChrisMorgan>
annevk: “research” == Google, Stack Overflow, Chrome bug tracker, &c.

[08:12:15.0000] <ChrisMorgan>
Most people seem to figure it a browser bug, but I tracked it through the specs and W3C and WHATWG agree that 3xx is treated as network error :-(

[08:12:18.0000] <annevk>
ChrisMorgan: pointers welcome if you file a bug

[08:12:33.0000] <annevk>
Yes I know, I wrote the spec

[08:12:37.0000] <annevk>
(both of them)

[08:13:08.0000] <ChrisMorgan>
I see that it’s not the easiest problem, but I was wondering about something like just doing another preflight request if necessary.

[08:13:24.0000] <ChrisMorgan>
Certainly I haven’t thought all the implications through.

[08:13:31.0000] <zewt>
annevk: fwiw, the "implicit" blob origin approach seems to sidestep this stuff, since the "real" origin stays internal

[08:13:34.0000] <ChrisMorgan>
But it is a very annoying limitation.

[08:14:01.0000] <ChrisMorgan>
CORS as a whole is annoying… but I understand why it is necessary and so there isn’t anything that could obviously be better.

[08:14:36.0000] <zewt>
one case i noticed where it was visible was when creating a blob URL from inside a file: origin, UAs don't expose the origin, so Chrome gives a bogus "blob:null/uuid" url, but Firefox's "blob:uuid" doesn't care

[08:15:13.0000] <ChrisMorgan>
annevk: you’ve convinced me, I’ll see about filing a bug about trying to get 3xx to work with preflight requests.

[08:15:24.0000] <ChrisMorgan>
Probably take a day or two.

[08:16:04.0000] <zewt>
(the "implicit" approach has its own weirdnesses, like how new URL(blobURL).origin would give different results depending on whether the URL was revoked or not)

[08:16:44.0000] <ChrisMorgan>
Now, I should go to sleep.

[08:18:14.0000] <annevk>
zewt: blob:null would be correct as the serialization of a unique ID origin is null

[08:18:24.0000] <annevk>
zewt: which is another argument as to why origin is not a string

[08:19:24.0000] <ChrisMorgan>
annevk: sorry I can’t help you more.

[08:20:04.0000] <zewt>
annevk: if you can't parse the actual origin back out of the blob URL, i think the reasons for the "explicit" origin approach go away

[08:20:27.0000] <zewt>
maybe not completely, since the URL API would be the same...

[08:22:32.0000] <zewt>
i guess it means that taking a blob URL and returning its origin would have to dig into the blob URL store (since eg. for file URLs the origin isn't actually in the URL), but the script-visible resulting .origin string would be identical both ways ("null"), only the internal origin would be different

[08:23:10.0000] <zewt>
i guess that's ugly but not horrible

[08:23:17.0000] <annevk>
ChrisMorgan: thanks for your thoughts, have a good night

[08:24:27.0000] <zewt>
though it would become script-visible again if there was something like url.isSameOrigin(url2)

[08:29:15.0000] <arunranga>
annevk: so is that bug a placeholder bug for tweaking the Fetch story for Blob URLs? I’m not 100% sure what action to take on it, but I can leave what’s currently in http://dev.w3.org/2006/webapi/FileAPI/#requestResponseModel to Fetch.

[08:30:17.0000] <arunranga>
(by “that bug” I mean Bug 25987)

[09:21:39.0000] <annevk>
arunranga: it's a bug about what the overall model should be

[09:27:57.0000] <zewt>
if we want to be able to figure out same-origin for file urls (maybe data too? not following that thread), seems like simple string parsing is out, at least

[10:05:31.0000] <Ms2ger>
Did I just get an email with an attachment w3c-standard-....docx?

[10:05:55.0000] <SamB>
Ms2ger: people are crazy sometimes ...

[10:09:16.0000] <jgraham>
Ms2ger: I don't know, did you?

[10:09:48.0000] <Ms2ger>
Either I did or I'm hallucinating about public-web-perf

[10:10:11.0000] <jgraham>
I like to pretend that public-web-perf is all hallucination

[10:11:40.0000] <jgraham>
/me checks a few recent emails, finds that it is still bz suggesting that specs should actually define things, closes the folder again

[10:48:06.0000] <zewt>
crazytalk

[11:14:43.0000] <IZh_>
Hixie: Hi. Minory typo. In the Forms section the example of the Pizza form and the example of server query string contains different phone numbers. ;-)

[11:15:04.0000] <Hixie>
please file all the bugs using the form on the page

[11:15:09.0000] <Hixie>
i can't track bugs reported on irc :-)

[11:16:54.0000] <IZh_>
I'll try. At this moment I'm on the phone with very bad internet connection in a subway. :-)

[11:17:11.0000] <gsnedders>
/me tries and work out how the sanest way to parse the parser spec is…

[11:19:57.0000] <Ms2ger>
Bootstrapping

[11:20:03.0000] <gsnedders>
:)

[11:20:25.0000] <gsnedders>
I should probably start off by just creating a list of all sentences in the tokenizer spec

[11:22:00.0000] <annevk>
zewt: not sure why we'd want to

[11:25:31.0000] <zewt>
not sure either, wasn't able to construct a test case (postMessage won't post to a file: iframe)

[11:26:55.0000] <zewt>
well, you should be able to use a blob url created in a file: url within that page

[11:27:37.0000] <zewt>
and if you're getting the origin by parsing the string, you can't check that since all you have is "null"

[11:29:05.0000] <annevk>
I'm not too concerned about file URL compat

[11:30:55.0000] <zewt>
well, it works in browsers today

[11:31:09.0000] <zewt>
(at least Chrome, on a quick test)

[11:34:28.0000] <zewt>
same for data: urls, which also give blob:null/uuid urls

[11:35:19.0000] <zewt>
making blob urls not work inside anything with a unique origin doesn't seem good

[11:38:07.0000] <annevk>
I guess they always compare against the serialized origin in which case it would always work

[11:38:25.0000] <annevk>
As I suggested earlier, just serialize the origin and append "/" and see if it's a substring

[11:39:50.0000] <zewt>
but the serialized origin is just "null", so it wouldn't be comparing that they're the same origin, it'd consider two different "unique origins" as being the same origin since they serialize the same

[11:41:09.0000] <zewt>
so i guess you could define that to work, but i'd imagine that'd just be defeating the check

[11:46:12.0000] <annevk>
I don't think it would combined with the fact that the blob URL store is unique per environment

[11:46:31.0000] <annevk>
As document.domain only works for HTTP URLs

[11:49:29.0000] <zewt>
i guess it just seems like asking for trouble that if you create a blob URL in two different unique origins, you end up with two URLs that are same-origin with each other

[11:50:24.0000] <zewt>
no idea what the side-effects would be, just that it seems like unexpected behavior in a security-sensitive value

[11:59:13.0000] <Philip`>
gsnedders: I tried parsing the parser spec once, and gave up and decided it was way easier and more reliable to just transcribe it into a declarative language by hand

[12:04:02.0000] <Hixie>
ok well my attempt to define how the JS loader works has kinda run aground before getting started. I guess es-discuss isn't going to be getting much traffic during the f2f.

[12:11:42.0000] <Hixie>
firefox does such a great job of actually rendering the HTML spec once it's loaded

[12:12:11.0000] <Hixie>
i wish i had a browser with chrome's load-time behaviour and firefox's render-time behaviour, on the spec...

[12:13:59.0000] <SamB>
/me remembers about that ghost of an idea he had to implement chunking in JS using display:none ...

[12:15:29.0000] <gsnedders>
Philip`: I know. I cited your mailing list post about that in my BSci thesis ;P

[12:16:53.0000] <SamB>
I wonder if the same is true of, say, the Relax NG or Relax NG Compact spec ...

[12:17:36.0000] <SamB>
I remember seeing something that looked suspiciously like a formal semantics in one or both of those ...

[12:18:13.0000] <gsnedders>
So my attempt to directly translate the spec into a declarative language led to bugs in the transcription

[12:18:23.0000] <gsnedders>
So I'm unsure about any property proven of that model

[12:18:28.0000] <gsnedders>
Because I don't trust it models the spec.

[12:19:49.0000] <Hixie>
bugs in the transcription?

[12:20:19.0000] <gsnedders>
The transcribed, formal, declarative copy didn't match the spec.

[12:21:35.0000] <Hixie>
was it an automated transcription?

[12:21:56.0000] <gsnedders>
No. By hand.

[12:22:04.0000] <Hixie>
ah

[12:22:51.0000] <gsnedders>
Unrelated: how is my desk such a mess?

[12:25:45.0000] <gsnedders>
/Why/ do I have year old train tickets? When am I going to need them?

[12:27:42.0000] <Philip`>
gsnedders: You should just run it against the test suite until it passes

[12:28:09.0000] <Philip`>
You'll have to do that anyway, because there's no way to tell your automatic translation thing isn't full of bugs

[12:28:27.0000] <Huvet>
I get a crash in html5lib==1.0b3 with '<z\uFFFD>' -> ValueError: chr() arg not in range(256) -- is this a known bug?

[12:29:37.0000] <Hixie>
foolip: ping

[12:29:48.0000] <Philip`>
gsnedders: and it's much easier to notice and fix bugs in a manual translation, than in a script that's full of regexps that try to pattern-match all the dozens of ways Hixie can phrase the same concept

[12:30:01.0000] <Hixie>
heh

[12:30:54.0000] <gsnedders>
Huvet: using lxml?

[12:31:02.0000] <gsnedders>
Huvet: probably a known bug

[12:31:05.0000] <Huvet>
gsnedders: yes

[12:31:20.0000] <Philip`>
qr/Act as if an end tag (?:token )?with (?:the )?tag name "(\S+)" had been seen, (?:and )?then, if that token wasn't ignored, reprocess the current token\./

[12:31:23.0000] <IZh>
Why there are no term "positive integer"? There are lots of "non-negative integer greater than zero".

[12:31:28.0000] <Hixie>
foolip: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24684

[12:31:28.0000] <Philip`>
(from my old attempt at a translator)

[12:31:37.0000] <gsnedders>
Philip`: I was hoping from my brief experiment to do stuff a bit better than that

[12:31:50.0000] <gsnedders>
IZh: because people get into arguments about what a positive integer is

[12:31:54.0000] <Hixie>
i recommend just using an NLP library

[12:32:00.0000] <gsnedders>
Hixie: my plan.

[12:32:00.0000] <Hixie>
/me ducks and runs

[12:32:13.0000] <gsnedders>
Hixie: Not actually using a full parser, because that';ll never work

[12:32:35.0000] <gsnedders>
Hixie: But can likely get somewhere

[12:32:47.0000] <IZh>
gsnedders: Hmm... Is there any another meaning of what positive integer could be?

[12:33:00.0000] <gsnedders>
(Your grammar is weird in places in the spec. :))

[12:33:08.0000] <gsnedders>
IZh: Some include 0.

[12:33:13.0000] <annevk>
zewt: they wouldn't be able to reach each other since each would have its own unique blob URL store

[12:33:32.0000] <annevk>
zewt: the additional origin check is only relevant for document.domain purposes afaict

[12:33:52.0000] <IZh>
gsnedders: I would send them back to school. Zero is not a positive.

[12:34:16.0000] <Hixie>
gsnedders: i meant some mythical library that literally just understands the spec :-)

[12:35:14.0000] <annevk>
foolip: wanna cleanup https://code.google.com/p/chromium/issues/detail?id=341854 ?

[12:35:33.0000] <annevk>
I wish someone on Gecko's end would drop xml:base already

[12:36:04.0000] <Ms2ger>
Not it

[12:37:58.0000] <caitp>
is URLUtils.searchParams actually implemented anywhere?

[12:38:08.0000] <IZh>
Hixie: When ACID4 will be ready?

[12:38:41.0000] <Ms2ger>
Never

[12:39:00.0000] <Ms2ger>
The Acid tests have been increasingly bad for the web, so we stopped doing them

[12:39:16.0000] <annevk>
caitp: Gecko

[12:39:22.0000] <caitp>
hmm

[12:39:29.0000] <IZh>
Ms2ger: why bad?

[12:39:45.0000] <caitp>
that's too bad, it would be really convenient to use them :( I guess that will give me something to hack into blink then

[12:39:48.0000] <Ms2ger>
Acid2 caused the only quirks-mode / standards-mode difference in the HTML parser

[12:40:06.0000] <Ms2ger>
And it caused years of confusion about -- in comments

[12:40:12.0000] <annevk>
I wonder why window.location.searchParams is not a thing

[12:40:20.0000] <Ms2ger>
Acid3... *sigh*

[12:40:36.0000] <SamB>
Hixie: it sounds like you need more macros ;-P

[12:41:00.0000] <Ms2ger>
annevk can give you some examples of what acid3 did... I'm off for today

[12:41:07.0000] <Hixie>
IZh: probably not until browsers stop caring about standards again

[12:41:22.0000] <annevk>
Ms2ger: isn't there enough written about that?

[12:41:23.0000] <Hixie>
Ms2ger: i think the acid tests did lots of good stuff, but for sure they also had some negative side-effects.

[12:41:51.0000] <Ms2ger>
Sure

[12:41:57.0000] <annevk>
Yes, it's grey again, not white or black

[12:42:14.0000] <Ms2ger>
I feel like the good stuff/bad stuff ratio decreased over time, though

[12:42:28.0000] <caitp>
hmm, I guess writing to searchParams in gecko has no effect, darn.

[12:42:35.0000] <IZh>
Never thought that tests may harm...

[12:43:09.0000] <Ms2ger>
If passing them is a goal by itself, regardless of what behaviour it tests for...

[12:44:39.0000] <IZh>
Looks like I'm very ancient and out-of-dated. ;-)

[12:45:24.0000] <caitp>
they have surgery to fix that these days, it worked wonders for pete burns

[12:47:52.0000] <gsnedders>
Hixie: bah, all NLP libraries are terrible, they are pretty much all done based on Chomsky's generative grammars, which is an utterly stupid idea.

[12:48:11.0000] <gsnedders>
But I'm not getting on that soapbox. :)

[12:48:40.0000] <gsnedders>
IZh: The problem with the Acid tests is they mostly force people to implement specs that nobody actually cares about and everyone has interoperably broken for years.

[12:50:25.0000] <IZh>
gsnedders: I see...

[12:51:03.0000] <Hixie>
actually the acid tests were pretty carefully written to not do that, by and large

[12:51:23.0000] <gsnedders>
still, a few pretty notable cases (like the comment parsing stuff)

[12:51:46.0000] <gsnedders>
I think everyone parsed <p><table> the same as well?

[12:53:16.0000] <Hixie>
well the two things you said are differnet issues

[12:53:33.0000] <Hixie>
acid2 dates back to the days where we were trying to get browsers to do the right thing in standards mode, rather than fixing the specs.

[12:54:01.0000] <Hixie>
back before we (I, at least) understand that specs were not stone tablets handed down from on high

[12:54:12.0000] <Hixie>
understood

[12:54:44.0000] <SamB>
Hixie: basically, when you were young and naive?

[12:54:53.0000] <Hixie>
well, naive, anyway

[12:56:06.0000] <IZh>
Off the topic: I'm waiting for wildcards in css-properties. I don't like to see series of -x-moz, -x-ie, -x-opera, -x-webkit... doing the same things under similar names. Why not use -x-*-something or -x-anyvendor-something?

[12:57:47.0000] <caitp>
what problem would that solve other than making experimental properties less cumbersome to use in css?

[12:57:59.0000] <SamB>
IZh: I thought the trend was to just drop the prefixes?

[12:59:06.0000] <SamB>
and use other mechanisms to discourage use way too early

[13:00:51.0000] <Hixie>
hahahahaha

[13:01:06.0000] <Hixie>
"In total, 3190 tests fail to pass in two implementations." "We contend that the specification being proposed for advancement through the process has demonstrated interoperability."

[13:01:51.0000] <SamB>
how many tests did they have?

[13:02:00.0000] <zewt>
3190

[13:02:19.0000] <zewt>
(no idea heh)

[13:02:42.0000] <SamB>
if zewt is right, can we exile the perpetrators

[13:02:47.0000] <Hixie>
they have about 1000 tests, with about 100 assertions in each test on average

[13:03:47.0000] <IZh>
SamB: the trend is good.

[13:03:49.0000] <zewt>
number of assertions beyond the first to fail in a test tends to be meaningless, at least in my tests

[13:04:33.0000] <SamB>
/me is a bit confused at the idea of the test continuing past failed asserts

[13:04:43.0000] <SamB>
/me guesses asserts mean something strange in JS ...

[13:04:44.0000] <Philip`>
Is it saying there are two implementations which the tests do not pass in, or that there are not two implementations which the tests pass in?

[13:04:50.0000] <Hixie>
the coverage is pretty anemic. There's some areas that have good coverage, e.g. the canvas features (though not new ones), <video>, and parsing

[13:04:56.0000] <SamB>
Philip`: lol

[13:04:57.0000] <Hixie>
Philip`: the latter

[13:05:39.0000] <Hixie>
for contrast, there are 3539 occurances of the word "must" in the HTML spec

[13:06:12.0000] <Hixie>
(very few of which are in the parser section)

[13:06:45.0000] <SamB>
Hixie: what about in the *real* HTML spec

[13:07:08.0000] <Hixie>
that's the one i was talking about

[13:07:13.0000] <SamB>
oh

[13:07:17.0000] <Hixie>
i guess their fork is missing some sections so they'll have fewer

[13:07:44.0000] <SamB>
I'm kind of surprised by "very few of which are in the parser section"

[13:08:46.0000] <gsnedders>
the parser section is: "you MUST use the following state machine: [insert thousands of lines of state machine]"

[13:09:04.0000] <gsnedders>
Hixie: that on public-html?

[13:09:09.0000] <Hixie>
yeah

[13:09:17.0000] <Hixie>
SamB: what gsnedders said

[13:09:21.0000] <SamB>
ah, well, okay

[13:09:31.0000] <SamB>
I figured it was something like that ...

[13:09:51.0000] <SamB>
hidden/factored-out musts ...

[13:10:28.0000] <gsnedders>
Hixie: where? I see no reference to the word "advancement" since 2012?

[13:10:45.0000] <Hixie>
it was in the -details.html file robin linked to

[13:10:47.0000] <Hixie>
sorry

[13:13:26.0000] <gsnedders>
The fun part is the whole sections of the spec with no tests.

[13:13:29.0000] <gsnedders>
Like #loading

[13:13:53.0000] <caitp>
that does sound like fun

[13:14:15.0000] <caitp>
exhilarating

[13:30:41.0000] <jgraham>
Hixie: is this the HTML spec?

[13:31:06.0000] <Hixie>
is what the HTML spec?

[13:31:32.0000] <jgraham>
I think it makes a lot more sense to do that than to hold the spec up until implementors fix all the tests, which they won't

[13:31:42.0000] <jgraham>
s/tests/bugs/

[13:31:51.0000] <jgraham>
The thing about testing

[13:32:03.0000] <Hixie>
i think it makes perfect sense to publish a patent policy snapshot, for sure

[13:32:36.0000] <Hixie>
but if they want to do that, why pretend they have a real test suite yet

[13:33:35.0000] <jgraham>
Hixie: and your assertion that there are 1000 tests with 100 asserts each is just wrong

[13:34:03.0000] <Hixie>
yeah, i later found http://www.w3c-test.org/html/dom/reflection-embedded.html which alone is 17% of the test suite

[13:34:27.0000] <Hixie>
so the 100 is more a mean than a median

[13:34:49.0000] <jgraham>
Counting files just doesn't make any sense

[13:35:19.0000] <jgraham>
You could put the same 100 tests in 100 files and 100 tests in 1 file

[13:35:36.0000] <jgraham>
It would be the same amount of testing

[13:35:58.0000] <SamB>
yeah

[13:36:12.0000] <Hixie>
sure. i was saying this in the context of robin comparing to the svg and css test suites, where he was citing test file numbers.

[13:36:36.0000] <Hixie>
svg had ~300 tests, but since each one tested a few hundred thousand pixels, it's more like 300,000,000 test assertions

[13:36:55.0000] <jgraham>
I think that's an absurd way to look at it

[13:37:01.0000] <SamB>
indeed

[13:37:09.0000] <Hixie>
it's not clear to me that numbers are a useful way to look at it at all

[13:37:12.0000] <Hixie>
what matters is coverage

[13:37:14.0000] <SamB>
many of those pixels aren't even all that important

[13:37:27.0000] <Hixie>
SamB: many of the test assertions aren't even all that important too :-)

[13:37:40.0000] <jgraham>
Not important in a different way

[13:38:26.0000] <SamB>
I mean, you know, it's not the end of the world if we don't get a byte-for-byte identical rasterization on every renderer

[13:38:39.0000] <jgraham>
I agree that counting tests isn't a very useful exercise

[13:39:17.0000] <jgraham>
But I also think that intentionally blocking progress on something we agree is useful for technical reasons is more stupid

[13:39:49.0000] <Hixie>
well sure. that the process is dumb is something i believe in so strongly that i quit the w3c.

[13:39:56.0000] <Hixie>
my complaint was in the context of robin saying this test suite was more useful than previous test suites, and trying to justify a huge error rate that way.

[13:40:04.0000] <SamB>
yeah, lintian actually has lots of tests that test many checks each

[13:40:19.0000] <Hixie>
(i posted my rant on public-html, fwiw)

[13:41:05.0000] <jgraham>
I saw

[13:41:19.0000] <jgraham>
I strongly suspect it is better than past testsuites

[13:41:20.0000] <SamB>
yeah, somehow I doubt the SVG testsuite outright fails at a single pixel component being off by one ...

[13:42:47.0000] <Hixie>
the CSS2.1 test suite isn't bad either

[13:43:06.0000] <Hixie>
i don't have a good handle on the coverage of either the CSS2.1 test suite or the HTML test suite, but the HTML test suite sure has some large holes

[13:43:18.0000] <Hixie>
(which isn't a criticism of the effort, it's obviously an on-going effort)

[13:43:30.0000] <Hixie>
(it's only a criticism of an attempt to use it as a proxy for something that has full coverage)

[13:44:46.0000] <SamB>
basically, I guess what I mean is that having tests fail when there is actually nothing wrong is BAD BAD BAD

[13:46:01.0000] <Hixie>
where are tests failing when there's nothing wrong?

[13:47:43.0000] <SamB>
Hixie: well, either there are loads HTML5 tests that are improperly failing, OR interop is actually fairly bad for the tested stuff

[13:48:00.0000] <Hixie>
interop is actually fairly bad for the tested stuff.

[13:48:16.0000] <SamB>
you don't just get to hand-wave away the failing tests

[13:48:16.0000] <Hixie>
the tested stuff that fails, anyway

[13:48:27.0000] <Hixie>
couldn't agree more

[13:48:44.0000] <SamB>
even if GDB's test suite *is* a gross offender here

[13:48:52.0000] <Hixie>
(that's why i predicted REC in 2022, not 2014, back when i cared about this)

[13:49:40.0000] <Hixie>
the fundamental problem is that the w3c is trying to use a broken process. They want patent coverage, which is a good thing to get ASAP, but their process says they can only get it once they have Proved Interoperability.

[13:49:54.0000] <Hixie>
there's just no reason they should gate the former on the latter.

[13:50:02.0000] <SamB>
it basically never goes green, so consequently it's not easy to catch new/reintroduced problems in the bud

[13:50:16.0000] <SamB>
Hixie: indeed

[13:50:21.0000] <SamB>
that's insane

[13:50:56.0000] <SamB>
they should demand the patent stuff ASAP

[13:59:51.0000] <zewt>
Hixie: i know nothing about the details, but maybe the agreements with people giving patent licenses depend on that, and they're afraid that asking everyone to change that could harm them somehow? (eg. "licenseholders review patent contract and someone decides they're better off keeping their landmines")

[14:01:15.0000] <Hixie>
not clear on what they could be concerned about

[14:01:24.0000] <Hixie>
a patent license is always against a specific piece of text

[14:01:31.0000] <zewt>
(not saying that'd be a good or bad reason, but it'd be a reason that I could parse)

[14:03:51.0000] <zewt>
it's not the patent license that would change, it's the process for giving the license

[14:05:00.0000] <zewt>
has the Process(r) for receiving patent licensing changed in recent memory (say, a couple years)?

[14:05:32.0000] <zewt>
(not an important question, just wondering if changing this would be opening an old box that nobody's modified in a decade, or if it's been dusted off periodically for something or other)

[14:05:33.0000] <Hixie>
no

[14:05:42.0000] <Hixie>
it's a decade+ old

[14:06:54.0000] <zewt>
well, if the compiler for changing the process (getting w3c members to agree to the change, possibly bringing Executives into the picture) hasn't been invoked in a decade, i could at least follow why they'd be uneasy about doing so

[14:07:51.0000] <annevk>
krit: http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0093.html reads a bit like STFU

[14:08:11.0000] <zewt>
(in any case i'd hope that the people who would initiate such a change would at least be willing to say in broad terms why they won't do it, so I guess there's not much point in my guessing)

[14:08:56.0000] <jgraham>
Hand waving away the failing stuff *for the purposes of the Process* is the only pragmatic way to get W3C to put some text under their patent policy and stop focussing on a out of date draft

[14:10:20.0000] <jgraham>
SamB: You can effectively use a testsuite where tests fail. You just have to know which tests fail

[14:10:38.0000] <SamB>
jgraham: okay, yeah, that can work too

[14:11:00.0000] <SamB>
but AFAICT we haven't got that either

[14:12:08.0000] <zewt>
jgraham: yeah, i guess the "50000 tests are failing, interop success!" silliness is ignorable if the only purpose is to invoke patent agreements (so long as BS'ing the test results like that doesn't jeopardize the license, which I'd hope it doesn't)

[14:12:31.0000] <jgraham>
SamB: We (Mozilla) do. It's not quite stable enough for production yet, but it works

[14:13:10.0000] <jgraham>
(and the code we use is open source and can be adapted for other browsers)

[14:15:14.0000] <krit>
annevk: the opposite is the case. I would like to see progress. You are right that the WG didn't spend a hell of time on fetching and security yet. Especially I didn't have much time.

[14:16:02.0000] <SamB>
jgraham: I was referring to GDB, in case that wasn't clear

[14:16:18.0000] <krit>
annevk: I really welcome help on this topic. I added some content so that people feel more encouraged to add stuff to the Wiki. It is less likely that people contribute to an empty Wiki.

[14:16:31.0000] <SamB>
where it'd tend to be at LEAST arch-dependent

[14:17:54.0000] <SamB>
and, hmm, I guess some of them depend on e.g. whether libc or gcc was built with "systemtap" probes

[14:19:28.0000] <SamB>
(not actually intended for use with systemtap, but using its sys/sdt.h and thus its probe ABI)

[14:20:11.0000] <jsbell>
Hixie: thanks for the events vs. microtasks answer. Exactly what I was hoping for.

[14:27:56.0000] <Hixie>
jsbell: np. it's got lots of rough edges still, unfortunately.

[14:35:21.0000] <jgraham>
SamB: Oh, it wasn't

[14:47:25.0000] <Hixie>
where do i file bugs to suggest something for the html test suite to test, again?

[14:47:50.0000] <Hixie>
https://github.com/w3c/web-platform-tests/issues ?

[14:48:54.0000] <Hixie>
looks like yes

[14:52:23.0000] <Hixie>
annevk: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25504

[15:25:20.0000] <TabAtkins>
JakeA: I don't know why you want a "soft fail" behavior for crossorigin stylesheets there.

[15:49:44.0000] <foolip>
Hixie: I don't have any ideas for https://www.w3.org/Bugs/Public/show_bug.cgi?id=24684#c22 I'm afraid

[15:50:55.0000] <foolip>
annevk: I've starred it for when I need to procrastinate

[16:01:47.0000] <caitp>
can anyone explain what "should" happen in a case like this? http://jsfiddle.net/Wz59M/1/

[16:02:11.0000] <caitp>
other than crashing FF nightly, that probably isn't supposed to happen

[16:03:00.0000] <caitp>
basically, from angular's POV, chrome is doing the "wrong thing" here, and firefox is doing the "right thing", but I just want to get a feel for "why" one or the other is the right thing

[16:04:27.0000] <Hixie>
half-way through the script, there's no options at all

[16:04:29.0000] <Hixie>
then you insert one

[16:04:33.0000] <Hixie>
so it's selected

[16:04:36.0000] <Hixie>
then you insert another

[16:04:51.0000] <Hixie>
and, well, there's already a selected one

[16:05:40.0000] <othermaciej>
I would expect “don’t show me” to show

[16:06:31.0000] <Hixie>
this is why the insertd one is selected: "If nodes are inserted or nodes are removed causing the list of options to gain or lose one or more option elements, or if an option element in the list of options asks for a reset, then, if the select element's multiple attribute is absent, the select element's display size is 1, and no option elements in the select element's list of options have their selectedness set to true, the user agent must set the selectedness

[16:06:42.0000] <caitp>
I think the issue is that, `x` does already have a selected option

[16:06:55.0000] <caitp>
you add another option which isn't selected, but chrome decides that it is selected

[16:07:34.0000] <caitp>
oh, we are removing the selected option

[16:07:46.0000] <othermaciej>
yeah, the selected option is removed before a new one is added

[16:07:59.0000] <Hixie>
i don't see anything in the spec that says what should happen when you add a second selected one...

[16:08:00.0000] <caitp>
okay, so inserting an option into a select with no options should select that option

[16:08:04.0000] <Hixie>
that's probably a bug...

[16:08:13.0000] <Hixie>
caitp: yeah, that part is clear

[16:08:19.0000] <Hixie>
caitp: it's the next insertion that's unclear to me

[16:08:23.0000] <Hixie>
file a bug? i gotta run, meeting

[16:08:30.0000] <caitp>
have fun :>

[16:08:57.0000] <othermaciej>
oh, right, it’s dynamically inserting an <option> with the selected attribute

[16:16:57.0000] <caitp>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23574 seems related, although i'm not familiar enough with that section of the spec to really explain it

[16:17:33.0000] <caitp>
at least, it's related to the bug on angular, not the underlying "insertion of option[selected]" I guess


2014-06-06
[18:27:27.0000] <a-ja>
MikeSmith: ping

[18:30:05.0000] <a-ja>
MikeSmith: dunno if you noticed, but styled scope got back out of blink...due to being buggy and no progress in 6+ months.  maybe need a warning for <style scoped> again?

[18:30:26.0000] <MikeSmith>
a-ja: dunno maybe

[18:30:41.0000] <MikeSmith>
I thought it was implemented elsewhere

[18:31:12.0000] <MikeSmith>
Firefox

[18:31:27.0000] <a-ja>
MikeSmith: i think it's in parsers....but, beyond that???

[18:31:55.0000] <MikeSmith>
it's implemented at least one other engine

[18:32:09.0000] <MikeSmith>
I think gecko

[18:33:05.0000] <MikeSmith>
plus I think there's also some polyfill for it

[18:33:33.0000] <a-ja>
think you're right

[18:34:05.0000] <MikeSmith>
so my current opninion is that we shouldn't annoy devs with warning messages if they're using polyfills

[18:35:07.0000] <MikeSmith>
at the time when Henri first added those this-is-unimplemented warnings, I think we didn't really have polyfills

[18:35:30.0000] <MikeSmith>
they weren't common at least, and maybe not even the word polyfill had been coined yet

[18:35:44.0000] <MikeSmith>
but the situation's different now

[18:39:10.0000] <a-ja>
i take it's way too early to consider <style nonce> and <script nonce> at this point

[18:39:36.0000] <a-ja>
...as called for by CSP 1.1

[18:46:50.0000] <MikeSmith>
a-ja: I guess the WebAppSec WG would need to file HTML spec bugs to get that added

[18:48:36.0000] <caitp>
do you ever feel like maybe having 900 working groups and 1800 specs isn't the best approach

[18:49:24.0000] <MikeSmith>
a-ja: but anyway @nonce is also already implemented and shipped

[18:50:06.0000] <MikeSmith>
caitp: there aren't that many WGs that matter. Most of them can be safely ignored

[19:19:46.0000] <Hixie>
MikeSmith: for the record, we designed many parts of HTML specifically so that they could be "polyfilled", so at the time we called it "shimmed"

[19:19:52.0000] <Hixie>
s/so/though/

[19:31:24.0000] <roc>
<style scoped> is shipping in Firefox I think

[19:32:47.0000] <a-ja>
roc: specificity probs ever resolved?

[19:32:59.0000] <roc>
dunno, ask heycam|away

[19:33:18.0000] <roc>
yeah, it's actually been shipping for quite some time

[19:33:58.0000] <a-ja>
/me needs to search bugs for @scope at-rule support, too

[19:43:42.0000] <MikeSmith>
Hixie: yeah but as far as the validatotor warnings it's just that nobody had actually started to do did much shimming of new features at the time we added those warnings

[19:44:34.0000] <MikeSmith>
Hixie: btw I thought Henri added those initially based on some part of the spec stating guidance for conformance checkers that they should warn about unimplemented features

[19:44:41.0000] <MikeSmith>
but maybe that was my imagination

[20:30:04.0000] <Hixie>
MikeSmith: dunno of such a section, but who knows

[22:35:49.0000] <JakeA>
TabAtkins: I was thinking about https://twitter.com/tabatkins/status/474209390254620672 - what were you thinking there?

[22:36:49.0000] <JakeA>
TabAtkins: I was thinking about https://twitter.com/tabatkins/status/474209390254620672 - what were you thinking there?

[00:18:19.0000] <annevk>
krit: what I'd like is some information as to why my input will now be used to some effect

[00:18:25.0000] <annevk>
krit: is there an active author/editor?

[00:21:49.0000] <zcorpan>
is there a spec for how drag-and-drop within contenteditable should work?

[00:29:41.0000] <krit>
annevk: The behavior ought to be specified in https://svgwg.org/specs/integration/ at some point. The reason this came up again at all was a request from WebAppSec WG. I hope that his gives new impulses to continue working on the spec + me slowly rolling out of other spec work like masking. I believe to find more time next month. However, if the Wiki

[00:29:41.0000] <krit>
progresses faster and the future structure of the document gets more clear, I am happy to do edits earlier. Editors are Cameron and me. You are right that many parts of the discussions haven't been added yet. I will search through the mailing lists next week. If you want to wait to see more progress on the wiki, I can understand it. But you are more than

[00:29:41.0000] <krit>
welcome to add notes to the Wiki sooner.

[00:30:05.0000] <krit>
annevk: the wiki is meant as a white board to collect ideas and thoughts. No need to write spec text there

[00:30:26.0000] <krit>
annevk: if you have any short notes in your mind, just add it

[00:30:36.0000] <krit>
annevk: links are fine as well

[00:59:31.0000] <annevk>
Domenic: "in prose" works if you're Allen or are keeping closely in touch with him, it doesn't really scale beyond that

[01:00:38.0000] <annevk>
krit: that link does not load

[01:00:49.0000] <annevk>
krit: "integration" seems kind of weird, HTML has no such chapter

[01:01:15.0000] <annevk>
krit: and things such as fetching and security are part of the core processing model, you can't just bolt them on somehow

[01:01:33.0000] <krit>
annevk: the purpose of the spec is covering eBooks and other languages including subsets of SVG as well

[01:01:56.0000] <krit>
annevk: :) Do not disagree

[01:02:33.0000] <annevk>
The fact that you guys can't even come up with a sane organization does not inspire confidence

[01:02:52.0000] <annevk>
And suggests nothing much has changed in the intervening years

[01:03:25.0000] <annevk>
These questions are not something you look at separately typically. You should come across these as you define SVG as a language

[01:14:59.0000] <krit>
annevk: SVG as a language has existed for more than 14 years. It is huge, it is complex. That members of the WG don't have as much time as the language deserves is more than unfortunate. But SVG is not the only specification suffering years of stagnation.

[01:15:44.0000] <krit>
Exmples are CSS OM for instance which has had multiple editors as well as far as I can remember, you were one of them.

[01:15:50.0000] <annevk>
That does suggest there's nobody to take on this issue

[01:16:17.0000] <krit>
It doesn't help to blame people instead we should look forward.

[01:16:59.0000] <annevk>
CSSOM has made steady progress. A great many things that was once undefined was defined over time. Not much new features, but the overall model was made much more clear and unambiguous.

[01:17:32.0000] <krit>
annevk: another point is probably the lack of experience in technologies like fetching... at least from the specification point of view.

[01:17:48.0000] <annevk>
As in, we went from HTML4-era level of detail to HTML5-era level of detail. That's pretty great I think.

[01:18:00.0000] <krit>
annevk: and we hope yo reach the same with SVG eventually

[01:19:00.0000] <annevk>
krit: I'm not trying to assign blame, I'm trying to figure out if there's anyone actively working on this and writing things down. We're not going to solve this by jotting notes on a wiki page and having teleconferences.

[01:19:10.0000] <annevk>
krit: This requires someone to put a few months of effort into this.

[01:19:51.0000] <krit>
annevk: honestly, I can not guarantee it. I can just promise that I do my best to keep it rolling.

[01:20:52.0000] <krit>
annevk: I do not have the possibility to work full time on this subject... all that I can offer is to help as much as I can.. even with editing

[01:22:55.0000] <krit>
annevk: I am not sure if heycam|away can, but he has a lot on his plate too. We can not just hand it over to anyone and force a different WG to take care of it. As you said, it is fundamental for SVG. But we can try to find help.

[01:24:01.0000] <zcorpan>
MikeSmith: https://github.com/ResponsiveImagesCG/picture-element/pull/204

[01:31:05.0000] <annevk>
krit: I guess I'm ready to help once there is someone actively working on it. This is not too different from how it was a couple of years ago.

[01:31:28.0000] <annevk>
(I hope heycam|away starts working on IDL. There's a ton of issues there :-()

[03:01:13.0000] <hsivonen>
Hixie, MikeSmith: validator.nu is back.

[03:01:42.0000] <hsivonen>
somehow, the VM's kernel modules have become broken enough that iptables-restore can't do its thing and the port mappings were missing

[03:02:08.0000] <hsivonen>
as a band-aid, I installed nginx to do proxying from one port to another

[03:02:29.0000] <hsivonen>
please let me know if POST or something like that broke

[03:02:55.0000] <hsivonen>
my other VMs don't have this problem

[03:05:28.0000] <hsivonen>
I'm guessing the reason for brokenness is an incomplete kernel update relative to Xen modules

[04:50:19.0000] <MikeSmith>
hsivonen: thanks I'll test and see if I notice any problems

[04:50:29.0000] <MikeSmith>
hsivonen: glad it wasn't my fault at least :-)

[05:15:31.0000] <annevk>
krit: how much time can you get from your manager?

[05:15:57.0000] <annevk>
krit: I'm happy to match your time and see how far we can get together

[05:38:52.0000] <krit>
annevk: I'll check this evening. I am actually close to your timezone CET

[05:42:31.0000] <jabbok>
hi all

[05:43:06.0000] <jabbok>
anybody got tips on using html5 notification api cross browser/platform?

[05:46:59.0000] <annevk>
krit: we're the same timezone these days

[05:47:12.0000] <krit>
annevk: did you move?

[05:47:23.0000] <annevk>
krit: yeah, I'm based in Zürich

[05:47:55.0000] <krit>
annevk: oh, didn't know

[05:47:57.0000] <jabbok>
annevk maybe?

[05:48:28.0000] <krit>
annevk: why did you move to Zurich? London needed the space for Servo?

[05:48:30.0000] <annevk>
jabbok: what's the issue?

[05:48:48.0000] <annevk>
krit: personal reasons, we don't really have an office here

[05:48:58.0000] <jabbok>
well whe’re trying to find a cross browser/platform notification method for ower webapp...

[05:49:04.0000] <krit>
annevk: ok :)

[05:49:23.0000] <jabbok>
maybe using the html5 notification api

[05:49:29.0000] <darobin>
the couldn't stand having him in the office so they sent him to the closest large city with no official presence

[05:49:56.0000] <krit>
annevk: with not real office, do you actually mean no office space at all?

[05:50:10.0000] <jabbok>
is there maybe some kind of javascript wrapper to make this work between browsers?

[05:51:09.0000] <darobin>
jabbok: check https://developer.mozilla.org/en/docs/Web/API/notification for support information and such

[05:51:34.0000] <jabbok>
I’ve been there, and in firefox this works all fine and dandy

[05:52:36.0000] <annevk>
krit: yeah I work from home

[05:52:59.0000] <jabbok>
but if i want to trigger a message with an event (dom ready for example) chrome doesn’t do that so it’s an api issue i think

[05:53:10.0000] <jabbok>
i thought maybe you guys would have suggestions

[05:53:11.0000] <krit>
annevk: well then meeting in Zurich is more difficult... IRC or video conference works too though

[05:53:13.0000] <annevk>
In Europe Mozilla has offices in Berlin, London, and Paris

[05:53:32.0000] <annevk>
krit: ooh, I was thinking meeting over IRC, but just having fulltime availability

[05:54:01.0000] <annevk>
krit: if you want an actual meeting maybe we can get TabAtkins and the Google office involved somehow :p

[05:54:32.0000] <krit>
annevk: k. Will check this evening without budget involved it is always easier to get some time

[05:55:39.0000] <annevk>
jabbok: hmm not sure

[05:55:46.0000] <annevk>
jabbok: I'd suggest stackoverflow.com

[05:55:58.0000] <jabbok>
those issues are all dated

[05:56:18.0000] <annevk>
jabbok: I don't get much further then trying to make sure the spec is okay and then moving to the next undefined thing

[05:56:31.0000] <annevk>
jabbok: but you can ask questions there, no?

[05:56:46.0000] <jabbok>
i’ll try that. Thanks for your time!

[05:56:55.0000] <jabbok>
and good luck on the standards ;)

[06:20:33.0000] <annevk>
JakeA: it seems that if we want SW to just modify the request and then return it (should change from null in that case I think), Fetch needs to restart from the top as the mode might have changed and such, no?

[06:23:14.0000] <annevk>
JakeA: e.g. if mode is same-origin and you change the url of the request, we're in trouble

[06:29:19.0000] <JakeA>
annevk: are we in trouble, or would it just fail?

[06:30:15.0000] <annevk>
JakeA: since step 6 of http://fetch.spec.whatwg.org/#concept-fetch is not currently I think we're in trouble

[06:33:36.0000] <annevk>
JakeA: it would actually help to have a set of use cases for modifying headers and mode

[06:34:15.0000] <annevk>
JakeA: as making sure "no CORS" fetches are <img>/<script>-compatible is hard

[06:35:33.0000] <JakeA>
annevk: if we go read-only, it's not going to stop us opening it up later is it?

[06:35:52.0000] <annevk>
JakeA: no

[06:36:24.0000] <annevk>
JakeA: it would probably still require answering the above question

[06:36:30.0000] <JakeA>
annevk: Let's shut it down. *looks into camera* shut it all down.

[06:36:36.0000] <annevk>
JakeA: e.g. I do think we your header use case to work

[06:36:44.0000] <annevk>
want*

[06:37:10.0000] <JakeA>
hah, can't remember it

[06:37:22.0000] <annevk>
JakeA: https://gist.github.com/jakearchibald/9f556ce0eafc47ba3d6e

[06:38:25.0000] <JakeA>
annevk: I've heard use-cases around tagging requests with priorities. Being able to polyfill headers like clienthints would be nice too.

[06:39:09.0000] <JakeA>
annevk: But you could do that with respondWith(fetch(event.request, modifications))

[06:39:18.0000] <JakeA>
annevk: except for the redirect issues

[06:40:07.0000] <JakeA>
annevk: For priorities we need to see how they'll be represented on the request object

[06:41:59.0000] <annevk>
JakeA: yeah, maybe that is better

[06:42:10.0000] <annevk>
JakeA: the modify existing request and then return it is kind of weird

[06:42:15.0000] <annevk>
JakeA: it'd be a new "default"

[06:46:43.0000] <JakeA>
annevk: I think it feels intuitive to modify the request object like that, but agree it's too complex in terms of the implementation for a first-pass

[06:47:14.0000] <annevk>
JakeA: so even if we drop that, if you do new Request() should you be able to set .mode?

[06:47:47.0000] <annevk>
JakeA: it's kind of unrelated whether we take https://gist.github.com/jakearchibald/9f556ce0eafc47ba3d6e into account

[06:47:59.0000] <JakeA>
annevk: Oh yeah, definately. Else how do I cache the JS on my CDN?

[06:48:28.0000] <annevk>
JakeA: well should be able to set Request.prototype.mode, of course you can set it through new Request()

[06:48:28.0000] <JakeA>
annevk: or do you mean set it *after* construction?

[06:48:58.0000] <annevk>
Yup

[06:49:15.0000] <JakeA>
annevk: I say lock it all down. We can open stuff up as we work it out & get good usecases

[06:49:22.0000] <annevk>
Okay

[07:50:36.0000] <annevk>
People who reply to GitHub via email, grr

[08:10:32.0000] <caitp>
whens the last time you tried to reply to github from your phone any other way? it's basically impossible :(

[12:03:24.0000] <zewt>
it should probably be possible to just reply to github notification emails and have it get translated into a reply (but I've never tried it)

[13:07:47.0000] <Hixie>
why does an argument with a default have to be explicitly marked as optional. isn't it obvious it's optional if it has a default? sigh.

[13:11:41.0000] <gsnedders>
Hmm, Google+ photo upload gave no choice of circles as far as I could see, and can't change it after upload? That's pretty screwed up.

[13:20:03.0000] <Hixie>
"Google+ photo upload"?

[13:20:08.0000] <Hixie>
you mean the autobackup feature?

[13:20:16.0000] <Hixie>
that just backs up to your account privately, it doesn't share it

[13:20:18.0000] <gsnedders>
nah, from the Android gallery app

[13:20:30.0000] <gsnedders>
the Google+ share, which is provided by the Google+ app, no?

[13:20:36.0000] <Hixie>
Gallery -> Share -> Google+ should give you an ACL editor

[13:20:55.0000] <gsnedders>
I couldn't see it anywhere, eh

[13:21:42.0000] <Hixie>
at the very top of the share dialog, there's an icon, a circle name, and a drop-down

[13:21:50.0000] <gsnedders>
Not here?

[13:22:01.0000] <Hixie>
show a screenshot?

[13:23:06.0000] <gsnedders>
It simply says "Geoffrey Sneddon\nTo Your Circles" with the  dropdown, with reshare/comment options. Seemingly, though it looks like a mere statement, you can change who its shared to be pressing on the "to x" bit.

[13:23:11.0000] <gsnedders>
Which wasn't obvious to me at all

[13:23:44.0000] <Hixie>
ah well i'm not going to make any arguments about how intuitive it is

[13:23:45.0000] <Hixie>
:-)

[13:24:02.0000] <Hixie>
you might be on a different version than i have

[13:24:35.0000] <gsnedders>
oh well, then I guess only people in my circles can read that wonderful user manual.

[13:25:40.0000] <gsnedders>
heh, hadn't even noticed the "Please strongly recommend reading the MANUAL before using the product". Who am I meant to recommend this to?

[13:27:41.0000] <jgraham>
gsnedders: If it helps you can recommend that I read the manual. Then you can use the product and I can ignore your recommendations, like normal :)

[13:58:25.0000] <gsnedders>
jgraham: as the manual says, "You can do everything u like as using a disk driver"

[14:04:43.0000] <Hixie>
yeah it's not like this was even just a matter of a bad automatic translation

[14:04:57.0000] <Hixie>
it's more that they hired a high school student as an intern to write the documentation

[14:05:06.0000] <Hixie>
and did no review

[14:06:54.0000] <gsnedders>
Interestingly, the manufacturer, CiT, appears to have no website.

[14:07:28.0000] <gsnedders>
On the other hand, it cost almost nothing and has good reviews


2014-06-07
[17:31:22.0000] <zewt>
fascinating is justifying blob urls not working for workers in IE because "it's not specifically allowed"

[17:31:42.0000] <zewt>
maybe the spec should enumerate every possible allowable URL, just to be "clear"

[19:09:27.0000] <TabAtkins>
JakeA: Right, but why do you need the friendly failover behavior? Just deny the stylesheet entirely if the cors check fails.

[21:51:00.0000] <Hixie>
zewt: actually it's specifically disallowed, unless blob: URLs (not their contents, the URL themselves) are defined as having a specific origin (as opposed to the unique origin, like data: URLs -- that's why the spec hard-codes data: URLs to make them work)

[00:20:53.0000] <JakeA>
TabAtkins: maybe I got the wrong end of the stick. When you mentioned fixing the spec when it came to stylesheets and CORS, what changes were you thinking of?

[00:22:17.0000] <TabAtkins>
I answered from the hip, and wasn't sure if cssom allowed the crossorigin attr yet.

[01:17:00.0000] <annevk_>
https://docs.google.com/file/d/0B4PVbLpUIdzoMDR5dWstRllXblU/edit async generators

[16:06:52.0000] <Hixie>
aw man

[16:07:05.0000] <Hixie>
i'm going through the parser tests in a somewhat random order

[16:07:24.0000] <Hixie>
but it seems somehow unfair that the second tree constructor test that i ended up having to deal with does foster parenting

[16:11:57.0000] <SamB>
/me hands Hixie some orphaned MIME messages

[16:12:11.0000] <Hixie>
hm?

[16:15:32.0000] <gsnedders>
Hixie: What random order?

[16:15:37.0000] <gsnedders>
Hixie: the order they're in the files?

[16:15:40.0000] <gsnedders>
that's pretty random :)

[16:16:29.0000] <Hixie>
well the file order i'm using is random

[16:16:36.0000] <Hixie>
apparently html5lib-tests/tree-construction/tests7.dat is the first test file i'm doing

[16:17:13.0000] <Hixie>
i got <!doctype html><body><title>X</title> to work

[16:17:18.0000] <Hixie>
now it's <!doctype html><table><title>X</title></table>

[16:17:23.0000] <gsnedders>
:)

[16:17:28.0000] <Hixie>
which seems ambitious for a second test to get right :-)

[16:17:48.0000] <gsnedders>
Just convert the spec into code using some NLP tool!

[16:17:52.0000] <Hixie>
hah

[16:18:13.0000] <Hixie>
how long does html5lib take to do all the tests, btw?

[16:18:33.0000] <Hixie>
i'm doing this to be faster, but i've no idea if i am :-)

[16:18:34.0000] <gsnedders>
some number of seconds

[16:18:49.0000] <gsnedders>
And on what implementation of Python?

[16:19:03.0000] <Hixie>
is there that much difference?

[16:19:08.0000] <zewt>
the universe is some number of seconds old

[16:19:27.0000] <gsnedders>
Hixie: tests, maybe not; general parsing, massively!

[16:19:44.0000] <gsnedders>
(tests have a lot of weird branches for parse errors taken frequently, real stuff mostly doesn't)

[16:20:36.0000] <Hixie>
interesting

[16:24:02.0000] <gsnedders>
for complete.html — CPython 2: 14.7s; CPython 3: 16.4s; PyPy: 7.7s

[16:26:07.0000] <gsnedders>
Hixie: also remembers whether modules for optional tree formats are installed; PyPy takes 33s to run all the tests in my current WC

[16:26:54.0000] <gsnedders>
I English good, it seem

[16:27:17.0000] <Hixie>
what's the difference between CPython and PyPy?

[16:28:07.0000] <gsnedders>
CPython is the reference implementation, a mere interpreter; PyPy is a tracing JITing VM

[16:28:36.0000] <Hixie>
ah

[16:29:02.0000] <Hixie>
i'll have to give you a binary when i'm done, have you compare that

[16:29:28.0000] <Hixie>
right now it probably does it in aout 20ms but crashes with "not implemented" about 2 lines in :-P

[16:29:37.0000] <gsnedders>
also note that that figure for the tests including serializer/sanitizer/etc. tests

[16:29:42.0000] <Hixie>
ah

[16:29:47.0000] <Hixie>
i'm only doing tokeniser/tree-constructor

[16:29:55.0000] <Hixie>
(and excluding some of those too, e.g. fragment tests)

[16:29:57.0000] <Hixie>
(iirc)

[16:30:06.0000] <gsnedders>
(it appears I really can't watch Buffy and type at the same time :))

[16:31:25.0000] <Hixie>
ho ho ho, i just found a bug in the html parser

[16:31:36.0000] <gsnedders>
in the spec?

[16:31:36.0000] <zewt>
nondeterministic GC in pypy makes me hesitant to go near it, though

[16:31:40.0000] <Hixie>
yeah

[16:31:44.0000] <Hixie>
one sec while i check my work

[16:31:49.0000] <gsnedders>
Do we implement the spec correctly? :)

[16:31:56.0000] <Hixie>
that's what i'm checking :-)

[16:32:13.0000] <gsnedders>
It wouldn't be the first time we've had bogus behaviour on the basis the spec did :)

[16:34:08.0000] <Hixie>
well gecko and blink seem to just ignore my mistake here, which seems wise

[16:34:13.0000] <gsnedders>
zewt: CPython is non-det GC too

[16:34:22.0000] <Hixie>
since otherwise they'd probably crash or create a crazy non-dom-valid dom

[16:34:23.0000] <Hixie>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3054

[16:34:24.0000] <zewt>
only with cycles

[16:34:40.0000] <gsnedders>
Besides, you can make it deterministic in both cases through gc.disable() :)

[16:34:54.0000] <zewt>
memory.splode()

[16:36:42.0000] <Hixie>
oh nevermind

[16:36:53.0000] <Hixie>
the spec actually checks for this later

[16:40:00.0000] <gsnedders>
Other problems with converting the spec text: coreference resolution.

[16:40:23.0000] <gsnedders>
Or not

[16:40:31.0000] <gsnedders>
Not such a big problem as I thought

[16:40:47.0000] <Hixie>
cowhat now?

[16:41:11.0000] <gsnedders>
Consider: "Consume the next input character; output the character".

[16:41:18.0000] <gsnedders>
What does "the character" refer to?

[16:41:27.0000] <Hixie>
aah

[16:41:29.0000] <Hixie>
yeah

[16:41:30.0000] <Hixie>
good luck!

[16:42:05.0000] <gsnedders>
I don't think you actually have that much coreference in the tokenizer at least though

[16:42:21.0000] <gsnedders>
Because you almost always (maybe always?) use "the current input character"

[16:43:21.0000] <Hixie>
man the foster parenting algorithm sure is described in a round-about way

[16:43:34.0000] <gsnedders>
Yes.

[16:44:12.0000] <gsnedders>
I think this Hixie guy is to blame there :)

[16:44:16.0000] <Hixie>
pah

[16:44:34.0000] <Hixie>
/me implements it completely differently and hopes he's right that it's isomorphic

[16:44:54.0000] <gsnedders>
Proving stuff is equivilent is hard given the spec machine is infinite state :(

[16:45:13.0000] <Hixie>
well proving that this subpart is equivalent should be easier

[16:46:21.0000] <gsnedders>
tbf, one can likely bound the stack of open elements at something like 10 elements and the list of active formatting elements similarly and then just argue everything will just be those with extra elements of no effect inbetween

[16:46:35.0000] <Hixie>
be careful about that

[16:46:41.0000] <Hixie>
noah's ark really screws with that

[16:46:55.0000] <Hixie>
if you do that you want a pretty high cap, iirc

[16:47:06.0000] <gsnedders>
Yeah, you will

[16:47:11.0000] <gsnedders>
I haven't tried to work it out

[16:47:23.0000] <SamB>
noah's ark is a technical term now?

[16:47:32.0000] <gsnedders>
I fear it's exponential to the number of formatting elements.

[16:47:43.0000] <Hixie>
SamB: so many silly terms in the parser, you've no idea

[16:47:50.0000] <Hixie>
SamB: it's the only way i could stay sane

[16:47:54.0000] <Hixie>
while writing it

[16:47:56.0000] <gsnedders>
/me takes a deep breath and carries on

[16:48:02.0000] <Hixie>
yeah, that one too :-)

[16:48:10.0000] <Hixie>
/me implemented that just yesterday (commented out, of course)

[16:48:11.0000] <gsnedders>
Hixie: Do you know of any bug for the spec being slow in Firefox?

[16:48:18.0000] <Hixie>
slow to load?

[16:48:19.0000] <Hixie>
no

[16:48:23.0000] <Hixie>
but it's a problem for sure

[16:48:29.0000] <SamB>
Hixie: that reminds me of \relax

[16:49:24.0000] <Hixie>
is it worrying when you implement an algorithm and your implementation has none of the variables of the original? :-)

[16:49:29.0000] <SamB>
/me isn't really TeXnically aware enough to know all that relax is good for ...

[16:49:42.0000] <SamB>
Hixie: it should worry someone

[16:49:45.0000] <gsnedders>
Hixie: Not replicating the WebKit HTML parser bug with </sarcasm> then? :)

[16:50:05.0000] <SamB>
hmm

[16:50:09.0000] <gsnedders>
Hixie: something around layout is slow when the window changes size, like to open the find box :(

[16:50:19.0000] <SamB>
gsnedders: where did that crop up?

[16:50:34.0000] <Hixie>
gsnedders: i still love that that happened

[16:50:46.0000] <SamB>
someone forgot to escape </sarcasm>, or was it inside a script or something?

[16:50:53.0000] <Hixie>
gsnedders: yeah, reflow is slow. dunno of a specific bug. cc me if you file one.

[16:51:05.0000] <gsnedders>
Hixie: k

[16:51:07.0000] <Hixie>
gotta go, bbl

[16:51:22.0000] <gsnedders>
SamB: https://bugs.webkit.org/show_bug.cgi?id=45645

[16:51:45.0000] <gsnedders>
SamB: This is the reason html5lib has tests for </sarcasm> :)

[16:51:47.0000] <SamB>
/me looks around for something spritely to open that on

[16:52:22.0000] <SamB>
has the standard managed to avoid mentioning </sarcasm> thus far?

[16:52:37.0000] <gsnedders>
The WebKit bug is there because the standard *does* mention it

[16:52:45.0000] <SamB>
hah

[16:53:00.0000] <gsnedders>
As Hixie said, the parser section is full of jokes

[16:53:05.0000] <zewt>
sure am tired of having to find obscure switches to tell MSVC to stop telling me that C functions like read() are "deprecated"

[16:53:38.0000] <gsnedders>
An end tag whose tag name is "sarcasm"

[16:53:38.0000] <gsnedders>
Take a deep breath, then act as described in the "any other end tag" entry below.

[16:53:43.0000] <gsnedders>
SamB: ^^

[16:53:52.0000] <SamB>
zewt: ouch

[16:54:03.0000] <gsnedders>
That's far too funny if you're actually in the middle of just implementing every single case one by one :)

[16:54:39.0000] <SamB>
does "take a deep breath" link somewhere?

[16:54:44.0000] <gsnedders>
nah

[16:54:58.0000] <gsnedders>
SamB: Seems like a bug. Report it! :)

[16:55:48.0000] <zewt>
uh, woah, now it's defaulting to having them as errors

[16:58:04.0000] <SamB>
zewt: so, um, the headers don't make it clear how to disable that?

[16:58:16.0000] <SamB>
you *did* look at the headers, right?

[16:58:33.0000] <zewt>
some of the warnings do ("#define this special thing" for sprintf()), but not read()

[16:58:36.0000] <SamB>
the funny thing is, read() doesn't have any buffer-size issues or anything

[16:59:08.0000] <zewt>
hell no i'm not going to dig into seventy-deep system headers, i'll let the web figure it out

[16:59:13.0000] <SamB>
I mean, like, can you see what construct is causing MSVC to treat those things as deprecated

[16:59:53.0000] <SamB>
yeah, I really don't like MSVC very much


2014-06-08
[17:01:17.0000] <SamB>
the one thing I've liked about it in the past is that I can actually get more-or-less a whole stack trace for code compiled with it

[17:01:46.0000] <SamB>
but maybe I could do that with an up-to-date GDB, too

[17:03:12.0000] <SamB>
(with GCC on windows, I've had to resort to stuff like using WinDbg alongside GDB and/or binutils)

[17:04:18.0000] <SamB>
(where WinDbg can unwind to my code -- and very likely also through it -- and GDB or binutils can help me with the addresses/name mappings)

[17:07:29.0000] <SamB>
(hmm, I guess intelisense is also kind of cool ...)

[17:07:43.0000] <SamB>
(but not cool enough to really want to deal with cl.exe ...)

[17:08:02.0000] <SamB>
(or, well, the compiler proper's probably in DLLs now ...)

[17:09:16.0000] <SamB>
Hixie: isn't the outline for http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html kind of nonsensical?

[17:11:51.0000] <Philip`>
zewt: "#define _CRT_SECURE_NO_WARNINGS" has worked in all the cases I've seen so far

[17:12:18.0000] <SamB>
do they seriously have a read_s?

[17:13:36.0000] <SamB>
/me reported https://www.w3.org/Bugs/Public/show_bug.cgi?id=26012

[17:15:18.0000] <gsnedders>
/me finally has a moment in which he thinks having text nodes is a good distinction from strings

[18:16:51.0000] <Domenic>
Hah, I like how in the WebKit source code there's an actual callTheAdoptionAgency(token); line

[18:19:22.0000] <SamB>
Domenic: well how would YOU name something that implements "call the adoption agency"?

[18:50:04.0000] <caitp>
"activateTerribleDesignDecision()"

[19:01:04.0000] <caitp>
seriously, who ever came up with that reparenting scheme... SMH ._.

[19:37:35.0000] <gsnedders>
caitp: see the acknowledgements section of the spec; Dave Hyatt

[19:37:58.0000] <gsnedders>
caitp: and if you start with the requirement that the DOM must be a tree, it's not clear you can do much better :(

[19:38:47.0000] <caitp>
gsnedders, this discussion has been had with hixie --- the DOM doesn't break when things don't get reparented, you can see this by dynamically inserting arbitrary content at places where it would ordinarily be reparented during parsing

[19:39:09.0000] <caitp>
it was a mistake to ever decide the DOM needed to reparent things, and it turns out to be very hard to fix that mistake ._.

[19:39:22.0000] <caitp>
but I don't like to name names when mocking terrible design decisions

[19:40:21.0000] <caitp>
people did it wrong before, and I guess we're stuck with it forever :(

[19:40:51.0000] <gsnedders>
But if you don't reparent you don't get a DOM that renders correctly, no?

[19:41:28.0000] <caitp>
you get a DOM that renders the way you expected it to be rendered when you authored your content wrong

[19:42:39.0000] <caitp>
the reparenting thing A) complicates things for no good reason, and B) makes things like custom elements slightly harder to implement correctly without the use of hackish nonsense like is=*

[19:43:14.0000] <caitp>
all to avoid breaking some awful smut website, I mean really

[19:43:38.0000] <gsnedders>
Plenty would argue "to avoid breaking some website" is a good reason. :)

[19:43:41.0000] <caitp>
people were not thinking when they decided this was something that needed to happen, but it's too hard to fix it =(

[19:46:06.0000] <gsnedders>
But, eh, the ship sailed when it came to misnested content tags before I could speak (probably).

[19:48:22.0000] <caitp>
from my perspective, my generation shouldn't have to pay for mistakes made by the generation that came a decade or two before, we should be fixing their broken crap

[19:48:33.0000] <caitp>
but herr ian disagrees

[19:49:19.0000] <gsnedders>
meh, plenty of evidence that breaking websites leads web browsers to lose marketshare and not websites being fixed

[19:50:05.0000] <caitp>
from my perspective, that's not a real excuse, if it leads to future work having to satisfy earlier, broken work

[19:50:16.0000] <caitp>
but people have their priorities, I guess

[19:50:20.0000] <caitp>
I just think they're getting it wrong in this case

[19:50:29.0000] <gsnedders>
convince the browser vendors to lose their marketshare, I guess

[19:50:50.0000] <gsnedders>
And there's again plenty of evidence what's in a spec doesn't really effect what browsers do in terms of breaking sites

[19:51:03.0000] <caitp>
that is certainly true

[19:51:49.0000] <caitp>
but the fact that the reparenting scheme lives in the spec sort of validates the decision to include broken stuff in the browser

[19:52:13.0000] <gsnedders>
Only difference the spec dropping it would make is the spec would cease to have implementations

[19:53:00.0000] <caitp>
if all vendors decided to ignore it

[19:53:06.0000] <gsnedders>
which they will

[19:53:26.0000] <caitp>
I don't think you can say "they will"

[19:53:45.0000] <caitp>
there are a lot of implementations out there

[19:54:23.0000] <gsnedders>
well, any impl with any real number of users will ignore it

[19:55:31.0000] <caitp>
I'm not sure about that, I don't think fixing that particular part of brokenness would hurt marketshare that much for a mainstream browser

[19:55:37.0000] <caitp>
and it would be temporary

[19:56:03.0000] <caitp>
you know why it's temporary, because people have their browser of choice, it's part of their identity, it becomes who they are!

[19:56:14.0000] <caitp>
that sounds silly, but it's not that much of an exaggeration, people have preferences for this stuff

[19:56:41.0000] <caitp>
pretty strong, irrational preferences

[21:21:58.0000] <Hixie>
/me runs into the fact that the stack of open elements is sometimes randomly mutated

[21:22:01.0000] <Hixie>
bummer

[21:22:06.0000] <Hixie>
that's gonna be exciting.

[22:18:07.0000] <Hixie>
hey someone double-check me here. In "push onto the list of active formatting elements", where the spec says "list markers", it should say "scope markers", no?

[02:19:08.0000] <jgraham>
Hixie: AFAICT there you use "list marker", in the definition above you use "scope marker" and everywhere else you use "marker"

[09:08:33.0000] <Hixie>
jgraham: k, that's what i concluded too

[09:15:42.0000] <jgraham>
Hixie: FWIW I think "scope marker" is a bad name since it requires a note that it doesn't correspond to the other notion of "in scope"

[09:41:12.0000] <Hixie>
jgraham: yeah...

[09:46:33.0000] <Hixie>
ok, renamed them all to just "marker", that's unambiguous enough

[09:46:38.0000] <Hixie>
also, made them all cross-refs

[09:50:04.0000] <jgraham>
Hixie++

[16:50:20.0000] <gsnedders>
http://anolis.gsnedders.com/ seems pretty silly

[16:50:24.0000] <gsnedders>
Why doesn't that just redirect?

[16:50:26.0000] <gsnedders>
o_O


2014-06-09
[19:13:15.0000] <Hixie>
wow, you sure have a lot of tests

[20:49:53.0000] <Hixie>
woot, i finally found a real bug in the parser tests

[20:54:36.0000] <Hixie>
oh wow, no, it's a spec bug

[21:12:40.0000] <Hixie>
/me fixes the spec

[21:12:52.0000] <Hixie>
looks like validator.nu already does this per the new spec

[21:13:19.0000] <SamB>
cool

[21:13:32.0000] <SamB>
just pretend it was always this way

[21:34:56.0000] <Hixie>
bummo, finally got to a test that relies on the script data less than sign state

[21:36:53.0000] <caitp>
bummo

[22:44:03.0000] <Hixie>
woops, the last checkin's message is bogus

[22:44:09.0000] <Hixie>
damnit

[22:44:54.0000] <caitp>
quick, force-push

[22:45:03.0000] <caitp>
before it's too late!

[22:45:11.0000] <Hixie>
don't think svn supports that, does it?

[22:46:36.0000] <SamB>
Hixie: no, but I think you *can* edit the commit message

[22:46:44.0000] <Hixie>
yeah, using svnadmin apparently

[22:46:55.0000] <Hixie>
i wonder where the repo actually is...

[22:47:01.0000] <SamB>
could do strange things to git mirrors ...

[22:47:09.0000] <Hixie>
aha, here we go

[22:47:21.0000] <Hixie>
eh, it's the checkin message

[22:47:24.0000] <Hixie>
how bad could it be

[22:48:35.0000] <SamB>
history would diverge depending on whether or not they saw the commit with the old message

[22:49:01.0000] <caitp>
i'm sure svn has full support for being terrible just like git does

[22:52:17.0000] <Hixie>
there, history has been revised.

[22:52:18.0000] <Hixie>
la la la.

[22:55:22.0000] <Hixie>
oh great, i found a bug in my tokeniser that the tokeniser tests didn't catch

[22:55:23.0000] <Hixie>
oops

[22:55:31.0000] <Hixie>
ok well now that i've broken everything it's time for bed. nn.

[23:40:23.0000] <Ms2ger>
"RESOLVED: Specs that define obsolete features don't need to test those features to exit CR."

[00:10:33.0000] <annevk_>
foolip: apparently Hixie changed a commit message in SVN, will that have bad effects on your mirror?

[00:11:32.0000] <annevk>
Ms2ger: what, for real?

[00:14:10.0000] <Ms2ger>
Part III of the Seoul notes

[00:14:48.0000] <annevk>
Oh wow, this was not from the HTML WG?

[00:14:52.0000] <annevk>
o_O

[00:15:01.0000] <Ms2ger>
No, CSS

[00:15:04.0000] <annevk>
/me is not impressed

[00:16:20.0000] <Ms2ger>
You should know I don't pay attention to the HTMLWG :)

[00:16:22.0000] <annevk>
So is the table display model now obsolete?

[00:48:25.0000] <foolip>
annevk: how did he do that?

[00:48:39.0000] <foolip>
but more importantly, which commit?

[00:48:46.0000] <annevk>
foolip: the last commit I think

[00:49:42.0000] <foolip>
let me check

[00:50:46.0000] <foolip>
do you know what the old and new message was?

[00:51:25.0000] <annevk>
foolip: old is what http://html5.org/r/8665 has

[00:52:12.0000] <annevk>
foolip: http://krijnhoetmer.nl/irc-logs/whatwg/20140609#l-142

[00:52:48.0000] <annevk>
Ms2ger: with Anolis, why if I have <dfn>origin</dfn> I cannot refer to an origin defined elsehwere?

[00:53:00.0000] <annevk>
Ms2ger: why is data-anolis-spec not stronger?

[00:53:01.0000] <Ms2ger>
Mm

[00:53:44.0000] <Ms2ger>
That's probably because those are implemented in different processes

[00:55:22.0000] <Ms2ger>
Try https://pastebin.mozilla.org/5378908

[00:55:39.0000] <annevk>
I'll hack around it

[00:56:11.0000] <annevk>
I want to switch to Bikeshed at some point anyway

[01:05:21.0000] <foolip>
annevk: html-mirror is now in sync with svn, but you'll probably need to force update your end since it's not a fast-forward commit

[01:07:04.0000] <annevk>
foolip: is there a way I can always do that?

[01:07:10.0000] <annevk>
foolip: so I don't have to do it if it happens again

[01:10:07.0000] <foolip>
yeah, you could fetch and reset --hard in your script

[01:24:38.0000] <annevk>
foolip: I can't get it to change

[01:24:48.0000] <annevk>
foolip: I tried git fetch --force; git reset --hard

[01:25:06.0000] <annevk>
foolip: also tried git pull --force

[01:26:38.0000] <foolip>
annevk: try simply git fetch and git reset --hard origin/master

[01:26:48.0000] <foolip>
(assuming you're on the master branch)

[01:29:26.0000] <annevk>
foolip: that seems to have fixed it

[01:30:06.0000] <annevk>
foolip: should I just change my script to that then?

[01:30:19.0000] <annevk>
I guess if Hixie does it again I'll do that

[01:34:05.0000] <zcorpan>
heycam|away: doesn't webidl allow single quotes? https://dvcs.w3.org/hg/csswg/rev/aec2cc899bab

[01:35:10.0000] <zcorpan>
http://heycam.github.io/webidl/#prod-string

[01:35:29.0000] <Ms2ger>
Apparently not

[01:35:37.0000] <zcorpan>
oh well

[01:36:25.0000] <zcorpan>
i actually run a webidl checker in the build process but it's flooded with missing interface type definitions so i missed that thing

[01:42:14.0000] <foolip>
annevk: there's a small risk that if my mirror breaks completely, reset --hard on your end will blindly follow along, leaving the web interface also broken until someone notices

[01:42:37.0000] <foolip>
I don't think it's going to matter much what you do, it'll be some work either way

[02:02:10.0000] <annevk>
foolip: okay, left it as is for now

[02:09:15.0000] <zcorpan>
annevk: the css "obsolete" was in the context of features that are non-web and must not be implemented by browsers

[02:09:16.0000] <zcorpan>
Ms2ger: ^

[02:11:55.0000] <zcorpan>
i guess it wouldn't hurt with negative tests, but OTOH i think it's fine to exit CR always

[02:27:29.0000] <Ms2ger>
I see

[02:32:21.0000] <annevk>
Maybe I'll merge XMLHttpRequest in sooner. There's a lot of potential code sharing between XMLHttpRequest and fetch()

[02:33:40.0000] <Ms2ger>
/me looks what fetch() looks like

[02:36:47.0000] <Ms2ger>
Ah, GlobalFetch,  there it is

[02:37:02.0000] <JakeA>
annevk: response.url, what did we decide that would be for constructed responses?

[02:37:24.0000] <annevk>
JakeA: the empty string, underlying object would be null

[02:37:30.0000] <Ms2ger>
annevk, do you want to implement Promises in Servo? :)

[02:37:35.0000] <zcorpan>
annevk: how do you suggest i fix addListener without invoking addEventListener?

[02:37:56.0000] <annevk>
zcorpan: you can use the underlying concepts just as addEventListener does

[02:38:04.0000] <annevk>
Ms2ger: not really

[02:38:37.0000] <zcorpan>
annevk: ok

[02:38:42.0000] <Ms2ger>
Would be nice if Servo did fetch() first

[02:38:52.0000] <annevk>
Servo should do Fetch first

[02:39:33.0000] <Ms2ger>
Not it :)

[02:39:39.0000] <JakeA>
annevk: So, if a page's CSP wanted to prevent constructed responses, we already have ways to detect that? We'd just need a CSP step after step 8 http://fetch.spec.whatwg.org/#http-fetch

[02:40:22.0000] <annevk>
JakeA: yes the idea for SW / CSP is to have a new step around there

[02:40:52.0000] <JakeA>
cool

[02:41:01.0000] <annevk>
JakeA: we still need to check if we do all the correct things with regards to redirects and such

[02:41:32.0000] <annevk>
JakeA: also currently response.url will be overwritten by request.url so we might need some distinct flag

[02:41:58.0000] <annevk>
JakeA: there's a bunch of things there we need to walk through carefully

[02:42:17.0000] <annevk>
I haven't done that, I'm mostly working on defining the API

[02:43:52.0000] <JakeA>
annevk: Is there any reason to overwrite response.url with request.url if the fetch is invoked recursively? That may be a good way to preserve it for the final CSP check

[02:44:18.0000] <annevk>
JakeA: yes, to make sure it's correct with respect to redirects

[02:44:34.0000] <annevk>
JakeA: otherwise e.g. responseURL on XMLHttpRequest would be wrong

[02:44:37.0000] <JakeA>
gotcha

[03:17:57.0000] <annevk>
JakeA: http://fetch.spec.whatwg.org/#fetchbodystream

[03:18:29.0000] <JakeA>
annevk: wfm!

[03:31:14.0000] <annevk>
JakeA: the main outstanding issue now is header representation

[03:32:04.0000] <annevk>
JakeA: I guess I'll try to tidy up everything aside from that

[03:32:27.0000] <annevk>
JakeA: if you could get some people to chime in on https://github.com/slightlyoff/ServiceWorker/issues/300 that'd be great

[03:53:09.0000] <toydestroyer>
Hi! Anyone here from Russian Google office in Moscow?

[04:04:51.0000] <JakeA>
annevk: Is anyone aside from Jonas against your proposal?

[04:05:16.0000] <annevk>
JakeA: not sure, also unsure whether HeaderMap is still the best name if it isn't really a map

[04:05:42.0000] <annevk>
Maybe just Headers

[04:08:23.0000] <JakeA>
annevk: Headers works, or HeaderData like FormData. I prefer just Headers.

[04:08:54.0000] <JakeA>
annevk: I think the proposal is spot on though. I don't think we need to make it a Map

[04:08:58.0000] <annevk>
Should we namespace all these classes? FetchHeaders, FetchRequest?

[04:09:12.0000] <annevk>
At the moment some are namespaced, some are not

[04:14:04.0000] <JakeA>
annevk: not keen on FetchRequest etc. Should it be HTTPRequest, or is it safe to assume http for browser requests?

[04:14:23.0000] <JakeA>
Although HTTPHeaders is clear

[04:14:24.0000] <annevk>
JakeA: HTTP is wrong for fetch()

[04:14:43.0000] <annevk>
JakeA: fetch() takes data URLs and such too

[04:15:17.0000] <JakeA>
annevk: Yeah, but when I do new Response(body) I'm creating an HTTP response

[04:15:25.0000] <JakeA>
anyway, I'm happy with just Response

[04:15:36.0000] <annevk>
JakeA: I'm not sure I see it that way

[04:15:58.0000] <annevk>
JakeA: e.g. Fetch (the spec) creates responses for data URLs too, they look like HTTP responses, but naming them such seems wrong

[04:17:04.0000] <JakeA>
fair

[04:22:30.0000] <jgraham>
annevk: I agree with your proposal fwiw

[04:57:44.0000] <Domenic>
annevk: so to('blob') ignores its argument if someone has previously called to('arraybuffer')? I think throwing an error would be better?

[05:01:45.0000] <Domenic>
errr return a rejected promise, of course

[05:15:38.0000] <Domenic>
annevk: > If the given value is not in the range 200 to 599, throw a TypeError. // should be RangeError

[05:17:46.0000] <annevk>
Domenic: you mean it would only work once?

[05:18:05.0000] <annevk>
JakeA: ^^

[05:18:31.0000] <annevk>
Domenic: happy b-day btw

[05:19:04.0000] <JakeA>
Domenic: Ohh, happy birthday! Are you allowed to drink in pubs yet? :P

[05:19:27.0000] <Domenic>
annevk: thanks :). and, gtg, but yes, once you consume the stream, it's all gone. can discuss more later, maybe will open an issue or something

[05:19:31.0000] <JakeA>
annevk: If streams can only be consumed once, then to() should reject on second calling

[05:43:26.0000] <annevk>
JakeA: we could make to() store the contents somewhere, but it's prolly better to just throw it away I guess

[05:44:11.0000] <JakeA>
annevk: throwing away sounds better. More compatible with streams and better for memory

[05:53:29.0000] <annevk>
fixed

[05:56:15.0000] <zcorpan>
mathiasbynens: you must be new here (re https://github.com/ResponsiveImagesCG/picture-element/issues/198 )

[05:56:46.0000] <mathiasbynens>
zcorpan: i guess I should go see the topic ^ now?

[05:56:59.0000] <zcorpan>
mathiasbynens: yes :-)

[05:58:10.0000] <zcorpan>
mathiasbynens: so in this case i'd expect people to use <picture> and test in a browser without support for <picture> (using picturefill or so) and conclude that everything is fine

[05:58:38.0000] <zcorpan>
but maybe it's not much of an issue

[05:59:06.0000] <zcorpan>
(or they test in a browser with support for <picture> but don't test dragging)

[06:59:19.0000] <annevk>
Domenic: should Response.redirect() throw RangeError too?

[07:24:17.0000] <caitp->
aitp

[07:25:07.0000] <caitp>
irc clients mang, they're not very good

[07:50:38.0000] <MikeSmith>
hey caitp

[07:52:21.0000] <caitp>
good morning MikeSmith senpai

[07:52:34.0000] <MikeSmith>
heh

[07:54:47.0000] <MikeSmith>
caitp: been meaning to ask you about https://github.com/w3c/web-platform-tests/pull/981

[07:54:58.0000] <MikeSmith>
Does that need review from annevk maybe?

[07:55:31.0000] <MikeSmith>
oh I see Simon commented on it

[07:55:52.0000] <caitp>
there was an issue opened about it on fetch or xhr, I forget

[07:56:15.0000] <MikeSmith>
ok

[08:06:52.0000] <Domenic>
annevk: ya RangeError there too I think.

[08:06:59.0000] <Domenic>
annevk: use GitHub issues and link to them from the top :)

[08:07:57.0000] <annevk>
Domenic: don't really want to migrate the existing setup

[10:33:04.0000] <hemanth>
From v0.11.6 I'm waiting for direct proxies in node..now we are at v0.11.13 still they havn arrived..:/ but why?

[10:43:54.0000] <Domenic>
hemanth: nobody is working on proxies in V8.

[10:44:22.0000] <Domenic>
https://code.google.com/p/v8/issues/detail?id=1543

[10:46:19.0000] <hemanth>
Domenic, Holy Goodness, it was reported on Jul 7, 2011! :(

[10:47:54.0000] <Domenic>
hemanth: implementer priorities are what they are... age of a feature doesn't really make much of a difference.

[10:48:31.0000] <annevk>
2011 is nothing

[10:49:55.0000] <hemanth>
Why are they finding it hard to sync up!? AFAIK SpiderMonkey is the only one which is almost up to the mark...

[10:50:20.0000] <zewt>
people have a lot to work on?

[10:50:59.0000] <hemanth>
But why have Proxy.create()? Rather remove it.

[10:51:07.0000] <TabAtkins>
annevk: Context for "obsolete doesn't need to be tested" is some property values that we're only defining in an informative appendix as having been supported by some printers, never browsers.

[10:51:08.0000] <Domenic>
SpiderMonkey also seems more willing to push out mostly-compliant, but unoptimized, versions of ES6 features.

[10:51:22.0000] <Domenic>
hemanth: they don't have Proxy.create() unless you turn on flags

[10:51:53.0000] <annevk>
TabAtkins: yeah, zcorpan mentioned that, I guess that's fine

[10:52:09.0000] <hemanth>
Domenic, Yeah, in any case for most of the ES6 features we need to turn on the flag

[10:55:20.0000] <hemanth>
I can understand it's tough for all the implementer to be in sync, but atleast when they are implementing a new spec, they can try to be, right? Each time a new spec is being implemented again the same mistakes are repeated....

[10:55:36.0000] <TabAtkins>
annevk: Yeah, things which need to be supported by browsers obviously need testing, even if they're obsolete and not to be used by authors.

[10:55:54.0000] <hemanth>
Sorry, but I'm finding it hard to understand the underlying problem.

[10:56:08.0000] <annevk>
hemanth: wrong channel to complain about V8

[10:56:15.0000] <hemanth>
/me sits at a corner. 

[10:57:08.0000] <hemanth>
No response at #node.js; annevk. I'm not complaining, just trying to understand...

[10:58:13.0000] <hemanth>
<pachet> hemanth: because proxies are evil and will cause all of your friends to stop talking to you

[10:58:23.0000] <hemanth>
^ heh heh from #node.js

[10:58:47.0000] <annevk>
hemanth: there's no infinite resources for a project so there is some balancing between new features, improving existing features, fixing bugs, perf, security, etc.

[10:59:16.0000] <annevk>
hemanth: then there's been ongoing discussion on the proxy design over in TC39 over the past couple of years which will likely lower priority for implementing it, etc.

[10:59:33.0000] <annevk>
hemanth: age of the bug doesn't really matter, there's decade old bugs that haven't been fixed yet

[11:01:59.0000] <hemanth>
Thanks for the insight annevk.

[11:02:30.0000] <hemanth>
/me makes a note in his diary : "So it's all about implementer priorities and finite resources."

[11:03:02.0000] <caitp>
that's a recurring theme around here

[11:03:37.0000] <hemanth>
:)

[11:04:22.0000] <Hixie>
well "If the next token is a U+000A LINE FEED (LF) character token, then ignore that token and move on to the next one" is a huge pain in the neck...

[11:04:25.0000] <Ms2ger>
Indeed

[11:06:04.0000] <Hixie>
i guess the tree constructor just has to set a flag on the tokeniser

[11:15:01.0000] <hemanth>
Can anyone state an example for an exotic object?

[11:15:01.0000] <Hixie>
Window

[11:15:01.0000] <Hixie>
(right?)

[11:15:02.0000] <Hixie>
(or no?)

[11:15:02.0000] <Ms2ger>
[]?

[11:15:50.0000] <hemanth>
Window heh heh yup, [] not sure.

[12:42:44.0000] <annevk>
yay, feedback from Microsoft

[13:00:58.0000] <annevk>
JakeA: Domenic: if to() reads all, what happens if you then store it?

[13:01:06.0000] <annevk>
JakeA: Domenic: there won't be anything, that seems kinda sad

[13:41:07.0000] <Domenic>
annevk: what do you mean, "then store it"?

[14:55:06.0000] <estellevw>
on http://www.w3.org/TR/html-markup/input.button.html the constraints and admonitions make it seem like list is a valid attribute. While it does not mention the list attribute as a valid attribute in the first half of the document, adding "The list attribute of the input element must refer to a datalist element." on the button type page makes it seem like it would actually do something. Does anyone know who edits these pages, and if it makes sense to bu

[14:55:07.0000] <estellevw>
them to remove that line?

[14:57:43.0000] <Domenic>
estellevw: did you see the abstract at http://www.w3.org/TR/html-markup/Overview.html ?

[14:58:04.0000] <estellevw>
nope. i did not. thanks

[15:01:01.0000] <estellevw>
wow. those pages aren't as informative as the archive. I need to do some updating. (Anyone have a time traveler I can borrow so I can find the time.)

[16:52:41.0000] <Hixie>
hm, that's odd

[16:52:45.0000] <Hixie>
my mail to es-discuss didn't make the archives?

[16:56:11.0000] <Hixie>
/me tries sending it again

[16:59:16.0000] <Hixie>
hey anyone know how we're doing with dropping mutation events?


2014-06-10
[17:07:04.0000] <zewt>
are sandboxed iframes included in a "unit of related similar-origin browsing contexts"? (seems like they are)

[17:07:24.0000] <zewt>
(tokens like "unit of related similar-origin browsing contexts" remind me of my Netware days)

[17:08:09.0000] <Hixie>
depends on their origin

[17:08:26.0000] <zewt>
oh, yeah, missed the distinction between that and "directly reachable browsing contexts"

[17:08:38.0000] <zewt>
which is probably what I was thinking more of

[17:10:34.0000] <zewt>
(FWIW "that, through appropriate manipulation of the document.domain attribute, could be made to be the same as other members of the group, but could not be made the same as members of any other group" seems a bit more spec-by-describing-the-result than most of HTML)

[17:10:52.0000] <Hixie>
yup

[17:11:06.0000] <Hixie>
spec-by-describing-the-result is the better way to write a spec, if you can do so in a way that describes all the cases

[17:11:41.0000] <TabAtkins>
Yup, that's what using grammars do, too. (And why using grammars isn't always the right choice for parsing.)

[17:11:42.0000] <Hixie>
often, though, especially with things like processing inputs, parsing, etc, describing steps results in much less prose than describing results

[17:15:22.0000] <Hixie>
damnit, i spent all afternoon tracing this one bug, and it's all because i assumed "continue" would skip the loop condition and just jump back to the top

[17:15:27.0000] <zewt>
it's easily the line in the spec I've had to squint the hardest at to figure out what it's saying to do

[17:16:05.0000] <Hixie>
yeah... the advantage of writing it that way is that the spec writer doesn't have to do the work :-)

[17:16:08.0000] <TabAtkins>
Hixie: On a for loop? Yeah, it skips to the top, but then it processes as normal.

[17:16:18.0000] <Hixie>
TabAtkins: repeat...until loop, but yeah, same deal

[17:16:23.0000] <TabAtkins>
"continue [to the next iteration]"

[17:16:25.0000] <TabAtkins>
Ah.

[17:16:39.0000] <TabAtkins>
do/while loops are just while loops that dont' test their first iteration.

[17:16:42.0000] <Hixie>
i knew this, i just happened to make two changes at the same time that interacted and didn't think about it

[17:16:47.0000] <zewt>
repeat until? ... pascal? heh

[17:17:13.0000] <Hixie>
i miss perl's loop control

[17:17:20.0000] <Hixie>
perl has awesome loop control

[17:17:35.0000] <Hixie>
next, last, redo, continue, loop labels...

[17:17:45.0000] <zewt>
usually if i'm getting annoyed at things like needing to break out multiple levels, i just break stuff into a nested function

[17:18:07.0000] <zewt>
beyond that the standard mechanics usually work well for me

[17:18:21.0000] <zewt>
(which I guess is just continue and break)

[17:18:32.0000] <Hixie>
if your loop body is one line, breaking it into a function makes it way harder to read

[17:18:56.0000] <zewt>
if my loop body is one line, there aren't multiple levels to break out of

[17:19:23.0000] <Hixie>
inner loop body

[17:19:33.0000] <Hixie>
or if you have a complicated nesting of multiple loops

[17:19:58.0000] <zewt>
i mean taking eg. for(x=0; x < width; ++x) { for(y=0; y < height; ++y) { break 2; } }, making the whole thing a function and just using return

[17:20:09.0000] <Hixie>
the point being that if your "code" is brief compared to your loop logic, splitting into a function ends up being harder to read than perl-style control

[17:21:19.0000] <SamB>
zewt: how does turning it into a non-local return help?

[17:21:45.0000] <zewt>
function() { for(x=0; x < width; ++x) { for(y=0; y < height; ++y) { return; } } }

[17:21:56.0000] <SamB>
oh

[17:21:56.0000] <zewt>
exits the whole loop

[17:22:04.0000] <SamB>
well, that's still no goto

[17:22:11.0000] <Hixie>
make it three levels of loops where the inner lever has to break out of the inner two but not the third

[17:22:14.0000] <SamB>
or whatever they have in Pascal

[17:22:21.0000] <Hixie>
to see what i mean about functions being unclear compared to inline loop control

[17:22:32.0000] <zewt>
it's a workaround and things like break statements that supply a number of levels to break might be a bit better (i assume perl has something like that), but that's the only loop construct i tend to need a workaround like that for

[17:22:45.0000] <Hixie>
pascal's as bad as C as far as loop control goes

[17:22:56.0000] <Hixie>
perl has labeled loops

[17:22:59.0000] <Hixie>
so you say e.g.:

[17:23:02.0000] <SamB>
hmm, okay, perl

[17:23:09.0000] <zewt>
for(z=0; z < 10; ++z) ( (function() { for(x=0; x < width; ++x) { for(y=0; y < height; ++y) { return; } } })(); }

[17:23:26.0000] <Hixie>
file: while (...) { ...; line: while (...) { ...; next file; } }

[17:23:26.0000] <zewt>
looks shitty on one line, of course, and it's still a workaround, but it's not terrible

[17:23:38.0000] <Hixie>
or next line, or redo line, or last file, or whatever

[17:23:49.0000] <Hixie>
for all the various combinations you might want

[17:24:09.0000] <Hixie>
(this is one of the few things about perl that's actually a net good, even to readability, imho :-) )

[17:24:42.0000] <SamB>
so is JS in the same boat as Python here?

[17:25:17.0000] <Hixie>
js is like c and company here, i think, right?

[17:25:26.0000] <Hixie>
dunno what python's loop control looks like

[17:25:35.0000] <TabAtkins>
You can break a loop using labels in JS, but you can't continue one from a label.

[17:25:53.0000] <Hixie>
oh, cool, ok

[17:26:01.0000] <Hixie>
so, in between

[17:29:43.0000] <SamB>
Python doesn't have labels at all

[17:37:39.0000] <TabAtkins>
Yeah, Python's annoying in that.  They say "don't get yourself into situations where you have to break/continue from multiple loops up", but sometimes it happens and it's the clearest way to write!

[17:37:55.0000] <TabAtkins>
And having to use flags to simulate the behavior is just dirty.

[17:38:21.0000] <zewt>
i usually switch to a nested function before using a flag

[17:42:44.0000] <SamB>
TabAtkins: I know!

[17:43:48.0000] <zewt>
my current annoyed-at language is C#, where someone who thinks they know better than me tells me how to write code

[17:44:29.0000] <zewt>
re: prohibiting switch fall-through, because some idiot read a "considered harmful" rant and decided to make my decisions for me

[17:45:10.0000] <TabAtkins>
Yeah, the case against switch fall-through is against *default* fall-through.

[17:45:29.0000] <SamB>
yeah, there should be a "fallthrough" statement or something

[17:45:33.0000] <TabAtkins>
Just changing the default and having some way to indicate that you should fall through is obviously the right way.

[17:45:54.0000] <SamB>
there is probably only one reason Python does not suffer from the same thing though

[17:45:57.0000] <ChrisMorgan>
/me contests the obviousness of that

[17:46:19.0000] <zewt>
well, python ... doesn't have switch

[17:46:23.0000] <ChrisMorgan>
And, for that matter, the truth of it.

[17:46:30.0000] <SamB>
zewt: yes, that's the reason

[17:46:40.0000] <TabAtkins>
zewt: Yes. which is also terrible.

[17:47:02.0000] <TabAtkins>
ChrisMorgan: I'll see your contestation, and raise you all the times I fell through accidentally because I forgot to say "break", and thus had a bug.

[17:47:31.0000] <TabAtkins>
I *rarely* want to fall-through on a switch.  It's common per-switch, but rare per-case, I think.

[17:47:33.0000] <ChrisMorgan>
TabAtkins: I’m with C♯ on this—forbidding fallthrough altogether is entirely reasonable.

[17:47:40.0000] <SamB>
ChrisMorgan: you think it should require explicit goto insteaa?

[17:47:43.0000] <TabAtkins>
That just means duplication.

[17:48:01.0000] <ChrisMorgan>
SamB: not that either.

[17:48:40.0000] <zewt>
if i'm trying to do a switch fallthrough, it's for a reason; the language needs to get out of my way unless there's some underlying structural reason why the language can't do it

[17:48:46.0000] <ChrisMorgan>
TabAtkins: normally there is not actually any basic need for fallthrough in the first place.

[17:49:25.0000] <SamB>
well, it isn't all THAT much more likely than wanting to goto somewhere else, I guess ...

[17:49:27.0000] <ChrisMorgan>
zewt: in Rust, or for that matter *any* language with proper pattern matching, fallthrough in `match` branches would make no sense whatsoever.

[17:50:01.0000] <ChrisMorgan>
/me has never felt the slightest pang of remorse or yearning for fallthrough in Rust

[17:50:04.0000] <SamB>
ChrisMorgan: I hope they have guards though

[17:50:15.0000] <ChrisMorgan>
SamB: to be sure, to be sure.

[17:50:23.0000] <ChrisMorgan>
All armed to the teeth! ;-)

[17:50:44.0000] <SamB>
I mean, conditions for the case matching at all

[17:51:05.0000] <ChrisMorgan>
To be sure, to be sure.

[17:51:05.0000] <TabAtkins>
ChrisMorgan: I see your attestation and raise you all the times in the CSS Syntax spec where I'm explicitly doing fall-through in my English-language switch statements. ^_^

[17:52:46.0000] <ChrisMorgan>
TabAtkins: I’m not familiar with your specific examples, but most of the ones that I imagine to be of the same nature are “if this is the case, follow these steps”, which does not need to be modelled as fall-through, though that is often one way of doing it (and not the most general, I might add).

[17:53:00.0000] <ChrisMorgan>
But hey—Swift uses pattern matching, so it *must* be right, huh?

[17:53:51.0000] <TabAtkins>
ChrisMorgan: No clue what Swift does, so shrug.

[17:54:17.0000] <TabAtkins>
I'm just talking about switch statements, which are indeed different from pattern matching.

[17:54:32.0000] <ChrisMorgan>
Back on the topic of labels, the funny thing is that Rust supports labels on its `for` and `loop` loops, but not its `while` loops… a strange omission which I had fun with, https://github.com/mozilla/rust/issues/12643.

[17:55:45.0000] <ChrisMorgan>
TabAtkins: I can’t speak much of Swift either, but at the theoretical level, switch statements, assuming no fall-through, provide a strict subset of the functionality of pattern matching.

[17:56:06.0000] <ChrisMorgan>
Anyway, this is probably all moderately off-topic for #whatwg!

[17:56:32.0000] <TabAtkins>
It's the "subset" part that makes it different.  If you're not extracting anything, just doing abbreviated testing (like normal switches do), then fallbacks make more sense, as a disjunction of cases.

[17:56:48.0000] <TabAtkins>
(Plus the occasional fun bit where you do some preliminary work in some cases and then fallthrough to the base-case to do more work.

[17:56:50.0000] <TabAtkins>
)

[17:57:25.0000] <TabAtkins>
(But that only works if you've only got a single type of prelim work to do, or if your multiple types are chained. If you have multiple parallel types of prelim work to do, you can't model it with fall-through.)

[17:59:28.0000] <ChrisMorgan>
`switch foo { bar: code1; baz: code2; break; default: code3; }` => `match foo { bar | baz => { if foo == bar { code1 } code2 }, _ => code3 }`. These should have the same performance characteristics when compiled.

[18:12:19.0000] <TabAtkins>
Is it appropriate to use [SameObject] on an attribute which occasionally swaps out its underlying value?

[18:12:23.0000] <TabAtkins>
But otherwise always returns the same object?

[18:23:03.0000] <TabAtkins>
annevk: Do I need to use [Exposed] on events too?  Or just normal interfaces?

[18:33:07.0000] <TabAtkins>
Hixie: Did you mean to make the :target arrow also slightly tilted?

[20:04:31.0000] <SimonSapin>
TabAtkins: for what it’s worth, I used a lot of pattern matching in rust-cssparser and never missed fall-through

[20:04:54.0000] <SimonSapin>
(but I do miss pattern matching a lot when going back to Python)

[20:06:15.0000] <Hixie>
TabAtkins: vaguely

[20:16:13.0000] <Hixie>
ok i've tried to post this to es-discuss twice now

[20:16:22.0000] <Hixie>
and i get nothing back and it doesn't go to the list

[20:16:29.0000] <Hixie>
i'm still subscribed...

[20:52:22.0000] <hemanth>
jorendorff, If you are around, just posted https://bugs.ecmascript.org/show_bug.cgi?id=2981

[22:19:42.0000] <annevk>
TabAtkins: events are normal interfaces

[22:20:09.0000] <annevk>
Domenic: I mean you want to store these objects some storage API

[22:22:12.0000] <TabAtkins>
annevk: kk

[23:13:56.0000] <Domenic>
annevk: yeah, you should generally just read them to the end and store the serialized version, or alternately stream them into a store

[23:13:59.0000] <annevk>
Hixie: another infographic I'd be interested in is one explaining the relationship of the higher-level object model; how browsing contexts relate to globals, relate to documents, relate to cross-origin Location objects, relate to settings objects, etc.

[23:14:16.0000] <Hixie>
that would be one hell of an inforgraphic

[23:14:32.0000] <annevk>
Domenic: my problem is that a developer might want to read data and store the Response

[23:14:37.0000] <annevk>
Domenic: currently that's not feasible

[23:14:46.0000] <annevk>
Hixie: yeah :(

[23:15:15.0000] <annevk>
Hixie: I still find it hard to follow at times what of the various objects I should look at from script and what I can reach from there

[23:17:26.0000] <Hixie>
annevk: http://junkyard.damowmow.com/542

[23:17:34.0000] <Domenic>
annevk: Ah yeah makes sense. Not sure how it would work generally for streams, since e.g. their content can be nondeterministic. (a Response body stream could be the product of the particular time on the server, or of a particular interaction between client and server, for example.) But maybe in this particular case we could define that it reads them to end

[23:17:34.0000] <Domenic>
at the time of storage, and then when it gets revived from cache it becomes a sort of "constant stream."

[23:17:34.0000] <Hixie>
HTH

[23:18:01.0000] <annevk>
Hixie: have a good night :p

[23:18:06.0000] <Hixie>
:-P

[23:19:02.0000] <annevk>
Domenic: okay, and if you wanted to read it to inspect it and store the object you'd have to tee it?

[23:20:09.0000] <Domenic>
annevk: in general yes, if you want to read without consuming you need to tee

[23:20:10.0000] <annevk>
Domenic: how do you distinguish between an empty stream and a depleted stream?

[23:21:55.0000] <Domenic>
annevk: good question, might not get this right off the top of my head, but I think: depleted will be "closed" already; empty will start "open" until you try to wait for more data to come in, at which point it becomes "closed"

[23:22:24.0000] <annevk>
Domenic: ah okay, closed vs open is nice terminology

[23:22:39.0000] <annevk>
Domenic: I should probably update my abstract stream description in Encoding to use that

[23:23:26.0000] <Domenic>
And I should probably update the "model" section to have more useful terminology of the sort. Will do at work tomorrow! :)

[23:25:13.0000] <annevk>
Yay model

[23:25:49.0000] <krit>
annevk: Hi

[23:25:50.0000] <annevk>
Yeah we need a model if we want to do this right. Rewrite all the things in terms of that and then slowly open them up to APIs

[23:25:55.0000] <annevk>
krit: morning

[23:26:36.0000] <krit>
annevk: Checked and would be available next week. Would you be able to look at SVG sec and have time?

[23:27:31.0000] <annevk>
krit: yes, let's do it

[23:28:06.0000] <krit>
annevk: cool. bringing kids to school usually. So am available from 9AM to whatever

[23:28:33.0000] <annevk>
krit: same here, this is really early for me

[23:28:52.0000] <krit>
annevk: bringing kids to school? :)

[23:28:58.0000] <Hixie>
huh

[23:29:02.0000] <annevk>
krit: I was about to correct that bit

[23:29:06.0000] <Hixie>
"in select" mode, <select> doesn't check if a select is in scope

[23:29:21.0000] <Hixie>
i think, per spec, <select>.innerHTML = '<select>' should crash

[23:29:27.0000] <Hixie>
am i crazy?

[23:31:00.0000] <annevk>
Hixie: the note "It just gets treated like an end tag." does make it seem like there's a bug there

[23:31:45.0000] <annevk>
Hixie: although "Pop elements from the stack of open elements until a select element has been popped from the stack." probably does not cause a crash

[23:32:07.0000] <Hixie>
you pop all the elements, then try to pop the stack when it's empty

[23:32:25.0000] <Hixie>
it'll either hang or crash or something bad will happen

[23:32:36.0000] <Hixie>
/me fixes the spec

[23:33:24.0000] <annevk>
Hixie: wouldn't you null-check the stack?

[23:33:30.0000] <Hixie>
and do what?

[23:33:46.0000] <Hixie>
i mean normally you shouldn't need to

[23:33:52.0000] <Hixie>
the parser isn't going to pop all the nodes off

[23:35:42.0000] <annevk>
Not sure, but e.g. in JavaScript [].pop() doesn't kill you

[23:35:56.0000] <Hixie>
well sure, in _javascript_

[23:36:15.0000] <Hixie>
you can typo your variables names and js isn't going to bat an eye

[23:36:24.0000] <annevk>
I love that you can write <select></select> with one character less though

[23:36:28.0000] <annevk>
Didn't know that

[23:40:02.0000] <Domenic>
annevk: TabAtkins: IMO "await a stable state" is more confusing than "queue a microtask," especially when appearing nearby "queue a task"...

[23:41:02.0000] <Hixie>
await a stable state makes the spec so much easier to read

[23:42:34.0000] <Domenic>
disagree

[23:43:23.0000] <Hixie>
it describes the algorithm as one straightforward algorithm, with the complicated timing details present but not in the way

[23:43:45.0000] <TabAtkins>
I just did what Hixie told me to do.

[23:44:13.0000] <annevk>
Hixie: why didn't you group the <dt>s?

[23:44:19.0000] <Hixie>
?

[23:44:25.0000] <annevk>
Hixie: with http://html5.org/r/8667

[23:44:25.0000] <Hixie>
context?

[23:44:30.0000] <Hixie>
they're not identical

[23:45:01.0000] <annevk>
Ah, parse error

[23:45:32.0000] <Hixie>
three clauses, three slightly different requirements

[23:45:52.0000] <Hixie>
ok i can now parse html5lib-tests/tree-construction/tests7.dat tests 1..14

[23:45:56.0000] <Hixie>
time for bed

[23:45:57.0000] <Hixie>
nn

[01:28:15.0000] <annevk>
So my bank turned ü into ³

[01:33:25.0000] <annevk>
Both however have stable positions in single byte encodings

[01:33:58.0000] <Ms2ger>
How about in ebcdic?

[01:42:54.0000] <annevk>
Ms2ger: yeah I guess

[01:46:14.0000] <annevk>
Ms2ger: can't find a code page where that would be the case

[02:03:53.0000] <darobin>
/me wonders if there's a hack to make annevk rich out of this

[02:04:14.0000] <darobin>
"I'd like to withdraw 99ü, please"

[02:06:33.0000] <annevk>
Why would http://www.techmania.ch/details.aspx?hersteller=Dell&produkt=EUCORD_CLOF be CHF 27?!

[02:06:49.0000] <annevk>
darobin: heh

[02:08:53.0000] <annevk>
It's not even the right cable

[03:59:25.0000] <krit>
Hixie: All constructors of Path2D seem to have the old name still: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path2d-withdata

[07:46:08.0000] <annevk>
So the inconsistent policies between CORS and UA-defined features is annoying.

[07:46:44.0000] <annevk>
Why can we have Last-Event-ID, Ping-To, and Ping-From without preflight if they are done by the UA, but not if they are done by the developer?

[07:47:19.0000] <annevk>
These are the only headers that require some kind of separation between developer set headers, and UA set headers

[08:58:36.0000] <annevk>
hsivonen: did you see Unicode is about to introduce 2800 more code points?

[08:58:50.0000] <annevk>
JakeA: any insights as to how to best address that?

[08:59:04.0000] <annevk>
Hixie: you maybe?

[09:00:33.0000] <MikeSmith>
annevk: what are the new code points? emoji?

[09:00:49.0000] <MikeSmith>
annevk: you have a link to an announcement or hwatever?

[09:00:57.0000] <annevk>
MikeSmith: @unicode

[09:01:01.0000] <MikeSmith>
thanks

[09:01:09.0000] <annevk>
MikeSmith: no pointer seems to be included

[09:01:54.0000] <MikeSmith>
yeah

[09:02:24.0000] <MikeSmith>
annevk: don't UAs already handle most of these?

[09:02:48.0000] <annevk>
MikeSmith: I guess I should have said new assigned code points or whatever the term is

[09:04:56.0000] <MikeSmith>
"Duployan shorthand & letters used in Teuthonista & other transcriptional systems"

[09:04:57.0000] <annevk>
http://www.unicode.org/charts/PDF/Unicode-7.0/ has details it seems

[09:05:03.0000] <MikeSmith>
/me looks

[09:05:10.0000] <annevk>
It now includes Linear A

[09:05:26.0000] <annevk>
Lars Thomas can be proud

[09:07:11.0000] <jgraham>
Linear A, Linear B and Carakan? Awesome

[09:07:19.0000] <annevk>
Just Linear A

[09:07:30.0000] <annevk>
Now I wonder about Futhark

[09:09:19.0000] <jgraham>
Linear B and Carakan are already in Unicode

[09:09:22.0000] <jgraham>
I think

[09:13:37.0000] <annevk>
Futhark is too

[09:15:54.0000] <jgraham>
So we have a full house?

[09:17:09.0000] <annevk>
I guess we can go shopping

[09:39:18.0000] <Hixie>
annevk: why would we need to address anything?

[09:40:10.0000] <annevk>
Hixie: I want to do away with author headers vs headers as it doesn't make much sense if you actually expose the request as an object

[09:40:31.0000] <annevk>
Hixie: and at that point the only problematic header is Last-Event-ID (and maybe Ping-To and Ping-From)

[09:41:13.0000] <annevk>
Hixie: as in headers that a spec has set that don't cause a preflight whereas they would if someone set them in some other context

[09:42:32.0000] <annevk>
Hixie: this becomes icky at the point where you'd add the ability to add headers to an EventSource fetch

[09:44:12.0000] <Hixie>
/me is confused

[09:44:17.0000] <Hixie>
how is unicode characters related to http headers

[09:44:26.0000] <Hixie>
i think i missed something

[09:45:05.0000] <Ms2ger>
Hixie, only temporally in this channel

[09:45:29.0000] <Ms2ger>
What you're missing is a <hr> between the conversations

[09:52:16.0000] <annevk>
Hixie: skip the line addressed at hsivonen, it's before that

[09:53:10.0000] <Hixie>
ah, i see

[09:53:21.0000] <Hixie>
i don't know why they're the only ones. Seems like their situation would be pretty common.

[09:53:38.0000] <Hixie>
it's attributes that are harmless when the server sets them, but not harmless when the author sets them.

[09:53:41.0000] <Hixie>
er

[09:53:44.0000] <Hixie>
when the client sets them

[09:53:51.0000] <Hixie>
not server

[09:53:55.0000] <Hixie>
and headers

[09:53:57.0000] <Hixie>
not attributes

[09:54:27.0000] <annevk>
but they're not so restricted that authors can never set them?

[09:55:10.0000] <Hixie>
right

[09:55:20.0000] <Hixie>
i mean, if the server wants to use them, and is willing to preflight it, who cares

[09:55:26.0000] <annevk>
The problem with these is that they're in the middle. Host is client-only. Last-Event-ID however, when set by the client is preflightless. When set by authors comes with a preflight.

[09:55:40.0000] <Hixie>
right

[09:55:52.0000] <Hixie>
Host is not something that you could opt into allowing the client to send

[09:55:54.0000] <annevk>
And if we want to keep that we would need some kind of flag.

[09:55:58.0000] <Hixie>
since the entire secutity system depends on it

[09:56:01.0000] <Hixie>
security

[09:56:20.0000] <annevk>
E.g. what if EventSource starts allowing you to set headers?

[09:56:29.0000] <annevk>
Maybe I should just assume that it doesn't

[09:56:31.0000] <Hixie>
i'm neck-deep in the html parser right now, you're not going to get any sympathy from me if you're looking for a way to keep things simple for yourself :-)

[09:56:50.0000] <annevk>
I'm trying to keep APIs simple for developers

[09:57:06.0000] <Hixie>
if EventSource lets you set headers, then what?

[09:57:08.0000] <annevk>
And trying to predict future growth of various APIs and how that would affect the system

[09:57:22.0000] <Hixie>
i don't see the problem

[09:57:30.0000] <Hixie>
i'm actually really surprised to hear there's only three headers like this

[09:57:37.0000] <Hixie>
i'd have thought there'd be more

[09:57:53.0000] <annevk>
If EventSource lets you set headers the granularity we need is on the level of headers. E.g. a header gets an additional flag about it being set by a spec rather than an author

[09:58:15.0000] <Hixie>
what spec is this in

[09:58:30.0000] <Hixie>
i cant' find last-event-id in fetch.spec and xhr.spec

[09:58:34.0000] <Hixie>
can't

[09:58:36.0000] <annevk>
It's in your spec

[09:58:48.0000] <annevk>
You are creating my problems :-)

[09:59:07.0000] <Hixie>
i don't see anything to do with cors with last-event-id

[09:59:36.0000] <annevk>
EventSource can do CORS and can include a custom header unlike other headers, Last-Event-ID

[09:59:40.0000] <Hixie>
in the html spec

[09:59:50.0000] <annevk>
However, because this header is set by the UA, there's no preflight

[10:00:18.0000] <annevk>
What Fetch sees is just a Request with a header list attached with Last-Event-ID in it

[10:00:38.0000] <annevk>
But now it has to know this is UA-set so it won't treat it as not a simple header

[10:00:58.0000] <annevk>
(As otherwise it would cause a preflight)

[10:01:07.0000] <Hixie>
what am i missing?

[10:01:14.0000] <Hixie>
er, ignore last line

[10:01:38.0000] <Hixie>
hasn't this worked for forever?

[10:01:52.0000] <Hixie>
i don't understand what's new here that this has suddenly come up

[10:02:04.0000] <annevk>
Yeah kinda, because I separated author headers and headers set by specs

[10:02:17.0000] <annevk>
However, that's a silly model and would create an ugly API

[10:02:33.0000] <annevk>
So I'm trying to come up with something better

[10:02:53.0000] <rektide>
hi. does anyone know of a way i can smoothly zoom into a page?

[10:03:59.0000] <rektide>
i spent a day wiring up a nice animated scale() transform

[10:04:29.0000] <rektide>
i think thinks went wrong when i tried keeping the center of the page as the zoom target by using requestAnimationFrame to adjust the scrollTop()

[10:04:30.0000] <annevk>
Solutions I see. We add a flag "API lets devs control headers". Set by fetch() and XMLHttpRequest, in all other cases we trust the specs to do the right thing

[10:04:34.0000] <annevk>
That's 1)

[10:04:35.0000] <Hixie>
annevk: i don't understand why the api is ugly?

[10:04:48.0000] <annevk>
2) We add these headers to simple headers.

[10:04:50.0000] <rektide>
the scrollTop seems to cause my requestAnimationFrame to only trigger every 33ms

[10:05:15.0000] <annevk>
3) We add an additional member to header about whether it's privileged or not

[10:05:16.0000] <Hixie>
annevk: there's a difference between a header set by the UA, and a header set via an API, right? we already have that in XHR.

[10:05:20.0000] <rektide>
and i still have some rather sincere jank. anyways, thanks.

[10:05:43.0000] <Hixie>
annevk: e.g. in XHR the UA sets Host, but the author sets X-Foo via the API

[10:05:43.0000] <annevk>
Hixie: I checked, XHR doesn't set any headers itself

[10:05:51.0000] <annevk>
Hixie: no, the network layer sets those headers

[10:06:00.0000] <annevk>
Hixie: i.e. Fetch, way after the CORS check

[10:06:25.0000] <Hixie>
sure but that's your problem at the spec level

[10:06:28.0000] <Hixie>
the author doesn't care about that

[10:06:37.0000] <Hixie>
from the author's perspective, there's UA-set headers, and author-set headers

[10:06:50.0000] <Hixie>
this is true in all APIs that let you set headers

[10:06:52.0000] <annevk>
No, it matters as to what's exposed in service workers

[10:07:11.0000] <annevk>
E.g. event.request.headers will not contain Host as that is set by the network layer

[10:07:23.0000] <Hixie>
that's odd

[10:07:37.0000] <annevk>
It seemed kind of natural to me

[10:07:40.0000] <Hixie>
but i guess you'd need to exclude some headers for auth

[10:07:44.0000] <Hixie>
Host is harmless, but others might not be

[10:07:55.0000] <annevk>
However, Host again would not be a problem either way, as authors cannot set it

[10:08:19.0000] <SamB>
Hixie: if the header is added by something that hasn't seen the request at all yet, it's obviously not going to be there yet, no?

[10:08:19.0000] <Hixie>
seems like you'd need a whitelist for what headers to expose

[10:08:32.0000] <annevk>
Hixie: yeah that is covered too

[10:08:38.0000] <Hixie>
SamB: i don't understand what you are asking

[10:08:55.0000] <Hixie>
annevk: is there somewhere i can read to see what service workers see?

[10:09:12.0000] <annevk>
Hixie: http://fetch.spec.whatwg.org/#fetching

[10:09:27.0000] <SamB>
I guess Host *could* get added at an earlier layer but seeing as it's mostly there because the GET doesn't mention the hostname ...

[10:09:31.0000] <annevk>
Hixie: http://fetch.spec.whatwg.org/#concept-http-fetch passes the request into service workers

[10:09:56.0000] <annevk>
Hixie: in step 8

[10:10:20.0000] <Hixie>
(what's "Mixed Content"?)

[10:10:31.0000] <annevk>
Hixie: https://w3c.github.io/webappsec/specs/mixedcontent/

[10:11:04.0000] <annevk>
Those hooks are WIP

[10:11:15.0000] <Hixie>
oh that kind of mixed content

[10:11:15.0000] <Hixie>
ok

[10:12:23.0000] <Hixie>
so https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#request-interface is what the service worker gets?

[10:12:54.0000] <annevk>
Hixie: http://fetch.spec.whatwg.org/#request is the new idea

[10:13:54.0000] <rektide>
are there polyfills to host fetch on XHR? or to provide XHR on fetch?

[10:14:19.0000] <Hixie>
annevk: man, i'm sure glad you're dealing with this and not me

[10:14:30.0000] <Hixie>
annevk: so the question is basically, which headers to expose there?

[10:14:35.0000] <rektide>
or against node's http.createClient or mikeal's request?

[10:14:38.0000] <Hixie>
annevk: or are the headers mutable?

[10:15:21.0000] <Hixie>
annevk: i think it'd be fine to have some headers be immutable in that API. Doesn't make the API surface particularly hard to understand, and it lets you include things like Host and Cache-Control.

[10:15:40.0000] <Hixie>
annevk: you could even include auth-related headers, and make them unreadable too

[10:16:01.0000] <Hixie>
annevk: so that headers would be in three modes: mutable, immutable, protected

[10:17:14.0000] <annevk>
Hixie: yeah there's some of that for response headers

[10:17:35.0000] <annevk>
Hixie: the main problem I have right now is the one I mentioned earlier

[10:17:49.0000] <Hixie>
why does what i described not solve that problem?

[10:17:55.0000] <annevk>
Fetch (the spec) takes a request which takes a set of a headers

[10:18:07.0000] <Hixie>
sure. The spec will need to have per-header metadata.

[10:18:11.0000] <annevk>
Those headers can trigger a preflight

[10:19:07.0000] <annevk>
Yeah so currently I don't need per-header metadata. The immutable and protected headers can just be lists that are checked on set and get

[10:19:21.0000] <annevk>
The problem is Last-Event-ID

[10:19:39.0000] <annevk>
Which triggers a preflight if it wasn't spec-sanctioned

[10:19:51.0000] <Hixie>
so you add the metadata

[10:19:54.0000] <Hixie>
what's the problem

[10:20:18.0000] <Hixie>
i'm really surprised these are the only headers in this mode

[10:20:35.0000] <annevk>
I think Last-Event-ID is actually the only one, since <a> doesn't do CORS

[10:20:49.0000] <annevk>
Or maybe <a ping download> does CORS?

[10:20:49.0000] <Hixie>
seems like e.g. Accept-Charset should be on this list too

[10:21:02.0000] <annevk>
Accept-Charset is not a header anymore

[10:21:07.0000] <Hixie>
and DNT

[10:21:17.0000] <annevk>
DNT is like Host

[10:21:22.0000] <Hixie>
and User-Agent

[10:21:27.0000] <annevk>
User-Agent is like Host

[10:21:34.0000] <Hixie>
how so

[10:21:43.0000] <Hixie>
i mean, it's on the same list today

[10:21:48.0000] <annevk>
Hixie: http://fetch.spec.whatwg.org/#forbidden-author-header-name

[10:21:51.0000] <Hixie>
i'm saying it should be treated like Last-Event-ID

[10:22:04.0000] <annevk>
No, they are more restricted

[10:22:06.0000] <Hixie>
if the UA sets it on a UA request, then sure, it shouldn't be mutated

[10:22:13.0000] <Hixie>
but why would we not allow it to be set on an XHR request, say

[10:22:41.0000] <annevk>
because we decided we wouldn't back in 2006

[10:23:08.0000] <Hixie>
well if that's an argument, then why does the same argument not apply to Last-Event-ID?

[10:23:20.0000] <annevk>
well I asked you if we should just add Last-Event-Id to that list

[10:24:02.0000] <Hixie>
right but we decided not to in 200x, right? :-)

[10:24:32.0000] <Hixie>
adding per-header metadata seems pretty simple to me.

[10:24:49.0000] <Hixie>
(it's not really per-header, it's more just two lists of headers)

[10:25:07.0000] <Hixie>
(two lists that browsers probably already have somewhere, to some extent)

[10:25:36.0000] <Hixie>
(since some attributes are going to be mutable in this API and some aren't, regardless of what we do here)

[10:27:08.0000] <SamB>
so ... older browsers are going to allow scripts to do whatever they like with those headers, or?

[10:27:40.0000] <Hixie>
older browsers don't have service workers at all

[10:38:50.0000] <boogyman>
Hixie: where do I go to report a broken link on the w3.org spec?

[10:39:09.0000] <boogyman>
Hixie: w3c spec > w3c wiki

[10:39:17.0000] <Hixie>
on a wiki? just fix it...

[10:39:56.0000] <boogyman>
I am unaware of what the link is attempting to reference. "checkbox state"

[10:40:37.0000] <boogyman>
I can make an educated that this may be a reference to the "checked" state, but the phrase is ambiguous.

[10:41:05.0000] <Hixie>
ah

[10:41:06.0000] <Hixie>
dunno

[10:41:10.0000] <Hixie>
/me doesn't much care for w3c things

[10:49:47.0000] <Hixie>
so, anyone know why posts i send to es-discuss might be dropping on the floor?

[10:50:47.0000] <marcosc_>
Hixie: "use strict"?

[10:50:48.0000] <marcosc_>
:)

[10:50:59.0000] <MikeSmith>
heh

[11:02:57.0000] <Domenic>
Hixie: it finally arrived

[11:03:07.0000] <annevk>
It can't be a list. Say we put Last-Event-ID on that list. And someone sets it through XMLHttpRequest. How does Fetch know what Last-Event-ID means?

[11:04:28.0000] <Hixie>
Domenic: i just resent it

[11:04:32.0000] <Hixie>
Domenic: from a different mail client

[11:07:27.0000] <JonathanNeal>
Hixie: it’s not like you to resent anything.

[11:08:58.0000] <SamB>
*groan*

[12:12:13.0000] <JakeA>
annevk: will catch up tomorrow morning

[13:02:38.0000] <rektide>
i think i found an approach for zooming content in and out smoothly

[13:03:31.0000] <rektide>
i tried using requestAnimationFrame to scrollTop(), but that's janky, has some egregious state tracking, and runs half FPS

[13:04:47.0000] <rektide>
originally i'd thought i needed to dynamically adjust transform-origin, but that would've required it's own janktacular state tracking to keep updating the origin to the center of the page as the user scrolls without shifting

[13:05:04.0000] <rektide>
guessing the only viable approach is the use translate(), which for some reason hadn't occured to me

[13:05:53.0000] <caitp>
you will of course report your findings and have them published in a peer-reviewed journal

[13:06:14.0000] <rektide>
ya'll are welcome to peer review my google+ writeup when it goes up

[13:06:21.0000] <caitp>
nice

[13:08:25.0000] <rektide>
i also had to use huge negative margins to trim the zoomed out content's real size down to it's transformed size, which is what made me think the transform-origin was going to be problematic: it'd mean updating those margins as the origin moved. otoh, i only really need to set the transform-origin right before zoom starts, and so long as i can reupdate the origin, re-trim the margins, and set the scrollTop() exactly right, it might not be too bad

[13:27:47.0000] <zewt>
sometimes you'll get much smoother scrolling with translate3d

[13:27:53.0000] <TabAtkins>
annevk: Do @font-face rules in documents expose those fonts to other documents in the same window?  I didn't think they did, which is why I did document.fonts, but if they are, I can see the argument for shifting to CSS.fonts.

[13:28:21.0000] <zewt>
depending on what the content is

[13:41:05.0000] <rektide>
the biggest suck of all is that "zoom" ends up with thousands of millions of results for zooming an image in and out

[13:41:53.0000] <rektide>
there's absolutely no hope of ever finding any useful information on how to zoom content in or out, which is only slightly bleaker than my outlook for ever getting this right myself by munging carefully with scale() translate(), negative margin, and translate origin

[13:42:16.0000] <caitp>
to be fair, isn't that usually the client's job?

[13:42:50.0000] <caitp>
spread fingers apart on the trackpad, notice that text and images scale up

[13:43:25.0000] <rektide>
it doesn't seem like a use case that the web should be exempt from actually doing

[13:43:34.0000] <rektide>
just because there is a use case where the browser can do some kind of job at it

[13:44:25.0000] <caitp>
some people would say the platform already kind of does too much, it's a silly level of scope creep

[13:45:12.0000] <rektide>
yes, you can't imagine wanting to change the size of a thing, clearly, definitely: should be banned, scope creep.

[13:45:34.0000] <caitp>
now now, I'm not taking sides in that argument =)

[13:46:30.0000] <rektide>
scope creep is my weak-sauce hacked out implementations. :(

[13:47:10.0000] <annevk>
TabAtkins: I suspect with HTML imports they would

[13:47:28.0000] <TabAtkins>
Ah, hm.  Yeah.

[15:14:19.0000] <Hixie>
man, getting the orientation of the stack of open elements wrong was so dumb

[15:15:13.0000] <SamB>
Hixie: hmm?

[15:15:24.0000] <SamB>
oh, you mean in your parser?

[15:15:27.0000] <Hixie>
when i specced the html parser, i defined a stack which grows downwards

[15:15:30.0000] <Hixie>
instead of upwards

[15:15:32.0000] <SamB>
oh

[15:15:34.0000] <SamB>
oops

[15:15:39.0000] <Hixie>
so the spec talks about "lower in the stack" meaning further from zero

[15:15:45.0000] <SamB>
just like on i386 ;-P

[15:15:49.0000] <Hixie>
heh

[15:15:56.0000] <Hixie>
it's freaking confusing

[15:16:03.0000] <Hixie>
but to fix it would be so risky

[15:16:06.0000] <Hixie>
that i daren't do it

[15:16:21.0000] <SamB>
maybe change to words that aren't up and down at all

[15:16:31.0000] <Hixie>
i use all kinds of words

[15:16:35.0000] <Hixie>
that's why it's risky

[15:16:51.0000] <Hixie>
e.g. "Let furthest block be the topmost node in the stack of open elements that is lower in the stack than formatting element..."

[15:17:08.0000] <Hixie>
topmost meaning nearest to index 0, lower meaning with index greater than

[15:17:17.0000] <Hixie>
assuming a positive-index stack where 0 is the first thing pushed onto it

[15:18:05.0000] <SamB>
clearly start by wrapping all such text in caution tape ;-P

[15:55:35.0000] <jamesr_>
redefine the stack to go left-to-right

[15:57:09.0000] <SamB>
hmm, that's not terribly exotic as directions go

[15:57:42.0000] <jamesr_>
or north/south?

[15:58:09.0000] <Philip`>
With C++ std::vector, a stack typically grows from front to back

[16:01:07.0000] <Philip`>
(Could go with turnwise and widdershins if you want to avoid ambiguity with typical 3D directional terms)

[16:03:14.0000] <jgraham>
/me thinks that the C++ committee and Hixie need to revise the law of universial gravitation

[16:03:35.0000] <jgraham>
Because their stacks are not going to be stable

[16:43:59.0000] <Hixie>
holy crap, i implemented the AAA and passed like 10 more tests


2014-06-11
[18:07:02.0000] <Domenic>
Hixie: glad you are deciphering this ES task/initialization stuff ... I think I got lost @_@

[23:55:46.0000] <annevk>
Domenic: I wonder what implementers will think

[01:37:46.0000] <annevk>
MikeSmith: any chance you can put a stop to people abusing mailing list addresses as Bugzilla accounts? https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985#c27

[01:38:06.0000] <annevk>
MikeSmith: that's really confusing

[02:01:54.0000] <annevk>
jgraham: heh, I remember when we implemented that stuff I was similarly confused by the stacks and just assumed that bit was okay since we passed the tests

[03:44:40.0000] <hemanth>
meow!

[03:47:45.0000] <annevk>
Removing author headers is proving to be a bit more invasive than expected, but it seems like it might play out well

[04:01:04.0000] <coolbot95>
What the WG?

[04:01:11.0000] <coolbot95>
That one's free.

[04:01:36.0000] <coolbot95>
I still don't know what "What" stands for.

[04:01:39.0000] <coolbot95>
Or "WHAT".

[04:01:46.0000] <Ms2ger>
Web hypertext application technology

[04:02:45.0000] <coolbot95>
I have never really grasped what your relation is to W3.

[04:02:48.0000] <coolbot95>
And the browser authors.

[04:02:57.0000] <coolbot95>
I just know W3/W3C started looking like a joke 10+ years ago.

[04:03:57.0000] <annevk>
coolbot95: http://wiki.whatwg.org/wiki/FAQ enjoy

[04:16:53.0000] <coolbot95>
Ah.

[04:17:06.0000] <coolbot95>
Seems to match my "10 years" thing perfectly.

[04:19:46.0000] <annevk>
Yeah, anniversary was a week ago

[04:20:59.0000] <coolbot95>
:S

[04:45:02.0000] <JakeA>
annevk: with the no-proflight headers, do we need a "cors-no-preflight" mode that cannot be set on construction unless it's constructed by the UA?

[04:45:30.0000] <annevk>
JakeA: yeah, that was an option I considered

[04:45:45.0000] <annevk>
JakeA: I went with an "unsafe request flag" that will be set by XHR and fetch()

[04:46:08.0000] <annevk>
JakeA: I haven't made this commit yet since it's pretty large and changes a bunch of things around

[04:46:29.0000] <annevk>
JakeA: and I really need to shower and get some food :p

[04:46:36.0000] <JakeA>
:D

[04:50:54.0000] <JakeA>
annevk: If I do myCache.put(request, response); event.respondWith(response); is that going to break? If we spec cache to tee response streams when storing, does it work around that?

[04:53:56.0000] <annevk>
JakeA: yeah we need to talk to Domenic about those streams

[04:54:04.0000] <annevk>
JakeA: maybe a structured clone of a stream should be a tee?

[04:54:32.0000] <annevk>
JakeA: to answer that we need to know how streams will work with structured cloning

[04:54:50.0000] <annevk>
JakeA: which is hard since we don't even know how structured cloning works with promises

[04:55:26.0000] <JakeA>
annevk: hah, thankfully we don't have to worry about that with request/response right?

[04:56:04.0000] <annevk>
JakeA: well storing is defined in terms of structured cloning...

[04:56:41.0000] <JakeA>
annevk: but there are no promises on request/response. There are methods which return promises, but that's different right?

[04:57:21.0000] <annevk>
JakeA: yeah, this is mostly about what should happen with the underlying stream

[04:57:43.0000] <annevk>
JakeA: there's no underlying promise, but a stream is basically a more complicated case of a promise I think when it comes to structured cloning

[05:00:09.0000] <JakeA>
annevk: I'm still worried about how complicated cache.add(url, url, url) is when it comes to cross-origin stuff (on a CDN), having to change the mode for those. It's almost like no-cors is a better default for cache, although it'd be very weird to have a different default for fetch() where cors makes more sense

[05:00:58.0000] <JakeA>
Can't think of a simple answer there though. Will have a think

[05:04:01.0000] <MikeSmith>
annevk: about that mailing-list bugzilla thing, I'll figure out who created that account and ask them to change the address to their actual address

[05:04:40.0000] <MikeSmith>
annevk: do you have any idea who it was that actually wrote that message?

[05:07:26.0000] <MikeSmith>
I wonder if maybe it was just that Harry created that account at some point and logged in with it so he could add it to the default Cc for webcrypto bugs, then forgot and stayed logged in with it and posted those bug comments

[05:07:41.0000] <MikeSmith>
I've actually done that myself before

[05:09:17.0000] <MikeSmith>
I don't know how to completely prevent that happening occasionally, because as far as I know, the only way to get bugzilla to Cc a mailing list is to create a bugzilla account with the list address as the account name

[05:11:10.0000] <annevk>
JakeA: you can always do cache.add(new Request(url, {mode:"cors"}), ...) but usability--

[05:11:28.0000] <annevk>
JakeA: I'll open an issue later on the structured clone and streams thing

[05:11:34.0000] <annevk>
JakeA: that's hard :(

[05:11:39.0000] <annevk>
MikeSmith: I suspect the chair

[05:11:53.0000] <annevk>
MikeSmith: oh Harry could be it I suppose

[05:12:03.0000] <annevk>
MikeSmith: ah ok

[05:24:45.0000] <zewt>
streams probably want to require being transferred, like messageports

[05:25:21.0000] <zewt>
so you don't end up with two endpoints

[05:42:07.0000] <Domenic>
annevk: JakeA: if there are methods/properties that return promises, they likely return internal-slot promises... I don't really know how structured clone works with internal slots or other internal state.

[05:43:28.0000] <JakeA>
Domenic: The only promise-returning method on request/response is body.to

[05:43:38.0000] <Domenic>
JakeA: ah, welp.

[05:44:50.0000] <Domenic>
will dedicate more time to thinking about it when issue opens, but my first thought is that structured cloning should read a stream to the end into some sort of "constant stream" or "snapshot stream"

[05:45:54.0000] <Domenic>
meanwhile i think i have admin rights on my computer today so i should hopefully be able to install git and sublime and get productive on streams...

[05:50:23.0000] <annevk>
Domenic: if you do that the super obvious cache.add(response); event.respondWith(response) would fail

[05:50:52.0000] <Domenic>
annevk: I guess I meant teeing it before streaming

[05:51:05.0000] <Domenic>
still think readToEnd is a better name than to because it makes the depletion obvious

[05:52:07.0000] <annevk>
Maybe body.readInto("blob")?

[05:52:15.0000] <annevk>
JakeA: ^^

[05:52:16.0000] <JakeA>
I'm really happy with .to

[05:52:51.0000] <annevk>
Yeah actually, Domenic, the naming of to() doesn't matter here

[05:52:53.0000] <Domenic>
readInto is probably going to be used for binary streams: readInto(arrayBuffer, offset, length)

[05:53:11.0000] <annevk>
In my example above there was no invocation of to()

[05:53:38.0000] <annevk>
Domenic: shouldn't that be fill like how Array calls it?

[05:53:38.0000] <Domenic>
sure

[05:54:00.0000] <Domenic>
no, I want read to be the verb that means "read out of the queued data, making it unavailable for other consumers"

[05:54:08.0000] <Domenic>
maybe readAndFill or something

[05:54:35.0000] <Domenic>
but yeah your example was not using to()/readToEnd(), which is why I was saying it's OK for it to tee

[05:54:50.0000] <Domenic>
whereas if we have all depleting things use the "read" verb, people can see that as the warning signal

[05:55:02.0000] <Domenic>
and other operations, like adding to cache, they can assume will not deplete

[05:57:59.0000] <Domenic>
hmm this tee-and-read-to-end approach for cloning makes sense for storing on disk, but not for cloning between realms. Maybe you transfer between realms?

[06:00:02.0000] <annevk>
Domenic: transfer makes sense

[06:00:27.0000] <annevk>
Domenic: note that if something can be transferred, you can clone it too, up to the user

[06:08:18.0000] <zewt>
what the hell? pressing escape isn't stopping animated gifs in firefox now

[06:10:29.0000] <zewt>
https://bugzilla.mozilla.org/show_bug.cgi?id=825486 stunning incompetence

[06:15:28.0000] <annevk>
Domenic: JakeA: https://github.com/slightlyoff/ServiceWorker/issues/313

[06:29:45.0000] <annevk>
JakeA: header commit made

[06:36:54.0000] <JakeA>
annevk: this is great. I was showing some people the fetch api & related classes. Feedback very positive when compared to XHR

[06:37:08.0000] <JakeA>
should write a blog post or something

[06:37:13.0000] <Ms2ger>
Well

[06:37:24.0000] <annevk>
JakeA: note that I also made it more clear what headers are exposed to SW now

[06:37:37.0000] <Ms2ger>
That's a bit like saying "I told them about the flu. Feedback very positive when compared to cholera"

[06:37:43.0000] <annevk>
JakeA: basically only the things that are set by the API, nothing that would be set by the network

[06:39:01.0000] <JakeA>
Ms2ger: haha

[06:39:43.0000] <jgraham>
Does that mean that there's a chance that Fetch will end up like Spanish Flu and kill millions of people across the world?

[06:39:52.0000] <JakeA>
annevk: The CSP guys here are wanting SW responses to be treated as redirects so they can continue to deal with requests rather than responses

[06:40:07.0000] <jgraham>
I only ask because I might have to withdraw my endorsement of this technology in that case

[06:40:19.0000] <JakeA>
annevk: explained to them why that doesn't really make sense without a boatload of hackery

[06:40:50.0000] <JakeA>
annevk: hopefully that'll be the end of it, but expect resistance on having a CSP hook after SW provides a response

[06:41:25.0000] <annevk>
JakeA: tell them to file a ticket

[06:41:33.0000] <annevk>
JakeA: seems bad to have that as Google-internal discussion

[06:42:00.0000] <JakeA>
annevk: fair point, I'll encourage further discussion in the open

[06:42:57.0000] <annevk>
JakeA: note that per CSP 1.1 if they treat them as redirects, SW would be blocked by default

[06:43:17.0000] <annevk>
JakeA: unless I don't understand the unsafe-redirect directive

[06:43:56.0000] <JakeA>
annevk: yeah, they were looking at all kinds of hackery to avoid just having a separate hook. I was happy with https://github.com/slightlyoff/ServiceWorker/issues/113#issuecomment-38908599 but I think they're looking at something different

[06:44:19.0000] <annevk>
JakeA: are these different people than Mike West?

[06:44:59.0000] <annevk>
Anyway, still need to go through the whole Response story to make sure it's sane

[06:45:58.0000] <annevk>
jgraham: no, but if it does kill millions of people we'll blame you

[06:46:38.0000] <JakeA>
annevk: yeah, the initial proposal was used as a starting point :/

[06:48:09.0000] <annevk>
Oh, in that case they might want to talk to Mike

[06:48:35.0000] <annevk>
The spec reflects discussions with him at BlinkOn and after

[06:50:16.0000] <jgraham>
fetch(Request("http://secret.lab.gov/bio-terror/launch", {method:POST}))

[06:57:11.0000] <Ms2ger>
Woo, renaming flexbox

[06:58:03.0000] <jgraham>
/me blinks

[06:58:32.0000] <jgraham>
/me hopes that was a temporal vortex causing 2012 Ms2ger to briefly appear in the present

[06:59:18.0000] <Ms2ger>
Nah, just 2012 minutes, right folks? http://lists.w3.org/Archives/Public/www-style/2014Jun/0107.html

[07:04:09.0000] <annevk>
jgraham: pretty sure POST has to be in quotes so that'd be fail :-)

[07:04:48.0000] <Ms2ger>
const POST = "POST";

[07:04:59.0000] <jgraham>
Dammit Ms2ger beat me to it

[07:48:05.0000] <TabAtkins>
Ms2ger: As always, only do renames when compatible. In this case, we're discussing only renaming the flex-basis value, but keeping "auto" in the flex shorthand.

[07:48:33.0000] <TabAtkins>
It was a mistake to have a value that means completely different things as a computed and used value.

[07:49:30.0000] <SamB>
that does sound like a pretty dumb idea, yeah

[07:49:49.0000] <annevk>
I no longer know what computed and used means :-(

[07:49:53.0000] <SamB>
just like not using <TABLE> for the tables in http://packages.qa.debian.org/s/systemd-shim.html

[07:50:55.0000] <annevk>
SamB: that's not a table, so seems legit

[07:51:24.0000] <SamB>
I mean the thing with the "general" header, and the one with the "bugs" header

[07:51:31.0000] <SamB>
oh also "versions"

[07:51:43.0000] <SamB>
... and "patch-tracker"

[07:52:27.0000] <annevk>
I can see how using <dl> is fine there. Though CSS lacks a bit in the styling department

[07:52:50.0000] <SamB>
my issue is that the left and right columns are misaligned

[07:53:14.0000] <SamB>
the bold font is like 1px taller here

[07:55:00.0000] <SamB>
huh, I guess a <dl> isn't as crazy as what I *expected* to find if I actually inspected

[07:55:12.0000] <SamB>
... so how the heck did they get it that screwed up?

[07:56:19.0000] <SamB>
hmm, would be saner with <di> though

[07:56:58.0000] <SamB>
so basically they float these things

[07:58:07.0000] <Ms2ger>
display: compact

[07:58:07.0000] <annevk>
<di> does not exist

[07:58:20.0000] <SamB>
annevk: yes, I know

[07:59:17.0000] <SamB>
"with <di>" that was shorthand for "with <di>, in an alternate universe where <di> actually existed"

[08:01:29.0000] <Ms2ger>
Please leave your sense of alternate universes at the door, thanks!

[08:01:38.0000] <annevk>
I'm getting pretty close to the point where I'm defining a generic multimap concept that FormData / URLSearchParams / Headers can use

[08:01:53.0000] <annevk>
Might not be that bad of an idea

[08:02:03.0000] <annevk>
Maybe once I merge all the things

[09:11:02.0000] <tobie>
Is the consensus that this is the right way to use promises? https://gist.github.com/mkruisselbrink/c5c5cd80f27f3158f451#file-gistfile1-pro-L23

[09:14:07.0000] <tobie>
(Promise resolves to undefined on successful geofencing region registration, rejects otherwise).

[09:18:30.0000] <Domenic>
tobie: LGTM. Remember to reject with Error instances (e.g. DOMExceptions, not DOMErrors)

[09:19:52.0000] <tobie>
Domenic: Thanks! (Not working on this myself. Just bumped into Promise<void> and that just… felt weird.)

[09:44:21.0000] <TabAtkins>
annevk: Just read the Cascade spec

[09:44:41.0000] <Krinkle>
annevk: URLSearchParams, is that what I think it is?

[09:44:45.0000] <Krinkle>
(parsed map of location.search)

[09:46:14.0000] <Krinkle>
I guess FormData's interface is similar to DOMTokenList (e.g. classList), with more type support of course and differentmethod names at the moment. It might be useful to have a getter on FormData instead of just append, too.

[10:01:36.0000] <SamB>
oh, have you guys what Emacs does with bytes that don't form part of a valid code sequence during character decoding?

[10:08:39.0000] <SamB>
you can't do it with an API that forces UTF-16, though :-(

[10:39:30.0000] <zewt>
any programmer's editor will do that, vim handles it cleanly too

[10:40:01.0000] <zewt>
though i've never trusted it to actually save changes when that happens

[10:40:27.0000] <SamB>
probably best to figure out WTF went wrong first and fix it, certainly

[10:41:08.0000] <SamB>
zewt: I was referring to the manner in which it represents the incomprehensible bytes though ;-)

[10:57:19.0000] <Hixie>
ok

[10:57:38.0000] <Hixie>
suppose a group provided a web service that took HTML input, and did something to it

[10:57:45.0000] <Hixie>
say, anolis. or a translator tool.

[10:58:12.0000] <Hixie>
now suppose that that tool needs the markup annotated in some way

[10:58:57.0000] <Hixie>
e.g. <code data-anolis-xref="attr-foo">foo</code> or <span data-translation-hint="name">Fred</span>

[10:59:36.0000] <Hixie>
according to the spec, data-*="" is inappropriate for this, because "Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements" and "These attributes are not intended for use by software that is independent of the site that uses the attributes"

[10:59:51.0000] <Hixie>
what should we recommend to such tools?

[11:00:05.0000] <Domenic>
data-?

[11:00:10.0000] <Domenic>
(i.e., change the spec)

[11:00:26.0000] <hober>
the author is adding these attributes for the express purpose of feeding their content to the web service?

[11:00:37.0000] <Hixie>
yeah, that was the only idea other than having them define a spec that i could come up with

[11:00:41.0000] <Hixie>
hober: yeah

[11:00:49.0000] <Domenic>
oooh i know XML namespaces!!!

[11:00:58.0000] <Ms2ger>
/me pushes Domenic off a bridge

[11:00:59.0000] <Domenic>
or ... custom DTDs!??!?!

[11:01:06.0000] <Hixie>
Domenic: don't make me turn this channel around!

[11:01:15.0000] <Ms2ger>
No, the CSSWG is the one that uses custom DTDs

[11:01:48.0000] <hober>
given the author's intent, i think data-* is appropriate. they *are* storing custom data private to the application

[11:02:17.0000] <Hixie>
yeah, i guess it could be read that way

[11:02:19.0000] <Ms2ger>
Hixie, doesn't matter, this isn't HTML ;)

[11:02:20.0000] <Domenic>
this feels vaguely related to the way in which custom element users like to use custom attributes too...

[11:02:21.0000] <Hixie>
it's kinda borderline, but close enough

[11:02:21.0000] <hober>
and the attributes *aren't* being used by software independent of the site, because the author made things dependent by adding them with the intent of feeding the site to the service

[11:02:33.0000] <Hixie>
fair enough

[11:02:37.0000] <Hixie>
i'll tweak the text

[13:21:15.0000] <zewt>
SamB: vim just shows <EC>, iirc

[13:21:26.0000] <zewt>
treated as a single "character"

[13:22:01.0000] <SamB>
Emacs has special "8-bit characters" that it uses for incomprehensible high bytes in input

[13:22:20.0000] <zewt>
firefox uses magic glyphs that show the hex value inside

[13:22:53.0000] <SamB>
I thought firefox converted incomprehensible byte sequences to U+FFFD

[13:23:21.0000] <zewt>
i mean when it has undisplayable things in utf-16 space

[13:23:34.0000] <zewt>
forget the particular cases, probably things like lone surrogates and control characters

[13:24:18.0000] <SamB>
anyway, Emacs uses codepoints past the end of current Unicode for high bytes that it can't decode from the coding system it's attempting to decode

[13:25:09.0000] <SamB>
and it uses a fairly evil representation of them in buffer text ;-P

[13:25:50.0000] <SamB>
zewt: you know how it's forbidden to represent any codepoint using more bytes than necessary in UTF-8 now?

[13:26:43.0000] <zewt>
"now"? since the dawn of time

[13:27:04.0000] <SamB>
well, I don't remember what the original spec said, okay?

[13:28:10.0000] <SamB>
even if, for all I know, it's exactly like what my current manpage says

[13:29:19.0000] <SamB>
anyway, Emacs uses the two-byte forms that are not permitted to be used to encode ASCII for its "8-bit byte" codepoints ;-)

[13:29:43.0000] <SamB>
(mostly only internally, though it seems that you can write such things to a file if you really want)

[13:31:44.0000] <SamB>
(mind you, I believe these codepoints are also used, e.g., for data that Emacs has made no attempt to decode using any particular coding-system)

[13:32:24.0000] <SamB>
(otherwise, it probably wouldn't be all that important to use other than the dawn-of-time UTF-8 sequences for those codepoints)

[13:32:57.0000] <SamB>
(since, as you know, dawn-of-time UTF-8 can encode up through 0x7FFFFFFF)

[13:52:54.0000] <Hixie>
wtf

[13:53:13.0000] <Hixie>
top(1) reckons my CPU is at about "96.4%us"

[13:53:34.0000] <Hixie>
but sorting processes by CPU usage, and showing everything, i can only account for about 20% CPU.

[13:53:41.0000] <Hixie>
wtf is the rest of it being used by?

[13:53:47.0000] <Hixie>
and how can i find out?

[13:53:58.0000] <zewt>
ps?

[13:54:23.0000] <Hixie>
isn't that the same data as top?

[13:54:54.0000] <zewt>
who knows, it sounds like top isn't using the same data as top

[13:55:16.0000] <zewt>
or maybe it's averaged differently or something

[13:55:18.0000] <wanderview>
depending on which version of top, it may be showing only your user processes and not including system threads

[13:55:28.0000] <wanderview>
there is usually an option to turn that on

[13:55:44.0000] <zewt>
right now on a random machine I regularly see processing taing more CPU than the summary claims is in use

[13:55:56.0000] <Hixie>
i can see init, so i'm guessing it's showing all processes

[13:56:04.0000] <zewt>
one confusion is sometimes cpu numbers are per-cpu, sometimes they're systemwide

[13:56:16.0000] <zewt>
init probably isn't quite the same as a kernel thread process

[13:56:27.0000] <zewt>
those are the ones that show up in brackets in ps

[13:56:30.0000] <zewt>
(assuming linux)

[13:57:41.0000] <zewt>
i've never seen those take any resources at all, and I wish ps wouldn't show them without a flag since it's just a ton of noise

[14:02:45.0000] <Hixie>
"ps -A -opcpu,pid,uname,args --sort=pcpu S -m" blames apache

[15:16:27.0000] <annevk>
Krinkle: it has a getter

[15:33:03.0000] <Krinkle>
annevk: and so it does..

[15:33:15.0000] <Krinkle>
annevk: http://xhr.spec.whatwg.org/#interface-formdata

[15:33:23.0000] <Krinkle>
But not implemented yet (in Chrome anyway)

[15:33:30.0000] <annevk>
yes, I wrote that

[15:33:36.0000] <Krinkle>
I know you did.

[15:33:36.0000] <annevk>
nn

[15:33:42.0000] <Krinkle>
slaapse

[15:33:57.0000] <Krinkle>
(groetn uut enschede)


2014-06-12
[22:27:07.0000] <Hixie>
why does tests2.dat's "<table><plaintext><td>" have four "foster-parenting-character-in-table" errors?

[22:27:11.0000] <Hixie>
i don't understand

[22:27:54.0000] <Hixie>
oh, i see

[22:27:56.0000] <Hixie>
nevermind

[01:36:12.0000] <GPHemsley>
Hixie: "In the algorithms below, the number of days in month month of year year is: 31 if month is 1, 3, 5, 7, 8, 10, or 12; 30 if month is 4, 6, 9, or 11; 29 if month is 2 and year is a number divisible by 400, or if year is a number divisible by 4 but not by 100; and 28 otherwise."

[01:36:24.0000] <GPHemsley>
Hixie: That seems to suggest that every month in the year 1900 has 29 days.

[01:37:01.0000] <GPHemsley>
Hixie: Er, I mean...

[01:37:07.0000] <ChrisMorgan>
GPHemsley: the semicolons are very clear.

[01:37:27.0000] <GPHemsley>
Hixie: That seems to suggest that every month in a leap year that is not divisible by 100 has 29 days.

[01:38:00.0000] <GPHemsley>
ChrisMorgan: The semicolons are clear; it's the comma I'm worried about.

[01:38:06.0000] <ChrisMorgan>
Follow the semicolons. There’s no ambiguity there.

[01:38:38.0000] <ChrisMorgan>
Apply the rules from left to right, as is standard practice in such lists, and you get the right result.

[01:38:46.0000] <GPHemsley>
29 [if month is 2 and year is a number divisible by 400], or [if year is a number divisible by 4 but not by 100]

[01:39:05.0000] <ChrisMorgan>
GPHemsley: comma binds more tightly than semicolon.

[01:39:48.0000] <Ms2ger>
It clearly needs an <ol>

[01:40:37.0000] <ChrisMorgan>
GPHemsley: really, the “if month is 2 and” should just be removed.

[01:40:48.0000] <ChrisMorgan>
s/if //

[01:40:52.0000] <GPHemsley>
ChrisMorgan: How do you figure that? 29 days are only in February

[01:41:16.0000] <ChrisMorgan>
And the range of possible values are [1, 12], of which all the rest have been accounted for.

[01:41:48.0000] <GPHemsley>
Ah, I see

[01:41:55.0000] <GPHemsley>
Yes, I suppose that's true.

[01:42:46.0000] <GPHemsley>
Actually, the biggest problem here is the second "if"

[01:43:09.0000] <ChrisMorgan>
I agree with your analysis of the parsing of the portion between the second and third semicolons, but deny it to be a problem.

[01:43:37.0000] <GPHemsley>
I can't see how. My bracketing is the literal interpretation.

[01:43:45.0000] <GPHemsley>
And that is clearly wrong.

[01:44:36.0000] <GPHemsley>
It should read more like "29 if month is 2, and year is a number divisible by 400 or year is a number divisible by 4 but not by 100"

[01:44:44.0000] <ChrisMorgan>
Because month *must* be 2 by that point.

[01:45:21.0000] <GPHemsley>
Ah, you're right

[01:45:57.0000] <GPHemsley>
Something about the way it's written suggests against following the normal order-matters reading of if/else

[01:46:02.0000] <GPHemsley>
to me

[01:46:58.0000] <GPHemsley>
"29 if year is a number divisible by 400 or year is a number divisible by 4 but not by 100"

[01:47:45.0000] <GPHemsley>
you could even condense it to "29 if year is a number divisible by 400 or a number divisible by 4 but not by 100"

[01:47:52.0000] <ChrisMorgan>
I read the entire thing as the following Python: 31 if month in (1, 3, 5, 7, 8, 10, 12) else 30 if month in (4, 6, 9, 11) else 29 if month == 2 and year % 400 == 0 or (year % 4 == 0 and year % 100 != 0) else 28

[01:47:55.0000] <GPHemsley>
depending on how explicit you feel the need to be

[01:48:02.0000] <ChrisMorgan>
There, the `month == 2 and` part is superfluous.

[01:48:21.0000] <GPHemsley>
yeah, I agree with you now

[01:53:42.0000] <annevk>
What's all this world cup stuff?

[01:55:06.0000] <GPHemsley>
:)

[02:16:21.0000] <jgraham>
annevk: It's the reason you got up this morning and felt the overwhelming need to paint your face orange

[02:16:59.0000] <annevk>
Hah, far too hot for that

[03:37:59.0000] <smaug____>
hmm, "HTTP 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, and 504 Gateway Timeout responses" was removed, but "Any other HTTP response code not listed here must cause the user agent to fail the connection." is still there

[03:43:42.0000] <smaug____>
we really need some good blame for specs

[03:45:15.0000] <zcorpan>
is there any url that blink considers to be unresolvable?

[03:48:27.0000] <tobie>
darobin: webidl parser doesn't handle Promise<sequence<DomString>?>> properly (throws an "Invalid operation" error), but doesn't mind Promise<sequence<DomString?>>. Any ideas why offhand?

[03:48:39.0000] <zcorpan>
"data:x," maybe?

[03:52:53.0000] <ChrisMorgan>
zcorpan: how about http://www.invalid/

[03:52:59.0000] <ChrisMorgan>
.invalid is reserved for the purpose.

[03:53:13.0000] <zcorpan>
ChrisMorgan: it doesn't fail to resolve on the url parser level

[03:53:27.0000] <zcorpan>
it fails in dns lookup

[03:54:13.0000] <ChrisMorgan>
Hokay.

[03:54:58.0000] <tobie>
darobin: Just. Nevermind.

[04:02:53.0000] <darobin>
tobie: okay :)

[04:12:59.0000] <annevk>
zcorpan: http://test:test/

[04:13:06.0000] <annevk>
zcorpan: iirc

[04:13:26.0000] <annevk>
yup, I win

[04:13:45.0000] <zcorpan>
annevk: how do you tell that it doesn't resolve?

[04:13:58.0000] <annevk>
protocol != http

[04:14:28.0000] <zcorpan>
ah. thanks!

[04:14:39.0000] <annevk>
in theory :link shouldn't match I think

[04:15:40.0000] <zcorpan>
it does though

[04:15:42.0000] <annevk>
oh that was removed

[04:16:09.0000] <annevk>
now the requirement is simply <a href>

[04:17:40.0000] <zcorpan>
.protocol is http: in gecko when url fails to resolve (but .href returns the input string)

[04:19:52.0000] <annevk>
Yeah, inconsistency all over

[04:20:12.0000] <annevk>
URL Standard has requirements, but nobody is biting

[04:34:26.0000] <zcorpan>
the spec's bug filer's textarea's resizer thumb seems like it's in the wrong corner

[04:47:36.0000] <tobie>
darobin: was using <pre> instead of <script type=text/plain> for WebIDL blocks

[04:47:53.0000] <darobin>
ah, yeah, that will bite your arse off

[05:20:34.0000] <SimonSapin>
zcorpan: depends what you mean by resolve, but http://dev.w3.org/csswg/css-values/#about-invalid sounds related

[05:22:55.0000] <zcorpan>
SimonSapin: as in "fail to parse"

[06:22:34.0000] <darobin>
tobie: catchy name, for this "http://www.w3.org/2001/02pd/rec54#ED" property uh?

[06:52:36.0000] <tobie>
darobin: don't expect me to understand what the name of the property is by reading this thing.

[06:52:59.0000] <darobin>
well it's easy!

[06:53:28.0000] <darobin>
pick a domain, then a random year, a mixture of random letters and numbers, then an anchor and a human-oriented shortname

[06:53:29.0000] <tobie>
darobin: my eyes can't get off of all the urls and namespaced props. sorry.

[06:53:33.0000] <darobin>
welcome to the semantic web!

[06:54:00.0000] <darobin>
oh you wish that were namespaced — it's not

[06:54:05.0000] <darobin>
RDF doesn't have namespaces

[06:54:08.0000] <darobin>
that *the* name

[06:54:13.0000] <tobie>
yeah, thankfully, this subset of semantic want parses as XML.

[06:54:27.0000] <darobin>
a blessing in disguise

[06:54:42.0000] <darobin>
I reckon this is the first time I see someone thankful for RDF/XML

[06:54:58.0000] <tobie>
The fact I'm thankful something parses as XML says a lot about how I feel about it.

[06:55:44.0000] <tobie>
Well granted thee are descent xml to json converters

[06:56:26.0000] <jgraham>
That's a HTML formatting, generated using XSLT, or an RDF schema that models the W3C process? There's so much wrong there I don't know where to start

[06:57:17.0000] <tobie>
At least the data is avaiable.

[06:58:13.0000] <tobie>
I also like my object in JS to look like this: obj["contact:homePage"][0]["$"]["rdf:resource"]

[06:58:23.0000] <tobie>
so much fun.

[06:59:46.0000] <annevk>
darobin: there was an idea about putting PSL into DNS, but nothing that really gained traction

[07:00:13.0000] <darobin>
annevk: I thought of that, but what's the advantage?

[07:00:55.0000] <annevk>
darobin: decentralized

[07:01:25.0000] <Ms2ger>
... extensibility?

[07:01:27.0000] <annevk>
darobin: however, might require a level of understanding not present there

[08:12:09.0000] <Domenic>
Does anyone have the TL;DR on what makes <script> parsing insane? seems like a mathiasbynens type thing :P

[08:12:41.0000] <annevk>
Domenic: it's a third of the states?

[08:12:45.0000] <mathiasbynens>
Domenic: document.write

[08:13:40.0000] <Domenic>
annevk: yeah, I guess that's too short :P. mathiasbynens: ahhh that makes sense.

[08:13:51.0000] <Domenic>
there are other issues too right? e.g. the </script> detection

[08:14:05.0000] <mathiasbynens>
http://mths.be/etago

[08:14:15.0000] <SamB>
there's document.write(), stuff like the <!-- --> (though CSS has that too), the fact that hardly anything needs to be escaped inside <script> (</script> is the main thing that comes to mind), etc?

[08:14:44.0000] <jgraham>
Yeah, the double dash stuff is the worst

[08:15:06.0000] <Domenic>
so if we were designing <module> from scratch, we would still need no-escaping and </module>, but we could remove <!-- --> and document.write()... maybe.

[08:18:15.0000] <annevk>
Domenic: it seems like a very big XSS hole to have <module>

[08:18:28.0000] <Domenic>
annevk: ah yeah, true :((

[08:18:41.0000] <jgraham>
Yeah, script type="module" seems way safer

[08:18:54.0000] <Domenic>
annevk: but hey, I thought we gave up that battle once <link rel="import"> arrived? :P

[08:19:10.0000] <annevk>
Domenic: also, if <module> has different characteristics from <script>, it seems even harder for people to deal with the hazard

[08:19:26.0000] <jgraham>
Please tell me that thread ended with people agreeing that link rel=import was a bad idea?

[08:19:30.0000] <Domenic>
annevk: which hazard?

[08:19:41.0000] <annevk>
Domenic: XSS

[08:20:17.0000] <Domenic>
jgraham: the hope was that <module> would be the new <script>, which kind of requires the easy-path to be at least as short to type, instead of having to add extra characters. I.e., trying to avoid the annoyingness of "use strict" or <!DOCTYPE html>.

[08:21:15.0000] <Domenic>
Although I guess it is kind of true that if implementers are shipping <link rel="import"> without XSS concerns they have already decided that blacklist-based XSS is not a use case they want to support.

[08:21:27.0000] <Domenic>
s/XSS/XSS prevention/

[08:21:57.0000] <jgraham>
It's possible that it also shows they dropped the ball and failed to consider it

[08:22:09.0000] <jgraham>
security isn't a use case

[08:22:48.0000] <annevk>
Domenic: I think Hixie is right that the annoying thing is that modules require syntax in the first place

[08:22:57.0000] <annevk>
Domenic: out-of-band syntax, that is

[08:23:27.0000] <Domenic>
annevk: I don't really think so. I have no issues with that part of the design.

[08:23:41.0000] <Domenic>
I.e. practically speaking it doesn't cause me any grief.

[08:24:05.0000] <Domenic>
worst case-scenario, we get no new toys and I just do <script>System.import('bootstrap-module')</script>

[08:24:56.0000] <jgraham>
So this conversation rather suggests that it does cause grief…

[08:25:41.0000] <jgraham>
I mean you can't simultaneously say it's not a problem to require syntax and that <script module> is too much syntax

[08:26:01.0000] <jgraham>
or type=module

[08:26:10.0000] <jgraham>
I don't know what back-compat stoy you want

[08:28:33.0000] <Domenic>
the current party line is that <script type="module"> is the transitional back-compatible thing, but eventually when all browsers implement <module> people can just use that instead. clearly that is pretty naive, as various aspects of this conversation reveal. but it seems possible at least.

[08:29:13.0000] <SamB>
why would there ever be a time when all browsers have implemented any particular new thing?

[08:29:17.0000] <annevk>
I don't get the whole transitional party line.

[08:29:32.0000] <annevk>
I have heard Dave argue it, but no other feature has ever had such treatment

[08:30:05.0000] <annevk>
If you want <module>, make that happen and create a polyfill with the former. Don't add two features to the platform that require indefinite support

[08:30:49.0000] <jgraham>
Didn't we just decide that <module> is XSS unsafe?

[08:31:32.0000] <annevk>
jgraham: arguably we have introduced a lot that is XSS unsafe, so the weight of that argument is unclear

[08:31:34.0000] <SamB>
jgraham: is that because we already have lots of anti-XSS stuff that has never heard of <module>, or is it something more fundamental?

[08:32:05.0000] <jgraham>
annevk: What have we introduced recently?

[08:32:16.0000] <annevk>
jgraham: various <video> event handlers

[08:34:06.0000] <jgraham>
Hmm, that does seem suboptimal

[08:35:57.0000] <SamB>
doesn't flagrantly XSS-unsafe stuff usually end up crippled in fairly short order?

[08:37:59.0000] <Domenic>
SamB: example?

[08:38:48.0000] <SamB>
well, okay, maybe not "fairly short"

[09:35:28.0000] <Hixie>
the difference is that <module> introduces radically new (and crazy) parsing rules

[09:35:45.0000] <Hixie>
that's why it's orders of magnitude more scary for security than new event handlers

[09:36:34.0000] <SamB>
... why would anyone let non-legacy parsing crazy into the HTML spec?

[09:37:28.0000] <jgraham>
Because they want module to work like script

[09:37:38.0000] <jgraham>
but to not be called script

[09:37:42.0000] <jgraham>
For some reason

[09:38:30.0000] <SamB>
but, they can't just use script's parsing rules because why?

[09:40:30.0000] <jgraham>
script has crazy parsing rules already

[09:40:52.0000] <jgraham>
So making those rules apply in a different context is new and crazy

[09:41:19.0000] <SamB>
not *radically* new and crazy, surely?

[09:42:28.0000] <SamB>
so I'm assuming Hixie meant something worse than that

[09:48:19.0000] <Hixie>
they'd be radically new because they'd apply to <module>, which they didn't apply to before

[09:48:42.0000] <Hixie>
and either they're crazy because they're like <script>, or they're crazy because they're specifically _not_ like <script>

[09:48:56.0000] <Hixie>
you're damned either way if you introduce a new script-containing element

[09:49:14.0000] <Hixie>
it's just a bad idea and we should stay away from anything that results in multiple script-capable elements

[09:49:45.0000] <Hixie>
(this would all have been much easier if the ES group had reached out before designing their module thing, to coordinate with us and figure out what was reasonable and what was not.)

[09:50:35.0000] <caitp>
you've still got a few months to get them to change their minds about things =)

[10:07:51.0000] <SamB>
Hixie: hmm, refactoring those words from saying "</script>" to saying "</script> or </module>, respectively" doesn't seem like a radical CHANGE, just a stupid one

[10:08:27.0000] <Hixie>
SamB: it's radical in that it radically changes how <module> is parsed, but if you're just arguing the semantics of how i phrased it, i'll concede :-)

[10:08:33.0000] <SamB>
I mean, would it add a huge amount of logic? not as far as I can see. would it give bizarrely different parse results in new and old browsers? hell yes.

[10:08:57.0000] <Hixie>
"bizarrely different parse results in new and old browsers" seems "radical" to me :-)

[10:09:05.0000] <Hixie>
and "crazy" too :-)

[10:09:06.0000] <SamB>
anyway, evil like <script> parsing should be kept strictly to legacy things

[10:09:26.0000] <SamB>
Hixie: well, the *rules* aren't radically new, the *behaviour* is

[10:09:50.0000] <Hixie>
i don't understand the difference, but this seems like splitting hairs so i'll extricate myself from the conversation now :-P

[10:10:02.0000] <Hixie>
<script> isn't going to be legacy, though, however much the ES folk want it to be

[10:10:10.0000] <Hixie>
we'll be using non-module scripts for decades

[10:10:28.0000] <SamB>
well, I mean, they shouldn't be encouraged to BREED

[10:10:41.0000] <Hixie>
doesn't matter how much you encourage them

[10:10:48.0000] <SamB>
it's legacy in the sense that crazy rules are a legacy

[10:10:57.0000] <Hixie>
oh well sure

[10:11:28.0000] <SamB>
not so much in the sense of "expected to die at some point"

[10:12:12.0000] <SamB>
kind of like that one argument to WinMain that's leftover from Win16

[10:12:21.0000] <SamB>
hPrevInstance

[10:13:13.0000] <Hixie>
well the difference is people ignore hPrevInstance now

[10:13:21.0000] <SamB>
true

[10:13:22.0000] <Hixie>
whereas <script> is going to be actively used for decades

[10:13:36.0000] <SamB>
maybe that's got more bearing on the <!-- --> part

[10:14:10.0000] <SamB>
anyway, I don't think hPrevInstance can possibly have a value in win32

[10:14:43.0000] <Hixie>
it's always NULL, no?

[10:14:58.0000] <SamB>
er, yeah, a non-0 value I mean

[10:15:53.0000] <SamB>
on account of win32 having per-process address spaces

[10:17:00.0000] <SamB>
/me should stop babbling

[10:34:17.0000] <Hixie>
can someone sanity check me?: in |An end tag whose tag name is "form"|, in the "in body" insertion mode, the "Otherwise" clause of step 2 of the first branch is redundant with step 1, right?

[10:36:38.0000] <jgraham>
Hixie: Well it doesn't make any sense at least

[10:37:02.0000] <jgraham>
Since it's an otherwise on an infallible operation

[10:37:06.0000] <Hixie>
yeah

[10:37:13.0000] <Hixie>
i'll just remove that second sentence of step 2

[10:38:49.0000] <SamB>
or, make a note like "I am invincible!"

[10:38:55.0000] <TabAtkins_>
Ms2ger: What's this about custom DTDs and the CSSWG yesterday?

[10:39:10.0000] <SamB>
what does a DTD have to do with anything

[10:39:30.0000] <SamB>
I thought a DTD was just a way to make your SGML editor do sensible autocompletion

[10:39:45.0000] <SamB>
and your SGML parser tell you when you screwed up

[10:40:49.0000] <Ms2ger>
TabAtkins_, see http://www.w3.org/Style/

[10:41:36.0000] <SamB>
(Speaking of, what things (if any) do you folks use to edit SGML and XML, respectively?)

[10:41:51.0000] <Hixie>
emacs.

[10:42:06.0000] <hober>
no one actually edits sgml anymore :)

[10:42:22.0000] <Ms2ger>
s/anymore//

[10:42:53.0000] <TabAtkins_>
SamB: The <!-- --> thing in CSS isn't insane at all, luckily - they get parsed as tokens, and ignored at the top-level of the stylesheet.  No big deal.

[10:43:14.0000] <TabAtkins_>
Ms2ger: I... I see.

[10:43:17.0000] <SamB>
I feel like it's kind of a shame about SGML; maybe SGML would have gotten more love if the specs hadn't been locked up in the ISO ...

[10:43:22.0000] <jgraham>
It's OK, once hober finishes his emacs HTML mode you won't need DTDs to enable syntax checking and autocomplete :p

[10:43:56.0000] <SamB>
I was actually wondering what modes ;-P

[10:44:09.0000] <Hixie>
SGML had two serious flaws, imho

[10:44:19.0000] <Hixie>
first, it was WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY more complicated than necessary

[10:44:27.0000] <Hixie>
second, it was WAAAAAY not powerful enough

[10:44:28.0000] <SamB>
and I didn't ask about HTML precisely because of the lack of an adequate mode for actual HTML, rather than for it's fictioanl SGML forms

[10:45:15.0000] <SamB>
Hixie: yeah, SGML declarations do seem kind of dopey

[10:46:01.0000] <SamB>
there's, maybe, *one* good thing about them: they managed to retrofit SGML to allow a declaration for XML ...

[10:46:56.0000] <SamB>
anyway use psgml and nxml/rng

[10:47:31.0000] <Hixie>
XML has two serious flaws, imho

[10:47:39.0000] <SamB>
yeah?

[10:47:40.0000] <Hixie>
first, it was WAY more complicated than necessary

[10:47:42.0000] <hober>
jgraham: :/

[10:47:46.0000] <Hixie>
second, it was WAAAAAAAAY not powerful enough

[10:47:54.0000] <SamB>
Hixie: well, at least that's a lot less As in the first flaw

[10:48:04.0000] <Hixie>
yup :-)

[10:48:06.0000] <TabAtkins_>
Yeah, XML isn't *that* over-complicated.

[10:48:11.0000] <TabAtkins_>
Just a good bit.

[10:48:27.0000] <SamB>
Hixie: what are the extra As in the second flaw for?

[10:48:36.0000] <Hixie>
it's less powerful than SGML

[10:48:37.0000] <TabAtkins>
XML is weaker than SGML.

[10:48:41.0000] <Hixie>
so...

[10:48:50.0000] <gavinc>
No over lapping tag spans :(

[10:49:05.0000] <SamB>
Hixie: yes, well, isn't DTD almost counter to the whole XML idea anyway

[10:49:09.0000] <TabAtkins>
SGML had overlapping tags?

[10:49:15.0000] <TabAtkins>
Non-tree data structure?

[10:50:01.0000] <SamB>
all I know of SGML I learned from James Clark's implementation ;-P

[10:50:20.0000] <SamB>
well, maybe not quite, but I wouldn't know much about anything he didn't implement

[10:50:29.0000] <Hixie>
if we restrict ourselves to tree structure use cases (which is a big restriction which we can come back to), XML is either too complicated because of all the DTD baggage, or not powerful enough because DTDs can barely describe the simplest of conformance requirements.

[10:51:36.0000] <Hixie>
man, the html parser spec has an inordinate number of negated conditions

[10:51:43.0000] <Hixie>
and i keep forgetting to negate them in my code

[10:51:55.0000] <Hixie>
leading to annoyingly hard-to-debug bugs

[10:52:01.0000] <SamB>
basically I think we should just forget about DTD except *maybe* as a vehicle for defining those, er, shorthand things

[10:52:13.0000] <SamB>
RNG is much, much better

[10:52:27.0000] <SamB>
(though maybe harder to explain)

[10:52:30.0000] <gavinc>
Entities are what DTDs get you that RNG still doesn't

[10:52:40.0000] <SamB>
that's the word!

[10:52:46.0000] <jgraham>
Hixie: You know, you are the person on the planet least likely to get sympathy there

[10:53:10.0000] <gavinc>
but entites introduce all sorts of nastyness

[10:53:18.0000] <Hixie>
jgraham: :-)

[10:53:33.0000] <SamB>
gavinc: yeah, the nastyness is why I said "*maybe*"

[10:53:34.0000] <gavinc>
since what most people want is names for hard to remember unicode characters, and what you get is a complex include system

[10:53:39.0000] <Hixie>
i've found a few bugs in the parser with this nutty project of mine

[10:53:44.0000] <Hixie>
so i feel like i'm being productive

[10:54:12.0000] <SamB>
Hixie: then, you just need to figure out how to compile it back to English

[10:54:29.0000] <Hixie>
unfortunately i'm not implementing the full parser

[10:54:36.0000] <Hixie>
e.g. i'm ignoring all the script execution stuff

[10:55:05.0000] <SamB>
darn it, why do w3.org / html5.org have so much higher pagerank for this phrase anyway

[10:55:19.0000] <Hixie>
which phrase?

[10:55:53.0000] <SamB>
An end tag whose tag name is "form"

[10:58:26.0000] <Hixie>
wow, yeah, that's sad

[10:59:15.0000] <SamB>
anyway, jgraham is totally right about that being nonsense

[10:59:38.0000] <SamB>
if you fail to set the form element pointer, I think it's time to die to SIGSEGV

[10:59:47.0000] <Hixie>
k. it's gone.

[11:14:15.0000] <Hixie>
TabAtkins: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503 - any chance we could have an efficient 'display-*' value for <br>?

[11:28:02.0000] <TabAtkins>
Yeah, need to take that back to the CSSWG.  Will do so.

[11:28:07.0000] <Hixie>
ta

[11:28:30.0000] <SamB>
what makes a CSS value efficient?

[11:28:39.0000] <Hixie>
see dbaron's comment in that bug

[11:29:56.0000] <annevk>
"What the actual fuck." <3 Mark Pilgrim

[11:37:18.0000] <Hixie>
i wonder what he thinks would be better

[11:37:25.0000] <Hixie>
an @rule in CSS?

[11:38:02.0000] <TabAtkins>
What's the context of that one?

[11:38:52.0000] <TabAtkins>
annevk: Do you have any examples of multipe-documents-in-one-window-sharing-fonts besides Imports?  Imports are already kinda-sorta same document, right?

[11:40:20.0000] <Hixie>
blink-dev

[11:40:38.0000] <Hixie>
does everyone agree that "If there is no adjusted current node" is equivalent to "If the stack of open elements is empty" ?

[11:42:20.0000] <SamB>
oh, why the heck did I get <br> mixed with <hr> ...

[11:43:30.0000] <SamB>
fragment case is a bit tricky to follow ... processing ...

[11:44:07.0000] <SamB>
also apparently "fragment case" is a technical term you didn't use here

[11:45:43.0000] <SamB>
/me can't follow where it goes from "if there is a context element" to just "the context element"

[11:46:38.0000] <SamB>
Hixie: I guess it does

[11:48:05.0000] <SamB>
Hixie: what happened to adding caution tape around any mention of direction WRT stacks

[11:51:54.0000] <Hixie>
SamB: file a bug if you're serious about that :-)

[11:52:03.0000] <Hixie>
(with concrete suggestions that don't make the spec even harder to read...)

[11:52:19.0000] <SamB>
oh, so no yellow tape then?

[11:52:28.0000] <SamB>
darn it

[11:52:37.0000] <Hixie>
i'm happy to do it, i just don't know how exactly

[11:54:35.0000] <Ms2ger>
The annoying thing is that it's not a stack, obviously :)

[11:54:51.0000] <SamB>
Ms2ger: oh

[11:54:53.0000] <SamB>
really?

[11:55:08.0000] <SamB>
it's not just a magnetic stack or something?

[11:55:32.0000] <SamB>
anti-gravity stack, maybe?

[11:56:58.0000] <Ms2ger>
It admits random access

[11:58:01.0000] <Hixie>
yeah, it's a stack where every now and then you just have to fiddle with it arbitrarily

[11:58:09.0000] <Hixie>
removing, swapping nodes around, all kinds of crazy stuff

[11:59:17.0000] <caitp>
just imagine if the parser didn't have to swap nodes around

[11:59:26.0000] <caitp>
what if...

[12:01:51.0000] <Ms2ger>
So, "an array"

[12:01:55.0000] <Ms2ger>
Or a vector

[12:03:25.0000] <SamB>
meh, I do stuff like that to stacks IRL all the time ;-P

[12:03:36.0000] <SamB>
though the most accessible item is at the TOP of the stack

[12:03:41.0000] <Hixie>
caitp: it would be awesome

[12:03:49.0000] <Hixie>
caitp: (also, it would not be compatible with most of the web)

[12:03:58.0000] <Hixie>
are we agreed that when the spec says "reprocess the token", it means to go through tree construction dispatcher again?

[12:05:31.0000] <SamB>
Hixie: hmm, the diagram in "Overview of the parsing model" has a green block obscuring part of it ...

[12:05:48.0000] <SamB>
TabAtkins: I blame you guys for this!

[12:07:00.0000] <Hixie>
oh wow, yeah

[12:07:01.0000] <Hixie>
oops

[12:07:20.0000] <Hixie>
TabAtkins: does HTML have a way to make boxes not overlap floats yet?

[12:07:27.0000] <Hixie>
i remember mozilla implemented something to do this way back when

[12:07:31.0000] <Hixie>
as a hack

[12:08:31.0000] <SamB>
you mean like a -moz- property or value?

[12:09:24.0000] <Hixie>
yeah

[12:19:40.0000] <TabAtkins>
Hixie: Only via BFC creation.

[12:19:47.0000] <Hixie>
bfc?

[12:19:47.0000] <TabAtkins>
All the methods of which have side-effects.

[12:19:54.0000] <TabAtkins>
Block Formatting Context.

[12:19:57.0000] <Hixie>
ah

[12:20:02.0000] <Hixie>
bumemr

[12:20:04.0000] <TabAtkins>
overflow: anything-but-visible is the most common way.

[12:21:36.0000] <Hixie>
what's anything-but-visible?

[12:21:56.0000] <Hixie>
i wonder how to fix this rendering issue

[12:22:01.0000] <Hixie>
maybe just make the float a higher z-index for now

[12:23:11.0000] <TabAtkins>
Hixie: It's... what it sounds like?

[12:23:31.0000] <Hixie>
what counts as 'visible'?

[12:23:54.0000] <Hixie>
does it mean "don't show a scroll bar if the bottom of this image is the only thing that overflows and the bottom of the image is fully transparent", for instance?

[12:24:09.0000] <TabAtkins>
Hixie: The "visible" keywords.  I'm being very literal.

[12:24:14.0000] <TabAtkins>
keyword, sorry.

[12:24:27.0000] <Hixie>
oh, not a specific keyword "anything-but-visible"

[12:24:28.0000] <Hixie>
ok

[12:24:38.0000] <TabAtkins>
Hahaha, of course not

[12:24:44.0000] <Hixie>
sorry, i thought you were being more literal than you were :-)

[12:24:54.0000] <TabAtkins>
That's too silly even for CSS.

[12:24:54.0000] <Hixie>
hey i dunno man, there's all kinds of new keywords in CSS these days that i've never heard of :-)

[12:25:20.0000] <Hixie>
setting 'overflow:hidden' on every paragraph in the HTML spec seems like a bad call

[12:25:26.0000] <Hixie>
z-index seems bad too though

[12:25:29.0000] <Hixie>
ugh

[12:25:46.0000] <Hixie>
i really just want a "warp my block background around floats" option

[12:25:51.0000] <Hixie>
oh well

[12:26:17.0000] <SamB>
what would happen if you *did* write "display: anything-but-visible"?

[12:26:22.0000] <SamB>
that's not "display: visible"

[12:26:38.0000] <SamB>
er. or "overflow:", whatever

[12:26:49.0000] <Hixie>
it would get ignored

[12:26:50.0000] <Hixie>
since it's not valid

[12:26:54.0000] <Hixie>
same as overflow: aiohfgoaiehjdzl;

[12:26:58.0000] <SamB>
right.

[12:27:01.0000] <Hixie>
or alkfjalksjf: alfhjalksfj

[12:27:36.0000] <SamB>
yeah, any idiot could tell that last one wouldn't do anything

[12:28:25.0000] <SamB>
there being no "alkfjalksjf" property and all

[12:30:14.0000] <Hixie>
are we agreed that "Pop an element from the stack of open elements, and then keep popping more elements from the stack of open elements until" implies that at least two elements will be popped?

[12:30:35.0000] <Domenic>
no

[12:30:38.0000] <Domenic>
sounds like at least one

[12:30:39.0000] <TabAtkins>
What's the float thing you're trying to do?

[12:31:07.0000] <Hixie>
TabAtkins: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26079

[12:31:21.0000] <SamB>
Hixie: me either, uness the "until" specifically refers to an *additional* element

[12:31:55.0000] <Hixie>
hmm... i guess

[12:31:59.0000] <Hixie>
i should make that clearer then

[12:36:31.0000] <TabAtkins>
Hixie: I've been looking through sections, but haven't fouind an example of such yet.

[12:36:51.0000] <TabAtkins>
Hixie: I'm also with the "at least one" interpretation.

[12:37:26.0000] <Hixie>
TabAtkins: the link in that bug is to a section with an image

[12:37:28.0000] <TabAtkins>
I'd say "pop elements from the stack of open elements until .... If this would pop less than two, pop two elements."

[12:38:02.0000] <TabAtkins>
Hm, I don't see it.

[12:39:01.0000] <Hixie>
search for "The input to the HTML parsing process consists of"

[12:39:04.0000] <Hixie>
and look to the right

[12:39:09.0000] <Hixie>
it's in 12.2.1 Overview of the parsing model

[12:40:10.0000] <TabAtkins>
Looks like that's not in the pointed-to section of the multipage. ^_^

[12:41:21.0000] <TabAtkins>
Ok, I see.

[12:41:31.0000] <TabAtkins>
We put overflow:hidden on all .note/.example/etc in the CSSWG stylesheet.

[12:41:34.0000] <TabAtkins>
Precisely to fix this.

[12:41:38.0000] <Hixie>
ah

[12:41:50.0000] <Hixie>
i think that would break all my fancy label things

[12:41:53.0000] <Hixie>
since they overflow

[12:41:58.0000] <TabAtkins>
Ah, true.

[12:42:47.0000] <TabAtkins>
WELP

[12:43:20.0000] <Hixie>
hm?

[12:43:21.0000] <SamB>
shouldn't it just be possible to make boxes extend to the right until they hit a float *or* hit the parent's edge?

[12:43:44.0000] <TabAtkins>
SamB: It *should* be, yes.  But it's not.

[12:43:47.0000] <Hixie>
samb: it's non-trivial, but that's what i'd like. Actually what i'd like is that they wrap their backgrounds around.

[12:43:53.0000] <Hixie>
but that's even less trivial

[12:44:09.0000] <SamB>
wrap their backgrounds around, you say?

[12:44:31.0000] <TabAtkins>
We have a trial value (with a purposely-bad name) in the Sizing spec that does this, but it's underspecified, as it only addresses sizes, not the position-shifting that BFCs do.

[12:44:34.0000] <SamB>
sounds like you want to print it out, cut out the pieces, and then glue them together ;-P

[12:44:52.0000] <Hixie>
and wrap their borders, for bonus points

[12:45:10.0000] <SamB>
TabAtkins: what about position shifting would it need to address?

[12:45:14.0000] <TabAtkins>
Those all come as part of a package, Hixie.

[12:45:36.0000] <Hixie>
even border-radius with border images? :-)

[12:45:36.0000] <TabAtkins>
SamB: If you have a left-floated item next to a BFC, the BFC not only shrinks its width, but also shifts to the right to get out of the way.

[12:45:48.0000] <SamB>
ouch

[12:45:58.0000] <TabAtkins>
Hixie: If your border images don't extend out of the border geometry, sure.

[12:46:02.0000] <SamB>
left floats FTL :-(

[12:46:05.0000] <TabAtkins>
Or if you're willing to add margin to address that.

[12:46:11.0000] <TabAtkins>
Left floats the most common float.

[12:46:27.0000] <SamB>
is it?

[12:46:28.0000] <Hixie>
TabAtkins: just so we're clear, i'm not talking about just resizing, i'm talking about wrapping around the float(s)

[12:46:38.0000] <TabAtkins>
I don't know what you mean, in that case.

[12:46:40.0000] <Hixie>
which would mean the border now has multiple corners, some concave, some convex...

[12:46:43.0000] <TabAtkins>
Oh!

[12:46:47.0000] <TabAtkins>
No.

[12:46:51.0000] <TabAtkins>
^_^

[12:46:51.0000] <SamB>
oh, yeah, that'd be even nicer

[12:46:52.0000] <Hixie>
that's why it's worth bonus points

[12:47:00.0000] <Hixie>
many, many bonus points...

[12:47:22.0000] <SamB>
you'd need extra border- stuff to put special background on the concave corners

[12:47:45.0000] <Hixie>
well crap

[12:48:05.0000] <Hixie>
the "any other end tag" step of the foreign parsing mode totally messes with all my optimisations

[12:48:13.0000] <SamB>
I mean, if you wanted to do one of the silly raster-based box things like people used to do with <table>

[12:48:19.0000] <Hixie>
"If node's tag name, converted to ASCII lowercase, is the same as the tag name of the token"!

[12:48:30.0000] <TabAtkins>
Just match CSSWG's style for notes/examples/etc? They were put together by actual designers, and have gotten lots of compliments over the years we've used them.

[12:48:33.0000] <Hixie>
i guess i'd better keep multiple tag names around...

[12:48:43.0000] <SamB>
Hixie: shouldn't the node already have a lowercased name?

[12:48:50.0000] <Hixie>
SamB: not in foreign content

[12:48:53.0000] <SamB>
darn

[12:49:13.0000] <SamB>
well then why does the close tag not have to match?

[12:49:58.0000] <Hixie>
because if you write <svg><CLIPPATH></clippath> the two "clippath" tags have to match

[12:50:03.0000] <Hixie>
but the element is actually <clipPath>

[12:50:15.0000] <Hixie>
i guess i'll just store a lowercased tag name

[12:51:27.0000] <SamB>
if you only know the case because you looked it up in a table, it seems almost silly to store the proper-cased version in the tree node

[12:51:49.0000] <Hixie>
well the proper-cased version is what you need for everything but parsing

[12:52:25.0000] <SamB>
... what exactly do you use the tree for in your implementation?

[12:53:21.0000] <SamB>
/me starts imagining strings with memoized lowercasing

[12:53:54.0000] <SamB>
hmm, do/can they have interning in JS?

[12:54:14.0000] <Hixie>
well e.g. a browser would need to know the right case to distinguish a <clipPath> element from a <clippath> element (the latter of which does nothing, the former is part of SVG)

[12:54:16.0000] <SamB>
or do they have those silly mutable strings like elisp has

[12:54:29.0000] <SamB>
Hixie: certainly

[12:57:03.0000] <SamB>
Hixie: but, uh, can't they just inherit the names from the traits object?

[12:57:16.0000] <Hixie>
the what now?

[12:57:33.0000] <SamB>
I think they mistakenly call them "prototypes" in JS?

[12:57:57.0000] <SamB>
darn, I forgot the ;-P

[12:58:01.0000] <Hixie>
who's using JS?

[12:58:07.0000] <SamB>
hmm

[12:58:51.0000] <SamB>
hmm, are you implying that there's going to be a browser that supports embedded SVG but doesn't represent its DOM using JS objects?

[12:59:27.0000] <Hixie>
no browser represents its DOM using JS objects

[12:59:39.0000] <Hixie>
that would be a performance disaster.

[12:59:54.0000] <TabAtkins>
We inch closer to that every day.

[13:00:08.0000] <TabAtkins>
dom.js is a project we keep shooting for.

[13:00:29.0000] <SamB>
I thought they just used magic pixie dust to make the fixed-layout stuff work

[13:00:48.0000] <SamB>
so the C++ code can keep pretending it's not a JS object

[13:02:08.0000] <SamB>
I guess JS doesn't have a way to pre-specify "slots" to be used for a certain class (not OO class, just the regular meaning) of objects?

[13:03:00.0000] <Hixie>
this is all academic in this instance, since my parser is not in JS

[13:10:32.0000] <SamB>
point

[13:11:38.0000] <SamB>
really what I meant is: why would you have to store the name in each node, rather than in a single thing that describes all elements of that name?

[13:12:05.0000] <SamB>
except for elements you've never heard of

[13:13:08.0000] <Ms2ger>
Ah, blink: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/nzRY-h_-_ig

[13:13:13.0000] <SamB>
Hixie: ... but, do you think you're the only one who'se allowed to talk "as if" the implementation must the JS DOM to represent the document?

[13:13:18.0000] <SamB>
+use

[13:13:25.0000] <SamB>
even while not actually meaning that

[13:14:15.0000] <SamB>
(Yes, I went there: I just specified the "as if" rule backward.)

[13:14:37.0000] <Ms2ger>
/me specifies as if SamB made sense

[13:14:44.0000] <SamB>
sorry :-)

[13:14:55.0000] <SamB>
/me will go back to easy things, like maintaining GDB packaging

[13:18:28.0000] <Hixie>
SamB: well i'm only storing a pointer, obviously

[13:18:41.0000] <Ms2ger>
/me points at Hixie 

[13:19:10.0000] <SamB>
Hixie: what language *are* you using again?

[13:19:20.0000] <TabAtkins>
objectpascal, obvs.

[13:19:27.0000] <SamB>
hmm.

[13:19:46.0000] <TabAtkins>
Hixie's favorite language.

[13:21:02.0000] <SamB>
yeah, I imagine there's a reason it has such a happy-seeming contingent of user despite being virtually unmarketed for ... a long time now?

[13:21:20.0000] <SamB>
*users

[13:22:13.0000] <SamB>
huh

[13:22:24.0000] <SamB>
Need to get 17.1 MB of archives.

[13:22:24.0000] <SamB>
After this operation, 161 MB of additional disk space will be used.

[13:22:32.0000] <Ms2ger>
Uncompressed?

[13:22:52.0000] <SamB>
I guess they ship sources for the libs?

[13:23:01.0000] <SamB>
that's for fpc

[13:24:20.0000] <TabAtkins>
SamB: Shrug, I'm a happy Common Lisper. We all have our kinks.

[13:24:43.0000] <Hixie>
i think i'd be a C++ head if i hadn't happened to start with pascal

[13:24:50.0000] <Hixie>
they're very similar, at the end of the day

[13:24:58.0000] <SamB>
Common Lisp always leaves me overloaded trying to figure out how to go about my business :-(

[13:25:01.0000] <SamB>
too many choices

[13:25:05.0000] <Hixie>
in terms of what they're good at and their performance characteristics

[13:25:25.0000] <Hixie>
but having started in pascal and then later delphi, i find C++ to be really ugly

[13:25:30.0000] <TabAtkins>
"There's an infinity of ways to do it, and that's not counting readtable hacking."

[13:25:55.0000] <Ms2ger>
I think everyone finds C++ ugnly

[13:25:56.0000] <Ms2ger>
ugly

[13:26:04.0000] <SamB>
I think Object Pascal has some important advantages; optimizations implemented in the compiler not being one of them.  Unless it makes the compiler run way faster, which it might ;-)

[13:26:05.0000] <TabAtkins>
Even the word is ugnly.

[13:26:15.0000] <Ms2ger>
Thank you, TabAtkins

[13:26:50.0000] <SamB>
the important advantages can basically be summarized as "not being fugly" and "having a real module system"

[13:27:13.0000] <Ms2ger>
Modules are pretty big

[13:27:48.0000] <SamB>
and C++ code wants to recompile at the drop of a hat

[13:28:33.0000] <SamB>
C doesn't have so much trouble there because C actually supports encapsulation

[13:34:25.0000] <SamB>
/me idly wonders if Hixie uses the IDE or Emacs to edit his Object Pascal

[13:34:48.0000] <Hixie>
emacs

[13:34:54.0000] <Hixie>
i couldn't get the ide to work

[13:35:01.0000] <Hixie>
(didn't try very hard, mind you)

[13:35:42.0000] <Hixie>
SamB: pascal as a language is designed to compile really freaking fast, especially when you only change one file (unit)

[13:36:01.0000] <SamB>
having interface files tends to help with that :-)

[13:36:04.0000] <Hixie>
SamB: but yeah, the freepascal compiler's optimisations aren't the world's leading optimisations

[13:36:19.0000] <SamB>
at least I know I've seen GHC tell me "oh whoops don't need to recompile that module" lots of times

[13:36:33.0000] <SamB>
Hixie: it seems kind of traditional ;-)

[13:37:02.0000] <SamB>
I mean have you seen the code that TP used to emit?

[13:37:24.0000] <SamB>
granted, I guess part of that is that the registers are even *less* flexible in 16-bit mode

[13:40:26.0000] <Hixie>
at the time i used TP, i wasn't particularly knowledgable about optimisations

[13:40:50.0000] <Hixie>
i mean, when i was a kid i thought that short-circuit boolean evaluation was Hot Stuff...

[13:43:40.0000] <Hixie>
hm, oops.

[13:43:49.0000] <Hixie>
i didn't notice that "push onto the list of active formatting elements" was non-trivial.

[13:44:52.0000] <SamB>
yeah, well, see, I was trying to decompile ZZT by hand

[13:45:07.0000] <SamB>
using a slightly different version of TP/BP

[13:45:22.0000] <SamB>
in modern times

[13:45:43.0000] <caitp>
annevk, firefox and chrome behave differently WRT the same-origin policy when talking to file uris (with the default security.fileuri.origin_policy) --- which behaviour is actually correct? it seems to me that gecko is doing the wrong thing here, but it's not super clear

[13:45:49.0000] <annevk>
TabAtkins: what if you paint on a <canvas> from another document?

[13:45:59.0000] <SamB>
but this was before I learned how restricted the registers are in 16-bit mode

[13:46:06.0000] <TabAtkins>
annevk: I don't understand what you mean.

[13:46:07.0000] <annevk>
caitp: file URLs are not standardized

[13:46:17.0000] <caitp>
hm

[13:46:40.0000] <annevk>
TabAtkins: from document create another document, create an element in that document that's named canvas

[13:46:49.0000] <SamB>
also, it's hard to figure out how to deal with file:// URLs and same-origin stuff

[13:47:12.0000] <SamB>
because there's no obvious "origin" boundaries in a filesystem

[13:47:27.0000] <TabAtkins>
annevk: I'd suppose that the "context" for the drawing op is the document that is executing the script?

[13:47:35.0000] <TabAtkins>
(That's underdefined right now.)

[13:47:51.0000] <caitp>
I think that's why in blink-land it's always a cross-origin request, and is only allowed depending on how the request is made

[13:48:04.0000] <annevk>
TabAtkins: yeah not sure, would have to test

[13:48:05.0000] <SamB>
you sure don't want to let things set their origin to "file:///" (if that means "/" in your browser on your OS)

[13:48:25.0000] <annevk>
origin is not a string people

[13:48:36.0000] <SamB>
yeah, yeah, yeah

[13:48:45.0000] <caitp>
you know what he means though =)

[13:49:16.0000] <annevk>
in any event, I'm not sure standardizing file is all that crucial

[13:49:20.0000] <SamB>
and the equivalent of "C:\\" is hardly better

[13:49:31.0000] <annevk>
making sure http to file fails is important, and Mixed Content takes care of that

[13:49:57.0000] <annevk>
and getting parsing of URLs starting with file: is somewhat important, though getting people to agree on that is harder

[13:50:08.0000] <SamB>
it would be nice if some browser would come along with a good way to set up origins though

[13:50:22.0000] <SamB>
for file://

[13:50:41.0000] <annevk>
why, file != web, it's just legacy support

[13:50:44.0000] <SamB>
maybe a file you could plop down that would say "you can count this as an origin"?

[13:50:51.0000] <annevk>
like computers supporting floppy drives

[13:51:03.0000] <annevk>
anyway, nn

[13:51:06.0000] <SamB>
annevk: it'd simplify things for locally-installed HTML documentation

[13:51:37.0000] <SamB>
say, if you built some racket docs locally

[13:52:56.0000] <caitp>
but why would you want to do that when you could push the docs to drive.google.com or whatever apple's thing is called

[13:54:43.0000] <SamB>
caitp: easier to just turn off the damn protection ...

[13:55:45.0000] <caitp>
it's not a serious response =) but I guess remote storage is one reason why it's less of a thing

[13:56:07.0000] <caitp>
or could be, at any rate.

[14:36:27.0000] <SamB>
I don't suppose I can get some decent line-wrap markers to go with my "white-space: pre-wrap"?

[14:36:52.0000] <TabAtkins>
Nope.

[14:36:55.0000] <TabAtkins>
Not without JS, that is.

[14:37:17.0000] <Domenic>
blink-dev O_O

[14:41:16.0000] <SamB>
so emacs can do it for probably the last century, and browsers *still* can't do it?

[14:44:10.0000] <TabAtkins>
Domenic: Hahaha, wtf are those people doing.

[15:04:32.0000] <hober>
TabAtkins: s/wtf/wtaf/

[15:14:45.0000] <TabAtkins>
hober: Indeed.

[15:16:24.0000] <SamB>
hmm, er, I will certainly not want hyphenation ...

[16:04:01.0000] <Hixie>
figures that i would fail on the very first test of tricky01.dat...

[16:04:18.0000] <Hixie>
with an internal error deep in the guts of my code, not even in the parser code...

[16:40:11.0000] <SamB>
/me mutters something about "display: segment-break;" ...


2014-06-13
[18:11:02.0000] <Hixie>
well, so far tricky01.dat is living up to its name

[18:11:06.0000] <Hixie>
test 1 was a huge pain to fix

[18:11:11.0000] <Hixie>
and now test 2 is failing

[18:39:04.0000] <zewt>
http://www.libpng.org/pub/png/libpng-1.4.0-manual.pdf that's one funny-looking "libpng.txt"

[19:08:03.0000] <Hixie>
good grief

[19:08:10.0000] <Hixie>
tricky01 sure is living up to its name

[19:38:03.0000] <SamB>
Hixie: the scariest part has got to be the "01"

[19:38:21.0000] <Hixie>
yeah, though sadly there's no 02

[19:39:59.0000] <SamB>
wait, you *like* scary testsuites?

[19:40:39.0000] <Hixie>
uh, yeah, they're awesome

[19:40:42.0000] <Hixie>
:-D

[19:51:57.0000] <Hixie>
ok test 8 in trick01 is just wrong. it's missing a bunch of parse errors.

[23:03:49.0000] <MikeSmith>
zcorpan: question about file:///opt/workspace/picture-element/index.html#parse-srcset-attr

[23:04:00.0000] <MikeSmith>
oofs

[23:04:09.0000] <zcorpan>
MikeSmith: yep?

[23:04:14.0000] <MikeSmith>
http://picture.responsiveimages.org/#parse-srcset-attr

[23:04:29.0000] <annevk>
https://github.com/nolanw/HTMLReader

[23:04:40.0000] <annevk>
I wonder how many languages are left without a decent HTML parser these days

[23:04:50.0000] <MikeSmith>
zcorpan: "descriptors" vs "descriptor list"

[23:05:01.0000] <MikeSmith>
annevk: Swift?

[23:05:08.0000] <annevk>
It would still be good if libxml2 added support I think, due to all the binding support for it all over

[23:05:11.0000] <annevk>
MikeSmith: heh

[23:05:42.0000] <MikeSmith>
heh on me :) I hadn't actually looked at that page before I made that comment..

[23:06:01.0000] <MikeSmith>
I mean it's not Swift but it's not what I was expecting

[23:06:17.0000] <zcorpan>
MikeSmith: "descriptor list" is set to "descriptors" in step 9

[23:06:23.0000] <MikeSmith>
oh

[23:06:28.0000] <MikeSmith>
/me looks again

[23:07:37.0000] <MikeSmith>
I guess I shouldn't try to read specs with my screen dimmed way down to save battery

[23:07:43.0000] <MikeSmith>
zcorpan: wait though

[23:07:49.0000] <MikeSmith>
9. Add candidate: Add url to raw candidates, associated with descriptors.

[23:08:23.0000] <MikeSmith>
that part is clear

[23:08:25.0000] <zcorpan>
MikeSmith: i'll probably tweak this to be less confusing, there's a bug about running the parser for each candidate as they are parsed instead of first adding to raw candidates

[23:08:42.0000] <MikeSmith>
zcorpan: ok

[23:09:14.0000] <MikeSmith>
that won't effect me at least because I parse them right away anyway

[23:09:27.0000] <MikeSmith>
I don't ever actually store the URLs

[23:09:51.0000] <zcorpan>
yeah

[23:10:06.0000] <zcorpan>
so is something not clear still?

[23:10:46.0000] <MikeSmith>
zcorpan: anyway I think it would be worth making descriptors -> list descriptor list more clear

[23:10:57.0000] <MikeSmith>
or really, I don't understand why you're using both

[23:11:08.0000] <MikeSmith>
why not just consistently use one or the other?

[23:12:34.0000] <zcorpan>
yeah so when i fix the bug i can get rid of "raw candidates" completely

[23:12:58.0000] <MikeSmith>
oh, ok

[23:13:30.0000] <zcorpan>
i haven't touched it yet because it's editorial so low prio

[23:13:45.0000] <MikeSmith>
sure

[23:15:36.0000] <MikeSmith>
zcorpan: so anyway my other question is, why does the parsing algorithm allow for multiple descriptors in image candidate strings at all?

[23:16:05.0000] <zcorpan>
MikeSmith: for future compat

[23:16:11.0000] <MikeSmith>
aha

[23:16:47.0000] <MikeSmith>
I guess I'm pretty skeptical about the value of writing future compat into specs

[23:17:32.0000] <MikeSmith>
e.g., hearing that it, is reminds me of ARIA allowing multiple roles in @role values

[23:17:46.0000] <MikeSmith>
but I guess that's an unfair comparison

[23:18:09.0000] <annevk>
MikeSmith: how are you going to address the integrity attribute?

[23:18:24.0000] <annevk>
MikeSmith: context: http://w3c.github.io/webappsec/specs/subresourceintegrity/

[23:18:25.0000] <zcorpan>
aria should have banned multiple roles for authors but the parsing was good

[23:18:32.0000] <MikeSmith>
zcorpan: so as long you're going to be making editorial changes, you might consider adding a note about that future-compat reason

[23:18:55.0000] <zcorpan>
MikeSmith: ok thx

[23:19:59.0000] <MikeSmith>
annevk: I think somebody mentioned that to me the other day and my thought was, that should be in the HTML spec if they want it to be part of the language

[23:21:02.0000] <MikeSmith>
but I think that what somebody mentioned to me was actually another attribute from a different webappsec spec that's also not in HTML yet

[23:21:16.0000] <MikeSmith>
yeah

[23:21:22.0000] <MikeSmith>
it was "nonce"

[23:21:45.0000] <MikeSmith>
annevk: kinda seems like they're making a habit of it

[23:22:12.0000] <MikeSmith>
annevk: I propose that they open bugs against the HTML spec for those

[23:22:22.0000] <MikeSmith>
I wonder if Hixie even knows about them yet

[23:22:31.0000] <zcorpan>
MikeSmith: the integrity thing might end up as a srcset descriptor later :-)

[23:22:33.0000] <MikeSmith>
I guess he knows about "nonce"

[23:22:45.0000] <annevk>
oh, that's CSP stuff?

[23:22:52.0000] <annevk>
Yeah, we should open bugs for that

[23:23:24.0000] <MikeSmith>
zcorpan: can't tell if you're trolling but I hope so

[23:23:45.0000] <zcorpan>
MikeSmith: no

[23:23:55.0000] <MikeSmith>
oh geez

[23:24:11.0000] <zcorpan>
how else would you do it if you want to use integrity + srcset?

[23:24:22.0000] <MikeSmith>
dunno

[23:24:30.0000] <zcorpan>
well then :-P

[23:24:55.0000] <MikeSmith>
because I don't really know anything about the "integrity" attribute so I don't count

[23:25:43.0000] <MikeSmith>
incidentally, "SRI" doesn't seem like such a great choice for a shortname

[23:26:03.0000] <MikeSmith>
annevk: maybe ask Mike West if he can raise the bugs

[23:26:14.0000] <MikeSmith>
since he's a friendly and clueful

[23:26:48.0000] <zcorpan>
/me notices http://w3c.github.io/webappsec/specs/subresourceintegrity/#the-noncanonical-src-attribute-todo ... 

[23:26:55.0000] <annevk>
MikeSmith: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26081

[23:27:05.0000] <MikeSmith>
damn man, these specs

[23:27:34.0000] <MikeSmith>
"Nonce sources require a new attribute to be added to both script and style elements: nonce."

[23:27:38.0000] <MikeSmith>
really?

[23:27:47.0000] <annevk>
MikeSmith: I'm not as concerned with WebAppSec

[23:28:00.0000] <annevk>
MikeSmith: now WebPerf...

[23:28:14.0000] <MikeSmith>
no comment there

[23:28:37.0000] <MikeSmith>
annevk: I'm glad you have the patience and perseverence there

[23:29:08.0000] <annevk>
I haven't really joined the WebPerf list, maybe I should...

[23:29:37.0000] <MikeSmith>
there's actually not a large amount of traffic on that list

[23:29:56.0000] <MikeSmith>
considering the state of things, I guess that's probably bad

[23:30:08.0000] <MikeSmith>
that is, there should be more traffic there

[23:33:13.0000] <MikeSmith>
anyway, I wonder in what universe it's OK that we have experienced spec writers writing stuff like "Nonce sources require a new attribute to be added to both script and style elements: nonce." into specs, and not actually attempting to normatively define the "nonce" attribute nor raise an HTML bug so that Hixie can properly define it

[23:33:21.0000] <MikeSmith>
(end rant)

[23:34:21.0000] <MikeSmith>
speaking of which, as far as I can see, dglazkov has not gotten around to normatively defining the "is" attribute

[23:34:51.0000] <MikeSmith>
or actually I think he's essentially said that it doesn't need to be normatively defined

[23:34:54.0000] <MikeSmith>
or something

[23:35:22.0000] <MikeSmith>
(end follow-up rant)

[23:35:38.0000] <MikeSmith>
/me goes back to working on picture validation

[23:38:03.0000] <zcorpan>
/me sends an email about noncanonical-src

[23:42:57.0000] <annevk>
MikeSmith: you could complain about the former on public-webappsec⊙wo and the latter on public-webapps⊙wr

[23:43:09.0000] <annevk>
MikeSmith: the latter seems useful to complain about

[23:44:06.0000] <annevk>
zcorpan: "I think the noncanonical-src feature is going to be insanely complicated to get right." probably requires some justification as I think this might have been prototyped in Blink already

[23:45:20.0000] <zcorpan>
do you have a pointer?

[23:47:09.0000] <zcorpan>
hmm, possibly pretending that it is a redirect might dodge complications. but it's not clear what was intended from the handwavy spec text

[23:48:33.0000] <zcorpan>
funny how sometimes browsers just ignore the spec (e.g. r8678)

[23:50:54.0000] <MikeSmith>
zcorpan: you mean, everybody ignores it consistently but nobody bothers to file a bug?

[23:51:33.0000] <zcorpan>
MikeSmith: yeah. or more likely in this case they don't realise that they were violating the spec

[23:52:11.0000] <zcorpan>
i.e. they implement what they think the spec says, but it's not literally what the spec says

[23:55:50.0000] <MikeSmith>
ah right

[23:58:01.0000] <MikeSmith>
zcorpan: I guess it's pretty hard for an editor to catch that kind of potential problem ahead of time

[23:58:45.0000] <zcorpan>
yes

[00:37:00.0000] <MikeSmith>
zcorpan: so another piece of feedback on picture is that I think you should consider making the parsing algorithms error-reporting

[00:37:52.0000] <MikeSmith>
zcorpan: as in, the thing of defining certain cases as parse errors but not requiring implementations to report them

[00:38:43.0000] <zcorpan>
MikeSmith: can you file a bug? https://github.com/ResponsiveImagesCG/picture-element/issues

[00:38:50.0000] <MikeSmith>
ok

[00:38:54.0000] <zcorpan>
thanks!

[00:40:45.0000] <zcorpan>
MikeSmith: i guess the algorithm for a validator needs to be a bit different since it will want to look at the whole value for sizes while a browser will want to abort parsing asap

[00:47:42.0000] <MikeSmith>
zcorpan: right. And in the case of srcset, handling the parse errors makes the implementation somewhat more complicated. e.g., if you're not reporting errors, your implementation of the splitting loop can just handle commas and whitespace there exactly the same

[00:48:06.0000] <zcorpan>
MikeSmith: yeah

[00:52:32.0000] <MikeSmith>
annevk: fwiw I really like the wording of your definition of "parse error" in the URL spec

[00:52:49.0000] <MikeSmith>
"a non-fatal mismatch between input and requirements"

[01:01:39.0000] <SamB>
/me wonders why it's not called a "warning" ......

[01:05:00.0000] <zcorpan>
SamB: it's an error because it violates authoring requirements

[01:50:22.0000] <SteveF>
JonathonNeal: yes

[01:50:42.0000] <SteveF>
JonathanNeal:yes

[02:00:23.0000] <jgraham>
Hixie: The tests in general are known to not be parse error complete

[02:00:39.0000] <jgraham>
Patches welcome

[03:29:24.0000] <annevk>
jungkees: when do you expect to simply reference Fetch?

[03:30:12.0000] <jungkees>
annevk: I'll be working on it next week

[03:31:11.0000] <annevk>
jungkees: cool, it's starting to become a bit confusing

[03:34:05.0000] <jungkees>
annevk: alright. Let's get it done sooner

[03:34:52.0000] <jungkees>
annevk: do you have anything particular that I need to be aware of? Re the design of Request/Response that we came up within the SW spec

[03:35:21.0000] <jungkees>
annevk: I've noticed that AbstractResponse has gone some such

[03:35:32.0000] <annevk>
jungkees: one thing seems to be that we want to move client/context to Request

[03:35:43.0000] <annevk>
jungkees: indeed, there's only a single Response class now

[03:36:19.0000] <annevk>
jungkees: the constructors are a bit different aligned with the discussions JakeA and I had

[03:36:50.0000] <annevk>
jungkees: toBlob() is now body.to("blob")

[03:36:55.0000] <jungkees>
annevk: alright. I'll catch up things from the Fetch spec esp. the API part

[03:37:28.0000] <annevk>
jungkees: I think best would be to just depend on those objects, just like you depend on other bits from Fetch

[03:39:29.0000] <jungkees>
annevk: Agreed. I'll have that in mind and will update the text

[03:39:52.0000] <jungkees>
annevk: Let's get it shaped next week. I'll ask things while working on it

[03:40:02.0000] <annevk>
jungkees: sounds good

[03:40:28.0000] <annevk>
jungkees: for .client I figured we want to define some kind of tuple thing

[03:40:40.0000] <annevk>
jungkees: (Client or Window or WorkerGlobalScope)

[03:41:07.0000] <annevk>
jungkees: though maybe if it's the current global we could just make it null

[03:41:13.0000] <annevk>
might be okay

[03:52:52.0000] <jungkees>
annevk: I found in HTTP fetch, it's being used to see whether the request came from SW context or not. What's the other use of .client in fetch algorithms?

[03:55:51.0000] <annevk>
jungkees: CSP / Mixed Content / ... specs make use of client

[03:56:26.0000] <annevk>
jungkees: in combination with context

[03:56:52.0000] <annevk>
jungkees: however, maybe you are right and that only makes sense in SW to be exposed

[03:57:18.0000] <annevk>
jungkees: would make my life easier

[03:57:40.0000] <jungkees>
annevk: Yeah guess so

[03:58:19.0000] <jungkees>
annevk: One quest about the queuing a task out of my own curiosity

[03:58:27.0000] <annevk>
jungkees: the argument for putting them on Request would be that they are there in the model, exposing them elsewhere in SW is somewhat odd

[03:58:59.0000] <annevk>
jungkees: sure

[03:59:00.0000] <jungkees>
annevk: is it technically wrong to queue a task from already async step? or is it a anti-practice?

[03:59:43.0000] <annevk>
jungkees: the only reason you queue a task is to sync state with the main thread

[04:00:26.0000] <annevk>
jungkees: so you have an async algorithm (that runs separately from the main thread by definition (although not formally defined yet)); and at some point you need to change a property and dispatch an event in the main thread, for that you'd queue a task

[04:00:52.0000] <annevk>
jungkees: if you just want to run some steps from an algorithm that's async, you just run them, you don't queue a task for that

[04:01:39.0000] <jungkees>
annevk: I see. thanks for the explanation

[04:05:16.0000] <annevk>
jungkees: I'll open an issue for context/client

[04:05:37.0000] <jungkees>
annevk: sure

[04:12:07.0000] <jgraham>
darobin: FWIW I disagree that shallow liking is more informative than shallow disliking. I think both indicate "I have a mild emotional reaction to this"

[04:12:40.0000] <darobin>
[dislike]

[04:13:00.0000] <darobin>
it depends what you mean by "more informative"

[04:13:32.0000] <darobin>
it does not carry more information if you're bit counting, but "like" carries all the information that it needs to IMHO, whereas "dislike" doesn't

[04:13:46.0000] <jgraham>
No, that's what I disagree with

[04:13:52.0000] <darobin>
if I propose something and you say you like it, that's all I need to know; if you say you dislike it then I want to know more

[04:14:36.0000] <darobin>
only one of those cases calls for change

[04:14:54.0000] <jgraham>
No, because if you are making a proposal that is itself a call for change

[04:15:20.0000] <darobin>
change *to the proposal*

[04:15:36.0000] <jgraham>
Knowing that people "like" a proposal isn't useful if you don't also know that they have thought through the consequences of that proposal rather than just having a shallow reaction to it

[04:23:47.0000] <annevk>
A good example of what jgraham means is parent selectors back when they were not feasible, you get a lot of popular support, but that doesn't mean it's good

[04:36:07.0000] <darobin>
sure, but those are two completely different metrics

[04:36:18.0000] <darobin>
it is useful to know that people like the use cases you liberate

[04:36:41.0000] <darobin>
that's an entirely different data point from the fact that people have thought it through

[05:27:18.0000] <annevk>
Apparently there's still promise-skeptics

[05:28:08.0000] <annevk>
I sort of that thought that after the async/await syntax was unveiled all debate would be over

[05:28:22.0000] <annevk>
So naïve

[05:28:41.0000] <caitp>
you people the people who aren't happy with the performance of the implementations in spidermonkey/v8?

[05:28:42.0000] <odinho>
*g*

[05:28:47.0000] <caitp>
or some other kind of skepticism

[05:30:30.0000] <annevk>
Not sure

[05:31:52.0000] <caitp>
it's mostly, as far as I can tell, the node.js people who are upset with the performance of native promises and prefer something like bluebird or just callbacks, awful as they are

[05:32:03.0000] <caitp>
but maybe there's more to it :>

[05:33:20.0000] <darobin>
annevk: you should know by now that for any proposal, there will in perpetuity be some skeptics — it's sort of its own Rule 34

[05:34:06.0000] <caitp>
but less enticing

[05:34:33.0000] <darobin>
caitp: for some people, I have my doubts that they're not more enticed

[05:35:47.0000] <caitp>
well, at least it's constructive, if you squint really hard

[05:36:51.0000] <darobin>
I try not to squint too hard anywhere in the vicinity of Rule 34, even if a variant

[05:41:08.0000] <caitp>
obscures the view too much?

[05:53:50.0000] <darobin>
well played caitp, well played

[07:12:04.0000] <annevk>
Domenic: not sure what you're talking about

[07:12:10.0000] <annevk>
Domenic: what properties are there for network errors?

[07:12:39.0000] <Domenic>
annevk: I haven't looked into it hard yet; will do so. But e.g. how many places in the spec cause network errors? A property could distinguish those.

[07:12:49.0000] <annevk>
Domenic: no we don't distinguish network errors

[07:13:14.0000] <Domenic>
annevk: so for example it would be *very* useful for the dev to know that they were blocked by CSP

[07:13:28.0000] <annevk>
Domenic: I don't think we want to reveal that

[07:13:32.0000] <Domenic>
:-/

[07:13:35.0000] <annevk>
Domenic: you can use CSP's error reporting feature though

[07:13:44.0000] <Domenic>
i think people will end up filtering on error strings in that case

[07:14:12.0000] <Domenic>
or mixed content...

[07:14:26.0000] <Domenic>
or cors...

[07:14:38.0000] <Domenic>
or too many redirects

[07:17:25.0000] <annevk>
Domenic: we don't expose those errors now anywhere, I'm not sure why fetch() would be any different

[07:17:46.0000] <Domenic>
because it's supposed to be better than XHR?

[07:18:48.0000] <annevk>
I'm not sure we want to reveal more sensitive information

[07:24:26.0000] <annevk>
Domenic: but if you get that past security guys, we could make network error more granular I guess

[07:27:52.0000] <annevk>
Domenic: it's better, but no less secure

[08:13:36.0000] <annevk>
JakeA: your fetch example gets even better with the new small functions

[08:14:28.0000] <JakeA>
annevk: arrow functions?

[08:14:48.0000] <annevk>
JakeA: fetch(url).then((response) => response.body.to("json")).then((json) => /* yey! */ )

[08:14:57.0000] <Domenic>
(and the parens aren't even needed)

[08:15:19.0000] <annevk>
JakeA: fetch(url).then(response => response.body.to("json")).then(json => /* yey! */ )

[08:15:26.0000] <JakeA>
\o/

[08:15:45.0000] <annevk>
and then you shorten response to r, etc. :-)

[08:15:56.0000] <JakeA>
I wonder when Chrome's planning to ship arrow functions…

[08:17:10.0000] <annevk>
prolly before async/await

[08:17:38.0000] <Domenic>
arrow functions are in progress by one of the igalia guys

[08:18:12.0000] <caitp>
the status of that isnt actually recorded on the launchbug, iirc

[08:18:15.0000] <Domenic>
i believe it's his first v8 contribution though so it's taking a bit of time

[08:18:52.0000] <annevk>
JakeA: I closed a bunch of SW issues btw

[08:19:17.0000] <annevk>
JakeA: maybe we should organize a virtual meeting day where we go through all the things again here on #whatwg

[08:19:52.0000] <JakeA>
annevk: I saw, cheers! I'm on I/O lockdown for the next few days, although it means there'll be a session on serviceworker (and a video)

[08:20:06.0000] <annevk>
also JakeA, you ruined my "Notifications" tab on Twitter

[08:20:18.0000] <JakeA>
haha, people like fetch

[08:20:35.0000] <JakeA>
annevk: Yeah, those meeting were really productive, if they're even half as productive via IRC they're worth doing

[08:20:36.0000] <annevk>
JakeA: heh, I saw you guys are going to announce <meta name=brand-color>

[08:20:45.0000] <annevk>
JakeA: major spoilers on blink-dev

[08:21:18.0000] <JakeA>
annevk: yey more meta tags

[08:21:29.0000] <annevk>
JakeA: is yey British yay?

[08:22:03.0000] <JakeA>
annevk: hmm, maybe, or maybe I've just been spelling it wrong all my life

[08:22:09.0000] <annevk>
http://www.urbandictionary.com/define.php?term=yey

[08:23:08.0000] <JakeA>
*every* letter combination < 8 chars means drugs/blowjobs on urban dictionary

[08:25:44.0000] <caitp>
what else are you going to use cant for?

[08:26:57.0000] <annevk>
Domenic: are you keeping track somewhere of concept operations on a stream?

[08:27:44.0000] <annevk>
Domenic: if you copy an object that holds onto a stream, you want to tee the stream, no?

[08:27:49.0000] <Domenic>
annevk: not yet

[08:28:06.0000] <Domenic>
annevk: I am not sure but probably.

[08:28:30.0000] <Domenic>
annevk: where is your structured clone repo? i wanna solve promises there and then move on to streams

[08:28:50.0000] <annevk>
Domenic: https://github.com/dslomov-chromium/ecmascript-structured-clone

[08:29:33.0000] <annevk>
Domenic: ask dslomov for edit rights

[08:29:53.0000] <Domenic>
annevk: meh just wanna figure out strategy in the issue tracker first

[08:30:13.0000] <annevk>
Domenic: https://github.com/dslomov-chromium/ecmascript-structured-clone/issues/5

[08:31:38.0000] <annevk>
Domenic: I'll add <!-- XXX streams --> markers in the Fetch source code so we can look through this stuff later

[08:32:24.0000] <annevk>
Domenic: we are getting very close to the point where we are going to make an attempt to implement Request/Response and FetchBodyStream et al btw

[08:32:58.0000] <Domenic>
annevk: yep, I'm full speed on streams now, as I want to be not-too-far-behind

[08:33:05.0000] <JakeA>
Would be great if node.append() could take a stream & progressively parse

[08:33:35.0000] <Domenic>
just wanna prioritize things that might affect fetch etc. first, so that's why i think the cloning/transferring is top priority

[08:33:51.0000] <annevk>
JakeA: I think that should work the other way around

[08:34:32.0000] <JakeA>
annevk: as in pipe a stream to an element?

[08:34:58.0000] <annevk>
JakeA: have a convenience method on an iterable that invokes node.append() with the next iterable as soon as it is there

[08:35:07.0000] <annevk>
JakeA: we'll have things like that on promises too

[08:35:25.0000] <annevk>
JakeA: otherwise you put all the complexity in node.append() and methods all over the place, where that isn't really justified

[08:37:40.0000] <annevk>
promise.callWithValue(node.append) or some such

[08:38:20.0000] <JakeA>
hmm, I was looking for something that'd hook into the html parser that's used to load the page, since we don't expose that to js at the moment.

[08:39:00.0000] <JakeA>
As in, you can't provide "<p>hello " and " world</p>" as seperate chunks at the moment

[08:39:14.0000] <JakeA>
separate*

[08:39:48.0000] <JakeA>
but the browser handles it fine during page load

[08:40:59.0000] <annevk>
That's called document.write()

[08:42:41.0000] <JakeA>
true

[08:44:10.0000] <JakeA>
element.write() would do it

[08:44:38.0000] <annevk>
Domenic: are you cautiously planning promises v2? Lots of https://github.com/kriskowal/q/wiki/API-Reference seems ready for inclusion

[08:45:05.0000] <JakeA>
The case I'm thinking of is fetch('some-largish-content.html').then(streamDataToElement)

[08:47:17.0000] <Domenic>
annevk: maybe, although async/await removes a lot of the need.

[08:47:34.0000] <Domenic>
annevk: .finally is my only high-priority thing

[08:47:47.0000] <annevk>
Domenic: how would you rewrite get for instance?

[08:48:01.0000] <Domenic>
annevk: and also maybe a version of .allSettled, or .any

[08:48:07.0000] <Domenic>
annevk: (await promise).property

[08:48:10.0000] <annevk>
var method = (async fetch(url)).method

[08:48:20.0000] <annevk>
oh await, doh

[08:48:25.0000] <annevk>
yeah nice

[09:12:47.0000] <annevk>
Domenic: should I ping es-discuss with https://github.com/dslomov-chromium/ecmascript-structured-clone/issues/6 or will you?

[09:16:18.0000] <Domenic>
annevk: I'll do it. I wonder how well it will go over to say "discuss this over on that other forum, not on this mailing list" :P

[09:17:04.0000] <annevk>
Domenic: well they are typically ignoring anything structured clone so I expect not too much trouble

[09:21:15.0000] <caitp>
what about #jslang? they seem to have time to talk about things

[09:55:53.0000] <Hixie>
jgraham: oh there will be patches

[09:56:07.0000] <Hixie>
jgraham: just as soon as i figure out how the heck to push a pull request

[09:56:19.0000] <Hixie>
or whatever is the terminology you kids use these days

[09:56:23.0000] <Hixie>
:-P

[09:57:50.0000] <jgraham>
You're not *that* much older than me

[09:57:56.0000] <jgraham>
I'm not gsnedders :p

[09:58:30.0000] <Hixie>
:-P

[10:00:52.0000] <Hixie>
i even have a few extra tests

[10:04:10.0000] <annevk>
HTML parser talk is one of my favorite pastimes

[10:04:20.0000] <annevk>
(context: es-discuss)

[10:05:41.0000] <Hixie>
how is <module> still not dead

[10:06:16.0000] <caitp>
what exactly was <module> supposed to be? i've been researching it a bit and haven't really had that cleared up

[10:06:39.0000] <Hixie>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868

[10:06:43.0000] <caitp>
because I think there are potential plans for our product to make use of it, and i want to make sure those plans disappear if they're terrible ideas

[10:07:31.0000] <Hixie>
just use <script type=module>

[10:07:45.0000] <Hixie>
which isn't valid yet but almost certainly will be

[10:07:54.0000] <Hixie>
though i dunno how we're going to fix the problem of non-js modules

[10:08:11.0000] <Hixie>
holy cow, i finally hit a test that checks <noscript>

[10:08:18.0000] <Hixie>
i was wondering if that'd ever come up

[10:08:41.0000] <caitp>
i'm not sure if it's still in the cards, but for the next iteration of angular, initially we were doing this weird thing involving es6 modules + html imports, somehow coupled together, I can't recall how that hack worked

[10:09:07.0000] <caitp>
but iirc the module tag was involved somewhere in there

[10:09:15.0000] <caitp>
or at least a fake version of it

[10:14:20.0000] <Hixie>
uh

[10:14:22.0000] <Hixie>
interesting

[10:14:28.0000] <Hixie>
html5lib tests assume that you parse scripts

[10:19:43.0000] <jgraham>
Yeah

[10:20:46.0000] <Hixie>
/me introduces a new #script-off directive for tests

[10:24:43.0000] <annevk>
JakeA: to get back to your streaming thing, it seems like you want a streaming HTML parser in JavaScript

[10:25:13.0000] <annevk>
JakeA: however, HTML cannot be streamed at the moment, so we might have to "fork" the parser (by adding a mode) to make such a thing actually feasible

[10:25:29.0000] <annevk>
JakeA: as for why it cannot be streamed, check out <table><x></table>

[10:28:29.0000] <Hixie>
it can be streamed, just not in a naive way like xml or json

[10:29:51.0000] <annevk>
Hixie: it would be kind of nice to provide naive HTML streaming at some point

[10:30:04.0000] <Hixie>
in what contexgt?

[10:30:30.0000] <annevk>
Hixie: Jake's example was loading some data over the network and incrementally streaming the data into the page

[10:30:43.0000] <Hixie>
like, XHR -> innerHTML

[10:30:45.0000] <Hixie>
?

[10:30:49.0000] <annevk>
Hixie: yes

[10:31:07.0000] <Hixie>
we could provide that

[10:31:24.0000] <Hixie>
just have XHR have a method like "xhr.sendOutputTo(element)"

[10:31:41.0000] <caitp>
xhr.pipe(node)

[10:31:41.0000] <Hixie>
but i don't know if we want to be encouraging treating HTML in that way

[10:31:59.0000] <Hixie>
better to stream the data in an app-internal format, then create the HTML on the client

[10:32:18.0000] <annevk>
JakeA: ^

[10:32:32.0000] <annevk>
I don't really like the sendOutputTo()

[10:32:43.0000] <annevk>
It seems like you want to provide the underlying primitive so people can build their own setups

[10:33:11.0000] <annevk>
Anyway, probably not high-priority, but worth thinking about

[10:33:38.0000] <Hixie>
the underlying primitive is "insertAdjacentHTML"

[10:34:04.0000] <Hixie>
though i guess you need to handle mid-token streaming

[10:34:13.0000] <Hixie>
so you need to keep the parser alive somehow

[10:34:28.0000] <Hixie>
yeah that could get complicated

[10:34:33.0000] <Hixie>
anyway the solution is to not stream HTML, imho

[10:35:22.0000] <caitp>
can you actually stream JSON, currently? because you could see that as being pretty useful

[10:35:42.0000] <Hixie>
you can certainly write a streaming parser

[10:36:00.0000] <caitp>
but do progress events actually give you chunks of data?

[10:36:21.0000] <annevk>
Hixie: structured cloning of promises is happening btw: https://github.com/dslomov-chromium/ecmascript-structured-clone/issues/6

[10:36:34.0000] <annevk>
Hixie: hopefully you don't have to define it in HTML, but I thought I'd let you know

[10:37:13.0000] <Hixie>
thanks

[10:37:25.0000] <Hixie>
wow, that's ambititous

[10:37:29.0000] <Hixie>
cloning without neutering

[10:37:41.0000] <Hixie>
ambitious, even

[10:38:19.0000] <Ms2ger>
http://www.w3.org/XML/2014/03/xproc-charter.html

[10:47:13.0000] <Hixie>
wtf is "XXX-undefined-error"

[10:49:39.0000] <Hixie>
i've reached the point where i'm finding more bugs in the tests than in my implementation

[10:49:43.0000] <Hixie>
that's a good sign

[10:51:03.0000] <jgraham>
https://github.com/html5lib/html5lib-python/search?q=XXX-undefined-error&ref=cmdform

[10:51:24.0000] <Hixie>
ah

[10:51:34.0000] <Hixie>
well it seems in this case it was a bogus error

[10:51:44.0000] <Hixie>
as was a later one "unknown-doctype element"

[10:52:33.0000] <Hixie>
finally hit a test of the  Script data double escape start state

[10:53:37.0000] <jgraham>
Yeah, the later script states aren't so well tested

[10:53:48.0000] <jgraham>
later additions I mean

[10:54:00.0000] <Hixie>
well the order i'm doing the tests in is pretty random

[10:54:03.0000] <jgraham>
Since they postdate Philip` generating a whole load of tests

[10:54:09.0000] <Hixie>
i mean, i did tricky01.dat before tests1.dat

[10:54:26.0000] <Hixie>
tricky01, btw, was by far the most tricky to fix so far!

[10:54:52.0000] <Hixie>
it found bugs in my dom implementation, in my test logic, in the AAA, everything

[10:56:46.0000] <jgraham>
I think those tests were mainly from abarth

[10:58:48.0000] <abarth>
yay for tricky01.dat!

[11:04:03.0000] <Hixie>
damnit, there's a bug SOMEWHERE in the script states

[11:04:08.0000] <Hixie>
how the heck am i supposed to find that

[11:05:29.0000] <Ms2ger>
Rewrite it all

[11:06:11.0000] <jgraham>
ERROR http://localhost:8000/resources/testharness.js:1840 - TypeError: location is null

[11:06:14.0000] <jgraham>
Uh

[11:06:17.0000] <jgraham>
That's not good

[11:07:17.0000] <Ms2ger>
Servo? ;)

[11:07:32.0000] <Ms2ger>
I think I saw you mention that before

[11:07:35.0000] <JakeA>
annevk: Hixie: I imagine a page loads by streaming html text to a parser which creates nodes and updates them as the stream is read. Curious about opening that up to developers by piping an html stream into an element

[11:08:12.0000] <Hixie>
JakeA: the problem is that the parser works on a Document

[11:08:21.0000] <jgraham>
Ms2ger: Gecko :(

[11:08:21.0000] <Hixie>
JakeA: whereas innerHTML is on an element

[11:08:52.0000] <Hixie>
JakeA: what you could do is load the page in an iframe, then put all the content in a <div>, and as soon as that is parsed, move the <div> into wherever you want hte content streamed

[11:09:05.0000] <Hixie>
JakeA: but honestly, the solution is to generate the html client-side

[11:10:44.0000] <JakeA>
Hixie: wouldn't streaming html into a fragment be very similar to the initial page load?

[11:11:09.0000] <Hixie>
the HTML parser parses into a Document

[11:11:29.0000] <Hixie>
innerHTML does all the parsing into a Document, then moves it into the element all at once

[11:12:21.0000] <JakeA>
Hixie: is that how it's implemented or just how it's specced

[11:13:00.0000] <Hixie>
both

[11:13:03.0000] <Hixie>
as far as i know

[11:13:46.0000] <JakeA>
Fair enough

[11:23:22.0000] <Hixie>
woah, i found one of these tests that had a bogus output

[11:23:47.0000] <Hixie>
how did that not get caught by all the browsers using these tests

[11:24:02.0000] <Hixie>
oh

[11:24:05.0000] <Hixie>
/me hides head in shame

[11:24:09.0000] <Hixie>
(it was in one of my new tests)

[11:24:16.0000] <Ms2ger>
Silly

[11:26:07.0000] <Hixie>
oh hey

[11:26:13.0000] <Hixie>
i hadn't implemented in-template yet

[12:27:54.0000] <Hixie>
<table><template><td></template></table> - currently this is a parse error because "Generate Implied End Tags" doesn't do table-related (e.g. </td>) tags

[12:28:06.0000] <Hixie>
should i have </template> "Generate implied end tags harder" so this is not a parse error?

[12:28:56.0000] <caitp>
yes

[12:29:12.0000] <caitp>
lets make the parser do even more stuff that the author didn't explicitly ask it to do

[12:30:01.0000] <TabAtkins>
Sarcasm: less helpful than you'd think. What a surprise.

[12:30:42.0000] <caitp>
was it sarcasm?

[12:35:14.0000] <TabAtkins>
Based on what I remember of your opinions, you telling Hixie to "make the parser do even mroe stuff that the author didn't explicitly ask it to do" does sound like a serious response.  Pretty sure you meant the exact opposite, which makes it sarcastic.

[12:35:46.0000] <caitp>
you caught me :(

[12:38:06.0000] <caitp>
I am not sure how to be helpful with discussions like that, other than to try and nudge things in the right direction. unless you think sarcasm might nudge it in the wrong direction, that would be less helpful

[12:38:41.0000] <TabAtkins>
It would be better to just be direct. "No, I don't think the parser should do even more stuff the author didn't explicitly ask it to do"

[12:39:42.0000] <caitp>
being direct is kind of like, there's a phrase for it but it's kind of inappropriate

[12:39:55.0000] <caitp>
it's not very colourful, there's no vibrancy or life to it

[12:39:58.0000] <TabAtkins>
??? That's just a direct answer to the question.

[12:39:59.0000] <caitp>
not as fun =)

[12:40:23.0000] <TabAtkins>
Point isn't to have fun, it's to have a technical discussion. You can be as sarcastic and fun as you like during the non-technical conversations that go on. ^_^

[12:43:09.0000] <annevk>
JakeA: I've decided I'm not going to reply to all questions asked on Twitter, just the trickier ones

[12:44:25.0000] <annevk>
Favorite answer I gave so far has to be https://twitter.com/annevk/status/477535987783192576

[12:47:32.0000] <JakeA>
annevk: hah, yes

[13:18:15.0000] <Hixie>
no opinions on the </td> thing?

[13:18:41.0000] <Hixie>
(note that i'm not talking about changing what the parser does, so caitp's comment kinda misses the point)

[13:18:47.0000] <Hixie>
(i'm just talking about what's a parse error)

[13:20:01.0000] <annevk>
Hixie: I don't understand why that shouldn't be a parse error

[13:20:12.0000] <caitp>
you were saying "should we generate end tags, or should we call it an error"

[13:20:15.0000] <Hixie>
annevk: because </td> is optional

[13:20:31.0000] <Hixie>
caitp: "generate end tags" is a term of art that doesn't affect the parsing

[13:20:35.0000] <Hixie>
caitp: it only affects whether it's an error

[13:20:45.0000] <caitp>
it affects the behaviour

[13:20:49.0000] <annevk>
Hixie: so is <template><dt></template> an error?

[13:20:53.0000] <Hixie>
caitp: if you're going to be so critical, it would help if you would at least learn about what you're criticising

[13:20:56.0000] <Hixie>
annevk: no

[13:21:10.0000] <Hixie>
annevk: that's why i'm suggesting we change it

[13:21:13.0000] <jcgregorio>
I'd be surprised if that was a parse error

[13:21:15.0000] <annevk>
Hixie: sounds good to me

[13:21:18.0000] <Hixie>
k

[13:21:21.0000] <caitp>
I don't think anything you've said invalidates what I'm saying --- error throwing or not throwing is behaviour

[13:21:34.0000] <annevk>
caitp: there's no throwing

[13:21:39.0000] <Hixie>
caitp: the DOM is the same either way

[13:21:41.0000] <caitp>
that's not the point, really

[13:21:52.0000] <caitp>
when I say throw, I'm not always talking about a JS context

[13:22:08.0000] <annevk>
caitp: can we just talk about this in terms of the HTML parser then?

[13:22:20.0000] <annevk>
caitp: arbitrary terms are confusing for everyone

[13:22:44.0000] <annevk>
Domenic: IDL for Headers initialization: http://logs.glob.uno/?c=mozilla%23content&s=13+Jun+2014&e=13+Jun+2014#c218158

[13:23:10.0000] <caitp>
in terms of the HTML parser, you're saying "should we do the crazy work necessary to hide the error in a way which doesn't really reflect what the author wrote, OR should we consider it an error (this does not mean an Exception)"

[13:23:43.0000] <caitp>
anyways, I would opt for the latter, preferably with a message for developers

[13:24:12.0000] <annevk>
caitp: what are you talking about? It does reflect what the author wrote. Many end tags are optional in HTML

[13:24:39.0000] <caitp>
which is one of the problems with HTML, not one of the solutions --- why should the template tag hang onto old badness?

[13:25:20.0000] <annevk>
caitp: if you don't like the format, use XML, but changing it's inherent consistency is just creating more badness imo

[13:26:18.0000] <caitp>
I don't think those optional tags are widely used anyways, I mean yeah the plural of anecdote is not data, but I read a lot of peoples code, and I've yet to see anything like that in use

[13:26:20.0000] <Domenic>
annevk: seems ok. not sure i have much to contribute.

[13:26:49.0000] <Hixie>
caitp: we're not doing any different work. We're going to be closing these tags anyway (we already do). The question is just, should we report missing end tags in this one specific situation as an error or not, given that they are optional elsewhere, and that we don't report an error even here for some other elements with optional end tags.

[13:26:53.0000] <caitp>
and besides, if new HTML features start getting rid of old badness, maybe eventually, the old badness can be discarded entirely

[13:27:11.0000] <Hixie>
implied end tags are used all _over_ the place

[13:27:28.0000] <Hixie>
especially the table ones, which is what we're talking about

[13:27:37.0000] <annevk>
Domenic: great

[13:27:37.0000] <caitp>
i'm sure they are, but how many of them are used in template contexts

[13:27:40.0000] <Hixie>
however, everything here is about <template> contexts, which are used almost nowhere.

[13:27:50.0000] <caitp>
exactly

[13:28:08.0000] <annevk>
I use optional end tags all the time

[13:28:26.0000] <annevk>
Whenever I have to write a <table> it's such a blessing

[13:28:35.0000] <annevk>
Or <li> with nested <p> for that matter

[13:28:41.0000] <Philip`>
/me wonders if "use" means "include" or "omit"

[13:28:52.0000] <TabAtkins>
Using the optionality aspect.

[13:28:57.0000] <TabAtkins>
So, "omit".

[13:30:33.0000] <caitp>
I dunno, I'm aware of those optional end tags and I literally never use them, because there's no way to logically consider stuff using those a well-formed consistent document

[13:30:46.0000] <TabAtkins>
...okay.

[13:30:58.0000] <TabAtkins>
That's nonsense, but sure, whatever.

[13:31:31.0000] <caitp>
it's not nonsense --- for a language to be simple, it must be consistent

[13:31:38.0000] <caitp>
this is why people suck at english, it's not consistent at all

[13:31:53.0000] <TabAtkins>
You didn't say "simple". You said "well-formed consistent".

[13:32:15.0000] <TabAtkins>
And a markup language that defines a tree structure with implied end tags is plenty "well-formed consistent".

[13:32:17.0000] <caitp>
a markup language "should" be simple

[13:32:31.0000] <caitp>
the structure "should" be easy to reason about

[13:32:51.0000] <TabAtkins>
...are you trying to talk about the AAA and table fixup?

[13:33:03.0000] <TabAtkins>
Because that's not at all relevant to what's been under discussion today.

[13:33:24.0000] <caitp>
hixie puts two things foreward, I favour one over the other

[13:33:38.0000] <caitp>
that is relevant, and not at all invalidated by intentionally misunderstanding things =)

[13:34:04.0000] <Hixie>
optional end tags do not in any way reduce the precision of the language or ability to reason about it

[13:34:13.0000] <Hixie>
their rules are simple, and well-defined

[13:34:33.0000] <caitp>
they're not actually

[13:34:36.0000] <TabAtkins>
Well, I wouldn't call <p> auto-closing "simple", but they're at least well-defined.

[13:34:39.0000] <TabAtkins>
The rest, yeah.

[13:34:42.0000] <caitp>
they're easy for _you_, they're less easy for _other_ people

[13:35:01.0000] <TabAtkins>
<li>, <dt>, <tr>, all those auto-closing rules are super simple.

[13:35:14.0000] <caitp>
boe can't even name all 3 of those elements

[13:35:18.0000] <caitp>
let alone all of the other ones with similar rules

[13:35:24.0000] <TabAtkins>
"boe"?

[13:35:29.0000] <caitp>
are you going to tell me that Boe can't be an HTML author because he can't reason about all this nonsense?

[13:35:30.0000] <Hixie>
<p> auto-closing is simple. The <p> closes when it comes across something that isn't allowed in the <p>.

[13:35:45.0000] <TabAtkins>
Hixie: The list of "things that aren't allowed in <p>" isn't trivial.

[13:35:55.0000] <caitp>
the fact that "things aren't allowed in a <p>" exists at all

[13:35:56.0000] <caitp>
is totally bogus

[13:36:05.0000] <Hixie>
TabAtkins: sure, it's the same list that someone needs to know to use HTML whether or not </p> is implied.

[13:36:11.0000] <TabAtkins>
caitp: Are you saying that Boe literally doesn't know what the <li> element is?

[13:36:22.0000] <TabAtkins>
Hixie: ???

[13:36:42.0000] <caitp>
Boe probably can't name <tt> or <em> or know the difference between <ol> or <ul>

[13:36:48.0000] <caitp>
Boe doesn't know what <tbody> means

[13:36:50.0000] <TabAtkins>
Who is this Boe?

[13:36:55.0000] <Hixie>
TabAtkins: if you don't know that <h1> isn't allowed in <p>, then you have bigger problems than not knowing that </p> will get implied if you put <h1> in <p>

[13:37:00.0000] <caitp>
Boe is a hypothetical author who is new to this language

[13:37:05.0000] <TabAtkins>
Hixie: <figure>, yay nay?

[13:37:08.0000] <SamB>
caitp: how about <p>

[13:37:13.0000] <Hixie>
TabAtkins: yay nay what?

[13:37:16.0000] <SamB>
I don't figure that should be allowed (directly) in <p>

[13:37:22.0000] <SamB>
it doesn't make any sense

[13:37:26.0000] <TabAtkins>
caitp: Sounds like Boe hasn't completed the first part of their "Learn you an HTML for great justice" course.

[13:37:32.0000] <caitp>
semantically it doesn't make much sense, sure

[13:37:34.0000] <TabAtkins>
Hixie: On the allowed list, or not?

[13:37:47.0000] <caitp>
as far as layout goes it doesn't make much sense

[13:37:49.0000] <Hixie>
TabAtkins: a paragraph cannot contain a figure, no

[13:37:59.0000] <caitp>
but even so, there's no reason why the language shouldn't allow for it

[13:38:03.0000] <TabAtkins>
That's non-obvious to me.

[13:38:06.0000] <caitp>
and no reason why the language should re-arrange it

[13:38:17.0000] <TabAtkins>
Thus my statement that "the list of things not allowed in <p> is non-obvious".

[13:38:21.0000] <Hixie>
TabAtkins: i am happy to concede that

[13:38:33.0000] <Hixie>
TabAtkins: my point is just that that is a bigger problem than </p> implied end tags

[13:38:43.0000] <Hixie>
TabAtkins: and once you've solved that problem, you've solved the implied end tag problem also

[13:38:44.0000] <TabAtkins>
Well, it's the same problem, no?

[13:38:51.0000] <Hixie>
you need the same information, yes

[13:38:51.0000] <caitp>
the fact that we re-arrange these things is because mistakes were made and now nobody wants to fix them for fear of upsetting people

[13:38:58.0000] <TabAtkins>
The content model of <p> is non-obvious, is what I"m saying. ^_^

[13:39:25.0000] <TabAtkins>
caitp: We know that you don't understand what the words "legacy compat" mean. You don't need to keep reinforcing that.

[13:39:25.0000] <Hixie>
caitp: we've given you several ideas for how you can try to address this problem, repeatedly whining here isn't productive to your goals

[13:39:33.0000] <caitp>
and if every new feature to the platform has to accommodate those old mistakes, then HTML is fundamentally and permanently broken

[13:39:51.0000] <TabAtkins>
They do, and it is, and yet we persist.

[13:39:51.0000] <Hixie>
TabAtkins: lots of HTML is non-obvious, unfortunately, yeah :-(

[13:40:08.0000] <Hixie>
caitp: i am happy to concede that HTML is fundamentally and permanently broken

[13:40:10.0000] <TabAtkins>
Hixie: Not challenging that.  Just saying, that particular thing is non-obvious, where you said it was simple. ^_^

[13:40:13.0000] <Hixie>
caitp: also, wildly successful

[13:40:20.0000] <caitp>
no, I know what legacy compat means and I understand it Tab, what I don't understand is the strong desire to keep it that way, even for new things

[13:40:34.0000] <Hixie>
TabAtkins: i said the auto-closing rule is simple

[13:40:37.0000] <caitp>
new things shouldn't be held back by old brokenness

[13:40:38.0000] <TabAtkins>
If you don't understand why legacy compat is important, then you don't understand "legacy compat".

[13:40:42.0000] <caitp>
even if it makes things inconsistent, so what

[13:40:45.0000] <TabAtkins>
Hixie: Only by referencing complicated things!

[13:40:47.0000] <Hixie>
TabAtkins: that it relies on less simple stuff, is a secondary issue :-)

[13:40:55.0000] <caitp>
new stuff should use a simpler, less whacky model

[13:41:10.0000] <caitp>
that's my opinion, you're welcome to disagree and I suspect you do

[13:41:13.0000] <TabAtkins>
I don't need full transitive closure on "simplicity", but at least a few hops. ^_^

[13:41:17.0000] <Hixie>
TabAtkins: all of this stuff eventually relies on electronics and microelectronics and i don't understand any of that, but it doesn't mean the higher layers aren't simple :-)

[13:41:21.0000] <Hixie>
hehe

[13:41:49.0000] <caitp>
TabAtkins, I understand why it's important to people who find it important

[13:42:01.0000] <Hixie>
caitp: new stuff should use as simple and as less wacky a model as it can while still standing a chance of being deployed

[13:42:15.0000] <caitp>
I don't believe that NEW things, which don't exist as far as legacy clients are considered, should have to accomodate those old rules

[13:42:17.0000] <TabAtkins>
The people who find it important are the users who look at the trillion existing pages, and the browser vendors serving those users.

[13:42:25.0000] <Hixie>
caitp: but there's no point us doing something that doesn't stand a chance of getting deployed

[13:42:34.0000] <TabAtkins>
Spec authors bemoaning complexity are nothing compared to them.

[13:42:36.0000] <caitp>
what makes you think it wouldn't be deployed

[13:42:41.0000] <caitp>
authors literally don't care

[13:42:49.0000] <Hixie>
(i'm an author and i care)

[13:43:06.0000] <Hixie>
caitp: browser vendors have told me they would not deploy breaking changes

[13:43:24.0000] <caitp>
you care about the sloppy version of table content breaking <template> tags when oyu can easily type the other 4 characters to make it work?

[13:44:02.0000] <caitp>
it's not a breaking change, legacy browsers aren't going to fall apart because the html parser treats <template> content differently

[13:44:18.0000] <Hixie>
it's not sloppy

[13:44:23.0000] <caitp>
it is sloppy

[13:44:26.0000] <Hixie>
it's not sloppy

[13:44:41.0000] <Hixie>
it's well-defined and unambiguous

[13:44:51.0000] <caitp>
it's the act of being unwilling to explicitly specify the end of the nodes content

[13:44:56.0000] <caitp>
this is sloppy in and of itself

[13:45:15.0000] <Hixie>
and we're not talking about treating <template> content differently; as mentioned before, this entire discussion involves zero changes to the DOM. We're only talking about how many errors are reported.

[13:45:20.0000] <Hixie>
wtf

[13:45:28.0000] <Hixie>
are "// foo" comments sloppy?

[13:45:47.0000] <caitp>
I don't think you can compare a programming language to a markup language

[13:46:10.0000] <caitp>
they serve different purposes and different authors

[13:47:04.0000] <caitp>
I think you'd have a problem if say, scope in a language which didn't care about indentation could have an optional "end" marker

[13:47:04.0000] <TabAtkins>
Hah, I specify the end of my <li> *by putting another <li> in* (or a </ul>, etc).

[13:47:09.0000] <Hixie>
are csv files sloppy?

[13:47:13.0000] <TabAtkins>
That's not sloppy, that's just omitting unnecessary crap.

[13:47:24.0000] <caitp>
yes, arguably CSV files are sloppy, is that a real question?

[13:47:33.0000] <SamB>
TabAtkins: yeah, that's why I mentioned <p> in <p>

[13:48:23.0000] <TabAtkins>
SamB: Yeah, that part of the rules is easy; it's all the other things that auto-close <p>.

[13:48:31.0000] <TabAtkins>
<div> implies a </p>, etc.

[13:48:35.0000] <Hixie>
ok, if you consider CSV files "sloppy" then by that definition HTML is "sloppy". But by that definition, "sloppy" is also "good", so I'm fine with it.

[13:48:38.0000] <caitp>
> make language needlessly more complicated

[13:48:54.0000] <caitp>
> features that most people never use

[13:49:10.0000] <SamB>
Hixie: CSV is loads worse

[13:49:29.0000] <SamB>
there's no HTML<del>5</del> spec/WHATWG of CSV

[13:49:57.0000] <caitp>
there's no spec of CSV period, it's pretty vendor-specific

[13:50:15.0000] <Hixie>
caitp: it's not "needless", it makes the language easier to author and more compatible with legacy UAs and content. It's not features that most people never use, tag omission is extremely widely used.

[13:50:20.0000] <TabAtkins>
I mean, there's http://tools.ietf.org/html/rfc4180

[13:50:24.0000] <SamB>
CSV is like maildir^N

[13:50:29.0000] <caitp>
it means typing fewer characters, this does not make it easier to author

[13:50:42.0000] <TabAtkins>
I used that when writing my CSV parser.

[13:50:45.0000] <caitp>
it makes it harder to read and write, because this is a markup language where we have start tags and end tags denoting when content starts and ends

[13:50:59.0000] <SamB>
I mean rfc822-style has more damn meaning than CSV has

[13:51:01.0000] <caitp>
then some markers are optional sometimes

[13:51:04.0000] <caitp>
this is weird and confusing

[13:51:13.0000] <caitp>
and then, parsers have to rearrange stuff sometimes

[13:51:16.0000] <caitp>
this is weird and confusing

[13:51:16.0000] <Hixie>
<table> <tr> <td> A <td> B <tr> <td> C <td> D </table> is a hell of a lot easier to maintain than <table> <tbody> <tr> <td> A </td> <td> B </td> </tr> <tr> <td> C </td> <td> D </td> </tr> </tbody> </table>

[13:51:19.0000] <caitp>
it's profoundly broken

[13:51:25.0000] <caitp>
there is nothing good about any of this

[13:51:34.0000] <Hixie>
anyway

[13:51:35.0000] <SamB>
(you just have to pick between actual mail/news format and deb822, based on the context)

[13:51:39.0000] <Hixie>
you're ignoring our arguments, so i'm done here

[13:51:39.0000] <TabAtkins>
Complaining about the rearranging is very different from complaining about omitted end tags.

[13:51:48.0000] <caitp>
i'm not ignoring your argument

[13:51:55.0000] <SamB>
caitp: yeah, there's lots of legacy crap :-(

[13:53:04.0000] <Hixie>
caitp: you're repeating arguments that have been countered, without taking into account the countering arguments, so, yeah.

[13:53:17.0000] <caitp>
they haven't been countered

[13:53:38.0000] <SamB>
I can't think of anything besides <h[1-n]> | <hr> w/ <p> on the TOS (normal notation) and </[something-higher-up-the-stack]> that should actually force a </p>

[13:53:51.0000] <caitp>
you haven't shown me how someone would consider your whacky markup "simple" or "useful" and not "confusing"

[13:54:04.0000] <SamB>
or, well, I guess with only inliney stuff on the stack

[13:54:28.0000] <SamB>
not, say, in a mid-paragraph <article>

[13:55:52.0000] <TabAtkins>
caitp: Besides several people literally saying "I find it simple, useful, and not confusing"?

[13:56:11.0000] <SamB>
otherwise, you start needing ways to mark paragraphs as "wait no this paragraph isn't actually interrupted by that display formula/example code/etc.", no?

[13:56:37.0000] <SamB>
what was "it" again?

[13:56:39.0000] <caitp>
look, it's not that I don't respect Ian or his opinion, but I think his opinion on the simplicity of HTML might not be as useful as he thinks, since he's so close to it

[13:57:08.0000] <caitp>
you have to look at the 12 year old kids, the college and highschool students, the secretaries, the soccer moms

[13:57:12.0000] <TabAtkins>
I just treat some part of HTML as similar to Python (I use indentation in my HTML in the same way) or like a streaming format where you only indicate boundaries.

[13:57:12.0000] <caitp>
their opinions on simplicity matter here

[13:57:14.0000] <Hixie>
SamB: a "paragraph" in HTML is just a run of text. If it contains a figure, it's not a paragraph, it's two paragraphs and a figure. Yes, this is not quite what English majors would have you say, but there we have it.

[13:57:31.0000] <caitp>
look at the algorithm for parsing HTML

[13:57:33.0000] <Hixie>
caitp: the long and short of it is you're 23 years too late for this argument.

[13:57:35.0000] <caitp>
is that not crazy to you?

[13:57:39.0000] <TabAtkins>
caitp: All those kids seems to get it fine. The omitting rules got added *because* people were omitting them and browsers were accommodating them.

[13:57:50.0000] <Hixie>
(nobody is arguing that HTML parsing is simple.)

[13:57:53.0000] <TabAtkins>
caitp: Most of HTML parsing's complexity is in <script>.

[13:57:59.0000] <caitp>
a good chunk of it is

[13:58:01.0000] <caitp>
i agree

[13:58:04.0000] <TabAtkins>
With a bit of crazy from things showing up in <table> that shouldn't be there.

[13:58:12.0000] <SamB>
Hixie: yeah, when I said "mark paragraphs as", I mean if you want to format it traditionally, you need ways to mark <p> nodes as actually part of a larger paragraph

[13:58:13.0000] <Hixie>
TabAtkins: nah, that's not complex, it's just long. The complexity is in the AAA.

[13:58:17.0000] <Hixie>
and noah's ark

[13:58:22.0000] <Hixie>
and foster parenting

[13:58:35.0000] <TabAtkins>
"Long" and "complex" are pretty similarly bad for understanding. ^_^

[13:58:37.0000] <Hixie>
SamB: ah if you want to mark english-major paragraphs, use <div>, not <p>

[13:58:37.0000] <caitp>
the adoption agency is crazy

[13:58:41.0000] <caitp>
i don't think it's limited to that

[13:58:42.0000] <SamB>
I think TeX actually keeps track of the tightness of the last line of the previous chunk of paragraph

[13:58:43.0000] <Hixie>
TabAtkins: fair enough

[13:58:46.0000] <TabAtkins>
A lot of CSS Syntax I was able to "simplify" just by making it shorter.

[13:59:02.0000] <Hixie>
the adoption agency is the least crazy of the four utterly crazy options we had at our disposal, sadly

[13:59:12.0000] <SamB>
Hixie: hmm, how'd the CSS look to get proper indentation then?

[13:59:27.0000] <caitp>
i'd hate to see the alternatives then, because the adoption agency makes me really sad

[13:59:33.0000] <SamB>
I guess you'd use :first and :last?

[13:59:39.0000] <Hixie>
SamB: "proper" indentation of paragraphs is no indentation, so... :-)

[13:59:44.0000] <TabAtkins>
SamB: What sort of indentation are you looking for?

[14:00:19.0000] <SamB>
Hixie: I mean if for some reason you were trying to vaguely approximate traditional typesetting

[14:00:24.0000] <Hixie>
caitp: yeah, the alternatives were so much worse. One dependended on the TCP packet boundaries. Another required changes to CSS to not render styles that didn't map to the tree. The last involved the tree structure actually being a graph.

[14:00:44.0000] <Hixie>
caitp: there's some discussion of this stuff on ln.hixie.ch if you go back far enough

[14:01:14.0000] <SamB>
in terms of the overall shape more so than particular fonts

[14:01:15.0000] <Hixie>
SamB: you'd probably wrap the first part of the paragraph in a <p> in the <div> and style it using div>p:first-child

[14:01:18.0000] <caitp>
anyways, I understand why you don't want to change the AAA stuff at this point, maybe that ship sailed a long time ago

[14:01:39.0000] <caitp>
but I think, just maybe, for new tags like <template>, we could do better

[14:01:59.0000] <Hixie>
caitp: people copy-and-paste their existing content into new contexts

[14:02:03.0000] <SamB>
caitp: what do you mean?

[14:02:03.0000] <Hixie>
caitp: they don't want it to change behaviour

[14:02:17.0000] <SamB>
do you mean <template> itself shouldn't force </template> ?

[14:02:27.0000] <SamB>
otherwise, I think you're doomed

[14:02:41.0000] <SamB>
that's probably the only real negotiable here

[14:02:58.0000] <caitp>
I don't think it should force </template>, I don't think it should have any concept of content that is allowed to be in it

[14:03:12.0000] <caitp>
the only case where it should force </template> is at the end of the document

[14:03:22.0000] <TabAtkins>
SamB: It doesn't force </template>, iirc. You can nest templates.

[14:03:29.0000] <SamB>
TabAtkins: cool

[14:03:48.0000] <SamB>
caitp: not even </[something further up the stack]>?

[14:04:05.0000] <caitp>
not even

[14:04:18.0000] <SamB>
that could be done, but it sounds pretty crazy to me

[14:04:45.0000] <caitp>
function C() { function D() { }

[14:04:48.0000] <caitp>
what should happen

[14:05:01.0000] <TabAtkins>
In what language?

[14:05:10.0000] <caitp>
in ECMAScript, since we're here =)

[14:05:35.0000] <TabAtkins>
I forget whether it hoists D out of C or not, but it's definitely allowed.

[14:05:45.0000] <caitp>
it's not allowed, C hasn't been closed

[14:06:12.0000] <TabAtkins>
Oh, didn't see that that's the point you were making.

[14:06:33.0000] <caitp>
the one higher in the stack doesn't get closed first

[14:06:39.0000] <TabAtkins>
...yes?

[14:06:39.0000] <caitp>
this is logical and makes sense

[14:06:43.0000] <TabAtkins>
Why would you think it would be?

[14:06:45.0000] <Hixie>
caitp: btw i think you're confusing the idea of what is valid with the idea of how the parser works

[14:07:13.0000] <TabAtkins>
Both C and D use } to close, so } isn't equivalent to "</[something further up the stack]>".

[14:07:31.0000] <Hixie>
caitp: it's important that we say that e.g. <h1><h2>foo</h2></h1> is invalid, since that's what validators use to flag mistakes to the author

[14:07:38.0000] <TabAtkins>
It might make sense for EOF to auto-close C (CSS does this), but that's it.

[14:07:42.0000] <Hixie>
caitp: just like how type checking compilers say there's a problem when you add a string to an integer

[14:07:49.0000] <Hixie>
caitp: quality assurance tools are important

[14:08:14.0000] <caitp>
quality assurance tools are important, no argument there =)

[14:08:35.0000] <caitp>
but ideally they'll tell you to close your tags explicitly instead of making the parser acommodate your awful markup

[14:08:50.0000] <Hixie>
the two parts of that sentence are unrelated

[14:09:12.0000] <gsnedders>
jgraham: gosh darn it, I'm still 2/3rds your age! :P

[14:09:19.0000] <TabAtkins>
"Your page is bad, and we wont' display it until you fix it" was already tried. It was a complete and utter failure.

[14:09:52.0000] <caitp>
which was that? you can write some pretty bad xhtml pages that will still render _something_

[14:10:20.0000] <SamB>
caitp: yeah, </$FOO> only grabs the first $FOO

[14:11:24.0000] <caitp>
i think you can find a happy medium between "abort on error" and "don't rearrange peoples gunk"

[14:11:30.0000] <TabAtkins>
caitp: No, XHTML just fails. It fails hard. If you see it render "something", that's because it's not XHTML. It's HTML that you are writing in an XHTML-like syntax.  Maybe you don't *realize* it's HTML, maybe you dont' know that what you did triggered HTML parsing, but it happened.

[14:11:35.0000] <caitp>
it's not one or the other, you know?

[14:12:20.0000] <Hixie>
caitp: what should happen if the page has  <table><tr><td>A</td></tr>B<tr><td>C</td></tr></table>

[14:12:45.0000] <caitp>
layout would come up with something to do with the text node

[14:13:07.0000] <caitp>
we could find out

[14:13:46.0000] <Hixie>
how about <p>A<b>B<i>C</b>D</i>E</p> ?

[14:16:01.0000] <caitp>
http://jsfiddle.net/azjVF/ try it for yourself

[14:17:32.0000] <caitp>
if layout engines can figure out what to do with it, I'm not convinced the parser should have to

[14:17:32.0000] <gsnedders>
TabAtkins: WebKit and I presume Blink render up to the error

[14:17:45.0000] <TabAtkins>
THEY ARE VIOLATING THE SPEC

[14:17:47.0000] <gsnedders>
TabAtkins: You only have to abort normal parsing, you don't have to discard what you've already parsed

[14:18:02.0000] <TabAtkins>
THE INTENTION

[14:18:08.0000] <gsnedders>
They're not though.

[14:18:33.0000] <Hixie>
gsnedders is actually right on this. you're allowed to keep what you parsed so far and render it.

[14:18:34.0000] <gsnedders>
Because otherwise SAX parsers could never follow the spec — and their existance was a goal.

[14:18:49.0000] <gsnedders>
Hixie: you say this like I'm always wrong!

[14:19:04.0000] <Hixie>
no, the "actually" was more about TabAtkins than you :-)

[14:19:23.0000] <TabAtkins>
I choose to interpret it like gsnedders did.

[14:19:31.0000] <gsnedders>
Damn it guys!

[14:19:40.0000] <TabAtkins>
"gsnedders is actually right on this (unlike his usual wrong-as-hell self)"

[14:20:02.0000] <Hixie>
gsnedders: i'm gonna have a bunch of fixes to the tests

[14:20:04.0000] <TabAtkins>
"I know it's hard to believe, what with it being gsnedders and all, who's wrong all the time."

[14:20:05.0000] <Hixie>
gsnedders: how do you want them?

[14:20:11.0000] <zewt>
strict parsing is pretty nasty for file formats authored by humans rather than machines

[14:20:24.0000] <gsnedders>
Hixie: a pull request, which I presume is what you and jgraham were discussing while I was watching X-Men.

[14:20:35.0000] <TabAtkins>
"But hey, even a wrong clock is right twice a day."

[14:20:42.0000] <Hixie>
gsnedders: for the whole batch at once?

[14:20:53.0000] <TabAtkins>
"Though that, sadly, is way more right than gsnedders is on a given day."

[14:21:02.0000] <gsnedders>
Hixie: Are they all just fixing them to match the spec?

[14:21:06.0000] <zewt>
which make xhtml not terrible for machine-generated markup, but useless for the rest

[14:21:17.0000] <Hixie>
gsnedders: also adding a few features to the test format

[14:21:31.0000] <Hixie>
gsnedders: (#script-on / #script-off, to indicate if scripting is enabled or not)

[14:21:38.0000] <gsnedders>
Hixie: I'd rather that was kept as a separate PR

[14:21:41.0000] <Hixie>
k

[14:21:45.0000] <gsnedders>
(I agree it's needed)

[14:21:52.0000] <Hixie>
also a few new tests

[14:21:56.0000] <Hixie>
minor variations on existing ones

[14:22:07.0000] <Hixie>
most of the changes are fixing the #errors sections

[14:22:30.0000] <gsnedders>
Keep them in a separate commit, but they can probably piggy-back one of those PRs

[14:22:47.0000] <zewt>
wish there was a way i could convince google search to blacklist scrape-and-paste sites, it's getting pretty bad particularly for SO

[14:22:49.0000] <gsnedders>
I tend not to be too fussed unless I disagree with the code :)

[14:23:10.0000] <Hixie>
k

[14:23:18.0000] <gsnedders>
Hixie: git add --patch may be useful, allows you to select specific changes when committing

[14:23:47.0000] <zewt>
i type -p, i assumed it meant "pick"

[14:24:11.0000] <gsnedders>
zewt: why the hell do I ever know what it is an abbr for?

[14:24:47.0000] <Hixie>
blimey template.dat is long

[14:25:01.0000] <zewt>
dunno, you typed it :P

[14:25:10.0000] <Hixie>
gsnedders: k, i'll probably get back to you when i'm ready

[14:25:15.0000] <Hixie>
gsnedders: to figure out how to do it :-)

[14:25:18.0000] <gsnedders>
Hixie: The split between files is pretty random, as I've mentioned before :)

[14:26:02.0000] <Hixie>
these tests have been invaluable so far

[14:26:22.0000] <gsnedders>
We need more! And a way to check they're right and stay right!

[14:26:31.0000] <gsnedders>
/me mumbles mumbles mumbles

[14:26:39.0000] <Hixie>
well, that's kind of what i'm doing.

[14:27:12.0000] <gsnedders>
Is your impl actually going to strictly stay up to date with the spec?

[14:28:50.0000] <Hixie>
dunno, but since it's going to be used by the spec pipeline, it has a higher chance than average of keeping up to date

[14:40:12.0000] <Hixie>
the spec's a bit inconsistent about how many parse errors you get with an unexpected EOF

[14:40:17.0000] <Hixie>
but i'm not gonna fix it

[14:40:30.0000] <Hixie>
(e.g. <template><script> -> 2, <template><table> -> 1)

[14:43:01.0000] <gsnedders>
Hixie: Only in the template case? It certainly used to be the case you only got one

[14:43:53.0000] <Hixie>
yeah, it's templates that mess this up i think

[14:45:10.0000] <Hixie>
actually

[14:45:11.0000] <Hixie>
no

[14:45:19.0000] <Hixie>
<table><script> -> 2 also, as far as i can tell

[14:45:31.0000] <Hixie>
<template><template><template> -> 3

[14:46:03.0000] <jgraham>
git add -p is an immediately sufficient answer to "why does git give you access to the staging area"

[15:01:06.0000] <Hixie>
<dummy><table><template><table><template><table><script> gives you four EOF messages

[15:01:12.0000] <Hixie>
but can you guess which four? :-)

[15:02:20.0000] <TabAtkins>
jgraham: Preach it.

[15:28:10.0000] <SimonSapin>
jgraham: I use git-cola to do the same by click-selecting lines

[15:54:27.0000] <gsnedders>
Hixie: I now want to see if there's an upper-bound on the number of EOF errors… :)

[16:06:04.0000] <Hixie>
gsnedders: well each <template> gives one, so not strictly

[16:06:13.0000] <Hixie>
gsnedders: but if you count all those as one... then yeah, probably

[16:07:03.0000] <zewt>
target=_blank needs to be shot into the sun

[16:07:15.0000] <zewt>
preferably hard enough that it shoots out the other side of the sun, so it can fall into the sun a second time

[16:08:31.0000] <gsnedders>
Hixie: strictly, because why would I care about anything but being technically correct? :)

[16:08:45.0000] <gsnedders>
All other forms of correct are just secondary to that.

[16:11:39.0000] <gsnedders>
hahaha. So apparently here any vehicle over 3m tall must have a sign in the cab giving the height… in feet and inches.

[16:18:20.0000] <Hixie>
ok who was the joker who put "Not Known" as the parse error

[16:19:33.0000] <gsnedders>
Hixie: ezyang

[16:20:16.0000] <gsnedders>
We only sorted out the format of the errors about a year ago, before them all that was checked was number

[16:25:56.0000] <Hixie>
oh my version way back when didn't haver errors?

[16:28:18.0000] <gsnedders>
It may well have

[16:28:32.0000] <gsnedders>
But no impl paid attention to the format, just the number

[16:28:43.0000] <gsnedders>
So they ceased being at all meaningful except for the number

[16:29:41.0000] <Hixie>
well that's all that's meaningful now, still, no?

[16:30:16.0000] <gsnedders>
In *theory* we should now have (col, row): [meaningless]

[16:30:23.0000] <Hixie>
ah

[16:30:32.0000] <Hixie>
well i'm not doing that, and a lot of them don't have that :-)

[16:30:40.0000] <gsnedders>
As I said, in theory. :)

[16:30:48.0000] <Hixie>
also, the ones that do have col,row almost always have the row off by one

[16:30:52.0000] <Hixie>
compared to what mine outputs

[16:31:01.0000] <gsnedders>
zero/one-base?

[16:31:35.0000] <Hixie>
no, i think they're both 1-based, but i for "<foo>" i output the error at 1,6, and the tests have it at 1,5

[16:31:43.0000] <Hixie>
after the token, vs on the last character of the token

[16:32:05.0000] <Hixie>
(mine leads to a better experience when integrated with an IDE, imho)

[16:32:35.0000] <gsnedders>
i.e., we give the position of the next character to be consumed?

[16:33:00.0000] <Hixie>
i do, you give the position of the last consumed character

[16:33:22.0000] <Hixie>
but really the positions are debatable

[16:33:32.0000] <Hixie>
i mean, the position of a missing doctype is before the token that discovers it, for example

[16:33:35.0000] <Hixie>
not after it

[16:34:06.0000] <gsnedders>
so we give the position of what the spec calls the "current input character"?

[16:34:15.0000] <gsnedders>
which seems sensible from an API POV

[16:34:46.0000] <Hixie>
yeah, i think so

[16:34:56.0000] <Hixie>
anyway, that's not documented

[16:34:57.0000] <annevk>
My memory of these things is not great, but I think to remember when we started hacking we just cared about parse errors as a boolean; if it expected any and we reported any, it was good

[16:34:59.0000] <Hixie>
so it doesn't exist :-P

[16:35:08.0000] <gsnedders>
Hixie: Indeed. :)

[16:35:14.0000] <Hixie>
annevk: i'm updating the tests to have an accurate number, at least

[16:36:03.0000] <annevk>
I haven't really touched any HTML parsing code for a long time now. WebVTT was fun to do. Hopefully some other other format comes along at some point

[16:36:51.0000] <annevk>
WebVTT was actually really nice. Wrote it while hanging out with MikeSmith eating cookies and drinking tea in his neighbourhood

[16:50:06.0000] <gsnedders>
jgraham: speaking of html5lib, what do I need to get code-review of anything nowadays? bah!

[16:50:49.0000] <Hixie>
blimey

[16:50:58.0000] <Hixie>
i pass 8109 tests, but "<a><b><b><p></a>" is enough to take me down

[16:51:17.0000] <gsnedders>
The AAA really needs more test coverage. :(

[16:51:18.0000] <Hixie>
(hard, to, that's a null deref crash)

[16:51:22.0000] <Hixie>
too

[16:51:47.0000] <Hixie>
the problem with the AAA is that it's like the bidi model and margin collapsing and the inline box model

[16:51:55.0000] <Hixie>
at any given time, nobody actually understands it

[16:51:58.0000] <gsnedders>
:)

[16:52:06.0000] <Hixie>
for brief periods of time, there'll be one person who actually groks it

[16:52:20.0000] <Hixie>
but they don't grok it for long enough to write many tests

[16:52:29.0000] <Hixie>
because otherwise they'll go mad

[16:52:59.0000] <gsnedders>
I remember when I was fixing CSS 2.1 tests originally by various Opera people

[16:53:09.0000] <gsnedders>
I reached the bidi ones and just nope'd straight outta there

[16:53:13.0000] <Hixie>
hah

[16:53:17.0000] <Hixie>
the trick with bidi ones

[16:53:21.0000] <Hixie>
is to write it all on pieces of paper

[16:53:22.0000] <Hixie>
and cut them up

[16:53:25.0000] <Hixie>
and then do it by hand that way

[16:53:28.0000] <Hixie>
(seriously)

[16:54:00.0000] <jgraham>
gsnedders: Ummm. Good question

[16:54:10.0000] <jgraham>
/me sleep

[16:54:12.0000] <gsnedders>
I think in one of the cases I went, "oh, hey fantasai… see these tests you wrote years ago? yeah, could you fix them?"

[16:55:08.0000] <gsnedders>
jgraham: I only really care about my PRs, I can review other people's code. :P

[16:56:34.0000] <gsnedders>
Hixie: What I really want is a formal model of the spec so I can just model things as satisfaction problems and get tests like that :)

[16:57:45.0000] <Hixie>
good luck

[16:58:21.0000] <gsnedders>
really all I need is a decent formal model that I'm relatively sure matches the spec

[16:58:23.0000] <Hixie>
crap now i only pass 6928 tests

[16:58:25.0000] <Hixie>
what did i do!

[16:58:38.0000] <gsnedders>
you broke stuff!

[16:58:58.0000] <gsnedders>
damn it Hixie, you're meant to be the all-knowing master of HTML, and you can't even parse it? pff!

[16:59:33.0000] <Hixie>
ohhhh.... i had a bogus assert

[16:59:49.0000] <Hixie>
where the spec says "if any", it really means "if any", not "there will be one and you should assert there is one"


2014-06-14
[17:00:14.0000] <Hixie>
8115 tests

[17:00:25.0000] <gsnedders>
Last time anyone was claiming stuff about the AAA around me I didn't claim to know what it did, I just threw assertions into html5lib and ran the testsuite and said, "that appears to be true' :)

[17:00:44.0000] <Hixie>
yeah

[17:00:50.0000] <Hixie>
seems reasonable

[17:01:03.0000] <Hixie>
goddamnit, "<div><a><b><u><i><code><div></a>"

[17:01:24.0000] <gsnedders>
It amusing watching you go through this pain for a change. :)

[17:01:44.0000] <Hixie>
hey, i was the first one to implement this damn algorithm :-P

[17:01:52.0000] <Hixie>
this is my third attempt

[17:02:04.0000] <Hixie>
(second in a programming language, i'm counting the spec as one)

[17:02:15.0000] <Hixie>
one day i'll do it in a language that's actually useful to someone

[17:02:22.0000] <gsnedders>
XD

[17:02:39.0000] <zewt>
if the spec counts as an implementation, shouldn't it count towards interop

[17:02:49.0000] <Hixie>
ok this bug appears to be related to the bookmark thing in the AAA

[17:02:58.0000] <Hixie>
unfortuantely i don't actually understand the bookmark thing in the AAA

[17:03:02.0000] <Hixie>
i was hoping i had it right...

[17:03:46.0000] <gsnedders>
Thereby proving your statement about the AAA above correct. :)

[17:04:24.0000] <Hixie>
it's really tempting to implement the bookmark thing by literally inserting something into the array

[17:04:28.0000] <Hixie>
and then searching for it

[17:04:34.0000] <Hixie>
but that's pretty terrible

[17:04:48.0000] <gsnedders>
Pretty sure that's what html5lib does

[17:07:25.0000] <Hixie>
aha

[17:07:27.0000] <Hixie>
i think i got it

[17:08:03.0000] <Hixie>
i remove something from the list but don't fix the bookmark

[17:13:42.0000] <Hixie>
and now <p><b><b><b><b><p>x !

[17:13:43.0000] <Hixie>
noahhhhh!

[17:13:52.0000] <gsnedders>
noah's ark?

[17:13:54.0000] <Hixie>
could have sworn i implement noah

[17:14:11.0000] <gsnedders>
but do you implement it correctly?

[17:14:27.0000] <Hixie>
i guess not...

[17:15:00.0000] <Hixie>
oh

[17:15:01.0000] <Hixie>
hahaha

[17:15:11.0000] <Hixie>
they were only considered matches if they had attributes

[17:16:06.0000] <Hixie>
holy kittens!!!

[17:16:11.0000] <Hixie>
8123 tests passed

[17:16:13.0000] <Hixie>
that's all of them

[17:16:19.0000] <Hixie>
well, all except the fragment mode tests

[17:22:06.0000] <Hixie>
gsnedders: so, i skip 106 tests, but i do run all the tree construction ones twice, so that kind of makes up for it. total time to run all the tests in an optimised build on the machine hosting whatwg.org (a dreamhost virtual host) is: 1.5s.

[17:23:12.0000] <Hixie>
gsnedders: you gonna be online in a couple of hours?

[17:23:55.0000] <gsnedders>
Hixie: I need to sleep!

[17:24:18.0000] <Hixie>
gsnedders: k

[17:24:30.0000] <Hixie>
gsnedders: ping me tomorrow, we can go through the test fixes

[17:24:50.0000] <gsnedders>
Hixie: am hosting party tomorrow, starting probably around the time you get up :)

[17:24:57.0000] <Hixie>
k well ping me whenever

[17:25:12.0000] <Hixie>
d'oh

[17:25:12.0000] <gsnedders>
will do, or ping me w/e

[17:25:23.0000] <Hixie>
i tried to optimise it further and the compiler said "Fatal: Procedure too complex, it requires too many registers"

[17:25:40.0000] <Hixie>
(specifically, trying to inline all the stuff into the function that handles entities)

[17:26:12.0000] <Hixie>
guess 1.5s will have to be fast enough

[17:26:17.0000] <Hixie>
next thing to try is parsing the spec

[17:26:19.0000] <Hixie>
but i gotta go now

[17:37:22.0000] <jamesr_>
what language is hixie writing this parser in?

[17:38:48.0000] <TabAtkins>
object pascal

[17:39:04.0000] <gsnedders>
It's Hixie, what makes you think he'd choose something sane?

[17:39:09.0000] <TabAtkins>
(i think - i've said so once already, and he didn't correct me)

[17:39:15.0000] <gsnedders>
(you are)

[17:46:48.0000] <Hixie>
freepascal, technically, but yeah

[17:47:30.0000] <Hixie>
http://software.hixie.ch/libraries/pascal/html/src/htmlparser.pas

[18:03:57.0000] <Hixie>
ok so my parser parser the HTML spec source (6 megs,) and then reserialises it in the test format used by the tests, in 24 seconds

[18:05:51.0000] <Hixie>
(13s user+sys)

[18:06:05.0000] <Hixie>
gonna have to work on improving that

[18:06:33.0000] <gsnedders>
surprisingly large diff between real and cpu time

[20:20:32.0000] <Hixie>
gsnedders: it's a busy machine

[08:57:46.0000] <annevk>
Hixie: https://twitter.com/fvsch/status/477797954385113089 (seems easy enough)


2014-06-15
[11:46:59.0000] <krit>
annevk: won’t make it before noon tomorrow (personal reasons)

[12:50:57.0000] <Hixie>
got it down to 8.5s user+sys to do all the tests and parse the html spec and reserialise it

[15:58:03.0000] <gsnedders>
which of the encodings defined in Encoding are not ASCII-supersets?

[15:59:54.0000] <caitp>
ebcdic

[16:00:19.0000] <gsnedders>
caitp: is not in Encoding

[16:01:05.0000] <caitp>
i know

[16:01:34.0000] <gsnedders>
then it by definition is not an encoding defined in Encoding which is not an ASCII-supserset

[16:01:35.0000] <caitp>
anyways, it would be anything which doesn't have the "if it's less than 0x80, return it"

[16:01:57.0000] <caitp>
clause

[16:02:16.0000] <caitp>
with the exception of the utf16 stuff

[16:02:26.0000] <gsnedders>
and possibly some of the SBCSes, as at least ibm866 isn't

[16:02:33.0000] <zewt>
i don't recall there being any at all, ascii-compatibility is pretty fundamental

[16:02:53.0000] <caitp>
utf16be isn't really ascii-compatible

[16:02:57.0000] <caitp>
on a little endian system

[16:03:20.0000] <gsnedders>
no variant of UTF-16 is an ASCII-superset

[16:03:21.0000] <zewt>
it's not a multibyte encoding at all, double-byte encodings are a different world entirely

[16:03:59.0000] <caitp>
well, they are sort of

[16:04:39.0000] <caitp>
if the low byte is the first byte read, and you're skipping a byte for each character, and the code points are all below 0x80

[16:04:50.0000] <zewt>
oh yeah this http://krijnhoetmer.nl/irc-logs/whatwg/20111215#l-1034

[16:05:37.0000] <zewt>
hope was to get ibm866 dropped, no idea if anyone actually tried

[16:06:29.0000] <zewt>
caitp: "skipping a byte for each character" if you have to skip every other byte then ... that's not a superset of ASCII. heh

[16:06:42.0000] <caitp>
it is for the first character you read ;)

[16:07:17.0000] <zewt>
as ascii supports streams which are longer than one byte long, that's also not a superset of ASCII :0

[16:07:23.0000] <zewt>
)

[16:07:41.0000] <caitp>
ascii is a text encoding and has no concepts of streams

[16:08:00.0000] <caitp>
a single utf16 character can look like a null-terminated ascii string

[16:08:18.0000] <zewt>
not sure what this has to do with the fact that UTF-16 is in no possible conceivable contrived way a superset of ASCII, heh

[16:09:15.0000] <caitp>
it is, because unicode is a superset of ascii, codepoints 0x00-0x7F, followed by latin1 extensions to ascii, followed by the rest of the basic multilingual plane

[16:09:16.0000] <zewt>
encodings that are streams of 8-bit units (ascii, utf-8, sjis, most of them) are typically treated as separate concepts to ones that are streams of 16-bit units (utf-16, ucs-2) or 32-bit (ucs-4)

[16:09:53.0000] <zewt>
... utf-16 is not a superset of ASCII. sorry, this is too silly a conversation for me to bother with

[16:10:37.0000] <caitp>
unicode is a superset of ASCII, and if you look at patterns of bytes, it's possible that you can't tell the difference between certain single-character UTF16 strings, and certain null-terminated ASCII strings

[16:11:48.0000] <zewt>
no. an encoding which is a superset of ASCII is one where the same string of codepoints ("hello"), encoded with both encodings, results in the same block of data.

[16:13:24.0000] <caitp>
nonsense, we're in agreement that utf16 bye definition contains codepoints represented by a minimum of 16 bits, but that does not mean that codepoints between 0x0000 and 0x0080 aren't supersets of ascii, and can't look identical to certain ascii strings

[16:13:40.0000] <caitp>
obviously that depends on arch and doesn't include multi-character strings, byte that's irrelevant

[16:16:18.0000] <zewt>
you seem to have a deep misunderstanding of what "superset of ascii" means; it does not mean "every sequence of bytes that is valid ASCII is also valid UTF-16", it means "every sequence of bytes that is valid ASCII *has the same interpretation* in UTF-16", which is obviously false

[16:16:34.0000] <zewt>
anyhow, going to do something else now :)

[16:17:27.0000] <caitp>
that's one definition of superset, but when you get down to patterns of bits, it's not the case

[16:17:37.0000] <caitp>
but regardless I agree it's not a super important discussion to have

[16:17:41.0000] <caitp>
nobody cares about utf16 =)

[16:18:01.0000] <gsnedders>
Plenty of people care about UTF-16 and it's used plenty

[16:19:55.0000] <caitp>
it's not really used in any serious capacity for interchange of data

[16:20:37.0000] <gsnedders>
Plenty of CJK sites use it


2014-06-16
[18:11:57.0000] <caitp>
nah, you're an ideographic or phonetic language, where you don't need two+ characters for every consonant and vowel, even with utf8 where your average cjk character is 3 bytes, it still doesnt make utf16 massive savings

[18:12:29.0000] <caitp>
whether it's used or not is besides the point, it's still not heavily used for interchange

[18:12:53.0000] <caitp>
we use it internally because it's slightly easier to work with, but for interchange it doesn't make a whole lot of sense

[18:13:32.0000] <caitp>
slightly bigger characters, but fewer characters used

[18:15:59.0000] <caitp>
i'd attribute the fact that actual documents use it more to the nature of tools than anything else

[18:21:20.0000] <caitp>
but it's not really a storage size win, it's not a network traffic performance win

[18:21:32.0000] <caitp>
not that any of it really matters a whole lot

[18:50:47.0000] <MikeSmith>
caitp: so I've been wondering how things will end up evolving with the big js mvc frameworks once web components actually becomes a cross-browser-implemented part of the platform

[18:50:51.0000] <MikeSmith>
if it ever does

[18:51:25.0000] <caitp>
well, we're hoping it does, but these frameworks aren't just about drawing pretty widgets

[18:51:30.0000] <caitp>
they're about application structure, right

[18:51:36.0000] <MikeSmith>
sure yeah I realize that

[18:52:28.0000] <caitp>
so I guess the thing that happens is, ideally, web components and other parts of the framework are easy to test, and it makes it nice and easy for us to help people structure applications, large and small

[18:52:28.0000] <MikeSmith>
it's not clear to me how much of, e.g., angular is handling the bits that web components does natively

[18:52:35.0000] <MikeSmith>
ok

[18:52:56.0000] <caitp>
s/framework/platform/

[18:55:00.0000] <caitp>
well, a good answer to that question is "look at the angular 2.0 prototype stuff", a big issue that they're dealing with is fitting the web component model into an application framework, IE fitting them into the dependency injection model, and making them aware of their surrounding DOM nodes

[18:55:23.0000] <caitp>
it's pretty interesting, and it's not a super easy problem to solve as web components exists currently

[18:56:14.0000] <MikeSmith>
so that's another question I had

[18:56:44.0000] <MikeSmith>
which is, what's lacking in web components as it exists currently

[18:57:37.0000] <MikeSmith>
I mean, what have you seen that angular could use that web components should ideally provide but doesn't yet

[18:58:06.0000] <MikeSmith>
I was thinking about this today after seeing abarth's message about his <marquee>-in-js implementation

[18:58:57.0000] <MikeSmith>
in particular https://groups.google.com/a/chromium.org/d/msg/blink-dev/sQndrT36l1A/b9fJoUK3RAUJ

[18:59:35.0000] <MikeSmith>
"There were a couple things that I couldn't implement correctly because they're magic pieces of the platform we haven't explained yet..."

[19:02:41.0000] <caitp>
I've been following that thread a bit, but I'm not sure of the magic necessary for marquee --- but I guess what we're dealing with is, custom elements are always instantiated asynchronously (as far as I'm aware), and you can't really do any magic like inject some parameters into their "constructors", if such a thing were to exist. the hack around it is to do the dependency injection logic in the attach callback

[19:03:04.0000] <caitp>
so in other words the platform doesn't enable that natively, and that's our mechanism for making controls aware of their relationship to the application

[19:03:41.0000] <caitp>
and the whole asynchronous "upgrading" of elements has other issues WRT testability, which I think have been raised with the test-the-web-forward people

[19:06:23.0000] <MikeSmith>
as far as the testing issue goes, the subset of the test-the-web-forward people working on writing tests for web components and reviewing those tests are actually the same people from Google who implemented web components in blink

[19:07:09.0000] <MikeSmith>
so I think we're planning on them to also come up with some solution to any special testing issues it creates

[19:07:36.0000] <caitp>
i expect so

[19:09:47.0000] <caitp>
there are some other things that are sort of frustrating, but I only really hear about it during meetings, since I'm working on other areas at the moment. might be some of it available in the meeting notes

[19:12:00.0000] <caitp>
yeah, looks like a lot of the discussion is recorded

[19:16:16.0000] <MikeSmith>
caitp: I guess I'll trust that that folks from angular are getting the feedback to dglazkov and hayato and others working on the web-components implementations and specs

[19:17:01.0000] <caitp>
i've suggested it, but I don't know if it's getting there. have to ask dglazkov if he's heard anything

[19:56:20.0000] <abarth>
MikeSmith: that's one of the reasons to use web components internally in the engine: you discover what's missing

[19:56:44.0000] <abarth>
MikeSmith: One thing I didn't mention on the list is I haven't figured out how to do inline event handlers properly

[19:57:00.0000] <abarth>
<marquee onbounce="...">Foo</marquee>

[19:57:10.0000] <abarth>
setting up the right JS environment for the ... is a bit subtle

[19:57:14.0000] <MikeSmith>
oh

[19:57:36.0000] <abarth>
the engine does that all the time, but it's not clear how to authors can do precisely the same thing

[19:57:47.0000] <abarth>
I think I've got the script version working right

[19:57:52.0000] <abarth>
foo.onbounce = ...

[19:58:03.0000] <abarth>
but the attribute version is subtly different

[19:58:27.0000] <MikeSmith>
it's cool to see these gaps getting exposed

[19:59:23.0000] <MikeSmith>
though I guess in the short term you'd just like to have a way to make it work

[20:01:08.0000] <MikeSmith>
also incidentally I guess this could be added to the list of reasons why inlining event handlers is not a best practice

[20:02:10.0000] <abarth>
I'm not really injecting much opinion

[20:02:18.0000] <abarth>
just trying to make thing A work the same way as thing B

[23:10:12.0000] <annevk>
krit: ah okay, guess I have some time to read up on SVG then :-)

[23:12:00.0000] <annevk>
gsnedders: utf-16 is the only encoding that's not ASCII-compatible

[23:38:06.0000] <MikeSmith>
hsivonen: about https://bugzilla.mozilla.org/show_bug.cgi?id=1024447#c12 I don't think the EME spec specifies the "keysystem" content attribute for the source element sufficiently, and it would be better to have it defined properly in the HTML spec -- provided that the attribute is actually suppored in UAs.

[23:38:06.0000] <MikeSmith>
hsivonen: I mean, for one thing, the relevant text in the EME spec reads in whole just, "The keysystem content attribute is added to HTMLSourceElement."

[23:39:55.0000] <annevk>
MikeSmith: did you file a bug on that?

[23:40:02.0000] <annevk>
MikeSmith: you should really file bugs :-)

[23:40:15.0000] <SamB>
MikeSmith: what, no "TODO: flesh out"?

[23:55:08.0000] <annevk>
JakeA: Headers is now defined in more detail

[00:00:33.0000] <JakeA>
annevk: cool. Will review in detail tomorrow. Stupid I/O deadline today.

[00:01:36.0000] <annevk>
JakeA: I'll mostly be working on SVG this week so that seems fine

[00:01:48.0000] <annevk>
JakeA: you already in SF?

[00:06:11.0000] <JakeA>
annevk: nah, heading out on Friday

[00:33:56.0000] <annevk>
/me finds out jungkees has been busy

[00:51:26.0000] <mathiasbynens>
zcorpan: you called it! (re: DnD/picture)

[01:10:14.0000] <zcorpan>
mathiasbynens: what do you mean?

[01:14:11.0000] <jungkees>
annevk: https://github.com/slightlyoff/ServiceWorker/issues/235

[01:15:00.0000] <jungkees>
annevk: with this particular thread, what should be fixed more?

[01:17:04.0000] <annevk>
jungkees: looking at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#default-method

[01:17:14.0000] <annevk>
jungkees: step 3.2 needs to be removed

[01:18:12.0000] <annevk>
jungkees: if response is a network error you need to reject with a TypeError

[01:18:31.0000] <annevk>
jungkees: and you need to explain how this relates to the overall lifecycle

[01:23:55.0000] <jungkees>
annevk: alright

[01:31:26.0000] <annevk>
jungkees: I think the spec still does not do a great job of explaining the overall model and how all the various pieces interact with it

[01:32:00.0000] <annevk>
jungkees: e.g. what is .default() plugging into that makes "handle a fetch" return the correct thing?

[01:32:55.0000] <jungkees>
annevk: will add them after sorting out the hooks to Fetch this week

[01:34:17.0000] <annevk>
jungkees: ah yeah, Nikhil opened an issue for that

[01:37:46.0000] <jungkees>
annevk: I'll add informal sections to explain the overall hook model and the use of fetch API in SW context xref to Fetch esp. Request/Response/Fetch part

[01:38:07.0000] <annevk>
jungkees: I'm not talking non-normative

[01:38:23.0000] <annevk>
jungkees: my concern is with the normative model

[01:38:45.0000] <annevk>
jungkees: the current setup is not sufficient

[01:38:50.0000] <mathiasbynens>
zcorpan: i assumed it would be simple & a no-brainer but you realized logic doesn’t necessarily apply in the world of Web Standards

[01:38:57.0000] <jungkees>
annevk: as I'll remove the Request/Response interfaces from SW

[01:39:16.0000] <zcorpan>
mathiasbynens: ah. yeah

[02:22:41.0000] <krit>
annevk: am back… back online

[02:24:11.0000] <krit>
zcorpan: hi. I uploaded a couple of DOMRect,DOMPoint and DOMQuad tests. If you have time, please review them. https://github.com/w3c/csswg-test/pulls #551-#553

[02:24:39.0000] <zcorpan>
krit: ok nice

[02:26:05.0000] <annevk>
krit: okay, how to best do this?

[02:26:31.0000] <smaug____>
heycam: would you need some ["foo", "bar"] defaults values for the dictionary/eventinit ?

[02:26:36.0000] <annevk>
krit: it seems your best bet is assuming the model HTML has outlined

[02:26:39.0000] <krit>
annevk: we could switch to #svg on w3c irc server… it is recorded as well IIRC

[02:27:05.0000] <krit>
annevk: we can discuss it here. Just not sure if we produce to much noise

[02:27:25.0000] <annevk>
krit: here is fine, this channel is known to be noisy

[02:27:31.0000] <krit>
annevk: ok

[02:27:59.0000] <krit>
annevk: agree that we should start from the HTML model

[02:28:18.0000] <krit>
annevk: For standalone SVG’s the model should be identical

[02:28:28.0000] <krit>
annevk: not much different to inline SVG

[02:28:47.0000] <annevk>
krit: given that, it's not clear why https://svgwg.org/specs/integration/ is needed, it seems the text should just be in https://svgwg.org/svg2-draft/

[02:28:56.0000] <krit>
annevk: Problem comes with fetching further resources… more specifically, SVG as fetch resource

[02:29:36.0000] <krit>
annevk: I think the SVG WG wanted to produce an anchor for specs using SVG

[02:29:53.0000] <krit>
annevk: something light weighted that provides all reference modes

[02:30:20.0000] <krit>
annevk: also, it would apply to all SVG specs, regardless of the version W3C status as REC and so on

[02:30:54.0000] <annevk>
krit: I think that's the wrong way to think about SVG. The way I see it is that we have some new elements (elements in the SVG namespace) and a special processing mode for XML with an "image/svg+xml" MIME type loaded as image

[02:31:46.0000] <krit>
annevk: I think for the security model, the WG would be open to put it back to SVG2.

[02:31:59.0000] <krit>
annevk: that doesn’t seem to be the biggest issue :)

[02:32:05.0000] <annevk>
krit: so you'd need to define the processing model for these new elements and you need to define a special algorithm for the "image" case that disables scripting and such

[02:32:49.0000] <krit>
annevk: there might be more modes…. SVG OpenType fonts could have a different set

[02:33:07.0000] <annevk>
krit: fair, that might be a third

[02:33:25.0000] <annevk>
krit: although I think fonts and images have roughly similar security characteristics

[02:33:26.0000] <krit>
annevk: At least for SVG images and SVG external resources (<pattern>, <filter>) we already agreed on the same policy

[02:33:54.0000] <krit>
annevk: agree, just that SVG as font gets context information to color the font

[02:34:46.0000] <krit>
annevk: but I am fine with keeping SVG as font as a special case that we handle later.

[02:35:04.0000] <krit>
annevk: so far there is just one implementer willing to implement SVG OpenType fonts

[02:35:57.0000] <krit>
annevk: back to SVG as document and SVG as image/svg+xml

[02:35:57.0000] <annevk>
krit: https://etherpad.mozilla.org/fixing-svg-processing

[02:39:10.0000] <annevk>
krit: so <svg:image> is like <img> these days?

[02:39:23.0000] <krit>
annevk: it ought to be

[02:39:24.0000] <annevk>
krit: if it loads SVG that SVG cannot execute script?

[02:39:29.0000] <annevk>
krit: sounds good

[02:39:35.0000] <krit>
annevk: still need to add cross origin attribute

[02:39:47.0000] <krit>
annevk: yes, same model as <img>

[02:39:59.0000] <annevk>
krit: that's fine, as long as the security model is equivalent

[02:40:54.0000] <annevk>
krit: do you know why CSS was seen as a risk? is it the fetching?

[02:41:32.0000] <krit>
annevk: the WebAppsSec WG wanted to disable styling in general… they feared that some data could be used to trick the user

[02:41:45.0000] <krit>
annevk: example is coloring the image dependent on viewport size

[02:42:15.0000] <krit>
annevk: by using media queries and selectors

[02:42:20.0000] <annevk>
krit: ah okay, so the attack vector would be anything that can read from the environment

[02:42:39.0000] <krit>
annevk: that was the strongest argument, yes

[02:43:05.0000] <krit>
annevk: while “read” does not mean that the attacker can read

[02:43:22.0000] <annevk>
hmm yeah, need better word

[02:43:23.0000] <krit>
annevk: just a different display behavior dependent on context

[02:44:31.0000] <annevk>
krit: so https://svgwg.org/svg2-draft/linking.html#processingIRI has a long list of things that can fetch

[02:45:05.0000] <krit>
annevk: let me check if it is accurate

[02:45:13.0000] <annevk>
krit: for each of those we need to figure out what happens with the resources retrieved

[02:45:50.0000] <krit>
annevk: a view elements can’t anymore: mask, filter.. otherwise correct

[02:46:03.0000] <annevk>
few?

[02:46:12.0000] <krit>
annevk: yes :)

[02:47:04.0000] <krit>
annevk: I think with the exception of script, a, (cursor?) the policy can be the same for all elements

[02:47:08.0000] <annevk>
krit: can they all reference externally too?

[02:47:13.0000] <krit>
annevk: yes

[02:47:32.0000] <annevk>
krit: but they're a bit different from the SVG as image case right?

[02:47:52.0000] <krit>
annevk: I don’t think so...

[02:47:58.0000] <krit>
annevk: actually they can'y

[02:47:59.0000] <krit>
t

[02:48:04.0000] <annevk>
krit: you basically extract some elements to act as a paint server or some such?

[02:48:05.0000] <krit>
annevk: they must be treated the same

[02:48:54.0000] <krit>
annevk: <use>, <text> and a couple of other elements reference elements for drawing, other elements are pain sources…. to differ here is not necessary

[02:49:08.0000] <krit>
s/pain/paint/

[02:49:39.0000] <annevk>
well it seems good to make a difference since you'd invoke different algorithms

[02:49:57.0000] <krit>
annevk: in this case there are 4:

[02:50:00.0000] <annevk>
one is draw an image given a response object and some height/width criterea

[02:50:11.0000] <annevk>
the others would be not that :)

[02:50:23.0000] <krit>
annevk: image, as paint source(gradients patterns), as operator (mask, clipPath, filter)

[02:50:58.0000] <krit>
annevk: and referenced (external) elements that are drawn in the context of the current document

[02:51:23.0000] <krit>
annevk: example for the last: <use xlink:href=“other.svg#path/>

[02:51:48.0000] <krit>
annevk: A <path> element is “copied” from the document other.svg and added in the place of <use>

[02:52:04.0000] <annevk>
krit: but you don't actually change the DOM, correct?

[02:52:16.0000] <annevk>
krit: this is some kind of shadow DOM thingy?

[02:52:23.0000] <krit>
annevk: no, it is implemented with shadow DOM

[02:52:29.0000] <krit>
annevk: right

[02:52:46.0000] <annevk>
same-origin restriction?

[02:52:53.0000] <krit>
annevk: none defined yet

[02:53:08.0000] <krit>
annevk: part of the new security model :)

[02:53:09.0000] <annevk>
do scripts execute?

[02:53:11.0000] <annevk>
I see

[02:53:28.0000] <annevk>
please start calling it processing model ;)

[02:53:42.0000] <annevk>
security is just one aspect of the many things that are not defined here :)

[02:53:46.0000] <krit>
annevk: that was brought up recently : <use xlink:href=“other.svg#g”/> that references <g><script></script></g>

[02:53:55.0000] <krit>
annevk: and it is not executed

[02:54:22.0000] <annevk>
okay, so potentially less volatile than HTML imports

[02:54:39.0000] <krit>
annevk: if implemented correctly :)

[02:56:06.0000] <annevk>
krit: does <use> have an object model?

[02:56:23.0000] <krit>
annevk: it was removed

[02:56:50.0000] <annevk>
krit: what about hit testing on <use> does that return the <use> element?

[02:57:25.0000] <krit>
annevk: so hit testing applies in general to <use>… do you mean event handlers?

[02:57:51.0000] <annevk>
krit: what would elementFromPoint() return?

[02:57:58.0000] <krit>
annevk: something like onmouseover may apply… need to check

[02:57:59.0000] <annevk>
krit: but yes, event handlers, :hover, etc.

[02:58:18.0000] <annevk>
krit: note that hit testing can return different things depending on who is asking

[02:58:20.0000] <krit>
annevk: elementFromPoint would not go into the <use> tree

[02:58:34.0000] <annevk>
krit: hit testing not being defined is of course problematic for that...

[02:59:02.0000] <krit>
annevk: there are no restrictions to hit testing for <use>… think that is defined

[03:00:32.0000] <krit>
annevk: “The event handling for the non-exposed tree works as if the referenced element had been textually included as a deeply cloned child of the ‘use’ element, and events are dispatched according to the shadow tree event dispatching algorithm [SHADOWDOM]."

[03:01:55.0000] <annevk>
krit: so basically this is defined in terms of shadow DOM, except shadow DOM does not actually provide encapsulation at the moment

[03:02:07.0000] <annevk>
krit: only Chrome has such a thing

[03:02:20.0000] <krit>
annevk: yes

[03:03:21.0000] <annevk>
mkay, I guess you guys can clean that up at some point, hit testing should prolly follow from that

[03:03:39.0000] <krit>
annevk: is there an example in HTML?

[03:03:47.0000] <krit>
annevk: how HTML defines hit testing?

[03:03:53.0000] <annevk>
krit: nobody defines hit testing

[03:04:04.0000] <annevk>
krit: it's a big problem

[03:04:06.0000] <krit>
annevk: that sounds like a meme

[03:04:27.0000] <annevk>
might be something about anne and being a broken record on hit testing

[03:08:44.0000] <annevk>
krit: so is <use> non-isolated or isolated?

[03:09:07.0000] <krit>
annevk: not isolated for styling, isolated for DOM

[03:09:18.0000] <annevk>
hmm

[03:09:55.0000] <krit>
annevk: hooking up <use> on shadow DOM is new… there might potentially be changes

[03:10:40.0000] <annevk>
krit: so <use> fetches a resources, parses it as XML, then locates node by ID and deepclones it into the shadow tree?

[03:10:57.0000] <annevk>
krit: and when it parsers it does so with scripting disabled

[03:11:59.0000] <krit>
annevk: so, what happens in implementations is that we fetch the document and run it though the parser… then we look for the id and deep clone it (some implementations just create the render tree)

[03:12:22.0000] <krit>
if you just create the render tree, you exclude Scripting already

[03:12:54.0000] <annevk>
well the render tree is created from the shadow tree

[03:13:11.0000] <annevk>
and the parser is what executes script

[03:15:56.0000] <krit>
annevk: animations can not be disables=d by author ATM. This is one problem with Canvas’s drawImage() “first frame” doesn’t really apply for SVG… in this case the UA indeed disables the animation

[03:17:17.0000] <annevk>
okay

[03:18:36.0000] <annevk>
krit: "(result of rendering to a bitmap or something else?)" is about how we'd define it; how it's implemented is immaterial

[03:18:57.0000] <krit>
annevk: ok, defining it by bitmap is the easiest

[03:19:40.0000] <krit>
annevk: (resolution depends on the device of course)

[03:23:18.0000] <krit>
annevk: xref == xlink:href ?

[03:23:30.0000] <annevk>
krit: cross-reference

[03:23:41.0000] <krit>
annevk: makes sense :P

[03:25:12.0000] <krit>
annevk: beside elementFromPoint() we have CSSOM calls like getClientsRect() and so on… which of course don’t look into the shadow tree

[03:25:36.0000] <krit>
annevk: not sure if there is a common expression for these kind of interfaces

[03:25:54.0000] <annevk>
krit: layout APIs?

[03:26:08.0000] <krit>
annevk: maybe

[03:26:11.0000] <annevk>
krit: render tree APIs I suppose, as they operate on that

[03:26:47.0000] <krit>
annevk: basically all APIs in http://dev.w3.org/csswg/cssom-view/ :P

[03:28:43.0000] <krit>
annevk: CSS WG refuses to deifne render tree. so layout actually sounds good

[03:28:54.0000] <annevk>
krit: is there anything in particular with getClientsRect()?

[03:29:17.0000] <annevk>
krit: it seems if you use it on <use> it would reveal the render size of the shadow tree?

[03:30:51.0000] <krit>
annevk: <use> it would

[03:31:01.0000] <krit>
annevk: *it would

[03:31:15.0000] <annevk>
krit: seems like <use> should be same-origin / CORS

[03:31:43.0000] <krit>
annevk: yes… it is in Firefox

[03:32:35.0000] <krit>
annevk: In FF the same for paint sources and operators

[03:33:11.0000] <krit>
annevk: And it shouldn’t be a problem to add this requirement in the spec. External references are just implemented in Firefox so far.

[03:33:25.0000] <krit>
annevk: and Opera <= 12

[03:33:45.0000] <annevk>
krit: I remember there was a problem with CSS and SVG together?

[03:34:13.0000] <annevk>
krit: where for CSS we did not want to have that restriction and so we ended up making the distinction through fragment identifiers?

[03:34:20.0000] <krit>
annevk: you probably mean the mask-image: url() problem, where url() can reference an image or an SVG resource?

[03:34:55.0000] <krit>
annevk: well, we went away from present fragment switching and required the same policies for both

[03:35:15.0000] <krit>
annevk: this indeed seems critical with same origin requirement for SVG resources :/

[03:36:00.0000] <annevk>
krit: okay, so if that's always same-origin that's great

[03:36:01.0000] <krit>
annevk: hm… need to think about it

[03:36:15.0000] <krit>
annevk: well, for use definitely

[03:36:32.0000] <krit>
annevk: for paint sources/operators maybe not so much because if the url() CSS function issue

[03:36:46.0000] <krit>
s/if/of/

[03:37:03.0000] <annevk>
I think I remember what I proposed to roc

[03:37:30.0000] <krit>
annevk: Ah! FF added the restriction because the resource was allowed to fetch more data

[03:37:33.0000] <krit>
annevk: IIRC

[03:38:20.0000] <krit>
annevk: and with the new model, operators and paint sources are not allowed to fetch anything no matter what

[03:38:22.0000] <annevk>
That we would make the cross-origin fetch, but if the resulting document was SVG, we would treat it as an error

[03:38:56.0000] <annevk>
krit: I thought you could still do some amount of discovery based on what gets masked on the page

[03:39:17.0000] <krit>
annevk: for clipPath yes, it affects hit testing

[03:39:42.0000] <krit>
annevk: that wasn’t seen as issue by the CSS WG when I brought it up

[03:39:50.0000] <annevk>
krit: yeah, so I'm thinking that blocking tainted SVG is probably the way to go (while allowing tainted images)

[03:40:17.0000] <annevk>
I'm not sure the CSS WG is the best place for security issues

[03:40:29.0000] <annevk>
It's not like CSS' processing model is very clear

[03:40:57.0000] <krit>
annevk: well, atm implementations fetch resources with certain policies… there is no checking for further policies after fetching

[03:41:11.0000] <annevk>
I'm not sure what that means

[03:41:51.0000] <krit>
annevk: you fetch a resource with same origin requirement, or you fetch it without any requirements… (to make it simple just the two cases)

[03:42:08.0000] <annevk>
sure

[03:42:09.0000] <krit>
annevk: once the implementation has the resource, it is assumed that everything is ok IIRC

[03:42:17.0000] <annevk>
but you can make a check once you get something back to see whether you want it

[03:42:27.0000] <annevk>
similarly to doing a content-type check as we sometimes do

[03:42:30.0000] <krit>
annevk: so if we fetch SVG without policies… then we do not check it a second time

[03:42:41.0000] <annevk>
yes, but we could, to make this work

[03:42:44.0000] <krit>
annevk: but do we do that today?

[03:42:58.0000] <annevk>
without the ridiculous check the url's fragment nonsense

[03:43:00.0000] <krit>
annevk: I mean somewhere?

[03:43:30.0000] <annevk>
well, SVG introduced this image or SVG problem

[03:43:44.0000] <krit>
annevk: true

[03:44:10.0000] <annevk>
and the way it was initially solved was by trying to distinguish them upfront by checking if the url had a fragment

[03:44:12.0000] <annevk>
which is broken

[03:44:24.0000] <krit>
annevk: yes

[03:44:31.0000] <annevk>
so either we create separate properties for the two cases or we distinguish after the fetch

[03:44:55.0000] <annevk>
and if you distinguish after the fetch between image and SVG, you can still discard one or the other if there's a problem

[03:45:09.0000] <annevk>
such as the response being tainted and being SVG

[03:45:20.0000] <krit>
annevk: to step back… masking does affect the visual output but does not contribute to hit testing

[03:45:27.0000] <krit>
annevk: it is just clip-path which does it

[03:45:38.0000] <krit>
annevk: so maybe we can limit it to clip-path only?

[03:45:50.0000] <krit>
annevk: clip-path property does not fetch images

[03:46:08.0000] <annevk>
my memory of the public-fx thread was that this was bigger

[03:46:26.0000] <krit>
annevk: bigger?

[03:48:06.0000] <annevk>
krit: http://lists.w3.org/Archives/Public/public-fx/2013AprJun/0046.html

[03:48:07.0000] <krit>
annevk: there is just one thing that could be exposed: rendering time… it take more time to render a mask than no mask

[03:48:16.0000] <krit>
annevk: so it could have affect on rAF

[03:48:20.0000] <annevk>
was about mask

[03:49:20.0000] <annevk>
http://lists.w3.org/Archives/Public/public-fx/2013AprJun/0021.html

[03:50:52.0000] <krit>
annevk: the first link still assumes that the document with the <mask> element can reference images from the same origin… which we don’t allow anymroe

[03:51:04.0000] <krit>
annevk: it must be in the document itself… no fetching

[03:52:26.0000] <annevk>
krit: so if you put a data URL there it'll always fail?

[03:53:15.0000] <krit>
annevk: dataURLs do not fetch by default, do they? they could have elements within that would try to fetch… which always fails.

[03:55:01.0000] <annevk>
krit: okay, I guess I see what you meant with respect to <mask>, you guys changed the model to be as "SVG as image" since that email exchange and now you think you can allow tainted responses

[03:55:25.0000] <annevk>
krit: does Firefox no longer do special casing for fragments then?

[03:55:30.0000] <krit>
annevk: hehe, right

[03:55:41.0000] <krit>
annevk: I don’t think it ever did?

[03:55:54.0000] <krit>
annevk: mask still just allows SVG resource in Gecko

[03:56:22.0000] <annevk>
okay, so it might be same-origin restricted at the moment?

[03:56:43.0000] <krit>
annevk: I think it is ATM

[03:58:41.0000] <annevk>
krit: okay, I want to take a break for a bit; I guess when we come back we should enumerate all the places that fetch

[03:58:55.0000] <krit>
annevk: ok, will be here

[03:59:45.0000] <annevk>
krit: prolly hour and a bit

[04:00:06.0000] <krit>
annevk: ok, thanks for looking into this!

[05:25:18.0000] <annevk>
krit: https://svgwg.org/ Streaming Draft link is broken

[05:26:41.0000] <krit>
annevk: doesn’t work for me too

[05:28:03.0000] <krit>
annevk: very strange, it is in the repository

[05:30:16.0000] <krit>
annevk: reported it to heycam, all I can do at the moment

[05:30:35.0000] <annevk>
krit: k

[05:30:38.0000] <annevk>
krit: https://etherpad.mozilla.org/fixing-svg-processing

[05:30:46.0000] <annevk>
krit: trying to complete the list of elements that fetch

[05:31:01.0000] <annevk>
krit: then I guess we can collect them into buckets somehow

[05:40:16.0000] <annevk>
krit: <style> does external references right?

[05:40:34.0000] <krit>
annevk: yes

[05:41:01.0000] <krit>
oh

[05:41:04.0000] <krit>
mistaken

[05:41:20.0000] <annevk>
krit: so can <cursor> be defined in terms of 'cursor'?

[05:41:43.0000] <annevk>
krit: as in, it might be good to remove the elements that can be described in terms of CSS

[05:42:34.0000] <krit>
annevk: old content might use it, but let me bring it up to SVG WG conf

[05:42:44.0000] <annevk>
krit: I mean spec-wise

[05:42:54.0000] <annevk>
krit: e.g. HTML defines <font> in terms of CSS

[05:43:42.0000] <krit>
annevk: needed to check, but yes

[05:43:55.0000] <krit>
annevk: cursor property might even be more powerful

[05:45:13.0000] <annevk>
krit: is the same true for other elements?

[05:45:14.0000] <krit>
annevk: looks like SVG has <cursor> to get the cursor position

[05:45:23.0000] <annevk>
o_O

[05:45:36.0000] <krit>
annevk: we have <font> in SVG which is the treated the same as in HTML

[05:46:04.0000] <annevk>
krit: <cursor> does not seem to be about getting the cursor position

[05:46:27.0000] <krit>
annevk: the x and y attributes are described about that + cursor image of course

[05:46:35.0000] <annevk>
yes

[05:46:38.0000] <krit>
http://www.w3.org/TR/SVG/interact.html#CursorElement

[05:47:00.0000] <annevk>
no, x and y are about where the image is to be placed relative to the mouse pointer

[05:47:24.0000] <annevk>
krit: see http://dev.w3.org/csswg/css-ui/#cursor

[05:49:05.0000] <krit>
annevk: for the property yes, but the SVG text implies otherwise

[05:49:40.0000] <annevk>
krit: that seems like one of the SVG's many bugs

[05:50:36.0000] <hsivonen>
MikeSmith: moving the keysystem attribute from EME to the HTML spec is a whole can of worms politically

[05:50:41.0000] <annevk>
because it doesn't actually make sense

[05:51:01.0000] <krit>
annevk: not even sure if we implement it in WebKit/Blink

[05:51:23.0000] <hsivonen>
MikeSmith: I'd rather have it better defined in EME itself as a first step

[05:51:52.0000] <annevk>
krit: can <feImage> be expressed in CSS?

[05:53:50.0000] <krit>
annevk: it does the same as <image> with the exception that it can reference an element

[05:54:00.0000] <krit>
annevk: which is than drawn in an offscreen buffer

[05:54:22.0000] <krit>
annevk: (maybe <image> can do the same? unsure)

[05:54:40.0000] <annevk>
is that observable somehow?

[05:55:48.0000] <krit>
annevk: observable how?

[05:56:10.0000] <krit>
annevk: I mean what do you want to observe?

[05:57:44.0000] <annevk>
nm

[05:58:32.0000] <annevk>
krit: do you know for all of these what the default fetching mode is?

[05:58:47.0000] <annevk>
krit: e.g. which are no CORS, which are CORS, and which are same-origin?

[06:00:08.0000] <krit>
annevk: again, definition is as <image> in general… added the cross origin attribute even http://dev.w3.org/fxtf/filters/#element-attrdef-crossorigin

[06:00:31.0000] <krit>
annevk: so it is no CORS by default, but can CORS can be set

[06:00:52.0000] <annevk>
what's the benefit of CORS in that case?

[06:02:08.0000] <krit>
annevk: http://dev.w3.org/fxtf/filters/#security

[06:02:56.0000] <annevk>
:(

[06:03:26.0000] <krit>
annevk: hehe, I guess I will never see a smile :)

[06:03:44.0000] <annevk>
heh

[06:04:21.0000] <annevk>
Okay, so feImage is tainted if the response's type is opaque

[06:05:40.0000] <annevk>
krit: I guess what I'm really interested in is whether the elements and properties we listed are same-origin or no-CORS by default

[06:05:42.0000] <MikeSmith>
hsivonen: ok I guess I'll do as annevk suggested and raise a bug against the EME spec

[06:06:02.0000] <annevk>
MikeSmith: please copy Chris Pearce and maybe me

[06:06:22.0000] <MikeSmith>
k

[06:06:41.0000] <krit>
annevk: all no-CORS since CORS didn’t existed when SVG 1.1 was speced

[06:07:04.0000] <krit>
annevk: (specification wise of course)

[06:07:34.0000] <annevk>
krit: nothing was same-origin restricted?

[06:07:35.0000] <krit>
annevk: and CSS doesn’t handle CORS yet either

[06:07:40.0000] <krit>
annevk: no

[06:07:45.0000] <krit>
annevk: nothing

[06:07:55.0000] <annevk>
can we talk implementation-wise now?

[06:08:13.0000] <krit>
annevk: CSS is still no-CORS

[06:08:19.0000] <krit>
annevk: same as in HTML

[06:08:20.0000] <annevk>
even clip-path?

[06:08:46.0000] <krit>
annevk: clip-path, mask, fill, stroke are same origin in Firefox

[06:09:01.0000] <krit>
annevk: they don’t fetch in WebKit and Blink yet

[06:09:15.0000] <annevk>
mask is mask-image?

[06:09:21.0000] <krit>
annevk: with the exception of -webkit-mask and -webkit-filter and -webkit-clip-path

[06:09:31.0000] <krit>
annevk: yes

[06:09:44.0000] <annevk>
ah, and -webkit- properties load images, not SVG, and do so no-CORS?

[06:09:46.0000] <krit>
annevk: remove -webkit-mask from the list

[06:10:20.0000] <krit>
annevk: -webkit-filter and -webkit-clip-path do load external resources as well. IIRC no self origin at the moment

[06:11:03.0000] <krit>
annevk: talking for general documents of course… not for SVG images

[06:11:19.0000] <annevk>
yeah

[06:11:59.0000] <krit>
annevk: the SVG elements do not fetch in Blink at all

[06:12:15.0000] <annevk>
krit: no SVG element?

[06:12:18.0000] <krit>
annevk: in WebKit we have the <use> element that did fetch. Think it is broken again

[06:12:37.0000] <krit>
annevk: In Firefox elements fetch same origin

[06:12:42.0000] <annevk>
krit: as in <svg><image xlink:href=...></svg> is broken?

[06:12:57.0000] <krit>
annevk: Opera <=12 fetches for CSS and elements without any restrictions

[06:13:10.0000] <krit>
annevk: I am unspecific

[06:13:24.0000] <krit>
annevk: operators and paint source elements don’t fetch

[06:13:31.0000] <krit>
in Blink and WebKit

[06:13:42.0000] <annevk>
in no context?

[06:13:48.0000] <krit>
annevk: right

[06:13:55.0000] <annevk>
but they support inline references?

[06:14:01.0000] <krit>
annevk: yes

[06:14:32.0000] <annevk>
okay, so lets figure out the algorithm to get to an SVG element

[06:14:43.0000] <annevk>
how is it established that you have an inline reference?

[06:14:53.0000] <krit>
annevk: I am not aware of restrictions for <script>, <?…stylesheet…?>, <image>, <feImage> specification wise

[06:15:24.0000] <krit>
annevk: we parse URL but just use the fragment identifier and search in the same document

[06:16:10.0000] <krit>
annevk: This caused a bug where the URL is a different document but we still search for the fragment ID in the same document

[06:16:33.0000] <krit>
annevk: might still be broken

[06:17:10.0000] <annevk>
given a document /doc and a base URL /a/ and a fragment in /doc that reads #text where should we look?

[06:17:32.0000] <annevk>
what if the fragment/reference reads /a/#text

[06:18:32.0000] <krit>
annevk: exclusively speaking for WebKit/Blink: we do not resolve the URL… we just take the string specified by the user and use the fragment identifier of it…. no resolving of URL yet

[06:18:50.0000] <annevk>
krit: what if the string does not start with a #?

[06:19:47.0000] <krit>
annevk: well, the parsing process looks for the fragment identifier exclusively… example: “other.svg#test”… we do not resolve the base address of other.svg

[06:20:02.0000] <annevk>
krit: what is this "parsing process"?

[06:20:08.0000] <annevk>
krit: you just try to find a #?

[06:20:21.0000] <krit>
annevk: let me check, but that is what I remember

[06:22:25.0000] <krit>
annevk: the parsing algorithm is 350 loc

[06:23:30.0000] <krit>
annevk: I can say that we do not “simply” search for #… the algorithm does a lot more… just say we extract the fragment identifier from the string

[06:23:52.0000] <krit>
let me find the link

[06:24:41.0000] <krit>
annevk: http://trac.webkit.org/browser/trunk/Source/WebCore/platform/URL.cpp#L1088

[06:27:59.0000] <annevk>
krit: oh okay, so it seems to properly parse a URL, but then ignore all the good bits

[06:28:09.0000] <annevk>
seems to warrant a :(

[06:29:49.0000] <krit>
annevk: actually, it was a security pro caution and is limited to SVG

[06:30:43.0000] <annevk>
if you ignore the path and such that's not a security procaution, that's a bug

[06:31:01.0000] <krit>
annevk: this way we didn’t need to look into when we allow external resources. In the first days of SVG integration in WebKit this seemed wise. And then we never actually came to implement it correctly and there wasn’t a huge demand either

[06:31:19.0000] <annevk>
sure, I'm not advocating that we support Fetch

[06:31:22.0000] <krit>
annevk: it is a bug, true

[06:31:48.0000] <annevk>
but not properly parsing the URL and making sure it actually is relative to the document before proceeding is a huge forward compat issue

[06:31:55.0000] <krit>
annevk: I know, but implementations are ramping up and now it gets important

[06:32:11.0000] <krit>
annevk: agree, that was a bug we didn’t thought about at the time

[06:32:20.0000] <annevk>
o_O

[06:32:32.0000] <annevk>
okay, lets move on, I started drafting an algorithm

[06:37:59.0000] <gsnedders>
Hixie: ping; can you give me both your code, how to build it, and how to run it, then I'll try?

[06:39:10.0000] <annevk>
krit: data URLs and blob URLs will work due to the fetching algorithm

[06:39:19.0000] <annevk>
krit: though for data URLs we'd need explicit opt in

[06:39:38.0000] <krit>
annevk: which section is that in URL spec?

[06:39:51.0000] <annevk>
krit: it's in the fetch spec

[06:40:43.0000] <krit>
annevk: looking

[06:43:37.0000] <krit>
annevk: still, your algorithm compares document URL with parsed URL… if they are equal and the URL has a frag id, then we search for an element in the same document OTHERWISE: 1)return network error if fetch is disabled…

[06:43:46.0000] <krit>
annevk: or do we not quit at 1)?

[06:44:12.0000] <annevk>
krit: ah

[06:45:16.0000] <annevk>
krit: no, blob and data URLs would just proceed to step 3

[06:45:51.0000] <krit>
annevk: right. Just mean that 3.1) says return on fetching disabled

[06:46:10.0000] <krit>
annevk: so dataURL and blob would return with negative result at 3.1

[06:46:11.0000] <annevk>
yes

[06:46:20.0000] <annevk>
if fetching is disabled

[06:46:43.0000] <krit>
annevk: for SVG image it is… and we should still allow blob and dataURL

[06:46:58.0000] <annevk>
how can an "SVG image" contain a blob URL?

[06:47:14.0000] <krit>
annevk: dholbert had a weird example

[06:47:37.0000] <krit>
annevk: I’ll ask him about the example again

[06:48:53.0000] <krit>
annevk: Asked him. He is in PSD timezone and should be awake in a couple of hours

[06:49:10.0000] <krit>
s/awake/online/

[06:49:32.0000] <annevk>
krit: okay, we could maybe make it a flag on Fetch

[06:49:55.0000] <annevk>
krit: "no networking flag" or some such

[06:50:07.0000] <krit>
annevk: ok, what about dataURLs and base64?

[06:50:29.0000] <annevk>
krit: I guess it might be okay to allow those yes

[06:50:55.0000] <krit>
annevk: it is important! :) People embed there PNGs in SVG files today

[06:51:31.0000] <krit>
annevk: External fonts seems to be the biggest problem for SVG Images… not sure how Firefox handles that today… not even sure how webkit does

[06:52:13.0000] <krit>
annevk: think WebKit doesn’t fetch web fonts today

[06:52:20.0000] <krit>
annevk: for SVG images

[06:52:34.0000] <annevk>
krit: "SVG images" is ambiguous

[06:53:15.0000] <krit>
annevk: indeed. In SVG WG we refer to image/svg+xml usually

[06:53:43.0000] <annevk>
krit: what is important for now is to define a model that's somewhat realistic, once we have that we can address various features

[06:55:53.0000] <krit>
annevk: yes

[06:56:08.0000] <annevk>
krit: so no scripting seems reasonably solid

[06:56:32.0000] <krit>
annevk: you refer to blobs?

[06:56:48.0000] <annevk>
krit: no, lets leave blob/data URLs alone for now, not important

[06:57:12.0000] <annevk>
krit: not doing scripting for an external resource is straightforward

[06:57:25.0000] <annevk>
krit: you simply don't invoke the parser with scripting enabled

[06:57:40.0000] <annevk>
krit: not doing fetching however, is processing layer

[06:58:10.0000] <annevk>
krit: so somewhere there's an algorithm that takes an SVG element and does something with it; use it as a mask/image/paint server/clip

[06:58:32.0000] <annevk>
krit: might be various such algorithms

[06:58:55.0000] <annevk>
krit: those need to be allowed to process elements, but also need to ensure no fetching is done

[06:59:07.0000] <annevk>
krit: for the CSS part of that CSS will need to gain a flag of "no fetching"

[06:59:28.0000] <annevk>
krit: which suggests maybe that flag should be passed all the way down to the fetching layer

[06:59:39.0000] <annevk>
krit: which then can decide whether to allow certain URLs, such as data URLs

[06:59:43.0000] <annevk>
in that mode

[07:00:18.0000] <krit>
annevk: another idea was to flag document

[07:00:41.0000] <krit>
annevk: and look at the status of document. So in general yes, fetching must pass the mode

[07:00:46.0000] <annevk>
yeah that seems equivalent

[07:00:48.0000] <krit>
annevk: fetchingEnables

[07:00:58.0000] <krit>
d

[07:02:14.0000] <annevk>
so for HTML most fetching is disabled if there's no browsing context

[07:02:18.0000] <annevk>
but it seems that wouldn't work here

[07:05:08.0000] <krit>
annevk: right

[07:05:32.0000] <krit>
annevk: sorry, need to take care of kids… slow in responce

[07:05:33.0000] <krit>
se

[07:09:00.0000] <krit>
annevk: could we continue tomorrow morning?

[07:09:26.0000] <annevk>
yeah sure, thanks for the help

[07:09:37.0000] <krit>
annevk: wrong way around ;)

[07:09:51.0000] <annevk>
need to think a bit how to proceed here

[07:10:04.0000] <annevk>
I'll let some Gecko people know we're trying to lock these things down

[07:14:08.0000] <krit>
annevk: cool! roc , bz and dholbert might be the right ppl to talk too

[07:51:53.0000] <jgraham>
annevk: I might just be very stupid, but your response about why .to() is preferred over .toX() didn't make any sense to me

[07:54:51.0000] <annevk>
*waves magic wand to make jgraham understand unstated things*

[07:56:32.0000] <Ms2ger>
The "state them" wand?

[07:57:05.0000] <annevk>
Ms2ger: unclear

[07:57:06.0000] <jgraham>
annevk: Erm. You posted the mail, I kind of assumed you already knew what you had stated

[07:57:27.0000] <annevk>
jgraham: you assumed I would understand what part didn't make sense to you?

[07:57:35.0000] <annevk>
sorry

[07:57:44.0000] <jgraham>
All of it didn't

[07:57:49.0000] <jgraham>
Hence "any sense"

[07:57:51.0000] <jgraham>
:)

[07:58:22.0000] <annevk>
seems pretty clear to me

[07:58:38.0000] <annevk>
anyway, I have to do something else

[07:58:52.0000] <jgraham>
I don't think it's at all clear conceptually (wihout reading the spec) why you can only call to() once, or why it would be worse with toX()

[07:59:50.0000] <jgraham>
Neither seems more complicated than the other to implement, really

[08:00:02.0000] <jgraham>
But the concerns about feature detection seem legitimate

[08:04:31.0000] <gsnedders>
Does anyone know if Google use Dart for anything significant?

[08:04:36.0000] <gsnedders>
(presumably in dart2js form)

[08:07:46.0000] <caitp>
the greentea stuff, at least

[08:10:07.0000] <caitp>
i guess it depends how you define "significant", though

[08:48:39.0000] <annevk>
jgraham: yeah, I guess we can look into it again

[09:37:02.0000] <annevk>
Is anyone trying this? https://loop.services.mozilla.com/calls/kfsTnuhULV9QzkcMbR4Xu1vJVV2hi-lQ4blJD1JVxcVlQ5lmH6isvyOI9iroY09PmTtX8hxuXCdeT-D4dXMwswZRId7DvBBEF728FxUOa0uS80v_TAt-pyak6A_Kubg0HU9qpbeQawu8KlEGuxcXYB9cpUPfAtoTWC6OJTMbx4YzxMnSnR0WfJwGJo41VsAVH_gC5W3lSIxArBE9V2-WG-CJ9fA

[11:42:06.0000] <estellevw>
The <output>, even those with a name, never have their value sumbitted along with the associated form, right?

[11:49:21.0000] <zcorpan>
estellevw: right

[11:49:43.0000] <estellevw>
thanks

[11:52:17.0000] <Domenic>
annevk: do you have that list of stream concepts that would be nice to define?

[11:57:43.0000] <Hixie>
gsnedders: ok here now

[11:58:14.0000] <gsnedders>
Hixie: you could just email me ;P

[11:58:56.0000] <Hixie>
that sounds like crazy talk

[11:58:58.0000] <Hixie>
ok

[11:58:58.0000] <Hixie>
so

[11:58:59.0000] <Hixie>
tests

[11:59:04.0000] <Hixie>
let's see

[11:59:19.0000] <Hixie>
git diff gives me a 1653 line diff

[12:00:07.0000] <Hixie>
how do you want them, one file at a time?

[12:01:11.0000] <gsnedders>
Hixie: related changes together

[12:01:21.0000] <Hixie>
how do i do that?

[12:01:23.0000] <gsnedders>
Hixie: you can use git add -p to select what to commit at each time

[12:01:42.0000] <gsnedders>
Google or prod someone else as to how, I need to phone my sister before I go out ;P

[12:01:46.0000] <Hixie>
k

[12:04:54.0000] <Hixie>
man git makes no sense to me at all

[12:05:08.0000] <Hixie>
what's the equivalent of "svn commit", meaning, the thing that sends my change upstream?

[12:05:57.0000] <Hixie>
everyone on the web is talking about multi-step processes involving web pages

[12:06:51.0000] <caitp>
`git push`?

[12:07:14.0000] <Hixie>
and waht does that push? all my commits?

[12:07:45.0000] <SamB>
hmm, anyone know a reference for the term "tofu"?

[12:08:44.0000] <Hixie>
SamB: context?

[12:09:01.0000] <SamB>
that stuff you see when you don't have the right font

[12:09:49.0000] <SamB>
usually little boxes, sometimes with hex codes in them

[12:09:50.0000] <Hixie>
oh the little squares?

[12:09:55.0000] <caitp>
Hixie: it will push the objects needed for the local refs to make sense remotely

[12:10:08.0000] <Hixie>
caitp: i've no idea what that means

[12:10:28.0000] <Hixie>
caitp: do i run git add, then git push? or git add, then git commit, then git push?

[12:10:39.0000] <SamB>
you have to commit before you can push changes

[12:10:40.0000] <Hixie>
how do i get several patches up to gsnedders?

[12:10:47.0000] <SamB>
commit each patch

[12:11:02.0000] <SamB>
then push the lot of them somewhere and inform him of where

[12:11:22.0000] <Domenic>
branch per patch, if they are independent

[12:11:34.0000] <caitp>
it's easier to explain with a chalkboard, but for the most part it's not worth worrying about the specifics of what gets pushed --- the simple case is, you have a branch, and you want to update a remote branch to match it

[12:11:53.0000] <caitp>
so you push your branch to the remote, and if it's a fast-forward commit, it will just work

[12:12:24.0000] <caitp>
and if it's not a fast-forward commit, then you should think carefully about it :d

[12:12:39.0000] <Hixie>
ok so with subversion, all i have to do is "svn diff", then i have the patch for review, then "svn commit", then it's upstream.

[12:13:07.0000] <SamB>
Hixie: in git you can commit first and review second

[12:13:24.0000] <Hixie>
you can do that in subversion too. svn commit, then svn diff with the revision numbers.

[12:13:34.0000] <Hixie>
i don't understand why git has to be so much more complicated.

[12:13:39.0000] <SamB>
yes, but without it being upstream

[12:13:46.0000] <Hixie>
i want it upstream

[12:13:52.0000] <Hixie>
what's the point of it not being upstream :-P

[12:14:08.0000] <caitp>
it's pretty simple, but there's a bit of a learning curve maybe. once you get the hang of it, it is totally natural

[12:14:13.0000] <SamB>
Hixie: git is used by many who don't have write access to upstream

[12:14:28.0000] <Hixie>
anyway

[12:14:48.0000] <Hixie>
so you're saying i should git add, then git commit, then git push, then git add, then git commit, then git push, etc?

[12:14:55.0000] <Hixie>
until i've got no more local changes?

[12:15:07.0000] <caitp>
you don't have to commit -> push -> commit -> push

[12:15:13.0000] <caitp>
you can commit -> commit -> commit -> push

[12:15:17.0000] <caitp>
if it's easier =)

[12:16:18.0000] <Hixie>
and that results in multiple patches on gsnedders' side?

[12:16:25.0000] <Hixie>
separate "pull requests" or whatever they're called?

[12:17:12.0000] <Domenic>
it results in separate commits, but not separate patches

[12:17:20.0000] <Domenic>
for separate patches, you should make separate branches

[12:17:31.0000] <Domenic>
Has anyone gotten Anolis + Travis-CI up and running?

[12:17:53.0000] <Hixie>
separate _branches_?

[12:17:55.0000] <Domenic>
Alternately, TabAtkins, how do I switch to Bikeshed?

[12:18:08.0000] <Hixie>
just to commit two separate files?

[12:18:21.0000] <Domenic>
branches are basically equivalent to commits in git

[12:18:26.0000] <Domenic>
they are not heavyweight as in svgn

[12:20:42.0000] <Hixie>
Domenic: i'm not finding anything online that leads me to that conclusions :-)

[12:20:55.0000] <Domenic>
Branches are pointers to commits

[12:21:19.0000] <Domenic>
literally if you look in the .git directory there will be files saying something like "branch_name: deadb33f"

[12:22:27.0000] <Hixie>
maybe i should just send gsnedders diffs

[12:23:21.0000] <SamB>
branches are *names* for commits

[12:23:28.0000] <SamB>
Hixie: you can use "git send-email" for that ;-P

[12:23:36.0000] <SamB>
after committing everything

[12:23:44.0000] <SamB>
or get format-patch

[12:23:52.0000] <Hixie>
is there no real documentation got git? i'm not finding anything sane on the web.

[12:23:56.0000] <Hixie>
for git

[12:23:57.0000] <Hixie>
not got git

[12:24:06.0000] <SamB>
you could try the manpages

[12:24:09.0000] <TabAtkins>
Domenic: What are you switching from?

[12:24:30.0000] <TabAtkins>
git manpages are terrible.

[12:24:32.0000] <Domenic>
TabAtkins: Anolis. Not too much complicated stuff yet. https://github.com/whatwg/streams/blob/master/index.html

[12:24:33.0000] <Hixie>
the man pages are impenetrable

[12:24:45.0000] <SamB>
hmm

[12:24:51.0000] <Domenic>
http://git-man-page-generator.lokaltog.net/

[12:24:59.0000] <TabAtkins>
Domenic: That's pretty easy to switch from, since it's similar to the old CSSWG preprocessor, and Bikeshed is a spiritual descendent.

[12:25:11.0000] <TabAtkins>
I can convert for you, or you can just follow the docs and ask me questions.

[12:25:19.0000] <Domenic>
Hixie: http://git-scm.com/book is probably the best

[12:25:41.0000] <SamB>
Hixie: anwyay, the nice thing is that anything you screw up before you push, you can still fix

[12:26:07.0000] <Hixie>
Domenic: i don't even know where to begin with that

[12:26:17.0000] <Hixie>
Domenic: (i've been trying to read that for the past half hour)

[12:26:27.0000] <TabAtkins>
Ugh, there's a super-great visual guide to git I'm trying to find.

[12:26:28.0000] <Domenic>
TabAtkins: hmm documentation has gotten much better since I last saw. I'll give it a shot and ask questions if I get stuck. Thanks!

[12:26:48.0000] <TabAtkins>
Domenic: It's been stable for like a year, so you must have looked at it a *long* time ago. ^_^

[12:26:55.0000] <TabAtkins>
https://marklodato.github.io/visual-git-guide/index-en.html

[12:26:59.0000] <SamB>
Hixie: maybe http://eagain.net/articles/git-for-computer-scientists/ will help?

[12:27:11.0000] <TabAtkins>
Hixie: ^^^ this was super informative to me.

[12:27:12.0000] <SamB>
Hixie: you aren't scared of DAGs are you?

[12:27:50.0000] <Hixie>
i'm not _scared_ of them, i just find the idea that i need to know about hashes and branches and DAGs and so forth just to submit some small diffs to be absurd

[12:28:05.0000] <Hixie>
TabAtkins: thanks, loking

[12:28:06.0000] <Hixie>
[24~looking

[12:28:10.0000] <Hixie>
l o o k i n g

[12:28:14.0000] <TabAtkins>
Hixie: The link I gave gives you a great, easy visual guide to the commands and what effect they have on the working directory, the index, and the history.

[12:28:17.0000] <TabAtkins>
Hahahaha

[12:28:37.0000] <SamB>
Hixie: well you don't have to know much about hashes to use it

[12:28:48.0000] <TabAtkins>
The hardest part of getting into git is (a) learning, intuitiveyl, what the index is for and why it's exposed, and (b) what commands interact with what thing.

[12:29:09.0000] <SamB>
call it the staging area

[12:29:10.0000] <TabAtkins>
Hard when you're used to a VCS that doesn't expose an index, at least.

[12:29:16.0000] <TabAtkins>
Yeah, same deal.

[12:29:48.0000] <Hixie>
TabAtkins: that explains the local stuff, but my real problem here is i don't care about the local stuff and just want to upload stuff to a remote server

[12:29:52.0000] <SamB>
the chief virtual of calling it an "index" is that that is less misleading than "cache"

[12:29:55.0000] <SamB>
er.

[12:29:58.0000] <Hixie>
i literally have zero use for the fact that git stores anything locally

[12:29:58.0000] <SamB>
s/virtual/virtue/

[12:30:07.0000] <TabAtkins>
Hixie: Pushing to a remote is just (1) get the stuff into your history, then (2) git push.

[12:30:18.0000] <SamB>
Hixie: you do it locally and then upload when you've got all the things locally that you want remotely

[12:30:25.0000] <Hixie>
TabAtkins: but what does it push?

[12:30:27.0000] <SamB>
just pretend you are the server for the moment

[12:30:30.0000] <TabAtkins>
Your history.

[12:30:37.0000] <Hixie>
i only want to push one diff

[12:30:39.0000] <SamB>
Hixie: all it needs to push to keep the dag in one piece

[12:30:40.0000] <TabAtkins>
(Using the "visual guide" terms.)

[12:30:43.0000] <SamB>
you can't push a diff

[12:30:46.0000] <SamB>
git has no diffs

[12:30:51.0000] <TabAtkins>
Hixie: You're already tracking the server, right?

[12:31:00.0000] <TabAtkins>
So you pulled from the server, then made changes and committed them, and want to push?

[12:31:00.0000] <Hixie>
"tracking"?

[12:31:23.0000] <TabAtkins>
Sorry, I keep using terms of art. ^_^

[12:31:30.0000] <SamB>
Hixie: you have it in the output of "git remote -v"?

[12:31:43.0000] <TabAtkins>
Point is: how did you get the code you were hacking on?

[12:31:47.0000] <TabAtkins>
With a `git pull`?

[12:31:47.0000] <Hixie>
i've no idea how i got my working directory, at this point, it's scrolled off the top of my .bash_history :-)

[12:31:53.0000] <TabAtkins>
Or `git clone`, whatever?

[12:32:03.0000] <SamB>
Hixie: so what says "git remote -v"?

[12:32:05.0000] <TabAtkins>
You probably cloned it.  There a `.git` folder in the top-level folder?

[12:32:06.0000] <Hixie>
git remote -v says "origin  https://github.com/html5lib/html5lib-tests (fetch)" (and origin)

[12:32:12.0000] <TabAtkins>
Okay, cool.

[12:32:12.0000] <Hixie>
er, and push

[12:32:35.0000] <SamB>
so yeah, you're tracking it

[12:32:39.0000] <Hixie>
now i have several changes in this direcory, and i'd like to submit them as separate patches. pull requests. whatever.

[12:32:54.0000] <TabAtkins>
Ah, you wanna do PRs.

[12:32:56.0000] <SamB>
hmm, separate pull requests means you'll need a branch for each

[12:32:58.0000] <TabAtkins>
That makes things a touch more complex.

[12:33:07.0000] <TabAtkins>
Want a walkthrough?

[12:33:22.0000] <Hixie>
if you're happy to give me one i would be much obliged, but i'd happily settle for documentation :-)

[12:33:51.0000] <TabAtkins>
Github's docs are okay for this, but it'll be compolicated since you've already made your changes all together.

[12:34:06.0000] <SamB>
"git gui" is your friend, I think

[12:34:12.0000] <Hixie>
they're in different files, fwiw

[12:34:18.0000] <TabAtkins>
Okay, that's easier.

[12:34:22.0000] <SamB>
oh, then "git add" is all you need

[12:34:25.0000] <TabAtkins>
Have you committed them yet? "No" is okay.

[12:34:31.0000] <Hixie>
(if they're not we'll pretend they are and then apologise to gsnedders later)

[12:34:38.0000] <Hixie>
nope

[12:34:42.0000] <TabAtkins>
Okay, cool.

[12:34:58.0000] <TabAtkins>
So you've got a lot of new files added, and none of them have had `git add` or `git commit` run on them yet, right?

[12:34:59.0000] <SamB>
("yes" would have been okay too)

[12:35:10.0000] <Hixie>
no new files iirc, just edits to existing files

[12:35:15.0000] <Hixie>
(these are changes to the html5lib tests)

[12:35:16.0000] <TabAtkins>
SamB: (Yeah, but I was trying to head off a "No, but I'm doing it now").

[12:35:19.0000] <TabAtkins>
Hixie: Okay.

[12:35:25.0000] <SamB>
Hixie: "git add" isn't just for new files

[12:35:26.0000] <TabAtkins>
So for each PR you wanna do, you'll need a fresh branch.

[12:35:39.0000] <Hixie>
ok

[12:35:42.0000] <Hixie>
/me grabs some wood

[12:35:43.0000] <TabAtkins>
So run `git checkout -b my-new-branch-name`.

[12:35:55.0000] <TabAtkins>
That'lll make a new branch and switch you to it.

[12:35:57.0000] <Hixie>
is that going to create new directories or anything?

[12:36:01.0000] <TabAtkins>
No.

[12:36:07.0000] <Hixie>
or just change the local directory to be in a branch?

[12:36:09.0000] <TabAtkins>
Branches are a magic git concept, not reflected in your directory structure.

[12:36:13.0000] <TabAtkins>
They're just a way of naming commits.

[12:36:27.0000] <Hixie>
so this is basically a way of naming the next commit(s)?

[12:36:32.0000] <TabAtkins>
The Yeah.

[12:36:47.0000] <SamB>
it switches which branch git considers to be your current branch

[12:36:54.0000] <TabAtkins>
Once you're in a new branch, `git add` the files you changed that you want to submit in a single PR, and `git commit`.

[12:37:00.0000] <TabAtkins>
Then make a new branch, and repeat.

[12:37:08.0000] <Hixie>
are these branch names local only, or should i take care to make them relevant in the future?

[12:37:09.0000] <TabAtkins>
Your uncommited files will follow you around as yous witch branches.

[12:37:21.0000] <SamB>
TabAtkins: shouldn't he switch back to "master" or whatever before he makes the next one?

[12:37:21.0000] <TabAtkins>
They'll go away as soona s the PR is merged.

[12:37:28.0000] <TabAtkins>
SamB: Oh yeah, right.

[12:37:39.0000] <Hixie>
ok

[12:37:40.0000] <SamB>
Hixie: the branch names don't have to last

[12:37:41.0000] <TabAtkins>
Do `git checkout master` after each commit, or your history'll be weird.

[12:37:52.0000] <TabAtkins>
And github will be unhappy.

[12:38:00.0000] <SamB>
I mean, probably the branches will be around forever but nobody will care once they've been merged up

[12:38:11.0000] <TabAtkins>
SamB: GH's UI lets you delete the branches.

[12:38:16.0000] <SamB>
well, sure

[12:38:17.0000] <Hixie>
where do i put the commit message?

[12:38:19.0000] <TabAtkins>
At least, remotely, and then that'll sync down.

[12:38:20.0000] <Hixie>
git commit -m"" ?

[12:38:25.0000] <TabAtkins>
Hixie: `git commit -m ""`

[12:38:26.0000] <Hixie>
k

[12:38:32.0000] <SamB>
but most people don't seem to bother to actually delete them ;-)

[12:38:44.0000] <Hixie>
and that gets sent to gsnedders somehow as part of the pull request?

[12:38:50.0000] <SamB>
Hixie: yes

[12:38:51.0000] <TabAtkins>
Not quite.

[12:38:53.0000] <TabAtkins>
Heh.

[12:38:57.0000] <TabAtkins>
This is preparing them for that.

[12:39:11.0000] <TabAtkins>
There are ways to do the PR from teh command-line, but I've never learned them.

[12:39:16.0000] <TabAtkins>
I do it through github's UI.

[12:39:27.0000] <zcorpan>
Hixie: you will want to checkout master (or gh-pages or whatever is the default branch) before doing the next git checkout -b foo

[12:39:34.0000] <Hixie>
TabAtkins: github can see my server?

[12:39:39.0000] <SamB>
TabAtkins: well, it does get included in the PR more-or-less

[12:39:56.0000] <TabAtkins>
Hixie: It can after you push.

[12:40:10.0000] <TabAtkins>
You'll be pushing the branches individually, and then you can tell GH to turn each branch into a PR.

[12:40:25.0000] <TabAtkins>
Like I said, there are more direct ways to do this last part, but I ahven't learned them yet.

[12:40:56.0000] <Hixie>
ok, so i've done git checkout -b format-changes; git add README.md; git commit -m"Update README file to include new and recent changes to the format"

[12:41:26.0000] <TabAtkins>
Now checkout master.

[12:41:30.0000] <TabAtkins>
Then repeat those steps for each other change.

[12:41:37.0000] <Hixie>
ok

[12:41:46.0000] <TabAtkins>
This'll clear out your working directory, which'll make things simpler if you have to resolve conflicts or whatever.

[12:41:48.0000] <zcorpan>
not push first?

[12:41:58.0000] <zcorpan>
git push origin -u format-changes

[12:42:15.0000] <TabAtkins>
zcorpan: Yeah, I'm just worrying about merge conflicts, though I guess that can be handled later.

[12:42:26.0000] <TabAtkins>
There won't be any conflict with the initial push.

[12:42:30.0000] <TabAtkins>
So yeah, do what zcorpan says.

[12:43:51.0000] <Hixie>
k

[12:44:02.0000] <Hixie>
/me wonders what his username is

[12:44:14.0000] <TabAtkins>
Is it asking for that?

[12:44:21.0000] <TabAtkins>
It's your github username/pw.

[12:44:21.0000] <zcorpan>
(if you want to make more commits to the same PR later, you can just checkout that branch and make your change, git add <file>; git commit -m "..."; git push )

[12:45:05.0000] <zcorpan>
(to fix review comments or rebase etc)

[12:45:22.0000] <Hixie>
hm

[12:45:27.0000] <Hixie>
/me tries to log in via the web site

[12:45:33.0000] <Hixie>
i thought i knew my credentials...

[12:46:21.0000] <zcorpan>
Hixie: did you clone with https: URL?

[12:46:35.0000] <Hixie>
"The requested URL returned error: 403 while accessing https://github.com/html5lib/html5lib-tests/info/refs"

[12:46:38.0000] <Hixie>
so i guess yes?

[12:46:44.0000] <Domenic>
if you have two-factor auth on you get screwed and have to generate a new per-machine password

[12:47:01.0000] <Hixie>
looks like chrome knows my password

[12:47:06.0000] <Domenic>
good old chrome

[12:47:07.0000] <Hixie>
now i just need to get chrome to tell it to me :-)

[12:47:20.0000] <TabAtkins>
That's in your settings page.

[12:47:46.0000] <Hixie>
yeah, chrome i know how to use. :-P

[12:47:52.0000] <Hixie>
ok well it's what i thought it was

[12:47:53.0000] <Hixie>
weird

[12:48:36.0000] <Hixie>
wtf

[12:49:15.0000] <Hixie>
no two factor auth...

[12:49:24.0000] <TabAtkins>
Oooh!

[12:49:40.0000] <TabAtkins>
You may have used your keys, and it's asking for your key password.

[12:49:45.0000] <TabAtkins>
Though, if it's asking for username, that's not right.

[12:49:49.0000] <Hixie>
it's asking for my username first, yeah...

[12:50:06.0000] <TabAtkins>
Oh wait, that might still be right.

[12:50:07.0000] <Hixie>
my .gitconfig has different information

[12:50:10.0000] <Hixie>
i wonder if that's the problem

[12:50:20.0000] <TabAtkins>
Maybe your key password for whatever key you gave to github?

[12:50:22.0000] <Hixie>
TabAtkins: i have no ssh keys set up

[12:50:29.0000] <TabAtkins>
Okay, then never mind that.

[12:50:36.0000] <Hixie>
though maybe i should just do that

[12:51:04.0000] <TabAtkins>
It means no un/pw, so that's what I do.

[12:52:26.0000] <Hixie>
yeah

[12:52:26.0000] <Hixie>
ok done

[12:52:33.0000] <Hixie>
let's try git push again

[12:52:41.0000] <Hixie>
still asking for username

[12:52:42.0000] <Hixie>
wtf

[12:54:06.0000] <Hixie>
https://help.github.com/articles/https-cloning-errors is unhelpful...

[12:55:25.0000] <Hixie>
i've just discovered you can use svn with github

[12:55:29.0000] <Hixie>
that's rather tempting

[12:55:55.0000] <TabAtkins>
Haha, you'll have to learn git someday!

[12:56:07.0000] <caitp>
I think it just uses git-svn behind the scenes, but it's probably not as tempting as you think

[12:56:12.0000] <TabAtkins>
(Though, learning GitHub is somewhat harder than just learning git.)

[12:56:20.0000] <Hixie>
ok seriously, why is github not letting me login

[12:56:23.0000] <Hixie>
i can ssh to github fine

[12:57:07.0000] <TabAtkins>
annevk: Which spec was it that I offered to Bikeshed for you? Was it DOM?

[12:58:08.0000] <caitp>
Hixie: which remote url are you using? if its your own repository, and you aren't using the secure url, you should be able to login with your github user/pass

[12:58:14.0000] <Hixie>
https://help.github.com/articles/why-is-git-always-asking-for-my-password seems likely to be what's going on, but i don't understand the words on that page

[12:58:30.0000] <caitp>
if it's the secure url, you should associate a key with your account and make sure git knows where to find it

[12:58:36.0000] <Hixie>
caitp: i'm trying to push to https://github.com/html5lib/html5lib-tests

[12:58:47.0000] <Hixie>
caitp: and i have the key set up such that ssh -T git⊙gc works fine

[12:58:50.0000] <caitp>
if it's not an account you have write access to, you're out of luck regardless

[12:58:51.0000] <jamesr_>
you can push to the ssh url if you want to use ssh key to auth

[12:59:18.0000] <caitp>
i'm guessing you have write access to html5lib

[12:59:36.0000] <caitp>
actually, I don't see you in the members list for that org

[12:59:41.0000] <Hixie>
caitp: i'm just trying to upload a pull request, presumably i don't need any rights to do that

[12:59:43.0000] <TabAtkins>
Oh yeah, that's probably it.

[12:59:58.0000] <caitp>
for a pull request, you'd upload to your own account

[13:00:00.0000] <TabAtkins>
To do a PR without commit right, you need to fork the repo to your own account.

[13:00:09.0000] <TabAtkins>
Then you push to your fork, and issue a PR from that.

[13:00:17.0000] <Hixie>
(seriously, what was wrong with the way we did it five years ago)

[13:00:20.0000] <SamB>
TabAtkins: is there a quick way to delete all the branches then?

[13:00:20.0000] <TabAtkins>
The main account can then accept the PR to integrate the change into themselves.

[13:00:23.0000] <caitp>
defunkt's `hub` tool makes this workflow pretty nice

[13:00:29.0000] <caitp>
so you might want to look into that

[13:00:33.0000] <Hixie>
so...

[13:00:34.0000] <TabAtkins>
Hixie: If you have commit rights its easier.

[13:00:36.0000] <Hixie>
how do i do that

[13:00:42.0000] <Hixie>
i thought i had already done my own fork

[13:00:46.0000] <TabAtkins>
Go into GitHub, and click the "fork" button.

[13:00:49.0000] <Hixie>
isn't that the whole point of git

[13:00:52.0000] <TabAtkins>
Then we can change your remote.

[13:00:55.0000] <Domenic>
TabAtkins: what metadata can I use to get something like the headers on http://fetch.spec.whatwg.org/ et al?

[13:00:58.0000] <TabAtkins>
And push your branches there instead.

[13:01:02.0000] <caitp>
cloning and forking are distinct

[13:01:24.0000] <TabAtkins>
Domenic: We don't have WHATWG boilerplate yet, but you can add that yourself really easily.

[13:01:37.0000] <Domenic>
TabAtkins: sounds good, will do later.

[13:01:40.0000] <TabAtkins>
Hixie: "forking" is a GH concept, not a git one.

[13:01:52.0000] <Hixie>
ok https://github.com/Hixie/html5lib-tests exists, whatever that is

[13:02:05.0000] <TabAtkins>
Hixie: All of these instructions are *way* more complicated than they have to be, because you're working within the GH model, but didn't *start* that way.

[13:02:24.0000] <Hixie>
TabAtkins: i'd be happy to work in some other model if it's simpler

[13:02:41.0000] <TabAtkins>
Hixie: Easiest model is to ask gsnedders to give you commit rights, and just push your changes. ^_^&

[13:02:48.0000] <Hixie>
i just want to have gsnedders review my changes and then have them committed to the repo

[13:02:54.0000] <TabAtkins>
Then you can set up cleanly with the GH model.

[13:03:23.0000] <TabAtkins>
In the GH model, you do all your work in your own fork, and throw PRs at the main repo.

[13:03:57.0000] <caitp>
the GH model is typically, you have your organization with a canonical repository, which is considered upstream, you have your own fork on your own account, and you have your local clones on however many machines

[13:04:25.0000] <Hixie>
TabAtkins: so in the GH model, you have a local repo, and then you push to a GH repo, and then you push from there to another GH repo?

[13:04:37.0000] <Hixie>
man

[13:04:37.0000] <caitp>
so all of your pushes should be against your fork on your github account, and you can submit those pushes for review in the canonical repository, it's pretty elegant

[13:04:39.0000] <Hixie>
again

[13:04:43.0000] <TabAtkins>
You push from your local repo to your fork, then PR over to the main fork, yeah.

[13:04:44.0000] <Hixie>
life was so much easier back in the subversion days

[13:04:46.0000] <Hixie>
but whatever

[13:04:53.0000] <TabAtkins>
Hixie: Depends on what you mean by "easier".

[13:05:06.0000] <Hixie>
is there some way to change my local working copy to point to https://github.com/Hixie/html5lib-tests instead?

[13:05:08.0000] <TabAtkins>
The GH model is designed for easy collaboration with strangers without allowing them to stomp on everything.

[13:05:15.0000] <TabAtkins>
And it works, once you know how to use it.

[13:05:32.0000] <caitp>
this model really grows on you, I am looking forward to chromium fully switching to git so that it's less crazy

[13:05:48.0000] <TabAtkins>
Yes, `git remote set-url origin <url-here>`

[13:05:57.0000] <Hixie>
caitp: so far this model has only grown on me like a disgusting fungus :-P

[13:06:00.0000] <TabAtkins>
You'll have to do this for each branch, I think?  I'm not super-sure, haven't done that before.

[13:06:19.0000] <TabAtkins>
Hixie: You're just experiencing change aversion due to trying to apply your SVG mental model on top of git.

[13:06:28.0000] <TabAtkins>
They're close, but not exact, so the friction feels like errors.

[13:06:34.0000] <Hixie>
no, i'm pretty sure it's not change aversion :-)

[13:06:39.0000] <TabAtkins>
Adn then having to deal with GH's structure on top of it is makign it worse.

[13:06:54.0000] <TabAtkins>
Having used both SVG and git extensively, I know it's not just "git is fucked up and hard". ^_^

[13:07:16.0000] <TabAtkins>
It's a little bit more complex, but most of the time you don't see that, and the complexity is actually quite worthwhile.

[13:07:42.0000] <TabAtkins>
Hixie: You may be able to make changes directly to .git/config

[13:08:49.0000] <Hixie>
so .git/config has no mention of the old url at all anymore

[13:08:52.0000] <caitp>
the basics are super simple, and intermediate stuff like complicated rebasing and refactoring stuff across multiple commits is actually really straight forward, but I guess I should focus on meetings and do less git-evangelism

[13:08:56.0000] <Hixie>
but i'm still getting prompted for my username

[13:08:58.0000] <Domenic>
TabAtkins: what if I have <dfn>Chunks</dfn> and want to (auto?) link to it from the word "chunk"

[13:09:26.0000] <TabAtkins>
Domenic: That happens automatically.

[13:09:37.0000] <Domenic>
such magic :O

[13:09:40.0000] <TabAtkins>
When it doesn't, use the title attribute to provide alternate text.

[13:09:57.0000] <Domenic>
Is there any difference between <a> and '?

[13:10:04.0000] <jgraham>
Hixie: We can make this easier

[13:10:07.0000] <TabAtkins>
(Bikeshed automatically accounts for common plurals, possessives, and -ing for both definitions and auotlinks.)

[13:10:21.0000] <TabAtkins>
Domenic: Big diff. Single quotes are for CSS property autolinks.

[13:10:23.0000] <jgraham>
Hixie: The GitHub model is broken for cases like this

[13:10:28.0000] <TabAtkins>
<a> by itself is a dfn autolink.

[13:10:29.0000] <Domenic>
ah k

[13:10:33.0000] <TabAtkins>
That is, a definition of type "dfn".

[13:10:38.0000] <TabAtkins>
A normal term, in other words.

[13:10:39.0000] <jgraham>
You should push to a branch of the main repo

[13:10:53.0000] <jgraham>
Then gsnedders or whoever can make pushes to fix your commits if needed

[13:11:18.0000] <TabAtkins>
jgraham: He just needs commit right for that, which he currently doesn't have.

[13:11:59.0000] <jgraham>
TabAtkins: That seems like a solvable problem

[13:12:09.0000] <TabAtkins>
That's what I said. ^_^

[13:12:58.0000] <Hixie>
ok, i've changed my password and now it lets me use that to push

[13:13:00.0000] <jgraham>
TabAtkins, Hixie: OK, now you have push access

[13:13:01.0000] <Hixie>
still isn't using ssh

[13:13:03.0000] <Hixie>
but whatever

[13:13:15.0000] <Hixie>
jgraham: ah

[13:13:19.0000] <TabAtkins>
Hixie: Okay, so just pushing to the main repo should be good now.

[13:13:25.0000] <Domenic>
General question (not Bikeshed specific): when should I use a normative vs. informative reference?

[13:13:38.0000] <Hixie>
does "push" affect my local repo at all?

[13:13:45.0000] <Hixie>
or can i just change the remote url and push again

[13:13:46.0000] <TabAtkins>
Domenic: Will a change in the reference cause your spec to need to change? If so, normative.

[13:13:46.0000] <Domenic>
In this case I am using the reference in an example, so it is presumably informative, but curious what the dividing line is.

[13:13:56.0000] <TabAtkins>
Hixie: Don't bother with remote urls now.

[13:13:58.0000] <Domenic>
TabAtkins: nice, that's a pretty clear line. thanks.

[13:14:53.0000] <Hixie>
Domenic: normative reference means that implementations of your spec need to read and implement the other spec or your spec won't make sense

[13:14:59.0000] <TabAtkins>
Hixie: But no, a push does nothing to your local repo. It just copies commits from your history to the remote repo's history.

[13:15:08.0000] <Hixie>
Domenic: non-normative means that the other document could be deleted from the world, and your spec would be unaffected

[13:15:18.0000] <Hixie>
Domenic: but that readers might still want to see that other spec for context

[13:15:23.0000] <Hixie>
TabAtkins: k

[13:15:35.0000] <Domenic>
Thanks Hixie.

[13:15:58.0000] <TabAtkins>
Hixie: Just like how "add" just copies changes from your working area to your staging area, and "commit" just copies changes from your staging area to your history. ^_^

[13:16:42.0000] <Domenic>
TabAtkins: well, that was pretty darn easy; impressive tool.

[13:17:02.0000] <jgraham>
Hixie: You want to do something like git remote add github git⊙gc:html5lib/html5lib-tests.git; git push --set-upstream github HEAD:hixie/new_tests

[13:17:06.0000] <TabAtkins>
Starting from Anolis makes some things easy. It's also possible that your dfns aren't typed correctly yet. ^_^

[13:17:13.0000] <Domenic>
TabAtkins: what's the best way to get WHATWG boilerplate in? Pull request bikeshed, or can I have it take a boilerplate from external?

[13:17:15.0000] <TabAtkins>
I'll give it a lookover if you want.

[13:17:17.0000] <Hixie>
TabAtkins: there sure are a lot of different stages in the git/gh model

[13:17:32.0000] <Hixie>
what is whatwg boilerplate?

[13:17:34.0000] <TabAtkins>
Domenic: PR bikeshed - the /include directory has all the boilerplate files.

[13:17:42.0000] <Hixie>
there shouldn't be any whatwg boilerplate

[13:17:45.0000] <TabAtkins>
Just make new ones for whatever you need.

[13:17:53.0000] <TabAtkins>
Hixie: The entire header and footer are boilerplate.

[13:17:57.0000] <Domenic>
TabAtkins: Eek, that means I have to get it running locally on Windows... wheeee

[13:18:05.0000] <Hixie>
there's no standard header and footer for whatwg specs

[13:18:08.0000] <Hixie>
unless you mean the DOCTYPE

[13:18:18.0000] <TabAtkins>
You should make one. ^_^

[13:18:19.0000] <Domenic>
Hixie: "boilerplate" in this case includes <script> and <link> files

[13:18:26.0000] <TabAtkins>
But also, the Group can be as granular as needed.

[13:18:33.0000] <Hixie>
TabAtkins: no, i mean, there's no standard. it's whatever the spec writer wants.

[13:18:44.0000] <Hixie>
e.g. whatwg/html and whatwg/dom are quite different

[13:19:03.0000] <TabAtkins>
HTML's a special case.  Everyone else is mostly different just because of the lack of a standard.

[13:19:22.0000] <TabAtkins>
Crafting a stadnardized header would be fine for most of them.

[13:19:34.0000] <Hixie>
noooooo

[13:19:37.0000] <Hixie>
no bureaucracy

[13:19:39.0000] <Hixie>
no boilerplate

[13:19:54.0000] <Hixie>
the spec author should be responsible for all spec content

[13:20:07.0000] <TabAtkins>
It's nothing to do with "bureacracy".

[13:20:16.0000] <TabAtkins>
It's just that the header is pretty formulaic.

[13:20:21.0000] <Hixie>
it shouldn't be

[13:20:22.0000] <TabAtkins>
And so typing it all out yourself is dumb.

[13:20:26.0000] <Hixie>
it should be compelling

[13:20:31.0000] <Hixie>
it should draw the reader in

[13:20:38.0000] <Hixie>
if it's formulaic then we're doing something wrong

[13:20:48.0000] <Hixie>
different specs have different needs

[13:21:59.0000] <TabAtkins>
Those needs are much less unique and special than I think you're indicating.  Case in point: most WHATWG specs have nearly identical-looking headers.

[13:22:07.0000] <Hixie>
and they all suck

[13:22:12.0000] <TabAtkins>
And I'll bet that whenever Anne makes a new one, he copy/pastes from an old one.

[13:22:19.0000] <Hixie>
seriously they're ugly headers right now

[13:22:29.0000] <Hixie>
we shouldn't create new specs that look like that

[13:23:08.0000] <TabAtkins>
Then figure out what they *should* look like, and standardize on that.

[13:23:37.0000] <Hixie>
it will surely change regularly

[13:23:44.0000] <Hixie>
as different spec authors experiment

[13:23:49.0000] <TabAtkins>
Then change it regularly.

[13:23:58.0000] <Hixie>
there shouldn't be an "it"

[13:23:59.0000] <TabAtkins>
This is far easier to do when it's generated by the tool.

[13:24:53.0000] <Hixie>
it should just be part of the spec source

[13:24:58.0000] <Hixie>
there's nothing to generate

[13:25:25.0000] <TabAtkins>
Welp, most of it is repetitive garbage no matter what you do, so I guess I totally disagree.

[13:26:38.0000] <Hixie>
there shouldn't be anything repetitive about it

[13:26:43.0000] <Hixie>
if it's repetitive it shouldn't be in the spec

[13:27:05.0000] <Domenic>
I *would* be happier right now if I could just port over the existing parts of the spec source, and have Bikeshed only touch the main body of the spec... there's like 15 lines that I'm going to spend the next few hours duplicating

[13:28:01.0000] <TabAtkins>
Domenic: If you do that, you'll lose the auto-genned index, refs, issues index, etc.

[13:28:15.0000] <TabAtkins>
But you can trick Bikeshed into not doing the header generation by including a doctype.

[13:28:28.0000] <TabAtkins>
If the first line is the html doctype, Bikeshed assumes you're providing your own header.

[13:28:49.0000] <TabAtkins>
Hm, I can't remember if it still includes the footer in that case.  Lemme see...

[13:29:24.0000] <Hixie>
um, so i broke something with this git stuff i'm doing

[13:29:31.0000] <TabAtkins>
Ah, it does not.

[13:29:33.0000] <Hixie>
i tried to be clever and use git add -p to add just one part of a change

[13:29:49.0000] <Hixie>
and now it's saying "error: You have local changes to 'tree-construction/template.dat'; cannot switch branches" when i try to checkout master

[13:30:08.0000] <SamB>
Hixie: "git stash" now

[13:30:10.0000] <TabAtkins>
Hixie: You need to commit them first.

[13:30:16.0000] <SamB>
then "git stash pop" after you switch back

[13:30:22.0000] <Hixie>
i did commit them

[13:30:29.0000] <Hixie>
i'm following the same steps you gave before :-)

[13:30:31.0000] <TabAtkins>
Oh, but they're to the file that's also commited.

[13:30:34.0000] <Hixie>
git checkout -b BRANCHNAME; git add FILES; git commit -m"MESSAGE"; git push origin -u BRANCHNAME; git checkout master

[13:30:35.0000] <TabAtkins>
Okay, yeah, stash.

[13:30:51.0000] <Hixie>
what does git stash pop do?

[13:30:52.0000] <TabAtkins>
`git stash` now will save and undo all the remaining uncommitted local changes.

[13:30:57.0000] <TabAtkins>
pop throws them away, don't do that.

[13:31:00.0000] <Hixie>
it says "nothing to apply"

[13:31:04.0000] <SamB>
hmm

[13:31:14.0000] <SamB>
I thought pop applied them first, THEN threw them away if that worked

[13:31:42.0000] <Hixie>
how do i see my "local changes"?

[13:31:59.0000] <Hixie>
and what are they local to?

[13:32:07.0000] <TabAtkins>
So, back to the visual guide. ^_^

[13:32:10.0000] <Hixie>
since there's three levels just in my own repo...

[13:32:16.0000] <TabAtkins>
working directory is the current state of your files.

[13:32:19.0000] <TabAtkins>
What you actually see.

[13:32:26.0000] <SamB>
Hixie: once committed, they don't count as "local" according to git

[13:32:28.0000] <TabAtkins>
staging area is what's getting ready for a commit.

[13:32:48.0000] <Hixie>
so which are the local changes? staged or working?

[13:32:53.0000] <TabAtkins>
(This exists for a few reasons, one of which is so that `git add -p` can exist and make sense)

[13:33:01.0000] <TabAtkins>
It usually means "not committed".

[13:33:02.0000] <Hixie>
git diff looks at working vs current comitted state of the branch?

[13:33:07.0000] <jgraham>
Hixie: git status shows the files with changes

[13:33:14.0000] <TabAtkins>
git diff looks at lots of things depending on the args.

[13:33:17.0000] <TabAtkins>
Visual guide explains that.

[13:33:19.0000] <jgraham>
Split into staged / unstaged / untracked

[13:33:21.0000] <TabAtkins>
Better than I'd be able to.

[13:33:32.0000] <jgraham>
git diff shows the unstaged changes

[13:33:43.0000] <jgraham>
git diff --staged shows the staged changes

[13:33:54.0000] <Hixie>
git diff --staged is empty

[13:34:09.0000] <Hixie>
git status shows everything under "On branch newtemplatetest" "Changed but not updated"

[13:34:36.0000] <Hixie>
presumably this is because i commited just one bit of one of these changed files

[13:34:47.0000] <Hixie>
and it doesn't know how to throw just that change away when going back to the earlier branch

[13:34:57.0000] <Hixie>
while keeping my other changes

[13:35:15.0000] <Hixie>
so i guess i do git diff > foo.patch; git reset; patch < foo.patch ?

[13:35:18.0000] <jgraham>
Hixie: Can you pastebin the output somewehre

[13:35:22.0000] <Hixie>
output of what?

[13:35:31.0000] <jgraham>
No, if you're using patch files you're doing it wrong

[13:35:36.0000] <jgraham>
Hixie: git status

[13:36:00.0000] <Hixie>
damowmow.com/temp/git-output

[13:36:04.0000] <Hixie>
http://damowmow.com/temp/git-output

[13:36:20.0000] <Hixie>
$ git checkout master

[13:36:21.0000] <Hixie>
error: You have local changes to 'tree-construction/template.dat'; cannot switch branches.

[13:36:35.0000] <Hixie>
template.dat is the file for which i commited just one chunk

[13:36:43.0000] <Hixie>
on the current branch

[13:36:55.0000] <jgraham>
Hixie: Just to make sure I know, what are you trying to achieve

[13:37:04.0000] <jgraham>
The scrollback was quite hard to follow

[13:37:11.0000] <Hixie>
trying to get gsnedders a bunch of patches

[13:37:16.0000] <Hixie>
one for each related change

[13:37:24.0000] <Hixie>
(brb getting food, back in 5 min)

[13:37:38.0000] <jgraham>
OK, and you have committed one patch and want to make more

[13:39:11.0000] <TabAtkins>
jgraham: And specifically, he's commited part of a changed file with add -p, and wants the rest of the file's changes in another branch.

[13:39:18.0000] <jgraham>
OK

[13:40:39.0000] <jgraham>
Hixie: So the advice from everyone about git stash was correct

[13:41:36.0000] <jgraham>
git stash basically commits all the changes in your working directory to a temporary branch

[13:42:02.0000] <jgraham>
These temporary areas are notionally arranged as a stack

[13:42:25.0000] <jgraham>
so git stash; git checkout master; git stash pop

[13:42:26.0000] <annevk>
TabAtkins: yeah, DOM I think

[13:42:31.0000] <Hixie>
back

[13:43:13.0000] <Hixie>
jgraham: ok cool, thanks

[13:43:20.0000] <Hixie>
jgraham: that's basically the same as what i said about with diff and patch

[13:43:23.0000] <annevk>
Domenic: hmm "tee", push x to stream, read from stream (and read until empty or read current buffer)

[13:45:04.0000] <annevk>
Domenic: if stream is closed/open I guess

[13:45:15.0000] <annevk>
(I currently use "is fully read" for closed)

[13:47:20.0000] <Hixie>
if i added something to my staging area in error, how do i remove it?

[13:48:24.0000] <Hixie>
git reset?

[13:49:04.0000] <Hixie>
yeah that seems to be it

[13:49:17.0000] <Hixie>
how about a way to diff the working directory against the staged stuff?

[13:49:22.0000] <Hixie>
so i can tell what i haven't staged?

[13:49:35.0000] <TabAtkins>
Hixie: VISUAL GUIDE

[13:49:48.0000] <TabAtkins>
It has all of these questions in beautiful diagram form.

[13:50:20.0000] <Hixie>
it claims "git diff" does what i want

[13:50:31.0000] <Hixie>
but it's not clear that that is true

[13:50:43.0000] <TabAtkins>
It hasn't lied to me yet, so shrug.

[13:51:08.0000] <Hixie>
k

[13:51:25.0000] <Hixie>
part of the problem is that things that seem symmetric have entirely different names

[13:51:30.0000] <Hixie>
e.g. look at the diff diagram on that page

[13:51:41.0000] <TabAtkins>
Yes.

[13:51:45.0000] <Hixie>
diff maint, diff HEAD, diff, diff --cached, wtf

[13:51:57.0000] <Hixie>
it's all over the place

[13:52:27.0000] <TabAtkins>
Note that "maint" is just a branch name there, not a command.

[13:52:40.0000] <TabAtkins>
And HEAD is a magic commit name that always refers to the tip of your branch.

[13:53:00.0000] <Hixie>
yeah

[13:53:32.0000] <TabAtkins>
So `diff` is WD against SA, `diff <commit/branch/etc>` is WD against history, `diff <commit/etc> <commit/etc>` is commit against commit.

[13:53:43.0000] <TabAtkins>
The --cached one is weird, but it's also rare to have to diff staging area against history.

[13:53:58.0000] <Hixie>
basically i think git suffers from two fundamental problems (both made orders of magnitude worse by github): it's over-engineered, and it has a horrible inconsistent ui

[13:54:36.0000] <TabAtkins>
Ignore the GH parts right now.  They have a simple and consistent model that is terribly confusing if you come at it piecemeal and trying to slowly adapt your working process to it.

[13:54:50.0000] <TabAtkins>
Once you actually learn it and use it proper, it's fairly easy and simple.

[13:55:26.0000] <Hixie>
/me accidentally types git checkout -p foo instead of -b foo and hopes that didn't break anything

[13:55:52.0000] <TabAtkins>
I can't make the same argument as strongly for git itself, because it does have some weird edges, but its core is pretty simple and elegant.

[13:56:08.0000] <TabAtkins>
Though again, piecemeal changing your process from SVG to git is confusing, and it burned me too.

[13:56:19.0000] <TabAtkins>
Once I found the visual guide everything made way more sense.

[13:56:32.0000] <Hixie>
i'm not trying to change my process at all

[13:56:41.0000] <Hixie>
i'm just trying to commit this one set of changes

[13:56:43.0000] <Hixie>
:-)

[13:56:54.0000] <TabAtkins>
Your process being "make changes, commit them". ^_^

[13:57:27.0000] <TabAtkins>
Domenic: Point me to a spec that you want to use the heading portion of, and I'll make boilerplates for you to use.

[13:57:57.0000] <TabAtkins>
Domenic: If you and annevk can agree on what heading stuff to use, all the better.

[13:58:45.0000] <TabAtkins>
Domenic: Also, I'm happy to review your bikeshedded file, to make sure you're using the right dfn types (so Shepherd will be happy when it starts parsing your spec).

[13:59:06.0000] <Hixie>
jgraham: (btw, thanks for setting me up with access)

[13:59:22.0000] <Domenic>
TabAtkins: excellent. i am very close to being done with a bikeshed draft that repros my current stuff, will ping you in 10 minutes probably

[13:59:28.0000] <TabAtkins>
kk

[14:01:37.0000] <TabAtkins>
annevk: Is "dom-core.html" an important filename to maintain for the generated file?

[14:01:44.0000] <TabAtkins>
Totally fine if it is, just making sure what you want.

[14:02:25.0000] <Hixie>
TabAtkins: ok i've committed everything

[14:02:36.0000] <Hixie>
TabAtkins: is there somewhere i can review these changes?

[14:02:45.0000] <Hixie>
pushed everything ,rather

[14:02:47.0000] <TabAtkins>
In the github UI, you can change what branch you're looking at.

[14:03:09.0000] <TabAtkins>
And if you need to make changes, `git checkout my-branch-name`, make changes, commit, push.

[14:04:47.0000] <Hixie>
then i hit "create pull request"?

[14:05:26.0000] <TabAtkins>
PRing from a branch to another branch in the same repo is fiddly.

[14:05:39.0000] <TabAtkins>
Better to just ping gsnedders about it and let him deal with it.

[14:05:46.0000] <TabAtkins>
He can pull the branch and merge it himself.

[14:06:07.0000] <Hixie>
ah ok these are all publicly viewable already? good

[14:06:12.0000] <Hixie>
https://github.com/html5lib/html5lib-tests/branches

[14:06:35.0000] <TabAtkins>
Yeah.

[14:06:35.0000] <Hixie>
gsnedders: ok dude, https://github.com/html5lib/html5lib-tests/branches

[14:06:41.0000] <Hixie>
TabAtkins: thanks so much for the help

[14:06:49.0000] <Hixie>
and to everyone else also

[14:06:55.0000] <Hixie>
but mainly tab :-)

[14:06:56.0000] <TabAtkins>
Now in the *future*, this can be much easier.

[14:07:02.0000] <TabAtkins>
Because you can do it right from the start.

[14:07:11.0000] <TabAtkins>
Clone your fork instead.

[14:07:21.0000] <Domenic>
heh, Python doesn't like Unicode

[14:07:22.0000] <TabAtkins>
Then make branches whenever you want to submit something.

[14:07:38.0000] <TabAtkins>
*Then* the "create PR" button in GitHub is easy and does the right thing.

[14:07:51.0000] <TabAtkins>
Domenic: Bikeshed errors? Plz let me know, everything should be clean by now.

[14:11:40.0000] <TabAtkins>
annevk: Would it annoy you if I converted your indentation to tabs?

[14:11:54.0000] <jgraham>
TabAtkins: No it isn't

[14:12:10.0000] <TabAtkins>
jgraham: What isn't?

[14:12:25.0000] <jgraham>
Fiddly to create PRs from branches in the same repo

[14:12:36.0000] <jgraham>
There is like a big green button for that

[14:13:00.0000] <jgraham>
Working from a fork is *much* harder

[14:13:13.0000] <jgraham>
Because there are 3 repos to worry about rather than two

[14:13:23.0000] <jgraham>
and it's much harder for anyone else to help you out

[14:13:29.0000] <jgraham>
because they can't push commits

[14:13:57.0000] <TabAtkins>
jgraham: In my experience with picture-element, it was really annoying.

[14:14:04.0000] <TabAtkins>
But maybe that was because we used a non-master main branch.

[14:14:11.0000] <jgraham>
Perhaps

[14:14:22.0000] <TabAtkins>
The GH UI was just super-unfriendly for this.

[14:14:37.0000] <TabAtkins>
And defaulted to doing some crazy shit when trying to specify what branch you were PRing against.

[14:14:43.0000] <jgraham>
In all the situations where I use GH I vastly prefer working with one upstream rather than a fork and a master

[14:14:52.0000] <jgraham>
s/master/origin/

[14:15:24.0000] <Hixie>
i have no experience of this, so my opinion is worthless, but what jgraham is saying makes more sense to me. :-)

[14:15:33.0000] <jgraham>
TabAtkins: For example https://github.com/html5lib/html5lib-tests/tree/newtemplatetest seems to be one of Hixie's branches

[14:15:52.0000] <jgraham>
and the green button to the left of the branch name creates a PR from that branch against master

[14:16:03.0000] <TabAtkins>
I've worked with several repos in the "fork and PR" model, and it's always worked well for me.

[14:16:17.0000] <TabAtkins>
jgraham: Okay, so my difficulty may have mainly been from the non-master main branch.

[14:16:21.0000] <TabAtkins>
Stupid gh-pages bullshit.

[14:16:57.0000] <TabAtkins>
In Anolis, does <span> by itself do anything?

[14:17:01.0000] <jgraham>
If you then want to make a PR against another branch, you can do it using the "pick a branch

[14:17:10.0000] <jgraham>
" UI after you select "create pull request"

[14:17:22.0000] <jgraham>
/me wished he knew that a few hours ago

[14:17:43.0000] <TabAtkins>
jgraham: Yeah, that UI *completely bugged out* when I last used it in the picture-element repo.

[14:18:20.0000] <Domenic>
TabAtkins: https://github.com/whatwg/streams/tree/bikeshed

[14:18:34.0000] <Domenic>
index.html is the old Anolis source; output.html is the bikeshed output.

[14:18:44.0000] <Domenic>
In the future will have Travis run bikeshed on gh-pages branch and not commit the output at all.

[14:18:55.0000] <TabAtkins>
Okay.

[14:19:22.0000] <Domenic>
Haven't started using implicit paragraphs yet but I think I got most other things like references and definitions updated.

[14:19:55.0000] <Domenic>
https://rawgit.com/whatwg/streams/bikeshed/output.html is the rendered output

[14:20:01.0000] <TabAtkins>
Domenic: OH man, use them. They're so good!

[14:20:07.0000] <TabAtkins>
Also: Markdown headings should work now.

[14:20:14.0000] <Domenic>
Ooooh

[14:20:17.0000] <TabAtkins>
But they're still technically experimental.

[14:20:28.0000] <TabAtkins>
Have I updated the docs yet?  Hm...

[14:20:33.0000] <Domenic>
Can I use them for no-num no-toc or similar?

[14:20:53.0000] <Hixie>
<span> is just a cross-ref source (<a>)

[14:20:56.0000] <Hixie>
in anolis

[14:20:57.0000] <TabAtkins>
I have not.

[14:21:04.0000] <TabAtkins>
Domenic: Not quite yet.

[14:21:15.0000] <TabAtkins>
Domenic: I have a shorthand for adding an id, but not for marking them no-num or no-toc.

[14:21:24.0000] <TabAtkins>
Hixie: Thanks.

[14:22:45.0000] <Domenic>
TabAtkins: any other markdown features to know about? E.g. links?

[14:22:54.0000] <TabAtkins>
Domenic: No inline markdown yet.

[14:23:01.0000] <TabAtkins>
Still slightly unsure if I want to do them or not.

[14:23:06.0000] <Domenic>
ya

[14:23:11.0000] <TabAtkins>
But code blocks work.

[14:23:15.0000] <TabAtkins>
And I'm working on lists.

[14:23:19.0000] <Domenic>
oooh

[14:23:34.0000] <Domenic>
fenced code blocks? dare i ask, with syntax highlighting??

[14:23:34.0000] <TabAtkins>
Plan to add syntax highlighting to code blocks a la gfm

[14:24:10.0000] <Domenic>
yessss will make these examples so much better

[14:24:14.0000] <TabAtkins>
Oh, I haven't added the code block support quite yet!

[14:24:23.0000] <TabAtkins>
I'll do that today, it's easy.

[14:25:57.0000] <Hixie>
ok so now that i have an html parser i need to figure out what features i need in my pipeline

[14:26:04.0000] <Hixie>
TabAtkins: what does bikeshed do that's critical?

[14:26:16.0000] <TabAtkins>
Hixie: Biggest one is cross-spec cross-references.

[14:26:22.0000] <Hixie>
ok, got that one

[14:26:23.0000] <Hixie>
outline, also

[14:26:27.0000] <TabAtkins>
Totally automagic unless there's a conflict.

[14:26:42.0000] <Hixie>
not so worried about the magic aspect, i like being explicit

[14:26:47.0000] <TabAtkins>
Bleh, okay.

[14:27:06.0000] <TabAtkins>
Railroad diagrams seem to be a lot of people's favorite feature. ^_^

[14:27:11.0000] <Hixie>
i also need spec splitting, and back-references from <dfn>

[14:27:24.0000] <TabAtkins>
IDL auto-markup, too.

[14:27:41.0000] <TabAtkins>
(That is, inserting <dfn> or <a>, as appropriate, on all the things in an IDL block.)

[14:28:04.0000] <Hixie>
interesting

[14:28:14.0000] <Hixie>
i'll just stick to using <span>s for now

[14:28:24.0000] <Hixie>
i need to get this up and running before i start making it clever :-)

[14:28:51.0000] <TabAtkins>
Yeah, those were all nice-to-haves that I added later.

[14:29:02.0000] <TabAtkins>
cross-spec refs were the actual reason I started Bikeshed.

[14:29:23.0000] <Hixie>
/me adds that to the "v2" list

[14:44:55.0000] <Domenic>
TabAtkins: When I do "<dfn>Some term</dfn> means ..." at the start of a paragraph, it gets capitalized in the index, which seems silly.

[14:45:24.0000] <TabAtkins>
Domenic: You can manually specify the linking test with title='', just like Anolis.

[14:45:48.0000] <TabAtkins>
I don't want to tweak any capitalization normally, as that will often be wrong.

[14:46:39.0000] <Domenic>
niiice

[14:51:10.0000] <TabAtkins>
annevk: Is your definition of "throw" supposed to be the same as WebIDL's, or something different?

[14:56:39.0000] <TabAtkins>
annevk: Hmmmm, the version of DOM on GitHub is different from the version on whatwg.org.  Where's the canonical source?

[14:56:58.0000] <TabAtkins>
/me is going to stop working on Bikeshedding this until figuring this out, in case he has to redo anything.

[15:09:29.0000] <TabAtkins>
Domenic: So it sounds like you were encountering unicode errors in Bikeshed?

[15:09:51.0000] <TabAtkins>
That's very strange, because unicode *definitely* works when run on linux and mac.

[15:10:02.0000] <TabAtkins>
So there's something wrong with your setup on Windows that is screwing things up.

[15:11:40.0000] <Domenic>
TabAtkins: I was actually using just the curl version

[15:11:45.0000] <Domenic>
albeit, via Windows curl...

[15:11:57.0000] <TabAtkins>
There's something getting fucked up in the middle, then.

[15:11:59.0000] <TabAtkins>
Hmmmm

[15:12:30.0000] <TabAtkins>
(The apostrophe thing is because Bikeshed automagically converts apostrophes to curly aposes when it can.)

[15:12:31.0000] <Domenic>
Totally willing to believe it's Windows' fault

[15:12:42.0000] <Domenic>
well, it shouldn't do that inside comments ;)

[15:13:06.0000] <TabAtkins>
Possibly, but it's done as a source-level hack, before parsing occurs.

[15:13:12.0000] <TabAtkins>
And comments are stripped out, too, so shrug.

[15:38:13.0000] <zewt>
close-quote-as-apostrophe is terrible

[15:38:39.0000] <TabAtkins>
Tell that to people who care about typography.

[15:39:08.0000] <zewt>
quotes are quotes, apostrophes are apostrophes, and ' is apostrophe

[15:39:17.0000] <TabAtkins>
Or a quote.

[15:39:21.0000] <TabAtkins>
You know, depending.

[15:39:43.0000] <zewt>
close-single-quote is a quote; using it as an apostrophe is just making *it* ambiguous too

[15:41:56.0000] <zewt>
it's absurd that unicode introduced a set of characters that are unambiguously quotes, then proceeded to recommend that everyone use them as ... apostrophes

[15:42:02.0000] <TabAtkins>
Unicode defines it as the preferred form.

[15:42:06.0000] <TabAtkins>
So shrug.

[15:46:40.0000] <Domenic>
Hixie: bad security cert on https://resources.whatwg.org/logo-streams.svg ?

[15:47:06.0000] <TabAtkins>
If you follow the link, there's a server error anyway.

[15:47:47.0000] <Domenic>
i was too scared of the hax0rs

[15:48:22.0000] <Domenic>
My Travis auto-build is working pretty awesomely though

[15:48:40.0000] <Hixie>
Domenic: there's no cert at all, is there?

[15:49:00.0000] <Domenic>
Hixie: it says there's one issued to sni.dreamhost.com

[15:49:05.0000] <Hixie>
odd

[15:49:14.0000] <Hixie>
i'm surprised there's even an https server at that domain

[15:49:14.0000] <Domenic>
I kind of thought we fixed this somewhat recently and got resources working over https

[15:49:16.0000] <Hixie>
oh

[15:49:18.0000] <Hixie>
of course there is

[15:49:21.0000] <Hixie>
it's the same IP as whatwg.org

[15:49:35.0000] <Hixie>
we got a cert for www.whatwg.org for one year

[15:49:37.0000] <Domenic>
gtg grab food before kitchen closes, bbiab

[15:49:48.0000] <zewt>
missing intermediate CAs?

[15:49:58.0000] <Hixie>
but didn't get any other certs

[15:50:07.0000] <Hixie>
and i don't expect to renew the one in one year, either, given how much of a pain that was

[15:50:19.0000] <Hixie>
if anyone wants to take charge on this, be my guest :-)

[15:50:47.0000] <zewt>
it's pretty simple, but it's definitely lame to have to pay the SSL Tax, heh

[15:51:43.0000] <Hixie>
i found some free provider

[15:52:05.0000] <zewt>
the only free certificate providers i tried were a huge pain in the ass

[15:52:15.0000] <Hixie>
see above. :-)

[15:52:26.0000] <zewt>
but that's the fault of the shtity provider

[15:52:28.0000] <zewt>
also shitty

[15:53:26.0000] <zewt>
i think the one I tried wanted users to create client certificates to log in and didn't have passwords at all, which is a nice option but given the actual level of security certs provide, absurd to require

[15:54:14.0000] <Hixie>
yep, that's the one

[15:54:47.0000] <zewt>
yeah. better off just paying the $20 or whatever on a real provider

[15:55:05.0000] <Hixie>
send me the $20 and i'll get right on that :-)

[15:55:17.0000] <Hixie>
i'm already paying plenty to actually host the server

[15:55:26.0000] <Hixie>
that seems to me to have a higher benefit-per-dollar ratio

[15:56:11.0000] <zewt>
my SSL cert off of godaddy was $13/year for a 5-year

[15:56:36.0000] <zewt>
(single domain, not wildcard; those are the ones they want stupid money for)

[15:56:41.0000] <Hixie>
/me mumbles something about "." and ".." messing up his "is this directory empty" logic

[15:56:57.0000] <Hixie>
given how many domains whatwg.org has, it might be best to go wildcard

[15:57:39.0000] <zewt>
of course, the "xhr.spec.whatwg.org" hostname layout will screw you there, too

[15:57:50.0000] <zewt>
never use hostnames more than one deep

[15:58:04.0000] <Hixie>
it's not really clear to me why we care about encryption here anyway

[15:58:06.0000] <Hixie>
they're specs

[15:58:17.0000] <Hixie>
we _want_ people to read them

[15:58:36.0000] <Hixie>
and it's not like some encryption is going to stop people from inserting random crap into them

[15:58:41.0000] <Hixie>
the w3c already does that in broad daylight

[15:58:45.0000] <zewt>
heh godaddy wants $300/year for wildcard

[15:59:21.0000] <zewt>
(but they also want $70/year for regular--you have to search out coupon codes to get the real prices, I guess there's no avoiding some form of stupid crap)

[16:00:00.0000] <zewt>
which is probably why I renewed for 5 years, I probably found a good coupon (also it means I don't have to screw with it for a long time)

[16:00:52.0000] <zewt>
i suppose it's unlikely that somebody would bother initiating an MITM attack on whatwg.org that randomly changes the word "must" to "should"

[16:01:12.0000] <Hixie>
not only is it unlikely, it'd be pretty hilarious

[16:13:34.0000] <Hixie>
hm

[16:13:46.0000] <Hixie>
doing those commits and stuff seems to have removed some of the changes from my local copy

[16:13:57.0000] <Hixie>
TabAtkins: is there some way to fetch all the changes back somehow?

[16:14:08.0000] <Hixie>
i'm not sure i even know what question i should be asking

[16:14:30.0000] <TabAtkins>
Hixie: You probably ruined everything at some point, so... no.

[16:14:33.0000] <TabAtkins>
But... maybe.

[16:14:40.0000] <TabAtkins>
Probably no.

[16:14:56.0000] <Hixie>
it ssays i'm "ahead by two commits"

[16:15:01.0000] <Hixie>
is there some way to see what those are?

[16:15:11.0000] <Hixie>
("it" being sgit status)

[16:15:14.0000] <Hixie>
git

[16:15:22.0000] <TabAtkins>
That means you've got two commits more than your remote repo.

[16:15:37.0000] <jgraham>
git log @{u}..

[16:15:52.0000] <TabAtkins>
I have no idea what that means.

[16:15:53.0000] <jgraham>
@{u} is short for @{upstream}

[16:16:10.0000] <jgraham>
Which is the upstream branch that the current branch is tracking

[16:16:12.0000] <Hixie>
how do i get a diff though?

[16:16:24.0000] <jgraham>
git dif @{u}..

[16:16:27.0000] <jgraham>
*diff

[16:16:30.0000] <Hixie>
that didn't show me anything

[16:16:32.0000] <Hixie>
(i tried that)

[16:17:01.0000] <Hixie>
the log gives two checkins from march

[16:17:04.0000] <Hixie>
which seems unlikely?

[16:17:05.0000] <jgraham>
Well what does git show HEAD show?

[16:17:29.0000] <Hixie>
it gives a commit id

[16:17:35.0000] <Hixie>
and a couple of merge ids

[16:17:42.0000] <Hixie>
and then says me, and march

[16:17:52.0000] <Hixie>
no idea what to do with that

[16:18:18.0000] <jgraham>
You have a merge in your history? That sounds pretty odd

[16:19:32.0000] <Hixie>
it's the way that git diff gives no content that baffles me

[16:19:49.0000] <caitp>
what is the git diff command you're using?

[16:19:59.0000] <caitp>
just git diff BASE HEAD?

[16:20:20.0000] <Hixie>
git diff <blabla> where blabla is the id of any of the last three checkins in git log

[16:20:40.0000] <Hixie>
git diff BASE HEAD says "fatal: ambiguous argument 'BASE': unknown revision or path not in the working tree"

[16:20:57.0000] <caitp>
I should have said <BASE>

[16:21:18.0000] <caitp>
and <HEAD>, like, the base revision and the head revision you want to check against it

[16:23:02.0000] <Hixie>
assuming these commits were just me messing about, and are in fact empty

[16:23:03.0000] <jgraham>
Hixie: If it's a merge commit and there are no conflicts there wouldn't be any

[16:23:14.0000] <Hixie>
how do i throw them away and just be at tip of tree?

[16:23:30.0000] <Hixie>
i just want to be at whatever html5lib is, then i want to pull in all my changes i uploaded earlier

[16:23:53.0000] <Domenic>
<Hixie> the w3c already does that in broad daylight // literal lol'ing happened

[16:26:00.0000] <jgraham>
Hixie: You have just seperated out all your changes into seperate branches

[16:26:08.0000] <Hixie>
yes

[16:26:59.0000] <jgraham>
It's not terribly easy to get into a state where you have the changes from all of those branches at the same time

[16:27:10.0000] <jgraham>
I mean you can

[16:27:17.0000] <jgraham>
But you probably don't want to

[16:27:23.0000] <Hixie>
my code won't compile until i do...

[16:27:32.0000] <Hixie>
well, it'll compile, but it won't pass its tests

[16:27:52.0000] <TabAtkins>
You really want to wait until they're accepted, then just pull the main repo again.

[16:28:00.0000] <TabAtkins>
That'll have everything in it at that point.

[16:28:05.0000] <Hixie>
i really want to run my code right now :-)

[16:28:30.0000] <Hixie>
i presumably have these branches locally

[16:28:45.0000] <Hixie>
i wonder if i can stash each one and pop it on my main branch

[16:28:58.0000] <TabAtkins>
Nothing to stash, as they're all committed up.

[16:29:17.0000] <TabAtkins>
You can make a separate branch, rebase all the other branches over it. That might work?

[16:29:27.0000] <TabAtkins>
Or just merge them all, possibly simpler.

[16:29:36.0000] <TabAtkins>
(Merge on a separate branch.)

[16:29:41.0000] <jgraham>
You can make a branch and cherry-pick all the changes onto it

[16:29:42.0000] <Hixie>
no idea what "rebase" means, but ok?

[16:29:50.0000] <caitp>
rebase is fun, you'll love it

[16:29:51.0000] <jgraham>
Don't try to use rebase

[16:29:57.0000] <caitp>
haha

[16:29:58.0000] <caitp>
aw.

[16:30:08.0000] <jgraham>
It's an awesome tool, but not what you want in this case

[16:30:12.0000] <Hixie>
how do i find a list of all my branches?

[16:30:16.0000] <jgraham>
git branch

[16:30:24.0000] <jgraham>
then create a new branch

[16:30:32.0000] <caitp>
git branch -a or -v, to list branches

[16:30:39.0000] <jgraham>
git checkout -b all_hixie_changes origin/master

[16:30:50.0000] <jgraham>
Just git branch in this case

[16:31:09.0000] <caitp>
ah I guess branch on its own does list them, without remotes

[16:31:26.0000] <jgraham>
(the second argument to git checkout means that the branch starts off at origin/master)

[16:31:38.0000] <jgraham>
And then for each branch that you have created

[16:31:49.0000] <jgraham>
git cherry-pick my_other_branch_name

[16:32:09.0000] <jgraham>
Which will take the topmost commit from the other branch and put it onto your combined branch

[16:32:16.0000] <Hixie>
cool, thanks

[16:32:22.0000] <jgraham>
I am assuming that there is only one commit on each of the other branches

[16:32:30.0000] <Hixie>
let's assume that for now

[16:32:56.0000] <jgraham>
/me -> slep

[16:32:58.0000] <jgraham>
*sleep

[16:33:12.0000] <Hixie>
nn!

[16:33:12.0000] <jgraham>
Hixie: I strongly recommend reading something that explains the git data model

[16:33:16.0000] <Hixie>
and thanks for the help

[16:33:26.0000] <Hixie>
the data model isn't really the source of my confusion

[16:33:27.0000] <jgraham>
Once you basically understand that everything becomes much simpler

[16:33:37.0000] <caitp>
the workflow?

[16:33:40.0000] <Hixie>
i mean, i get the model, it's the just UI for manipulating the model makes no sense to me

[16:33:46.0000] <caitp>
yeah

[16:34:12.0000] <jgraham>
My experience is once you understand the data model the manipulation of it makes a lot more sense

[16:34:13.0000] <Hixie>
you use IDs here, branches there, weird punctuation in the other place, or arguments, all depending on... some black magic logic

[16:34:29.0000] <Hixie>
i mean why "origin" but "@{u}" ?

[16:34:43.0000] <jgraham>
http://wildlyinaccurate.com/a-hackers-guide-to-git

[16:34:43.0000] <Hixie>
instead of @{o} and @{u} or origin and upstream?

[16:34:58.0000] <jgraham>
Probably not the best guide, but I saw it recently and it

[16:35:02.0000] <jgraham>
's not inaccurate

[16:35:19.0000] <Hixie>
and fundamentally imho it's just over-engineered. but then i don't want distributed version control...

[16:36:16.0000] <zewt>
i have no idea what @{u} is and i've used git for a couple years now

[16:36:18.0000] <caitp>
i'm not sure what "@{u}" is supposed to be either, and I'm pretty good with git

[16:36:27.0000] <zewt>
there are tons of things you just don't need to know in git

[16:36:40.0000] <Hixie>
that's pretty much the problem

[16:36:53.0000] <Hixie>
and a pretty clear sign of something being over-engineered

[16:37:00.0000] <Hixie>
personally i think _svn_ is too complicated

[16:37:01.0000] <jgraham>
It's really not over-engineered

[16:37:09.0000] <jgraham>
If anything it's too simple

[16:37:12.0000] <gsnedders>
Hixie: you can use names of branches as aliases for the commit at the top of the branch

[16:37:20.0000] <gsnedders>
Hixie: likewise tags

[16:37:29.0000] <jgraham>
Most of the things that confuse people are because the data model is poking through

[16:37:42.0000] <zewt>
there are definitely things which are weird and unobvious which suggests questionable design to me

[16:37:49.0000] <gsnedders>
git's data model is /really, really, really/ simple. And arguably the problems are lack of absractions on it.

[16:38:02.0000] <caitp>
add, rm, commit, rebase, push, pull, checkout, remote cherry-pick, format-patch, am, log, and maybe rev-parse for scripting, and not necessarily in that order

[16:38:12.0000] <caitp>
most of those commands are simple and self-explanatory

[16:38:18.0000] <jgraham>
e.g. origin/master is literally the path .git/refs/origin/master

[16:38:28.0000] <jgraham>
Which is a file containing a SHA1

[16:38:48.0000] <jgraham>
Which points to the head of the origin/master branch

[16:39:26.0000] <jgraham>
caitp: ref-log is also useful

[16:39:27.0000] <Hixie>
i just want a remote file system that's versioned

[16:39:35.0000] <Hixie>
no branches, tags, local repos, etc

[16:39:51.0000] <zewt>
different workflows need different thing

[16:39:52.0000] <Hixie>
just a way to commit, a way to diff, a way to revert

[16:39:55.0000] <jgraham>
Yeah, but that's not what we want in order to share work with you

[16:40:00.0000] <zewt>
i've never once needed format-patch

[16:40:12.0000] <Hixie>
i'm not really looking to share work with anyone :-P

[16:40:25.0000] <jgraham>
Well here you are

[16:40:30.0000] <jgraham>
But your needs are strange because you usually work alone

[16:40:31.0000] <caitp>
format-patch made working on mozilla-central from git a lot easier

[16:40:39.0000] <jgraham>
That is very much the 0.1% case

[16:40:47.0000] <jgraham>
caitp: moz-git-tools

[16:40:59.0000] <caitp>
this was from a while back

[16:40:59.0000] <zewt>
the whole "patch sets to mailing lists" workflow seems pretty terrible to me, heh

[16:41:07.0000] <jgraham>
Yeah, it is

[16:41:19.0000] <jgraham>
The whole patches attached to bugzilla workflow is also terrible

[16:41:23.0000] <zewt>
the #1 biggest thing open source has gained from git is being able to send patches *without* having to send patches

[16:41:35.0000] <Hixie>
i think people working alone is more like the 99.999% case, but sure

[16:41:44.0000] <Hixie>
i agree that other people have other needs

[16:41:47.0000] <caitp>
in some ways, I think bugzilla's model kind of beats rietveld. _.

[16:42:02.0000] <zewt>
fork github project, make changes in a branch, send a PR, and the whole "sending a patch" thing is invisible--which has lowered the bar for sending patches massively

[16:42:30.0000] <Hixie>
alright, my tests pass again

[16:42:32.0000] <Hixie>
excellent

[16:42:38.0000] <caitp>
horray

[16:42:42.0000] <Hixie>
jgraham: thanks again, btw, especially for putting up with my whining

[16:42:58.0000] <jgraham>
zewt: Yeah, it's pretty amazing that forms the central value proposition of github

[16:43:09.0000] <jgraham>
Especially when their implementation is so halfassed

[16:43:43.0000] <gsnedders>
jgraham: thanks for putting up with Hixie's whining so I could go and drink cider

[16:43:43.0000] <jgraham>
Hixie: np

[16:43:53.0000] <zewt>
oddly i tend to make a comparison between git and twitter--twitter has essentially zeroed the cost for sending a message to someone else (even if those messages are excessively limited)

[16:43:58.0000] <Hixie>
gsnedders: https://github.com/html5lib/html5lib-tests/branches

[16:44:05.0000] <gsnedders>
Hixie: aye, I saw in the backlog

[16:44:23.0000] <gsnedders>
tomorrow's problem, assuming I don't kill someone and end up in jail during driving lesson :)

[16:44:44.0000] <jgraham>
gsnedders: I doubt the cider will help</protip>

[16:44:53.0000] <jgraham>
/me really is going to sleep now

[16:45:07.0000] <Hixie>
gsnedders: roger, good luck

[16:45:14.0000] <TabAtkins>
Ooh, yeah, "Hacker's Guide to Git" works quite well as an explanation of the data model.

[16:45:30.0000] <gsnedders>
jgraham: I'm pretty sure I can cope with one bottle ten hours before.

[16:46:23.0000] <zewt>
git is one of those things that you sort of have to both 1: read a bunch and then 2: suck up and use it for a couple months to get past the curve

[16:46:41.0000] <zewt>
which isn't an indicator of great design, but worth it in its case

[16:48:33.0000] <TabAtkins>
I think it's easier if you didn't learn a previous VCS.

[16:49:02.0000] <TabAtkins>
But yeah, intuitively getting what commits/tags/branches represent, and how they're different from files and folders, is a little hard.

[16:49:17.0000] <zewt>
rebasing can be a bit tricky too

[16:49:25.0000] <gsnedders>
most of git makes sense if you understand the underlying model

[16:49:29.0000] <TabAtkins>
Super-easy once you understand cherrypicking.

[16:49:33.0000] <gsnedders>
but only if you understand the underlying model

[16:49:42.0000] <TabAtkins>
Because rebase is just "automatically cherry-pick everything from the common ancestor to here for me".

[16:49:46.0000] <zewt>
what helped me a lot was to peek into .git while it was rebasing; once you see a directory with a couple dozen numbered patch files, it's pretty clear what it's doing

[16:51:22.0000] <zewt>
i guess one of the weaker points is force pushing

[16:51:42.0000] <zewt>
because explaining it goes like this: "you should never ever ever do this, except when you should"

[16:52:46.0000] <zewt>
that might be more due to the github pull request model that was layered on top (where you have to force push over the PR branch to update it); in the original linux kernel model maybe there was no normal workflow reason to ever do it

[16:53:35.0000] <gsnedders>
you should always assume others have cloned your repo and have things based on that branch

[16:53:40.0000] <gsnedders>
hence getting rid of that is bad

[16:55:54.0000] <TabAtkins>
What *&is* a good reason to force push?

[16:55:58.0000] <TabAtkins>
I've never had to do so.

[16:56:43.0000] <gsnedders>
A good reason? You committed your password to the repo and want to entirely remove it from history.

[16:56:52.0000] <gsnedders>
However, note anyone who already has a clone still has it

[16:57:15.0000] <TabAtkins>
Right, you can't amend othe rpeople's histories.

[16:57:40.0000] <gsnedders>
The typical case in the GitHub case is when rebasing a PR


2014-06-17
[17:03:05.0000] <zewt>
hero ku uses git for pushing code; you need to force push to that a lot too

[17:03:42.0000] <zewt>
also heroku; ios'a new habit of autocorrecting words when you type the *next* word is terrible

[17:06:48.0000] <TabAtkins>
Huh, Android just autocorrets when you hit space.

[17:19:10.0000] <zewt>
that's what ios used to do; now it tries to figure out phrases

[17:19:42.0000] <zewt>
which means you never really know when it'll insert a typo for you

[17:35:46.0000] <Domenic>
TabAtkins: lookin' good. https://whatwg.github.io/streams/

[17:36:14.0000] <Domenic>
Next up I think I need to steal some CSS and/or JS to get the anchor links working

[17:36:23.0000] <TabAtkins>
Happy to help.

[17:36:49.0000] <TabAtkins>
The parts of the CSSWG stylesheet are pretty easy to find.

[17:37:08.0000] <TabAtkins>
http://dev.w3.org/csswg/default.css

[17:37:17.0000] <TabAtkins>
Look for a.self-link

[17:37:48.0000] <TabAtkins>
Also: whatwg specs should use the CSSWG toc styling, it's the best.

[17:39:23.0000] <Domenic>
sweet. will play with this more tomorrow maybe. although at some point i have to consider this yak shaved and keep working on the actual text :P

[17:56:33.0000] <zewt>
yak shaving considered harmful

[18:04:23.0000] <Hixie>
TabAtkins: last time you said that css spec styling was the best, i picked a random css spec, and it looked horrible. do you have a specific spec in mind?

[18:08:52.0000] <Domenic>
was the day April 1?

[18:10:36.0000] <zewt>
one of them was

[22:28:44.0000] <annevk>
TabAtkins: dom-core.html is not too important I guess; https://github.com/whatwg/dom/ should be canonical; I use two definitions of throw, one is from DOM, one is from IDL

[00:17:05.0000] <zcorpan>
Hixie: yoav wants to put a link in his patch to my recent img spec changes. could you regen the spec?

[00:21:41.0000] <krit>
annevk: I am back online

[00:22:21.0000] <annevk>
krit: cool

[00:23:11.0000] <krit>
annevk: I checked mask-image and filter and think that both do not cause any problems if the resources are not allowed to load further resources

[00:23:20.0000] <krit>
annevk: both do not affect layout

[00:23:28.0000] <annevk>
krit: having written down the algorithms it does seem like SVG as image has a lot in common with the other cases

[00:23:43.0000] <annevk>
krit: it's just that rather than returning an element by ID, in that case you simply take the root

[00:23:54.0000] <krit>
annevk: I presented the problem with clip-path to the WG in Tokyo and the WG decided that the attack pattern is not suitable enough

[00:24:18.0000] <annevk>
krit: which WG?

[00:24:23.0000] <krit>
annevk: CSS WG

[00:24:29.0000] <annevk>
krit: what makes them good at security?

[00:25:11.0000] <annevk>
You don't go to the CSS WG for security recommendations

[00:25:12.0000] <krit>
annevk: All I was able to do as spec author is to present the problem, present alternatives and ask for approval… which I did

[00:25:25.0000] <annevk>
You ask abarth, bz, ...

[00:25:35.0000] <krit>
annevk: we discussed it

[00:25:38.0000] <annevk>
WebAppSec copied

[00:25:43.0000] <krit>
annevk: bz was in the discussion

[00:25:50.0000] <annevk>
In Tokyo?

[00:26:05.0000] <krit>
annevk: He did not approve the outcome of the discussion but did not object either

[00:26:28.0000] <krit>
annevk: no, we discussed the issue before the F2F on the mailing list

[00:26:30.0000] <annevk>
o_O sounds like a bad outcome to me

[00:26:50.0000] <krit>
annevk: but irrelevant for the other properties that I care more about right now

[00:27:02.0000] <krit>
annevk: we can bring up clip-path at any time again

[00:27:49.0000] <annevk>
k

[00:28:51.0000] <krit>
annevk: what that means is that mask-image, fill, stroke and filter do not need to check the resource after downloading again

[00:28:59.0000] <krit>
annevk: something that was important for roc

[00:29:22.0000] <annevk>
but you do, no?

[00:29:24.0000] <krit>
annevk: even though he agreed that this is not a big issue if it would be necessary

[00:29:30.0000] <annevk>
you need to at least do a MIME type check?

[00:29:34.0000] <krit>
annevk: no, we don't

[00:29:45.0000] <annevk>
o_O

[00:29:48.0000] <krit>
annevk: well, this is done AFTER downloading the resource

[00:29:54.0000] <krit>
annevk: the MIME checking

[00:29:57.0000] <annevk>
yes

[00:30:13.0000] <krit>
annevk: the policies prevent downloading the resource in the first place

[00:30:25.0000] <annevk>
What policies?

[00:30:42.0000] <krit>
annevk: The CORS policies as implement

[00:30:50.0000] <annevk>
I have the feeling you're compounding several issues onto one

[00:30:53.0000] <krit>
annevk:  that is common between blink, gecko and WebKit

[00:31:11.0000] <krit>
annevk: you mean?

[00:31:13.0000] <annevk>
I don't see what CORS has to do with this

[00:31:38.0000] <krit>
annevk: right, lets say fetching policies … where CORS is still part of

[00:32:03.0000] <annevk>
Sure, are you saying fetching mode is CORS for mask/fill/stroke/filter?

[00:32:21.0000] <krit>
annevk: http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/ResourceFetcher.cpp

[00:32:28.0000] <krit>
annevk: no, “image"

[00:32:46.0000] <annevk>
There's no "image" mode

[00:33:15.0000] <krit>
annevk: that is because implementations use their own terms

[00:33:34.0000] <krit>
annevk: we check what type we expect

[00:34:05.0000] <krit>
annevk: font, image, stylesheet, script, SVG document (for <embed>), media

[00:34:42.0000] <abarth>
i've been reading along, but I need to go to sleep soon

[00:34:52.0000] <abarth>
can you summarize what the CSS WG decided?

[00:34:59.0000] <annevk>
You're not making much sense. But I guess what you mean is that mask/fill/stroke/filter use no CORS as mode and that the CSS WG decided that was okay.

[00:35:16.0000] <krit>
annevk: yes

[00:35:18.0000] <annevk>
Even if the eventual thing was an SVG resource

[00:35:26.0000] <krit>
annevk: right

[00:35:43.0000] <abarth>
that's almost certainly insecure

[00:35:57.0000] <abarth>
you can't load XML across origins without CORS

[00:36:08.0000] <krit>
abarth: why wouldn’t you?

[00:36:19.0000] <abarth>
because XML is a confidential mime type

[00:36:34.0000] <abarth>
these features also let you probe inside the XML for ids and such

[00:36:42.0000] <abarth>
which isn't good

[00:37:21.0000] <krit>
abarth: IIRC we discussed that earlier and you even opened a bug report and closed it right afterwards

[00:37:40.0000] <krit>
abarth: we had this discussion before Blink fork

[00:37:58.0000] <abarth>
do you have a link to the discussion?

[00:38:07.0000] <abarth>
I remember this issue came up before

[00:38:11.0000] <krit>
abarth: it takes me some time to find it

[00:38:13.0000] <abarth>
but I didn't remember the details

[00:38:32.0000] <abarth>
maybe there's some specific thing that makes it safe, but in general its unsafe

[00:38:38.0000] <krit>
abarth: the point is, that you can not do ID sniffing with CSS

[00:39:12.0000] <krit>
abarth: if the resource exists, then you download it… there is no way for anyone to check if the ID was found or not

[00:39:31.0000] <abarth>
presumably you can tell if the mask was applied, right?

[00:39:39.0000] <krit>
abarth: how?

[00:40:00.0000] <krit>
abarth: it doesn’t apply, the url is still part of property style

[00:40:17.0000] <krit>
s/it/the mask/

[00:40:22.0000] <abarth>
sure, but the pixels on the screen will be different

[00:40:27.0000] <annevk>
abarth: for <img> I think we decided it was safe

[00:40:28.0000] <krit>
abarth: yes

[00:40:46.0000] <abarth>
if the pixels on the screen are different, the web site can learn that by interacting with the user

[00:40:49.0000] <annevk>
abarth: <img> does no CORS, and if the return MIME type is image/svg+xml we decode that as a bitmap and render it

[00:41:01.0000] <abarth>
there was a cute proof-of-concept on hacker news the other day

[00:41:05.0000] <abarth>
for history sniffing

[00:41:11.0000] <abarth>
using this technique

[00:41:20.0000] <abarth>
annevk: yes

[00:41:26.0000] <krit>
abarth: that one needed visited pseudo selector

[00:41:37.0000] <abarth>
krit: you don't think you could build the same thing using mask?

[00:41:42.0000] <krit>
abarth: which sadly is not specified enough

[00:41:48.0000] <abarth>
meaning make a game

[00:42:03.0000] <abarth>
where the player makes different clicks depending on if a mask applied?

[00:42:32.0000] <abarth>
annevk: we wouldn't do that today, but we're stuck with it because of the past

[00:42:33.0000] <krit>
abarth: hit testing is not applied on mask, but like opacity, you can “hide” objects

[00:42:42.0000] <abarth>
krit: you're not understanding

[00:42:52.0000] <abarth>
mask changes the pixels on the screen

[00:42:58.0000] <abarth>
users react to pixels on the screen

[00:43:05.0000] <annevk>
abarth: yeah, we could have disallowed the cross-origin case there though and require the crossorigin attribute

[00:43:07.0000] <abarth>
meaning, they react to whether the mask applied

[00:43:17.0000] <abarth>
meaning they tell you whether your ID probe worked

[00:43:28.0000] <abarth>
annevk: exactly

[00:43:31.0000] <annevk>
abarth: e.g. if the response image/svg+xml but also tainted/opaque, act as if there was a network error

[00:43:35.0000] <krit>
abarth: sure you can do that

[00:43:43.0000] <abarth>
hence, you're creating a security vulnerability

[00:43:51.0000] <abarth>
unless you use CORS

[00:43:53.0000] <annevk>
abarth: that seems like what we should do for mask et al

[00:44:16.0000] <annevk>
abarth: if we want to keep the "tainted" cross-origin fetching for non-SVG resources

[00:45:25.0000] <abarth>
https://news.ycombinator.com/item?id=7855168

[00:45:42.0000] <abarth>
is a recent demo of this approach

[00:45:49.0000] <abarth>
you could build the same thing with mask

[00:45:56.0000] <abarth>
to probe cross-origin resources rather than history

[00:47:12.0000] <abarth>
/me needs to get to sleep

[00:47:17.0000] <abarth>
security's no fun

[00:47:19.0000] <abarth>
:(

[00:47:30.0000] <annevk>
thanks abarth, I was mostly trying to figure out the overall processing model, but this helps greatly with fetch specifics that we also need to nail down

[00:48:07.0000] <annevk>
abarth: nn

[00:49:20.0000] <krit>
abarth: we should discuss that on the mailing list again

[00:50:44.0000] <krit>
abarth: IIRC the issue was that you can figure out if the ID exists even without CSS.. pure JS

[00:51:01.0000] <krit>
abarth: the URL of the resource is known at the point

[01:00:35.0000] <annevk>
krit: I don't understand the aversion to better safe than sorry

[01:01:53.0000] <krit>
annevk: we always need to find the right balance between security and the expressiveness of authors… We don’t need to make the web as secure as possible but as secure as necessary to protect users

[01:02:37.0000] <annevk>
Yes, and we have repeatedly learned that not using CORS is bad for users

[01:05:19.0000] <krit>
annevk: and I think it is good to have people on the other side that challenge the need of overprotection :)

[01:06:43.0000] <annevk>
Overprotection?

[01:09:10.0000] <annevk>
krit: anyway, I updated the algorithms in the etherpad

[01:09:36.0000] <annevk>
krit: they are now generic enough to cover both SVG as image, and whereever else we might need to take hold of a set of nodes

[01:09:54.0000] <annevk>
krit: if you don't pass in an ID it simply returns the root, otherwise it returns the element identified

[01:10:30.0000] <annevk>
krit: there's various entry points as well, as e.g. the mask/filter/ case will do its own fetching and then only if type is image/svg+xml hand it off to SVG

[01:24:53.0000] <krit>
annevk: ?

[01:25:22.0000] <annevk>
krit: what is unclear?

[01:30:00.0000] <krit>
annevk: no, wanted to know if this is what you would like to see for mask-image/

[01:30:37.0000] <annevk>
krit: yeah, it seems we should actually write out mask image processing

[01:30:43.0000] <annevk>
krit: because that is more complicated

[01:31:19.0000] <annevk>
krit: I also wonder if TabAtkins will be in a more convenient timezone at some point so we can fix this stuff in CSS

[01:31:20.0000] <krit>
annevk: fill and stroke inherit the same behavior… so this could be ironed out for all SVG properties then

[01:31:23.0000] <krit>
annevk: including clip-path and filter

[01:31:49.0000] <annevk>
yeah, the algorithm "To get an image or SVG element given a /url/:"

[01:32:22.0000] <annevk>
it seems that should also take an environment URL and maybe an environment base URL

[01:32:38.0000] <krit>
annevk: Tab is working on more parameters for url() that allows authors to specify CORS rules

[01:32:39.0000] <tobie>
Fwiw, tend to agree with jgraham on the to('json') vs. asJSON.

[01:33:11.0000] <annevk>
krit: sure, again, that is not really important

[01:33:17.0000] <annevk>
krit: what is important is the basic setup

[01:33:25.0000] <annevk>
krit: without additional features

[01:33:34.0000] <annevk>
please try to focus on that

[01:34:16.0000] <annevk>
tobie: talk to JakeA or Domenic I guess

[01:43:18.0000] <annevk>
If people want to follow the SVG discussion, we moved to W3C, #svg

[03:12:32.0000] <MikeSmith>
zcorpan: so, about srcset, I have question that maybe I should hesitate to ask since I'm not sure I want to implement it, but I'll ask anyway

[03:13:10.0000] <MikeSmith>
which is, should it be a conformance error if the same URL is specified multiple times in the same srcset value

[03:14:03.0000] <MikeSmith>
in other words, is there ever a use case for specifying a URL with different descriptors in the same srcset value

[03:14:25.0000] <zcorpan>
MikeSmith: not sure

[03:14:28.0000] <MikeSmith>
e.g., srcset="image1.png 1X, image1.png 2X"

[03:14:44.0000] <MikeSmith>
(though probably not that example)

[03:15:02.0000] <zcorpan>
MikeSmith: can you file a bug?

[03:15:08.0000] <MikeSmith>
yeah

[03:15:10.0000] <zcorpan>
thx

[03:17:09.0000] <MikeSmith>
zcorpan: also I told you before I wasn't storing the URLs anyway. But I changed that and I am now, because I use them for reporting purposes in the error messages

[03:17:24.0000] <MikeSmith>
and I do that because I can't report the exactly column number of where the error is

[03:18:11.0000] <MikeSmith>
which is a general deficiency in the way the validator datatype/microsyntax error-reporting is designed

[03:19:20.0000] <MikeSmith>
most of the time it's not a problem to no report the exacty column number because the attribute values are generally short and not complex

[03:19:20.0000] <MikeSmith>
but the case for srcset is a bit different

[03:21:07.0000] <zcorpan>
MikeSmith: yeah i guess you'll highlight the entire value right?

[03:21:55.0000] <zcorpan>
or the whole tag even

[03:22:22.0000] <MikeSmith>
right

[03:23:13.0000] <MikeSmith>
zcorpan: it's less than ideal but it'd be a lot of work to change given the current design of the datatype-checking code

[03:23:20.0000] <zcorpan>
yeah

[03:23:50.0000] <zcorpan>
i guess people can figure out what the error is anyway

[03:26:05.0000] <zcorpan>
maybe you can do a hack and give a relevant extract in the message?

[03:27:41.0000] <annevk>
Lovely, mask:url(#something) references an element in the document the stylesheet is associated with

[03:28:16.0000] <annevk>
However, they also allow mask:url(/elsewhere#something) which would parse relative to the stylesheet's URL, then be fetched, ...

[03:28:43.0000] <smaug____>
what is an opposite of composed? incomposed seems to have also some other meanings.

[03:28:52.0000] <zcorpan>
MikeSmith: something like srcset="lala 1.5x, foo,, bar 2x" -> Bad value for attribute srcset on element img: Found empty image candidate in `foo,,`

[03:29:14.0000] <annevk>
I guess you could parse against the stylesheet's URL and then treat it as a document-reference if it's the same as the stylesheet's URL minus the fragment thing... But oh boy

[03:29:35.0000] <annevk>
smaug____: excited per Google

[03:30:17.0000] <annevk>
smaug____: also agitated, boisterous, disturbed, excited, fierce, frantic, frenzied, furious, heated, passionate, raging, roused, ruffled, stormy, turbulent, violent, wild, wrathful

[03:30:33.0000] <smaug____>
boisterousDocument

[03:30:37.0000] <smaug____>
sounds perfect

[03:30:45.0000] <annevk>
:-)

[03:30:47.0000] <MikeSmith>
flustered

[03:31:11.0000] <annevk>
ruffled as technical term would also be fun

[03:31:20.0000] <MikeSmith>
unsettled

[03:32:11.0000] <annevk>
I should probably post about IDNA being updated at some point

[03:32:27.0000] <annevk>
Now that http://www.unicode.org/reports/tr46/ is published with the revised algorithms

[03:32:46.0000] <smaug____>
/me is trying to figure out names for the trees where document is the root node, and doesn't contain shadow dom, and the tree which does contain shadow dom. ComposedDoc for the latter

[03:33:34.0000] <MikeSmith>
raw?

[03:33:50.0000] <annevk>
smaug____: why does the former need to be different from Document

[03:33:54.0000] <MikeSmith>
untainted?

[03:34:00.0000] <annevk>
smaug____: document and composedDocument seems fine

[03:34:06.0000] <smaug____>
annevk: this is mainly for Gecko internal stuff

[03:34:39.0000] <smaug____>
in order to force the API user to think whether shadow dom should be handled

[03:34:56.0000] <MikeSmith>
smaug____: PreComposed?

[03:35:03.0000] <smaug____>
well, it is not pre

[03:35:07.0000] <smaug____>
it is Document

[03:35:26.0000] <MikeSmith>
then Un-

[03:35:40.0000] <MikeSmith>
UnComposed

[03:35:41.0000] <smaug____>
perhaps that

[03:37:36.0000] <MikeSmith>
anyway it seems analogous the character composition, so maybe there are already some names that could be repurposed from the code around that

[03:38:03.0000] <smaug____>
/me uses un-

[03:42:25.0000] <MikeSmith>
I naively set out on srcet checking hoping I'd be able to get by without needing to create strings and store strings

[03:42:29.0000] <MikeSmith>
so much for that plan

[03:46:11.0000] <MikeSmith>
zcorpan: ah I remember now that's why I was asking you about the URLs. So far the spec has no requirement that would make me need to compare the URLs to one another, so so far I don't need to create strings for them or store them as strings

[03:52:26.0000] <zcorpan>
you need to store and compare the parsed descriptors though

[03:53:10.0000] <darobin>
MikeSmith: I had a case not long ago in which better datatype error reporting would have been really nice, it was for a pretty long data: URL

[03:53:27.0000] <zcorpan>
(but they're not strings, so yeah)

[03:53:39.0000] <darobin>
and all it told me was that there was a character in there it didn't like (and that I should be careful with quotes and spaces, which wasn't the problem)

[03:55:04.0000] <annevk>
MikeSmith: still no schemaless validator?

[03:56:12.0000] <zcorpan>
annevk: that'd be a pretty big leap

[03:57:25.0000] <annevk>
one small step for the validator, ...

[04:42:45.0000] <MikeSmith>
darobin: yeah I noticed that same data: URL error-reporting problem

[04:44:56.0000] <darobin>
MikeSmith: I understand that giving the column number is nigh impossible (and I can imagine why), but if you could somehow surface the faulty character it would help lots

[04:46:08.0000] <MikeSmith>
darobin: so that's possible at least. I mean obviously we have the problem character available at that point. we just need to add it to the error message

[04:46:36.0000] <MikeSmith>
the data: URL reporting code is some relatively old part

[04:47:05.0000] <MikeSmith>
it probably needs some attention in other parts too

[04:49:33.0000] <MikeSmith>
annevk: I've been moving away from the schema more and more when possible at least. e.g., for srscet the basic srcset-allowed-for-source-and-img constraint is all that the schema specifies, and the schema says the datatype for srcset is just "string". I put the actual real datatype association-and-checking for it into other code

[04:50:19.0000] <MikeSmith>
in part because srcset is unique in that it basically has two different dataypes depending on whether the "sizes" attribute is also specified

[04:51:14.0000] <MikeSmith>
and also because I tried it first in the schema and it exposed a bug in jing schema-checking code that I couldn't be assed to try to troubleshoot and fix

[04:52:15.0000] <MikeSmith>
it actually exposed a case in jing where the behavior was different depending on the *order* of the attributes -- different if sizes was specified before srcset, or after

[04:52:58.0000] <MikeSmith>
which, I didn't even think that would be possible given the way the parser and jing work

[04:53:04.0000] <MikeSmith>
but I guess it actually use

[04:53:07.0000] <MikeSmith>
*is

[04:54:19.0000] <MikeSmith>
darobin: if you have time to file a bug about the data URL thing, please do. It's an easy fix and I could do it this weekened

[04:56:59.0000] <darobin>
MikeSmith: I was already on the bugzilla page :)

[04:57:47.0000] <MikeSmith>
/me and darobin putting the MPAA dollars to good use

[04:58:02.0000] <darobin>
:)

[05:15:14.0000] <zcorpan>
MikeSmith: note that srcset with w is allowed without sizes

[06:01:21.0000] <MikeSmith>
zcorpan: yeah I know that :) but the thing is internally in the vnu design I essentially need to handle it as a separate datatype when sizes is there too

[06:01:53.0000] <zcorpan>
MikeSmith: k :-)

[06:03:07.0000] <annevk>
zcorpan: http://dev.w3.org/csswg/cssom/#css-style-sheets is somewhat wrong

[06:03:30.0000] <annevk>
zcorpan: location should be named href and you should have a field url or some such that's the actual location against which urls are resolved and such

[06:03:44.0000] <annevk>
zcorpan: is the plan that everything else in CSS references this?

[06:03:50.0000] <zcorpan>
annevk: please file a bug

[06:04:40.0000] <zcorpan>
annevk: not sure, but it needs to be well-defined at some point

[06:05:18.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26116

[06:05:40.0000] <annevk>
I'm trying to figure out fetching for SVG

[06:05:55.0000] <annevk>
Seems CSS could use some cleanup there too

[06:06:38.0000] <annevk>
And SVG requires this thing where you load an external SVG document, but don't actually fetch anything from it that isn't a blob or data or other local URL

[06:06:55.0000] <annevk>
Styles need to be resolved however so that property needs to be supported by CSS too

[06:07:15.0000] <annevk>
However, it's unclear where in CSS such things would be defined

[06:07:20.0000] <annevk>
TabAtkins: ^^

[06:08:00.0000] <zcorpan>
earlier today i was pondering how <img src=svg> works when it has a late well-formedness error

[06:09:39.0000] <annevk>
I guess that's not too different from a GIF or some such that has an error late?

[06:09:46.0000] <annevk>
Ill-defined :/

[07:02:58.0000] <zcorpan>
annevk: GIF either goes from unavailable -> error or unavailable -> partially available -> completely available (even if it has late errors, it doesn't make the whole thing corrupt). i think

[07:07:36.0000] <Domenic>
MikeSmith: zcorpan: maybe <img srcset="pixelized.png 1x, vectorized.svg 1.5x, pixelized-2 2x, vectorized.svg 2.5x"> would be a use case for the same URL multiple times?

[07:08:58.0000] <zcorpan>
Domenic: maybe, but would you actually do that? instead of <img src="pixelated.png" srcset="vectorized.svg"> ?

[07:10:07.0000] <Domenic>
i kind of envisioned people creating specific breakpoint images for certain resolutions/densities, and then saying that they'd rather use a vectorized version in between for perfect scaling, instead of letting the browser do it fuzzily.

[07:10:09.0000] <darobin>
/me throws some lowsrc at zcorpan, just for funs

[07:12:52.0000] <zcorpan>
darobin: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26072

[07:13:41.0000] <darobin>
zcorpan: oh man, I was actually joking — but you mean business

[07:13:44.0000] <Ms2ger>
Good old lowsrc

[07:14:26.0000] <darobin>
/me recalls the jokes, "Hey, unfortunately my ISP is France Telecom, could you add lowlowsrc to the spec please?"

[07:15:19.0000] <odinho>
:P

[07:19:17.0000] <yoav>
zcorpan: FWIW, I think that any data URI/cached image can be used as a replacement image until the real resource is downloaded

[07:19:20.0000] <yoav>
See https://code.google.com/p/chromium/issues/detail?id=382591

[07:19:49.0000] <yoav>
zcorpan: And AFAICT, this is inside the "UA resource selection optimization" domain

[07:20:15.0000] <yoav>
So no need to spec it (even though we can add a note or something)

[07:22:51.0000] <zcorpan>
yoav: intredasting

[07:25:45.0000] <zcorpan>
ok wontfixed the lowsrc bug

[07:28:01.0000] <zcorpan>
annevk: thx for the bug

[07:55:03.0000] <Domenic>
http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0 redirects to bing??

[07:56:05.0000] <Ms2ger>
https://sites.google.com/site/openwebfoundation/

[07:56:07.0000] <Ms2ger>
Wat

[07:59:39.0000] <annevk>
/me *blinks*

[07:59:58.0000] <annevk>
mathiasbynens: https://code.google.com/p/v8/source/detail?r=18683 does not seem good, writing invalid utf-8 should not be an option...

[08:00:04.0000] <jgraham>
annevk: Traitor

[08:00:19.0000] <annevk>
jgraham: ?

[08:00:30.0000] <jgraham>
annevk: Don't worry

[08:00:39.0000] <annevk>
k

[08:00:44.0000] <jgraham>
It wasn't funny anyway :)

[08:10:53.0000] <mathiasbynens>
annevk: felixge said it’s because the V8 team wants to keep the API stable :/

[08:11:28.0000] <mathiasbynens>
(note that it’s not just an option – it’s the default)

[08:13:33.0000] <annevk>
they are crazy

[08:21:09.0000] <darobin>
V8? Crazy? Noooo

[08:25:34.0000] <annevk>
heard it here first

[08:31:34.0000] <zcorpan>
Hixie: i've added picture, i tried running anolis locally and i think the xrefs are OK now. let me know if something's still broken.

[08:37:23.0000] <TabAtkins>
annevk: What is "this thing where you load an external SVG document"?

[08:37:46.0000] <annevk>
TabAtkins: I'll need some more context :-)

[08:38:02.0000] <TabAtkins>
The thing you mentioned me about 2 hours ago.

[08:38:42.0000] <annevk>
TabAtkins: oh, SVG as image

[08:39:00.0000] <TabAtkins>
Oh, now I understand your sentence.

[08:40:37.0000] <TabAtkins>
Referring to a "property" confused me, as it looked like you meant a CSS property, not an abstract property.

[08:55:35.0000] <Domenic>
Hixie: I'm happy to buy a SSL cert for resources.whatwg.org

[08:58:34.0000] <jgraham>
https://www.globalsign.com/ssl/ssl-open-source/ might apply

[09:03:55.0000] <Domenic>
The main use case is avoiding mixed-content warnings on HTTPS sites, like github.io or github.com

[09:44:40.0000] <mathiasbynens>
Domenic: might as well go for a *.whatwg.org cert then

[09:45:09.0000] <Domenic>
mathiasbynens: if we can get a free one, sure, but we'd need a $300/year one to cover all the subdomains and sub-subdomains

[09:45:22.0000] <Domenic>
mathiasbynens: turns out wildcard certs ($100/year) only cover a single level

[09:45:52.0000] <mathiasbynens>
Domenic: TIL

[09:53:02.0000] <annevk>
TabAtkins: I've been working with krit on figuring out how we should define those features that can reference both an SVG element and an image and it seems we're closing in on a solution

[09:53:49.0000] <annevk>
TabAtkins: I guess at some point we should discuss what it'll take to define fetching for CSS properties in general

[09:54:20.0000] <annevk>
TabAtkins: it seems part of the infrastructure for that is defined in CSSOM today (the concept of a CSS style sheet and its various subconcepts)

[10:15:54.0000] <TabAtkins>
Yeah, but possibly not enough. More than happy to help figure this out whenever you have time, or to apply whatever you and krit bang out.

[10:16:31.0000] <TabAtkins>
Dunno if you heard, but we figured out how we want to allow passing flags and whatnot with urls.

[10:17:25.0000] <TabAtkins>
Within our existing budget of lookahead, I can change parsing to make *quoted* url() functions actually a FUNCTION token, so they can take additional values after the url string.  (Unquoted urls would still be the magical weird URL token.)

[10:17:38.0000] <TabAtkins>
Passed dbaron's initial sanity check, so I'm happy about it.

[10:18:23.0000] <TabAtkins>
annevk: Also, would appreciate your feedback on the WHATWG bikeshed header, over in my github.

[10:18:41.0000] <TabAtkins>
Domenic has a couple of questions about variations between your headers and his.

[10:20:15.0000] <annevk>
TabAtkins: looking now

[10:20:15.0000] <krit>
TabAtkins: if you mean CORS arguments as part of URL, we didn’t touch it… that would still be up to you and annevk

[10:20:34.0000] <TabAtkins>
krit: Yeah, that's what I'm talking about.

[10:20:35.0000] <TabAtkins>
Ok.

[10:20:38.0000] <annevk>
As far as I can tell we need CORS mainly for @import

[10:21:01.0000] <TabAtkins>
Yeah, so we can expose the stylesheets.

[10:21:14.0000] <annevk>
But it might be good to make url() in general forward compatible with it at least

[10:21:30.0000] <TabAtkins>
But also we'll need them if we ever expose more resources that are cors-restricted by default.

[10:22:00.0000] <TabAtkins>
annevk: URL good enough for me to refer to it from V&U to define url parsing now?

[10:22:30.0000] <annevk>
TabAtkins: yeah, think so

[10:22:38.0000] <annevk>
TabAtkins: but note that you need access to a base URL

[10:22:50.0000] <annevk>
TabAtkins: you need some kind of environment setup too

[10:22:53.0000] <TabAtkins>
Right, which the stylesheet should provide.

[10:22:55.0000] <TabAtkins>
Interesting.

[10:23:02.0000] <TabAtkins>
I'll read more into it.

[10:23:33.0000] <annevk>
TabAtkins: well for now it's mostly base URL; but if we expose these properties in script somehow they might want to make blob URLs work somehow

[10:24:14.0000] <Hixie>
zcorpan: regenning...

[10:24:42.0000] <Hixie>
Domenic: cool

[10:24:51.0000] <Hixie>
i wonder how you can get it to me safely

[10:24:56.0000] <Hixie>
let's see

[10:27:28.0000] <Ms2ger>
Hixie, pgp, clearly

[10:27:46.0000] <Hixie>
Domenic: you around?

[10:27:51.0000] <Domenic>
Hixie: ya just got back

[10:41:42.0000] <Hixie>
zcorpan: Possible xref problems:

[10:41:43.0000] <Hixie>
+   density</var> be the URL and pixel density that results from <span>selecting an image source</span>, respectively.</li>

[10:48:36.0000] <zcorpan>
Hixie: fixed

[10:49:16.0000] <Hixie>
zcorpan: cool, will integrate that too

[10:49:25.0000] <Hixie>
zcorpan: sorry i haven't been regenning much recently, i'm updating my pipeline

[10:49:35.0000] <Hixie>
zcorpan: hopefully gonna make it sooo much quicker

[10:49:46.0000] <Hixie>
i've got the parsing of the spec down to four seconds

[10:49:48.0000] <zcorpan>
Hixie: it's ok

[10:49:58.0000] <zcorpan>
nice

[10:50:06.0000] <Hixie>
takes 90MB to hold the parse tree, but...

[10:51:06.0000] <SamB>
Hixie: does that involve a lot of redundancy?

[10:51:24.0000] <zcorpan>
might be less memory to use the v.nu parser in streaming mode

[10:51:34.0000] <Hixie>
memory is cheap

[10:51:38.0000] <SamB>
does that support Object Pascal?

[10:51:44.0000] <Hixie>
it's time that i'm worried about

[10:51:57.0000] <zcorpan>
SamB: i think only java and c++

[10:52:18.0000] <zcorpan>
actually dunno if the c++ version has the streaming mode

[10:52:18.0000] <Hixie>
SamB: most of the cost is my DOM, i think. The source is only 6MB, so even if i have two or three copies of it, I wouldn't get to 90MB just from that.

[10:52:20.0000] <SamB>
zcorpan: that's one more language than I expected you to mention

[10:52:35.0000] <Hixie>
if i used validator.nu's parser i'd do it in Java or C++

[10:52:56.0000] <SamB>
Hixie: I didn't expect the source to even be included in that figure

[10:53:03.0000] <zcorpan>
SamB: firefox uses the c++ parser

[10:53:09.0000] <Hixie>
i dunno how fast validator.nu is though

[10:53:22.0000] <Hixie>
SamB: 90MB is the memory usage of the process after it's parsed the spec

[10:53:28.0000] <Hixie>
so it includes everything

[10:53:40.0000] <Hixie>
though i recently changed how i read the file to just be an mmap, dunno how that affects it

[10:54:07.0000] <Hixie>
medium-term i plan to move to a world where i don't copy the strings at all, since that's about 10% of the total time the process takes right now

[10:54:10.0000] <Hixie>
maybe even 20%

[10:54:15.0000] <SamB>
Hixie: what proxy for "memory usage" are you using?

[10:54:16.0000] <Hixie>
i forget the most recent numbers

[10:54:16.0000] <zcorpan>
https://hsivonen.fi/cost-of-html/ - dunno if it tells you anything you can compare it to

[10:54:23.0000] <Hixie>
SamB: resident size

[10:54:25.0000] <zcorpan>
might also be out of date

[10:54:36.0000] <Hixie>
hm, interesting

[10:54:37.0000] <Hixie>
/me looks

[10:55:13.0000] <SamB>
and, er, which OS is this?

[10:55:53.0000] <zcorpan>
Hixie: http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html#dependencies-0 should be moved. should i file bugs or is irc ok?

[10:56:24.0000] <Hixie>
SamB: debian

[10:56:43.0000] <SamB>
ah, my favorite :-)

[10:57:13.0000] <Hixie>
zcorpan: file a bug, i'll do it when it's more stable

[10:57:22.0000] <Hixie>
zcorpan: doesn't hurt to have it there for now

[10:57:26.0000] <zcorpan>
Hixie: k

[10:57:38.0000] <Hixie>
zcorpan: i'll review the <picture> section in detail at some point

[10:57:52.0000] <zcorpan>
Hixie: great, thanks

[10:58:09.0000] <Hixie>
no, thank _you_! i'm so glad i don't have to do this

[10:59:23.0000] <SamB>
Hixie: anyway, I think I might look at the private size rather than the resident size

[10:59:54.0000] <Hixie>
SamB: if i really cared about memory usage, i'd probably just instrument the internals

[10:59:56.0000] <zcorpan>
Hixie: my pleasure

[11:00:03.0000] <Hixie>
SamB: my main concern is speed

[11:00:05.0000] <SamB>
yeah

[11:00:09.0000] <Hixie>
and four seconds is about 3.99 seconds too slow

[11:00:10.0000] <Hixie>
:-)

[11:00:24.0000] <zcorpan>
/me gotta go

[11:00:47.0000] <SamB>
Hixie: maybe you're thrashing the cache

[11:00:52.0000] <annevk>
TabAtkins: so btw, I'm happy to help out with URL / Fetch integration / CSS model setup

[11:01:01.0000] <annevk>
TabAtkins: however, I have a pretty serious timezone problem

[11:01:10.0000] <TabAtkins>
Yeah. ^_^

[11:01:36.0000] <Hixie>
SamB: yeah, need to run it under valgrind-cachegrind

[11:01:51.0000] <Hixie>
SamB: right now i still have a low-hanging fruit in the form of the string copying to deal with

[11:02:15.0000] <annevk>
TabAtkins: I'll see if I can type out some advice soonish and we can do it the very slow way on www-style

[11:02:30.0000] <Hixie>
SamB: not gonna try to figure out cachegrind until i've got everything i can out of callgrind :-)

[11:04:08.0000] <SamB>
Hixie: I'm almost surprised they're distinct frontends, honestly

[11:04:14.0000] <SamB>
they have a hell of a lot of overlap

[11:04:37.0000] <Hixie>
yeah?

[11:04:41.0000] <Hixie>
i've never used cachegrind

[11:04:50.0000] <Hixie>
then again i'd never used callgrind until a few days ago

[11:05:03.0000] <SamB>
not saying that they have enough that you can just use cachegrind for everything

[11:05:34.0000] <SamB>
but they've got more in common than any two other valgrind tools I can think of

[11:06:30.0000] <TabAtkins>
annevk: The very slow way is better for me, because it means I don't have to hold things in my head until I'm ready to do them. ^_^

[11:07:11.0000] <annevk>
TabAtkins: sounds good

[11:07:41.0000] <Hixie>
SamB: it did seem that way from the docs, yeah

[11:10:03.0000] <annevk>
<picture> changes not being announced on @WHATWG seems bad

[11:10:19.0000] <Hixie>
yeah, that's an artefact of my currnet pipeline and how they're being merged in

[11:10:30.0000] <Hixie>
i'll add it to the list of things to fix

[11:10:36.0000] <Hixie>
(or, file a bug to remind me)

[11:10:42.0000] <Hixie>
(put "tools" in the whiteboard)

[11:11:47.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26121

[11:13:15.0000] <Hixie>
thanks

[14:04:52.0000] <aleray_>
hi, I would like to markup seconds (or milliseconds if needed) in rdfa, like <span property="aa:begin" content="5.2">00:00:05,2</span>. how can I specify the content is a float/a second value?

[14:05:22.0000] <Ms2ger>
I doubt you'll find a lot of rdfa enthusiasts here

[14:05:57.0000] <scor>
aleray_: use the datatype attribute, for example datatype="xsd:float"

[14:06:45.0000] <jgraham>
Wow RDFa and XSD? Good thing I left my sense of logic at the door

[14:06:56.0000] <aleray_>
scor, thanks. probably a stupid question, but Is there anything specific datattype for time?

[14:07:05.0000] <SamB>
Ms2ger: because people around here don't like RDF, or because they dislike RDFa in particular?

[14:07:30.0000] <jgraham>
I think yes to both

[14:08:03.0000] <SamB>
aren't the datatypes the only thing worth using from XML Schema?

[14:08:39.0000] <scor>
aleray_: is it a duration, or a time that you want to represent?

[14:09:52.0000] <aleray_>
scor, a timecode: begin and end times

[14:09:56.0000] <scor>
aleray_: either way, #swig is a probably a better channel to ask your questions

[14:10:17.0000] <aleray_>
scor, oups, that the chan I inteded to join

[14:10:24.0000] <aleray_>
thanks


2014-06-18
[17:01:46.0000] <Hixie>
success! my pipline now outputs the same as anolis

[17:01:52.0000] <Hixie>
...for the first line of the file, anyway

[18:23:13.0000] <MikeSmith>
Hixie: validator.nu is fast enough that it can check the entire HTML spec in less than 3 seconds

[18:24:55.0000] <MikeSmith>
Hixie: the part of that time that's taken up by parsing is milliseconds

[19:19:29.0000] <Manishearth>
annevk: around?

[19:50:28.0000] <Hixie>
gsnedders: hey do you know what order anolis uses for attributes when serialising?

[19:50:33.0000] <Hixie>
MikeSmith: really?

[19:50:41.0000] <Hixie>
MikeSmith: it always seems to take quite a lot longer, to me...

[19:51:42.0000] <Hixie>
MikeSmith: hm, no, i guess you're right

[19:52:03.0000] <Hixie>
MikeSmith: that's pretty impressive

[19:52:21.0000] <MikeSmith>
the power of hsivonen

[19:52:31.0000] <Hixie>
of course this is a different machine

[19:52:34.0000] <Hixie>
so i dunno how it compares

[19:52:48.0000] <MikeSmith>
true

[19:54:01.0000] <Hixie>
what tricks does the parser use?

[19:54:11.0000] <Hixie>
i mean, things like interning the strings to do string comparisons, dispatch tables, etc

[19:54:52.0000] <MikeSmith>
that you would need to ask Henri about

[19:55:20.0000] <MikeSmith>
I'm really only familiar with the parts of the parser code that I've patched, which isn't very many parts, and mostly trivial

[19:56:30.0000] <MikeSmith>
though I'm not reminded that I'm waiting on Henri to make a decision about handling of un-ambiguous ampersands in the parser to bring it into conformance with the HTML spec

[19:57:35.0000] <Hixie>
i don't understand the whitespace stripping that anolis does

[19:57:46.0000] <Hixie>
actually i guess it's probably libhtml or whatever parser anolis uses

[19:57:54.0000] <MikeSmith>
(the validator error messages about, e.g., the ampersand in "http://x?foo&bar" being invalid are actually generated by the parser, which is an error-reporting implementation)

[19:58:03.0000] <MikeSmith>
Hixie: bingo

[19:58:48.0000] <Hixie>
still, i don't understand it

[19:59:11.0000] <MikeSmith>
in my experience there are a lot of WTFs in the results from the 3rd-party library code that anolis and the splitter use

[20:00:21.0000] <Hixie>
yeah but if i don't reproduce those wtfs precisely, it's gonna be a pain to check the results :-)

[20:00:49.0000] <MikeSmith>
ah

[20:01:54.0000] <Manishearth>
Hey, I'm a bit unclear about the xhr spec, anyone who can help with that?

[20:02:04.0000] <Manishearth>
Specifically, http://xhr.spec.whatwg.org/#the-send()-method step 13

[20:02:17.0000] <MikeSmith>
Hixie: I dealt with them in the past just be doing some post-processing. but I never noticed weirdness in teh WS handling

[20:02:41.0000] <Manishearth>
The handling for synchronous requests is not totally clear to me since it seems to omit some important steps

[20:03:00.0000] <MikeSmith>
Manishearth: annevk would be the one to ask but pretty sure he's sleeping at these hours

[20:03:12.0000] <Manishearth>
yeah

[20:03:26.0000] <Manishearth>
Ms2ger isn't around either, usually I ask him :)

[20:04:05.0000] <MikeSmith>
Manishearth: I wonder why you want to handle synchronous requests

[20:05:41.0000] <Manishearth>
MikeSmith: because I'm implementing XHR, and web-platform-tests wants them

[20:05:51.0000] <Manishearth>
:)

[20:06:31.0000] <Manishearth>
wpt uses sync fetch often to get better workflow. I agree that sync fetch is a rather bad way of doing things on the web

[20:07:35.0000] <MikeSmith>
indeed

[20:07:48.0000] <MikeSmith>
I didn't know wpt was doing that

[20:08:06.0000] <Manishearth>
The one that's breaking for me right now is https://github.com/w3c/web-platform-tests/blob/master/XMLHttpRequest/abort-after-send.htm

[20:08:13.0000] <MikeSmith>
/me looks

[20:08:17.0000] <Manishearth>
because I'm not setting the readystate properly

[20:08:34.0000] <Manishearth>
When the spec says "If req's synchronous flag is set, pass the return value, synchronously, to process response end-of-file below."

[20:09:07.0000] <Manishearth>
I'm not sure if I'm suposed to skip the other "process" steps. I'm doing the steps, storing the data, but not sure if I should be changing ready state and firing events

[20:09:25.0000] <Manishearth>
readystatechange/onprogress doesn't make much sense for sync anyway

[20:09:40.0000] <MikeSmith>
right

[20:10:42.0000] <Manishearth>
So for sync should the only effect on the XHR object be the changing of the ready state to Done when it finishes?

[20:11:48.0000] <Manishearth>
or should I be changing the ready state each step for sync, but not firing the event?

[20:13:02.0000] <MikeSmith>
/me tries to think of who else might be around right now who's implemented XHR

[20:13:34.0000] <MikeSmith>
ah wait you're the one who's working on the XHR ipmlementation for servo?

[20:14:16.0000] <MikeSmith>
/me scratches off his "ask that guy who's working on the XHR implementation in servo" suggestion

[20:15:05.0000] <Manishearth>
pahaha

[20:15:07.0000] <MikeSmith>
smaug's not awake yet either

[20:18:51.0000] <Manishearth>
np, I'll wait till Ms2ger comes back then. I have one way of fixing the immediate issue, but I think it's best if I'm clear about that part of the spec

[22:29:00.0000] <zcorpan>
Hixie: maybe you can run anolis with html5lib instead for comparison of the result?

[23:33:59.0000] <annevk>
Manishearth: around now

[23:34:58.0000] <annevk>
Manishearth: yeah, even for synchronous you should dispatch readystatechange et al in the end

[23:35:42.0000] <annevk>
Manishearth: but yeah, that could be done better

[23:38:03.0000] <jamesr_>
Manishearth: sync XHR is one of those fun APIs that runs javascript reentrantly

[23:38:13.0000] <jamesr_>
the blink implementation is pretty straightforward, i can check things if you'd like

[23:38:15.0000] <annevk>
jamesr_: not per spec

[23:38:39.0000] <jamesr_>
annevk: oh? in webkit/blink the rsc events fire 'under' the send() call, i believe

[23:38:49.0000] <jamesr_>
/me cooks up test

[23:39:11.0000] <annevk>
jamesr_: per spec there's only a final set of events just before send() returns

[23:39:31.0000] <annevk>
jamesr_: but since the events are sync too, that's not re-entrant

[23:39:58.0000] <jamesr_>
the event handlers run before control returns to whoever calls send(), no?

[23:40:07.0000] <annevk>
jamesr_: sure

[23:40:41.0000] <annevk>
jamesr_: I guess that's a bit re-entrant, but no more than some custom function I have invoking dispatchEvent()

[23:40:43.0000] <jamesr_>
ok. i guess it's a terminology difference, then. to me that's reentrant

[23:40:54.0000] <jamesr_>
right, since they are event handlers

[23:40:55.0000] <annevk>
jamesr_: fair, I was thinking nested event loop

[23:41:09.0000] <annevk>
jamesr_: which is what Gecko has at the moment and is definitely not supported by the spec

[23:41:10.0000] <jamesr_>
nah. we don't run anything else while the xhr is out

[23:41:27.0000] <jamesr_>
in chromium, the entire process's blink thread is locked

[23:50:20.0000] <annevk>
So six months after the purported deadline of ES6, class design is being reconsidered

[23:51:34.0000] <annevk>
When I said a while back it would take at least a year for people to get around to do proper subclassing everywhere, people got angry

[23:54:38.0000] <Manishearth>
annevk: lunchtime for me, will get back to you on this. Thanks!

[23:58:42.0000] <jamesr_>
is servo attempting the storage mutex stuff? or skipping it?

[00:05:11.0000] <annevk>
/me doesn't know

[00:10:21.0000] <krit>
annevk: morning

[00:10:46.0000] <krit>
annevk: I added a question to the pad on the first algorithm

[00:11:42.0000] <krit>
annevk: if the associated document is document.svg would url(document.svg#frag) be treated as element reference?

[00:12:06.0000] <krit>
annevk: ..assuming the specified value is on an external CSS

[00:12:46.0000] <krit>
annevk: it certainly can’t be used as image since it would reference itself

[00:13:06.0000] <annevk>
krit: why can't it be fetched and treated as image?

[00:13:36.0000] <annevk>
krit: more important, what do implementations do now?

[00:14:26.0000] <krit>
annevk: depends on the property… need to check an example with image… one moment

[00:15:11.0000] <annevk>
I'm again surprised these questions haven't come up before, but I guess it's good we are addressing them now

[00:18:39.0000] <krit>
annevk: there are no properties that reference images in SVG

[00:19:05.0000] <krit>
annevk: With the exception of ‘cursor'

[00:19:51.0000] <annevk>
krit: okay, but is it treated as an external reference today or an internal?

[00:20:24.0000] <annevk>
krit: if url(style.css#frag) is internal, surely that must be external

[00:20:31.0000] <krit>
annevk: that depends on the property. There is no implemented property that can be either of both today

[00:20:48.0000] <annevk>
krit: not even in Gecko?

[00:21:12.0000] <krit>
annevk: not even in Gecko…. however, give me a couple of minutes and I reproduce it with fill and cursor

[00:22:47.0000] <annevk>
krit: okay, but we should still be able to answer the question, if url(style.css#frag) is internal, then url(document.svg#frag) is either external or should not work

[00:22:56.0000] <annevk>
krit: can we at least confirm that much?

[00:23:01.0000] <krit>
annevk: ok, self referencing with cursor doesn’t work

[00:23:32.0000] <annevk>
krit: are you testing in a browser that supports SVG for cursors?

[00:23:36.0000] <krit>
annevk: needs checking in FF as well. I already told you what Blink and WebKit would do

[00:23:50.0000] <krit>
annevk: I would need to search a browser that doesn't

[00:24:03.0000] <krit>
annevk: of course it supports SVG

[00:24:15.0000] <annevk>
krit: does it start working if the style sheet is then associated with a different document?

[00:25:51.0000] <annevk>
Are the tests online?

[00:26:13.0000] <krit>
annevk: no, can paste them

[00:26:51.0000] <krit>
https://www.irccloud.com/pastebin/vf3hQKYS

[00:27:19.0000] <krit>
style.css#grad doesn’t work, self.html#grad does in Firefox

[00:27:42.0000] <annevk>
and #grad does too?

[00:28:14.0000] <krit>
annevk: yes

[00:28:23.0000] <annevk>
:-(

[00:28:28.0000] <krit>
annevk: same behavior in Blink WebKit (to my surprise)

[00:29:15.0000] <krit>
annevk: so the algorithm does not what FF, Chrome and Safari do today

[00:32:58.0000] <annevk>
krit: in http://dump.testsuite.org/svg/url-parsing.html with #grad it does not work in Firefox

[00:33:38.0000] <krit>
annevk: it does

[00:33:43.0000] <krit>
annevk: it is red

[00:33:50.0000] <annevk>
krit: refresh

[00:34:01.0000] <annevk>
In Nightly there is no red

[00:34:13.0000] <annevk>
Only if I change it to url-parsing.html#grad

[00:34:34.0000] <annevk>
That means Firefox actually does sensible URL parsing here

[00:35:23.0000] <krit>
annevk: hm, interesting… it does work locally

[00:35:53.0000] <krit>
no it doesn't

[00:36:11.0000] <annevk>
Yay Firefox for sanity

[00:37:50.0000] <krit>
annevk: It does work in Safari, Chrome and IE

[00:38:08.0000] <annevk>
krit: I recommend we get them to fix this bug

[00:38:47.0000] <krit>
ed: willing to change the behavior on Blink —^

[00:38:54.0000] <krit>
*in

[00:39:07.0000] <annevk>
not sure ed is in this channel

[00:39:20.0000] <krit>
argh, wait

[00:39:33.0000] <krit>
he is offline :(

[00:39:40.0000] <annevk>
ah okay

[00:39:54.0000] <krit>
I know why this happens in WebKit and Blink and the implementation needs to be fixed anyway

[00:40:15.0000] <annevk>
Yeah, you told me they parse the URL and then grab the fragment not doing any comparisons

[00:40:17.0000] <krit>
annevk: I wouldn’t mind changing the behavior in WebKit when I get to implement it

[00:40:36.0000] <annevk>
Very happy Firefox didn't fuck it up

[00:40:43.0000] <krit>
annevk: this is not fully true anymore…. style.css#frag doesn’t work either

[00:41:11.0000] <annevk>
Fair, so they must special case # at the start somehow

[00:42:01.0000] <krit>
annevk: yes, I assume we check the baseURL at the beginning… later we just care about the fragment identifier

[00:42:44.0000] <krit>
annevk: I am willing to change that

[00:43:24.0000] <krit>
annevk: so /document/ is still not correct in the algorithm… it must always check associated document URL

[00:43:38.0000] <krit>
annevk: which can be /document/ but doesn’t need to

[00:43:42.0000] <annevk>
krit: yeah, we should probably split CSS and element handling

[00:43:59.0000] <annevk>
krit: otherwise this gets too confusing

[00:44:22.0000] <krit>
annevk: yes, we would split it anyway and the behavior needs to go to CSS directly

[00:44:47.0000] <krit>
annevk: as a general behavior for future usage of url()

[00:46:40.0000] <annevk>
krit: yeah, my plan is to write an email to www-style about this and work with TabAtkins to make it happen

[00:47:05.0000] <annevk>
krit: but before I do that I think it would be good for us to write the actual algorithms to make sure we're not missing anything

[00:48:10.0000] <krit>
annevk: k.

[00:48:31.0000] <krit>
annevk: Btw. with stacked SVGs, fragment sniffing is still possible cross domain

[00:48:43.0000] <krit>
annevk: the one thing the abarth thought would be a problem

[00:49:00.0000] <krit>
annevk: not sure if it really is a problem since you can mostly do it with JS today

[00:49:11.0000] <krit>
annevk: or even manually

[00:50:59.0000] <krit>
annevk: just clip-path: url() is still a problem since it changes geometry… but this would require sensitive data within the clip-path

[00:51:44.0000] <krit>
...so encoding a password in the path data of clip-path

[00:52:14.0000] <krit>
which we of course can not prevent someone from doing…. but it is extremely unlikely as well

[00:57:36.0000] <annevk>
how can you do fragment sniffing using :target?

[00:58:04.0000] <krit>
annevk: no, abarth use case was the active involvement of the user

[00:58:26.0000] <krit>
annevk: with :target you can make certain element visible or invisible

[00:58:37.0000] <annevk>
but you don't know anything about the remote file

[00:58:55.0000] <krit>
annevk: not without the help of the user

[00:59:10.0000] <krit>
annevk: the link from abarth https://news.ycombinator.com/item?id=7855168

[00:59:15.0000] <annevk>
I don't understand, the remote file would have to use :target

[00:59:32.0000] <krit>
annevk: yes, that is true

[00:59:38.0000] <annevk>
I don't really follow the attack scenario

[01:00:17.0000] <annevk>
Anyway, back in a bit

[01:44:57.0000] <Manishearth>
annevk: So do you think that in the sync case, all readystatechange events should be fired?

[01:45:08.0000] <Manishearth>
because thir handlers will only be executed after the sync finishes

[01:45:34.0000] <Manishearth>
or should the *last* one be the only one to fire?

[01:49:37.0000] <annevk>
krit: I updated the algorithms

[01:49:44.0000] <annevk>
krit: they now work for either style sheets or documents

[01:49:52.0000] <krit>
looking

[01:49:59.0000] <annevk>
Manishearth: only the last

[01:50:30.0000] <Manishearth>
annevk: Alrighty. Same answer for progress events?

[01:50:38.0000] <Manishearth>
(only fire the last triplet of events)

[01:51:02.0000] <annevk>
Manishearth: the idea is that sync would invoke "To process response end-of-file for response, run these substeps: "

[01:51:17.0000] <annevk>
Manishearth: there's a bug now though that state would not be LOADING

[01:51:27.0000] <Manishearth>
annevk: exactly :)

[01:51:32.0000] <Manishearth>
that's how I found it out

[01:52:01.0000] <annevk>
Manishearth: yeah I should rewrite this a bit to make it more clear what the synchronous handling is

[01:52:22.0000] <Manishearth>
My ready state in sync wasn't changing because I had implemented the spec, and I thought I had misinterpreted the "If req's synchronous flag is set, pass the return value, synchronously, to process response end-of-file below."

[01:54:02.0000] <annevk>
Manishearth: how would you like to be acknowledged?

[01:54:13.0000] <annevk>
Manish Goregaokar?

[01:54:15.0000] <Manishearth>
annevk: I think a simple `If state is LOADING or the sync flag is set, run these subsubsteps:` would work

[01:54:20.0000] <Manishearth>
annevk: yeah

[01:54:22.0000] <Manishearth>
thanks

[01:54:22.0000] <krit>
annevk: to confirm, for #get-svg-element it is not possible for authors to specify a dataURL or blob… in general it seems just possible for fetching images

[01:54:48.0000] <krit>
annevk: note: no idea if dataURL or blog would make sense

[01:54:49.0000] <krit>
hee

[01:54:51.0000] <krit>
here

[01:55:23.0000] <annevk>
why would it not be possible?

[01:56:32.0000] <krit>
annevk: in your algorithm it would run into fetch, no?

[01:56:50.0000] <annevk>
krit: yes, and Fetch handles data and blob URLs

[01:56:55.0000] <krit>
annevk: fetch is not permitted if /internal only flag/ is true

[01:57:14.0000] <krit>
annevk: that means dataURL and blob are not allowed for SVG as image

[01:57:24.0000] <krit>
image/svg+xml

[01:57:26.0000] <annevk>
krit: no it doesn't

[01:57:38.0000] <annevk>
krit: the internal only flag is for cases that don't handle external references

[01:57:52.0000] <annevk>
krit: it's not for SVG as image

[01:57:54.0000] <krit>
ok, got it

[01:58:33.0000] <annevk>
lets rename that one to local only flag

[01:58:34.0000] <krit>
annevk: #get-local-svg-element seems to allow style.css#frag

[01:58:43.0000] <annevk>
no it doesn't

[01:59:07.0000] <annevk>
 /baseURL/ would be the style sheet's URL and /document/ would be the style sheet's associated document

[01:59:10.0000] <krit>
annevk: oh, because we do not look at external CSS anymore?

[01:59:17.0000] <krit>
ahh

[01:59:18.0000] <krit>
ok

[01:59:43.0000] <krit>
annevk: is that defined that way in Fetch alread?

[01:59:54.0000] <krit>
annevk: or does the algorithm need to do that

[02:00:07.0000] <annevk>
Is what defined?

[02:00:17.0000] <annevk>
Manishearth: it might take me a while to get to this, I'd like to fix it more properly than that

[02:00:33.0000] <Manishearth>
annevk: Ah, I see. No problem

[02:00:35.0000] <krit>
annevk: this “/document/ would be the style sheet's associated document"

[02:00:46.0000] <Manishearth>
We might have to change the wording for the error handling too

[02:01:02.0000] <annevk>
krit: no, that all needs to be handled by SVG and CSS

[02:01:25.0000] <annevk>
krit: Fetch only deals with getting a bag of bits out of a URL

[02:01:35.0000] <annevk>
krit: and all the hassle that comes with that, it doesn't have magic built in

[02:02:14.0000] <krit>
no magic, k :D

[02:02:41.0000] <annevk>
krit: what Fetch handles is indicated with [FETCH]

[02:02:53.0000] <krit>
thanks

[02:03:15.0000] <annevk>
everything else, including the line indicated with [FETCH] (so everything really) needs to be in SVG / CSS

[02:05:13.0000] <annevk>
krit: actually, maybe these algorithms should take a parsedURL and a document, that seems better

[02:06:07.0000] <krit>
annevk: fetching an SVG element: “...MIME type is not image/svg+xml” what about application/xml

[02:06:17.0000] <krit>
annevk: SVG can still be an XML documen

[02:06:18.0000] <krit>
t

[02:06:42.0000] <krit>
annevk: or, inline SVG, where the fetched SVG element is in an HTML document

[02:06:46.0000] <annevk>
I thought that was outlawed

[02:07:40.0000] <krit>
annevk: The CSS example that you uploaded used it. ok was local, but I think FF supports it for other HTML documents as well

[02:08:18.0000] <krit>
annevk: only Firefox would support it…

[02:08:21.0000] <annevk>
local is completely different

[02:08:40.0000] <annevk>
krit: depends, how does <use> work?

[02:09:12.0000] <krit>
annevk: uses the processing algorithm from SVG that you referenced yesterday

[02:10:28.0000] <krit>
annevk: not restricted to mime type it seems

[02:10:47.0000] <krit>
annevk: http://www.w3.org/TR/SVG/linking.html#processingIRI

[02:11:25.0000] <annevk>
krit: what about implementations?

[02:11:48.0000] <krit>
annevk: again, just Firefox would have implemented it… maybe Presto

[02:11:54.0000] <krit>
annevk: creating an example

[02:12:12.0000] <annevk>
krit: I thought ed demonstrated external <use> support in Blink?

[02:12:32.0000] <krit>
oh right… was about to check for CSS

[02:17:21.0000] <krit>
annevk: for CSS I don’t even get it to work with paint server in another SVG file right now...

[02:17:41.0000] <krit>
annevk: same for paint server in an SVG

[02:17:48.0000] <krit>
s/SVG/HTML/

[02:19:01.0000] <krit>
annevk: ok, paint server in SVG document works… in HTML doesn't

[02:19:13.0000] <krit>
annevk: for CSS on Firefox

[02:19:28.0000] <annevk>
krit: so I thought the idea was that external SVG elements would follow the SVG as image path

[02:19:34.0000] <annevk>
krit: which means only image/svg+xml

[02:20:12.0000] <krit>
annevk: the same mode…

[02:20:20.0000] <krit>
annevk: same mode as  image/svg+xml

[02:20:27.0000] <krit>
annevk: but let me check <use> first

[02:23:48.0000] <krit>
annevk: example with <use> to other <svg> https://dl.dropboxusercontent.com/u/39760138/self/selfReference.html

[02:24:00.0000] <krit>
annevk: seems not to work in FF, but in Safar/Chrome

[02:25:32.0000] <krit>
annevk: https://dl.dropboxusercontent.com/u/39760138/self/selfReference2.html <use> element reference to HTML

[02:25:37.0000] <krit>
annevk: doesn’t work anywhere

[02:27:27.0000] <krit>
annevk: ok, had a styling issue… first example works in FF now

[02:27:56.0000] <krit>
annevk: 2nd seems to run in loops

[02:28:07.0000] <krit>
annevk: FF doesn’t stop loading

[02:28:13.0000] <krit>
annevk: possibly a bug in FF

[02:29:53.0000] <krit>
annevk: https://dl.dropboxusercontent.com/u/39760138/self/selfReference3.html in this case I have a other.xml that I reference it works… but probably because browsers don’t always trust the mime type

[02:30:46.0000] <krit>
annevk: Firefox loads it with MIME type application/xml

[02:30:50.0000] <krit>
annevk: other.xml

[02:31:00.0000] <annevk>
krit: okay, that does indicate the MIME type check is different for external references from images

[02:31:10.0000] <krit>
so image/svg+xml and application/xml should be possible

[02:31:37.0000] <annevk>
which seems like a good reason keep external references and images distinct

[02:31:51.0000] <annevk>
and potentially apply different fetch modes to them

[02:37:41.0000] <roc>
this again!

[02:38:26.0000] <roc>
I thought we had previously converged on a consensus to make external references and images use the same fetch model

[02:40:40.0000] <annevk>
hey roc

[02:40:56.0000] <annevk>
roc: it seems that is impossible given that we support things like image.svg#test

[02:41:21.0000] <annevk>
roc: http://dahlström.net/svg/structure/svgstack-usage.html

[02:41:56.0000] <annevk>
roc: we're trying to figure out SVG/CSS fetching bits a bit more formally here https://etherpad.mozilla.org/fixing-svg-processing

[02:50:49.0000] <roc>
I thought the resolution was to make everything use the image model

[03:01:12.0000] <annevk>
roc: given mask:url(someurl#test)

[03:01:38.0000] <annevk>
roc: how do we know whether that's an image with #test or an mask identified by #test?

[03:02:26.0000] <roc>
do an image load

[03:02:40.0000] <roc>
if #test is a <mask> element, treat it as a mask

[03:03:03.0000] <roc>
do some kind of same-origin check

[03:03:10.0000] <roc>
We had this worked out somewhere

[03:04:22.0000] <annevk>
Manishearth: should be more clear now

[03:04:58.0000] <annevk>
roc: yes, except http://dahlström.net/svg/structure/svgstack-usage.html seems to kill that solution

[03:05:32.0000] <annevk>
roc: and apparently we allow more than SVG images for these loads (e.g. application/xml resources)

[03:05:42.0000] <roc>
no it doesn't. None of the referenced elements there are <mask>s

[03:05:51.0000] <roc>
or <pattern>s or gradients

[03:06:19.0000] <annevk>
roc: fair

[03:06:26.0000] <annevk>
roc: what about supporting more than image/svg+xml?

[03:08:10.0000] <annevk>
roc: I think the other thing that changed is that we learned image fetching is really rather involved: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24055

[03:08:24.0000] <roc>
I don't think supporting application/xml is important

[03:08:37.0000] <roc>
servers are likely to map *.svg to image/svg+xml anyway

[03:08:37.0000] <annevk>
roc: which means that overloading it with external element references might be painful, but I guess we can deal

[03:09:15.0000] <annevk>
I'm happy to write out that solution

[03:09:20.0000] <roc>
I don't think we'd be overloading it. I assume the image fetch algorithm eventually can produce something with an SVG DOM

[03:09:21.0000] <annevk>
krit: ^

[03:09:40.0000] <annevk>
roc: yeah fair, image fetch has a branch for image/svg+xml

[03:09:55.0000] <roc>
that is, I assume it can produce many results, at least some of which have an SVG DOM

[03:10:36.0000] <roc>
then we just need to be able to do some kind of same-origin check and get read-only access to the DOM

[03:11:10.0000] <annevk>
yeah, we'd parse with scripting disabled

[03:11:19.0000] <roc>
of course animations could be running in the DOM so it's a bit more complicated than that, but it should work

[03:11:34.0000] <annevk>
and then we need some kind of "safe render mode for SVG" that handles the rest

[03:11:49.0000] <annevk>
that disables fetching more resources

[03:12:10.0000] <roc>
yeah, we already have that implemented. I think SVG specced something like that or at least talked about it

[03:12:39.0000] <annevk>
only talk so far, we're trying to write down the basics now

[03:12:40.0000] <krit>
roc: the solution from annevk adds heuristics that would allow assumptions on the fetched resource before fetching it…. local element or image is that

[03:13:00.0000] <krit>
roc: that would be significant easier to implement in WebKit and Blink

[03:13:17.0000] <krit>
roc: without need to rewrite our CSS engine

[03:13:23.0000] <roc>
krit: you mean heuristics to guess whether it's an image load or an external resource load?

[03:13:31.0000] <roc>
I advocated that for a long time myself :-)

[03:13:33.0000] <krit>
roc: yes

[03:13:37.0000] <annevk>
krit: no

[03:13:51.0000] <annevk>
that algorithm only handles local references or images

[03:13:55.0000] <annevk>
not external references

[03:14:14.0000] <annevk>
if you want both you need the solution roc and I came up with a year ago

[03:14:24.0000] <krit>
annevk: of course since your algo. does not allow fetching for things that can get an element or image… so we check the baseURL to figure that part out

[03:14:30.0000] <krit>
annevk: my point

[03:14:36.0000] <roc>
I thought we could say url(...#foo) is an external resource load and too bad about SVG image stacks

[03:14:37.0000] <roc>
however

[03:14:38.0000] <krit>
annevk: I don’t want both

[03:14:45.0000] <annevk>
krit: yes but roc does

[03:14:45.0000] <roc>
I don't want that approach anymore

[03:14:56.0000] <roc>
now I think just using image fetch will be fine

[03:15:08.0000] <roc>
and simpler

[03:15:12.0000] <krit>
roc: would you be fine with no external paint server loads on url() function?

[03:15:17.0000] <krit>
roc: cool

[03:15:23.0000] <roc>
er

[03:15:25.0000] <annevk>
krit: you misunderstand roc

[03:15:29.0000] <krit>
maybe

[03:15:36.0000] <krit>
roc: say again please?

[03:15:45.0000] <roc>
I'm saying you can have external paint servers, it's just that the document is always loaded using the image fetch algorithm

[03:16:13.0000] <krit>
roc: yeah, that is what Anne and I discussed on monday

[03:16:30.0000] <annevk>
krit: if image fetch returns an SVG document and fragment points to a <mask> in it, it's a mask, otherwise an image, stuff like that

[03:16:33.0000] <roc>
so fill:url(foo.svg#bar) would load foo.svg as an image, and then if the 'bar' element is a paint server, it gets used as a paint server, otherwise it's treated as the foo.svg#bar image

[03:16:35.0000] <krit>
roc: again, would require to rewrite parts of WebKit and Blinks CSS engine

[03:17:03.0000] <krit>
roc: Blink doesn’t seem to be keen about external element fetches for url() either

[03:17:25.0000] <krit>
*as well

[03:17:29.0000] <roc>
I don't see what the problem is

[03:17:35.0000] <annevk>
krit: Blink is fine with it as long as the security check is there

[03:17:49.0000] <annevk>
abarth said as much the other day

[03:17:50.0000] <krit>
roc: no, abarth is

[03:17:55.0000] <roc>
Blink/Webkit don't currently support "external resource reference" loads, but they do support SVG image loads. Gecko supports both

[03:17:56.0000] <krit>
annevk: —^

[03:18:07.0000] <krit>
roc: right, we don't

[03:18:25.0000] <roc>
I'm proposing we eliminate external resource reference loads and only use SVG image loads, which Webkit/Blink already have. This is a great proposal for those guys :-)

[03:18:48.0000] <krit>
roc: that is Annes solution

[03:18:59.0000] <krit>
roc: element references just in the current SVG document

[03:19:07.0000] <krit>
roc: no external element references

[03:19:08.0000] <annevk>
krit: no it's not

[03:19:11.0000] <annevk>
geez

[03:19:43.0000] <roc>
krit: I think you're confused but I don't know exactly how :-)

[03:19:52.0000] <krit>
annevk: #get-svg-element To get an SVG element given a /url/, a /document/, and an optional /internal only flag/: does exactly that

[03:20:07.0000] <annevk>
krit: no it doesn't support external SVG elements

[03:20:22.0000] <annevk>
krit: roc is proposing we do

[03:20:48.0000] <krit>
roc: fill: url(externDocument.svg#pattern) is not supported in WebKit and Blink… but in FF… do you want it to work or don’t you care?

[03:20:56.0000] <annevk>
krit: you apply the same fetch algorithm as for images, and then you do post processing to determine whether or not it's an image or an external ref

[03:21:28.0000] <roc>
what Anne said

[03:21:38.0000] <krit>
roc: too bad :(

[03:21:44.0000] <roc>
?

[03:22:19.0000] <krit>
roc: I am not advocating for allowing external paint servers

[03:22:28.0000] <roc>
you mean you're against it?

[03:22:28.0000] <krit>
roc: so your opinion is not mine :)

[03:22:42.0000] <krit>
roc: even so I agree that it works in theory

[03:24:02.0000] <krit>
roc: don’t believe that the implementation efforts for fetching the resource and figuring out what it is are worth it in WebKit

[03:24:03.0000] <roc>
ok

[03:24:11.0000] <krit>
roc: simple cost to usage calculation

[03:24:34.0000] <roc>
that's a reasonable position

[03:25:25.0000] <annevk>
roc: would you apply the same restrictions on <use>?

[03:26:09.0000] <roc>
Given we already support external references in some form, the Gecko situation is a bit different and we might reach a different conclusion.

[03:27:25.0000] <krit>
annevk: <use> is a different code path for us. However, <pattern> and co. with xlink:href still don’t need to reference external elements IMO

[03:27:50.0000] <krit>
roc: yes, right now I am entirely speaking as implementer...

[03:28:08.0000] <krit>
…implementer for WebKit and Blink

[03:28:47.0000] <roc>
annevk: I would just say that <use> does an SVG image load and uses any element it can find. I don't think <use> is or will be specced to actually use an image.

[03:29:17.0000] <annevk>
roc: yeah, just wondering if it would be restricted to image/svg+xml as well, but that sounds good to me

[03:29:32.0000] <krit>
roc: so we could agree on the general "fetch as image” algorithm. It might be implemented in two stages in WebKit and Blink… 2nd stage being external element

[03:29:33.0000] <krit>
s

[03:29:53.0000] <krit>
roc: annevk: speaking for the CSS part of it

[03:30:11.0000] <roc>
annevk: yeah, I think there's no point in speccing a fetch algorithm just for <use>

[03:30:47.0000] <annevk>
roc: sgtm

[03:31:45.0000] <krit>
roc: What about <pattern>, <linearGradient>/

[03:32:13.0000] <krit>
roc: both are not allowed to reference external elements in SVG… at least it could be interpreted that way

[03:32:20.0000] <krit>
roc: (SVG is not specific enought)

[03:32:50.0000] <krit>
roc: does Firefox allow referencing elements in other documents? <pattern xlink:href=“other.svg#patter”/>

[03:33:17.0000] <roc>
yeah I think so

[03:33:28.0000] <roc>
in Gecko we have nsReferencedElement which handles tracking dynamic ID changes etc

[03:33:37.0000] <roc>
it also handles external resource loads automatically

[03:33:53.0000] <krit>
roc: ok

[03:34:17.0000] <krit>
roc: I guess WebKit can generalize the code more to handle these elements as well

[03:35:33.0000] <krit>
annevk: ok, looks like one algorithm could be enough with a sub algorithm for image handling

[03:36:28.0000] <krit>
roc: another question mask: url(other.svg#maskDoesNotExist) would you interpret that as image with the new mask-image syntax?

[03:36:33.0000] <annevk>
krit: yeah, and we'd disable the image path for <use> and such

[03:36:54.0000] <annevk>
krit: yes that would be an image

[03:37:13.0000] <annevk>
krit: otherwise "stacked images" would not work

[03:37:19.0000] <krit>
annevk: exactly

[03:37:38.0000] <annevk>
we already covered that earlier

[03:38:32.0000] <krit>
annevk: also, ignore abarth external image fragment sniffing?

[03:38:55.0000] <krit>
annevk: (me doesn’t think it is a strong case anyway)

[03:39:18.0000] <annevk>
krit: well we could require CORS opt-in for the external ref case (and only make images work for opaque responses)

[03:39:39.0000] <annevk>
krit: depends a bit on security guys

[03:39:47.0000] <krit>
annevk: yes

[03:40:53.0000] <annevk>
I guess this requires some additional parameter to the algorithm to indicate what is expected

[03:41:21.0000] <krit>
annevk: we require that later anyway when url() gets CORS arguments, don’t we?

[03:41:46.0000] <annevk>
krit: if we don't require it now, CORS won't make a difference later

[03:41:47.0000] <krit>
annevk: so the algorithm can already pretend that this is an argument

[03:42:20.0000] <krit>
annevk: well what is the point of the parameters for url() anyway then

[03:42:33.0000] <annevk>
we need it at least for @import

[03:42:43.0000] <krit>
annevk: ok

[03:42:51.0000] <annevk>
we might need it for the external ref case, that depends on security analysis

[03:43:01.0000] <annevk>
it seems we need it for clip too

[03:44:55.0000] <krit>
annevk: shape-outside as well

[03:45:18.0000] <krit>
annevk: which has same-origin restrictions at the moment IIRC

[03:45:56.0000] <krit>
annevk: http://dev.w3.org/csswg/css-shapes/#shape-outside-property

[03:46:04.0000] <krit>
annevk: see <image>

[03:46:19.0000] <krit>
annevk: CORS enabled fetch

[03:47:06.0000] <annevk>
Fonts have something similar, so I guess CSS is already a bit of a mismatch between things

[03:49:24.0000] <krit>
/me head out for lunch

[03:58:26.0000] <Ms2ger>
SVG iframe element? Wat?

[04:00:47.0000] <roc>
yes, I'm not a fan either

[04:01:51.0000] <Ms2ger>
Do we expect Intent to Implement for preffed-off features?

[04:03:39.0000] <annevk>
Ms2ger: wrong channel? But I think so

[04:03:58.0000] <Ms2ger>
I'm pretty sure I haven't seen one for SVG iframes

[04:38:14.0000] <Ms2ger>
Anyone else having trouble reaching krijn?

[04:39:22.0000] <annevk>
Ms2ger: he seems to be doing some cycling

[04:39:51.0000] <Ms2ger>
Carrying his server?

[04:56:40.0000] <krit>
Ms2ger: roc: Not a fan of it as well. But maybe from a different perspective? I don’t like the duplication of code… tho could be done with <foreignObject …><html><iframe/></html></foreignObject> today. At least in theory. Just Firefox allows iframe as ancestor of <foreignObject>.

[04:59:09.0000] <roc>
Ms2ger: powercycling perhaps?

[04:59:21.0000] <roc>
krit: you mean descendant

[04:59:28.0000] <krit>
roc: right

[05:03:33.0000] <Ms2ger>
krit, sure, but fixing browser bugs by implementing new features doesn't really work

[05:05:20.0000] <krit>
Ms2ger: I don’t like having iframe in HTML NS and another one in SVG NS. Even though both use the same code in the background. And I am not saying that it is intend to be a work around for browser bugs.

[05:06:09.0000] <Ms2ger>
Oh, misread, then

[05:08:06.0000] <roc>
annevk: oh boy. https://svgwg.org/svg2-draft/embedded.html

[05:08:15.0000] <roc>
annevk: I did not know about this.

[05:08:37.0000] <Ms2ger>
SVG 2 Requirement: 	- Have a video element in SVG namespace with the same characteristics as the HTML 5 video element.

[05:08:37.0000] <Ms2ger>
- Support 'canvas' element in SVG 2

[05:08:39.0000] <Ms2ger>
Nice

[05:09:19.0000] <Ms2ger>
/me volunteers roc to keep an eye on the SVGWG

[05:16:54.0000] <annevk>
roc: not sure if we should do any of that

[05:17:03.0000] <roc>
it looks crazy to me

[05:17:51.0000] <Ms2ger>
Yay, namespaces!

[05:18:09.0000] <krit>
annevk: well, we should keep image!

[05:18:20.0000] <krit>
the rest won’t survive the CR period

[05:18:50.0000] <krit>
(and foreignObject should stay as well… for legacy)

[05:19:16.0000] <Ms2ger>
Let's kick it out before CR?

[05:19:21.0000] <roc>
people are trying to implement SVGIframeElement for Gecko

[05:19:27.0000] <roc>
we need to kick it out now

[05:19:40.0000] <krit>
roc: they do?

[05:19:47.0000] <roc>
yep

[05:19:47.0000] <annevk>
roc: why was there no email to dev.platform?

[05:19:48.0000] <Ms2ger>
Yes

[05:19:49.0000] <roc>
not us

[05:19:51.0000] <krit>
roc: didn’t see an intent to implement

[05:19:53.0000] <roc>
contributors

[05:19:54.0000] <Ms2ger>
Nope

[05:19:54.0000] <roc>
right

[05:20:02.0000] <Ms2ger>
That's what I was complaining about above

[05:20:21.0000] <roc>
I actually noticed this a month ago, commented in the bug, and then forgot about it. Oops.

[05:20:29.0000] <krit>
:)

[05:20:59.0000] <krit>
Do make it clear: I support having video and canvas within SVG content… just not SVG elements for it

[05:21:10.0000] <roc>
yeah

[05:21:52.0000] <annevk>
SVG hasn't even explained their version of the <script> element in detail

[05:22:07.0000] <annevk>
Is there some way to leave comments on the SVG spec that won't get lost?

[05:22:16.0000] <roc>
www-svg

[05:22:18.0000] <Ms2ger>
I don't think so

[05:22:30.0000] <Ms2ger>
Mailing list comments tend to get lost

[05:22:44.0000] <Ms2ger>
More so if convenient

[05:22:46.0000] <roc>
you can always point to them and say "I told you so"

[05:22:51.0000] <roc>
that's the most important thing for me :-)

[05:23:33.0000] <Ms2ger>
I'd say getting the spec fixed is more important, as is having a clear list of open issues

[05:23:50.0000] <roc>
maybe

[05:24:05.0000] <roc>
in practice it's usually easier for me to send an email to a list than file a bug or use some other issue tracker

[05:24:10.0000] <roc>
so that's what I do

[05:24:17.0000] <roc>
if I can

[05:24:25.0000] <Ms2ger>
I didn't say that was easier :)

[05:24:33.0000] <Ms2ger>
I said it was less likely to get lost

[05:25:54.0000] <krit>
roc: oh, annevk can do that

[05:26:44.0000] <krit>
roc: Ms2ger: also, <script> will be specced in the way it is in HTML

[05:26:49.0000] <Ms2ger>
I'd have suggested heycam, but I need him for IDL

[05:27:20.0000] <krit>
roc: Ms2ger: there is just a difference how to reference an external script.. which we try to harmonize as well

[05:27:48.0000] <krit>
Ms2ger: heycam is *just* the chair of the SVG WG… what can he do :P

[05:27:58.0000] <annevk>
roc: I'll sort it out

[05:28:05.0000] <Ms2ger>
Fix IDL bugs full-time for the next 6 months :)

[05:28:57.0000] <krit>
annevk: well, what is there to sort out if we follow HTML on <style>, <script> and the other elements derived from HTML?

[05:28:57.0000] <roc>
I'm composing an email to www-svg right now :-)

[05:29:15.0000] <annevk>
oh ok

[05:29:21.0000] <krit>
annevk: even synchronous loading… event handling and so on is harmonized with HTML now

[05:29:27.0000] <annevk>
/me is preparing some eggs

[05:30:05.0000] <annevk>
krit: you can't just say "follow", you actually have to write things out and see if it works

[05:30:57.0000] <annevk>
krit: e.g. <html:style> does not work if there's no associated browsing context

[05:31:03.0000] <annevk>
krit: seems like SVG wants something else there

[05:31:10.0000] <krit>
annevk: you have to write that <script> behaves as HTML <script> and reference HTML <script>… no complex wording needed. That was one of the biggest mistakes of SVG 1.1 that it did that

[05:31:22.0000] <annevk>
Yeah so that is bullshit

[05:31:29.0000] <krit>
annevk: no it is not

[05:31:55.0000] <krit>
annevk: it is bullshit to disrespect everything others do

[05:33:34.0000] <annevk>
?

[05:33:46.0000] <annevk>
I just gave an example of why it doesn't work and then you say it does

[05:33:47.0000] <Ms2ger>
<annevk> Yeah so that is bullshit

[05:35:17.0000] <MikeSmith>
sloppy work doesn't deserve respect

[05:35:36.0000] <MikeSmith>
it merits being called what it is

[05:36:17.0000] <roc>
people do though

[05:36:35.0000] <MikeSmith>
sure

[05:37:46.0000] <MikeSmith>
but it's important for people to not get defensive when others point out sloppiness in their work

[05:38:10.0000] <MikeSmith>
and it's important for them to also understand why people lose patience with sloppiness

[05:38:45.0000] <krit>
MikeSmith: defensive by asking for respect in the wording you use? That is called politeness.

[05:39:05.0000] <MikeSmith>
he was just speaking his mind

[05:39:27.0000] <MikeSmith>
he didn't write that up as a message to the group or the editors

[05:39:38.0000] <jgraham>
/me is convinced that having an argument will solve everything

[05:39:41.0000] <krit>
MikeSmith: being impolite nearly always results in defensive and offensive behavior which will never lead to better specws

[05:40:45.0000] <krit>
jgraham: agree

[05:40:59.0000] <Ms2ger>
I don't think using "bullshit" was necessary or helpful

[05:42:45.0000] <krit>
anyway, to get back… We, speaking as a member of the SVG WG, always welcome feedback… www-svg is the right email list for that. The chairs are usually good at tracking the feedback we get and bring it up during calls.

[05:45:26.0000] <krit>
even better are concrete examples that don’t work and suggestions how to improve the situation.

[05:46:47.0000] <krit>
annevk: so if you could bring up your issue with the associated browsing context and <style> to the www-svg mailing list, this would be very appreciated

[05:48:43.0000] <krit>
annevk: as said before… the general theme for SVG2 is to harmonize the spec with HTML as much as possible. Browsers mostly do that today anyway.

[05:50:58.0000] <krit>
annevk: there are even ideas to let SVG elements inherit from HTMLElement… this is an ambitious task that needs a lot of considerations

[05:51:32.0000] <darobin>
I have to say that's the kind of bullshit that I would welcome heartily

[05:51:41.0000] <annevk>
Yes it does, can you sympathise with "bullshit" re "no complex wording needed" above?

[05:52:50.0000] <annevk>
roc: are you going to give feedback about <iframe> and such or should I?

[05:55:34.0000] <roc>
I will

[05:57:11.0000] <Ms2ger>
krit, inherit sounds weird... Right now "implements HTMLElement" === "in the HTML namespace", I'd rather not mess with that invariant

[05:58:09.0000] <krit>
Ms2ger: yes the namespacing is one of the issues… the biggest one for backwards and forwards compatibility

[05:58:32.0000] <krit>
Ms2ger: but in the long term.. do we really want to preserve the SVG namespace?

[05:59:09.0000] <Ms2ger>
I have no love for it

[05:59:29.0000] <Ms2ger>
But I don't know if that's worth the time to fight with

[06:00:33.0000] <krit>
Ms2ger: well, we are talking about months of fighting for years or decades of complaining

[06:01:29.0000] <Ms2ger>
What do you mean by preserving the SVG namespace?

[06:01:46.0000] <Ms2ger>
There's significant deployed SVG-in-XML that uses i

[06:02:02.0000] <Ms2ger>
So I suspect browsers won't be able to forget it entirely

[06:02:27.0000] <krit>
Ms2ger: no, that is indeed a huge part of the discussion

[06:03:00.0000] <annevk>
You could change the XML parser

[06:03:11.0000] <Ms2ger>
That's an option, yes

[06:03:21.0000] <Ms2ger>
Not one I'd take lightly, though

[06:04:30.0000] <krit>
Ms2ger: there are more issues. One is the <image> element with its different function set than <img>

[06:04:53.0000] <krit>
Ms2ger: <image> works in most HTML documents today and will create an HTMLImageElement

[06:05:24.0000] <krit>
Ms2ger: so how to differ between SVG <image> and “HTML” <image>

[06:05:29.0000] <Ms2ger>
I wish I could forget about that, but I know :/

[06:06:21.0000] <krit>
Ms2ger: it goes on with (and we come back to it) <script> and <style> which we are working on harmonizing but certain things are still special for legacy content… like xlink:href on <script>

[06:07:37.0000] <krit>
Ms2ger: this might require changes to HTML… would HTML be willing to do that?

[06:08:11.0000] <Ms2ger>
I'm not going to say no without a concrete proposal

[06:08:15.0000] <Ms2ger>
It seems possible

[06:08:19.0000] <krit>
Ms2ger: on the other hand… SVG DOM for <style> is mostly useless… it won’t hurt to get rid of it

[06:10:12.0000] <krit>
Ms2ger: Btw. the Blink team experimented with using the HTML parser even for standalone SVG documents. Missing support for XML entities seemed to be the biggest problem… not a huge problem for newer content though

[06:10:32.0000] <annevk>
XML entities?

[06:10:43.0000] <annevk>
People actually declare internal DTDs for SVG?

[06:12:28.0000] <krit>
annevk: in the past they did

[06:20:17.0000] <darobin>
I haven't seen that in a while though tbh

[06:20:39.0000] <darobin>
annevk: a large part of the problem here is that Illustrator would make use of that

[06:20:51.0000] <darobin>
I think more recent versions don't do that anymore

[06:21:21.0000] <annevk>
good times

[06:26:43.0000] <darobin>
annevk: that's possibly the least of the horrors that Illustrators did to SVG :)

[06:41:44.0000] <annevk>
krit: I updated the algorithm

[06:41:49.0000] <annevk>
krit: could remove most of it now

[07:23:49.0000] <zewt>
 

[07:23:50.0000] <zewt>
 

[07:24:05.0000] <zewt>
well okay

[08:06:54.0000] <JonathanNeal>
What happened to SVG?

[08:12:26.0000] <TabAtkins>
annevk: I'm convincing blink people that working on "just put SVG in the HTML namespace" is worthwhile.

[08:12:52.0000] <TabAtkins>
The hoops you have to jump through to get Web components to work with SVG are terrible currently.

[08:18:53.0000] <darobin>
TabAtkins: that would be awesome

[08:20:57.0000] <annevk>
TabAtkins: I'm not sure what that means

[08:21:32.0000] <annevk>
TabAtkins: are you also convincing your employer to employ an editor to work fulltime on fixing SVG? :)

[08:28:04.0000] <Domenic>
At Lab49 we did a lot of SVG for our banking apps, and it was slow/buggy in Chrome. Might be able to squeeze it into the mobile performance banner.

[08:28:18.0000] <Ms2ger>
Remove SVG for mobile perf?

[08:28:33.0000] <Ms2ger>
Be careful what you wish for

[08:32:00.0000] <jgraham>
If we make SVG the way froward, presto is the rendering engine of the future

[08:32:15.0000] <jgraham>
*forward

[08:54:31.0000] <TabAtkins>
annevk: It roughly means what I said: putting svg into the html namespace.

[08:54:46.0000] <TabAtkins>
Plus the attendant changes to deal with that.

[08:55:00.0000] <annevk>
TabAtkins: what happens to the SVG namespace?

[08:55:15.0000] <annevk>
TabAtkins: what classes do they implement?

[08:55:26.0000] <TabAtkins>
We're working out the details.

[08:55:42.0000] <annevk>
TabAtkins: in public?

[08:55:45.0000] <TabAtkins>
It'll be hacky, I'm sure.

[08:55:58.0000] <TabAtkins>
Once we have an inkling if what might work, yes.

[08:56:36.0000] <jgraham>
That sounds like "no"

[08:57:09.0000] <Ms2ger>
I heard "no" too

[08:58:56.0000] <TabAtkins>
You guys have some strange ears

[09:00:18.0000] <annevk>
More like strange IRC clients

[09:08:23.0000] <Ms2ger>
jamesr_, not doing storage mutex stuff by virtue of not doing any storage in Servo

[09:08:39.0000] <annevk>
Ms2ger: no cookies?

[09:08:52.0000] <Ms2ger>
None yet

[09:25:01.0000] <annevk>
darobin: http://discourse.specifiction.org/t/wheres-the-do-not-like-button/341 has been loading for several seconds now

[09:25:26.0000] <darobin>
annevk: just loaded in a snap from here

[09:25:30.0000] <annevk>
hmm

[09:25:34.0000] <darobin>
maybe some temporary hiccup?

[09:25:37.0000] <annevk>
seems there's occasional hanging

[09:25:45.0000] <darobin>
I doubled the server's power about a week ago

[09:26:05.0000] <darobin>
so far the load seems to be okay; but please don't hesitate to tell me again and I might double it again

[09:27:04.0000] <caitp>
http://jsfiddle.net/d29gj/ who's idea was this?

[09:27:10.0000] <caitp>
smh .v.

[09:30:26.0000] <caitp>
does it not, I don't know, make sense to maybe throw a type error or something if a form control's name is a property from lets say, Node or something, to avoid that nonsense? I mean really @_@

[09:31:28.0000] <jgraham>
No, the design problem is that name shadows properties at all

[09:31:45.0000] <caitp>
yes

[09:32:45.0000] <caitp>
well, that whole scenario is pretty sad =( jeeze

[09:33:18.0000] <Domenic>
Good ol' @HTML5_Chewbacca managed to get the word out about <picture> landing: https://twitter.com/HTML5_Chewbacca/status/479277675853651968

[09:38:29.0000] <caitp>
anyways, was that introduced in html of old, is that one of the more recent failures? I want to know if it's too late to file a bug about that nonsense

[09:39:10.0000] <jgraham>
Umm, that's actually pretty insulting

[09:39:12.0000] <jgraham>
:)

[09:39:34.0000] <caitp>
well it's clearly a failure, the question is if it's too late to fix it or not

[09:39:34.0000] <jgraham>
I don't think anyone would have introduced that feature in the last 10 years

[09:39:42.0000] <jgraham>
Far too late

[09:40:04.0000] <jgraham>
It probably works like that in NS4 or IE5 or something

[09:40:15.0000] <caitp>
bleh

[09:40:48.0000] <caitp>
the immobility of this stuff is really disheartening =)

[09:44:33.0000] <annevk>
mounir: is denying of locking exceptional? https://www.w3.org/Bugs/Public/show_bug.cgi?id=25054#c8

[09:44:42.0000] <annevk>
mounir: otherwise you should not reject the promise

[09:47:07.0000] <annevk>
Domenic: that bit about promises is really unintuitive at the moment

[09:47:27.0000] <annevk>
Domenic: it makes more sense in the try await catch world, but now...

[09:47:54.0000] <Domenic>
it seems reasonable, for a method named lockOrientation, that if you can't lock the orientation, it's an exceptional condition

[09:48:28.0000] <Domenic>
if it were named canLockOrientation(), then getting back "no" would not be exceptional

[09:48:42.0000] <Domenic>
if it were named "requestToLockOrientation()," then the answer is kind of wishy-washy.

[09:49:32.0000] <Domenic>
but yes, you should generally assume any time you reject a promise, that is essentially like throwing an exception, especially since people coding with try/catch/await will have exactly that experience.

[09:49:37.0000] <jgraham>
Yeah, it seems like if it were sync code you might well implement it with an exception

[09:54:25.0000] <mounir>
annevk: the entire lock flow assume that the lock happened when the promise succeeds

[09:56:43.0000] <Hixie>
zcorpan: yeah that's not a bad idea

[10:06:12.0000] <SamB>
so, any reason why it shouldn't *be* an exception?

[10:07:18.0000] <SamB>
I mean, I see no reason why exceptions can only be transported by throwing

[10:41:48.0000] <Hixie>
jgraham: you around? i'm getting an assertion trying to use html5lib instead of lxml.html

[10:41:58.0000] <Hixie>
in your anolis instance

[10:42:10.0000] <Hixie>
assert isinstance(buffer, bytes) is throwing, in detectEncodingMeta in inputstream.py

[11:09:17.0000] <gsnedders>
Hixie: anolis should just serialize attributes in alphabetical order

[11:09:39.0000] <gsnedders>
Hixie: and if that assertion is being hit something is badly wrong :|

[11:10:06.0000] <Hixie>
i'm apparently using "serializer=alllib" too, i guess i should change that to html5lib

[11:10:20.0000] <gsnedders>
alllib? what on earth is that

[11:10:29.0000] <Ms2ger>
^

[11:10:31.0000] <Hixie>
/me shrugs

[11:10:42.0000] <gsnedders>
/me blames jgraham 

[11:10:48.0000] <Ms2ger>
I think the alphabetical-serializing merged

[11:10:58.0000] <Hixie>
merged?

[11:11:13.0000] <gsnedders>
Ms2ger: given I think jgraham hasn't updated PMS in years…

[11:11:27.0000] <Ms2ger>
That's the new-fangled term for landing a patch

[11:11:33.0000] <Ms2ger>
gsnedders, I thought he did at some point

[11:12:19.0000] <gsnedders>
Ms2ger: idk, I ignore all this PMS-related, um, stress

[11:12:36.0000] <Ms2ger>
I see what you did there

[11:14:32.0000] <gsnedders>
Gosh darn it Firefox crashing again

[11:51:37.0000] <IZh>
IZh: Hi. As I see from the standard  the e-mail input field's value must consist of [a-zA-Z0-9-] characters in domain part (after @). But what about international domain names?

[11:51:58.0000] <IZh>
I mean user@москва.рф

[11:52:15.0000] <Ms2ger>
Punycode

[11:52:58.0000] <Ms2ger>
There is no requirement that the user sees ASCII, note

[11:53:29.0000] <IZh>
Ms2ger: but should a user know it's ugly e-mail version?

[11:53:58.0000] <Ms2ger>
No, the user could enter the internationalized version

[11:54:32.0000] <IZh>
And a browser will transparently convert the value?

[11:59:34.0000] <gsnedders>
IZh: yes

[11:59:43.0000] <caitp>
I don't think browsers currently do transparently convert the value, I checked that a few weeks ago when it was brought up on angular

[11:59:50.0000] <caitp>
unless it's locale-dependent or something

[12:00:04.0000] <gsnedders>
IZh: or at least that is the intention

[12:00:28.0000] <gsnedders>
IZh: the spec only defines the over-the-wire format and at the JS API; what the browser displays in the UI is tangential

[12:06:14.0000] <IZh>
I mean, if non-ascii value is not acceptable in JS, then a browser must do the convertion.

[12:07:10.0000] <IZh>
Or user will enter an international value and it could be considered as invalid by a browser.

[12:08:57.0000] <gsnedders>
But the user doesn't see the JS API.

[12:09:04.0000] <gsnedders>
They see whatever widget the browser provides.

[12:10:41.0000] <gsnedders>
How inputs in the widget map to values exposed at the JS level is up to the browser

[12:12:48.0000] <IZh>
Yes. But if a user will type user@москва.рф, then will it be considered invalid by browser according to the spec?

[12:13:03.0000] <gsnedders>
The spec makes no comment on such things.

[12:13:12.0000] <gsnedders>
The spec makes no requirements on UI.

[12:13:17.0000] <caitp>
http://jsfiddle.net/UMrw6/ yeah still no punicod-ification, need to polyfill that stuff =(

[12:13:20.0000] <caitp>
kind of unfortunate

[12:13:44.0000] <gsnedders>
An extreme example would be exposing input@type="date" (which uses the Georgian calendar at a JS/wire level) as another calendar in the UI, esp. in locales where other calendars are the default

[12:15:09.0000] <caitp>
gsnedders; the spec actually does comment on that

[12:15:57.0000] <caitp>
although I guess it's not normative per se, but

[12:16:15.0000] <gsnedders>
caitp: okay, only my latter statement was true

[12:16:37.0000] <caitp>
right, that is true

[12:16:58.0000] <IZh>
Ah... I see. The phrase " The value attribute, if specified and not empty, must have a value that is a single valid e-mail address." is related to only markup's and JS' provided values, and not to a value that is typed by user.

[12:17:21.0000] <Ms2ger>
Correct

[12:18:03.0000] <gsnedders>
IZh: The obvious example of this is to look at implementations of input@type="color"

[12:18:12.0000] <gsnedders>
IZh: Most don't expose the raw value anywhere

[12:21:06.0000] <IZh>
I see...

[13:51:34.0000] <Hixie>
gsnedders: even more obvious is type=password

[15:06:32.0000] <SamB>
hmm, where are the same-origin rules codified these days ...

[15:09:31.0000] <Hixie>
which ones?

[15:09:43.0000] <Hixie>
the same-origin policy pervades the entire platform

[15:15:51.0000] <smaug____>
anyone here familiar with dart2js?

[15:16:46.0000] <smaug____>
(if the whole thing is still being developed at all)

[15:17:38.0000] <smaug____>
ah, #dart

[15:17:53.0000] <SamB>
Hixie: well, I'm wondering about the definition of "same", and the interface for setting the origin to a more accessible value

[15:18:48.0000] <SamB>
and, like, what do different ports do to things?

[15:19:25.0000] <SamB>
or, say, http:// vs https:// vs ftp:// ?

[15:19:34.0000] <Hixie>
the definition of "same" is http://whatwg.org/html#same-origin

[15:19:51.0000] <Hixie>
not sure what "the interface for setting the origin to a more accessible value" means

[15:20:01.0000] <Hixie>
nor what you mean by "things"

[15:20:17.0000] <Hixie>
though i think the definition of "same" might answer that?

[15:20:53.0000] <SamB>
forget the "and, " before the "like, " there

[15:21:01.0000] <SamB>
so, yeah

[15:23:09.0000] <SamB>
Hixie: ah, nice, that's exactly what I was looking for

[15:23:32.0000] <SamB>
Hixie: anyway, I half expected this section to have been pulled out into its own spec

[15:23:51.0000] <Hixie>
it might be in the origin RFC as well?

[15:23:54.0000] <Hixie>
i'm not sure what the state of that is

[15:24:06.0000] <Hixie>
(i try to keep the number of specs down where possible)

[15:24:25.0000] <SamB>
meh @ IETF

[15:24:42.0000] <SamB>
except opus seems pretty cool

[15:26:12.0000] <SamB>
(even if it is missing the "expected results" half of its test suite ...)

[15:26:28.0000] <rillian>
SamB: you mean the opus test suite?

[15:26:35.0000] <SamB>
yeah

[15:26:52.0000] <rillian>
there's validation code in the RFC

[15:27:00.0000] <SamB>
hmm

[15:27:24.0000] <SamB>
maybe they just need a README in that directory on their website or something then

[15:27:37.0000] <rillian>
I keep meaning to run it through emscripten and make a browser test page with it

[15:28:10.0000] <SamB>
how does it work?

[15:28:20.0000] <SamB>
/me goes to see if he can understand it ...

[15:28:47.0000] <rillian>
https://tools.ietf.org/html/rfc6716#section-6.1

[15:29:25.0000] <rillian>
the idea with opus_compare is to do a fuzzy-match, so we can declare implementations compliant even if they're not bit-exact

[15:29:37.0000] <rillian>
giving implementors freedom to optimize the code

[15:30:27.0000] <SamB>
Hixie: I'm kind of surprised there isn't a "domain name to ASCII" algorithm that converts a whole name to ASCII, putting dots between the components ...

[15:30:32.0000] <rillian>
there's also a smaller set for testing the .opus file encapsulation implementation. I'll agree with you that side isn't complete.

[15:34:33.0000] <Hixie>
SamB: http://url.spec.whatwg.org/#concept-domain-to-ascii

[15:34:59.0000] <Hixie>
oh nevermind

[15:35:03.0000] <Hixie>
that's still per-label

[15:35:30.0000] <Hixie>
or no?

[15:35:42.0000] <Hixie>
http://url.spec.whatwg.org/#concept-domain doesn't make sense to me

[15:35:56.0000] <Hixie>
what does "the form of a domain" look like?

[15:36:52.0000] <Hixie>
filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26138

[15:38:47.0000] <SamB>
rillian: I guess I'd basically want to see some files like the ones on http://www.opus-codec.org/examples/ alongside the opus versions, at least

[15:39:05.0000] <SamB>
though I might have expected FLAC rather than .wav

[15:40:51.0000] <rillian>
SamB: for human listening tests?

[15:40:53.0000] <SamB>
rillian: I mean, I understand that implementations aren't required to use any particular output sampling rate

[15:43:03.0000] <SamB>
but you could downsample, say, 48k sample decodings to whatever output rate you're actually working at and test if the output is plausibly close, yeah?

[15:43:39.0000] <SamB>
or, worst case, do it by ear, yes

[15:44:12.0000] <rillian>
SamB: that's what opus_compare tries to do

[15:44:35.0000] <rillian>
part of the problem is that there are both fixed and floating point implementations

[15:44:50.0000] <rillian>
so you can exactly verify the entropy coder output, but not the audio output

[15:45:06.0000] <rillian>
how would you test 'plausibly close'?

[15:46:19.0000] <SamB>
well, I'd *probably* start by transforming to the frequency domain

[15:47:41.0000] <rillian>
https://git.xiph.org/?p=opus.git;a=blob;f=src/opus_compare.c

[15:47:41.0000] <SamB>
or possibly by buying a DSP book, or at least another signal processing book since someone lost the one I had for school ...

[15:49:15.0000] <SamB>
hmm, I suck at googling and chatting at the same time ;-)

[15:51:12.0000] <rillian>
it looks like it splits the audio into overlapped blocks, does a rough transform, and applies some psychoacoustic stuff

[15:51:25.0000] <SamB>
anyway, I guess http://people.xiph.org/~greg/opus_testvectors/ is the one I was confused by

[15:51:42.0000] <SamB>
and I was thinking for decode testing; encoder testing is obviously MUCH more involved

[15:51:54.0000] <rillian>
yeah, that could use a readme

[15:55:24.0000] <SamB>
Hixie: I really miss the days when I could use the single-page spec; too bad I have no real idea what changed that makes that so unpleasant now ...

[15:55:44.0000] <Hixie>
what browser?

[15:56:22.0000] <SamB>
well, ISTR it used to work okay in Chrome, but no more. Not sure if it was something on your end or Chrome's end, even ...

[15:56:55.0000] <Hixie>
chrome sucking on the html spec these days is https://code.google.com/p/chromium/issues/detail?id=376847

[15:56:56.0000] <SamB>
I mean, *something* started demanding more RAM, but I'm not sure what ...

[15:57:12.0000] <SamB>
not sure if it worked okay in Firefox or not

[15:57:33.0000] <Hixie>
firefox is fine once it's loaded

[15:57:38.0000] <Hixie>
but loading the spec in firefox is painful

[15:57:43.0000] <Hixie>
not sure if they have a bug on that

[15:57:49.0000] <SamB>
how much memory does it use once it's loaded?

[15:57:59.0000] <Hixie>
in which?

[15:58:03.0000] <SamB>
firefox

[15:59:03.0000] <Hixie>
about half a gig

[15:59:35.0000] <Hixie>
(including the browser)

[15:59:47.0000] <Hixie>
chrome uses a little over a quarter of a gig (not including the browser)

[15:59:54.0000] <Hixie>
memory isn't the issue though

[16:01:25.0000] <SamB>
it is *an* issue for me

[16:02:50.0000] <Hixie>
buy more ram

[16:02:51.0000] <Hixie>
:-)

[16:04:25.0000] <SamB>
yeah, iirc the SMBIOS data on this thing claims I can triple my RAM by doubling the size of the existing modules and installing a third, but I'm not positive the third slot actually exists

[16:04:57.0000] <Hixie>
heh

[16:05:03.0000] <Hixie>
how much ram do you have?

[16:05:08.0000] <SamB>
1 gig :-(

[16:05:56.0000] <Hixie>
1 gig!

[16:06:02.0000] <Hixie>
what is this, 1997? :-P

[16:06:29.0000] <Hixie>
ok filed https://bugzilla.mozilla.org/show_bug.cgi?id=1027382 on firefox hanging while loading the html spec

[16:07:05.0000] <SamB>
dude, the computer we got in, like, 1996 or 1997 came with 16 megs and my dad had to upgrade it to 32 megs

[16:07:37.0000] <zewt>
Hixie: fwiw, I think refusing to adjust the spec when it's doing uncommon things (an unusually large page doing unusual things with CSS) to try to force browsers to do optimizations that they don't have time to do is unreasonable and harmful

[16:08:19.0000] <SamB>
zewt: he's doing that?

[16:08:31.0000] <SamB>
I mean, on purpose?

[16:08:52.0000] <Hixie>
zewt: it's not that unusual, and firefox handles it perfectly. Plus, until recently the situation was reversed (the CSS did something that hurt Firefox, but not Chrome, because Chrome cheated), so it's about time the tables were turned.

[16:08:58.0000] <zewt>
that's what my takeaway was from https://code.google.com/p/chromium/issues/detail?id=376847#c26

[16:10:15.0000] <zewt>
i'm sure there are tons of cases where either browser is faster than the other; I think the HTML spec is the wrong place to wage these battles (all it means is today, I'm much less likely to load the spec to answer a question than I was a couple months ago)

[16:11:27.0000] <Hixie>
it's not like this is on purpose

[16:11:37.0000] <Hixie>
i just wrote CSS that should work, and it did work

[16:11:39.0000] <Hixie>
except in chrome

[16:11:39.0000] <zewt>
making the spec convenient to access is far more important than trying to coerce a browser into making some whack-a-mole CSS optimization

[16:11:41.0000] <smaug____>
Hixie: fixing that responsiveness issue in FF needs multiprocess setup. That way UI wouldn't be blocked, only the child process. Similar to Chrome, where scrolling or resizing while loading html spec isn't working too well.

[16:11:58.0000] <Hixie>
smaug____: yeah, that was my guess too

[16:12:00.0000] <smaug____>
(fortunately e10s project is doing quite well)

[16:12:41.0000] <smaug____>
I do profile html spec loading occasionally

[16:12:45.0000] <SamB>
zewt: I don't think it counts as what you said unless he's insisting on sticking with his original approach in the face of a reasonable alternative

[16:13:10.0000] <Hixie>
SamB: i haven't looked into what an alternative would look like

[16:13:14.0000] <Hixie>
SamB: but i'm sure it'd be possible to find one

[16:13:20.0000] <SamB>
so, um, is there some way to let firefox take a breather during the loading process

[16:13:29.0000] <zewt>
someone recommended something on the ticket, iirc

[16:14:35.0000] <smaug____>
SamB: it is mostly layout stuff... need to improve interruptible layout

[16:14:39.0000] <roc>
In Firefox nightlies you can actually open the HTML5 spec in a separate process tab, so problem solved if you remember to do that :-)

[16:14:45.0000] <SamB>
Hixie: also, it sounds kind of unreasonable to expect a transition that impacts every element to be too quick

[16:14:53.0000] <SamB>
smaug____: ah

[16:14:56.0000] <Hixie>
SamB: it's blazing fast in firefox

[16:15:03.0000] <Hixie>
SamB: not even a slight hickup

[16:15:09.0000] <Hixie>
SamB: buttery smooth 60fps goodness

[16:15:13.0000] <SamB>
Hixie: huh, what properties ...

[16:15:16.0000] <SamB>
/me goes to check

[16:15:17.0000] <smaug____>
SamB: chrome is equally bad too with resizing the window for example

[16:15:34.0000] <Hixie>
roc: how do i do that?

[16:15:43.0000] <Hixie>
roc: i mean, i only have this one page open...

[16:16:08.0000] <Hixie>
roc: but as soon as i try to open the spec, it messes up command-tabbing around the OS and so on, because it doesn't respond any more

[16:16:19.0000] <SamB>
Hixie: presumably it has the client area in the other process but the chrome still in the main process

[16:16:31.0000] <SamB>
oh, it screws with the OS?

[16:16:35.0000] <zewt>
reasonable to expect it or not, having the spec be fast and convenient for everyone is so much more important than any style changes (the spec was perfectly fine before, IMO)

[16:17:00.0000] <smaug____>
in the menu FF has open New e10s Window

[16:17:11.0000] <smaug____>
one may need to do Customize first, I think

[16:17:16.0000] <Hixie>
roc: yeah, i just created a new e10s window and while the page is loading, if i command-tab to another app, the window stays up

[16:17:25.0000] <zewt>
"e10s"? is that supposed to be meaningful? heh

[16:17:28.0000] <Hixie>
roc: and if i click on another app then command-tab back to firefox, the window doesn't show

[16:17:36.0000] <Hixie>
zewt: internal codename

[16:17:40.0000] <zewt>
heh okay

[16:17:46.0000] <SamB>
anyway, *my* problems probably started >1y ago ...

[16:18:21.0000] <Hixie>
zewt: the spec wasn't fine before, we got lots of complaints about the look. but yeah, it's sad that it's slow in chrome, i just don't like working around what are just bugs.

[16:18:39.0000] <Hixie>
zewt: and since i never worked around firefox bugs, it seems bad that i work around chrome bugs

[16:19:19.0000] <SamB>
Hixie: what firefox bugs did you decide not to work around, and why?

[16:19:37.0000] <Hixie>
some similar performance issue with selectors

[16:19:40.0000] <Hixie>
and for the same reason

[16:19:58.0000] <SamB>
"because it was just bugs", not "because the workaround was fugly"?

[16:20:03.0000] <Hixie>
right

[16:20:07.0000] <Hixie>
bugs should be fixed :-)

[16:20:12.0000] <Hixie>
not worked around

[16:20:29.0000] <SamB>
well, yeah, I guess your hands are tied then

[16:20:52.0000] <Hixie>
i'll probably end up working around this one eventually if they don't fix it, because it is somewhat more eggregious

[16:21:00.0000] <SamB>
however, you're perfectly at liberty to work around my lack of RAM, since that's not actually a bug in some vendor's code ;-P

[16:21:07.0000] <Hixie>
(and zewt is right)

[16:21:18.0000] <Hixie>
(that the spec being readable is more important)

[16:21:26.0000] <Hixie>
SamB: that's what the multipage spec is for

[16:21:26.0000] <SamB>
though I don't expect you to find your own workaround

[16:21:43.0000] <SamB>
yeah, that does help

[16:22:54.0000] <SamB>
but still, I miss the nifty crossref thing working document-wide, and Ctrl+F ...

[16:24:22.0000] <SamB>
Hixie: what is "additional data"?

[16:24:36.0000] <Hixie>
for origins?

[16:24:41.0000] <SamB>
yeah

[16:24:43.0000] <Hixie>
e.g. certification signature or whatever

[16:24:46.0000] <Hixie>
certificate

[16:24:58.0000] <Hixie>
probably nothing, in practice

[16:28:28.0000] <SamB>
hmm, needs more hyperlinks


2014-06-19
[17:05:46.0000] <Domenic>
If someone had lots of free time they could implement a working Ctrl+F even in multipage

[17:06:11.0000] <Domenic>
might be able to get away with doing it all client side by XHRing the singlepage

[17:07:14.0000] <SamB>
someone proposed doing something like that in `eww' to make it act more like `info-mode' when browsing Texinfo output ...

[17:07:38.0000] <SamB>
except elisp doesn't have XHR, obviously

[17:08:10.0000] <Domenic>
the only potentially tricky part would be searching only within text. would need to parse the XHR'd document then use textContent perhaps? hmm but then need to get to nearest scroll position or ID. tricky.

[17:08:47.0000] <SamB>
which reminds me how I wish browsers would have such features just for users

[17:09:32.0000] <SamB>
Domenic: DOM does not have source locations, then?

[17:10:36.0000] <Domenic>
As in, index into textContent string -> nearest parent node? No.

[17:11:10.0000] <SamB>
hmm

[17:11:48.0000] <Domenic>
Would need to walk the entire tree, or build an index, both of which seem bad.

[17:11:56.0000] <SamB>
I was thinking of either byte or line/column ranges for each DOM node

[17:12:26.0000] <Domenic>
Nah

[17:21:55.0000] <gsnedders>
Was there not some talk about APIs to control ctrl+f somewhere? Around pdf.js, maybe?

[17:31:46.0000] <Domenic>
There was, on the whatwg list

[17:32:06.0000] <Domenic>
It is a good idea IMO. Don't remember if it ever made it into Hixie's queue

[17:34:35.0000] <gsnedders>
idk, I don't really read mailing lists nowadays, I just read IRC :P

[17:34:48.0000] <gsnedders>
and spec change logs

[20:21:12.0000] <SamB>
Hixie: huh, you really have to do your own index entries?

[20:21:18.0000] <Hixie>
hm?

[20:21:48.0000] <SamB>
/me pulls to make sure that's not changed ...

[20:22:12.0000] <Hixie>
i'm not sure to what you are referring

[20:23:49.0000] <SamB>
the comment at the top of html/source

[20:23:58.0000] <SamB>
2nd to last bullet

[20:24:38.0000] <Hixie>
yes?

[20:28:50.0000] <SamB>
I'd have expected indices to be automatically extracted from the relevant anchors

[20:29:05.0000] <Hixie>
where possible, it is

[20:29:13.0000] <Hixie>
but most of the indices have data that just isn't anywhere else

[20:29:25.0000] <Hixie>
in fact some of the indicies are the source of data used elsewhere

[20:29:25.0000] <SamB>
ah

[20:29:46.0000] <Hixie>
e.g. the one-line attribute descriptions you see in the element description boxes are actually sourced from the attribute index

[22:52:20.0000] <roc>
Hixie: WFM, sorry

[23:10:56.0000] <jamesr_>
roc: what would your canvas.preferredWidth/Height attributes return?

[23:11:35.0000] <jamesr_>
i'm not sure what an author would need that they can't get from the CSS size of the <canvas> and window.devicePixelRatio

[23:12:31.0000] <roc>
the canvas could be in a CSS transform

[23:13:28.0000] <roc>
also, if the size of the canvas * devicePixelRatio is not an integer, the author can't know what rounding the browser will do

[23:13:58.0000] <roc>
the latter came up in a Mozilla bug, which is what prompted my email

[23:14:29.0000] <jamesr_>
the browser doesn't know what the author wants either

[23:14:44.0000] <jamesr_>
in non-integer cases there are several justifiable choices

[23:15:21.0000] <jamesr_>
http://jsfiddle.net/r7V9L/ should always stay 1:1 with physical px with browser zoom, respecting the zoom level

[23:15:39.0000] <jamesr_>
(there's a bug in chrome on hi dpi m achines that causes filtering, but it appears to work in firefox)

[23:15:50.0000] <jamesr_>
that chooses to clip the content to the canvas

[23:15:53.0000] <jamesr_>
but you may also want to pad

[23:18:05.0000] <roc>
That approach works but it doesn't work if you're trying to fill the viewport

[23:20:29.0000] <roc>
Does that make sense? It depends on resizing the canvas to a CSS size which is known to be a multiple of device pixels. If you need to fill some container, you can't do that.

[23:26:09.0000] <roc>
to be fair, if you're trying to fill the viewport and you're the toplevel frame in a browser or app it's probably safe to assume that your viewport is actually some multiple of device pixels in size

[23:26:53.0000] <roc>
in which case you can just obtain the fractional CSS size of your viewport and multiply by devicePxielRatio and you're good

[23:28:02.0000] <roc>
but it would be nice to have a general solution so we can tell authors "do this" and their content will work in all contexts

[23:32:28.0000] <jamesr_>
well, if you're trying to fill a container and the container does not line up nicely on physical pixel boundaries you have some choices to make

[23:32:34.0000] <jamesr_>
and the correct choice is content-dependent

[23:32:45.0000] <jamesr_>
you can construct the largest physical pixel rectangle fully enclosed by the container

[23:32:59.0000] <jamesr_>
which may have small gaps on the edges, potentially all 4 edges

[23:33:15.0000] <jamesr_>
or you can make the smallest physical pixel rectangle that fully contains the container

[23:33:22.0000] <jamesr_>
and overdraw the edges slightly

[23:33:41.0000] <roc>
suppose you have a <canvas> element in the page with a CSS border

[23:34:06.0000] <jamesr_>
or do something else, like have the top left corner be the closest physical pixel to 0,0 that is inside the container and let the right/bottom fully fill (meaning they go slightly outside the container potentially)

[23:34:07.0000] <roc>
and suppose the canvas rect edges are logically at some subpixel offset(s)

[23:34:17.0000] <jamesr_>
and if you are larger, you have to decide to clip or extend

[23:34:27.0000] <roc>
Gecko will not draw a fuzzy border. We snap the border edges to device pixels at render time.

[23:34:47.0000] <jamesr_>
sure, i think everyone snaps border edges

[23:34:53.0000] <jamesr_>
but they're a bit of a special case

[23:35:20.0000] <roc>
obviously the canvas should exactly fill the inside of that border. So our border snapping defines the device pixel rect the canvas should fill.

[23:35:23.0000] <jamesr_>
if you have a div with a transform next to the canvas what do you do?

[23:35:52.0000] <roc>
what do you mean "next to the canvas"?

[23:36:01.0000] <jamesr_>
that's what the author intends

[23:36:23.0000] <jamesr_>
say it's a flexbox or something with div, canvas, div on a row

[23:36:47.0000] <roc>
what about it?

[23:37:40.0000] <roc>
another example is that if the canvas has a CSS background (and no padding or borders), we'll draw the background snapped to some device pixel rect. Again, the canvas will be rendered to fill that exact device pixel rect.

[23:38:00.0000] <roc>
So the device pixel rect filled by the canvas is defined by us.

[23:38:28.0000] <jamesr_>
that's true but i don't think the box decoration cases are what authors are most likely to be interested in

[23:38:47.0000] <jamesr_>
and you want to do that snapping well after the author has had a chance to produce content

[23:38:49.0000] <roc>
if we expose the size of that rect, authors can use that to set the canvas backing store correctly. If we don't expose it, it's impractical for them to figure out what it is.

[23:38:59.0000] <jamesr_>
i.e. after you know the pinch zoom + pan offset from the user

[23:39:09.0000] <jamesr_>
at which point you're probably well past anything running on the javascript thread

[23:39:30.0000] <roc>
panning isn't an issue. We pan in units of whole device pixels.

[23:39:48.0000] <SamB>
I was just gonna say, subpixel scrolling would be dumb ...

[23:40:16.0000] <roc>
pinch zooming is an issue for all these proposals. I wouldn't change the exposed values during a pinch zoom, but I would at the end of the gesture.

[23:40:42.0000] <SamB>
and, um, the canvas is going to have worse problems during zooming ;-P

[23:57:45.0000] <JonathanNeal>
Neat idea https://github.com/ThePacielloGroup/html5-h but goodness gracious what a polyfill.

[00:30:09.0000] <JonathanNeal>
SteveF: did <html5-h> used to be <w3c-heading>? Any reason worth knowing why it was changed?

[00:30:37.0000] <JonathanNeal>
I should mention, I’m less interested in the prefix change. I did see the explanation for that.

[00:30:59.0000] <SteveF>
JonathanNeal: name shorter is all

[00:31:41.0000] <JonathanNeal>
oh okay, thanks.

[00:32:21.0000] <SteveF>
JonathanNeal: ties in with uber cool XHTML2 <h>

[00:32:51.0000] <JakeA>
annevk: Wonder if `new Request()` content type should default to "application/x-www-form-urlencoded" for text body content. Doing a simple post via fetch() is a bit of a ballache right now

[00:33:47.0000] <JonathanNeal>
SteveF: I had wondered, but I try not to presume, especially based on the XHTML 1.1 nostalgia.

[00:35:25.0000] <annevk>
JakeA: that or multipart/form-data?

[00:36:12.0000] <JakeA>
annevk: I imagine you'd get that if you provided a formdata object

[00:36:14.0000] <JakeA>
actually

[00:36:50.0000] <JakeA>
could FormData have a constructor like new FormData({hello: "world"})

[00:37:05.0000] <annevk>
JakeA: yeah it will get that

[00:37:29.0000] <annevk>
JakeA: another candidate would be URLSearchParams, but that cannot handle Blob/File

[00:38:28.0000] <JakeA>
annevk: I guess if you provide URLSearchParams as a response body you'd get application/x-www-form-urlencoded, and multipart/form-data if you provide a FormData

[00:38:40.0000] <JonathanNeal>
I hope you don’t mind, but I’m going to write an alternative polyfill for <html5-h>, SteveF. I can’t get over Polymer, yet.

[00:39:37.0000] <annevk>
JakeA: I guess

[00:39:50.0000] <annevk>
JakeA: someone needs to define multipart/form-data

[00:39:59.0000] <JakeA>
/me runs away

[01:01:36.0000] <krit>
annevk: morning. I looked at the algorithm. It seems 2) disallows load of images if called with /local SVG element flag/ set

[01:03:00.0000] <krit>
annevk: also, when do we still need the flag? step 3) seems to indicate that Fetch will handle fetching (or better not allowing fetching) of external resources

[01:03:29.0000] <krit>
annevk: after the discussion with roc, we always allow referencing external elements

[01:03:53.0000] <krit>
annevk: and disallow fetching external resources in general in certain modes

[01:04:09.0000] <krit>
annevk: (in which case referencing external elements is a failure as well)

[01:14:06.0000] <JonathanNeal>
Like http://sandbox.thewikies.com/h/demo.html

[01:30:18.0000] <JakeA>
Anyone working on the push API here? Any idea why we'd want to allow more than one push registration per serviceworker registration? Really complicates the API

[01:33:51.0000] <JakeA>
Ohh, that was a bit candyman

[01:33:57.0000] <JakeA>
sicking:  Any idea why we'd want to allow more than one push registration per serviceworker registration? Really complicates the API

[01:38:42.0000] <sicking>
JakeA: so that you can have separate ones for emails and attachments for example

[01:38:57.0000] <sicking>
JakeA: so that the user can turn on syncing of emails but not attachments

[01:39:15.0000] <sicking>
JakeA: Android does something very similar, though it has a terribly hard-to-find UI for it

[01:39:33.0000] <sicking>
JakeA: oh, wait, sorry

[01:39:38.0000] <JakeA>
sicking: Isn't that something the site's server would decide?

[01:39:40.0000] <sicking>
JakeA: push registration, not sync registration

[01:39:49.0000] <sicking>
JakeA: yes, sorry, i was talking about something else

[01:40:25.0000] <sicking>
JakeA: for push I believe it has been decided to only allow one push registration per SW

[01:40:37.0000] <JakeA>
sicking: Ohhh fantastic

[01:41:11.0000] <sicking>
JakeA: given that we actually have more than me working on push, i've happily punted it to those guys

[01:41:12.0000] <JakeA>
sicking: Need to keep up to date with that mailing list I guess. Which list is that happening on?

[01:41:36.0000] <sicking>
JakeA: i believe this was decided at a push face-to-face in madrid a few weeks ago

[01:42:14.0000] <JakeA>
sicking: Who should I bug for the latest registration code? Hoping to preview it at I/O

[01:42:52.0000] <sicking>
JakeA: try dougt@moz. I'm not sure who was there from Google

[01:43:24.0000] <JakeA>
sicking: excellent, thanks!

[01:44:10.0000] <annevk>
sicking: you in Europe now?

[01:44:24.0000] <sicking>
annevk: Taiwan

[01:44:34.0000] <annevk>
sicking: ah okay, that explains the times :-)

[01:44:40.0000] <sicking>
annevk: i was in Europe on friday

[01:44:49.0000] <sicking>
yeah :)

[01:45:03.0000] <annevk>
sicking: so progress notifications, the suggested API seems okay?

[01:45:18.0000] <sicking>
annevk: got link to proposal?

[01:45:19.0000] <annevk>
sicking: can't we do something with a writeable property on the object?

[01:45:43.0000] <annevk>
sicking: https://github.com/whatwg/notifications/issues/17

[01:46:06.0000] <sicking>
brb

[01:58:48.0000] <annevk>
krit: I guess that flag can be removed

[01:59:05.0000] <annevk>
krit: it seems the caller still needs some flexibility as to what is passed to Fetch

[01:59:13.0000] <annevk>
krit: well, not Fetch, "image fetch"

[01:59:19.0000] <annevk>
krit: which will be defined by HTML most likely

[02:00:43.0000] <krit>
annevk: sounds good to me

[02:10:53.0000] <SteveF>
JonathanNeal: knock yourself out :-)

[02:21:59.0000] <annevk>
zcorpan: hey, are you planning on working on the generic "image fetch" algorithm?

[02:22:27.0000] <zcorpan>
annevk: yeah probably at some point

[02:22:57.0000] <annevk>
zcorpan: SVG in general wants to use that algorithm also for masks and paint servers and such

[02:23:51.0000] <zcorpan>
ok

[02:23:54.0000] <annevk>
zcorpan: so the basic algorithm should probably either return an XML tree or an image

[02:24:08.0000] <annevk>
zcorpan: or failure

[02:24:17.0000] <annevk>
zcorpan: and the XML tree is only when the MIME type is image/svg+xml

[02:24:23.0000] <annevk>
zcorpan: and with scripting disabled

[02:27:08.0000] <zcorpan>
/me pasted the above into https://www.w3.org/Bugs/Public/show_bug.cgi?id=24055

[02:31:17.0000] <annevk>
krit: simplified the algorithm some more assuming image fetching will deal with the rest

[03:00:08.0000] <sicking>
annevk: still there?

[03:00:15.0000] <annevk>
sicking: yeah

[03:00:33.0000] <sicking>
annevk: why is progress better to have as a settable property?

[03:00:47.0000] <sicking>
annevk: rather than as in the proposal?

[03:01:01.0000] <annevk>
sicking: seems you get a lot of Notification objects with the proposal

[03:01:21.0000] <sicking>
annevk: the idea is to use tags to replace the existing notification, no?

[03:02:12.0000] <annevk>
sicking: sure

[03:02:48.0000] <sicking>
annevk: doesn't that solve it? I thought it was defined that replacing using a tag would not do a full new "user alert"

[03:02:51.0000] <annevk>
sicking: maybe that's fine, but if we're going to have <button> and such, does that still make sense? Replacing notifications?

[03:03:35.0000] <sicking>
annevk: yeah, i think replacing still makes sense. For example replacing "you have 4 new voicemails" with "you have 5 new voicemails"

[03:03:41.0000] <annevk>
It does work. It just seems weird to require replacing the Notification rather than updating it

[03:03:55.0000] <annevk>
Yeah I guess

[03:04:04.0000] <sicking>
annevk: having a single model is better than two

[03:04:05.0000] <annevk>
On the upside it is rather simple that way

[03:04:09.0000] <sicking>
yeah

[03:04:33.0000] <annevk>
On the downside I'm not sure how this extends to more arbitrary notifications such as as the new stuff in iOS

[03:04:42.0000] <annevk>
But I guess that can be done later

[03:48:00.0000] <krit>
annevk: an SVG Image loaded with <img> does or does not have a browsing context?

[03:48:24.0000] <krit>
annevk: "A browsing context is an environment in which Document objects are presented to the user." would suggest that it doesn't

[03:48:34.0000] <annevk>
krit: it doesn't

[03:49:02.0000] <krit>
annevk: so style sheets can operate without browsing context?

[03:49:07.0000] <annevk>
krit: a browsing context is a window/tab, content in <iframe>

[03:49:55.0000] <krit>
annevk: k, thanks

[03:51:52.0000] <annevk>
krit: it's a bit unclear to me how <style> and such would/should work there

[03:52:11.0000] <annevk>
krit: I think SVG as image might require refactoring in HTML as well

[03:52:28.0000] <annevk>
krit: e.g. HTML's <style> element present there would start fetching subresources

[03:52:37.0000] <krit>
annevk: right, that is my concern with the definition of browsing context... on the other hand... it is not the user who does have access to Document objects

[03:52:42.0000] <krit>
annevk: so it would fit again

[03:53:32.0000] <annevk>
It seems browsing contexts are not really relevant here, I was mistaken about that yesterday, but there are some other issues

[03:53:38.0000] <krit>
annevk: that was my next question... can Fetch define in general that documents without browsing context can not fetch external resources? So  "local fetches only flag" is set.

[03:54:20.0000] <annevk>
No we shouldn't do it that way

[03:54:36.0000] <annevk>
That doesn't work well for e.g. a document fetched through XMLHttpRequest

[03:54:41.0000] <krit>
annevk: ok, can do it outside of fetch

[03:55:59.0000] <krit>
annevk: could you add a flag "local fetches only" to fetch with an issue that it needs to be defined?

[03:56:06.0000] <krit>
annevk: something that can be referenced

[03:56:11.0000] <annevk>
there's an open bug

[03:56:24.0000] <krit>
annevk: but no name for it yet?

[03:56:33.0000] <annevk>
there's a proposed name in that bug

[03:56:38.0000] <annevk>
I copied you

[03:57:43.0000] <krit>
annevk: could you paste the link please? don't see it right now

[03:59:45.0000] <annevk>
krit: I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26144 on <html:style>

[03:59:59.0000] <annevk>
krit: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26114 is the bug on defining "local fetches only fag"

[04:00:04.0000] <annevk>
flag, even

[04:00:44.0000] <darobin>
/me glad annevk hasn't picked up smoking after all

[04:00:57.0000] <annevk>
:)

[04:01:25.0000] <darobin>
and anyway if you went to fetch fags the polite thing to do would be to also get some beer

[04:01:48.0000] <krit>
annevk: thanks!

[04:07:52.0000] <annevk>
krit: emailed www-svg on <svg:script> definition

[04:09:13.0000] <annevk>
Now I wonder whether <template> does its magic when fetched through XMLHttpRequest

[04:12:10.0000] <annevk>
It does

[04:19:19.0000] <annevk>
krit: I saw you added some notes

[04:20:51.0000] <annevk>
krit: I'm not sure if you should make things depend on "browsing context"

[04:21:01.0000] <annevk>
krit: that would do weird things if you fetch image/svg+xml through XHR

[04:21:28.0000] <annevk>
krit: you probably want "process the resource just retrieved" with mode "limited" or some such

[04:22:42.0000] <annevk>
krit: and then for each element you define what "limited" means

[04:26:26.0000] <annevk>
My <template> thing above is now https://github.com/w3c/web-platform-tests/issues/1064

[04:47:05.0000] <annevk>
JakeA: can you reply to the WHATWG thread on to()?

[04:47:20.0000] <JakeA>
annevk: Shall do

[04:47:25.0000] <annevk>
/me doesn't really care

[04:48:55.0000] <JakeA>
tbh I don't care much either

[04:49:46.0000] <annevk>
say we have toBlob / toFormData / etc.

[04:49:55.0000] <JakeA>
toString is the tricky one

[04:50:05.0000] <JakeA>
I guess toText is fine

[04:50:10.0000] <annevk>
yeah

[04:50:18.0000] <annevk>
we'd mimic XHR naming

[04:51:00.0000] <annevk>
if you invoke one of them, set a flag so the others return a rejecting promise?

[04:51:44.0000] <JakeA>
I guess that would be our "in the mean time" behaviour. Eventually it'll reject if the stream has already been read

[04:52:16.0000] <annevk>
yeah, but if you invoke one again or a another while a stream is being read, it seems best to simply reject

[04:52:41.0000] <JakeA>
Aren't we describing the same thing?

[04:52:55.0000] <annevk>
<canvas> uses the toBlob() naming too, but there it keeps working

[04:53:12.0000] <annevk>
but I guess that's fine since you should expect them to do something else on a stream vs a steady object

[04:53:27.0000] <annevk>
JakeA: we might :)

[05:00:59.0000] <tobie>
JakeA: toJSON was also highlighted as being problematic and asJSON was suggested instead.

[05:01:39.0000] <JakeA>
tobie: What's wrong with toJSON?

[05:02:09.0000] <tobie>
it's used by JSON.stringify

[05:03:22.0000] <JakeA>
ah fuck

[05:04:11.0000] <annevk>
then all of them should be as*

[05:04:24.0000] <tobie>
annevk: agreed.

[05:04:34.0000] <JakeA>
Just sent that

[05:04:39.0000] <annevk>
I'm gonna have some lunch while you guys sort it out :)

[05:10:33.0000] <zcorpan>
ok see you guys in 6 weeks

[05:52:00.0000] <krit>
annevk: thanks... will add that

[06:01:47.0000] <annevk>
krit: what's the best way to get SVG updated with respect to all the IRI language? Send email?

[06:02:12.0000] <krit>
annevk: oh, I am actually working on it right now... do you want to do the edits?

[06:02:29.0000] <annevk>
mathiasbynens: maybe you should add to http://javascript.spec.whatwg.org/#goals that we want to upstream all the things ideally

[06:02:30.0000] <krit>
annevk: I probably need a couple of days anyway

[06:02:53.0000] <annevk>
krit: oh wow, great

[06:02:57.0000] <krit>
annevk: if you want to edit, ping heycam ... not sure how strict he seed the editing policies

[06:03:04.0000] <annevk>
krit: I was wondering how easy it would be for me to help editing

[06:03:10.0000] <krit>
s/seed/sees/

[06:03:12.0000] <annevk>
krit: are you guys hosting on GitHub?

[06:03:29.0000] <krit>
annevk: sadly not :(

[06:03:30.0000] <mathiasbynens>
annevk: good point, that can never be made clear enough

[06:04:46.0000] <krit>
annevk: we have a mercurial repository

[06:04:58.0000] <krit>
annevk: heycam would need your public key

[06:05:10.0000] <annevk>
mathiasbynens: since that is always the first complaint :)

[06:06:07.0000] <annevk>
krit: hmm, I guess for now I'll stick to sending feedback then

[06:06:24.0000] <krit>
annevk: that definitely works. Please do that!

[06:06:27.0000] <annevk>
krit: not sure I have a public key

[06:06:40.0000] <annevk>
well, prolly a GH generated one

[06:06:47.0000] <krit>
annevk: you can also send your private key to heycam  ;)

[06:06:54.0000] <annevk>
hehe

[06:31:19.0000] <MikeSmith>
what's the difference between "pixel density" and "pixel depth"? do they mean the same thing?

[06:32:56.0000] <annevk>
MikeSmith: I think pixel depth is an alternative term for color depth

[06:33:07.0000] <MikeSmith>
ah

[06:33:20.0000] <darobin>
MikeSmith: two sides of the same thing; pixels representing YouTube comments are pretty dense, whereas those used for, say, Feynman quotes are pretty whoa deeep

[06:33:29.0000] <MikeSmith>
haha

[06:34:09.0000] <Ms2ger>
Whereas the pixels used for darobin quotes are a waste of electricity :)

[06:34:28.0000] <darobin>
aren't we in a sweet mood today Ms2ger

[06:34:53.0000] <Ms2ger>
I don't do sweet, dear :)

[06:35:45.0000] <darobin>
what a darling

[06:46:58.0000] <annevk>
Ms2ger: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26014

[06:48:26.0000] <Ms2ger>
Is "The append(name, value, filename) method must run these steps:" supposed to cover the append(ScalarValueString name, ScalarValueString value) signature too?

[06:48:47.0000] <annevk>
I don't see why not

[06:49:25.0000] <Ms2ger>
I guess #create-an-entry does handle strings

[06:49:35.0000] <annevk>
Yes

[06:50:00.0000] <Ms2ger>
Mm

[06:50:07.0000] <Ms2ger>
I guess it's fine

[06:50:22.0000] <Ms2ger>
It feels a little weird

[06:58:49.0000] <annevk>
Domenic: to(x) -> asX()

[06:59:14.0000] <annevk>
Will implement that change now

[07:30:17.0000] <Ms2ger>
/me forwards to annevk... "what is an example of a DOM class people would like to be able to subclass?"

[07:30:48.0000] <annevk>
Ms2ger: I think all of them, basically

[08:02:35.0000] <annevk>
/me wonders what GROSA in https://twitter.com/lucasmourelle/status/479610741058994177 means

[08:54:15.0000] <JonathanNeal>
Would CSS pseudos like :heading add selector weight?

[08:54:50.0000] <jgraham>
We have tried and failed to get :heading(N) before

[08:56:40.0000] <JonathanNeal>
Then let me rephrase; are CSS pseudo elements weighted with elements or class/attributes?

[08:57:26.0000] <SamB>
jgraham: what would that do?

[08:58:11.0000] <annevk>
JonathanNeal: what does weighted mean?

[08:58:15.0000] <jgraham>
JonathanNeal: I don't understand what you mean "weighted" (but that might just mean I don't know CSS terminology)

[08:58:39.0000] <annevk>
JonathanNeal: do you mean specificity? In which case, yes

[08:59:01.0000] <SamB>
yeah, pretty sure he meant specificity

[08:59:03.0000] <JonathanNeal>
I’m referring to selector weight. It typically goes ID.Attribute.Element.

[08:59:24.0000] <JonathanNeal>
Oh, sorry for using the wrong terminology.

[08:59:26.0000] <SamB>
JonathanNeal: you talking about how more-specific selectors are supposed to override less-specific selectors?

[08:59:46.0000] <SamB>
not cascading, mind!

[09:00:00.0000] <SamB>
/inheritance

[09:00:49.0000] <JonathanNeal>
Do CSS pseudo elements share the same specificity as elements? eg `:first-child` has the same specificity as `p`.

[09:01:43.0000] <JonathanNeal>
And gosh, I don’t even know if I just accidentally confused pseudo elements with pseudo classes.

[09:01:45.0000] <SamB>
hmm, I'd sorta hope :first-child would rank a bit higher ...

[09:01:56.0000] <SamB>
I think you did

[09:02:48.0000] <SamB>
I think pseudo-elements don't even *need* higher specificity due to being nested inside real elements

[09:04:36.0000] <Domenic>
wow such confusion so specificity much selectors

[09:04:49.0000] <JonathanNeal>
What I really want to know is, was the proposed :heading(N) selector a pseudo element, and if it was, would it have been the same weight as h1-6?

[09:05:10.0000] <JonathanNeal>
weight/specificity

[09:05:23.0000] <annevk>
It was a class

[09:05:34.0000] <Domenic>
so to be clear, when we talk about weight, we're talking about how much they weigh in earth gravity? because they use CSS on the international space station too

[09:05:39.0000] <annevk>
Since it matched an existing node, it didn't generate one

[09:06:10.0000] <annevk>
Domenic: it depends on how far away you are from the screen

[09:06:17.0000] <Domenic>
walked right into that one...

[09:07:04.0000] <annevk>
JonathanNeal: http://dev.w3.org/csswg/selectors/#specificity

[09:07:06.0000] <Domenic>
annevk: interesting, re to->as. Might be able to convince myself that whenever you see "stream as x" you should read that as "consume the stream and get back the result as an x"

[09:07:10.0000] <SamB>
I'm pretty sure that e.g. weighted averages work exactly the same in the ISS as on earth

[09:07:12.0000] <SamB>
;-P

[09:08:23.0000] <SamB>
Domenic: so "stream as opus" means?

[09:08:25.0000] <Domenic>
annevk: still think using the verb "read" would be better in some way. Although readAsJSON() sounds like it would just read the next chunk (since read() reads the next chunk). Bringing us to the overly-verbose readToEndAsJSON(). So yeah maybe I can convince myself "as" is an abbreviation for "read to end as"

[09:08:46.0000] <JonathanNeal>
Sometimes I confuse the “S” in CSS with inheritance. Thanks for walking me through things in a manner fitting the Benny Hill theme.

[09:09:03.0000] <Domenic>
#horse_#whatwg

[09:09:29.0000] <JonathanNeal>
I’ll be sure to use this conversation in future interviews. “Look at how well I misunderstood the syntax. Impressive, no?”

[09:10:23.0000] <Ms2ger>
JonathanNeal, did you mean the C?

[09:11:00.0000] <JonathanNeal>
https://www.youtube.com/watch?v=MK6TXMsvgQg

[09:12:29.0000] <JonathanNeal>
Domenic: I was reading your thread https://github.com/ThePacielloGroup/html5-h/issues/27 which is how I came to ask these questions (and malfunction).

[09:13:31.0000] <JonathanNeal>
So I wrote an alternative polyfill that re-arranges the weight on DOM mutations. https://github.com/ThePacielloGroup/html5-h/issues/28

[09:13:55.0000] <JonathanNeal>
And as I was thinking about the issue of selector specificity, I came here, and failed.

[09:14:07.0000] <Domenic>
oh nice, iwas thinking about writing such a thing

[09:14:40.0000] <SamB>
Hixie: so, how come there's not a README in http://svn.whatwg.org/webapps to give a clue how to rebuild?

[09:15:13.0000] <JonathanNeal>
Domenic: If you’re interested, I could put it in its own project and make you a co-admin.

[09:16:35.0000] <Domenic>
JonathanNeal: tempting, but I think I'll have to decline. That would push me over the edge from "caring enough to comment on issues and threads" to "caring enough to do actual work on a good solution," which is more caring than I should really invest.

[09:17:01.0000] <Ms2ger>
gsnedders, take your laptop outside?

[09:20:58.0000] <JonathanNeal>
Domenic: such honesty so clear

[09:21:46.0000] <JonathanNeal>
I should really be contributing to all the responsive element discussions, but I’m easily distracted.

[09:39:57.0000] <annevk>
SamB: I don't think the scripts are open source

[09:40:27.0000] <annevk>
SamB: if you ask Hixie privately you can get the details and hopefully his new system will be completely out there

[09:44:51.0000] <gsnedders>
Ms2ger: I wouldn't be able to see the screen in the sun

[09:45:05.0000] <Ms2ger>
In Scotland?

[09:45:09.0000] <Ms2ger>
[citation needed]

[09:46:18.0000] <SamB>
have you seen how many languages that comic has been translated to, with recolored bunting and everything?

[09:46:18.0000] <gsnedders>
We're have one of our seven days of sun today.

[09:48:55.0000] <TabAtkins>
jgraham: I don't think we *failed* to get :heading(n). It just wasn't all that interesting. Nothing blocked it, I don't think.

[09:49:16.0000] <jgraham>
That sounds like "failed to get"

[09:51:28.0000] <TabAtkins>
There's a difference between 500 and 503.

[09:52:31.0000] <jgraham>
Not from the point of view of the end user

[09:54:31.0000] <TabAtkins>
From the point of view of someone trying to mess about with the relevant standards, though, there is.

[09:54:38.0000] <TabAtkins>
Here, the standards bodies are the browser.

[09:59:17.0000] <jgraham>
FWIW I think there were actually technical objections about perf

[09:59:44.0000] <jgraham>
I would love a :heading(N) selector, so I hope I am wrong

[09:59:59.0000] <jgraham>
But I don't think it was just a case of "we can't be bothered to look at this"

[10:00:32.0000] <TabAtkins>
jgraham: Meh, can run outline algo once on the page and attach a short int to every heading.

[10:01:06.0000] <TabAtkins>
No one will complain if :heading(256) fails to select the correct heading.

[10:01:12.0000] <SamB>
TabAtkins: indeed

[10:01:23.0000] <SamB>
that's WAAAY too much nesting

[10:01:38.0000] <SamB>
and you wouldn't be able to see a heading that small ;-P

[10:02:48.0000] <jgraham>
TabAtkins: But if the dom changes the depth will change. Possibly in a non-local way

[10:02:58.0000] <TabAtkins>
Mm, true.

[10:03:06.0000] <TabAtkins>
Stupid non-static DOM.

[10:08:45.0000] <annevk>
mounir: so I bought some 99% chocolate, that shit is hardcore

[10:08:57.0000] <annevk>
mounir: back to 70% for now

[10:22:50.0000] <TabAtkins>
annevk: Yeah, 70-80 is my limit too.

[10:23:09.0000] <TabAtkins>
But my friend Emil hates sweet things, and there's a chocolatier near me that does 99% and 100% truffles, which he fell in love with.

[10:23:14.0000] <jgraham>
YOu know the quality of chocolate isn't a function of its cocoa percentage, right?

[10:23:47.0000] <jgraham>
Well not a monotonically increasing function at least

[10:23:50.0000] <SamB>
I assume 0% chocolate is unacceptable, though

[10:25:03.0000] <jgraham>
0% chocolate? Well if it's being sold as "chocolate", yes. If it's being sold as "cheese" it's probably better than 30% chocolate. Well depending on which cheese it is.

[10:25:04.0000] <TabAtkins>
jgraham: Of course, but it's an important factor in the quality.

[10:26:35.0000] <jgraham>
It's one piece of information that tells you something about the likely taste

[10:27:36.0000] <jgraham>
SamB: And now I think about it white chocolate is 0% cocoa solids. It's an entirely different product ofc, but can be nice

[10:32:05.0000] <SamB>
jgraham: huh, so what's it actually made of?

[10:32:39.0000] <jgraham>
Cocoa butter, sugar and milk, usually with vanilla flvouring

[11:24:43.0000] <mounir>
annevk: you don't eat 99% chocolate the same way as you eat 70%, you know, right?

[11:26:39.0000] <jgraham>
Depends how you eat 70%?

[11:27:01.0000] <Ms2ger>
"Not"

[11:40:08.0000] <Ms2ger>
/me wonders what's up with the data- attributes at https://developers.google.com/web/fundamentals/getting-started/your-first-multi-screen-site/content

[11:43:08.0000] <caitp>
they make validators happy

[12:28:47.0000] <gsnedders>
hmm

[12:28:55.0000] <gsnedders>
something is wrong with Hixie's branches on html5lib

[12:29:03.0000] <Hixie>
hm?

[12:30:16.0000] <gsnedders>
all the branches same to include the same initial commit (6825810c65) and then a merge with master

[12:31:51.0000] <gsnedders>
I presume that commit should be on newtests?

[12:33:44.0000] <gsnedders>
huh, the following merge commit seems to undo that change

[12:34:26.0000] <Hixie>
oh that's probably that weird commit i didn't understand

[12:34:29.0000] <Hixie>
from march?

[12:34:38.0000] <Hixie>
it seems to be empty?

[12:35:49.0000] <gsnedders>
https://github.com/html5lib/html5lib-tests/commit/6825810c650a6277933a5db860e973382355a5cc is pretty clearly not empty

[12:36:02.0000] <gsnedders>
but combined with the merge that follows it, they change nothing

[12:43:42.0000] <krit>
Hixie: Hi. There are still some appearances of Path() in the spec: "The Path() constructor, when invoked, must return a newly created Path2D object." http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path2d

[12:43:51.0000] <Hixie>
oops

[12:43:58.0000] <Hixie>
fiel a bug?

[12:44:00.0000] <Hixie>
file

[12:44:16.0000] <krit>
K

[12:44:27.0000] <krit>
On Bugzilla?

[12:52:47.0000] <Hixie>
yeah

[12:52:50.0000] <Hixie>
you can use the form on the spec

[12:52:54.0000] <Hixie>
bottom right

[13:16:49.0000] <Hixie>
TabAtkins: it's not so much that no page will be using that feature that matters, it's that no page using that feature will be affected by the removal of that feature

[13:17:23.0000] <Hixie>
gsnedders: i got a lot of e-mail about the tests, am i supposed to do anything with them?

[13:19:18.0000] <gsnedders>
Hixie: no, there are just pull requests that you're tagged in

[13:20:09.0000] <Hixie>
k

[13:21:13.0000] <jgraham>
Any and all email from github is effectively spam because it generates so much of it that you have to find some other way of following activity

[13:24:14.0000] <TabAtkins>
Hixie: Yeah, sure.

[13:28:05.0000] <Hixie>
TabAtkins: i mention that only because it removes the need for handwaving away the crazy pages that use the feature even though it doesn't yet work

[13:28:36.0000] <TabAtkins>
Ah, yeah, that's the "degenerate cases" I alluded to.

[13:29:55.0000] <Hixie>
right

[13:35:00.0000] <SamB>
so, um, there's a <header> element, but there's no way to style it properly? That's ... useful ...

[13:35:48.0000] <Hixie>
hm?

[13:35:57.0000] <Hixie>
it should style the same as any other element

[13:44:08.0000] <SamB>
Hixie: hmm, maybe I'm confused about what :header(n) would do

[13:44:15.0000] <Hixie>
what's :header(n) ?

[13:44:51.0000] <SamB>
Hixie: a non-thing, presently

[13:45:13.0000] <SamB>
or maybe it was :heading(n)

[13:45:34.0000] <Hixie>
i'm confused...

[13:46:39.0000] <SamB>
TabAtkins and jgraham mentioned, er, :heading(n) as a proposal that failed to gain traction ...

[13:47:33.0000] <Hixie>
and from that you concluded that <header> couldn't be styled...?

[13:48:10.0000] <SamB>
Hixie: no, I just jumped to confusions about what <header> is supposed to be

[13:48:12.0000] <jgraham>
<header> isn't teh same thing

[13:48:15.0000] <SamB>
forget I mentioned <header>

[13:48:20.0000] <SamB>
I was confused

[13:48:20.0000] <Hixie>
k...

[13:48:47.0000] <SamB>
so what would :header(n) have been for?

[13:48:48.0000] <SamB>
er.

[13:48:51.0000] <SamB>
:heading(n)

[13:50:09.0000] <TabAtkins>
SamB: <header> isn't a heading, in the <h1> sense.

[13:50:19.0000] <TabAtkins>
Ok, I see you got that already. ^_^

[13:50:23.0000] <SamB>
yeah

[13:51:09.0000] <Hixie>
it'd probably be a way to directly target headings of a particular depth

[13:51:13.0000] <Hixie>
in the outline

[13:51:20.0000] <Hixie>
(i'm just guessing)

[13:51:23.0000] <TabAtkins>
Yeah, that's what :heading(n) is supposed to do.

[13:52:10.0000] <TabAtkins>
In <section><h1>foo</h1> <section><h1>bar</bar> </section></section>, :heading(1) would target foo and :heading(2) would target bar.

[13:52:35.0000] <TabAtkins>
(Actually, because of the section implied by <body>, those are probably :heading(2) and :heading(3).)

[13:53:00.0000] <SamB>
TabAtkins: hmm, that seems kind of like a bad idea

[13:53:11.0000] <SamB>
how would you ever get a :heading(1) then

[13:53:22.0000] <jgraham>
<body><h1>

[13:53:26.0000] <SamB>
ah

[13:53:29.0000] <SamB>
nevermind ;-)

[13:53:44.0000] <SamB>
/me slaps forehead. except he's too lazy to actually do it

[13:54:19.0000] <TabAtkins>
Too lazy to even move your hand. How lazy.

[13:54:39.0000] <SamB>
still, it seems rather confusing to use h1 that way

[13:55:09.0000] <SamB>
what would it do with <hgroup>? anything?

[13:55:23.0000] <SamB>
ignore the descendants, perhaps?

[13:56:04.0000] <Hixie>
<hgroup> is a heading with the same status as the highest-ranked heading inside it

[13:56:17.0000] <Hixie>
(h1 is highest, h6 is lowest)

[13:56:38.0000] <Hixie>
and affects the outline accordingly

[13:56:49.0000] <SamB>
but, would a :heading() rule allow you to style it sensibly?

[13:57:15.0000] <SamB>
I guess you could use element-type selectors for that part ...

[13:57:30.0000] <Hixie>
depends how it would be defined

[13:57:48.0000] <Hixie>
it's almost certainly academic since i doubt browsers will ever implement a selector that depends on the outline

[13:57:56.0000] <SamB>
:-(

[13:58:01.0000] <Hixie>
just like they won't implement a selector that depends on substringing inline text

[13:58:07.0000] <Hixie>
too expensive

[13:59:30.0000] <SamB>
substringing inline text sounds a lot MORE expensive

[14:00:38.0000] <Hixie>
once it crosses the bar of "expensive", exactly _how_ expensive it is is somewhat irrelevant

[14:17:33.0000] <SamB>
Hixie: well, how hard have they thought about this stuff?

[14:25:12.0000] <SamB>
Hixie: I mean, obviously they can't recalculate section levels any faster than O(n) while moving a subtree between sectioning levels ...

[14:26:34.0000] <SamB>
/me is imagining an overlayed tree for the outline

[14:29:58.0000] <SamB>
also, I'm assuming outlining would be lazy; no sense doing it before something wants to see the outline

[14:31:14.0000] <SamB>
or for irrelevant parts of the tree

[14:33:43.0000] <SamB>
gsnedders: what's with the huge styling on http://gsnedders.html5.org/outliner/ ?

[14:34:03.0000] <SamB>
and, ow, that file input thing is much wider than it looks

[14:34:17.0000] <Hixie>
SamB: the outline tree is worse than O(N) by depth of tree

[14:34:18.0000] <SamB>
no wonder I got so many file browser dialogs

[14:34:46.0000] <SamB>
Hixie: I was thinking more in terms of O(n) for nodes visited

[14:35:05.0000] <SamB>
maybe it's a problem that browsers want to know how tall the page is though :-(

[14:38:19.0000] <Hixie>
you need to visit quite a lot of nodes to figure out the outline depth of a node

[14:38:39.0000] <SamB>
at some point, certainly

[14:40:38.0000] <SamB>
Hixie: hmm, who *does* use the outlining algorithm, anyway?

[14:42:33.0000] <Hixie>
anyone who wants to e.g. generate a table of contents

[14:44:00.0000] <SamB>
would there be many compatability problems caused by changes to the algorithm in the spec?

[14:45:41.0000] <gsnedders>
SamB: idk

[14:45:47.0000] <gsnedders>
SamB: stop assuming logic!

[14:45:52.0000] <Hixie>
SamB: compatibility, probably not

[14:46:01.0000] <SamB>
gsnedders: I wasn't necessarily assuming that

[14:46:15.0000] <gsnedders>
SamB: I dunno, it was basically hacked together one evening

[14:54:43.0000] <gsnedders>
jgraham: https://critic.hoppipolla.co.uk/r/431 doesn't match the PR

[14:54:49.0000] <gsnedders>
jgraham: can you fix that?

[14:55:23.0000] <Hixie>
gsnedders: btw do all the test updates look ok? or did i make any mistakes?

[14:55:38.0000] <gsnedders>
Hixie: I'm just looking through all the PRs now :P

[14:55:51.0000] <gsnedders>
Hixie: I just added them so they were there and didn't get forgotten about mostly

[14:56:05.0000] <Hixie>
ah ok cool

[14:56:09.0000] <Hixie>
let me know if you have any questions

[14:56:20.0000] <Hixie>
i'm staring at the code as we speak so it's a good time for me, it's all paged in :-)

[14:57:49.0000] <gsnedders>
oh god new AAA tests

[14:57:53.0000] <gsnedders>
I don't even want to consider this

[15:01:44.0000] <gsnedders>
Hixie: you wouldn't happen to be in the brief, rare state of understanding the AAA? :)

[15:01:56.0000] <Hixie>
lol

[15:02:01.0000] <Hixie>
wait, _new_ AAA tests?

[15:02:07.0000] <gsnedders>
not by you

[15:02:07.0000] <Hixie>
which tests are these

[15:02:10.0000] <Hixie>
oh ok good

[15:02:18.0000] <gsnedders>
https://github.com/html5lib/html5lib-tests/pull/26 includes new AAA tests

[15:02:19.0000] <Hixie>
i can run them by my implementation and tell you if i pass them... :-)

[15:02:21.0000] <gsnedders>
I don't want to review them

[15:02:27.0000] <gsnedders>
because oh-god-the-AAA

[15:03:35.0000] <Hixie>
i'm not seeing any formatting elements on that page

[15:04:13.0000] <gsnedders>
look at the individual commits, near the bottom

[15:04:29.0000] <Hixie>
https://github.com/revite/html5lib-tests/commit/912be08fa4fd82e2dcee7351f0f468aa9f6fa5c3 ?

[15:04:47.0000] <gsnedders>
there are two new AAA tests I think there

[15:04:48.0000] <gsnedders>
that's one

[15:06:42.0000] <gsnedders>
Hixie: FWIW, I'd rather slightly more descriptive commit messages, like saying what the new tests are testing for

[15:07:09.0000] <Hixie>
noted

[15:07:15.0000] <gsnedders>
and like, what spec changes are https://github.com/html5lib/html5lib-tests/pull/42 for?

[15:08:45.0000] <Hixie>
we've removed a few attributes from the list

[15:11:16.0000] <SamB>
maybe give revision numbers or, heck, links?

[15:11:27.0000] <gsnedders>
revision numbers are more what I'm looking for here :)

[15:12:00.0000] <Hixie>
i've no clue

[15:12:07.0000] <Hixie>
i just copied-and-pasted the spec table into my code

[15:12:23.0000] <Hixie>
then checked the results to see if they were what i remembered

[15:12:25.0000] <Hixie>
and they were

[15:13:12.0000] <SamB>
Hixie: is it true that the reason you don't have a README or Makefile in http://svn.whatwg.org/webapps that the buildsystem involves proprietary software?

[15:13:29.0000] <jgraham>
gsnedders: No idea what's going on with that PR, the branch is it supposed to be based on is just master

[15:13:34.0000] <SamB>
hmm, whoops, grammar fail :-(

[15:13:57.0000] <Hixie>
SamB: no, i just haven't bothered since there's not much point other people generating the spec

[15:14:22.0000] <SamB>
Hixie: I just want to try to add some interlinks, or maybe play with the JS stuff

[15:14:27.0000] <Hixie>
(plus my pipeline right now is a disaster anyway)

[15:16:26.0000] <Hixie>
gsnedders: https://github.com/revite/html5lib-tests/commit/912be08fa4fd82e2dcee7351f0f468aa9f6fa5c3 passes my implementation

[15:18:06.0000] <Hixie>
gsnedders: https://github.com/revite/html5lib-tests/commit/42289424296cc238bb8afe4c313650d0724985c0 does not

[15:18:48.0000] <gsnedders>
Hixie: now tell me which is wrong :)

[15:18:51.0000] <Hixie>
gsnedders: specifically, i disagree with "                                                                                       |45: Unclosed element "code"."

[15:18:55.0000] <Hixie>
er

[15:19:03.0000] <Hixie>
with "45: Unclosed element "code""

[15:19:39.0000] <Hixie>
though i don't see why

[15:19:44.0000] <Hixie>
maybe that's a bug in my implementation

[15:20:15.0000] <Hixie>
oh, i see why

[15:20:20.0000] <Hixie>
it's redundant with the previous one

[15:21:12.0000] <gsnedders>
Hixie: can you add a comment on the commit? I think if you mouse-over the line you'll get some message bubble?

[15:21:20.0000] <gsnedders>
if the test is wrong/

[15:21:21.0000] <gsnedders>
*?

[15:21:35.0000] <Hixie>
already done

[15:21:56.0000] <Hixie>
also i hate that github comments accept html

[15:22:32.0000] <gsnedders>
they do…?

[15:24:21.0000] <SamB>
gsnedders: insofar as github's flavour of markdown does, yes

[15:25:07.0000] <gsnedders>
"Update for spec changes changing what SVG attributes are changed" — I'm not sure that's a better commit message

[15:25:34.0000] <gsnedders>
change the change with changes

[15:25:39.0000] <Hixie>
CHANGE IT

[15:26:33.0000] <SamB>
gsnedders: huh?

[15:32:41.0000] <gsnedders>
Hixie: looking at the readme update, I'm just like, "template contents are represented like that? well, okay"

[15:32:50.0000] <Hixie>
apparently

[15:35:04.0000] <gsnedders>
jgraham: "Merge 991cc674 adds merged-in commits.  Please push the merge manually and follow the instructions." — I can't do that.


2014-06-20
[22:00:05.0000] <zcorpan>
Hixie: can you pls regen? kthxbye :-)

[22:31:05.0000] <Hixie>
zcorpan: i tried, but got assertion errors in anolis since i was still set to using html5lib

[22:31:12.0000] <Hixie>
zcorpan: will try again tomorrow

[00:19:38.0000] <Ms2ger>
gsnedders, way to spam me :)

[00:36:57.0000] <annevk>
mounir: heh, sure, this 70% is better quality too, Lindt is okay

[01:14:26.0000] <annevk>
Heh, why did I not see http://dev.w3.org/html5/decision-policy/html5-2014-plan.html until now

[01:15:28.0000] <annevk>
I love how first it says "monolithic kitchen sink specification" (without acknowledging that is a WHATWG graphic and that the situation at the W3C is different) and then goes on to claim "HTML5 is good at modularity" as if they didn't just say monolithic

[01:31:58.0000] <jgraham>
gsnedders: I doubt I can either.

[01:32:04.0000] <jgraham>
Which review is this?

[01:50:41.0000] <darobin>
annevk: I won't necessarily defend "plan 2014", certainly not to the letter, but in fairness the link to the image is straight to http://images.whatwg.org/abstract.png which, well, doesn't exactly hide the provenance :)

[01:51:27.0000] <darobin>
also, it is entirely possible to believe that a specification is handled in a monolithic manner but that the technology lends itself to (some forms of) modularity

[01:54:09.0000] <annevk>
(my point was mostly that WHATWG HTML is larger than W3C HTML5; so that using that graphic as representing W3C HTML5 is weird, especially with the weird Jeff Jaffe modular dance it is followed with)

[01:55:10.0000] <darobin>
annevk: yeah, I won't dispute that there's weirdness

[02:11:13.0000] <jgraham>
What's the best URL to use as a reference for web-platform-tests?

[02:12:49.0000] <annevk>
https://github.com/w3c/web-platform-tests

[02:13:31.0000] <jgraham>
Not really that useful as an introduction to what wpt *is*

[02:15:27.0000] <darobin>
jgraham: depends on what level of introduction — perhaps the README should be pimped to serve the purpose you have in mind?

[02:17:34.0000] <annevk>
krit: is there anything left we need to work on?

[02:17:51.0000] <jgraham>
darobin: Yeah, perhaps that's the right solution. It just means the answer to my original question depends on me actually creating such an introduction

[02:19:20.0000] <darobin>
jgraham: I think it may be useful, nothing obvious jumps at me from the TestTWF docs

[03:17:45.0000] <annevk>
darobin: that email broke threading again

[03:18:34.0000] <annevk>
Though it did not on http://lists.w3.org/Archives/Public/www-svg/2014Jun/thread.html

[03:18:43.0000] <annevk>
Gmail :/

[03:18:46.0000] <darobin>
that's what I was going to say

[03:18:53.0000] <darobin>
I think the problem is at your end

[03:19:03.0000] <darobin>
the message has all the right Reply-To stuff

[03:19:17.0000] <annevk>
I guess Gmail sorts on Subject?

[03:20:01.0000] <darobin>
Thunderbird is a clusterfuck of brokenness on small trivial things like not corrupting mailboxes or not breaking its own UI every other minute; but you can be sure it got mailing list headers right

[03:20:18.0000] <darobin>
I have no idea, I always found GMail completely unusable

[03:22:09.0000] <annevk>
I find it super awesome, except for plain text and I guess the header stuff

[03:22:43.0000] <annevk>
Opera Mail was really great at those things, was hard to switch away from that

[03:25:41.0000] <darobin>
I never got to try Opera Mail because it crashed importing my email every single time I decided to give it a shot

[03:27:49.0000] <jgraham>
Wow the one thing that you can't accuse Thunderbird of is updating the UI too often

[03:27:56.0000] <jgraham>
It's changed like once in about 5 years

[03:30:48.0000] <gsnedders>
One thing you can't accuse Opera Mail of is changing, like, ever.

[03:35:21.0000] <darobin>
jgraham: I didn't accuse it of updating — but it (dynamically) breaks an awful lot

[03:35:53.0000] <jgraham>
Oh, I see

[03:35:58.0000] <Ms2ger>
I haven't had that experience

[03:36:07.0000] <jgraham>
I don't really rembmer that happening recently

[03:36:14.0000] <darobin>
just this morning I undeleted a mail in a thread, it made it show the thread twice in the box view, with one copy gradually losing its subject (and showing Jan 1970 for the date) as I deleted from the other

[03:36:42.0000] <darobin>
then it became impossible to delete the ghost thread

[03:36:49.0000] <darobin>
just another day with Thunderbird :)

[03:37:20.0000] <jgraham>
You might be using more advanced features than me :)

[03:38:08.0000] <darobin>
jgraham: it's true that figuring out how to enabling threading required pretty advanced experimental sleuthing

[03:38:17.0000] <darobin>
*enable

[03:42:29.0000] <Ms2ger>
I guess I never delete emails :)

[03:42:56.0000] <jgraham>
Yeah that's a point. I only delete spam

[03:43:31.0000] <gsnedders>
What kinda of weirdo deletes emails?

[03:43:33.0000] <gsnedders>
Oh, wait, darobin.

[03:47:22.0000] <jgraham>
evidently

[03:48:21.0000] <jgraham>
Which incidentially sounds like his album of terrible MOR music aimed at middle aged women "darobin: evidently"

[04:02:37.0000] <darobin>
ow, that's just mean jgraham :)

[04:04:13.0000] <darobin>
I guess it's the kind of music you could listen to while reading http://www.amazon.co.uk/The-Darobin-Legend-Mysterious-Warriors/dp/059529832X

[04:06:53.0000] <MikeSmith>
/me edits the Plan 2014 doc to add a link to http://ecx.images-amazon.com/images/I/513JXR8S50L._.jpg

[04:07:23.0000] <darobin>
haha

[06:14:45.0000] <annevk>
JakeA: Domenic: I've been looking into defining progress events better and something occurred to me. Streams will not help with actually identifying how many bytes transfered

[06:15:54.0000] <annevk>
JakeA: Domenic: HTTP network and cache fetch layer deals with content encodings and as such those details never make it all the way through

[06:17:57.0000] <JakeA>
annevk: hmm, so we need bytesReceived and bytesExpected on response.body?

[06:20:29.0000] <annevk>
JakeA: I'm not sure what the best solution is

[06:22:15.0000] <JakeA>
annevk: will there be the same issue reading from disk, or is this unique to web requests?

[06:22:37.0000] <JakeA>
annevk: bah, gotta go flight mode, for a flight no less

[06:23:02.0000] <annevk>
JakeA: I think this is unique to HTTP

[06:23:29.0000] <annevk>
JakeA: although it depends a bit on how we deal with zipped storage and such I guess

[06:23:46.0000] <annevk>
JakeA: we haven't really started exploring those details until recently

[06:24:07.0000] <annevk>
JakeA: safe travels

[06:24:28.0000] <annevk>
JakeA: I'm away starting second week of July

[06:49:26.0000] <hemanth>
/me is searching for some serious use-cases for generators 

[06:52:18.0000] <hemanth>
Domenic, I would be very useful if you could suggest me few use-case studies of generators :-)

[06:54:50.0000] <Ms2ger>
You could perhaps look at https://mxr.mozilla.org/mozilla-central/

[06:57:17.0000] <darobin>
I guess there's a reason they say "Helpful as a Ms2ger"

[06:57:20.0000] <hemanth>
Ms2ger, nice, the first thing I came across searching there was TODO: Bug 948484 - support arrow functions and ES6 generators :)

[06:57:24.0000] <zewt>
typically to make non-linear code linear, in my experience

[06:58:11.0000] <zewt>
similar to workers, i suppose

[06:59:04.0000] <Ms2ger>
darobin, so it's not only in my dreams they say that?

[06:59:06.0000] <hemanth>
I understand the power of yield

[06:59:53.0000] <hemanth>
Did some tree traversal with it as well, http://h3manth.com/new/blog/2014/tree-traversal-with-es6-generator/

[06:59:56.0000] <jgraham>
You use them anytime you want lazy iteration

[07:00:13.0000] <jgraham>
Which is pretty often in my experience

[07:00:14.0000] <zewt>
jgraham: i find that to be a nice bonus, but not the main benefit

[07:00:22.0000] <hemanth>
Control flow w/suspend and resume

[07:00:28.0000] <zewt>
at least in my use in python

[07:01:15.0000] <hemanth>
something like  var responses = yield [_get("index.html", resume()) is fun

[07:01:23.0000] <hemanth>
more like what koa and co does

[07:05:19.0000] <jgraham>
zewt: Are you talking about yield on the rhs?

[07:06:11.0000] <jgraham>
like foo = (yield bar())

[07:06:41.0000] <jgraham>
I don't think of that as a generator, although the PEP does call it "extended generators"

[07:07:17.0000] <zewt>
jgraham: no, the generator itself

[07:08:10.0000] <jgraham>
So I don't exactly see how you are using them to make non-linear code linear that doens't amount to iteration

[07:08:23.0000] <zewt>
the main benefit i find is being able to write the generator itself linearly, eg. as if it's the top-level function and it's calling a function to output values, rather than having to save state and be called independently several times

[07:09:00.0000] <jgraham>
Right, the implicit state saving is useful

[07:09:07.0000] <hemanth>
it's ideal to encode infinite sequences and operations over them

[07:09:12.0000] <jgraham>
Rather than having to write a class

[07:09:24.0000] <zewt>
it's a bigger benefit than the streaming itself, IMO

[07:43:13.0000] <Hixie>
jgraham: you got a sec for debugging anolis/pms?

[07:48:31.0000] <jgraham>
Hixie: Perhaps

[07:49:19.0000] <Hixie>
i'm hitting the assert isinstance(buffer,bytes) on line 535 of inputstream.py (detectEncodingMeta)

[07:50:22.0000] <Domenic>
annevk: why do streams not help with that?

[07:50:41.0000] <jgraham>
Hixie: What are you doing to hit it?

[07:51:08.0000] <Hixie>
jgraham: http://anolis.hoppipolla.co.uk/aquarium.py/output?uri=http://www.whatwg.org/specs/web-apps/current-work/source-whatwg-complete&process_toc=on&process_xref=on&process_sub=on&w3c_compat_xref_a_placement=on&w3c_compat_xref_elements=on&parser=html5lib&serializer=html5lib&omit_optional_tags=on&output_encoding=ascii

[07:56:39.0000] <jgraham>
Hixie: Well you are evidently getting punted down the "not unicode" codepath, but at some point getting unicode data

[07:56:45.0000] <jgraham>
I'm not sure why

[07:57:05.0000] <jgraham>
s/not unicode/raw bytes/

[07:57:24.0000] <Hixie>
i'm trying to use html5lib so i have a sane output that i can try to duplicate

[07:57:30.0000] <Hixie>
so in theory this will be the last time i need this

[07:57:39.0000] <Hixie>
so if you want to just band-aid it for now that's fine by me

[07:58:10.0000] <Hixie>
(the libxml.html + aaalib output that i was using before is not sane, especially with respect to whitespace)

[07:58:11.0000] <annevk>
Domenic: you could explain this as the network stream handing you a transformed stream without giving you access to the actual network bits

[07:58:28.0000] <Hixie>
oh, that reminds me

[07:58:34.0000] <jgraham>
Hixie: Well there is a real bug, probably in html5lib

[07:58:55.0000] <jgraham>
Somewhere around the code that SimonSapin changed to avoid a real bug in python

[07:58:59.0000] <Hixie>
annevk: i was talking to some folk at google the other day who do back-end html serving stuff, and they asked about a feature of service workers and i didn't know the answer

[07:59:08.0000] <Domenic>
annevk: yeah, i guess. but the transform stream could contain an accumulator that counts bytes transformed so far

[07:59:31.0000] <Hixie>
annevk: is there any way in service workers to batch requests? e.g. if the browser knows that it suddenly needs three scripts, can the service worker package them up into one back-end request and then split up the result?

[08:00:03.0000] <annevk>
Domenic: yeah, what JakeA was suggesting might work

[08:00:45.0000] <Domenic>
annevk: oh this is about progress events on service workers, not on XHR

[08:00:47.0000] <annevk>
Hixie: since you can do event.respondWith(promise), yes

[08:01:06.0000] <annevk>
Domenic: progress "events" for fetch()

[08:01:11.0000] <Domenic>
right

[08:01:36.0000] <Hixie>
annevk: how would you do the buffering? just set a timer for 1ms and see if you get any other requests in the meantime? or would the three requests be delivered to the worker at once?

[08:01:38.0000] <Domenic>
so RequestBodyStream should just be a stream of arraybuffers

[08:01:54.0000] <annevk>
Domenic: we recently figured out how exactly we wanted progress events for XMLHttpRequest to behave, while trying to figure out a plan as to how to write that in the specification I realized our streams approach is not quite ideal for that

[08:02:06.0000] <Domenic>
that's as close to "raw network bytes" as JavaScript gets

[08:02:26.0000] <annevk>
Domenic: no, Content-Encoding is already done at that point

[08:02:35.0000] <Domenic>
annevk: it shouldn't be.

[08:02:39.0000] <annevk>
Hixie: yeah I guess

[08:02:50.0000] <annevk>
Domenic: euhm

[08:02:56.0000] <Hixie>
annevk: would be nice if there was a less hacky way to know that a batch of requests came in at once

[08:03:02.0000] <Domenic>
annevk: RequestBodyStream should be raw bytes. If you want to decode, do `.pipeThrough(new TextDecoderTransform(request.headers["Content-Encoding"]))`

[08:03:26.0000] <Domenic>
s/["Content-Encoding"]/.get("Content-Encoding")

[08:03:52.0000] <annevk>
Hixie: how would you know such a thing?

[08:04:34.0000] <Hixie>
annevk: e.g. when i have the dependency thing i'm working on, and script A depends on scripts B, C, and D, and you tell the browser "i need script A!". The browser synchronously knows it needs A, B, C, and D.

[08:05:03.0000] <Hixie>
annevk: or similar for ES modules

[08:05:05.0000] <annevk>
Domenic: hmm, that would make fetch() noticeably harder to work with

[08:05:37.0000] <annevk>
Hixie: https://github.com/slightlyoff/ServiceWorker/issues/new ?

[08:08:02.0000] <Domenic>
annevk: add .asStringStream() then

[08:08:19.0000] <annevk>
Domenic: Content-Encoding has nothing to do with that

[08:08:39.0000] <Domenic>
annevk: then I don't understand; you said "Content-Encoding is already done at that point"

[08:09:02.0000] <Domenic>
oh dear

[08:09:07.0000] <annevk>
Domenic: browsers have a network & cache layer

[08:09:15.0000] <Domenic>
I'm getting Content-Encoding and text encoding mixed up

[08:09:20.0000] <annevk>
Domenic: that sits below the fetching layer

[08:09:26.0000] <annevk>
Domenic: which sits below the content layer

[08:09:42.0000] <Domenic>
so we're not exposing primitives to allow access to the raw, gzipped bytes?

[08:09:47.0000] <annevk>
Domenic: the network & cache layer deals with gzip and friends

[08:09:54.0000] <Domenic>
i thought that was the entire point of fetch having a stream API

[08:10:25.0000] <Domenic>
so if someone wants to fetch something and then store it on disk, you're going to un-gzip it first, then make them gzip it back to store efficiently on disk?

[08:11:03.0000] <annevk>
Domenic: I don't know, all I know is what we've explained so far

[08:11:22.0000] <Domenic>
annevk: I thought fetch was going to be a low-level API like Node's http.get

[08:11:27.0000] <Domenic>
or rather http.request

[08:11:33.0000] <annevk>
I'm not necessarily opposed to changing it, but that would require a bunch of coordination

[08:12:02.0000] <Domenic>
well does any of this impact near-term stuff? it seems all related to the eventual stream manifestation

[08:12:28.0000] <annevk>
Well, it seems it would affect whether you get a JSON object back or a failure because it was zipped

[08:12:31.0000] <jgraham>
Hixie: So I think upgrading html5lib has helped. I also think it's going to time out before you get a response…

[08:12:49.0000] <jgraham>
Oh, no, it worked

[08:13:33.0000] <Domenic>
nah, I figure asXXX can contain as many steps as you want, for maximum convenience

[08:13:41.0000] <annevk>
Domenic: whoa whoa whoa

[08:14:05.0000] <jgraham>
annevk doing his best Keanu Reeves impression there

[08:14:21.0000] <Domenic>
asJSON = is application/json? ok proceed; otherwise fail. is gzipped? pass through ungzip transform. now json parse. succeed? return object. fail ? return parse error

[08:14:45.0000] <Domenic>
i guess there's a text-decoding step there too

[08:14:51.0000] <Domenic>
after the ungzip

[08:15:20.0000] <Hixie>
jgraham: cool, let me try regenning...

[08:17:44.0000] <annevk>
Domenic: there is

[08:17:55.0000] <Hixie>
jgraham: thanks, looks like it worked!

[08:18:23.0000] <annevk>
Domenic: https://github.com/slightlyoff/ServiceWorker/issues/339

[08:18:36.0000] <jgraham>
Hixie: Great

[08:18:44.0000] <Domenic>
annevk: indeed. and if you're doing transforms from array buffers to text to object, makes sense to me to make that compressed array buffers to uncompressed ones to text to object

[08:19:11.0000] <Hixie>
man, what a diff

[08:19:25.0000] <JonathanNeal>
SteveF: re <h>, would it be better for me to file a pull request with my polyfill or to create a separate polyfill repo?

[08:19:41.0000] <annevk>
Domenic: maybe, though it also quite fundamentally impacts what is going on today

[08:19:48.0000] <SimonSapin>
jgraham: Do you mean https://github.com/html5lib/html5lib-python/issues/127 ? This was worked around in html5lib

[08:20:43.0000] <jgraham>
SimonSapin: I don't think it was actually that bug, but it must have been something we fixed relatively recently

[08:20:46.0000] <SteveF>
JonathanNeal: i think the discussion has a little way to go on it yet, I would hold off if you are interested in it being used

[08:21:40.0000] <SteveF>
JonathanNeal: have been busy with other things but plan to make further contribution to dicussion

[08:26:29.0000] <JonathanNeal>
SteveF: got it, thanks!

[08:26:47.0000] <Domenic>
annevk: I don't think it impacts any APIs fetch exposes today.

[08:27:22.0000] <Domenic>
annevk: and I think if we don't provide this level of access now, we'll have to do more archaeology and discover what's underneath fetch to enable certain use cases.

[08:29:45.0000] <Hixie>
annevk: https://github.com/slightlyoff/ServiceWorker/issues/340

[08:30:41.0000] <slightlyoff>
WAT

[08:31:25.0000] <slightlyoff>
I don't even...really? This can't be our bottleneck

[08:31:36.0000] <annevk>
slightlyoff: what are you talking about?

[08:31:50.0000] <slightlyoff>
We need advisory memory caching headers *long* before this

[08:32:00.0000] <slightlyoff>
#340

[08:32:44.0000] <Hixie>
i'm not making any assertions about prioritisation

[08:33:09.0000] <slightlyoff>
Do we have data to suggest we need it?

[08:33:41.0000] <slightlyoff>
Do browser caches work this way WRT IPC latency elimination today? (Chrome doesn't)

[08:33:58.0000] <Hixie>
i'm not sure what you're asking

[08:34:02.0000] <Hixie>
what would this have to do with caches?

[12:49:56.0000] <caitp>
so, I'm curious --- what is the new Request object referenced in the fetch spec supposed to offer over existing XHR?

[12:50:19.0000] <TabAtkins>
A sane, simple API.

[12:50:33.0000] <TabAtkins>
Versus the several lines of crap you have to remember and type out with every XHR today.

[12:51:08.0000] <caitp>
well that would be lovely, but we'll see

[12:51:17.0000] <caitp>
it doesn't look like anyone has begun implementing it yet though

[12:52:39.0000] <TabAtkins>
No, it's quite new.

[13:01:40.0000] <caitp>
yeah, I need to take another look at it---but really the question here is like, taking jQuery for example, if they're already abstracting XHR, do they gain anything from eventually also abstracting Request

[13:02:44.0000] <caitp>
I guess nobody knows for sure until implementations exist

[13:03:26.0000] <Domenic>
it also seems like it will expose more potential capabilities

[13:03:51.0000] <Domenic>
especially once it becomes streaming

[13:07:11.0000] <TabAtkins>
caitp: "Will the libraries switch to it" isn't really a useful argument; libraries can paper over *lots* of things.  Removing the necessity for libraries to exist for common pieces of the platform to be usable is important for the evolution of the platform.

[13:07:23.0000] <TabAtkins>
But also, yes, we'll be adding fun new things to Request over time.

[13:08:24.0000] <caitp>
well, I work on some of these libraries, so the question becomes "should we worry about adding support for Request once it's available --- what's the testability story like, etc"

[13:17:29.0000] <Domenic>
well Angular is just going to overwrite everything to make it "more testable" anyway, so I'm not sure why you're worried ;)

[13:17:45.0000] <Domenic>
TabAtkins: anything we can do about moving Status before TOC? I don't care that much, but would be nice.

[13:18:10.0000] <TabAtkins>
Domenic: Yes, planning on doing something about that, so you can supply a *local* version of some boilerplate and have it sub in instead.

[13:18:33.0000] <Domenic>
TabAtkins: Awesome! Will merge for now then.

[13:20:42.0000] <caitp>
it's not clear that we actually can "overwrite everything" when it comes to native code which uses native promises, since they might not respect our mocks :)

[15:52:07.0000] <gsnedders>
is it possible for Fetch to be polyfilled using XHR?

[15:54:02.0000] <caitp>
regarding what was being said earlier about extended possibilities (eg the Stream API), there's a bug open (or closed, I can't remember I didn't read it) about adding support for the stream api to xhr too

[15:54:38.0000] <caitp>
assuming you mean the interfaces defined in Fetch

[15:54:42.0000] <gsnedders>
yeah

[15:55:39.0000] <jsbell>
Depends what you mean by "polyfill" too. A useful, forward-compatible subset, certainly.

[15:55:53.0000] <gsnedders>
I was meaning the whole API

[15:56:00.0000] <gsnedders>
I mean obviously a subset is doable

[15:56:25.0000] <caitp>
definitely the streams thing is not really polyfillable, even in browsers with progress events

[15:56:57.0000] <caitp>
haven't gotten too far into that yet though, living in xhr land :>


2014-06-21
[17:10:33.0000] <JakeA>
Fetch can return opaque responses. You get detailed cors options, and soon you'll get streams. You'll be able to explain XHR in terms of fetch.

[17:10:45.0000] <JakeA>
But fetch does more, better

[17:17:13.0000] <TabAtkins>
Domenic: Okay, just landed the ability to replace boilerplate sections.  Should we come up with some decent default text, or should I just make an empty status-whatwg.include file and let you fill it in only when desired?

[18:58:59.0000] <JonathanNeal>
gsnedders: Fetch?

[20:01:33.0000] <zewt>
gsnedders: sit

[20:02:19.0000] <SamB>
gsnedders: rollover

[21:52:50.0000] <JonathanNeal>
I see that I can’t load SVGs from different domains. Is there any way to get them to load? Like updating the host’s origin policy?

[22:10:26.0000] <SamB>
JonathanNeal: how are you trying to use them?

[22:10:33.0000] <SamB>
I think you can use them for <img> just fine

[22:10:53.0000] <JonathanNeal>
<svg><use xlink:href=""/></svg>

[22:14:42.0000] <SamB>
ah, yeah, that would leak info

[22:44:01.0000] <JonathanNeal>
SamB: is there something like Access-Control-Allow-Origin I can set to allow it?

[22:51:09.0000] <TabAtkins>
JonathanNeal: No, but theoretically it would be find to allow that.

[22:51:25.0000] <TabAtkins>
JonathanNeal: But can you use just <image>?

[22:51:32.0000] <TabAtkins>
Or do you really need the behavior of <use>?

[23:12:26.0000] <JonathanNeal>
TabAtkins: I have an SVG with many <symbol> elements. I use it as a spritemap. I am hosting the spritemap on another domain.

[23:14:31.0000] <JonathanNeal>
My use case is that our university hosts our branding on one domain. Among the assets are stylesheets and images, some of which I have updated to use SVG instead of PNG and glyphfont.

[23:38:42.0000] <JonathanNeal>
TabAtkins: These sprites’ fills are colorized by the current color, so I’m not sure I can use <image>.

[23:40:33.0000] <caitp>
don't you just yearn for the good old days of 1x1 pixel transparent gifs and recycled jpegs full of artifacts

[06:05:33.0000] <GPHemsley>
If a line is made up spans with various (proportional) font-size values, is it conforming for the text to overlap across lines?

[06:07:14.0000] <GPHemsley>
https://imgur.com/RBsyMR1

[06:16:59.0000] <SimonSapin>
GPHemsley: I believe not

[06:27:43.0000] <SimonSapin>
GPHemsley: with `position: static` and `transform: none`, the line box should be high enough to include everything, and line boxes should not overlap each other

[06:30:44.0000] <GPHemsley>
ah, hmm, it seems there is a line-height of 25px in the cascade

[06:31:27.0000] <GPHemsley>
data:text/html,<div style="width: 25em; line-height: 25px"><span style="font-size: 1.5em;">act</span> <span style="font-size: 1.5em;">action</span> <span style="font-size: 1.5em;">american</span> <span style="font-size: 1.1em;">bill</span> <span style="font-size: 0.9em;">congress</span> <span style="font-size: 0.9em;">continue</span> <span style="font-size: 1.8em;">dream</span> <span style="font-size: 0.9em;">forwardlooking</span> <

[06:31:28.0000] <GPHemsley>
span style="font-size: 1.5em;">government</span> <span style="font-size: 1.1em;">john</span> <span style="font-size: 0.9em;">kennedy</span> <span style="font-size: 0.9em;">long</span> <span style="font-size: 1.1em;">meet</span> <span style="font-size: 0.7em;">moment</span> <span style="font-size: 1.1em;">must</span> <span style="font-size: 1.5em;">nation</span> <span style="font-size: 1.3em;">national</span> <span style="font-size:

[06:31:28.0000] <GPHemsley>
1.3em;">need</span> <span style="font-size: 1.3em;">now</span> <span style="font-size: 4em;">our</span> <span style="font-size: 1.3em;">peace</span> <span style="font-size: 0.9em;">program</span> <span style="font-size: 0.9em;">rights</span> <span style="font-size: 1.1em;">seek</span> <span style="font-size: 1.5em;">strength</span> <span style="font-size: 1.5em;">strong</span> <span style="font-size: 1.5em;">time</span> <span style=

[06:31:33.0000] <GPHemsley>
"font-size: 1.3em;">united</span> <span style="font-size: 4em;">will</span> <span style="font-size: 0.7em;">years</span>

[06:31:39.0000] <GPHemsley>
ah, hm

[07:52:05.0000] <matijs>
Is there a machine readable value for x that we can use in a <time datetime=x>present</time> to represent the present/now/today?

[14:47:03.0000] <JonathanNeal>
GPHemsley: that’s some nice HTML you got there.

[15:05:15.0000] <JonathanNeal>
TabAtkins: When you say “that model is crazytown” is that referring to <use xlink:href>? Do you think the future of using SVGs is strictly <img> or something else?

[16:06:46.0000] <caitp>
as sad as it is, xml doesn't work very well in HTML or the DOM, so SVG has some issues --- they aren't necessarily related to the issue you're talking about WRT cross-domain <use> tags, but there are a number of hard problems to solve, and it could be that SVG's future in html is just as broken as html has been, historically, if not moreso

[16:07:40.0000] <caitp>
no need to get into the specifics about the various broken things, but if you've looked at it, you've probably noticed some of the issues

[16:09:36.0000] <caitp>
of course that doesn't mean that the future of SVG won't be successful, it's a common theme around here about broken things being highly successful

[16:11:17.0000] <SamB>
caitp: :-(

[16:14:40.0000] <caitp>
well I'm not saying I'm right, it could be a pessimistic view =)

[16:15:20.0000] <caitp>
but the way it looks to me, it's a bit like trying to fit a square peg into a round hole, it doesn't quite squeeze in

[16:17:39.0000] <SamB>
well, I mean, I don't really expect SVG embedded in the HTML syntax to work the best ...

[16:17:52.0000] <caitp>
the network requirements may not line up with those of the web platform, xml complicates things for CSS resulting in weird and unfortunate hacks, which are still not actually working in some mainstream browsers, and are certainly not working with DOM apis using query selectors, beyond selectors, the createElementNS thing is really just a hack to support xml, there are all these corners that don't quite fit

[16:18:09.0000] <caitp>
the CSS issue particularly being @namespaces

[16:19:00.0000] <caitp>
yeah it's not really limited to SVG, most of that stuff is just XML not really fitting well into HTML to begin with

[16:19:01.0000] <SamB>
where you really need something more like what RNG has, eh?

[16:19:29.0000] <SamB>
and CSS not really being this generic thing it's presented as

[16:19:50.0000] <SamB>
I guess it works about as well as DTDs though ...

[16:44:34.0000] <TabAtkins>
JonathanNeal: I'm referring to cross-document <use>.

[16:44:58.0000] <TabAtkins>
Though now that the instance tree is gone, it might be slightly saner.

[16:45:56.0000] <TabAtkins>
caitp: Namespaces don't really cause problems for CSS unless you're missing vocabs with the same element names.

[16:46:33.0000] <caitp>
it's not necessarily a problem implementing them, but lets face it, it's a hack

[16:47:12.0000] <TabAtkins>
And even then it's not a "problem" so much as an inconvenience.

[16:47:41.0000] <caitp>
inconveniences are problems =) but I concede that css is the smallest problem

[16:48:03.0000] <caitp>
although DOM selector APIs having to deal with case-sensitive names is kind of sucky

[16:48:12.0000] <caitp>
because that is just totally different from HTML

[16:48:21.0000] <caitp>
which is what this stuff was built for

[16:49:30.0000] <caitp>
there are all kinds of problems with it, and I'm not saying that as an attack on XML, because XML is great. but the pieces never really fit together very well

[16:49:35.0000] <caitp>
from my perspective


2014-06-22
[17:23:49.0000] <MikeSmith>
caitp: yeah in contrast the pieces of the Web platform all fit together super elegantly well

[17:24:13.0000] <caitp>
the sarcasm is appreciated

[17:24:43.0000] <SamB>
caitp: well that's good, because otherwise you'd have totally misunderstood him

[17:26:57.0000] <caitp>
my argument that shoving XML into HTML doesn't really fit doesn't necessarily mean that everything else fits together well, but it doesn't necessarily help the situation

[17:27:56.0000] <caitp>
it will be interesting to see how that plays out, and if it can be made to sort of work

[17:39:52.0000] <JonathanNeal>
If I want to use SVG over webfont and use it across domains then I'm going to need to hack.

[17:44:42.0000] <JonathanNeal>
Which probably means an XHR request and access headers, if I can even do that with an SVG. I can imagine it now, JSVN (Jay-Sven, JavaScript Vector Notation) and JSVNP.

[17:57:39.0000] <MikeSmith>
JonathanNeal: btw what's the level of support for img@crossorigin is browsers?

[17:57:50.0000] <MikeSmith>
caniuse tells me nothing

[17:58:36.0000] <JonathanNeal>
MikeSmith: I don't know, and I will be testing as soon as I can get on the laptop.

[18:00:19.0000] <MikeSmith>
JonathanNeal: https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image indicates it's been supported in Chrome and Firefox for a long time

[18:01:07.0000] <MikeSmith>
there are some things that Alexis doesn't add to to caniuse even when they already have browser support. I don't understand why

[18:01:56.0000] <caitp>
maybe nobody has tried to add it yet?

[18:02:04.0000] <caitp>
they take patches

[18:02:54.0000] <caitp>
i don't see any issues about CORS wrt images

[18:05:42.0000] <JonathanNeal>
Well, SVG is a special kind of image, in that it's a kind of readable.

[18:06:09.0000] <MikeSmith>
writing a canisuse patch requires me to first have tests, or write the tests myself

[18:06:25.0000] <MikeSmith>
which I suspect is why Alexis hasn't added it

[18:07:47.0000] <MikeSmith>
he doesn't add stuff without tests

[18:10:02.0000] <SamB>
I assume the point of using CORS with an img is to keep it untainted?

[18:26:53.0000] <JonathanNeal>
It looks like even with CORS, IE9-11 is out of the picture.

[21:15:25.0000] <zcorpan>
Hixie: will the broken ndash and dots fix themselves in your new pipeline? See first example in introduction

[02:28:53.0000] <musically_ut>
I have a question about the CORS specification which probably has been discussed on some mailing list. Where should I post the question or search for answers?

[02:45:55.0000] <MikeSmith>
musically_ut: whatwg⊙wo or public-webappsec⊙wo

[02:46:24.0000] <musically_ut>
MikeSmith, Thanks. Is there a web-frontend to search those mailing lists?

[02:46:28.0000] <MikeSmith>
musically_ut: or ping annevk here when he's around (he wrote the spec)

[02:46:45.0000] <MikeSmith>
musically_ut: yeah lists.w3.org

[02:46:58.0000] <musically_ut>
I could write him an e-mail but I'd rather do some research myself first. :)

[02:47:01.0000] <musically_ut>
Perfect.

[02:47:28.0000] <MikeSmith>
the whatwg list archives are at http://lists.w3.org/Archives/Public/public-whatwg-archive/

[02:48:03.0000] <MikeSmith>
musically_ut: note that Anne has folded CORS into the Fetch spec

[02:48:16.0000] <musically_ut>
Huh .. April 2004 was the 10 year anniversary of whatwg. I never made the connection.

[02:48:20.0000] <musically_ut>
* April 2014

[02:48:24.0000] <MikeSmith>
so the standalone CORS spec is obsolete

[02:48:54.0000] <MikeSmith>
no this month was the anniversary of the whatwg actually

[02:49:03.0000] <musically_ut>
:)

[02:49:31.0000] <musically_ut>
http://www.w3.org/TR/cors/ doesn't seem to suggest that the spec has become obsolete.

[02:50:15.0000] <MikeSmith>
April was the 10 year anniversary of the HTML spec (aka WebApps 1.0 aka HTML5) https://github.com/whatwg/web-history#2004-04

[02:50:28.0000] <MikeSmith>
musically_ut: never use anything in http://www.w3.org/TR/

[02:50:40.0000] <musically_ut>
/me raises eyebrows.

[02:50:47.0000] <MikeSmith>
seriously

[02:51:45.0000] <MikeSmith>
always use either the Editor's Draft version that corresponds to whatever's in http://www.w3.org/TR or find out whatever has replaced it

[02:52:13.0000] <musically_ut>
What does "TR" in the URL stand for?

[02:52:16.0000] <MikeSmith>
the documents in http://www.w3.org/TR can pretty much always be considered out of date

[02:52:21.0000] <MikeSmith>
Technical Report

[02:52:26.0000] <musically_ut>
Ah.

[02:53:21.0000] <MikeSmith>
anyway as far as CORS, I think the WebAppSec WG is still maintaining a separate spec but the browser implementors are implementing from Fetch now

[02:53:24.0000] <MikeSmith>
or should be

[02:53:36.0000] <musically_ut>
This is rather confusing. http://www.w3.org/TR/  lists neither Fetch nor CORS TR.

[02:53:55.0000] <musically_ut>
But I did not know about the cumulative Fetch specs.

[02:54:10.0000] <musically_ut>
I have found them here: http://fetch.spec.whatwg.org/#http-cors-protocol

[02:54:11.0000] <MikeSmith>
yeah sorry for the confusion but it's not unique to this case

[02:54:29.0000] <MikeSmith>
musically_ut: yeah http://fetch.spec.whatwg.org is what you want to be reading

[02:54:56.0000] <musically_ut>
Excellent.

[02:57:13.0000] <musically_ut>
Okay, I'll search the archives a bit to see if I can find an answer. Otherwise, you'll hear from me on the mailing list. :)

[02:57:14.0000] <MikeSmith>
btw we're trying to do some things to deal with the http://www.w3.org/TR confusion problem but it's taking some time because there's a lot of politics and inertia that get in the way

[02:57:25.0000] <MikeSmith>
musically_ut: sounds great. cheers

[02:57:36.0000] <musically_ut>
What is the plan with www.w3.org/TR then?

[02:58:10.0000] <Ms2ger>
Ignore it

[02:58:23.0000] <MikeSmith>
the plan is to make it always provide up-to-date info about what the latest version of every spec is

[02:58:41.0000] <musically_ut>
up-to-date == github master branch?

[03:00:09.0000] <MikeSmith>
but in the mean time you can ignore TR or least any time you look at a doc in http://www.w3.org/TR you should check the top of it to see if it lists a "Latest Editor's Draft" link

[03:00:17.0000] <MikeSmith>
and if it does, use the document at that link

[03:00:38.0000] <Ms2ger>
And if it doesn't, still try to find one :)

[03:00:39.0000] <MikeSmith>
and if it doesn't then be very suspicious

[03:00:41.0000] <MikeSmith>
yeah

[03:00:48.0000] <musically_ut>
:)

[03:01:15.0000] <musically_ut>
So if it doesn't have an editor draft then it has very likely been made obsolete?

[03:01:22.0000] <MikeSmith>
well

[03:01:34.0000] <MikeSmith>
yeah, basically

[03:01:51.0000] <MikeSmith>
either that or it's not relevant at all to begin with

[03:02:22.0000] <musically_ut>
Great. Thanks for the tips, MikeSmith and Ms2ger

[03:02:27.0000] <MikeSmith>
there are many documents at http://www.w3.org/TR that have absolutely nothing to do with the Web platform so you don't need to care about them at all

[03:03:26.0000] <MikeSmith>
musically_ut: http://platform.html5.org is a much better index of what's relevant

[03:04:59.0000] <MikeSmith>
Ms2ger: do you know if all floating-point numbers are allowed in CSS length values?

[03:05:16.0000] <Ms2ger>
I don't

[03:07:15.0000] <musically_ut>
Ah, nice.

[03:10:20.0000] <MikeSmith>
well I find http://dev.w3.org/csswg/css-values/#number-value which says "A number is either an <integer> or zero or more decimal digits followed by a dot (.) followed by one or more decimal digits." but then it also says "It corresponds to the <number-token> production in the CSS Syntax Module." and TabAtkins railroad diagram at http://dev.w3.org/csswg/css-syntax-3/#number-token-diagram suggests it can be any floating-point number, not just "either an 

[03:38:49.0000] <MikeSmith>
TabAtkins: I'm trying to figure out if, e.g., 100e+0vw is a valid length value or not

[03:39:30.0000] <MikeSmith>
TabAtkins: because I'm trying to write an error-reporting @sizes parse for the validator

[03:39:44.0000] <MikeSmith>
*parser

[07:38:50.0000] <TabAtkins>
MikeSmith: Trust the specified parser.

[07:38:58.0000] <TabAtkins>
100e+0vw is valid.

[07:39:09.0000] <TabAtkins>
I need to update V&U to take the scinot change into account.

[07:48:23.0000] <TabAtkins>
MikeSmith: Fixed now.

[12:17:46.0000] <MikeSmith>
TabAtkins: Coolーthanks!

[12:22:26.0000] <TabAtkins>
MikeSmith: To write a good sizes parser, you'll want to write a full css parser, which is trivial to do by following the Syntax spec.

[12:22:54.0000] <TabAtkins>
And is much smaller than an html parser. ^_^

[12:38:58.0000] <MikeSmith>
TabAtkins: for the validator I need the parser to be error-reporting, which I think can make the implemented algorithm need to be somewhat different from the spec

[12:39:57.0000] <MikeSmith>
at the very least it means I basically need to infer some parse errors based on the corresponding authoring requirements

[12:40:59.0000] <MikeSmith>
e.g., at http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html#parse-a-sizes-attribute where it says "Remove all consecutive <whitespace-token>s from the end of unparsed size. If unparsed size is now empty, continue to the next iteration of this algorithm.", I need to emit an error for the "If unparsed size is now empty" condition


2014-06-23
[18:25:56.0000] <MikeSmith>
TabAtkins: so I need to come up with a one-sentence prose description of "valid source size list" to add to http://wiki.whatwg.org/wiki/MicrosyntaxDescriptions

[18:26:13.0000] <MikeSmith>
TabAtkins: how about "A comma-separated list of size expressions, with each size expression consisting of a CSS length optionally preceded by a CSS media condition."?

[18:54:10.0000] <MikeSmith>
Hixie: Clicking on the [FOO] text in the References section (in the single page spec) should ideally show me that <dfn> popup thing, listing all the places in the spec which reference [FOO]

[18:54:54.0000] <MikeSmith>
Hixie: I thought you had it doing that behavior before and it's regressed, but maybe I just imagined that it did it before but it never actually had

[18:56:33.0000] <MikeSmith>
Hixie: anyway it seems like with your current toolchain if you just wrapped the [FOO] text there is a <dfn> it would automatically give the behavior I want

[18:57:21.0000] <MikeSmith>
Hixie: and further anyway, please consider this a request to make your new toolchain do it at least

[19:35:03.0000] <Hixie>
MikeSmith: nted

[19:35:06.0000] <Hixie>
noted, even

[19:35:16.0000] <MikeSmith>
thanks

[19:35:27.0000] <MikeSmith>
raised a bug for it

[19:35:36.0000] <Hixie>
oh, excellent, thanks

[19:39:51.0000] <MikeSmith>
TabAtkins: I guess there's a reason why source-size lists can only contain <media-condition>s but not <media-query>s?

[19:42:06.0000] <TabAtkins>
<media-query> is stupid and legacy, that's why.

[19:43:22.0000] <TabAtkins>
Regarding a prose description, I might emphasize that there are pairs of conditions/sizes, and a final bare size.

[19:44:37.0000] <TabAtkins>
MikeSmith: How useful is that ref thing? I was thinking of adding it to Bikeshed.

[19:45:44.0000] <MikeSmith>
TabAtkins: for the HTML spec at least I find it extremely useful myself

[19:46:00.0000] <MikeSmith>
necessary even

[19:46:18.0000] <MikeSmith>
for smaller specs it might be less useful

[19:47:49.0000] <TabAtkins>
Interesting would be to ref cross-spec too.

[19:48:09.0000] <TabAtkins>
Would mean a larger database from Shepherd, but definitely possible.

[19:48:17.0000] <MikeSmith>
oooh yeah

[19:48:24.0000] <MikeSmith>
that would be very nice to have

[19:49:17.0000] <Hixie>
oh like a <dfn> pointing to where it's used in other specs?

[19:49:24.0000] <Hixie>
that'd be interesting

[19:49:29.0000] <MikeSmith>
yeah

[19:52:23.0000] <MikeSmith>
TabAtkins: hmm yeah about the prose description, from what you said and looking back at the grammar, I realize it's not pairs of "a CSS length optionally  preceded by a CSS media condition.

[19:52:32.0000] <TabAtkins>
Hixie: Please make HTML Bikeshed friendly for its dfns, and I will produce wonders.

[19:52:46.0000] <Hixie>
file a bug letting me know what you need

[19:52:59.0000] <TabAtkins>
Kk

[19:53:08.0000] <Hixie>
i'm hoping to make my pipeline eventually just fetch the remote specs and figure it all out dynamically

[19:53:25.0000] <TabAtkins>
(It's a whole bunch of data-dfn-type attributes.)

[19:53:54.0000] <TabAtkins>
Yeah, you should be able to use Shepherd's data too. It's great.

[20:04:42.0000] <MikeSmith>
TabAtkins: OK so for the prose how about "A list of one or more condition-size pairs, each consisting of a required CSS media condition plus a required size (CSS length), then optionally with a single final (condition-less) size (CSS length) following the list of all condition-length pairs."?

[20:04:52.0000] <MikeSmith>
prose is hard

[20:05:14.0000] <TabAtkins>
Sounds reasonable

[20:05:27.0000] <MikeSmith>
cool, thanks

[20:06:00.0000] <TabAtkins>
Hixie: Let me know when you're interested, I can help you interface with Shepherd for linking data.

[20:15:53.0000] <MikeSmith>
TabAtkins: for <picture> is there a use case for specifying both media= and sizes= for the same <source> element?

[20:17:07.0000] <TabAtkins>
Yeah, for sure. Use sizes whenever the image is variable sized.

[20:17:24.0000] <TabAtkins>
That can definitely happen within media breakpoints.

[20:18:26.0000] <MikeSmith>
ok

[20:19:37.0000] <SamB>
TabAtkins: does he like keep it in a cyborg implant or something?

[20:19:42.0000] <SamB>
the linking data

[20:20:42.0000] <TabAtkins>
Shepherd is the name of the program. ^_^

[20:21:05.0000] <TabAtkins>
plinss is the maintainer of the project.

[20:23:59.0000] <MikeSmith>
TabAtkins: so sizes='all 500px, 100vw' is disallowed, right? (because it has a media query, not a media condition)

[20:24:47.0000] <SamB>
TabAtkins: so how come the program is the one with a human-looking name!

[20:25:53.0000] <TabAtkins>
MikeSmith: Yes

[20:26:05.0000] <TabAtkins>
SamB: Shepherd is a title, not a name!

[20:26:24.0000] <SamB>
TabAtkins: some people seem to have it as a name anyway

[20:28:37.0000] <MikeSmith>
TabAtkins: so (sorry if I'm being daft) but why is "all 500px" disallowed? There's no use case for an author to use it? (Or to use some similar media query in sizes with whatever other media type)

[20:29:35.0000] <TabAtkins>
Media queries are obsolete.

[20:30:04.0000] <TabAtkins>
That is, the actual mq part.

[20:31:01.0000] <TabAtkins>
They're mostly deprecated in the spec. Only a handful of remaining ones are allowed to evaluate to anything.

[20:32:26.0000] <MikeSmith>
TabAtkins: ok, thanks

[21:19:06.0000] <MikeSmith>
TabAtkins: incidentally do you think it would be useful for the markup validator to emit a warning for use of media-type mqs in HTML markup -- e.g., source@media and link@media?

[21:19:57.0000] <MikeSmith>
TabAtkins: with the warning saying or paraphrasing the "It is expected that all of the media types will also be deprecated in time, as appropriate media features are defined which capture their important differences." statement from the MQ spec

[21:21:56.0000] <SamB>
so, what's the new way to handle style for printing?

[21:24:08.0000] <MikeSmith>
SamB: maybe "update-frequency:none, pointer:none, hover:none, overflow-block: paged, overflow-inline: none"

[21:24:30.0000] <MikeSmith>
per http://dev.w3.org/csswg/mediaqueries-4/#issue-ef9781e9

[21:25:51.0000] <SamB>
/me wonders how pointer:none helps with that ...

[21:30:13.0000] <MikeSmith>
SamB: I see now my response wasn't an answer to the question you actually asked but instead an answer to the question, "What's the new way to do a media query for print?"

[21:32:48.0000] <MikeSmith>
or more specifically a media query for printer device, as opposed to say, an eink device, as opposed to a desktop computer

[21:33:28.0000] <SamB>
ah, I guess I see the point there ...

[21:34:12.0000] <MikeSmith>
yeah the actual CSS rules of your "print" stylesheet you'd just keep the same as now, I think

[21:34:16.0000] <SamB>
hmm, actually, wait, none of that indicates the need for a different color scheme

[21:35:04.0000] <MikeSmith>
well it's just an editor's note-to-self FIXME in the spec at this point, I think

[21:35:36.0000] <MikeSmith>
but it gives the general idea

[21:36:36.0000] <MikeSmith>
that idea being, you do finer-grained feature detection instead of simple-minded coarse media-type detection

[21:38:31.0000] <SamB>
which is why I thought of the lack of a hint for the different color needs presented by paper (like "don't wrinkle it to hell by putting ink everywhere for no reason")

[22:16:29.0000] <zcorpan>
MikeSmith: it should be zero or more ... Optionally followed by the default size. But at least one of them

[22:46:59.0000] <TabAtkins>
SamB: As noted, the answer is "figure out what things you actually depend on", and use MQs for those.

[22:47:49.0000] <SamB>
yeah

[00:13:50.0000] <mathiasbynens>
https://news.ycombinator.com/item?id=7928968 makes it seem like the URL Standard needs some evangelism

[00:15:52.0000] <MikeSmith>
https://twitter.com/shadow_hayato/status/480931013871165442 :-)

[00:15:57.0000] <MikeSmith>
hayato++

[00:16:24.0000] <MikeSmith>
mathiasbynens: oh god

[00:18:00.0000] <MikeSmith>
"The relevant specs are..." [list of the wrong specs instead of the right one]

[00:18:38.0000] <mathiasbynens>
yep… and there are several comments like that

[00:19:04.0000] <mathiasbynens>
i replied, but it seems like More People™ need to know about the URL Standard

[00:23:04.0000] <MikeSmith>
mathiasbynens: your plan sounds logical but would result in much less entertainment value like what's provided in these comments

[00:40:34.0000] <Ms2ger>
mathiasbynens, that's not a real standard! It's not written for 80s printers!

[02:32:38.0000] <odinho>
http://blogs.opera.com/desktop/2014/06/opera-24-linux-released-developer-stream/ < opera developer 24 linux ♥  :)

[02:53:31.0000] <jgraham>
Better late than never I guess

[02:53:45.0000] <jgraham>
Although I was guessing "never" so apparently my guesses aren't worth much

[02:53:57.0000] <wilhelm>
I lost a bet.

[03:21:29.0000] <annevk>
mathiasbynens: talk about it at a conference?

[03:21:52.0000] <annevk>
mathiasbynens: could use some help with test suite and browser evangalism too

[03:22:07.0000] <annevk>
mathiasbynens: Gecko folks seem to be warming up to the idea of cleaning up URL code, but it's going to take a while

[03:23:43.0000] <annevk>
Domenic: when will streams.spec.whatwg.org be up?

[07:20:17.0000] <Domenic>
annevk_: good question. I have no idea how to get subdomains set up. Halp?

[07:20:50.0000] <annevk>
Domenic: Hixie can get you an account and ssh access

[07:21:06.0000] <annevk>
Domenic: unless you want me to handle a basic syncing thing that the other specs use too

[07:21:45.0000] <annevk>
Domenic: most *.spec.whatwg.org domains just have a webhook which is a simple script that gets files from GH

[07:22:07.0000] <Domenic>
annevk: hmm unsure. maybe i could see your scripts or whatevs, then figure out how to get them integrated into the CI?

[07:22:20.0000] <Domenic>
Right now I have https://github.com/whatwg/streams/blob/master/deploy-gh-pages.sh

[07:23:14.0000] <annevk>
#!/bin/sh

[07:23:14.0000] <annevk>
echo "Content-type: text/plain"

[07:23:14.0000] <annevk>
echo ""

[07:23:16.0000] <annevk>
curl -L https://raw.github.com/whatwg/dom/master/dom-core.html > dom-core.html

[07:23:18.0000] <annevk>
echo "teehee"

[07:23:31.0000] <Domenic>
heh fair

[07:23:46.0000] <Domenic>
I am aiming for a "v0.9" end of this week, so yeah getting the correct URL might be good.

[07:24:05.0000] <annevk>
So if you want to handle it yourself, just ask Hixie

[08:36:55.0000] <Domenic>
annevk: what does asBlob add that asArrayBuffer does not?

[11:30:25.0000] <annevk>
Domenic: MIME

[11:31:10.0000] <annevk>
Domenic: and being cloneable without memory impact

[11:31:54.0000] <Domenic>
annevk: aren't ArrayBuffers transferable?

[11:47:00.0000] <annevk>
Domenic: that makes them unreadable from the point of transfer

[11:47:23.0000] <annevk>
(which is why I said cloneable, not transferable)

[11:58:52.0000] <Domenic>
mmm, right, so they're the missing immutable array buffers

[13:13:32.0000] <Domenic>
WebIDL needs to be moved to Rec. That is exactly what it needs.

[13:24:35.0000] <Hixie>
yeah, nothing would help webidl more than to be moved to rec...

[13:41:12.0000] <jamesr_>
looks like target is a hook to avoid recursion

[13:41:19.0000] <annevk>
jamesr_: seems somewhat weird to me to invoke that

[13:41:32.0000] <jamesr_>
hmmm

[13:41:48.0000] <annevk>
jamesr_: what actually happens is that the ECMAScript engine terminates (engine started for that callback)

[13:42:15.0000] <annevk>
jamesr_: so something should just wrap the engine terminating and you should just cause it to terminate by rethrowing an exception

[13:42:32.0000] <annevk>
anyway, bedtime

[13:42:58.0000] <jamesr_>
and poor polyfill guy is boned

[13:43:00.0000] <jamesr_>
g'night

[13:43:14.0000] <JonathanNeal>
ouch

[14:08:05.0000] <JonathanNeal>
Any folks here using SVGs? I have some questions about using them in <use xlink:href> vs <img src>.

[14:09:59.0000] <JonathanNeal>
Namely, I have used <use xlink:href> because it allows me to style properties of the svg per instance per page. The downside is, IE does not support external sources and no browsers supports cross domain sources.

[14:28:02.0000] <TabAtkins>
JonathanNeal: And?

[14:28:36.0000] <JonathanNeal>
Well, since <img> doesn’t do the aforementioned things, I was wondering what techniques people have chosen and how they have worked around the drawbacks.

[14:29:18.0000] <SamB>
JonathanNeal: did you check if .svg can do those things?

[14:30:11.0000] <TabAtkins>
JonathanNeal: Ah, so you've got a collection of SVG images, and you're trying to use an inline <svg><use/></svg> in the page to try and produce colors to it via inheritance?

[14:30:42.0000] <SamB>
if that doesn't work, maybe you can, uh, use xinclude to *generate* the different-colored SVGs?

[14:32:05.0000] <SamB>
JonathanNeal: anyway, presumably using same-domain .svg files to set the different colors would at least help for the other browsers?

[14:32:18.0000] <JonathanNeal>
TabAtkins: yes, sometimes I am using svgs like folks use font icons. I wondered if someone had come from the other approach of replacing PNGs and using <img src="path/to/image.svg"> and I thought we could talk about how and why we used either. I just wanted to learn, and evaluate which method is best in certain circumstances.

[14:34:19.0000] <TabAtkins>
JonathanNeal: Okay, now I understand what you're doing.

[14:35:00.0000] <TabAtkins>
What you want is SVG Parameters, which are a way to set custom properties on an external SVG document via query params.

[14:35:12.0000] <TabAtkins>
Which... doesn't exist yet.

[14:35:15.0000] <SamB>
So, exactly to what extent does the SVG spec not support CORS?  I mean, are there just some little changes needed, or are they somehow opposed to it?  Is there some political problem preventing them from referring to the relevant algorithms?

[14:35:18.0000] <TabAtkins>
But when it does, you'll have what you want.

[14:35:23.0000] <SamB>
TabAtkins: so helpful ...

[14:35:52.0000] <TabAtkins>
SamB: Nah, just a matter of putting in the work.  krit was working with annevk recently about it.

[14:36:19.0000] <SamB>
I guess it's not as trivial as I would have expected then

[14:39:49.0000] <moorsiek>
hey, guys!

[14:42:28.0000] <moorsiek>
Anybody knows the origins of the 16px font-size in browsers? I've dug many-many sites, specs, etc., but couldnt find when (or why) 16px became some sort of defacto standard. =|

[14:43:26.0000] <JonathanNeal>
moorsiek: I researched this once.

[14:43:38.0000] <JonathanNeal>
First, it’s because 16px is 12pt.

[14:48:07.0000] <TabAtkins>
Yup, 16px=12pt, the default in word processors and such.

[14:48:11.0000] <TabAtkins>
It's just a pretty standard size.

[14:54:37.0000] <moorsiek>
Okay, I see. Thank you, guys! So it appears that the www has inherited this size from the other field :)

[15:03:12.0000] <JonathanNeal>
moorsiek: we have inherited a lot from previous fields.

[15:03:24.0000] <JonathanNeal>
Keyboard layouts, font sizes, the 80 character thing, etc.

[15:14:45.0000] <JonathanNeal>
paul_irish: do you remember when we researched the 12pt thing? Didn’t you compile the history somewhere?

[15:14:56.0000] <JonathanNeal>
the 12pt being the default in browsers thing

[15:44:09.0000] <JonathanNeal>
moorsiek: In 1785, Francois Didot was refining typography standards. This was before TabAtkins and linear gradient. Back then, a lot of measurements were written non-numerically. Imagine if we wrote measurements like we write color: blue. e.g. font-size: parisienne. So, Francois “normalized” the standard size of type to be 1/72 of a French inch and he

[15:44:09.0000] <JonathanNeal>
called that a pica, which he divided into 12 points. Dividing by 12 was the natural thing to do back then.

[15:47:31.0000] <Hixie>
other way round (point = 1/72", pica = 1/12pt)

[15:48:11.0000] <Hixie>
no wait

[15:48:33.0000] <Hixie>
what you said was right except s/inch/foot/

[15:49:56.0000] <JonathanNeal>
Yes, thanks. And really, Didot was reworking something he had seen from Truchet years earlier, much like we still do today.

[15:50:52.0000] <Hixie>
yeah. also all these numbers got renormalised a few times over the years

[15:51:59.0000] <JonathanNeal>
Yes, and eventually Adobe and Mac implemented the same standard that had been suggested something like twenty years prior.

[15:52:08.0000] <JonathanNeal>
Much like Firefox and IE.

[15:53:31.0000] <JonathanNeal>
And then we ruined line returns i mean carriage returns i mean, anyway, and then we had a standard. And that’s where standards come from. WHATWG is the best standard. The last standard, surely, for the rest of the history of mankind.

[15:59:06.0000] <JonathanNeal>
My favorite is the 80 character rule. It goes back to an 80 character limit on a screen, which goes back to 80 column standard on a punch card designed in 1928.

[16:01:26.0000] <caitp>
#927

[16:11:39.0000] <JonathanNeal>
Hixie: here’s one I don’t know. Why do we use angled brackets for HTML?

[16:11:59.0000] <Hixie>
cos sgml used angle brackets and tim thought it looked cool, or something

[16:12:51.0000] <zewt>
my least favorite is people who try to tell me to mangle my python code so it doesn't wrap on an 80 column screen

[16:12:56.0000] <zewt>
re: no.

[16:13:32.0000] <Hixie>
80's a bit narrow, but it's good to pick a fixed width so all the developers on a project know what size to make their edit windows

[16:14:18.0000] <zewt>
having a rough guideline, but having a couple lines wrapping is harmless in any reasonable programmer's editor

[16:14:37.0000] <Hixie>
there's nothing reasonable to do with wrapping lines

[16:14:39.0000] <zewt>
and my rough guideline is closer to 120

[16:15:03.0000] <zewt>
doesn't give me any trouble

[16:15:06.0000] <Hixie>
120's probably ok if nobody on your project likes to have lots of narrow edit windows next to each other

[16:15:34.0000] <zewt>
not mangling my code for people who do that

[16:15:56.0000] <Hixie>
that's fine if your project doesn't have such people

[16:16:12.0000] <a-ja>
but the lines always wrap on my TTY

[16:16:33.0000] <zewt>
my favorite is pep-8, which has a bunch of "how to wrap code to fit in 78 or whatever columns", and those examples are so hideous they make a joke of pep-8

[16:16:57.0000] <Philip`>
80 characters wide with 8-space tabs (e.g. the Linux kernel) is great - some people take the hint to avoid deep nesting and pull things out into helper functions, while other people decide to indent heavily and then split their code into a single symbol per line so it trickles down the right of the screen in a nice random pattern

[16:17:04.0000] <zewt>
such people can deal with it, because such people can't expect the whole world to bend their code for them

[16:17:45.0000] <Hixie>
zewt: not the whole world, just the people on their project.

[16:18:11.0000] <zewt>
i stick to 4-space tabs now, mostly because it's the most common and an easy sell to programmers--when it comes to indentation, consistency is more important than anything

[16:18:57.0000] <zewt>
some people dislike 8 as too wide; I consider 2 completely unreadable

[16:19:10.0000] <Hixie>
i assume you mean indents, not tabs

[16:19:14.0000] <zewt>
(and only gnu would use 3)

[16:19:17.0000] <Hixie>
using raw tabs is obviously crazy

[16:19:29.0000] <zewt>
yes, I always turn hard tabs off completely

[16:19:31.0000] <JonathanNeal>
Got it, so in 1974, Charles Goldfarb was looking to create a standard way to markup documents. His partners were Ed Mosher and Ray Lorie and they called it Generalized Markup Language because it matched their last initials.

[16:20:29.0000] <zewt>
since some editors conflate indentation and tab stops and some people can't understand the difference, or why hard tabs are always 8 spaces, and the easiest sell it just turn them off

[16:21:28.0000] <Hixie>
anyway the real reason to make sure you wrap to 80 chars is that that's the width of a punch card

[16:21:41.0000] <Hixie>
and if you overflow that, your punchcard processor is just gonna fail

[16:21:44.0000] <Hixie>
which is expensive

[16:21:48.0000] <Hixie>
and a waste

[16:21:53.0000] <zewt>
well, that's not why it's in pep-8 :P

[16:21:54.0000] <Hixie>
so, stick to 80 chars

[16:22:05.0000] <JonathanNeal>
Hixie is right.

[16:22:25.0000] <zewt>
which is the PEP I take least seriously, and which some people try to use as bible

[16:23:40.0000] <JonathanNeal>
I still haven’t learned why they choose angled brackets, but in the original GML of the 70’s tags were started with a colon and ended with a period, e.g. :h1.

[16:24:40.0000] <zewt>
maybe it's as simple as "tags starting with a colon and ending with a period is hideous"

[16:24:46.0000] <caitp>
at the end of the day, it doesn't really matter what they picked

[16:24:47.0000] <Hixie>
(and 72 characters is reasonable because the last 8 are typically used for sequence numbers so you can resort a deck if you drop it)

[16:27:04.0000] <JonathanNeal>
caitp: it doesn’t matter until someone wonders why all HTML isn’t slim-lang.

[16:28:07.0000] <JonathanNeal>
Or Coding Horror calls it a tax. http://blog.codinghorror.com/xml-the-angle-bracket-tax/ and pushes the industry further from XML-like protocols (and perhaps into JSON-like protocols)

[16:28:23.0000] <caitp>
even if html wound up looking like HAML or YAML or whatever else, people would still say it wasn't nice

[16:28:31.0000] <caitp>
because that's just what people do

[16:28:38.0000] <zewt>
json seriously needs to allow comments

[16:29:32.0000] <caitp>
the syntax/grammar of html is really one of the least offensive parts when you get down to it

[16:31:07.0000] <JonathanNeal>
I think I got it! In a 90’s book, some guy mentioned that writing out the code was part of the process, and it was a real pain, and certain decisions were made to help make physically writing the code easier.

[16:34:35.0000] <JonathanNeal>
Nevermind, I misunderstood it. Sorry, Steven J. DeRose.

[16:39:39.0000] <JonathanNeal>
Okay, so there were several standards. Because SGML had to allow for multiple delimiters, the spec was huge. Most folks found using <> was the most readable, thus “SGML elements were (nearly always) delimited with angle brackets.” http://www.snee.com/bobdc.blog/2012/01/a-brief-opinionated-history-of.html

[16:45:15.0000] <TabAtkins>
zewt: "hard tabs are always 8 spaces"?

[16:49:11.0000] <zewt>
the tab stop for ^I should always be 8 spaces, but people who confuse the hard tab stop with the code indentation size change it, resulting in WW3

[16:50:22.0000] <zewt>
and visual studio's criminally incompetent developers set tab stops to 4, which badly aggravates the problem

[16:50:52.0000] <SamB>
zewt: it might not be the devs' fault

[16:51:03.0000] <SamB>
that might be management's mandate ...

[16:51:48.0000] <SamB>
(though perhaps they don't have many VS hackers *left* who still run Emacs)

[16:51:52.0000] <zewt>
to users that's not really a distinction, but okay

[16:52:12.0000] <zewt>
call it the visual studio team if you want

[16:53:47.0000] <TabAtkins>
zewt: Oh, right, hard tabs are "insert multiple spaces".  Sorry, was confused.

[16:54:10.0000] <zewt>
hard tabs are insert tab control characters, soft tabs are insert spaces

[16:54:30.0000] <zewt>
(not sure if we're saying the same thing)

[16:54:44.0000] <TabAtkins>
Argh, dammit. I got it backwards again!

[16:55:05.0000] <TabAtkins>
Well, tab control characters are purposely resizable, but I think I've had this discussion with you before, and you wont' admit you're wrong. ^_^

[16:55:49.0000] <JonathanNeal>
That’s why I prefer tabs. You decide!

[16:56:21.0000] <zewt>
changing the tab stop size means you have text files that are only viewable consistently f you configure your environment to match the one they were authored in

[16:57:06.0000] <TabAtkins>
As we've discussed in the past, that only happens if people misuse tab characters for alignment, rather than solely indentation.

[16:57:09.0000] <zewt>
code with the "wrong" tab stop is invariably hilarious but useless

[16:57:37.0000] <SamB>
TabAtkins: Knuth says tabstops are 8 spaces apart

[16:57:42.0000] <SamB>
are you gonna argue with Knuth?

[16:57:58.0000] <zewt>
things I'm not going to spend mental bandwidth on while working (and worse, time trying to explain to coworkers): whether I'm inserting spaces or tabs

[16:58:27.0000] <SamB>
but yeah, it's not so much an issue if you very carefully follow these arcane rules to ensure that they're only used for alignment, and that tabs and spaces are never mixed ...

[16:58:27.0000] <JonathanNeal>
Tabs are intended to be variable and responsive. That’s why we have .editorConfig and other tools to standardize them across machines to your hearts content.

[16:58:54.0000] <JonathanNeal>
And I can just undo all your two-spaces and put in tabs, and let you configure tabs to look like two-spaces. We both win.

[16:58:57.0000] <SamB>
I thought tabs were a primitive mechanism for text compression for teletypes

[16:59:09.0000] <JonathanNeal>
Until you start using tabs for space alignment, and at that point, you’re doing it wrong.

[16:59:31.0000] <SamB>
I always consider it a "lose" when I have to configure a tab size in my editor to make something look sensible

[16:59:49.0000] <SamB>
this happens far more than I should like

[16:59:57.0000] <JonathanNeal>
http://editorconfig.org/ problem solved


2014-06-24
[17:00:32.0000] <zewt>
turn off hard tabs, use 4-space indents.  problem solved in the simplest way imaginable

[17:00:33.0000] <SamB>
therefore, some people are reconfiguring the size AND not aware of the associated arcane rules

[17:01:44.0000] <SamB>
(or using braindead stuff like VS that starts out with a non-standard value)

[17:02:15.0000] <zewt>
I sure don't want to spend time (expensive time, since it involves getting other people to do it too) just to allow fiddling with the indentation; 4 spaces is fine

[17:02:45.0000] <SamB>
zewt: yeah, I prefer that approach

[17:03:29.0000] <SamB>
I set my Emacs to avoid TAB by default

[17:04:27.0000] <zewt>
and since it's an easy sell, it leaves more in the "arguing about code style with coworkers" budget for things like "don't write comments in stream of consciousness"

[17:05:35.0000] <montecfel>
This is unbelievably annoying. When drawing a text with fillText on a canvas, the font will randomly blur even though you Math.round() the x and y coordinates. The string "This is a text." is blurry. If I change it into "This is a text.aaa", it becomes sharp. If I remove or add any chars, it becomes blurry again. Can somebody save my computer from meeting with my sledgehammer?

[17:06:08.0000] <montecfel>
The font size is not dynamic, but fixed at 16px.

[18:42:24.0000] <TabAtkins>
zewt: Arguing about tab width is a fun thing to burn code-style budget on. Real tabs avoid this.

[18:43:02.0000] <TabAtkins>
SamB: The "arcane rules" are "indent with tabs, align with spaces". Not exactly hard.

[18:44:12.0000] <SamB>
I guess it isn't too complicated for *C*

[18:44:14.0000] <TabAtkins>
When aligning a broken line, you indent to the same level, then align the remaining with spaces. Trivial.

[18:44:31.0000] <SamB>
TabAtkins: it's arcane compared to "don't use TABs"

[18:45:35.0000] <TabAtkins>
"Arcane in comparison" doesn't carry much weight when both are so simple. ^_^

[18:46:17.0000] <SamB>
well, a lot of people still manage to screw it up :-(

[18:46:19.0000] <TabAtkins>
A paperclip is heavy when compared to a feather, but that doesn't make it "heavy".

[18:47:07.0000] <TabAtkins>
Yeah, and those same people screw up space alignment too. I've never seen a space-indented file without an indentation mistake.

[18:48:03.0000] <caitp>
as long as it's "good enough", who cares

[18:48:18.0000] <SamB>
TabAtkins: I guess you haven't looked very hard ;-)

[18:48:53.0000] <TabAtkins>
Oh, I'm sure they exist, particularly when there are automated checks or strict style reviews.

[18:49:12.0000] <TabAtkins>
But I think they're rare.

[18:50:00.0000] <caitp>
if you abolish style rules, you don't even need git blame anymore, the blame is built into the file :D

[18:50:13.0000] <TabAtkins>
caitp: A file that randomly switches between 2 and 4 space indents isn't "good enough".

[18:50:25.0000] <SamB>
TabAtkins: oh, sure

[18:50:31.0000] <caitp>
i'm not being totally serious there tab, but I think there are a lot of things that you can let slide

[18:50:38.0000] <SamB>
but the indent width setting is totally different from the tab width settign

[18:50:38.0000] <caitp>
like aligning function parameters on a wrapped line

[18:50:42.0000] <TabAtkins>
And I've seen plenty of that, even for single-author files.

[18:50:48.0000] <othermaciej>
“never use tabs” is a much simpler rule to follow

[18:50:51.0000] <caitp>
stuff like that is pretty "who cares"

[18:51:03.0000] <caitp>
long as it's readable

[18:51:33.0000] <TabAtkins>
caitp: Yeah, I usually break lines by just indenting an extra level, rather than aligning anything. Even simpler.

[18:51:34.0000] <othermaciej>
consistency is important for code

[18:51:50.0000] <othermaciej>
irrelevant differences jump out at you, making it harder to notice the relevant differences

[18:51:50.0000] <TabAtkins>
Because then the rule is "always use tabs".

[18:52:00.0000] <caitp>
consistency is important

[18:52:09.0000] <caitp>
but it's not the -most important thing-

[18:52:22.0000] <SamB>
TabAtkins: that would work okay as long as it's fine if I leave tabs at the standard width

[18:52:27.0000] <TabAtkins>
othermaciej: You might want to figure out who you're arguing against, because it isn't me. ^_^

[18:52:46.0000] <SamB>
so, you better not nest too much if you do that

[18:52:52.0000] <othermaciej>
TabAtkins: my statements were counters to things said by different people

[18:53:00.0000] <TabAtkins>
SamB: Eh, works fine for me at anything between 2 and 8 spaces.

[18:53:44.0000] <SamB>
anyway, obviously if you don't use tabs, everyone needs to use the same `c-basic-offset'

[18:53:51.0000] <caitp>
far more bothersome than any of that is the insistence on using hungarian notation

[18:54:26.0000] <SamB>
hmm, I'm still not sure how I feel about hungarian notation

[18:54:31.0000] <othermaciej>
TabAtkins: I am pretty sure you agree with me that consistency in code formatting is important, but you also seemed to advocate use of real TABs for indenting, which I am not a fan of

[18:54:54.0000] <SamB>
TabAtkins: anyway, it sounds like I would have no problem with YOUR files

[18:54:57.0000] <TabAtkins>
Nominative determinism really leaves me no choice.

[18:55:07.0000] <SamB>
but many people do not know that there are ANY rules, and that's a problem

[18:55:15.0000] <othermaciej>
hungarian notation often adds more noise than info

[18:55:26.0000] <TabAtkins>
Yes, those people are the devil.

[18:56:01.0000] <SamB>
I would really prefer if getting live TABs required completing a training course of some kind

[18:56:18.0000] <SamB>
and if clippy would pop up if you started ruining the indentation in a file by using the wrong basic offset ;-P

[18:56:22.0000] <caitp>
U+000B after every function, or else!

[18:56:50.0000] <TabAtkins>
Yeah, IDEs could help by highlighting lines that start with spaces.

[18:57:37.0000] <SamB>
TabAtkins: I think it's a *bit* more complicated than that

[18:57:59.0000] <TabAtkins>
Yeah, but it's a good start.

[18:58:29.0000] <SamB>
I mean, how do you know if those spaces are for normal indentation or alignment?

[18:59:01.0000] <caitp>
his argument was that alignment isn't really necessary -> just add an extra indentation on wrapped lines

[18:59:06.0000] <SamB>
anyway, you've really gotta throw TAB out the window in, say, Haskell ...

[18:59:08.0000] <TabAtkins>
Just stick with my "only tabs" rule.

[18:59:13.0000] <caitp>
which works great for that particular style

[18:59:48.0000] <caitp>
of course you can do that with spaces too, and then you get to hang out with the cool kids

[19:00:22.0000] <TabAtkins>
Of all the cool kids jumped off a bridge, would you?

[19:00:43.0000] <caitp>
depends on the bridge!

[19:00:50.0000] <TabAtkins>
(Probably yes, there's probably something cool down there.)

[19:00:52.0000] <SamB>
well, I'd make damn sure my glider was in good shape beforehand ...

[19:03:20.0000] <SamB>
anyway, I've seen three positions with any sanity to them: Tab's, the one where you use only spaces and you're careful to at least use the same `c-basic-offset' everywhere, and the one where you say tab stops occur every 8 columns and make sure to use the same `c-basic-offset' as everyone else.

[19:04:27.0000] <SamB>
probably all of these could use some settings in .dir-locals.el

[19:06:05.0000] <MikeSmith>
"if you abolish style rules, you don't even need git blame anymore, the blame is built into the file" wins

[19:06:28.0000] <SamB>
I don't even *understand* that utterance

[19:06:39.0000] <SamB>
oh, wait

[19:06:51.0000] <caitp>
you can infer authorship and date from writing style!

[19:06:51.0000] <SamB>
that means everyone uses a different `c-indent-offset'?

[19:07:06.0000] <caitp>
but it was not a serious comment

[19:07:08.0000] <SamB>
well, that won't tell you which commit it was though

[19:07:11.0000] <SamB>
;-P

[19:07:22.0000] <caitp>
although of the set of useless super powers

[19:07:28.0000] <caitp>
that would be a pretty cool one

[19:07:37.0000] <zewt>
didn't know this thread was still going; i feel sort of bad :P

[19:08:01.0000] <SamB>
I think I'm done now

[19:08:25.0000] <SamB>
having given a list of positions I think are at all sane to have

[19:08:26.0000] <zewt>
i've been watching SGDQ (http://www.twitch.tv/speeddemosarchivesda) and having a beer

[19:10:14.0000] <TabAtkins>
zewt: It's cool, I'm having wine and flying.

[19:11:25.0000] <zewt>
TabAtkins, replying to the one thing highlighted at me: my experience is it's much easier to get consensus on "4-space soft tabs" than anything related to hard tab stops, which is a big benefit to me (we can just set it up and get back to work)

[19:12:53.0000] <TabAtkins>
zewt: On the other hand, Blink and Chromium use 2 and 4 space indents, respectively. Meeting the codebase is painful

[19:13:15.0000] <TabAtkins>
Merging, argh.

[19:14:22.0000] <caitp>
blink uses 2 space indents all over the place

[19:14:24.0000] <zewt>
2-space indentation is unforgivable

[19:14:29.0000] <caitp>
er

[19:14:31.0000] <caitp>
4 space*

[19:14:38.0000] <caitp>
are you saying there are files in blink that use 2 space?

[19:14:43.0000] <zewt>
but more than anything, changing indentation needs to be avoided at all costs

[19:15:57.0000] <zewt>
if they use different indentation across overlapping codebases, and they've reinvented code that needs to be merged, then somebody needs to be taken out of a decision-making position

[19:16:09.0000] <zewt>
because that's the worst possible result

[19:17:04.0000] <caitp>
to be fair, blink was inherited from webkit, and they probably weren't there when webkit decided on their style? but I am pretty sure it's 4 space indentation in chromium, blink and v8

[19:17:19.0000] <zewt>
... reindented (yeah, I'm on my phone)

[19:17:37.0000] <caitp>
oh i'm wrong, 2 space in v8

[19:17:41.0000] <caitp>
there you go =)

[19:17:58.0000] <zewt>
but if you've forked code and you have any intention of sharing code, you keep the existing indentation style--period

[19:17:59.0000] <TabAtkins>
We might have aligned indentation after the fork.

[19:18:22.0000] <SamB>
TabAtkins: that probably wasn't a good idea if you wanted to steal patches ever ...

[19:18:36.0000] <SamB>
TabAtkins: anyway, .dir-locals.el is your friend!

[19:18:49.0000] <zewt>
i guess the most important thing to remember about code style is: it's not the most important thing

[19:19:24.0000] <caitp>
i haven't landed anything in webkit, just blink, so I can't recall

[19:20:25.0000] <SamB>
I like the coding style rules for the GDB testsuite

[19:21:38.0000] <zewt>
i assume it's gnu

[19:21:40.0000] <SamB>
where there *are* no rules for the programs to run GDB on, because some of GDB's bugs might actually depend on coding style ...

[19:23:52.0000] <TabAtkins>
That's horrifying.

[19:24:34.0000] <caitp>
it's only horrifying when you realize contractors for boeing might be debugging code on it

[19:25:14.0000] <caitp>
or toyota or pick your favourite

[19:25:39.0000] <MikeSmith>
what specifically is being discussed at the "Web Input" meeting? https://twitter.com/jacobrossi/status/481173650523955200

[19:26:51.0000] <caitp>
input/touch/pointers/etc?

[19:27:34.0000] <MikeSmith>
must be I guess

[19:29:19.0000] <MikeSmith>
http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0084.html it seems

[19:30:25.0000] <SamB>
TabAtkins: well, you know, GNU have a lot of rules

[19:30:41.0000] <SamB>
I don't expect the indentation rules are actually involved here

[19:30:43.0000] <MikeSmith>
ah good TabAtkins was there

[19:30:50.0000] <MikeSmith>
and I see hober in the photo

[19:31:49.0000] <TabAtkins>
A bunch of things, trying to align on controversial cross-browser topics.

[19:32:45.0000] <MikeSmith>
TabAtkins: yeah I'm perusing https://docs.google.com/document/d/1C6P3Mhza1jdMJyP9G6fr7n7zcXrCmwih1o2xohFVEhc/edit now

[19:37:04.0000] <TabAtkins>
Yeah, Max took good notes.

[19:37:33.0000] <MikeSmith>
threaded input handling..

[19:38:36.0000] <MikeSmith>
the overview at https://docs.google.com/presentation/d/1VYfCKye4TM-QiR_hiLvwYxhci_xc5YcA4oZxtrp2qes/edit#slide=id.p is nice

[19:45:37.0000] <MikeSmith>
TabAtkins: is there implied optional whitespace anywhere in CSS syntax? (similar to the way there is in grammars in some IETF specs, e.g., HTTP headers

[19:47:57.0000] <MikeSmith>
TabAtkins: I mean, if I'm looking at a railroad diagram for a certain thing and it doesn't explicitly show whitespace as being allowed in some particular place, does that that mean the corresponding parsing algorithm for that thing does not expect to find whitespace there?

[19:47:58.0000] <TabAtkins>
Yes, V&U defines all this.

[19:48:06.0000] <MikeSmith>
ah ok

[19:48:40.0000] <TabAtkins>
Not that railroad diagrams are non-normative.

[19:48:40.0000] <TabAtkins>
Note

[19:49:07.0000] <TabAtkins>
That yes was to your first question, not the second one.

[19:49:19.0000] <MikeSmith>
TabAtkins: roger that

[19:49:27.0000] <MikeSmith>
/me finds http://dev.w3.org/csswg/css-values/#component-whitespace

[19:49:54.0000] <TabAtkins>
Yup, that's it.

[19:49:55.0000] <MikeSmith>
TabAtkins: I guess I expected to find that stated in teh Syntax spec instead of V&U

[19:50:34.0000] <MikeSmith>
TabAtkins: cool, thanks

[19:51:40.0000] <TabAtkins>
Syntax does the core syntax, not the grammar of actual properties.

[19:51:55.0000] <MikeSmith>
ah ok

[19:51:58.0000] <TabAtkins>
But also, the location is idiot historical.

[19:52:03.0000] <TabAtkins>
Partly

[19:52:27.0000] <MikeSmith>
sure

[19:53:18.0000] <MikeSmith>
TabAtkins: so now I understand about WS among components but the thing I'm wondering about specifically is about WS around delimiters

[19:53:38.0000] <TabAtkins>
Delimiters?

[19:54:27.0000] <MikeSmith>
TabAtkins: I mean, e.g., parens in functions -- calc(1px + 3px) vs calc( 1px + 3px )

[19:54:57.0000] <TabAtkins>
No rule there.

[19:55:52.0000] <TabAtkins>
Calc is a bit of a special case, but yeah, arguments to a function obey the same "component value" rules.

[19:56:40.0000] <MikeSmith>
ah OK sure, yeah, the WS in this case is space around the components, I see

[19:58:17.0000] <MikeSmith>
/me should write stuff out first before asking, since it's quite clear now when he actually looks at it written out

[06:56:37.0000] <annevk>
I hate these XMLHttpRequest state bugs :-(

[09:35:21.0000] <JonathanNeal>
Has anyone experimented with JavaScript generated markup how Google interprets it for search results? I’m thinking about entire pages of generated markup.

[09:46:23.0000] <annevk>
Domenic: when is it good to use null?

[09:49:55.0000] <TabAtkins>
JonathanNeal: Google hasn't been very detailed with what's happening, but they did announce recently that they're starting to execute at least some JS for indexing purposes.

[09:51:15.0000] <JonathanNeal>
Yes, clamstar was kind enough to share this with me http://googlewebmastercentral.blogspot.com/2014/05/understanding-web-pages-better.html

[09:58:56.0000] <Domenic>
annevk: kind of fuzzy, but in general it's a signifier for "there is purposefully nothing here," instead of "this was left unset" (which is `undefined`).

[09:59:32.0000] <Domenic>
E.g. it seems good that querySelector('asdf') returns `null`. If it returned `undefined`, that's what all functions without return values return, so it's kind of saying "I was supposed to return something, but there was nothing there."

[10:00:17.0000] <Domenic>
This whole distinction is kind of Stockholm-syndromey. I often catch myself saying "it makes perfect sense! How did we live without the distinction before!" And then I step back and say, WTF, clearly this language has changed your brain.

[10:23:29.0000] <annevk>
Domenic: so the problem with that is if you start returning null, you want to accept null too

[10:24:01.0000] <annevk>
Domenic: so you can't really make it a rule that methods accepting null should be retrofitted to use undefined/optional behavior instead

[10:24:32.0000] <annevk>
Domenic: e.g. node.insertBefore(..., otherNode.previousSibling)

[11:05:46.0000] <Domenic>
disagree

[11:05:53.0000] <Domenic>
null should throw in that situation

[11:06:02.0000] <Domenic>
undefined is a default-value signaler

[11:06:13.0000] <Domenic>
there's no sensible "default value" for a node that you want to insert

[11:06:18.0000] <Domenic>
annevk ^

[11:06:46.0000] <Domenic>
(both null and undefined should throw in that situation)

[11:07:27.0000] <annevk>
append seems reasonable

[11:08:48.0000] <annevk>
(which is what DOM does)

[11:14:15.0000] <Domenic>
it seems reasonable if you're trying to trigger the default value, but it's more likely a bug if you're trying to pass in document.querySelector('#tpyo')

[11:28:19.0000] <annevk>
E.g. node.prepend(input) would be node.insertBefore(input, node.firstChild)

[11:30:26.0000] <annevk>
TabAtkins: with the addition of rebeccapurple various notes around http://dev.w3.org/csswg/css-color/#named-colors are no longer accurate

[11:30:47.0000] <TabAtkins>
annevk: Yeah, noticed that.

[11:30:54.0000] <TabAtkins>
Was wondering if/how to change that.

[11:30:56.0000] <annevk>
TabAtkins: removing the notes about X11, HTML, and SVG might make sense

[11:31:35.0000] <annevk>
TabAtkins: maybe saying that most of them came from X11 in a note, with a pointer to that email that does all the archeology

[11:31:51.0000] <TabAtkins>
Yeah, was thinking about that. It's a great email!

[11:31:58.0000] <annevk>
is

[11:34:04.0000] <Manishearth>
annevk: around?

[11:34:26.0000] <annevk>
Manishearth: sorta

[11:34:59.0000] <Manishearth>
Okay, in http://xhr.spec.whatwg.org/#interface-formdata, in the `create an entry` bit, the spec seems to rewrite the `value` argument multiple times

[11:35:05.0000] <Manishearth>
Is that intentional?

[11:35:41.0000] <Manishearth>
This affects step 4, since it says "If value is a File and filename is given" -- `value` will always be a File, since it was made a File in the previous step

[11:35:53.0000] <Manishearth>
(since it was overwritten)

[11:36:24.0000] <annevk>
it can also be a string

[11:36:37.0000] <annevk>
and yes, it is intentional that in case it was a Blob, that step is applied

[11:36:38.0000] <Manishearth>
annevk: `value` is a Blob

[11:36:45.0000] <annevk>
not necessarily

[11:36:48.0000] <Manishearth>
(a File is also a Blob)

[11:36:53.0000] <annevk>
agreed

[11:37:11.0000] <annevk>
value is either a string or a Blob

[11:37:15.0000] <Manishearth>
so in step 3, "If value is a Blob, set value to a new File object", we are overwriting value?

[11:37:21.0000] <annevk>
yes

[11:37:59.0000] <Manishearth>
oh, I get it, this is used elsewhere too

[11:38:22.0000] <Manishearth>
(for the append() and set() where a DOMString is passed)

[11:38:30.0000] <Manishearth>
er, ScalarValueString

[11:38:38.0000] <Manishearth>
thanks

[11:38:44.0000] <annevk>
step 3 should not apply if value is a File however

[11:38:56.0000] <annevk>
that could be clarified

[11:39:35.0000] <Manishearth>
annevk: "If value is a Blob but not a File?"

[11:39:53.0000] <annevk>
yeah

[11:39:57.0000] <annevk>
making that edit now

[11:40:02.0000] <Manishearth>
okay, thanks

[11:40:35.0000] <annevk>
done

[12:12:01.0000] <IZh>
Hi. Is there API to query file upload progress from JS?

[12:12:30.0000] <caitp>
what kind of file upload progress?

[12:12:49.0000] <IZh>
Percentage

[12:13:25.0000] <caitp>
you can look at XMLHttpRequestUpload progress events, but that obviously is restricted to xmlhttprequest

[12:13:35.0000] <caitp>
and doesn't work for like, <form method="POST">

[12:13:57.0000] <IZh>
Lots of sites do it by using AJAX to query temporary file size from the server. But I would like to ask the browser itself.

[12:15:42.0000] <IZh>
Of course, I mean POST.

[12:16:31.0000] <caitp>
I mean, it would work for XHR (unless you're using like IE9 or under), but would not work for form submission

[12:17:10.0000] <IZh>
I think it would be great to implement some events for form's uploading progress. Because all modern sites need to display the progress.

[12:17:59.0000] <caitp>
couldn't hurt to ask if browsers are interested in doing that

[12:21:33.0000] <IZh>
I don't know whether they are, but it could make life easier.

[12:38:33.0000] <caitp>
well you might want to ask around here (there are some browser people hanging around), and maybe file a bug on the appropriate draft, which would probably be web-apps

[12:52:31.0000] <Domenic>
nah it'd be whatwg⊙wo

[12:52:36.0000] <Domenic>
this is about the HTML spec

[12:52:41.0000] <Domenic>
if it's about <form>

[12:55:34.0000] <caitp>
yeah, try that

[13:23:52.0000] <annevk>
IZh: the problem is that <form> causes navigate

[13:24:16.0000] <annevk>
IZh: which replaces the current document

[13:24:45.0000] <annevk>
IZh: events for navigation process don't make much sense if the document (and its associated global) change

[13:31:42.0000] <caitp>
it doesn't necessarily need to cause navigation, though, I think you'd make a lot of people happy if they could just <form method="POST" action="someroute" onprogress="updateWidget()">, heh

[13:32:20.0000] <caitp>
but I'm not going to get into that little discussion

[13:32:29.0000] <annevk>
That would cause navigation

[13:32:35.0000] <caitp>
it would _now_

[13:32:49.0000] <caitp>
but it doesn't necessarily need to, if you have some attribute that says "don't navigate plz"

[13:32:57.0000] <annevk>
If you want a new kind of form submission behavior that would be a different discussion

[13:33:30.0000] <caitp>
I'm not the one that wants it, I'm just saying it's not really beyond the realm of the reasonable

[13:33:46.0000] <caitp>
it's doable, and it wouldn't likely break any existing apps

[13:34:13.0000] <annevk>
Sure, but it's a different feature from progress

[13:34:18.0000] <caitp>
whether anyone actually wants to do it or not is a different discussion

[13:36:39.0000] <smaug____>
ojan: does blink have usage data for mutation events

[13:37:51.0000] <smaug____>
in gecko the data is currently measuring mutation events used in a window, and of  2.1G windows 5.5M have had mutation event listeners

[13:43:43.0000] <Domenic>
Loving this WebIDL thread

[13:45:02.0000] <SamB>
smaug____: any idea how had NoScript installed

[13:45:06.0000] <SamB>
+many

[13:45:15.0000] <SamB>
or anything of that nature

[13:53:55.0000] <smaug____>
SamB: no idea

[13:54:00.0000] <smaug____>
does it use mutation events?

[13:54:38.0000] <SamB>
actually, I was just figuring sites wouldn't get a chance to use them if noscript blocked the script

[13:54:41.0000] <smaug____>
oh, those might not get mutation events recorded


2014-06-25
[18:55:25.0000] <roc>
Anyone know why <img style="position:absolute; background-color:blue; left:10%; top:10%; right:10%; bottom:10%"> gives a 0x0 size of the <img> element in Chrome? This seems like an extremely basic bug

[18:57:28.0000] <roc>
/me wonders if that's actually correct

[18:59:11.0000] <roc>
looks like it is!

[19:30:42.0000] <Hixie>
as far as i can tell according to http://www.w3.org/2013/09/normative-references, the w3c's policy is that the w3c's own specs aren't good enough to be normatively referenced :-)

[19:38:16.0000] <MikeSmith>
Hixie: I think that doc's not been updated in a while but if you have suggestions I think plh would genuinely be interested

[19:38:54.0000] <MikeSmith>
the thing is that plh has a stronger interest than most anybody else in seeing the W3C have a saner policy for normative references

[19:39:26.0000] <MikeSmith>
since he's the one that's responsible for trying to get most of the specs through the W3C process

[19:39:59.0000] <MikeSmith>
specs for the web platform at least

[19:41:01.0000] <MikeSmith>
and the main thing that blocks many of the specs progressing right now is not any technical issues but instead this references problem

[19:43:23.0000] <SamB>
is that blocked on a patent policy?

[19:45:28.0000] <Hixie>
MikeSmith: that doc is all about "stable references" and (indirectly through a reference it itself has) "due process" and "broad consensus" and so on

[19:45:46.0000] <Hixie>
MikeSmith: a variety of things which the w3c doesn't actually do, and which are in any case not good ways to design technologies

[19:46:44.0000] <Hixie>
MikeSmith: there should really be very few concerns when referencing another spec. Prime amongst them: "Is the document being actively maintained?" and "Does the document accurately describe what implementations must do to obtain interoperability with deployed content?"

[19:46:50.0000] <MikeSmith>
I guess I filter out those parts. I'm more interested in tryin to make the actual requirements in there reflect what's important

[19:46:54.0000] <SamB>
process is probably a good idea for GRs and CTTE decisions; other than that I dunno ...

[19:47:04.0000] <MikeSmith>
Hixie: yeah, like that

[19:47:13.0000] <MikeSmith>
Hixie: it should have that kind of wording

[19:47:18.0000] <SamB>
Hixie: would it be a big issue if some spec were frozen?

[19:47:33.0000] <Hixie>
SamB: you mean like on the TR/ page? yeah...

[19:47:54.0000] <SamB>
like, I dunno, pretend the GIF spec actually specified everything important 20 years ago

[19:49:18.0000] <Hixie>
SamB: it'd still need to be updated over the years to track changes in frame length clamping, e.g.

[19:49:33.0000] <SamB>
hmm

[19:51:21.0000] <MikeSmith>
Hixie: the thing is, as I think you know, we don't really have a binding policy on this. Or really, the policy is, the Director decides whether something can transition or not, and if you can make a convincing case to the director for some individual spec, the director OKs it

[19:51:21.0000] <MikeSmith>
Hixie: but the director responds to reason and sound arguments, and things like "Is the document being actively  maintained?"

[19:51:21.0000] <MikeSmith>
... are sound

[19:51:21.0000] <MikeSmith>
and I don't think some of those things have been well-articulated by anybody to the director so far

[19:51:36.0000] <MikeSmith>
and "Does the document accurately describe what implementations must do to obtain interoperability with deployed content?" too

[19:52:08.0000] <Hixie>
"the director decides" is what people say is the worst part of the whatwg

[19:52:28.0000] <SamB>
I didn't know TimBL was at the WHATWG

[19:52:48.0000] <Hixie>
different director in the whatwg's case

[19:52:52.0000] <MikeSmith>
WGs should not be allowed to reference "stable" specs that don't match implementation realities -- unless the reference is to say, We're violating the following parts of this out-of-date spec

[19:52:55.0000] <Hixie>
(different director per spec, even)

[19:53:02.0000] <SamB>
I thought they were called editors

[19:53:10.0000] <Hixie>
a rose by any other name...

[19:53:40.0000] <SamB>
would be just as prickly?

[20:08:16.0000] <MikeSmith>
hayato: I don't find Kenji on IRC but been wanting to ask what the plans are for his open PRs at https://github.com/w3c/web-platform-tests/pulls/KenjiBaheux

[20:09:10.0000] <MikeSmith>
hayato: those have all mostly been sitting open with no activity for months and have kinda gone stale at this point

[20:09:40.0000] <hayato>
MikeSmith: These PRs are waiting for Kenji's response?

[20:09:47.0000] <hayato>
MikeSmith: Let me take a look

[20:10:05.0000] <MikeSmith>
yeah I think they're waiting on Kenji

[20:10:10.0000] <MikeSmith>
/me looks too to confirm

[00:07:31.0000] <zcorpan>
MikeSmith: the mq ref bug seems like make work. If you think it is urgent ask hixie to prioritize it

[01:17:06.0000] <annevk>
I like how 1386 mocks 386 a bit

[02:46:11.0000] <Ms2ger>
So who thought setting up a public-editing-tf mailing list was a good idea?

[02:49:49.0000] <darobin>
Ms2ger: pretty much everyone involved in the editing discussion

[02:50:20.0000] <darobin>
and, judging by the number of people who wrote to me saying "thanks for removing that incomprehensible discussion from WebApps", quite a few WebApps people too :)

[03:00:02.0000] <Ms2ger>
Yeah, defining things in silos always works out well

[03:00:16.0000] <Ms2ger>
Good that I wasn't hoping for that to go anywhere

[03:06:00.0000] <roc>
Ms2ger: surely you're too young to be this bitter

[03:06:36.0000] <Ms2ger>
Standards work ages one quickly

[03:07:14.0000] <roc>
hmm, how old does that make me?

[03:07:54.0000] <Ms2ger>
being-cited-in-textbooks-old :)

[03:23:32.0000] <MikeSmith>
/me dials down the Bitterness setting on the Ms2ger bot, dials up the Smoothness

[04:41:51.0000] <tobie>
Domenic: #popcorn

[04:51:00.0000] <annevk>
tobie: what did he do?

[04:51:29.0000] <tobie>
annevk: he reference the WebIDL thread above. :)

[04:51:49.0000] <tobie>
*referenced

[04:51:58.0000] <annevk>
ah

[05:05:47.0000] <annevk>
So with Symbols we could make a lot of things extensible

[05:06:17.0000] <annevk>
E.g. send() and fetch() both take a thing of sorts and extract bytes and a MIME type out of it (and maybe an encoding)

[05:06:56.0000] <annevk>
If we defined @@fetchExtract or some such that returns an object with the relevant information, that would totally work

[06:37:14.0000] <smaug____>
does the spec say something about image documents

[06:37:43.0000] <smaug____>
I mean, what kind of content the document should have, if just an image is loaded to a browsing context ?

[06:37:54.0000] <smaug____>
(I think it did, but can't find it now)

[06:38:24.0000] <annevk>
smaug____: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#read-media

[06:39:13.0000] <smaug____>
thanks

[06:39:20.0000] <smaug____>
(history.html o_O)

[06:40:03.0000] <annevk>
smaug____: artefact of splitting

[07:19:45.0000] <zewt>
help, working in a new codebase and these guys use hard tabs, so the code is all randomly unformatted and unreadable

[07:38:20.0000] <annevk>
I wonder who is implementing networking in Servo

[07:38:30.0000] <annevk>
And whether they are making use of http://wiki.whatwg.org/wiki/HTTP and such

[07:41:37.0000] <SimonSapin>
annevk: we (Servo) use rust-http, which is built mostly by Chris Morgan. I don’t know what specs it’s based on.

[07:42:22.0000] <SimonSapin>
annevk: also, how does that wiki page relate to the "httpbis" RFCs? https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

[07:43:18.0000] <annevk>
SimonSapin: I believe most of it is still accurate, unless the feedback was addressed

[08:36:15.0000] <Domenic>
annevk: I am indeed confused @_@

[08:36:29.0000] <Domenic>
what does asFormData() work on, if not application/x-www-form-urlencoded?

[08:36:52.0000] <Domenic>
I guess multipart/form-data...

[08:36:58.0000] <Domenic>
Thus option 1) is about making it work on both

[08:37:27.0000] <Domenic>
whereas asURLSearchParams(), if it were to exist, would work only on application/x-www-form-urlencoded

[08:37:53.0000] <annevk>
Yes, multipart as FormData handles files

[08:38:43.0000] <Domenic>
OK. I think I finally understand the OP now. So option 1) is having only asFormData(), but having it work on both of those two formats

[08:54:00.0000] <annevk>
Domenic: stuffing .loaded and .total on some stream concept actually makes a lot of sense

[08:54:13.0000] <annevk>
Domenic: going to prototype that in English

[08:54:42.0000] <Domenic>
For very few streams do you know the size ahead of time

[08:55:28.0000] <Domenic>
And .loaded doesn't make much sense without the ability to know when it changes, at which point you're probably just consuming the stream anyway.

[08:56:20.0000] <annevk>
Observing I guess

[08:56:39.0000] <annevk>
Anyway, for fetch streams you know it surprisingly often

[08:56:49.0000] <Domenic>
Yeah, passive observation is one thing

[08:57:24.0000] <Domenic>
not sure you need a .contentLength to alias .headers.get('contentLength') though

[08:58:03.0000] <annevk>
get('content-length')

[08:59:18.0000] <Domenic>
right

[09:00:23.0000] <annevk>
Yeah I guess might refactor it later or some such

[09:54:30.0000] <Domenic>
This seems bad http://dev.w3.org/fxtf/geometry/#DOMRectList

[09:55:15.0000] <Domenic>
annevk ^

[09:56:19.0000] <annevk>
Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26200

[09:56:58.0000] <Domenic>
I was just about to email public-fx; guess that wil ldo.

[09:57:04.0000] <Domenic>
Will comment on blink-dev

[09:57:27.0000] <Domenic>
I wonder if I should switch to using my @google.com email...

[10:01:35.0000] <annevk>
Domenic: if you plan on never leaving Google

[10:03:17.0000] <Domenic>
yeah :-/

[10:03:30.0000] <Domenic>
Still need to switch to d⊙dm, but that's going to be so much work.

[10:06:32.0000] <Domenic>
annevk "FYI all these interfaces landed in Firefox and are available in the nightly builds"

[10:06:41.0000] <Domenic>
how did we let these slip by...

[10:09:05.0000] <annevk>
Domenic: happened March 18

[10:09:15.0000] <caitp>
most of the people I work with are only using their corporate accounts for accessing internal stuff, maybe you don't need it for public mailing lists?

[10:09:21.0000] <annevk>
Domenic: I think I didn't pay attention because I thought it was already discussed earlier on

[10:09:55.0000] <Domenic>
Can you pick up the torch to nuke DOMRectList in Firefox?

[10:10:10.0000] <annevk>
Domenic: as for changing emails, I found it surprisingly easy, just make sure you get both in the same inbox while transitioning

[10:10:32.0000] <annevk>
Domenic: I don't even know what DOMRectList is for

[10:10:44.0000] <annevk>
Domenic: if it's getClientRects() it might be needed

[10:11:10.0000] <Domenic>
ah.

[10:11:18.0000] <Domenic>
trying to download FF nightly to find out

[10:12:20.0000] <Domenic>
you can't run nightly and stable at the same time?? O_O

[10:13:19.0000] <annevk>
Just run Nightly all the time :-)

[10:13:47.0000] <annevk>
I think the only stable browser I have is Safari because it came with the OS...

[10:15:09.0000] <annevk>
Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26103

[10:15:16.0000] <annevk>
Domenic: that's effectively your request

[10:15:29.0000] <Domenic>
Ah yeah it's getClientRects(), sucky

[10:15:32.0000] <annevk>
Domenic: I don't think I'm getting the idea through to Hixie

[10:15:53.0000] <annevk>
That specification should call that out somehow, that it's legacy

[10:15:55.0000] <Domenic>
would be best to name it LegacyGetClientRectsReturnValueType

[10:16:08.0000] <Domenic>
and make it [NoInterfaceObject]

[10:16:16.0000] <Domenic>
yeah I should probably chime in on that bug

[10:16:21.0000] <annevk>
And add Symbol.iterator

[10:16:38.0000] <annevk>
Symbol.iterator all the things

[10:17:07.0000] <Domenic>
hmm Chrome has ClientRectList, also exposed globally

[10:18:58.0000] <annevk>
That was the old name

[10:19:16.0000] <annevk>
It seems the CSS WG obsession to split all the specs has happened here

[10:20:49.0000] <annevk>
Oh man, once I'm done with this change in Fetch I've fixed several SUPER HARD BUGS

[10:24:56.0000] <annevk>
krit: a getter does not an array make

[10:26:43.0000] <krit>
annevk: beside that it is not of type Array and has not the usual methods of Array it does exactly what authors need to do with it

[10:27:00.0000] <krit>
annevk: DOMRectList is definitely not intended to be modified

[10:27:07.0000] <krit>
annevk: at least not by the user

[10:27:22.0000] <krit>
annevk: you can modify the elements of it though

[10:27:39.0000] <annevk>
No, you can't map, reduce, etc.

[10:27:59.0000] <annevk>
And DOMRectList is a snapshot, so it doesn't matter if it's modified

[10:30:09.0000] <krit>
annevk: who says that it is a snapshot?

[10:31:35.0000] <annevk>
krit: the spec could be clearer, but I sure hope that it's not live

[10:31:48.0000] <annevk>
(if it is, the spec needs to be clearer)

[10:32:11.0000] <annevk>
(can't just return an empty list in that case)

[10:32:12.0000] <krit>
annevk: it doesn’t because it does not specify the use case

[10:32:29.0000] <annevk>
?

[10:34:49.0000] <krit>
annevk: it is up to the interface thats uses DOMRectList to define if the user can update the elements and it will do something in the backend or if it returns a snapshot

[10:35:48.0000] <annevk>
1) DOMRectList should never be used again

[10:35:52.0000] <Domenic>
That is not how JavaScript works...

[10:36:06.0000] <annevk>
2) The usage it has suggests it's only used as static and therefore we might be able to get rid of it

[10:45:26.0000] <SamB__>
Domenic: what's not how JavaScript works? "it is up to the interface [...]"?

[10:50:52.0000] <Domenic>
Yes

[11:19:03.0000] <caitp>
what's going on with the traceur repl arv_ =( seems to be broken today

[11:19:24.0000] <arv_>
caitp: Let me take a look

[11:24:03.0000] <arv_>
caitp: Fixed

[11:33:07.0000] <caitp>
thanks

[12:37:30.0000] <TabAtkins>
roc: Looks like the formula is that the width calculation yields 0x0 intrinsic size (because there's no src there), then you use 'left' and that width to position it, ignoring 'right' due to overconstraint?  (And same with top/height.)

[13:09:20.0000] <annevk>
TabAtkins: so how do I know email to www-style is tracked?

[13:09:47.0000] <TabAtkins>
Editor deals with it? (We are bad at giving tracking feedback.)

[13:16:59.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26134 :-)

[13:17:02.0000] <annevk>
/me is not feeling it

[13:17:28.0000] <annevk>
TabAtkins: that requires tracking on my part

[13:25:11.0000] <montecfel>
Is it intended behavior for custom .woff fonts in CSS/Canvas to be drawn with the coordinate system being in the bottom-left rather than top-left?

[13:25:31.0000] <TabAtkins>
montecfel: Example?

[13:25:51.0000] <TabAtkins>
I mean, do other font types draw differently somehow?

[13:29:58.0000] <montecfel>
TabAtkins: Well, I don't know. I just know that the one I have does.

[13:30:03.0000] <montecfel>
And it happens to be a .woff.

[13:30:13.0000] <montecfel>
And AFAIK, .woff is the only format to use these days.

[13:30:26.0000] <montecfel>
It seems like they normally are counted with a top-left coordinate system.

[13:30:27.0000] <TabAtkins>
montecfel: Okay, your questions was misleadingly detailed. ^_^

[13:30:55.0000] <SamB>
montecfel: I believe fonts normally orient their axes in this manner, yes

[13:31:03.0000] <TabAtkins>
I think text drawing is usually done by specifying the point that the baseline begins at.  What do you mean by "in CSS"?

[13:31:21.0000] <TabAtkins>
I know SVG <text> anchors things bottom-left, and I think canvas text does too.

[13:31:24.0000] <SamB>
if you're talking about coordinates included in the font

[13:32:07.0000] <SamB>
where "bottom left" doesn't mean bottom left of the bounding box, of course, but merely the reference point, which is at the left of the boundingbox and on the baseline

[13:32:47.0000] <Philip`>
montecfel: You can change ctx.textBaseline for canvas text - the default baseline is at the bottom of the letters

[13:34:13.0000] <montecfel>
Hmm...

[13:34:28.0000] <montecfel>
Well, I "load in" the .woff in a .css.

[13:34:33.0000] <montecfel>
But then I use it to draw inside a Canvas.

[13:35:02.0000] <TabAtkins>
Okay, and when you tell it to draw at, say, (10, 20), it puts the bottom-left of the text string at 10,20, and you're confused by that?

[13:35:27.0000] <SamB>
montecfel: sounds like you might want to look into .textBaseline

[13:35:36.0000] <SamB>
Philip`: that is a very unusual default

[13:35:51.0000] <TabAtkins>
SamB: ? Why is it unusual?

[13:36:00.0000] <TabAtkins>
That's the standard english baseline, shared by most writing systems.

[13:36:02.0000] <SamB>
well, what if I had, say, a j

[13:36:10.0000] <SamB>
oh, he was speaking loosely?

[13:36:10.0000] <TabAtkins>
He didn't mean "literally bottom".

[13:36:15.0000] <SamB>
ah

[13:36:16.0000] <SamB>
cool

[13:36:21.0000] <SamB>
I was worried for a moment

[13:36:41.0000] <SamB>
TabAtkins: sorry, I think I left my sanity at the door or something

[13:36:46.0000] <TabAtkins>
Heh.

[13:41:45.0000] <TabAtkins>
montecfel: Still there, or did things solve themselves?

[13:49:57.0000] <montecfel>
Problems never solve themselves for me.

[13:50:00.0000] <montecfel>
Back, though.

[13:50:11.0000] <montecfel>
Hmm. That sounds like a property/directive that might come in handy indeed.

[13:50:21.0000] <TabAtkins>
Okay, so looking at my previous line to you, is that the part where you're confused?

[13:50:39.0000] <TabAtkins>
Note that messing with baselines is probably more confusing than you realize.

[13:50:41.0000] <montecfel>
Well, I believe this is what is happening, yes.

[13:50:54.0000] <montecfel>
But this will be a thing I have to invest for the next project.

[13:51:11.0000] <TabAtkins>
Yeah, if you can figure out something that works, go for it.

[13:51:44.0000] <TabAtkins>
But the behavior you're seeing is very standard for direct text-drawing APIs.  You're probably just dealing with confusion from CSS, where you never draw text directly, you position a box that *contains* text.

[14:55:57.0000] <Domenic>
Hixie: given the brand-color kerfluffle, do you think updating the HTML spec to say something like "if your meta tag changes user agent behavior, it needs to be in this spec" would be a good idea?

[15:02:17.0000] <jamesr_>
if it changes UA behavior that isn't observable from the web that doesn't sound like a good idea

[15:02:31.0000] <jamesr_>
it'd be weird for the HTML spec to start making statements about browser UI

[15:05:35.0000] <Hixie>
Domenic: what kerfuffle?

[15:06:24.0000] <Domenic>
Hixie: https://groups.google.com/a/chromium.org/d/msg/blink-dev/nzRY-h_-_ig/KR3XWn73tDoJ ?

[15:07:03.0000] <Hixie>
i wouldn't call that a kerfuffle, but ok

[15:07:11.0000] <Hixie>
the solution with that kerfuffle is easy

[15:07:20.0000] <Hixie>
blink should just support the property names the other browsers used

[15:07:38.0000] <Domenic>
ok. so they should be specced?

[15:07:59.0000] <Hixie>
all meta values should be specced

[15:08:09.0000] <Domenic>
do you think the wiki is sufficient then?

[15:08:31.0000] <Domenic>
it seems to easy to just create a new proprietary meta thing and then say "we specced it on the wiki" without ever actually trying to collaborate across browsers

[15:08:47.0000] <Hixie>
it's easy to just create a proprietary element and do that too

[15:08:58.0000] <Hixie>
or to create something in a closed silo ignoring feedback from others

[15:09:10.0000] <Hixie>
even if it's not proprietary

[15:09:22.0000] <Hixie>
or to disagree with someone and just shut them out instead of addressing their feedback

[15:09:35.0000] <Hixie>
there's all kinds of ways that you can do an end-run around community-driven spec development

[15:09:38.0000] <Hixie>
it's life

[15:10:40.0000] <Hixie>
changing the spec to say that things have to be in the spec won't change anything

[15:10:51.0000] <Hixie>
(if it did, we wouldn't have the stupid stuff with ruby extensions, e.g.)

[15:10:52.0000] <Domenic>
sure. but i would rather people feel bad about creating something proprietary, than feel good about creating something spec-compliant (via the wiki).

[15:11:04.0000] <Hixie>
people won't feel bad

[15:11:08.0000] <Domenic>
well, the spec currently says "it must be in the wiki"

[15:11:17.0000] <Hixie>
yeah, and no vendor until chrome put it in the wiki

[15:11:17.0000] <Domenic>
and that compelled action

[15:11:21.0000] <Domenic>
hmm

[15:11:27.0000] <Hixie>
it compelled action the third time it was implemented

[15:11:29.0000] <Hixie>
with a third name

[15:11:34.0000] <Hixie>
that's hardly a success

[15:11:37.0000] <Hixie>
it's a 100% failure rate

[15:11:45.0000] <Hixie>
66% failure to register, 33% failure to reuse an existing term

[15:11:52.0000] <Domenic>
fair. maybe we can't push our luck.

[15:12:10.0000] <Hixie>
making the barrier higher certainly won't improve matters

[15:32:03.0000] <TabAtkins>
Hixie: The problem here is that "the spec only requires us to put it on the wiki" was being used as an *explicit justification* for not talking it over with other browsers. It was total bullshit, of course, but having the spec at least address that would have made the bullshit more obvious, and thus less likely to have been stated embarrasingly in public.

[15:33:17.0000] <Hixie>
the spec requires more than that for a value to be "ratified"

[15:33:38.0000] <Hixie>
feel free to just mark the value as "discontinued"

[15:33:57.0000] <Hixie>
since it has received wide peer review and been found wanting

[15:34:12.0000] <Hixie>
but in any case, changing how the registry system works is something i'd like to do. it's been pending on feedback from hsivonen for a while.

[15:35:12.0000] <gsnedders>
…what kind of version name is "L"?

[15:35:27.0000] <Domenic>
Codename for some dessert that starts with L, I assume

[15:37:23.0000] <Philip`>
I guess they learned a lesson from using "KLP" as the codename for the previous version, so now they just use a single letter until the marketing people pick the real name

[15:37:41.0000] <gsnedders>
…what kind of version name is "KLP"?

[15:38:52.0000] <Hixie>
Key Lime Pie, later KitKat

[15:38:54.0000] <Philip`>
The abbreviation of Key Lime Pie, from before theyrealised how much everyone loves Kit Kats

[15:39:00.0000] <Philip`>
s// /

[15:39:17.0000] <gsnedders>
Guess that makes more sense than XP

[15:41:23.0000] <TabAtkins>
Our versions are always consecutive letters, given dessert names at release.

[15:41:37.0000] <TabAtkins>
Dunno why we haven't announced the name yet, though. I dont' even know it.

[15:41:56.0000] <TabAtkins>
/me hopes it's Limoncello, so we'll get some in the microkitchens.

[15:41:59.0000] <Philip`>
(There are still lots of references "klp" in the Android repositories, which is needlessly confusing if you only know the actual release names)

[15:42:35.0000] <Philip`>
(Then again, there were three separate Jellybean versions, so needless confusion seems to be a habit)

[15:43:19.0000] <TabAtkins>
Indeed.

[15:45:20.0000] <gsnedders>
TabAtkins: I'm now imagining a Limoncello launch party, where, uh, the Limoncello flows freely. That would end badly.

[15:59:17.0000] <jamesr_>
/me is hoping for Lime Pie

[16:44:33.0000] <roc>
TabAtkins_: right

[16:44:43.0000] <TabAtkins_>
roc: kk

[16:45:03.0000] <roc>
annevk: DOMRectList has existed for a very long time. It started off as an IE invention for getClientRects, and then we standardized it.

[16:45:55.0000] <roc>
annevk: it is not live, and it's entirely possible we can make getClientRects return sequence<DOMRect>.


2014-06-26
[18:14:11.0000] <montecfel>
Hmm.

[18:14:31.0000] <montecfel>
It is not possible to invoke fullscreen unless the user clicks?

[18:14:45.0000] <montecfel>
I tried to make Alt + Enter go into fullscreen, but it doesn't work. It only works when there is a click event.

[18:16:05.0000] <montecfel>
You can probably ignore that.

[18:23:56.0000] <montecfel>
"Request for full-screen was denied because Element.mozRequestFullScreen() was not called from inside a short running user-generated event handler."

[18:23:59.0000] <montecfel>
Huh? :/

[18:28:04.0000] <caitp>
it doesn't look like there's anything normative about disallowing that outside of event handlers, montecfel

[18:28:24.0000] <montecfel>
Well... hrm.

[18:28:37.0000] <montecfel>
How do I detect if a modifier key was pressed together with the e.keyCode?

[18:28:38.0000] <caitp>
more craziness from moco? why not!

[18:28:46.0000] <montecfel>
caitp: ?

[18:28:54.0000] <caitp>
oh, I know the answer to that, hang on

[18:29:04.0000] <montecfel>
moco = Mozilla Corporation?

[18:29:22.0000] <montecfel>
Yes, they sure are being very do-everything-except-for-working-on-the-actual-browser-y lately.

[18:29:23.0000] <caitp>
the keyboardevent interface has some properties for modifier keys, like altKey

[18:29:28.0000] <montecfel>
Lately = last 5-10 years?

[18:29:36.0000] <montecfel>
Yeah...

[18:29:57.0000] <montecfel>
Is Ctrl + Enter or Alt + Enter the classic "go to fullscreen" or "go out from fullscreen" key combo?

[18:30:00.0000] <montecfel>
Alt + Enter, I believe.

[18:30:36.0000] <montecfel>
Do you mean it's e.altKey?

[18:30:51.0000] <caitp>
yeah

[18:31:02.0000] <montecfel>
And it's just a boolean?

[18:31:07.0000] <caitp>
I think that's from DOM 2 or something

[18:31:15.0000] <montecfel>
Finally something that makes sense!

[18:32:26.0000] <MikeSmith>
TabAtkins_: you'll probably be unhappy to know that when I land @sizes checking support in the validator, it's going to accept pretty much anything within calc(...), because the kludgey way I handle it for now only just looks for "calc" followed by balanced parens

[18:32:53.0000] <caitp>
guess i'm wrong, dom3

[18:33:45.0000] <MikeSmith>
TabAtkins_: for the validator I really can't justify the time needed to stop and write a full CSS tokenizer to handle this one single attribute in the entire language that would benefit from it, as far as conformance checking goes

[18:34:35.0000] <MikeSmith>
@sizes is seeming more and more to me like a layering violation

[18:35:32.0000] <MikeSmith>
not that I'm a purist. I guess it's probably a justified violation in this case. But still it's punching holes.

[18:44:43.0000] <MikeSmith>
Hixie: Domenic I wouldn't call the brand-color thing a kerfuffle either. I'd call it a wilful abuse of the spirit of requirements. The arrogance displayed in that thread is worthy of bad-old-days Microsoft or whatever other "evil" incarnantion of some org just flipping the bird to everybody else

[18:45:21.0000] <MikeSmith>
I suspect we probably have more instances of that kind of stuff to look forward to

[18:47:23.0000] <a-ja>
MikeSmith: haven't read followups to that discussion in a few days....new developments?

[18:47:25.0000] <MikeSmith>
the rationalization around it that followed was even more disappointing than the initial act of abusing the implicit contract

[18:47:49.0000] <Hixie>
the worst imho is that this was the third instance of this

[18:47:55.0000] <Hixie>
for this very feature

[18:47:58.0000] <MikeSmith>
a-ja: no I've not read any followups to it during the last week or so.. Not sure if there have been any

[18:48:08.0000] <Hixie>
so three vendors had the same arrogance and missing-the-point-ness

[18:48:16.0000] <MikeSmith>
Hixie: well, that too

[18:48:22.0000] <MikeSmith>
that exactly

[18:48:41.0000] <a-ja>
MikeSmith: agree with your "evil" categorization, fwiw

[18:48:44.0000] <Hixie>
which i kinda take as an indication of failure on the part of standards advocacy :-(

[18:49:10.0000] <MikeSmith>
Hixie: well, we sort of expect that everybody will be a good actor

[18:50:16.0000] <SamB>
I'm missing the context :-(

[18:51:13.0000] <MikeSmith>
a-ja: evil is what organizations other than yours do

[18:51:22.0000] <a-ja>
heh

[18:52:23.0000] <MikeSmith>
SamB: thread on blink-dev about an intent-to-ship for meta@name=brand-colorg

[18:52:29.0000] <MikeSmith>
*color

[18:54:49.0000] <SamB>
Hixie: so this is the THIRD time somebody has done ... what exactly?

[18:55:12.0000] <Hixie>
SamB: invented a proprietary value to colour system ui for the page

[18:55:24.0000] <SamB>
Hixie: ah

[18:55:35.0000] <SamB>
Hixie: so like IE's scrollbar thing?

[18:55:40.0000] <Hixie>
yeah

[18:55:49.0000] <Hixie>
specifically, doing so without getting other vendors to buy in

[18:56:00.0000] <SamB>
what was the other one?

[18:56:27.0000] <MikeSmith>
Hixie: anyway I agree with Domenic's proposal about "if your meta tag changes user agent behavior, it needs to be in this spec" or some such language

[18:57:51.0000] <Hixie>
/me shrugs

[18:57:57.0000] <Hixie>
i don't think it would make that much difference

[18:58:02.0000] <Hixie>
but in any case

[18:58:05.0000] <MikeSmith>
Hixie: also btw and fwiw even if we had implemented your proposal for validator refinements for meta@name, I don't think it would have prevented this case -- or this set of three cases

[18:58:10.0000] <Hixie>
i want to change that whole extension model

[18:58:15.0000] <Hixie>
and i'm just waiting for hsivonen's feedback

[18:58:50.0000] <Hixie>
yeah, that's good feedback on the proposal

[18:59:17.0000] <MikeSmith>
Hixie: feedback to which proposal? Your message at the beginning of the year wasn't a proposal for changing the whole extension model, was it?

[18:59:36.0000] <MikeSmith>
Hixie: I mean what feedback are you waiting on from Henri

[18:59:51.0000] <caitp>
don't worry dude, in the future web compat won't matter because we'll be making people write 12 versions of their applications for hundreds of different smartphones, tablets, gps machines, laundrey machines, etc, and nobody will even remember a time when the same document looked more or less the same on a different device

[19:00:44.0000] <SamB>
caitp: you have a funny way of beginning that sentence

[19:01:32.0000] <caitp>
you have to read it with just the right tone to really get it

[19:03:37.0000] <SamB>
oh, now I see

[19:04:03.0000] <MikeSmith>
caitp: on the plus side, I guess we can look forward to people's sigs saying "Sent from my laundry machine."

[19:04:05.0000] <SamB>
the other two times are listed RIGHT IN THE FIRST DAMN POST and they can't see this is a bad idea?

[19:05:42.0000] <Hixie>
MikeSmith: it was a start to a proposal, but yeah, not a complete one.

[19:05:51.0000] <Hixie>
MikeSmith: that's what i'd like to see hsivonen's feedback on, though

[19:06:14.0000] <SamB>
From: "'Alex Russell' via blink-dev" <blink-dev⊙co>

[19:06:54.0000] <SamB>
/me wonders wth the "via blink-dev" bit is for

[19:07:10.0000] <MikeSmith>
SamB: I think http://goo.gl/mxQwE pretty well captures their attitude toward what other people think about it being a bad idea

[19:08:00.0000] <MikeSmith>
SamB: I think that just indicates the message was sent from the Web interface

[19:08:11.0000] <MikeSmith>
SamB: rather than by e-mail

[19:08:24.0000] <SamB>
why are they poluting my gnus view with such inane distractions

[19:09:27.0000] <MikeSmith>
/me adds SamB to the list of crazy people like hober and Haakon that use emacs for reading mail

[19:10:03.0000] <SamB>
MikeSmith: well, the first post looked terrible on gmane classic, so I foolishly hoped it would look better in gnus

[19:10:18.0000] <SamB>
anyway, it's not mail, it's news, obviously

[19:10:45.0000] <MikeSmith>
nothing is obvious to me when it comes to emacs

[19:13:08.0000] <MikeSmith>
Hixie: also btw and fwiw at this point, I recently did at least update the validator to quit having the list of meta@name and a|link@rel values hardcoded. They are now pulled in a build time from http://help.whatwg.org/extensions/meta-name/ and http://help.whatwg.org/extensions/a-rel/ and http://help.whatwg.org/extensions/link-rel/

[19:13:37.0000] <MikeSmith>
Hixie: which are just generated by python scripts that scrape the wiki

[19:14:18.0000] <MikeSmith>
Hixie: so they're  not updated real time but at least it's progress over what we were doing before

[19:14:18.0000] <Hixie>
MikeSmith: cool

[19:16:31.0000] <roc>
montecfel: FWIW, as one of the gazillions of people Mozilla people working on the browser, I somewhat resent the suggestion that we aren't.

[19:24:58.0000] <montecfel>
roc: What about all the weird projects that Mozilla are announcing all the time? Why is the browser and all the issues that still exist never heard of, basically?

[19:25:27.0000] <montecfel>
This latest IDE-in-the-browser is very "inner system"-y.

[19:41:05.0000] <roc>
What you hear about is not entirely under our control

[19:41:53.0000] <roc>
if you look at https://hacks.mozilla.org/, you will see a lot of articles there about devtools and new browser engine features

[19:42:14.0000] <roc>
if you're more interested in the front end, there was a major UI change that shipped recently that you may have heard about

[19:43:47.0000] <caitp>
they are working on the browser, and lots of other stuff too, credit where credits due

[20:08:29.0000] <MikeSmith>
yeah as far as any perceived never-heard-of problem, I can't see that there's any shortage of information going out about new gecko browser-engine features

[20:09:06.0000] <MikeSmith>
https://hacks.mozilla.org/ and the related twitter account are a great source of info

[20:12:43.0000] <MikeSmith>
and as far as announcements about the IDE-in-the-browser thing, that doesn't seem to me at all like a weird project at all. Clearly it's something intended to meet needs of the same web devs that care about the core browser-engine features

[20:18:57.0000] <SamB>
I'd suggest a SWANK backend, if SLIME would ever get its ass in gear and at least pretend to have a stable protocol ...

[20:21:41.0000] <MikeSmith>
SamB: SLIME and SWANK are real things, or some kind of troll you're trying to catch me with

[20:21:58.0000] <MikeSmith>
SamB: ah, emacs

[20:22:01.0000] <SamB>
yeah, emacs

[20:22:02.0000] <MikeSmith>
you got me

[20:22:03.0000] <SamB>
real things

[20:22:05.0000] <MikeSmith>
I feel for it

[20:22:11.0000] <MikeSmith>
nice troll

[20:22:15.0000] <MikeSmith>
emacs-rolled me

[20:23:58.0000] <SamB>
Slime is a CL IDE for Emacs that's better than the builtin support for Emacs Lisp.  And it's been abused to work with lots of things that aren't CL, too ...

[20:24:25.0000] <MikeSmith>
ah OK

[20:25:08.0000] <MikeSmith>
that's novel, emacs being abused to do things that are better handled with other things

[20:29:07.0000] <jory>
Mmmmm, emacs... delicious.

[20:34:54.0000] <SamB>
I'm not actually aware of a more fertile ground for mail/news implementations than Emacs; are you?

[20:35:24.0000] <SamB>
nevermind that it comes with not one but TWO irc clients ;-P

[20:35:48.0000] <jory>
Of course, "It's all just text"

[22:23:34.0000] <caitp>
having fun with the promise implementation? :p

[22:27:34.0000] <Domenic>
caitp: awesome response time

[04:21:33.0000] <smaug____>
Hixie: curious, why http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#read-media says "should". Any reason to not "must"? (Someone was just about to change image document content in Gecko and said that isn't against of the spec because of that "should")

[04:21:40.0000] <smaug____>
/me r-'ed that patch

[04:28:17.0000] <Ms2ger>
smaug____, well, then they don't know what "SHOULD" means :)

[05:38:32.0000] <SimonSapin>
must (but we know you won’t)

[07:03:55.0000] <mounir>
Domenic: ping

[07:04:03.0000] <Domenic>
mounir: pong

[07:04:43.0000] <mounir>
Domenic: regarding https://github.com/w3c/screen-orientation/issues/13

[07:05:18.0000] <mounir>
Domenic: I'm not sure how we can avoid screen.orientation != screen.orientation (comment 4)

[07:05:29.0000] <mounir>
Domenic: unless we do very complicated things

[07:05:35.0000] <mounir>
Domenic: is it something you care about?

[07:05:56.0000] <Domenic>
mounir: yes, it is something I care about very much

[07:06:17.0000] <Domenic>
mounir: I am happy to write up the spec text if necessary. We need to set an example on how to do this for other specs, since WebIDL is deficient.

[07:06:38.0000] <mounir>
Domenic: screen.orientation would be an Object if I understand correctly, right?

[07:07:13.0000] <mounir>
Domenic: but in order to have equality, we would need to return exactly the same object

[07:07:36.0000] <Domenic>
mounir: yep. Just think of how you would implement this in JavaScript.

[07:08:36.0000] <mounir>
Domenic: so, doing that for screen.orientation isn't much of a pain

[07:09:07.0000] <mounir>
Domenic: making screen.lockOrientation() promise being fulfiled with an object that is equal to screen.orientation when they are the same is... more of a pain

[07:09:12.0000] <Ms2ger>
Domenic, no

[07:09:23.0000] <Domenic>
mounir: I don't care about that as much, but it also seems pretty easy

[07:09:24.0000] <Ms2ger>
Domenic, if IDL is deficient, fix IDL

[07:09:39.0000] <mounir>
Ms2ger: might take years :)

[07:09:40.0000] <Domenic>
mounir: just say "resolve p with the value of this.orientation"

[07:10:02.0000] <Domenic>
Ms2ger: fair. I have time for that now.

[07:10:08.0000] <mounir>
Domenic: this.orientation is updated after the promise is resolved ;)

[07:10:18.0000] <Domenic>
mounir: why?

[07:10:24.0000] <Ms2ger>
Thanks

[07:11:25.0000] <mounir>
Domenic: to prevent orientationchange event handlers to fire before

[07:11:50.0000] <Domenic>
mounir: what is the exact sequence? orientationchange fires, promise resolves, value changes?

[07:11:56.0000] <mounir>
no

[07:12:02.0000] <mounir>
promise resolved

[07:12:06.0000] <mounir>
value changes

[07:12:08.0000] <Domenic>
It seems wierd that lockOrientation().then(() => screen.orientation is wrong)

[07:12:09.0000] <mounir>
event fires

[07:12:22.0000] <Domenic>
ok. why not make it value changes, promise resolved, event fires

[07:15:29.0000] <annevk>
and from the same task, pretty please

[07:15:43.0000] <mounir>
yeah, I guess we could do that

[07:15:54.0000] <annevk>
(promise will learn about it after the event that way, but that seems fine)

[07:15:57.0000] <mounir>
that's going to be a pain to implement...

[07:16:08.0000] <annevk>
mounir: why?

[07:16:13.0000] <Domenic>
:( why are promises so hard to use from C++

[07:16:15.0000] <mounir>
hmm, I would prefer to have the promise being aware of the change before the event

[07:16:28.0000] <mounir>
Domenic: it's not because of promises, it's because of locking

[07:16:35.0000] <Domenic>
oh that's good to hear

[07:16:43.0000] <mounir>
Domenic: promises are not hard to use

[07:16:52.0000] <annevk>
you change the value, resolve the promise, dispatch the event

[07:16:53.0000] <Domenic>
they are hard to use in Blink, apparently.

[07:16:55.0000] <annevk>
in one task

[07:17:03.0000] <annevk>
at the start of the task the event listeners will run

[07:17:11.0000] <annevk>
at the end of the task any registered promise observers will run

[07:17:12.0000] <mounir>
Domenic: I work on Blink...

[07:17:15.0000] <annevk>
(as a microtask)

[07:17:20.0000] <Domenic>
mounir: I'm so confused

[07:17:37.0000] <Domenic>
mounir: also, hi coworker!

[07:17:47.0000] <mounir>
ahaha

[07:18:04.0000] <Domenic>
mounir: https://github.com/slightlyoff/ServiceWorker/issues/223#issuecomment-46138414 is what I was referring to I guess

[07:18:12.0000] <annevk>
the way promise.then() works you can't really notify the promise observers before the event

[07:18:19.0000] <Domenic>
but yes, annevk's spec text will give the observable order you desire

[07:18:21.0000] <mounir>
annevk: I prefer to have the promise fire before so it's clear that the orientationchange happens because of the lock

[07:18:31.0000] <Domenic>
since events are synchronous and promises are asynchronous

[07:18:33.0000] <annevk>
we had this thing about synchronous invocation of promise observers but that died

[07:18:44.0000] <Domenic>
wait, i'm confusing myself

[07:18:59.0000] <annevk>
promise observers are asynchronous

[07:19:09.0000] <Domenic>
annevk, your spec text will result in the wrong observable order, right?

[07:19:09.0000] <annevk>
or whatever the term is

[07:19:14.0000] <Domenic>
/me clearly needs more coffee

[07:19:36.0000] <annevk>
Domenic: event listeners first, then the promise in the end-of-task microtask

[07:19:51.0000] <Domenic>
annevk: right, which is the opposite of what mounir wants

[07:20:00.0000] <annevk>
you can't get what mounir wants

[07:20:04.0000] <Domenic>
yes you can

[07:20:12.0000] <mounir>
annevk: I want ice cream!

[07:20:24.0000] <annevk>
mounir: we have some here ;)

[07:20:26.0000] <Domenic>
resolve p with this.orientation. Upon fulfillment of p, fire event "orientationchange"...

[07:20:54.0000] <annevk>
not upon fulfillment, upon p firing it's observers

[07:21:04.0000] <mounir>
/me dies a little bit inside

[07:21:12.0000] <annevk>
that could work, do we have easy language for that?

[07:21:37.0000] <mounir>
that will be even harder to implement

[07:22:02.0000] <Domenic>
annevk: "upon fulfillment" is the same as "upon p firing it's observers" :) https://github.com/w3ctag/promises-guide#reacting-to-promises

[07:22:05.0000] <annevk>
Domenic is suggesting "value = x; promise.resolve(x); promise.then(dispatchEventForValueChange)"

[07:22:29.0000] <annevk>
which seems like a nice pattern for when you have both promises and events

[07:22:49.0000] <annevk>
but a bit more icky I guess since promises are JavaScript and everything else is C

[07:27:44.0000] <mounir>
could we do something like this:

[07:28:07.0000] <mounir>
when a lock is done we resolve the promise with a value

[07:28:26.0000] <mounir>
when orientation changes, we update screen.orientation and queue a task to fire an event

[07:28:46.0000] <mounir>
that way, we have screen.orientation changed, the promise fires then the event, right?

[07:29:02.0000] <Domenic>
domain question: what is the diffference between "lock is done" and "orientation changes"?

[07:29:15.0000] <mounir>
Domenic: those are different concepts

[07:29:23.0000] <mounir>
that's why implementation-wise it's painful to link them

[07:29:25.0000] <Domenic>
ok. but in the lockOrientation() case, how are they connected?

[07:29:29.0000] <Domenic>
I see

[07:29:44.0000] <mounir>
Domenic: I can change the orientation by turning my phone

[07:29:53.0000] <mounir>
Domenic: I can lockOrientation() twice in a row

[07:30:03.0000] <mounir>
and have an orientationchange that will not resolve the lock

[07:30:07.0000] <mounir>
then the next one will

[07:30:18.0000] <Domenic>
what does "resolve the lock" mean

[07:30:30.0000] <mounir>
Domenic: the lock is applied

[07:30:45.0000] <Domenic>
hmm hmm

[07:31:03.0000] <Domenic>
OK here is a hack that would work, I think

[07:31:15.0000] <Domenic>
And minimizes complexity and coupling

[07:31:58.0000] <Domenic>
lockOrientation(): when lock is done, resolve the promise

[07:32:31.0000] <Domenic>
when orientation changes: change this.orientation, queue a microtask to queue a task to fire an event

[07:32:51.0000] <Domenic>
and define ordering so that "lock is done" happens after "orientation changes"

[07:33:02.0000] <mounir>
hmm

[07:33:24.0000] <mounir>
that's roughly what I said above, isn't it? ;)

[07:33:37.0000] <mounir>
I guess we agree

[07:33:43.0000] <Domenic>
upon re-reading, I think it is :)

[07:33:59.0000] <mounir>
\o/

[07:34:06.0000] <Domenic>
it might be important to say "queue a microtask to queue a task" instead of just "queue a task"

[07:34:19.0000] <Domenic>
I would have to re-check how browser turns are specced to be sure

[07:34:34.0000] <mounir>
I will ask you to review that the PR ;)

[07:34:41.0000] <Domenic>
In either case a non-normative note about the intended ordering should probably be included

[07:34:57.0000] <mounir>
but before that, I shall have some fun and implement this... :)

[07:35:01.0000] <Domenic>
:D

[07:36:17.0000] <mounir>
Domenic, annevk: thanks for your help :)

[07:36:30.0000] <Domenic>
mounir: thanks for caring about getting it right!

[07:52:30.0000] <annevk>
/me is still not sure he grasps the complete flow, will review later

[07:53:07.0000] <annevk>
Domenic: fetch() now no longer handles content codings automatically

[07:53:15.0000] <Domenic>
annevk: sweet

[07:53:17.0000] <annevk>
Domenic: still handles transfer codings and TLS of course

[07:53:46.0000] <annevk>
that was a tough change, but was sorta required anyway to fix progress events

[07:55:25.0000] <annevk>
JakeA: Fetch now has these open issues: structured cloning, and behavior of method

[07:55:57.0000] <annevk>
Domenic: I guess I should also offer some kind of 304-opt-out flag

[07:56:16.0000] <Domenic>
annevk: I guess I should continue along the structured cloning track

[07:56:44.0000] <Domenic>
annevk: modulo writing things up a bit more formally, it seems like cloning promises between realms works fine. time to think about cloning them to disk.

[07:57:08.0000] <annevk>
it's not blocking shipping most likely, but solving it would be good to make sure we don't end up with surprises later

[07:57:29.0000] <annevk>
I liked the message channel solution

[07:57:46.0000] <Domenic>
annevk: re 304, isn't the opt-out just not sending the conditional GET headers?

[07:58:27.0000] <annevk>
Domenic: so UAs add such headers, the opt out would be not getting a 200 back

[07:58:35.0000] <Domenic>
hmm

[07:58:53.0000] <annevk>
there's some magic post-processing going on there

[07:58:56.0000] <Domenic>
node's http client is much more raw in this respect, but that's not necessarily a good thing

[07:59:16.0000] <Domenic>
i.e. http.get() doesn't add any headers you don't pass, and a 304 is just a 304, it doesn't get converted to a 200

[07:59:28.0000] <annevk>
Note that header setting in http://fetch.spec.whatwg.org/#http-network-or-cache-fetch is XXX

[07:59:46.0000] <annevk>
It doesn't set User-Agent, Date, etc.?

[07:59:57.0000] <Domenic>
I think it sets Date since that's required by the spec

[08:00:04.0000] <Domenic>
will check in a minute

[08:00:14.0000] <Domenic>
on the flip side, nobody has yet to my knowledge written a good browser-quality cache for node that handles that stuff automatically, so the raw-ness kind of sucks for a lot of use cases.

[08:00:28.0000] <annevk>
We can't do raw

[08:00:38.0000] <annevk>
But we could come close if that's desired

[08:00:51.0000] <annevk>
Data from node would be great

[08:01:10.0000] <annevk>
Domenic: maybe file a ticket with the data? on SW is fine, I'll link it al together

[08:01:29.0000] <Domenic>
yeah we should have this discussion on a ticket

[08:02:29.0000] <JakeA>
annevk: where are those issues documented?

[08:02:57.0000] <annevk>
JakeA: in the spec

[08:03:01.0000] <annevk>
JakeA: see the red markers

[08:03:07.0000] <annevk>
JakeA: there's also SW issues filed for them

[08:03:17.0000] <annevk>
JakeA: but nobody is looking at old SW issues other than me I think :/

[08:04:18.0000] <annevk>
/me still has to check if the security model with SW and Response/Request is correct

[08:06:40.0000] <JakeA>
annevk: a lot of that is my fault, my time got swallowed with I/O stuff. That's done at the end of this week.

[08:25:55.0000] <annevk>
JakeA: nah man, there's like fifteen people involved in this effort

[08:25:58.0000] <annevk>
JakeA: that video was fun btw

[08:41:17.0000] <Domenic>
http://www.w3.org/TR/encoding/ is not bad, as plagarism goes

[08:42:00.0000] <Domenic>
the only improvements I could think of would be adding language along the lines of "this document is obsolete and is intended for use only by patent lawyers", and making the red box float in the center of the screen, not bottom.

[08:45:21.0000] <gsnedders>
/me thinks someone just needs to come up with some reasonable RF policy for other specs

[08:45:29.0000] <gsnedders>
but the problem is getting people to agree to it

[09:38:49.0000] <annevk>
Hixie: that email :-)

[09:38:51.0000] <annevk>
so true

[09:40:07.0000] <Hixie>
so tired of having to explain this over and over

[09:40:57.0000] <caitp>
explain it again, :)

[09:42:47.0000] <annevk>
Hixie: at some point Domenic will use his magic and capture it all in GitHub repo or some YouTube video

[09:47:10.0000] <jgraham>
The one about certification?

[09:50:08.0000] <annevk>
I guess the one about spec development

[09:50:13.0000] <annevk>
Well, hoping

[09:50:26.0000] <jgraham>
Which one?

[09:53:40.0000] <Hixie>
i created this, with respect to the meta thing yesterday: http://wiki.whatwg.org/wiki/Best_Practices_for_Implementors

[09:57:13.0000] <annevk>
jgraham: I thought you were rhetorical

[09:58:55.0000] <jgraham>
annevk: I'm very confused

[09:59:27.0000] <jgraham>
I honestly don't know which email you were reading :)

[10:00:06.0000] <annevk>
jgraham: ooh, I thought you were making a comment about the fictional GitHub repo or YouTube video

[10:00:16.0000] <annevk>
jgraham: yes this started with that email

[10:00:23.0000] <jgraham>
which email?!

[10:00:30.0000] <annevk>
about certification

[10:00:34.0000] <jgraham>
Oh right

[10:00:35.0000] <jgraham>
Yeah

[10:01:22.0000] <annevk>
Ooh look, a brand-color extension has been proposed

[10:01:25.0000] <jgraham>
So unfortunatley I think there's a >99% chance that email won't change Glenn's opinion and about a 90% chance it will make him think "Hixie is a clown who doesn't understand the requirements of Real Businesses"

[10:02:13.0000] <annevk>
That reminds me of the famous Boeing example that always came up during TPAC

[10:02:18.0000] <Domenic>
Hixie: I liked the email but I think it would have been stronger if you dropped the "pointless" from "pointless certification"

[10:02:23.0000] <Domenic>
oh what Boeing example, sounds fun

[10:02:42.0000] <jgraham>
Yeah, the "pointless" was not helpful

[10:02:43.0000] <Hixie>
Domenic: what is the point of certifying a WebIDL implementation?

[10:02:51.0000] <annevk>
Domenic: that Boeing was using old browsers and that therefore standards were important, it didn't make any sense

[10:03:02.0000] <jgraham>
Certification is not, in itself, pointless

[10:03:06.0000] <annevk>
Domenic: but somehow people loved it and it always got cheers

[10:03:11.0000] <Domenic>
Hixie: no point for us, but for Glenn, or more importantly Glenn's pointy-haired boss, maybe there is one

[10:03:18.0000] <Domenic>
annevk: O_O

[10:03:28.0000] <Hixie>
jgraham: right, i was trying to explicitly distinguish the useful certification from the kind of certification we're talking about here

[10:03:36.0000] <jgraham>
It might not be the optimal strategy for a platform like the web where rapid improvement is valued over interop

[10:03:53.0000] <SamB>
Hixie: isn't the "pointless" basically pointless?

[10:03:53.0000] <jgraham>
Hixie: It sounds like you are describing certification as inherently pointless

[10:03:57.0000] <SamB>
I mean how many certifications aren't?

[10:04:14.0000] <jgraham>
SamB: Well I like to know that my plug won't electrocute me…

[10:04:31.0000] <Hixie>
jgraham: i was just commenting on this specific kind of certification

[10:04:33.0000] <SamB>
oh, so we're including non-software certifications now?

[10:04:50.0000] <SamB>
maybe I should say, non-general-purpose-software certifications

[10:04:52.0000] <Hixie>
SamB: well presumably e.g. a doctor getting certified as "able to doctor" is not pointless

[10:05:16.0000] <jgraham>
SamB: Well the context is really TV people who have a background in hardware where certification is not pointless

[10:05:22.0000] <SamB>
ah

[10:05:24.0000] <Hixie>
SamB: presumably flight software being certified as "able to not crash the rocket into the ground at t=0" is also not pointless

[10:05:48.0000] <SamB>
Hixie: yeah, hense my amendment to include more hyphenated terms ;-)

[10:06:11.0000] <jgraham>
They extrapolate that experience to the web and try to go around making "certified" versions of all the standards

[10:06:42.0000] <jgraham>
Which are usually a snapshot from some time, with a few added features and some more removed and a testsuite that you're supposed to conform to

[10:06:49.0000] <SamB>
Hixie: lets also make sure to mention the obligatory hospital equipment

[10:07:11.0000] <SamB>
like those IV regulators or whatever

[10:08:18.0000] <jgraham>
Certification is useful any time there's a significant harm to something being misrepresented

[10:08:30.0000] <SamB>
yeah

[10:08:31.0000] <jgraham>
Which is pretty often

[10:08:44.0000] <SamB>
but it's not so useful when the software changes every few weeks

[10:09:10.0000] <jgraham>
Right. There is a downside too, which is calcification

[10:09:34.0000] <SamB>
I mean, not unless you can get costs down to where it gets certified every damn release, BEFORE release

[10:09:57.0000] <jgraham>
Anyway for the web it isn't going to happen, because people don't value interop that much

[10:10:03.0000] <SamB>
which seems really unlikely for software that involves a lot of C, C++, and JavaScript

[10:12:58.0000] <Hixie>
i think people on the web value interop very much, it's just that the standards are huuuuuge, and not yet done

[10:13:12.0000] <jgraham>
But they won't ever be "done"

[10:13:12.0000] <Hixie>
and won't be done for a long time, because we started with very poor specs and thus very divergent implementations

[10:13:20.0000] <Hixie>
and it's gonna take a long time for them to converge

[10:13:45.0000] <Hixie>
i think one could imagine a time decades hence where you could freeze a spec before adding more new features, and say, this is what browsers must implement to render today's content

[10:13:48.0000] <SamB>
Hixie: also people keep insisting on new features

[10:13:57.0000] <Hixie>
(i don't think it'd be particularly useful, but that's a separate issue)

[10:14:21.0000] <Hixie>
the problem is right now, and for the forseeable future, there's no chance of the specs being good enough for them to describe exactly what browsers need to do

[10:15:36.0000] <jgraham>
I think you can imagine that time, but I don't think it will happen. There's a tradeoff between interop and evolution, and as long as the former is good enough people always prefer the latter

[10:15:52.0000] <jgraham>
This isn't even a bad thing (it helps keep the platform relevant)

[10:16:27.0000] <Hixie>
yeah it's quite possible that we won't reach this point before the web is irrelevant

[10:16:40.0000] <jgraham>
But it does mean that it's an uphill battle to get people to invest resources in interop, particularly for features that are seen as "Good Enough"

[10:17:07.0000] <SamB>
Hixie: how will the web be irrlevent?

[10:17:48.0000] <annevk>
jgraham: it's still a bit unclear to me how in the current climate I'm allowed to work on improving interoperability on low-level architecture

[10:18:55.0000] <jgraham>
annevk: Because you are effective at selling it as needed for $new_shiny?

[10:19:26.0000] <annevk>
Yeah, that works I guess

[10:19:58.0000] <Hixie>
SamB: something is eventually going to replace the web as the world's information store.

[10:20:03.0000] <annevk>
Took me a while to figure out that was happening though, I was just trying to fix problems

[10:20:28.0000] <SamB>
Hixie: I guess I'm wondering if will have a new name

[10:20:46.0000] <Hixie>
SamB: LCARS, maybe?

[10:21:20.0000] <SamB>
isn't that a HIG and/or toolkit?

[10:21:50.0000] <SamB>
I do like the idea of being able to customize my menus and controls and have them follow me around, though

[10:22:09.0000] <IZh>
Hi. What about sending document loading progress events to parent document? Or at least providing such interface to query the status and percentage of completeness?

[10:22:45.0000] <Hixie>
SamB: "technically" LCARS is an information retrieval system, though people often refer to the UI as LCARS

[10:24:11.0000] <Hixie>
SamB: but e.g. "hey siri, i need the expansion for the abbreviation LCARS" is probably close to where we're headed, and it's not clear that the web need exist in that world, at least not in anything like the form we have today

[10:24:23.0000] <IZh>
Of course, if there is a parent.

[10:25:41.0000] <jgraham>
Hixie: That seems like a very strange statement. I mean you are just talking about a UI, which doesn't say much about the backend information store

[10:27:08.0000] <jgraham>
It seems like the UI you describe is a) only a small subset of all the possible interaction UIs we will require and b) quite implementable on top of the web as it exists

[10:28:36.0000] <SamB>
jgraham: well, what is the backend information store of the web anyway?

[10:29:03.0000] <jgraham>
A collection of hyperlinked text documents, in theory

[10:29:33.0000] <jgraham>
In practice these days, it's closer to a set of hyperlinked applications written in js

[10:30:01.0000] <SamB>
one does hope that we can get something slightly less opaque next time around

[10:30:23.0000] <jgraham>
What makes you think that this would be a a success?

[10:31:50.0000] <jgraham>
It seems like it's the semantic web problem. They assume that people want to know the answers to questions like "what's the expansion of LCARS" whereas people actually want to know things like "are there any interesting things happening today" or "can I find someone to have a relationship with"

[10:32:09.0000] <SamB>
I mean, obviously, there's nothing to stop things being just as opaque as they tend to be now, but it might be nice if that wasn't nearly mandatory for anything of any complexity

[10:32:14.0000] <jgraham>
I guess "siri get me a girlfriend" is a possible future, but it sounds quite dystopian

[10:33:23.0000] <IZh>
jgraham: The future is: Siri, will you be my girlfriend? ;-)

[10:33:34.0000] <SamB>
IZh: that's the future, is it?

[10:34:11.0000] <SamB>
IZh: I assume you aren't hoping that stuff you asked about would work cross-origin

[10:34:21.0000] <caitp>
the dystopia exists, just around the corner there's some kid looking to make millions making some combination tinder/snapchat and marketing it to 13 year olds

[10:34:52.0000] <SamB>
I mean, at least, not without something like CORS saying it's okay

[10:35:07.0000] <annevk>
https://twitter.com/jaffathecake/status/482215293985783810 haha

[10:35:54.0000] <IZh_>
SamB: of course

[10:37:03.0000] <SamB>
jgraham: Hmm, yeah, I guess the "semantic web" people are hoping to bring such transparency to the web we already have, aren't they?

[10:42:36.0000] <Ms2ger>
link rel=script again?

[10:42:57.0000] <Ms2ger>
/me ignores this thread, assumes Hixie will close it out quickly

[10:43:18.0000] <SamB>
why would anyone think that might be useful?

[10:43:39.0000] <Ms2ger>
It's consistent!

[10:44:28.0000] <caitp>
they're right, it would be better for everyone to start shrinking the language rather than growing it

[10:44:45.0000] <Hixie>
jgraham: yeah, i wouldn't be surprised if it was built on top of the web as we know it

[10:45:10.0000] <Hixie>
jgraham: but simultaneously, large parts of it might become irrelevant (e.g. navigation, scripting)

[10:45:17.0000] <SamB>
Hixie: it does seem more likely than building it on top of Emacs, yes

[10:45:18.0000] <Hixie>
jgraham: anyway, this is all conjecture

[10:50:42.0000] <Ms2ger>
Most often use for tag <script> is to include external script through

[10:50:43.0000] <Ms2ger>
<script src="somecdn.example/jquery.js">, or alike. May be we could add

[10:50:43.0000] <Ms2ger>
rel="script" to <link> tag with same behaviour as <script> with src.

[10:50:43.0000] <Ms2ger>
It's similiar to stylesheets: we can link external stylesheets via <link>

[10:50:43.0000] <Ms2ger>
and include CSS directly on page with <style> tag.

[10:50:47.0000] <Ms2ger>
SamB, ^

[10:51:33.0000] <annevk>
JakeA: https://github.com/slightlyoff/ServiceWorker/issues/347

[10:51:49.0000] <annevk>
Domenic: shall I file an issue on that header thing?

[10:52:10.0000] <caitp>
> remove primitives from the language, simplify it >> allow developers to grow the language with custom elements >>> eventually profit

[10:52:27.0000] <SamB>
Ms2ger: so basically they have hobgoblin-infested, small minds?

[10:52:41.0000] <Ms2ger>
No comment

[10:52:44.0000] <SamB>
oh wait, that wouldn't be an example of false consistancy though would it

[10:52:52.0000] <annevk>
I once thought that would be cool

[10:53:05.0000] <Ms2ger>
I probably did too

[10:53:07.0000] <SamB>
just "too late" realyl

[10:53:11.0000] <annevk>
Because then you could do Link: <script.js>; rel=script

[10:53:15.0000] <Ms2ger>
/me liked XHTML2 at one point

[10:53:29.0000] <annevk>
Making something like http://annevankesteren.com/robots.txt even more impressive

[10:53:37.0000] <annevk>
XBL, alas

[10:53:48.0000] <annevk>
Also, separation of script and markup

[10:54:02.0000] <Ms2ger>
"Huge line for a talk about mobile web performance. The mobile web is not dead! #io14"

[10:54:21.0000] <Ms2ger>
Sounds like people want to know if their code is going to be removed

[10:54:41.0000] <SamB>
is the mobile web somehow different from the normal web?

[10:54:52.0000] <caitp>
it's the one people actually use

[10:55:17.0000] <SamB>
well, I mean, my dumbphone's browser is some kind of sick joke

[10:55:53.0000] <SamB>
but I was under the impression that I was using more-or-less the same web on my aging desktop as everyone else, only much, much slower

[11:01:43.0000] <Domenic>
JakeA: why is my face there

[11:01:47.0000] <Domenic>
annevk: yes please

[11:02:00.0000] <caitp>
unlike the desktop, where you can do pretty much anything without any significant performance hits, people end up optimizing web apps for a specific handset, because maybe css doesn't do a good enough job so lets emulate gradiants in a canvas or invent some idea that flat uis are attractive or something --- and then once all of that is done they say "no lets not make this a web app, lets make this a packaged app so we

[11:02:01.0000] <caitp>
 can use native APIs because webRTC or geolocation don't exist yet", etc

[11:02:11.0000] <caitp>
it ends up being pretty different

[11:06:14.0000] <annevk>
Domenic: https://github.com/slightlyoff/ServiceWorker/issues/348

[11:06:41.0000] <Domenic>
annevk: sweet, queued for tonight or tomorrow.

[12:13:52.0000] <annevk>
marcosc: why is that not a wiki page?

[12:14:13.0000] <annevk>
GH repo seems overkill

[12:24:51.0000] <Domenic>
honestly sending pull requests is more convenient than registering for that wiki

[12:25:03.0000] <Domenic>
plus you get issue tracking

[12:31:36.0000] <marcosc_>
annevk, what Domenic said

[13:23:44.0000] <Hixie>
smaug____: iirc the idea is that if the browser wants to make navigating to an image bring up an image editor, or whatever, then it's not really our place to say that's not valid

[13:35:59.0000] <IZh>
In the section "Submit Button state" there is the fingerprint icon. How Submit button could be used to fingerprint a user? There are no additional notes about it in this section.

[13:36:40.0000] <IZh>
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#submit-button-state-%28type=submit%29

[13:40:41.0000] <IZh>
Hixie?

[13:41:27.0000] <Domenic>
interesting question

[13:41:31.0000] <Hixie>
check the value of the .value idl attribute when the element has no value content attribute

[13:41:49.0000] <Hixie>
(gives you a few bits, but they're redundant with the UA string)

[13:41:58.0000] <Hixie>
(and the language)

[13:43:31.0000] <IZh>
Hixie: Thanks for explanation. May be few words should be added about it. At least pointing to .value attribute.

[13:43:41.0000] <Hixie>
maybe. file a bug :-)

[13:44:07.0000] <Domenic>
why would the .value attribute matter... i don't get it...

[13:44:45.0000] <Hixie>
try it :-)

[13:46:20.0000] <Domenic>
it's "Submit Query" in IE, but "" in Chrome and Firefox

[13:46:36.0000] <Domenic>
is this just a matter of fingerprinting via some browsers not following the spec?

[13:47:09.0000] <Domenic>
it seems like the value of .value is unspecced for submit buttons

[13:48:05.0000] <IZh>
Filed. :-)

[13:49:17.0000] <Hixie>
Domenic: it's specced to be UA-dependent, which is the fingerprint vector

[13:49:29.0000] <Hixie>
(i'm surprised you get "")

[13:49:43.0000] <Domenic>
Hixie: how I read the spec was that the label is UA-dependent, as long as .value was unset

[13:49:49.0000] <Domenic>
i didn't see a spec for .value

[13:50:08.0000] <IZh>
Why the bug filing form has no Author field? ;-))

[13:50:32.0000] <Domenic>
Hixie: actually following the link to "default" it seems like the spec says it should be ""

[13:50:39.0000] <IZh>
May be in expanded version.

[13:51:17.0000] <Hixie>
IZh: if you're logged into the spec annotation system, the author is automatically entered

[13:51:28.0000] <IZh>
Hixie: Oh! Good.

[13:52:03.0000] <Hixie>
Domenic: hm, you're right. I guess it's actually the button width that you'd have to look at to get the fingerprinting bits, not the attribute value

[13:52:25.0000] <Domenic>
Hixie: ah right, that'd do it. makes sense.

[13:56:01.0000] <IZh>
Revalidated the spec. Only 3 minor errors: still has one broken link to W3C's css-font-load-elements and 2 accessibility errors about iframes without "title" attributes.

[13:56:39.0000] <TabAtkins>
Hixie: Ah, if you have a link to font-load-events, switch it font-loading.

[13:57:09.0000] <Hixie>
there's a bug on that i think

[13:57:31.0000] <Hixie>
sorry about not doing any fixes in recent days. i'm working on my pipeline.

[13:57:35.0000] <TabAtkins>
Np.

[13:57:42.0000] <Hixie>
once that's done hopefully my productivity will be higher.

[13:57:51.0000] <Hixie>
(than before, i mean, not than now, where it's zero!)

[14:02:38.0000] <MikeSmith>
IZh: 2 accessibility errors about  iframes without "title" attributes

[14:02:40.0000] <MikeSmith>
?

[14:03:01.0000] <MikeSmith>
IZh: which checker reports errors about those?

[14:03:17.0000] <IZh>
CSE HTML validator.

[14:03:26.0000] <Hixie>
an overzealous one, presumably :-)

[14:04:27.0000] <IZh>
It says: [70] The "iframe" element requires the "title" attribute to label the frame, describe the contents, and facilitate frame identification so users can determine which frame to enter. Frame titles must be meaningful. For example, "Table of Contents", "Where the content is displayed", and "Sitewide navigation bar" (or simply "Navigation"). Visit http://www.w3.org/TR/WCAG20-TECHS/H64 for...

[14:04:29.0000] <IZh>
...more information. [A, 2.4.1; H64] [A, 4.1.2; H64]

[14:05:36.0000] <MikeSmith>
IZh: "users can determine which frame to enter"? for an iframe?

[14:06:17.0000] <Hixie>
many ATs have a pretty poor user experience around iframes

[14:06:30.0000] <Hixie>
they basically offer them as black boxes that the user can chose to enter or not, given the title

[14:06:47.0000] <MikeSmith>
oh

[14:07:22.0000] <MikeSmith>
that does sound bad

[14:07:25.0000] <Hixie>
(instead of doing what the HTML spec basically requires, which is to treat them as transparent transclusions)

[14:07:30.0000] <MikeSmith>
yeah

[14:08:05.0000] <Hixie>
careful, criticising ATs means you hate disabled users

[14:08:07.0000] <MikeSmith>
man that has to be really annoying for the users

[14:08:42.0000] <IZh>
Anyway, there are 2 iframes without titles in the spec.

[14:09:22.0000] <MikeSmith>
Hixie: I love everybody

[14:09:44.0000] <MikeSmith>
IZh: nobody in real universe puts titles on iframes

[14:10:22.0000] <IZh>
MikeSmith: No problem. :-)

[14:11:04.0000] <MikeSmith>
I wonder what NVDA does with iframes. I mean, if it also does the "offer them as black boxes that the user can chose to enter or not, given the title" thing

[14:11:15.0000] <MikeSmith>
I would hope at least NVDA doesn't do that

[14:11:26.0000] <MikeSmith>
or Voiceover

[14:18:41.0000] <IZh>
"Internal Error: Oops. That was not supposed to happen. A bug manifested itself in the application internals. Unable to continue. Sorry. The admin was notified." I have crashed the validator.nu ;-)

[14:22:33.0000] <MikeSmith>
IZh: you didn't crash it :)

[14:22:42.0000] <MikeSmith>
that's just an uncaught exception

[14:22:52.0000] <MikeSmith>
but thanks for finding it

[14:23:10.0000] <MikeSmith>
do you have a URL for a doc that I can test with, to reproduce that

[14:23:14.0000] <MikeSmith>
?

[14:23:20.0000] <MikeSmith>
or a minimal test case

[14:23:24.0000] <IZh>
It can't handle port nombers >= 65536 ;-)

[14:23:48.0000] <IZh>
http://validator.whatwg.org:65536/

[14:24:04.0000] <MikeSmith>
ah that may be in the library code that we use for checking URLs

[14:24:14.0000] <MikeSmith>
/me checks

[14:28:07.0000] <MikeSmith>
IZh: java.lang.NullPointerException        at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:721)

[14:28:42.0000] <IZh>
Somebody has to check port number. :-)

[14:30:39.0000] <IZh>
Also one probably potential security issue: When you validating http://localhost/ it says 404. But not access denied or so. I mean that the validator could be probably used for scanning internal network.

[14:31:07.0000] <IZh>
Probably validator should ban access to private IP ranges.

[14:31:57.0000] <IZh>
Or I could try to validate some web-server status page or so (by enabling "Show Source"), if any.

[14:33:41.0000] <IZh>
And there is one way to abuse the validator: recursion. ;-) You can ask the validator to validate the results of validating the results of validating of some page. :-)

[14:34:08.0000] <IZh>
Of course, with enabled "Show Source" ;-)

[14:35:15.0000] <IZh>
I think there should be a restriction on validating URL when validating itself.

[14:36:51.0000] <MikeSmith>
IZh: please file bugs

[14:37:19.0000] <MikeSmith>
I've talked about some of these things with Henri already and we didn't have any clever ideas

[14:38:21.0000] <IZh>
MikeSmith: Where is the validator's bug reporting page?

[14:38:35.0000] <IZh>
Found it.

[14:38:51.0000] <MikeSmith>
but I think we're essentially not doing anything different than you could do with a browser or with lynx or some other http UA

[14:46:56.0000] <IZh>
One more internal error. Select "File Upload" but do not provide any file, enable "Show Outline" and click Validate ;-)

[14:51:30.0000] <IZh>
I think it can't make outlines for empty documents.

[14:52:54.0000] <MikeSmith>
oh that's kinda silly

[14:53:01.0000] <MikeSmith>
I guess I should fix that

[14:54:53.0000] <MikeSmith>
hmm validator.w3.org/nu doesn't have that issue

[14:55:09.0000] <MikeSmith>
/me checkes qa-dev.w3.org:8888

[14:56:57.0000] <IZh>
Because it forbids to submit the form without file.

[14:57:30.0000] <IZh>
But it has the port number issue.

[14:58:31.0000] <MikeSmith>
can't reproduce it at http://qa-dev.w3.org:8888

[14:58:54.0000] <IZh>
8888 is less than 65536 ;-)

[14:58:56.0000] <MikeSmith>
which is built from  the latest  soruces

[14:59:09.0000] <IZh>
Try 65536 or greater port number

[14:59:18.0000] <MikeSmith>
IZh: I mean the outline problem

[14:59:30.0000] <IZh>
Try on http://validator.nu/

[14:59:39.0000] <MikeSmith>
and I mean I have an instance of the validator at http://qa-dev.w3.org:8888

[15:00:03.0000] <MikeSmith>
IZh: yeah I understand but I don't have access to the error logs for http://validator.nu/

[15:00:08.0000] <IZh>
Hmmm... No error.

[15:00:11.0000] <MikeSmith>
whereas I do for http://qa-dev.w3.org:8888

[15:00:14.0000] <MikeSmith>
yeah

[15:00:39.0000] <MikeSmith>
the code running at http://validator.nu/ is a little behind the current sources

[15:00:50.0000] <MikeSmith>
so maybe I made a fix in the meantime, I dunno

[15:00:54.0000] <IZh>
I see.


2014-06-27
[00:06:36.0000] <annevk>
Discussing Vats: https://github.com/dslomov-chromium/ecmascript-structured-clone/issues/7

[00:06:46.0000] <annevk>
This wakes me up in the morning :-)

[00:19:16.0000] <MikeSmith>
I didn't even know there was a plan to specify structured clone in the es spec

[00:19:23.0000] <MikeSmith>
or if I did I forgot

[00:19:33.0000] <MikeSmith>
/me catches the clue train late

[00:22:50.0000] <MikeSmith>
annevk: so where do "worlds" fit into this? are "worlds" just an implementation thing?

[00:23:18.0000] <annevk>
I'm not sure what a world is.

[00:23:32.0000] <annevk>
But objects live in a realm and they can freely move to other realms, as long as they remain within the same vat.

[00:23:40.0000] <annevk>
If they want to leave the vat, they need to cloned or transfered.

[00:23:47.0000] <MikeSmith>
ah

[00:23:49.0000] <annevk>
be*

[00:24:22.0000] <annevk>
(Of course, they can also be cloned or transfered within the same vat.)

[00:33:38.0000] <MikeSmith>
annevk: so "worlds" I meant as in "isolated worlds" at https://developer.chrome.com/extensions/content_scripts#execution-environment

[00:33:57.0000] <annevk>
MikeSmith: that's different

[00:34:04.0000] <MikeSmith>
yeah I can see that now

[00:34:09.0000] <MikeSmith>
after reading it

[00:34:14.0000] <annevk>
"worlds" are more like views

[00:34:28.0000] <MikeSmith>
ah yeah

[03:05:10.0000] <gsnedders>
I'm pretty sure I'm missing something in ES6. ES5 defined for-in st deleting an unvisited property in the body caused it to never be visited; as far as I can tell, it would be visited per ES6.

[08:55:19.0000] <annevk>
Domenic: why does something with Symbol.iterator also have forEach(); convenience?

[08:55:36.0000] <Domenic>
annevk: dumb reasons, like making polyfills more usable

[08:55:50.0000] <annevk>
Domenic: so maybe we should not copy that in DOM?

[08:56:30.0000] <Domenic>
depends on the case ... i feel the pattern has been established for map and set-like things, i.e. having has/get/delete without forEach would be strange

[08:56:47.0000] <Domenic>
but for e.g. NodeWalkers I wouldn't copy it

[08:57:02.0000] <Domenic>
or other "exotic" iterables that aren't just array-like or map/set like

[08:58:18.0000] <annevk>
FormData, and such are like that, but they don't have any iteration support yet

[08:59:01.0000] <Domenic>
yeah, i mean, it doesn't hurt to have it, it's just IMO stupid

[09:01:25.0000] <annevk>
I should add a comment to the IDL iterables bug that it takes a position on this

[10:19:04.0000] <TabAtkins>
annevk: Yeah, until iterators are a real thing, forEach is needed.  I made sure to add it to FontFaceSet when I finally removed [SetClass].

[10:19:17.0000] <TabAtkins>
But agree that we shouldn't use it in the future.

[12:15:55.0000] <annevk>
Domenic: using e.g. http://software.hixie.ch/utilities/cgi/test-tools/echo you can see what browsers include in fetches

[12:31:31.0000] <annevk>
Domenic: hope you understand about asking you to file a bug on IDL; don't really want to start fighting this on a per API basis

[12:31:47.0000] <annevk>
(or defining the whole thing in prose, that'd take ages and would contain so many errors)

[12:32:06.0000] <Domenic>
annevk: I just think it's important not to have wrong spec text there in the meantime, and it's actually a good thing to define things correctly ahead of time and then just copy them over to IDL.

[12:32:10.0000] <annevk>
(aside from the fact that bz et al would refuse to implement)

[12:32:38.0000] <annevk>
in the maintime we need something we can implement and ship

[12:32:42.0000] <annevk>
mean*

[12:33:36.0000] <Domenic>
why can't you implement and ship the correct semantics

[12:33:50.0000] <Domenic>
literally just say "consult the existing algorithm you've already implemented for Map"

[12:34:41.0000] <annevk>
because ES != DOM on many levels in implementations today

[12:34:54.0000] <annevk>
not really sure we need to go into this discussion again, maybe bz is up for it if you ask nicely

[12:35:07.0000] <Domenic>
i don't see why the spec has to be incorrect to accomodate that

[12:35:11.0000] <Domenic>
the spec should be correct

[12:35:22.0000] <Domenic>
if implementations can't implement that correctly until after Q3 or whatever, that's fine

[12:35:29.0000] <Domenic>
but it's then a bug in the implementations that can be tracked

[12:35:37.0000] <Domenic>
and not the spec telling them to be wrong

[12:36:59.0000] <annevk>
I'm happy to update the spec once IDL provides better hooks, I'm not going to define this whole object in terms of ES and then let implementers figure out what binding to use

[12:38:20.0000] <Domenic>
It is frustrating that you are more focused on layering on top of IDL than on specifying correct semantics :(

[12:38:42.0000] <Domenic>
implementer concerns should be implementer concerns

[12:39:27.0000] <annevk>
I guess I'm more of a pragmatist

[12:40:22.0000] <Domenic>
So what would solve this. I will pull request WebIDL right now if that will fix it.

[12:40:44.0000] <annevk>
And I would be happy to correct the semantics if that were straightforward, but it's an order of magnitude more complicated at the moment and it's unlikely any of that work will actually be used

[12:41:18.0000] <Domenic>
It seems like you'd want some kind of AddMapInputs(sequenceArg, this, "set") specified in WebIDL

[12:41:27.0000] <annevk>
Yes, fixing IDL would solve this

[12:41:49.0000] <annevk>
Note that it should be this.append, not set

[12:41:50.0000] <Domenic>
OK. I will pull request that to WebIDL if you don't want to put it into Fetch. Is that AddMapInputs good?

[12:41:58.0000] <Domenic>
OK sure you'd pass "append"

[12:42:45.0000] <annevk>
Many specifications will need this, that's why I'm kicking it up a layer as "not my problem"

[12:43:22.0000] <annevk>
I don't really want to take responsibility for IDL at this point

[12:43:29.0000] <Domenic>
Right now only one specification does

[12:44:57.0000] <annevk>
There have been many requests for "open-ended dictionary"

[12:45:20.0000] <annevk>
And this is not the first place there's nested sequences either I think

[12:45:43.0000] <Domenic>
This feels similar to adding something in your code in one file that needs it, and later extracinting it out into a utils package

[12:45:43.0000] <annevk>
bz can probably reference a few things

[12:45:56.0000] <Domenic>
Instead of just introducing buggy code

[12:46:20.0000] <Domenic>
But whatevs, if introducing buggy code is just a tactic for getting me to write the correct code in the utils package, that works too

[12:46:34.0000] <Domenic>
Also: WebIDL is generated from XML @_@

[12:46:47.0000] <annevk>
I did check this particular IDL with you beforehand if you remember

[12:46:55.0000] <Domenic>
Sure, the arguments were fine

[12:47:02.0000] <Domenic>
The processing of them is not

[12:47:42.0000] <SamB>
WebIDL is generated from XML?

[12:47:46.0000] <annevk>
Per bz there's a difference

[12:47:46.0000] <SamB>
that sounds counterproductive

[12:47:57.0000] <SamB>
it's like RNG Compact, only backwards!

[12:48:09.0000] <SamB>
maybe you meant something other than what it sounded like

[12:48:18.0000] <Domenic>
There is an XSLT file and a makefile (yay, fails on Windows)

[12:48:33.0000] <SamB>
you must be using the wrong make

[12:48:38.0000] <SamB>
maybe try the other one

[12:48:52.0000] <annevk>
Domenic: but yeah, writing the utils package is significantly more low-level and I'd rather not have to write that code

[12:48:53.0000] <SamB>
or maybe you forgot to put xsltproc in PATH

[12:49:06.0000] <annevk>
Domenic: that's why I've filed a ton of bugs on IDL hoping someone would fix them

[12:49:08.0000] <Domenic>
SamB: can't tell if you're trolling or just have never used Windows

[12:49:27.0000] <SamB>
well, I can't remember which of the two makes that ship with MinGW are actually useable

[12:49:28.0000] <annevk>
Domenic: there's only so many things I can tackle

[12:49:30.0000] <Domenic>
annevk: sure. it's just sucky that instead there's bugs infesting specs in the meantime.

[12:49:53.0000] <SamB>
and "forgot to put xsltproc in PATH" could be considered trolling

[12:50:09.0000] <annevk>
Domenic: as far as I can tell the way it's written now can be migrated to something less throwy later easily

[12:50:25.0000] <annevk>
Domenic: there's a transition path of sorts to a saner future

[12:50:48.0000] <SamB>
Domenic: so, I guess you probably meant the *spec*?

[12:50:56.0000] <SamB>
rathert than just web IDL code in general

[12:51:12.0000] <SamB>
(if you count IDL as code)

[12:51:15.0000] <annevk>
Domenic: also, <3

[12:52:13.0000] <SamB>
/me tries to imagine the idiot who writes his Relax NG in the XML syntax, only to use trang to convert it into the compact syntax that Emacs/nxml/rng-validate can use

[12:52:30.0000] <annevk>
Domenic: so btw, if you do actually think the IDL is fine and it really is the prose that's broken, that would be an easy fix, but I was doubting that to be the case, hence the pushback

[12:54:32.0000] <Domenic>
annevk: yeah, it could be migrated I think, it's true. I should calm down.

[12:54:36.0000] <annevk>
Domenic: also, I'm fairly happy with tweaking things over time until all the details are correct; I'd rather have the current algorithm and get that shipped and then improve than a half-broken IDL/JS mix in the spec that nobody is sure what to do with

[12:54:36.0000] <Domenic>
SamB: yes indeed.

[12:54:42.0000] <Domenic>
annevk: <3 indeed :)

[12:55:18.0000] <Domenic>
annevk: I think the prose could be fixed pretty easily. Just say something like "call `this.append(header[0], header[1])` and rethrow any exceptions essentially.

[12:57:17.0000] <TabAtkins>
Is this about something like .extend() for HeaderMap?

[12:57:34.0000] <TabAtkins>
(Map really needs .extend(), btw.)

[12:57:39.0000] <Domenic>
Nah it's about new HeaderMap(iterableOfTwoElementArrays) and how the current spec text does not match Map(iterableOfTwoElementArrays)'s behavior

[12:57:40.0000] <TabAtkins>
(I use it regularly in Python.)

[12:57:46.0000] <TabAtkins>
Ah.

[12:57:50.0000] <Domenic>
Map and set are anemic

[12:57:50.0000] <annevk>
s/HeaderMap/Headers/

[12:58:03.0000] <Domenic>
I really want the bind operator so we can stop blocking on the committee for good standard library

[12:58:12.0000] <TabAtkins>
Indeed.

[12:58:14.0000] <Domenic>
and still get something method-ish enough to be pleasant

[12:58:42.0000] <Domenic>
I will try to get the ball rolling in time for next TC39

[12:59:41.0000] <TabAtkins>
Sweet, thanks.

[13:00:00.0000] <TabAtkins>
/me likes the look of myMap::extend(foo).

[13:00:01.0000] <annevk>
I'd like to talk vats with Mark Miller some day, just for fun

[13:00:18.0000] <Domenic>
haha

[13:00:23.0000] <Domenic>
*I* think it would be fun

[13:00:33.0000] <annevk>
I was not sarcastic :-)

[13:00:34.0000] <Domenic>
I think other people would warn you off

[13:01:40.0000] <TabAtkins>
Hm, okay, so similar topic. I need to add a constructor for FontFaceSet.  FFS is currently defined as storing its stuff in an internal Set. Can I just say that it passes its arguments to the Set constructor and uses the result as its internal set?

[13:01:41.0000] <annevk>
Gecko actually has vats of sorts thanks to bholley

[13:01:57.0000] <annevk>
With some silly stuff for document.domain

[13:02:14.0000] <annevk>
It's really quite cool and a lot nicer than the hacks Blink et al have

[13:02:15.0000] <Domenic>
TabAtkins: in-ter-esting...

[13:02:33.0000] <TabAtkins>
I do that for all the Set methods it exposes - just epxlicitly delegate to the internal set and return what it returns.

[13:02:35.0000] <Domenic>
Probably not, because you want argument validation?

[13:02:52.0000] <Domenic>
(or coercion, rather)

[13:02:54.0000] <TabAtkins>
Domenic: I have to write the argument list, yeah, but that's allt he validation I need I think.

[13:03:03.0000] <TabAtkins>
It'll just take an iterable of FontFace objects.

[13:03:10.0000] <TabAtkins>
No coercion happening.

[13:03:12.0000] <Domenic>
Hmm yeah that'd probably do it

[13:03:21.0000] <Domenic>
(right, coercion is for strings)

[13:03:36.0000] <annevk>
Yeah, all the multimap stuff I've designed is also using an internal multimap of sorts

[13:03:57.0000] <Domenic>
TabAtkins: yeah I'm pretty sure that would work.

[13:04:00.0000] <TabAtkins>
/me still isn't sure how to write the return value of entries/values.

[13:04:10.0000] <annevk>
I should probably define an actual conceptual multimap to make it clearer how FormData/URLSearchParams/Headers are all kind of the same

[13:04:45.0000] <TabAtkins>
annevk: Would be nice, yes.

[13:04:54.0000] <Domenic>
TabAtkins: `any` seems good ;)

[13:04:59.0000] <Domenic>
/me doesn't really believe in IDL return values

[13:05:14.0000] <annevk>
Reportedly they're good for JIT

[13:05:15.0000] <TabAtkins>
Domenic: I'm currently copying the MDN text and using "Iterator".

[13:05:25.0000] <TabAtkins>
They're informative for the author, at least.

[13:05:46.0000] <Domenic>
Yeah yeah, fine guys, be practical. I'm going to sit over here in castle theoretical purity and be self-satisfied, mmk?

[13:06:13.0000] <TabAtkins>
Interesting that Castle Theoretical Purity is the one arguing for *less* type information.

[13:06:55.0000] <annevk>
Well ES6 doesn't have types, so

[13:07:00.0000] <annevk>
:p

[13:08:31.0000] <Domenic>
heh, yeah, ES's room in Castle Theoretical Purity is not often visited by other residents.

[13:30:02.0000] <TabAtkins>
annevk, Domenic: Should I define the signature of the FFS constructor as (sequence<FontFace>) or something? Or is there a better way to indicate "iterable of FontFace objects"?

[13:30:23.0000] <Domenic>
I think that's the right way to go. I think all iterables are convertable into sequences

[13:30:37.0000] <Ms2ger>
sequence argument is "iterable"

[13:30:50.0000] <Ms2ger>
Not sure if the spec has been updated to say that yet, though

[13:30:52.0000] <TabAtkins>
Cool.

[13:31:12.0000] <TabAtkins>
The fact that arguments and attributes/return values use the same names but mean different things is weird.

[13:32:09.0000] <Ms2ger>
I don't think they "mean different things", but not going to start that again

[13:32:45.0000] <TabAtkins>
"sequence<Foo>" means "iterable of Foos" in argument lists, but explicitly "Array of Foos" in attributes/return values.

[13:33:13.0000] <Ms2ger>
No, it means "sequence of Foos" in both cases

[13:33:45.0000] <Ms2ger>
And there's a function jsval -> sequence<Foo>, and one sequence<Foo> -> jsval

[13:34:43.0000] <TabAtkins>
I can pass in an iterator to the former, but can't ever get an iterator out of the latter; I have to do something different for that.

[13:35:10.0000] <Ms2ger>
Yes?

[13:35:42.0000] <SamB>
TabAtkins: can't you get any iterable type out of the latter?

[13:35:50.0000] <SamB>
depending on the whims of the implementor?

[13:35:54.0000] <TabAtkins>
SamB: No.

[13:36:17.0000] <TabAtkins>
Giving an attribute the type "sequence<Foo>" means it'll be an Array of Foos.

[13:36:19.0000] <SamB>
well it seems stupid if it's just another name for an Array

[13:36:36.0000] <TabAtkins>
Welcome to legacy naming problems!

[13:36:39.0000] <Ms2ger>
(Note that those functions don't precisely correspond to argument/return value; sometimes it's the other way around)

[13:36:44.0000] <TabAtkins>
Remember that WebIDL wasn't JS-specific originally.

[13:36:45.0000] <SamB>
how is sequence<Foo> legacy

[13:36:51.0000] <SamB>
TabAtkins: oh

[13:36:56.0000] <Ms2ger>
SamB, why invent a new name for it?

[13:37:07.0000] <Ms2ger>
It's conceptually a sequence for both

[13:37:21.0000] <TabAtkins>
Because it's way clearer to read "Array<Foo>" than to have to remember that "sequence" in WebIDL means Array in JS.

[13:37:34.0000] <TabAtkins>
The conceptual part of it isn't important; you actually want to know what type it is.

[13:37:38.0000] <Ms2ger>
I wouldn't mind calling them both Array

[13:37:52.0000] <SamB>
that sounds wrong also

[13:37:56.0000] <Ms2ger>
I disagree that concepts are not important

[13:38:01.0000] <TabAtkins>
Calling the argument one Array would be wrong, since it only actually uses iterableness.

[13:38:14.0000] <Ms2ger>
It converts into an array

[13:38:19.0000] <Ms2ger>
Anyway

[13:38:20.0000] <SamB>
does it have to?

[13:38:30.0000] <Ms2ger>
Yes

[13:38:46.0000] <TabAtkins>
SamB: Doesn't really matter; that parts hidden away behind machinery. Point is that it does one iteration over the object.

[13:38:47.0000] <Ms2ger>
Well, it does if you do anything side-effecty in the loop

[13:39:05.0000] <SamB>
TabAtkins: yeah, I know, how can it "have to" do something you can't observe anyway?

[13:39:58.0000] <Ms2ger>
For example, node.append(node, {toString... }) won't append the first argument before evaluating the toString

[13:40:09.0000] <SamB>
gotcha

[13:40:11.0000] <Ms2ger>
So conceptually, it gathers them into an array first

[13:40:49.0000] <Ms2ger>
(Well, that's variadic arguments, but same thing for sequences)

[13:43:53.0000] <TabAtkins>
Yeah, it does a data-validation/conversion pass over all the argument before operating on them.  Whether they end up stored in an Array or not is an unknowable aspect. ^_^

[13:44:37.0000] <Ms2ger>
Sure

[13:44:46.0000] <Ms2ger>
I'm not talking about implementation here

[13:45:02.0000] <Ms2ger>
All I'm saying is that *conceptually*, it gathers them into an array first

[13:45:20.0000] <Ms2ger>
If you understand that, you understand the behaviour

[13:45:29.0000] <Ms2ger>
Even if the actual implementation is unknowable

[13:45:45.0000] <TabAtkins>
Right. But using that to say that the argument type should say "Array" is still wrong, because we don't care whether you pass an Array or not.

[13:45:47.0000] <SamB>
so an array, not an Array

[13:46:04.0000] <TabAtkins>
We just care about the iterable aspect, and so that's what should be reflected in the name of the argument type, ideally.

[13:46:18.0000] <Ms2ger>
So how about callbacks?

[13:46:29.0000] <TabAtkins>
How about them?

[13:46:44.0000] <Ms2ger>
If you have a callback function that takes a sequence<T>, you're getting an array, not an unknowable iterable

[13:47:13.0000] <TabAtkins>
Hm, interesting point.

[13:47:15.0000] <SamB>
that could explode, you know

[13:47:39.0000] <TabAtkins>
SamB: How?

[13:47:47.0000] <Ms2ger>
Boom?

[13:47:59.0000] <Domenic>
this yak is getting shaaaaaaved

[13:48:33.0000] <Domenic>
right now i'm installing a package manager so i can get winpthreads so i can get libxml2 so i can get libxslt so i can make the webidl i wrote

[13:48:42.0000] <SamB>
so, I mean, what do you do if you really did want to just take an iterable so it's okay if the sequence is longer than any available memory chunk?

[13:48:46.0000] <TabAtkins>
Domenic: Have you tried not using Windows?

[13:49:00.0000] <Ms2ger>
SamB, you still get an Array

[13:49:00.0000] <SamB>
Domenic: which manager?

[13:49:00.0000] <Domenic>
I fight for the users!

[13:49:22.0000] <SamB>
Ms2ger: surely it's possible to get an iterable which you can iterate at your leisure somehow

[13:49:37.0000] <TabAtkins>
That said, if you now have libxml2, you might have the ability to install Bikeshed and make it work.

[13:49:43.0000] <TabAtkins>
If you do so, PLEASE WRITE IT DOWN AND SEND IT TO ME.

[13:49:48.0000] <TabAtkins>
I'd love install instructions for windows.

[13:49:57.0000] <SamB>
you would probably not love them

[13:50:11.0000] <Ms2ger>
Ha

[13:50:37.0000] <TabAtkins>
Man, even the Linux instructions aren't great.

[13:50:46.0000] <TabAtkins>
Installing OSS is hard.

[13:50:51.0000] <Ms2ger>
SamB, well, the browser is always going to give you an array; it's not going to analyze your code to check if it needs an array, and give you an iterable otherwise

[13:50:59.0000] <SamB>
TabAtkins: why isn't it "apt-get install bikeshed" yet

[13:51:16.0000] <TabAtkins>
Ms2ger: I think he meant "surely there's some way to indicate in WebIDL that the callback shoudl be passed an iterable".

[13:51:26.0000] <TabAtkins>
SamB: Because that's crazy times.

[13:51:27.0000] <SamB>
Ms2ger: I was figuring you could write some different IDL to get it give you the iterable

[13:51:36.0000] <Ms2ger>
Oh, on the IDL side

[13:51:48.0000] <Ms2ger>
That sounds like a pain

[13:52:08.0000] <SamB>
could be

[13:52:25.0000] <SamB>
are you imagining monster stack traces?

[13:54:07.0000] <Ms2ger>
Just monster implementation :)

[13:54:25.0000] <Ms2ger>
Maybe it could work, but it feels funny

[13:54:28.0000] <Ms2ger>
On another note

[13:54:41.0000] <Ms2ger>
"A form control that is disabled must prevent any click events that are queued on the user interaction task source from being dispatched on the element." is a nice COMEFROM

[13:54:43.0000] <TabAtkins>
Seems not too crazy to return an iterator over some structure.

[13:56:56.0000] <Hixie>
Ms2ger: yeah unfortunately there's no spec that actually defines dispatch properly in the first place, so i couldn't do anything _but_ a COMEFROM there :-(

[13:57:07.0000] <Ms2ger>
Mm

[13:57:25.0000] <Ms2ger>
I guess this is UI Events territory

[13:57:51.0000] <SamB>
TabAtkins: what about letting an IDL method *accept* one?

[13:58:12.0000] <SamB>
rather than coercing it into an array of some kind

[13:58:12.0000] <TabAtkins>
SamB: Accepting one is just done by using "sequence<Foo>" today.

[13:58:29.0000] <Ms2ger>
Ha

[13:58:39.0000] <TabAtkins>
Oh, you mean one that only consumes data as it needs, rather than all up-front?

[13:58:52.0000] <Ms2ger>
UI Events is a delta spec for D3E/DOM, yet has neither in its References section

[13:59:03.0000] <SamB>
TabAtkins: yeah

[14:01:18.0000] <SamB>
would that be a normative reference, or a transformative reference?

[14:08:16.0000] <Domenic>
I give up on this xslt thing

[14:08:30.0000] <Ms2ger>
Hixie, hm, I guess "form control" in a term of art there?

[14:08:52.0000] <Hixie>
i think "disabled" is the term of art there, no?

[14:08:53.0000] <Hixie>
maybe

[14:08:56.0000] <Hixie>
is it hyperlinked?

[14:09:16.0000] <SamB>
isn't form control two terms

[14:09:18.0000] <Ms2ger>
Yeah, to...

[14:09:23.0000] <Ms2ger>
"A form control is disabled if ..."

[14:10:20.0000] <Hixie>
close enough :-P

[14:10:42.0000] <Ms2ger>
That still doesn't tell me which elements are form controls, though

[14:11:58.0000] <Ms2ger>
Hixie, or am I overlooking something?

[14:12:11.0000] <Ms2ger>
There's things like "Listed, labelable, submittable, and reassociateable form-associated element." under categories

[14:12:26.0000] <SamB>
Hixie: did I mention that the section about origins would be improved by hyperlinking more of the places where it mentions parts of URLs, and it wouldn't hurt to either give a summary of the parts of a URL or links to the corresponding parts of the URL spec ...

[14:12:59.0000] <Hixie>
SamB: if you filed a bug, then you did. othewise, you didn't. :-)

[14:13:21.0000] <Ms2ger>
Hixie, (not just trying to nitpick, I have no idea if my implementor in Servo (hi abinader) got them all)

[14:13:28.0000] <SamB>
I was gonna write you a patch for it but your buildsystem is, uh, so messy you're evidently ashamed to even mention it in the repo

[14:13:28.0000] <Hixie>
Ms2ger: replace "form control" with "boogie moogie" and that section doesn't change meaning as far as i can tell

[14:13:38.0000] <Ms2ger>
Indeed

[14:13:56.0000] <Ms2ger>
So what kind of elements are boogie moogies? :)

[14:14:04.0000] <Hixie>
Ms2ger: doesn't matter

[14:14:17.0000] <Hixie>
Ms2ger: why would it matter?

[14:14:17.0000] <SamB>
Ms2ger: you can't tell?

[14:14:31.0000] <Hixie>
Ms2ger: you just apply this if they're disabled

[14:14:52.0000] <Ms2ger>
Who's "they"?

[14:14:56.0000] <abinader>
I'm currently basing that all form controls affected by disabled are those in which have the disabled idl property

[14:15:04.0000] <SamB>
I mean, my thinking would be that it's pretty easy to tell based on whether it has something to do with input to a form, and whether it has a disabled attribute?

[14:15:04.0000] <Ms2ger>
I mean, does it apply to a elements?

[14:15:08.0000] <Hixie>
Ms2ger: boogie moogies are disabled if they have a disabled attribute set, where "disabled attribute" is specifically "attr-fe-disabled", which only some elements can have set

[14:15:12.0000] <SamB>
Ms2ger: I'd say no

[14:15:14.0000] <abinader>
which matches the ones listed in http://www.whatwg.org/specs/web-apps/current-work/multipage/common-idioms.html#concept-element-disabled

[14:15:17.0000] <Ms2ger>
Hmm

[14:15:25.0000] <Hixie>
Ms2ger: <a disabled> doesn't have an attr-fe-disabled attribute set

[14:15:27.0000] <SamB>
the widgety stuff is what I'd assume it talks about

[14:15:35.0000] <Ms2ger>
SamB, I don't care what you'd say, I care what the spec says :)

[14:15:43.0000] <Ms2ger>
Hixie, that's pretty obscure

[14:15:51.0000] <Hixie>
Ms2ger: no disagreement from me there :-)

[14:15:52.0000] <SamB>
Ms2ger: clearly I'm right and the spec is wrong

[14:16:07.0000] <SamB>
where wrong could just include "very unclear"

[14:16:15.0000] <Ms2ger>
I'm still not implementing you ;)

[14:16:23.0000] <SamB>
good

[14:16:27.0000] <SamB>
I'm full of bugs in general

[14:16:44.0000] <Ms2ger>
tmi

[14:16:49.0000] <annevk>
just extend dbaron's desk a bit and we should be good

[14:17:04.0000] <SamB>
wetware bugs, not, you know, actual insects or anything of that nature

[14:17:22.0000] <Ms2ger>
Ha

[14:17:23.0000] <SamB>
annevk: I don't get it

[14:17:31.0000] <dbaron>
the conformant HTML4 desk?

[14:17:32.0000] <annevk>
you must be new here

[14:17:44.0000] <SamB>
intermittent, at least

[14:17:56.0000] <annevk>
dbaron: :-)

[14:18:28.0000] <Ms2ger>
Hixie, I think that's worth a note, at least

[14:18:41.0000] <SamB>
I honestly wasn't sure if annevk was referencing/making a joke, or referring to a piece of software

[14:18:44.0000] <Hixie>
Ms2ger: absolutely agreed

[14:18:47.0000] <Hixie>
Ms2ger: file a bug :-)

[14:19:07.0000] <SamB>
called "desk", which while a fairly bad name for a piece of software, is not unimaginably bad

[14:20:03.0000] <Hixie>
the former

[14:20:11.0000] <Hixie>
though really it's not a joke but an analogy

[14:20:33.0000] <Hixie>
specifically: any desk on which you carve two quote marks is a fully conforming implementation of HTML4

[14:21:01.0000] <Hixie>
(seriously. not a joke. find a requirement that such an implementation would violate, i dare you!)

[14:21:14.0000] <Hixie>
(in fact it's more conforming than most browsers, since browsers assume a default encoding!)

[14:22:25.0000] <Ms2ger>
Productive review... I'm not even done, and I've already filed three spec bugs

[14:22:39.0000] <SamB>
Hixie: what is the pair of quotes for, exactly?

[14:23:00.0000] <Ms2ger>
SamB, <q> is required to render with quote mars around it

[14:23:08.0000] <SamB>
Hixie: what does HTML4 say you have to do about encodings

[14:23:10.0000] <SamB>
Ms2ger: lol

[14:23:14.0000] <Ms2ger>
SamB, that's understood to be the only actual requirement in HTML4

[14:23:25.0000] <SamB>
but no mention of how far around it?

[14:23:47.0000] <SamB>
or that each such element needs a distinct pair of quotes?

[14:24:03.0000] <Hixie>
SamB: "Visual user agents must ensure that the content of the Q element is rendered with delimiting quotation marks"

[14:24:10.0000] <Hixie>
SamB: (it's one of the few requirements)

[14:24:13.0000] <annevk>
Ms2ger: D3E?

[14:24:22.0000] <annevk>
Ms2ger: such a sad spec

[14:24:28.0000] <SamB>
oh, so I a desk without the quotes is just a non-visual user agent

[14:24:32.0000] <Ms2ger>
annevk, two D3E, one about the confusingness in HTML above

[14:24:33.0000] <SamB>
s/I //

[14:24:44.0000] <Hixie>
SamB: "Therefore, user agents must not assume any default value for the "charset" parameter" is the requirement about encodings that i mentioned

[14:24:52.0000] <SamB>
Hixie: ah

[14:25:00.0000] <annevk>
/me watches inbox zero go bust

[14:25:31.0000] <annevk>
HTML4 is so silly

[14:25:40.0000] <SamB>
Hixie: how naive are the peopel who wrote THAT requirement?

[14:25:52.0000] <SamB>
I mean, it's pretty crazy ...

[14:25:54.0000] <Ms2ger>
SamB, have you read HTML4?

[14:26:09.0000] <SamB>
Ms2ger: not lately

[14:26:10.0000] <Hixie>
the web was young

[14:26:17.0000] <annevk>
I think the main problem is that people are still writing specs HTML4-style

[14:26:19.0000] <Hixie>
and the people writing specs for it were young too

[14:26:25.0000] <SamB>
I was probably at least as naive back when I would have read it

[14:26:29.0000] <Hixie>
took a while to learn the lessons

[14:26:39.0000] <Hixie>
(unfortunately some never did and still edit specs at the w3c)

[14:27:06.0000] <SamB>
you really need to give an "or else you will be eaten by a giant bear" or something, except something that is actually very bad and very easy to demonstrate

[14:27:27.0000] <annevk>
Yeah, learning lessons takes long. Hard to fathom how XMLHttpRequest has evolved over eight years

[14:27:39.0000] <SamB>
like, "or we will steal your computer from you and make you pay the electric bill"

[14:28:16.0000] <SamB>
"MUST NOT" without teeth is quite silly

[14:28:37.0000] <SamB>
when its the sort of thing users will be wanting

[14:29:04.0000] <SamB>
first they make reasonable request like "This document is clearly in ASCII, just parse it already" ...

[14:29:14.0000] <SamB>
and it just goes downhill from their

[14:31:25.0000] <Domenic>
Only semi-related, but I like it when specs include undefined behavior, because then you can be a conforming implementation even if your response to the situation is indeed to mine bitcoins on the user's computer.

[14:31:57.0000] <Ms2ger>
Domenic, might as well alert YOLO in an infinite loop

[14:32:11.0000] <SamB>
Domenic: you're kidding, right?

[14:33:11.0000] <SamB>
do you really have a reason to like undefined behaviour, or do you really wish it could just go away like I assume most people do most of the time ...

[14:33:26.0000] <SamB>
not to confuse it with unspecified or implementation-defined behaviour

[14:40:53.0000] <Hixie>
Domenic: it wouldn't be non-conforming for an ES implementation to mine bitcoins from a user's computer even when not doign something undefined

[14:41:10.0000] <Hixie>
or most other specs for that matter, HTML, DOM, whatever

[14:41:24.0000] <SamB>
true

[14:41:29.0000] <SamB>
POSIX

[14:41:58.0000] <Ms2ger>
Ha, posix

[14:42:16.0000] <SamB>
not that conforming to POSIX is what you call "wise"

[14:42:45.0000] <Ms2ger>
Then again, isn't the goal of an ES implementation to let random sites mine bitcoins on your computer?

[14:43:01.0000] <SamB>
Ms2ger: you must be thinking of WebGL

[14:43:30.0000] <Ms2ger>
I prefer not to

[14:44:03.0000] <SamB>
my main experience with WebGL is firefox telling me "not can has ilt; you no has WebGL"

[14:44:09.0000] <SamB>
*Tilt

[14:44:16.0000] <SamB>
darn enter key always gets in my way

[14:44:31.0000] <Ms2ger>
My main experience is making Chrome crash

[14:44:38.0000] <Ms2ger>
I need to submit that test at some point


2014-06-28
[09:41:35.0000] <annevk>
June 28: some people really want us-ascii back

[09:45:03.0000] <JonathanNeal>
annevk: http://www.howjsay.com/index.php?word=ascii vs http://www.howjsay.com/index.php?word=utf so much more abrasive

[09:45:10.0000] <zewt>
wondering why system is crawling to a halt and freezing, then notice chrome is using ... 8.5 gigs of memory

[09:46:21.0000] <zewt>
what the shit? "To make Chrome safer, we disabled some extensions that aren't listed in the Chrome Web Store and may have been added without your knowledge." and it killed one of my user scripts

[09:46:40.0000] <zewt>
pushing me very hard back towards firefox

[09:47:05.0000] <zewt>
what... the fuck? it won't let me reenable it

[09:48:39.0000] <zewt>
help page says "nope, you can't turn it back on, deal with it" dealing with it by quitting this useless browser


2014-06-29
[16:05:10.0000] <SamB>
so, nobody actually defines the rules to turn XHTML into a Document?

[16:38:44.0000] <gsnedders>
SamB: yup.

[16:38:49.0000] <gsnedders>
SamB: or XML in general


2014-06-30
[17:51:11.0000] <SamB>
and they tell me that HTML email is totally unstandardized

[18:19:06.0000] <SamB>
so, I can have an <xmlns:foo> element, but only if I use the right namespace URL?

[18:20:19.0000] <SamB>
http://dom.spec.whatwg.org/#dom-document-createelementns

[21:27:12.0000] <roc>
I think this insistence that WebIDL be no more expressive than JS has gone much too far

[21:29:07.0000] <MikeSmith>
roc: people are really advocating for that?

[21:29:27.0000] <MikeSmith>
on script-coord? or somewhere else?

[21:29:37.0000] <MikeSmith>
/me is way behind on e-mail

[21:30:30.0000] <roc>
that is my impression from public-script-coord, though to be fair it's mostly Domenic Denicola

[21:34:41.0000] <MikeSmith>
roc: yeah I'm reading up on that thread now. Wonder what slightlyoff's take on this is

[21:36:48.0000] <caitp>
*reads thread*

[21:37:06.0000] <caitp>
would those interfaces need to be exposed to JS at all? I thought that's what NoInterfaceObject was mostly used for

[21:46:58.0000] <roc>
Domenic seems to insist that there be one WebIDL interface per implementation class.

[21:49:22.0000] <caitp>
I can see his point, it would be potentially be helpful for users, and would also probably be helpful for the whole "implement the platform in JS" push

[21:49:30.0000] <caitp>
but I dunno :>

[23:39:05.0000] <annevk_>
roc: a large part of ES6 was to make ES as expressible as DOM

[01:32:05.0000] <annevk>
I realized over the weekend the asFormData thread was slightly silly, as for FormData parsing you need to extract the MIME type in order to get the boundary

[01:32:32.0000] <annevk>
Nobody on the list noticed that however

[03:09:57.0000] <annevk>
/me filed http://www.rfc-editor.org/errata_search.php?rfc=2388&eid=4030

[03:47:05.0000] <annevk>
/me revives http://wiki.whatwg.org/wiki/FormData

[04:00:46.0000] <annevk>
/me filed http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4031

[04:10:05.0000] <annevk>
Domenic: fetching itself requires teeing as well

[04:10:57.0000] <annevk>
Domenic: e.g. POST a stream to X, now X replies with a redirect to Y. The platform expects both X and Y to get the stream

[04:12:01.0000] <annevk>
I should probably spell that out in http://fetch.spec.whatwg.org/#http-network-or-cache-fetch rather than say "Let HTTPRequest be a copy of request." which does not really work for streams (well, copy is not immediately clear)

[04:12:28.0000] <MikeSmith>
annevk: I think Larry would be happy if you filed issues at https://github.com/masinter/multipart-form-data/issues too

[04:13:00.0000] <MikeSmith>
annevk: oh, the first one at least

[04:13:03.0000] <MikeSmith>
not the http one

[04:15:30.0000] <annevk>
Is that actually moving?

[04:16:16.0000] <annevk>
Seems the boundary comment is already captured there by a comment from Alexey

[04:36:06.0000] <MikeSmith>
annevk: dunno if it's moving or not but I know Larry would for people to at least read what he's got there and comment

[04:44:13.0000] <annevk>
I'm sort of surprised it is not done yet, this should not be hard

[04:44:48.0000] <annevk>
/me points himself to topic

[04:45:36.0000] <annevk>
Hixie: your echo tool is great btw

[04:45:47.0000] <annevk>
Hixie: that hex viewer :-)

[06:14:40.0000] <annevk>
Domenic: either way "When an Advisory Board or TAG participant changes affiliations, as long as Advisory Board and TAG participation constraints are respected, the individual MAY continue to participate until the next regularly scheduled election for that group." applies

[06:40:28.0000] <annevk>
Refactoring XMLHttpRequest in terms of Fetch <3

[07:14:23.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23646#c24 lol

[07:20:39.0000] <annevk>
Hixie: how much positive reactions have you gotten to the "domintro" boxes? So far all they have caused is confusion in bug reports I got

[07:20:58.0000] <annevk>
Hixie: in particular implementers citing them causes concern

[07:25:26.0000] <Domenic>
What's a domintro box

[07:36:55.0000] <annevk>
http://xhr.spec.whatwg.org/#the-open%28%29-method the green box that says "Note"

[07:45:35.0000] <Domenic>
Oh. So before those were green but didn't have the little box, right?

[07:45:43.0000] <Domenic>
I much prefer the explicit call-outs myself.

[07:51:57.0000] <jgraham>
Maybe it should say "non normative note"

[07:52:46.0000] <annevk>
Domenic: well yes, that it says "Note" is great, I'm just wondering if there's value versus having people just read the algorithms

[07:52:57.0000] <annevk>
Domenic: and leaving "domintro" material to MDN

[07:52:59.0000] <Domenic>
annevk: ah, for them existing at all, you mean.

[07:53:28.0000] <annevk>
Yes, given that people get confused and most developers don't seem to read specifications

[07:53:32.0000] <Domenic>
Oh, and not just notes generally, but the "intro" notes describing each method.

[07:53:54.0000] <jgraham>
annevk: Being able to get a rough idea of what a method is supposed to do seems valuable. Not least to people writing MDN

[07:54:15.0000] <annevk>
Domenic: notes generally still have value I think

[07:54:40.0000] <Domenic>
I agree that they can be a bit problematic. I think I would prefer making them more vague, i.e. one- or two-sentence prose descriptions instead of things that link to defined terms, and specify all the error conditions

[07:55:04.0000] <annevk>
That might work

[07:55:13.0000] <annevk>
Trying to be accurate is indeed not paying off

[07:55:17.0000] <annevk>
Oh shit, back later

[07:55:31.0000] <Domenic>
So e.g. "mutates the state of the XMLHttpRequest object according to the passed values, setting it up for a future call to send()" (just off the top of my head)

[08:14:40.0000] <MikeSmith>
we should have an implementor view of the spec that omits all of the non-normative parts

[08:15:12.0000] <MikeSmith>
basically, just the class=impl parts

[08:15:19.0000] <jgraham>
MikeSmith: The other notes are really helpful when implementing

[08:15:34.0000] <jgraham>
Because they often state non-obvious things that should be invariants

[08:15:39.0000] <jgraham>
Or similar

[08:16:37.0000] <MikeSmith>
jgraham: So we need class="impl note"

[09:03:47.0000] <Domenic>
In ES specs/streams spec we do "Assert: <invariant must hold>" as part of the spec steps

[09:12:40.0000] <jgraham>
Domenic: Not just asserts though. e.g. the parser spec has things like (paraphrasing) "although this attribute is removed and never used in the tree, it is still the /currentAttribute/"

[09:13:28.0000] <jgraham>
Which is already normatively specified, but makes it clear that the behaviour in the normative parts is intentional

[09:17:13.0000] <Domenic>
Yeah, fair.

[09:32:13.0000] <gsnedders>
Also last I knew Hixie wasn't confident of the "fragment case" notes being correct, and thought there might also be other cases not so denoted.

[09:36:23.0000] <Hixie>
yeah the fragment case stuff is out of date, i'm pretty sure. i really should just strip those annotations.

[09:36:47.0000] <Hixie>
annevk: before i added domintro boxes i got a regular stream of people saying the spec was inpenetrable for authors, because nothing said how to use APIs

[09:36:59.0000] <Hixie>
annevk: since adding them, i've gotten no such feedback, but i do occasionally get confused implementors

[09:37:26.0000] <Hixie>
annevk: mostly new implementors who can't tell that they're non-normative and have no requirements, though

[09:40:07.0000] <SamB>
I think you should get some cute "caution" signs

[09:40:30.0000] <Hixie>
the "Note" labels aren't cute enough?

[09:40:55.0000] <Hixie>
we used to explicitly label them "These are not normative, the requirements are below", but I think the "Note" conveys the same meaning

[09:41:19.0000] <SamB>
I meant for particular (classes) that you suspect of being stale

[09:41:59.0000] <Hixie>
?

[09:42:10.0000] <Hixie>
MikeSmith: we actually do have class="impl note" in some places, fwiw

[09:42:17.0000] <Hixie>
e.g. any note in the parser section

[09:44:44.0000] <SamB>
Hixie: oh, btw, how in the world am I supposed to fix crossrefs in the multipage edition without a copy of the buildsystem ;-P

[09:45:09.0000] <Hixie>
i'm going to fix those shortly

[09:45:13.0000] <Hixie>
i'm redoing my build system

[09:45:28.0000] <Hixie>
the multipage splitter is in github, though, fwiw

[09:45:31.0000] <Hixie>
the current one, i mean

[09:45:33.0000] <SamB>
hmm

[09:45:42.0000] <Hixie>
it's not part of the spec generator per se

[09:45:49.0000] <SamB>
see, this is why you should have a README in the repo

[09:45:58.0000] <Hixie>
*shrug*

[09:46:08.0000] <Hixie>
i wouldn't have thought to put that in there :-)

[09:46:17.0000] <SamB>
well, yes, that's why I'm telling you now

[09:46:38.0000] <Hixie>
the only thing i'd think to put in such a README is "stop forking the spec"

[09:46:45.0000] <Hixie>
and the w3c would ignore it anyway

[09:48:25.0000] <SamB>
it'd go like this "My current spec generator is awful, so I'm writing a new one at <...>.  Code to split this into multiple pages is at <...>, and some of the images, scripts, and stylesheets are in the repo at <...>.

[09:48:40.0000] <SamB>
oops forgot the closing quote

[09:49:34.0000] <Hixie>
that would just make it even easier for the w3c to fork it

[09:49:40.0000] <Hixie>
which is an antigoal

[09:49:46.0000] <SamB>
they don't use your style though

[09:49:51.0000] <SamB>
or logos

[09:50:06.0000] <Hixie>
they use the rest

[09:50:14.0000] <Hixie>
they even use some of the styles

[09:50:23.0000] <SamB>
hmm

[09:50:48.0000] <SamB>
I don't see that making it easier for the W3C to fork it is actually going to make anything worse; they *already* forked it.

[09:51:03.0000] <Hixie>
it's an ongoing thing

[09:51:09.0000] <Hixie>
they copy all our patches too

[09:51:12.0000] <Hixie>
well, most of them

[09:51:20.0000] <SamB>
What license are you using for the text again?

[09:51:29.0000] <Hixie>
(if it was just all of them and tehy didn't make any additional changes, it would be fine)

[09:51:52.0000] <Hixie>
SamB: "You are granted a license to use, reproduce and create derivative works of this document"

[09:51:58.0000] <Domenic>
did you see this reply: https://twitter.com/stevefaulkner/status/483600468011393025

[09:52:00.0000] <SamB>
Hixie: yeah, if it was all of them that'd not really be what you call a fork

[09:52:25.0000] <SamB>
Hixie: maybe switch to one requiring retention of copyright statements ;-P

[09:53:00.0000] <SamB>
like the Expat license

[09:53:05.0000] <Hixie>
SamB: i'm very close to just changing the license to disallow forking entirely

[09:53:28.0000] <Hixie>
SamB: i'm right on the knife edge of not being sure which is more important, the freedom for specs to be reusable, or the damage the w3c is causing with their fork

[09:53:33.0000] <SamB>
Hixie: what, you gonna go all LPPL on them?

[09:53:42.0000] <SamB>
or Knuth?

[09:53:49.0000] <SamB>
like "you must not call this HTML if you fork it"

[09:53:59.0000] <SamB>
"no, you can't just add a 5"

[09:54:09.0000] <Hixie>
i was thinking more the w3c documentation license with "w3c" replaced with "whatwg", for extra irony

[09:55:22.0000] <SamB>
hmm, I'd really prefer if you'd try some other Free Software licenses before you do something like that

[09:55:54.0000] <Domenic>
Hixie: this feels like a very movie-esque situation... I think I have to chime in and say "don't do it! That's what separates *us* from *them*!"

[09:57:52.0000] <SamB>
I'd just start with "Copyright 200x--20xx whatwg.org"

[09:58:13.0000] <Hixie>
Domenic: yeah, that's why i haven't done it

[09:58:13.0000] <SamB>
then go on to give the text of the Expat license, which would forbid the W3C from removing the first bit

[09:58:37.0000] <Hixie>
SamB: there's plenty of licenses like that. I'd just use the MIT license if that was my goal.

[09:58:47.0000] <Hixie>
SamB: however, having them put our copyright on their spec isn't the goal

[09:58:47.0000] <SamB>
expat license IS an MIT license

[09:58:51.0000] <SamB>
http://www.jclark.com/xml/copying.txt

[09:58:52.0000] <Domenic>
SamB: the relevant portion is not whether they include some kind of credit (they already do), but whether they modify it. Thus the W3C document license's "No right to create modifications or derivatives of W3C documents is granted pursuant to this license."

[09:59:08.0000] <SamB>
hmm, so, maybe use something like the LGPL then

[09:59:34.0000] <Domenic>
LGPL software can't be forked? Weird.

[09:59:37.0000] <SamB>
it can

[09:59:43.0000] <Domenic>
Well then it's not suitable.

[09:59:47.0000] <SamB>
but I think you're technically supposed to document the changes

[10:00:22.0000] <Hixie>
SamB: they do "document" the changes

[10:00:31.0000] <Hixie>
i mean, they do a pathetic job of it, but they at least try

[10:00:38.0000] <Hixie>
the problem isn't that

[10:00:43.0000] <Hixie>
the problem is that there are changes at all

[10:00:48.0000] <SamB>
also they'd be required to pass on the permission to all recipients

[10:01:18.0000] <jgraham>
The level of problem here is not worth the cost of adopting a restrictive license

[10:01:48.0000] <jgraham>
Not least because you would automatically lose any argument in favour of permissive licenses in the future

[10:02:07.0000] <Hixie>
yup

[10:02:43.0000] <Hixie>
jgraham: is there some way to force pms to sort attributes? or if they're always sorted, what order are they sorted in?

[10:03:06.0000] <Hixie>
/me crosses his fingers and repeats "please don't say python hash order please don't say python hash order"

[10:03:14.0000] <SamB>
well, the LGPL isn't viral to the extent that the GPL is

[10:03:31.0000] <Hixie>
realistically, the license isn't changing

[10:03:39.0000] <jgraham>
Hixie: It is possible to make html5lib do it. I don't remember if that's exposed anywehre though

[10:04:20.0000] <Hixie>
jgraham: any chance i could get you to make pms do it briefly? i'm trying to ensure my output matches pms', so that i know i haven't broken anything

[10:06:15.0000] <SamB>
Hixie: wouldn't *any* sort of copyleft make things tricky for the W3C fork, though?

[10:06:35.0000] <Hixie>
this is probably their most important spec, "tricky" won't stop them

[10:06:45.0000] <Hixie>
and it has much bigger disadvantages

[10:06:53.0000] <Hixie>
e.g. can't reuse in mozilla comments

[10:06:56.0000] <SamB>
hmm

[10:07:42.0000] <SamB>
so would any sort of licensing scheme with an |MPL be a pointless exercise here?

[10:08:02.0000] <SamB>
what does the MPL let you get away with?

[10:09:27.0000] <Hixie>
MPL is more or less the sme as what we have now

[10:09:48.0000] <jgraham>
Hixie: Try now, but I'm not sure I did anything useful

[10:09:48.0000] <MikeSmith>
Hixie: about class="impl note", I'm reminde that you're always way ahead of me

[10:11:33.0000] <Hixie>
jgraham: thanks, trying now

[10:22:30.0000] <SamB>
hmm, well, #debian-devel thinks you should use one of those anyway just to make sure you're actually granting all the rights you think you're granting ;-)

[10:22:36.0000] <SamB>
er, sorry, was scrolled up

[10:22:51.0000] <SamB>
s/one of those/MIT licenses/

[10:23:00.0000] <SamB>
er.

[10:23:11.0000] <SamB>
grammatified better

[10:23:25.0000] <Hixie>
yeah, we should. but changing the license is harder than it appears, so unless someone has an actual problem, we won't.

[10:23:34.0000] <Hixie>
clearly the w3c is sure we're granting them.

[10:26:06.0000] <Hixie>
jgraham: that changed nothing :-(

[10:31:29.0000] <jgraham>
Hixie: Oh, sorry. Got to run now but I will try again later / tomorrow

[10:33:13.0000] <Hixie>
jgraham: k

[10:33:20.0000] <Hixie>
jgraham: thanks for trying!

[11:47:02.0000] <SamB>
Hixie: oh, btw, those links that point at, like, the previous sentence are kind of annoying

[11:49:50.0000] <SamB>
Hixie: and will your new tool link to the actual *definitions* imported from other specs?

[12:23:33.0000] <mounir>
Domenic, abarth: ping

[12:28:08.0000] <abarth>
mounir: hi

[12:28:46.0000] <mounir>
abarth: I thought it could be great to have a quick discussion about the screen.orientation issue

[12:28:47.0000] <abarth>
mounir: I commented on the github bug thread

[12:28:51.0000] <abarth>
yeah

[12:28:55.0000] <mounir>
abarth: I saw that

[12:28:58.0000] <abarth>
there's some sort of crazy going on

[12:29:13.0000] <mounir>
abarth: what would you prefer?

[12:29:48.0000] <abarth>
i'd just leave it as an normal interface

[12:30:00.0000] <abarth>
instead of hacking around to try to making it into a dictionary

[12:30:56.0000] <mounir>
abarth: and you would pass that interface when resolving the promise?

[12:31:22.0000] <abarth>
i'm not sure I understand the connection to promises

[12:31:29.0000] <abarth>
but sure, you can pass an interface to a promise

[12:31:40.0000] <mounir>
screen.lockOrientation().then(function(o) {})

[12:31:41.0000] <abarth>
that's how everything else in the platform works

[12:31:46.0000] <abarth>
sure

[12:31:48.0000] <mounir>
o is the orientation at the time of the lock being applied

[12:31:52.0000] <mounir>
it has to be "frozen"

[12:32:16.0000] <abarth>
you don't mean frozen in the ECMAScript sense

[12:32:21.0000] <abarth>
you just mean 'not live'

[12:32:26.0000] <abarth>
sure

[12:32:30.0000] <mounir>
abarth: yes, thus the quotes

[12:32:45.0000] <mounir>
having a live and not live version sounded dirty

[12:32:52.0000] <mounir>
and I didn't really know what to do

[12:32:52.0000] <abarth>
why?

[12:33:01.0000] <abarth>
that's how everything works

[12:33:10.0000] <mounir>
Domenic's proposal sounded a cleaner way to solve the problem

[12:33:22.0000] <abarth>
except that it doesn't work

[12:33:25.0000] <mounir>
abarth: there isn't that many frozen/live objects

[12:33:30.0000] <abarth>
you can't even express it in IDL

[12:33:36.0000] <mounir>
abarth: except crazy things like NodeList, maybe

[12:33:42.0000] <abarth>
window.location

[12:33:48.0000] <abarth>
window.document

[12:33:55.0000] <abarth>
|document| is live

[12:34:01.0000] <abarth>
but if you make your own element

[12:34:05.0000] <abarth>
and hold onto it

[12:34:10.0000] <abarth>
it's "not live"

[12:35:02.0000] <abarth>
the reason screen.orientation is "live" is because the platform keep mutating it

[12:35:27.0000] <abarth>
the version it gives you via lockOrientation is "no live" because the platform just doesn't mutate it

[12:35:48.0000] <mounir>
abarth: I understand that

[12:36:00.0000] <mounir>
abarth: I'm not really convinced that it is nicer that Domenic's opinion

[12:36:06.0000] <mounir>
s/opinion/proposal/

[12:36:14.0000] <abarth>
dominic's proposal doesn't work

[12:36:22.0000] <abarth>
and is different from every other thing in the platform

[12:36:42.0000] <abarth>
is there any problem with the proposal above that needs to be solved?

[12:37:36.0000] <mounir>
why it doesn't work?

[12:37:45.0000] <mounir>
because it's not expressable in WebIDL?

[12:38:43.0000] <mounir>
fwiw, doing s/dictionary/object/ and it becomes fine wrt WebIDL

[12:39:18.0000] <abarth>
maybe the "not working" part is specific to the CL you wrote

[12:39:35.0000] <abarth>
but the CL you wrote is a security vulnerability

[12:39:53.0000] <mounir>
how so?

[12:40:03.0000] <mounir>
because it's using custom bindings?

[12:42:47.0000] <mounir>
abarth: my understanding is that I can't return an arbitrary object using the bindings in Blink, if that's not right, I can change the CL

[12:43:09.0000] <abarth>
Chasing down the details, I see that I'm mistaken about it being a security vulnerability

[12:43:17.0000] <abarth>
here's a strange behavior that you've got through:

[12:43:24.0000] <abarth>
var x = screen.orientation;

[12:43:28.0000] <abarth>
x.foo = "bar";

[12:43:30.0000] <mounir>
abarth: anyhow, I want to make sure we have an agreement on the API - if the implementation needs fixing, that's orthogonal

[12:43:31.0000] <abarth>
... time passes ..

[12:43:44.0000] <abarth>
alert(screen.orientation.foo == "bar")

[12:43:51.0000] <abarth>
does that alert |true| or |false| ?

[12:44:57.0000] <mounir>
abarth: might be true but screen.orientation should be read-only

[12:45:06.0000] <mounir>
abarth: I should probably fix that

[12:45:20.0000] <mounir>
(i was actually thinking about that during diner...)

[12:45:30.0000] <abarth>
making screen.orientation readonly doesn't solve this problem

[12:45:49.0000] <abarth>
the problem is that you're creating new objects from time to time

[12:45:55.0000] <abarth>
which means you lose all the expandos

[12:46:44.0000] <abarth>
In any case, I still haven't heard a problem with implementing this feature the normal way

[12:47:28.0000] <abarth>
if there's no problem to solve, I'd strongly prefer for this feature to behave in the same way as every other API in the plaform

[12:48:35.0000] <mounir>
abarth: I was going to go the "normal way", as you can see, the spec was going that way and only needed to add the frozen definition

[12:48:50.0000] <mounir>
abarth: Domenic pointed that other solution that looked reasonable

[12:49:14.0000] <abarth>
when you get into the details, they look less reasonable

[12:50:09.0000] <mounir>
abarth: sure

[12:50:53.0000] <mounir>
abarth: I don't have any strong opinion but I would like to hear from Domenic before going the other way

[12:51:51.0000] <mounir>
(ahah, that previous sentence is terrible...)

[12:53:15.0000] <annevk>
Hixie: is there any advantage of class=domintro over class=note then? Maybe we should have class=intro and just label them "Introduction"?

[13:07:03.0000] <annevk>
mounir: what abarth is saying is that you need to define the lifetime of the object you return

[13:07:11.0000] <annevk>
mounir: or its GC policy

[13:07:31.0000] <annevk>
mounir: but you need to do that either way

[13:07:32.0000] <mounir>
annevk: I understood that

[13:07:46.0000] <annevk>
mounir: so I don't really see the problem, seems like it could just be the lifetime of the screen object

[13:08:02.0000] <abarth>
annevk: my point is that we're creating all these problems and complex spec and implementation to solve a non-problem

[13:08:08.0000] <mounir>
annevk: and we will get many objects lying around for no reason?

[13:08:57.0000] <abarth>
annevk: instead, we could just use the normal spec for readonly attributes in WebIDL and return a normal interface object

[13:09:24.0000] <annevk>
abarth: that Chrome is wonky when it comes to dealing with JavaScript shouldn't really influence API design I think

[13:09:29.0000] <SamB>
annevk: any idea why this says what it does about "xmlns" <http://dom.spec.whatwg.org/#dom-document-createelementns>?  I'm not familiar with any xmlns elements

[13:09:40.0000] <abarth>
annevk: I didn't say that

[13:09:56.0000] <abarth>
annevk: I said this API should work the same way as every other API in the platform

[13:10:11.0000] <abarth>
annevk: no one has advanced any reason why doing things the normal way is a problem

[13:10:31.0000] <annevk>
Our "the normal way" is alien to many web developers

[13:10:43.0000] <annevk>
And JavaScript as a language

[13:11:06.0000] <annevk>
SamB: legacy XML cruft

[13:11:34.0000] <SamB>
annevk: because it SOUNDS like stuff that has more to do with attributes

[13:12:44.0000] <abarth>
annevk: can you show me some code that would be written by a web developer that would be materially better using this alternative approach?

[13:14:28.0000] <annevk>
abarth: if you're not convinced by the premise that the platform is a library written on top of JavaScript I recommend talking to slightlyoff et al

[13:14:52.0000] <abarth>
annevk: The normal way of implementing this works fine in JavaScript

[13:14:53.0000] <annevk>
abarth: or e.g. dglazkov if that's closer

[13:15:05.0000] <abarth>
annevk: there's nothing "non javascripty" about the normal way here

[13:15:19.0000] <abarth>
annevk: so, you don't have a concrete problem with the normal approach either

[13:15:22.0000] <annevk>
abarth: yes there is, the normal way has a non-constructable class

[13:15:26.0000] <Hixie>
SamB: i hope so, eventually

[13:15:32.0000] <abarth>
so, make the class constructable

[13:15:43.0000] <Hixie>
annevk: domintro vs note is mostly a historical thing now

[13:15:49.0000] <annevk>
abarth: if you write some JavaScript, the normal way to return some properties is just returning an object

[13:16:14.0000] <abarth>
the only difference here is (1) the prototype and (2) the toString value

[13:16:33.0000] <Hixie>
"if you're not convinced by the premise that the platform is a library written on top of JavaScript I recommend talking to slightlyoff et al" <- i have, still not convinced

[13:16:37.0000] <annevk>
abarth: people care about us not using data properties too, these things matter to some people

[13:16:50.0000] <abarth>
annevk: so, do you have any code that would be made better?

[13:16:56.0000] <abarth>
it sounds like the answer is "no"

[13:17:36.0000] <SamB>
if it's written in JavaScript, remind me what all that C++ code is for

[13:18:12.0000] <annevk>
abarth: I don't think this is helping

[13:18:50.0000] <abarth>
ok :)

[13:19:21.0000] <Hixie>
"Our "the normal way" is alien to many web developers" <- the JS way is alien to at least as many developers

[13:19:58.0000] <abarth>
Hixie: it's all about who you pick as "JS" developers

[13:20:13.0000] <Hixie>
exactly

[13:20:16.0000] <abarth>
the true scottsmen who will arbitrate

[13:20:20.0000] <Hixie>
yeah

[13:21:46.0000] <annevk>
abarth: it does seem to me that just like we think XML is cruft, returning an object that has a prototype and various bits IDL adds over a normal object can also be seen as such

[13:21:58.0000] <annevk>
abarth: but I'm not the one you need to convince here

[13:22:08.0000] <Hixie>
(for the record i've no idea what y'all are actually talking about, concretely)

[13:22:43.0000] <abarth>
Hixie: it's has to do with what screen.orientation returns

[13:22:55.0000] <abarth>
should its prototype be Object.prototype

[13:23:05.0000] <abarth>
should it change identity when the orientation changes

[13:23:09.0000] <Hixie>
shouldn't it just be a string...

[13:23:51.0000] <abarth>
it has two fields

[13:24:17.0000] <abarth>
angle and type

[13:24:26.0000] <MikeSmith>
Hixie: from where is the quote "if you're not convinced by the premise that the platform is a library written on top of JavaScript I recommend talking to slightlyoff"?

[13:24:51.0000] <Hixie>
MikeSmith: slightly earlier in the annevk/abarth conversation

[13:25:03.0000] <MikeSmith>
Hixie: ah ok

[13:25:15.0000] <MikeSmith>
/me is just reading scrollback now

[13:25:40.0000] <abarth>
Hixie: but yes, you could explode them onto Screen if you wanted

[13:26:19.0000] <Hixie>
abarth: imho should probably return an  interface ScreenOrientation { readonly attribute SomeEnum firstField; readonly attribute SomeOtherEnum secondField; }

[13:26:26.0000] <Hixie>
abarth: what else would it return?

[13:26:38.0000] <abarth>
that's my perspective

[13:26:48.0000] <Hixie>
lgtm, ship it

[13:27:10.0000] <abarth>
that's alien to "JS" developers

[13:27:41.0000] <abarth>
instead, they want exactly the same thing, except the prototype is set to Object.prototype and the toString returns "[Object object]"

[13:28:02.0000] <Hixie>
that's alien to Web developers

[13:28:22.0000] <SamB>
abarth: why do they have to care about that

[13:28:26.0000] <Hixie>
what Web devs want is that rare that the Web has done consistently for decades

[13:28:36.0000] <SamB>
isn't Object.prototype in the chain anyway

[13:28:39.0000] <Hixie>
that sentence got garbled

[13:28:44.0000] <abarth>
SamB: that's my argument.  no code is made better by returning that sort of object instead

[13:28:55.0000] <Hixie>
what Web devs want is that rare thing, a think the Web has done consistently for decades. namely, the interface thing.

[13:29:00.0000] <Hixie>
thing. not think.

[13:29:04.0000] <Hixie>
i'm gonna go elsewhere now.

[13:29:11.0000] <SamB>
Hixie: hehehe

[13:29:42.0000] <SamB>
it sounded senseful to me, if slightly garbled

[13:30:37.0000] <SamB>
(can't you do that in JavaScript too though?)

[13:32:01.0000] <Hixie>
do what in JS?

[13:32:08.0000] <Hixie>
return a host object?

[13:33:38.0000] <SamB>
you can only do that whole interface thing for host objects?

[13:35:00.0000] <Hixie>
"interface" basically means "host object"

[13:35:09.0000] <Hixie>
i mean it's more complicated than that

[13:35:22.0000] <Hixie>
but what abarth and i are saying is that the api should return a host object

[13:35:26.0000] <Hixie>
not an Object

[13:36:09.0000] <SamB>
yeah, I know; I guess I'm just underestimating the extent to which host objects are magical ...

[13:36:42.0000] <Hixie>
they're not really magical at all

[13:36:48.0000] <Hixie>
well, Window is

[13:36:49.0000] <SamB>
s/magical/special/ ?

[13:37:06.0000] <Hixie>
they're not really special either, there's more types of host objects than there are types of Object

[13:37:36.0000] <Hixie>
they're just objects implemented by the browser

[13:37:48.0000] <SamB>
where by special I mean different from things one can do in JavaScript code

[13:38:08.0000] <Hixie>
well obviously author code can't create objects implemented by not-author code

[13:38:36.0000] <SamB>
well, yes, that part is clear

[13:56:37.0000] <odinho>
I think they want to implement as many browser features as possible in javascript these days.  And that might be part of the reason host objects seem to breaking their stride.  Not having to go out from JIT or somesuch.

[13:57:01.0000] <odinho>
In case someone is following along at home and didn't already know.

[14:03:51.0000] <SamB>
odinho: which "they"?

[14:04:10.0000] <SamB>
Chrome's chrome doesn't seem to be in JS ...

[14:12:14.0000] <mounir>
Domenic: yt?

[14:14:34.0000] <Domenic>
mounir: ya back

[14:15:20.0000] <mounir>
Domenic: i replied in the GH issue

[14:15:33.0000] <mounir>
Domenic: this thing is a bit frustrating :)

[14:17:07.0000] <Domenic>
mounir: yeah, sorry...

[14:17:22.0000] <mounir>
Domenic: not your fault, mostly a tz problem

[14:17:29.0000] <mounir>
Domenic: I sud

[14:17:48.0000] <mounir>
I used to do non-office hours, it's hard to handle tz while doing office hours

[16:19:37.0000] <JonathanNeal>
If an article displays comments for individual paragraphs, what does that markup look like? Is there a definitive element to use for the comments, like <blockquote> or <aside>? <p>Content</p><x>Comment</x>.

[16:20:11.0000] <Hixie>
<article> is the definitive element for comments

[16:20:30.0000] <Hixie>
assuming you mean reader comments

[16:20:32.0000] <SamB>
that's kind of dumb, since it's not really the same thing as a comment ...

[16:20:40.0000] <Hixie>
it really is

[16:20:42.0000] <Hixie>
see the spec

[16:20:47.0000] <SamB>
I've seen the spec!

[16:21:08.0000] <Hixie>
there's no difference between a person's comment, and a person's article, other than the writer of the article thinking they're special

[16:21:23.0000] <Hixie>
(this is demonstrated really effectively by reddit)

[16:21:30.0000] <SamB>
reddit has articles?

[16:21:38.0000] <Hixie>
exactly.

[16:21:40.0000] <SamB>
I thought that thing was just the first comment

[16:21:48.0000] <Hixie>
there is no difference.

[16:22:06.0000] <zewt>
depends entirely on the site

[16:22:15.0000] <Hixie>
only superficially

[16:22:16.0000] <SamB>
maybe what I really mean is there ought to mark up what is being replied to ...

[16:22:19.0000] <zewt>
comments are very different on stackoverflow (but stackoverflow's comment system is completely worthless and not really a good example)

[16:22:21.0000] <SamB>
if anything

[16:22:46.0000] <SamB>
indeed, SO comments are totally not deserving of <article>

[16:22:57.0000] <Hixie>
zewt: stackoverflow's structure maps to <article> very well also

[16:23:16.0000] <zewt>
i have no idea what the point of "<article>" is in the first place (but I'm usually in the "mostly divs" camp)

[16:23:23.0000] <Hixie>
SamB: it is marked up. it's whatever the parent <article> is.

[16:23:37.0000] <SamB>
Hixie: that doesn't distinguish replies from quotations!

[16:23:48.0000] <Hixie>
the point of <article> (and all the other "block-level" elements) is to kill divs :-)

[16:23:58.0000] <Hixie>
SamB: quotations are marked up with <blockquote>

[16:24:07.0000] <Hixie>
not <article>

[16:24:16.0000] <SamB>
what if you repost a whole article in your article?

[16:24:33.0000] <Hixie>
then you put it in <blockquote>

[16:25:24.0000] <JonathanNeal>
I follow. If one paragraph has a few, ordered comments, are those comments then grouped by a <section>?

[16:26:18.0000] <Hixie>
yeah, or aside, probably

[16:26:39.0000] <Hixie>
(section is probably better than aside)

[16:26:45.0000] <JonathanNeal>
As opposed to, say, <ol><li><article/><li><article/></ol>

[16:27:04.0000] <JonathanNeal>
That feels all kinds of wrong to me, but I don’t know the spec well enough to justify the feeling.

[16:27:08.0000] <Hixie>
i personally wouldn't consider it a list in the <ol> sense, but some people would advocate for that and i wouldn't say they're wrong

[16:30:35.0000] <JonathanNeal>
My feeling is: Not everything that is ordered is a list. Any article can be made of paragraphs dispalyed in a certain order. To be a list, that requires intent to absorb the list items as connected to each other.

[16:31:37.0000] <JonathanNeal>
So, <section><article/><article/></section> is okay because an article “could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment”. Thanks!

[16:31:52.0000] <Hixie>
/me nods

[16:31:56.0000] <Hixie>
yeah that's why i wouldn't put it in a list either

[16:32:43.0000] <SamB>
Hixie: the other problem I have with the "nest them" idea is that I normally think of the comments as coming *after* the article they comment on ...

[16:33:41.0000] <Hixie>
you can put them anywhere you want, before, middle (like JonathanNeal is saying), after, on a different page, whatever you want

[16:34:32.0000] <SamB>
hmm, screw it, lets just use an mbox ;-P