| 00:08 | <rniwa> | dcheng: yt? |
| 00:08 | <rniwa> | Domenic: yt? |
| 01:42 | <rniwa> | MikeSmith: could you add @ehsan to https://github.com/whatwg/html>; |
| 01:43 | <rniwa> | MikeSmith: he's a Gecko contributor |
| 02:12 | <MikeSmith> | rniwa: added with read access |
| 03:31 | <luxio> | why so many people idling here? |
| 06:30 | <annevk> | luxio: lots of people trying to get rid of their sense of logic |
| 07:53 | <tobie> | TimothyGu: isn't document.all awesome!? |
| 07:59 | <annevk> | Hmm I just noticed that Bikeshed puts <script> elements way late in the document |
| 07:59 | <annevk> | How do you get them in <head>? |
| 07:59 | <annevk> | And how would you do the same for a <style>? |
| 08:16 | <tobie> | annevk: iirc BS puts all <style> elements in <head>. |
| 08:17 | <tobie> | annevk: no idea about <script> |
| 09:52 | <foolip> | zcorpan: https://drafts.fxtf.org/geometry/ or https://drafts.fxtf.org/geometry-1/? |
| 09:52 | <foolip> | zcorpan: only the latter has DOMRectList, but is an uglier URL |
| 09:53 | <zcorpan> | foolip: huh. they're supposed to be identical |
| 09:53 | <foolip> | zcorpan: a deploy problem perhaps? |
| 09:55 | <zcorpan> | took a guess and pinged plinss |
| 09:55 | <zcorpan> | thanks |
| 09:55 | <foolip> | zcorpan: so linking to the one without the version should be the right thing? |
| 09:56 | <zcorpan> | foolip: yeah, in general, but in web-platform-tests the linter will whine about versionless spec links under css/ |
| 09:56 | <zcorpan> | iirc |
| 09:56 | <foolip> | zcorpan: that's fine, those aren't URLs, just reviewing URL fixes in Blink's IDL files now |
| 09:58 | <TimothyGu> | tobie: totally |
| 10:44 | <annevk> | TimothyGu: https://github.com/w3c/web-platform-tests/pull/6890 |
| 10:45 | <TimothyGu> | woo hoo! |
| 10:46 | <annevk> | I guess I'll start filing some browser bugs too on the base64 bits that don't interoperate |
| 11:30 | <tobie> | TimothyGu: looking at your latest change. You seem to understand the difference between an Object Type with a [[Call]] internal method and ECMAScript Function Objects. TBH, I don't. Care to enlighten me (or someone else for that matter). |
| 11:56 | <tobie> | Domenic, annevk: ^ |
| 12:28 | <annevk> | tobie: oh sorry, missed that |
| 12:29 | <tobie> | annevk: np |
| 12:29 | <annevk> | tobie: I'm not really sure on the difference |
| 12:29 | <tobie> | annevk: :( |
| 12:29 | <annevk> | tobie: do functions have [] accessors? |
| 12:30 | <tobie> | annevk: oh; *that*. I have no idea. |
| 12:30 | <annevk> | tobie: I vaguely recall some types having (), some [], and weird ones having both |
| 12:31 | <annevk> | tobie: so object with call seems like one of those weird ones on the face of it, but I'd have to look into it more to be sure |
| 12:31 | <tobie> | annevk: what I'm trying to figure out is what do we mean when we say Function object |
| 12:32 | <annevk> | tobie: it doesn't mean alert(Function)? |
| 12:33 | <tobie> | annevk: related to https://github.com/heycam/webidl/pull/405#issuecomment-322244133 |
| 12:33 | <tobie> | annevk: no. That would be "the Function object"? |
| 12:35 | <annevk> | tobie: hmm, a built-in function object is like a normal JavaScript function that's provided by the browser somehow |
| 12:35 | <annevk> | tobie: I think the most important bit is that the implementation is hidden |
| 12:35 | <annevk> | tobie: and defined by a spec |
| 12:36 | <tobie> | annevk: so we have the notion of built-in down, that's fine. |
| 12:36 | <tobie> | annevk: the issue is around the non built-in ones. |
| 12:38 | <annevk> | tobie: I think what is called "function object" in that PR just refers to all JavaScript functions, with built-in ones being a subset |
| 12:40 | <tobie> | annevk: I want venn diagrams of all the things. |
| 12:42 | <annevk> | tobie: pretty sure that would hang your computer |
| 12:43 | <zcorpan> | MikeSmith: WDYT about the bugs about <script>/<template> in the content model? Leave the spec as is or change it as I suggested back then? |
| 12:44 | <tobie> | annevk: that PR is changing a bunch of "<emu-val>Function</emu-val> object" to "function object" and linking to https://tc39.github.io/ecma262/#sec-object-internal-methods-and-internal-slots |
| 12:45 | <tobie> | annevk: maybe we should link it to https://tc39.github.io/ecma262/#sec-terms-and-definitions-function instead? |
| 12:46 | <tobie> | annevk: tbh I'm having a hard time figuring out how the ES spec is structured. |
| 12:59 | <annevk> | tobie: the section the PR refers to has the <dfn> it seems like: "A function object is an object that supports the [[Call]] internal method." |
| 13:00 | <tobie> | annevk: agreed. Is that what we mean by "<emu-val>Function</emu-val> object" is my question, I suppose. |
| 13:01 | <annevk> | tobie: I think uppercase Function is likely to refer to global.Function |
| 13:02 | <tobie> | annevk: I don't think that's what it was doing in the WebIDL spec. |
| 13:03 | <annevk> | tobie: not sure then, perhaps conventions changed between ES5 and ES6? |
| 13:03 | <annevk> | tobie: a lot of IDL is aligned with ES5 language |
| 13:06 | <tobie> | annevk: I know. :( |
| 13:08 | <annevk> | tobie: looking at https://es5.github.io/ it seems that ES was sloppy before ES6 |
| 13:09 | <annevk> | tobie: that has stuff like "built-in Function object" |
| 13:09 | <annevk> | tobie: so IDL likely inherited a lot of that |
| 13:09 | <tobie> | \o/ |
| 13:13 | <TimothyGu> | tobie: here's what I figured out |
| 13:13 | <Domenic> | tobie: "ECMAScript Function object" is https://tc39.github.io/ecma262/#sec-ecmascript-function-objects . It is a function derived from ECMAScript source text written down by a developer. |
| 13:13 | <TimothyGu> | ^^ that :) |
| 13:14 | <Domenic> | lol sorry ^_^ |
| 13:15 | <TimothyGu> | I did try to make the distinctions between "function object" and "built-in function object" very clear, though there are some instances I'm not too sure what to link |
| 13:15 | <tobie> | Right--so Object type with [[Call]] is a superset whose elements are built-ins and ES function objects? |
| 13:15 | <TimothyGu> | yes |
| 13:15 | <Domenic> | The set also includes non-function objects who just happen to have [[Call]] |
| 13:16 | <Domenic> | Like proxies, for example |
| 13:16 | <TimothyGu> | also bound function exotic objects, proxies |
| 13:16 | <TimothyGu> | e.g. for https://heycam.github.io/webidl/#es-map-size |
| 13:16 | <Domenic> | And probably legacy-caller platform objects |
| 13:17 | <Domenic> | built-in function objects have a specific [[Call]]: https://tc39.github.io/ecma262/#sec-built-in-function-objects |
| 13:17 | <TimothyGu> | I wrote "map size getter is a [=built-in function object=]" but below I kept "The value of the [=function object=]’s “length” property" |
| 13:17 | <TimothyGu> | felt writing "built-in function object" for the second case felt a bit redundant |
| 13:17 | <tobie> | What about https://tc39.github.io/ecma262/#sec-terms-and-definitions-function? |
| 13:18 | <TimothyGu> | tobie: it's too vague IMO |
| 13:18 | <TimothyGu> | generally that section is full of vague definitions that will be defined in detail later |
| 13:19 | <tobie> | TimothyGu: sure. But aren't we precisely aiming for vagueness here? |
| 13:20 | <tobie> | TimothyGu: I mean it seems that by "function object" we sort of mean all the callable things |
| 13:20 | <TimothyGu> | well, "object with [[Call]]" is similarly broad but more precise than "member of the Object type that may be invoked as a subroutine" |
| 13:21 | <tobie> | TimothyGu: agreed. It's just ES spec doesn't really let you link to this. |
| 13:21 | <tobie> | TimothyGu: which is a common issues with the ES spec. |
| 13:21 | <TimothyGu> | yeah, that's unfortunate |
| 13:21 | <tobie> | TimothyGu: agreed. |
| 13:22 | <tobie> | So, now that everyone has provided greater context, I'm with you that "object with [[Call]]" is what we'd like to link to. |
| 13:22 | <tobie> | TimothyGu: I'm not sure how to best do that, tbh. |
| 13:23 | <tobie> | TimothyGu: I guess it depends who the intended audience of that linking is. |
| 13:23 | <TimothyGu> | we can ask tc39 to put an id there |
| 13:25 | <tobie> | TimothyGu: around here: https://tc39.github.io/ecma262/#_ref_40 ? |
| 13:26 | <tobie> | "A function object is an object that supports the [[Call]] internal method." |
| 13:26 | <TimothyGu> | yes, specifically for "function object" |
| 13:26 | <tobie> | Right, just like one of our DFNs |
| 13:26 | <TimothyGu> | yep |
| 13:26 | <tobie> | WFM. |
| 13:27 | <TimothyGu> | they have a system to do that too, e.g. https://tc39.github.io/ecma262/#global-object |
| 13:28 | <tobie> | oh, neat. |
| 13:28 | <tobie> | I'll send a PR. |
| 13:29 | <TimothyGu> | tobie: do you have an opinion on the question I posed earlier, whether to use "built-in function object" for both cases or "built-in" for the first one and just "function object" for the second? |
| 13:30 | <TimothyGu> | TimothyGu | e.g. for https://heycam.github.io/webidl/#es-map-size |
| 13:30 | <tobie> | TimothyGu: maybe not link it the second time at all? |
| 13:31 | <TimothyGu> | it's not really the linking I'm worried about but what to write |
| 13:32 | <TimothyGu> | Domenic: do you know where "length" property for built-in functions are defined in ES? |
| 13:33 | <Domenic> | Yes, there's a clause... |
| 13:34 | <TimothyGu> | I mean, I can find the one for normal ECMAScript functions but not built-in ones... |
| 13:34 | <TimothyGu> | the one for ES functions is https://tc39.github.io/ecma262/#sec-functioninitialize |
| 13:35 | <Domenic> | No, there's something that says "look at the headings"... |
| 13:35 | <Domenic> | Every built-in function object, including constructors, has a length property whose value is an integer. Unless otherwise specified, this value is equal to the largest number of named arguments shown in the subclause headings for the function description. Optional parameters (which are indicated with brackets: [ ]) or rest parameters (which are shown using the form «...name») are not included in the default argument |
| 13:35 | <Domenic> | count. |
| 13:35 | <TimothyGu> | ah found it: https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects |
| 13:35 | <tobie> | Isn't there a way to use a more imperative style here? Similar to the last steps of https://heycam.github.io/webidl/#named-constructors |
| 13:38 | <TimothyGu> | We don't use CreateBuiltinFunction at all for functions defined in the IDL spec, we should probably fix that first |
| 13:38 | <TimothyGu> | we do for IDL operations though |
| 13:38 | <Ms2ger> | There's a bug about that, I think |
| 13:38 | <TimothyGu> | ... there's a bug about everything... |
| 13:43 | <tobie> | :D :-/ |
| 13:44 | <gsnedders> | Domenic: that clause is always so hard to find |
| 13:45 | <annevk> | TimothyGu: kudos for multiple ;base64 occurrences |
| 13:47 | <TimothyGu> | 👍 |
| 14:08 | <annevk> | Domenic: I'm getting a lot of failures from Travis that are fixed after a couple restarts |
| 14:08 | <annevk> | Domenic: 'The command "curl --remote-name --fail https://resources.whatwg.org/build/deploy.sh && bash ./deploy.sh" exited with 1.' |
| 14:09 | <Domenic> | annevk: hmm so that could be a problem with the deploy script since maybe we are hiding errors? But I suspect it means resources.whatwg.org is flaky. |
| 14:09 | <annevk> | Domenic: and it always seems to be the fetching that fails |
| 14:09 | <Domenic> | Yeah OK. So, more dreamhost problems. |
| 14:10 | <annevk> | Domenic: maybe they're rate-limiting Travis? |
| 14:10 | <Domenic> | Seems unlikely... we don't deploy that often. I think I hit the various specs myself more often than Travis does. |
| 14:10 | <Domenic> | Maybe there's something in the logs though, indeed. |
| 14:12 | <Domenic> | annevk: so I'd kind of like to avoid iso-...-decode since iso-... doesn't define mappings for various bytes |
| 14:12 | <Domenic> | annevk: I liked "numeric" because it's "take the number of the byte and turn it into the number of the codepoint" |
| 14:14 | <annevk> | Domenic: wait what? it doesn't? |
| 14:14 | <annevk> | Domenic: source? http://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-1.TXT |
| 14:14 | <Domenic> | ftp://std.dkuug.dk/JTC1/sc2/wg3/docs/n411.pdf is missing several ranges |
| 14:15 | <Domenic> | Interesting! |
| 14:15 | <Domenic> | https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout matches the pdf |
| 14:16 | <Domenic> | So it looks like Unicode has a different definition of iso-8859-1 than ISO does |
| 14:16 | <gsnedders> | One of them keeps 0x80–0x9F undefined, IIRC? |
| 14:16 | <annevk> | Okay, the commonly understood meaning is that those are mapped as I understand it, although it's hard to test in browsers |
| 14:16 | <Domenic> | And 0x00-0x20 |
| 14:17 | <Domenic> | (Also 0x7F) |
| 14:17 | <Domenic> | I don't feel like there is any "common meaning" here :). Besides maybe windows-1252 :) |
| 14:17 | <annevk> | Domenic: "string convert" and "byte sequence convert"? |
| 14:17 | <Domenic> | I think that works for me |
| 14:17 | <Domenic> | I'd kind of like to use "encode"/"decode" but those are OK-ish |
| 14:18 | <annevk> | Domenic: isomorphic encode/decode? |
| 14:19 | <Domenic> | oooh |
| 14:19 | <Domenic> | that works for me. |
| 14:20 | <annevk> | cool |
| 14:26 | <annevk> | Domenic: can https://github.com/whatwg/infra/pull/145 land? |
| 14:27 | <Domenic> | annevk: I'll do one more pass |
| 16:23 | <gsnedders> | the jsDoc docs are… pretty bad, for a documentation project |
| 16:24 | <tantek> | gsnedders, are they also, by any chance, js;dr? |
| 16:25 | <gsnedders> | tantek: no, they aren't, AFAICT |
| 16:25 | <tantek> | well that's a relief at least |
| 16:33 | <nox> | Domenic: Ain't that a case of IANA ISO-8859-1 vs ISO/CEI 8859-1? |
| 16:34 | <annevk> | Domenic: resources.whatwg.org does seem super reliable to me though |
| 16:35 | <annevk> | nox: don't think so |
| 16:36 | <nox> | annevk: AFAIK the ISO/CEI one doesn't define mappings for all the bytes. |
| 16:36 | <annevk> | nox: IANA's references don't either |
| 16:37 | <Domenic> | annevk: I approved and then realized https://github.com/whatwg/infra/pull/146#issuecomment-322519502 sorry |
| 16:37 | <nox> | annevk: You sure? |
| 16:38 | <nox> | "ISO-8859-1 is the IANA preferred name for this standard when supplemented with the C0 and C1 control codes from ISO/IEC 6429 (see below for HTML5 exception). IBM calls it Code page 819 or CP819. The following other aliases are registered for ISO-8859-1: iso-ir-100, csISOLatin1, latin1, l1, IBM819. Oracle calls it WE8ISO8859P1." |
| 16:41 | <annevk> | nox: I'm not sure where that quote is from, but the references on https://www.iana.org/assignments/character-sets/character-sets.xhtml (both ISO and the RFC) don't seem to define those areas |
| 16:41 | <nox> | https://tools.ietf.org/html/rfc1345 lists ISO-8859-1 with mappings for all bytes AFAIK, but maybe I miscounted. |
| 16:41 | <annevk> | Domenic: no worries |
| 16:42 | <annevk> | nox: oh I guess it does at the end, hmm |
| 16:42 | <annevk> | nox: oh well, IANA charsets is obsoleted too so best to avoid |
| 16:43 | <nox> | I've way more often saw the ISO-8859-1 version with the 256 code points, |
| 16:43 | <nox> | than the ISO/IEC 8859-1 one with the subset of them. |
| 16:45 | <gsnedders> | the only time I see the one without the controls is when people are claiming Windows-1252 is a compliant implementation of ISO-8859-1, just giving meaning to undefined bytes |
| 16:46 | <annevk> | Domenic: should we update that note though? |
| 16:46 | <annevk> | Domenic: it's still the best advice for getting a byte sequence out of a string |
| 16:46 | <annevk> | Domenic: isomorphic encode is mostly for legacy stuff |
| 16:47 | <Domenic> | annevk: I think we should update it, even if we keep recommending UTF-8. It's just weird to see that note and then two lines down see "here's a procedure for going from strings to byte sequences" |
| 16:50 | <annevk> | Domenic: two lines down is the other procedure, but okay |
| 16:51 | <Domenic> | annevk: lgtm |
| 16:59 | <annevk> | Domenic: I really don't understand what's wrong with the build process, resources.whatwg.org responds perfectly here |
| 16:59 | <annevk> | Domenic: oh right, if it's rate-limiting by DreamHost that would be it |
| 16:59 | <Domenic> | Hmm OK, maybe a Travis-specific thing then. Maybe we can add more debugging to the script somehow |
| 18:58 | <rniwa> | annevk: drag & drop is a bean bag of bugs and interoperability nightmare :( |
| 19:19 | <annevk> | rniwa: that's UI events |
| 19:19 | <rniwa> | annevk: well, not just that but dataTransfer behavior is really inconsistent |
| 19:19 | <annevk> | rniwa: one day I want to dig in, but I keep waiting and hoping someone else does it |
| 20:19 | <Domenic> | annevk: shall we merge https://github.com/whatwg/html/pull/2869 ? |
| 20:25 | <TabAtkins> | @annevk As noted by tobie, Bikeshed auto-moves all <style> elements into the <head> automatically, because it's guaranteed to not be a behavior change. But I can't guarantee that for <script>s; you might be depending on relative ordering, or for a <script> to execute after a particular element was parsed into the DOM, and moving would break it. |
| 20:25 | <TabAtkins> | Are these your own <script> elements you're having a problem with, or something that Bikeshed is generating? |