| 02:07 | <MikeSmith> | Domenic: I figured you’d like that change |
| 02:08 | <MikeSmith> | when you have time, please test and let me know if I missed anything |
| 02:08 | <MikeSmith> | I mean for that whole PR |
| 02:08 | <MikeSmith> | all the script and style stuff |
| 02:08 | <MikeSmith> | https://github.com/validator/validator/issues/560 that is |
| 02:09 | <MikeSmith> | TabAtkins: FYI, I added integrated CSS checking of <style> contents to the HTML checker |
| 02:10 | <MikeSmith> | using the same backend code from the W3C CSS checker |
| 09:15 | <annevk> | TabAtkins: as I've said for about a decade, that data model is broken 😊 |
| 09:16 | <Ms2ger> | What's the initial value of https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#selection-direction ? |
| 09:17 | <annevk> | Ms2ger: I don't know, but it seems like it should depend on the platform |
| 09:18 | <Ms2ger> | If the platform doesn't "support that direction" (as in the next sentence), would it ever be appropriate to return "none" from the getter? |
| 09:20 | <annevk> | Ms2ger: if it doesn't support "none" I don't think it should be |
| 09:21 | Ms2ger | files an issue to clarify |
| 09:21 | <annevk> | Ms2ger: but I agree that it's a little vague in the same way your initial test was vague |
| 09:22 | <annevk> | I really hope we can at some point abstract these "depends on platform" better so it's clear what kind of variability there is (and which variability is tightly coupled) |
| 10:40 | <annevk> | tobie: I'm pretty sure https://www.w3.org/Bugs/Public/show_bug.cgi?id=23056 can be closed, but I can't find the corresponding commit |
| 10:42 | <tobie> | annevk: thanks, I'll take a look |
| 11:04 | <annevk> | tobie: speaking of IDL things, is providing "this" as a reference for spec algorithms to use on the list of priorities? |
| 11:05 | <tobie> | annevk: yes |
| 11:09 | <annevk> | tobie: also, it seems you didn't reply to https://github.com/heycam/webidl/pull/423#pullrequestreview-77122347 |
| 11:13 | <tobie> | annevk: I wasn't too sure the first part was a question or a statement. I should have asked. |
| 11:14 | <tobie> | annevk: Now I realize it probably was a request to sync. :) |
| 11:18 | <tobie> | annevk: wrt to the second part of the question, I assumed there were open issues against wpt and idlharness in https://github.com/heycam/webidl/issues/365, but there are none. |
| 11:24 | <annevk> | tobie: yeah, was just trying to get a plan of action |
| 11:25 | <annevk> | tobie: I can take more actions |
| 11:25 | <annevk> | tobie: might actually do this today and take a break from the MIME type zone |
| 11:34 | <annevk> | littledan: what would be a good name for this project so I can give it a label? |
| 11:35 | <annevk> | littledan: tobie: I'm gonna go with "needed-for-js" for now |
| 11:35 | <littledan> | I think wycatz previously looked into this, calling it "JSIDL". I like that name. |
| 11:35 | <littledan> | wycats |
| 11:35 | <annevk> | good call |
| 11:37 | <annevk> | sprinkled that label around |
| 11:37 | <littledan> | annevk, tobie, Domenic: Thanks for all your help here. Thomas Wood from ICL (@IgnoredAmbiance) is also interested in getting involved here, maybe from a standpoint of using this IDL to improve automated analyses/implementation of the JS spec. I'll send him this label; if you have any ideas for what he could work on, that would be helpful |
| 11:39 | <annevk> | littledan: it would be good to hear some of the requirements that others might have to make this successful in order to determine priorities |
| 11:40 | <annevk> | littledan: adding missing features is probably the least involved at this point; the other things require a good bit more coordination |
| 11:40 | <annevk> | littledan: and by others I mean TC39 primarily |
| 11:52 | <littledan> | We've already discussed the effort in a few forums that TC39 members can see; to reach more of them, a presentation about the problem at TC39 would probably be helpful |
| 11:52 | <littledan> | maybe Domenic is thinking of giving that; otherwise, I'd be happy to arrange for you or tobie to call in to explain the ideas and ask for feedback |
| 11:58 | <littledan> | what surprised me in the last couple days is how interested the WebIDL community is to making changes to WebIDL to make this work--this would be an important thing to communicate to TC39 |
| 11:59 | <annevk> | littledan: I see, I've always supported doing this, but to a large extent it's that we need resources to make it happen |
| 11:59 | <annevk> | littledan: in particular the syntax changes require quite a bit of dedicated effort to get right |
| 12:00 | <littledan> | which of the syntax changes seem plausible to you? |
| 12:07 | <littledan> | maybe we can find help in the TC39 community here, once the problem and areas for work are presented |
| 12:07 | <annevk> | littledan: I have some concerns with attributes, but in principle I love all of them |
| 12:07 | <annevk> | littledan: I put the attribute concerns in a new issue |
| 12:14 | <annevk> | littledan: I also like how your changes are fairly pragmatic |
| 12:15 | <annevk> | littledan: e.g., it's not "please do away with all your number types", but "alias double with Number" (and potentially drop double) |
| 12:19 | <tobie> | littledan: fwiw, I've been trying to push for convergence between roughly speaking node.js and Web JS for quite some time. In a sense, this is just underlying infra work to make that longer term, higher level goal happen. |
| 12:25 | <annevk> | That's already happening, but this would simplify it |
| 12:35 | <annevk> | tobie: I think I closed all legacy IDL bugs that could be closed |
| 12:37 | <tobie> | annevk: oh, wow! Thanks! |
| 12:58 | <Mek> | annevk: would it make sense to add an "exclude query" flag to URL serializing, or should I just copy my URL record, unset the query, and serialize that if that's the behavior I want? |
| 13:00 | <annevk> | Mek: unset for now, since it's not widespread I think, but I'd love to know where we want to lose it |
| 13:02 | <Mek> | in this case it's for blob URLs where (firefox, but not chrome) ignores query strings when resolving them. |
| 13:03 | <Mek> | but yeah, there's a couple of ways I can get that behavior without changing serialization behavior |
| 13:13 | <annevk> | Mek: maybe Firefox is wrong? |
| 13:13 | <annevk> | Mek: given that you can't get such URLs to begin with, I'm not sure why that shouldn't just be a mismatch in the store |
| 13:13 | <Mek> | yeah, looking back at the bugs filed agains blink and webkit for this and the resulting discussion that does seem like the most sensible outcome |
| 13:14 | <annevk> | yeah, consumers of exclude query just went back to 0 |
| 13:14 | <annevk> | yay* |
| 13:15 | <Mek> | Arguably the current URL spec agrees with firefox in that it only looks at url's path[0] to look up an entry in the blob URL store (which would mean query strings are ignored), but without actually having a well defiend lookup process that step is pretty ambigious anyway |
| 13:18 | <annevk> | Mek: hmm yeah, I guess the question is how the lookup should work and what is stored in the db |
| 13:48 | <annevk> | MikeSmith: that validator change broke building HTML I’m pretty sure |
| 14:49 | <littledan> | annevk: Thanks, that was my intention. I don't actually see any feature or syntax that I'd want to add which actually contradicts what WebIDL already has; at worst, things would be redundant and overlapping in confusing ways (which is really not great to have long-term) |
| 15:09 | <annevk> | littledan: any such cases also seem like something we'd want to work through and either make disappear or call one legacy and continue with the other |
| 17:25 | <TimothyGu> | littledan: what's the context on having ECMAScript use Web IDL? Is there a GitHub issue or something I can read through? |
| 17:27 | <annevk> | TimothyGu: inconsistent method definitions are appearing |
| 17:27 | <TimothyGu> | ...like? |
| 17:27 | <annevk> | TimothyGu: littledan has examples, might be Intl mostly |
| 17:28 | <annevk> | But yeah, overarching issue would be good or maybe a proposal repo |
| 17:29 | <TimothyGu> | Also I understand WebAssembly is going to use Bikeshed for its API spec... is there a repo for that yet? |
| 17:31 | <littledan> | PR for WebAssembly using WebIDL: https://github.com/WebAssembly/spec/pull/591 |
| 17:32 | <littledan> | there's no issue tying the WebIDL/ES thing all together; it is very early |
| 17:33 | <littledan> | for new ECMAScript specs, we're sticking to specific conventions and I don't think new things deviate from each other, but there's a lot of copypasta and it's difficult to author and review |
| 17:33 | <littledan> | lots of new proposals needlessly deviate early in their development by not having a clear model for what to follow |
| 17:33 | <littledan> | if we want to add to the JS standard library, I'm worried the current process won't scale |
| 17:45 | <TimothyGu> | tobie: it's not ES properties vs IDL attributes that's the difference, but how their names are used. See https://github.com/heycam/webidl/pull/483#issuecomment-349491093 |
| 17:46 | <TimothyGu> | between whether or not "'s are used |
| 17:46 | <tobie> | TimothyGu: yeah, didn't mean to imply a prop vs attr diff, but precisely how their names were used. |
| 17:47 | <TimothyGu> | tobie: wait so is <code>entries</code> what you're suggesting |
| 17:47 | <TimothyGu> | or rather <code>"entries"</code> |
| 17:48 | <TimothyGu> | or just "entries" |
| 17:48 | <tobie> | TimothyGu: so my rationale was to say that if you're saying: the x named "foo" |
| 17:49 | <tobie> | … you're really just putting quotes around a word, and there's no particular reason do mark it up specially in any other way. |
| 17:50 | <tobie> | TimothyGu: we agree that <code class=idl>foo</code> describes the idl thing itself. |
| 17:51 | <TimothyGu> | The difference being the name isn't a word. It's an identifier. That leads back to the original problem: I want to be very clear about the spacing in identifiers, and monospace font is the best way to do that |
| 17:52 | <TimothyGu> | otherwise we can get "<LF>identifier" because of automatic word wrapping rather than " identifier" as intended |
| 17:53 | <tobie> | TimothyGu: but those aren't identifiers, they're JS (infra) strings, no? |
| 17:54 | <tobie> | TimothyGu: there's a difference between saying: the x named "foo" and the value of x is (the string) "<code>foo</foo>" |
| 17:55 | <TimothyGu> | I'm not sure we are talking about the same thing |
| 17:55 | <tobie> | TimothyGu: we're not (that's what what I'm failing to point out) |
| 17:56 | TimothyGu | deep breathe |
| 17:56 | <TimothyGu> | so there are a few scenarios. I'm going to list all of them out, and you tell me what you think should be the case |
| 17:57 | <TimothyGu> | 1. Call the then property of |O|. |
| 17:57 | <tobie> | TimothyGu: the spacing issue arose in what is clearly a string (https://heycam.github.io/webidl/#ref-for-dfn-class-string) |
| 17:57 | <TimothyGu> | 2. If |O| has a property called then |
| 17:57 | <TimothyGu> | 3. If |str| is "then" |
| 17:58 | <TimothyGu> | tobie: yes, but it's concatenating an identifier with a string, which is implicitly saying that identifiers *are* strings |
| 17:59 | <tobie> | TimothyGu: well, well, well... |
| 18:00 | <TimothyGu> | or is that a stretch |
| 18:00 | <tobie> | TimothyGu: Frankly, that's questionable either way |
| 18:00 | <tobie> | But let me address your 1-3 examples first |
| 18:00 | <annevk> | Domenic: encodeURI is close to USVString, but not close enough |
| 18:00 | <TimothyGu> | and to make things worse property names in JS are strings, not identifiers, while they in IDL are identifiers, not strings |
| 18:01 | <tobie> | so (3) is clearly: If |str| is "<code>then</code>" |
| 18:02 | <tobie> | (1) should be: Call the <code class=idl>then</code> property of |O|. (to follow the ES convention) |
| 18:03 | <tobie> | (2) I find weird and I think it the contentious one. |
| 18:04 | <tobie> | If we said something like: If |O| has a property whose identifier is then |
| 18:05 | <TimothyGu> | that would only work for a subset, since JS property names can have spaces in them |
| 18:06 | <tobie> | I was suggesting these should be quoted: "then" |
| 18:06 | <TimothyGu> | Agreed on the quoted. But should there be <code>? |
| 18:07 | <tobie> | so: If |O| has a property called "then" |
| 18:07 | <tobie> | possibly |
| 18:07 | <tobie> | but then not with class=idl |
| 18:07 | <TimothyGu> | hmm |
| 18:08 | <tobie> | because we're really referring to them as either a string or just a quoted piece of text |
| 18:08 | <tobie> | not as an idl thing |
| 18:08 | <tobie> | for example, you could write: |
| 18:08 | <annevk> | Is there no precedent in ECMAScript to follow? |
| 18:09 | <TimothyGu> | annevk: there are, but ES doesn't have the <code class=idl> vs <code> distinction. |
| 18:09 | <tobie> | let |k| be the string "<code>foo</foo>" |
| 18:09 | <tobie> | call the property |k| of |O| |
| 18:10 | <tobie> | you don't really know that k is going to be used as an idl prop until it is |
| 18:10 | <TimothyGu> | That makes sense |
| 18:10 | <TimothyGu> | So the *definitions* in the spec currently follow the form "a property named “forEach” must exist with attributes" |
| 18:10 | <tobie> | So I don't really have an opinion as to whether these should be "<code>txt</code>" or just "txt", |
| 18:11 | <annevk> | I see, I guess I didn't know about class=idl |
| 18:11 | <tobie> | but I don't like the class=idl part |
| 18:11 | <TimothyGu> | would it be better to have "a <code class=idl>forEach</code> property must exist with attributes", or "a property named "<code>forEach</code>" must exist with attributes" |
| 18:12 | <annevk> | TimothyGu: I'd go with the former |
| 18:12 | <tobie> | I don't really care either way |
| 18:12 | <tobie> | wfm |
| 18:12 | <TimothyGu> | k |
| 18:13 | <tobie> | TimothyGu: thanks a bunch, I'll merge this as soon as you fix it |
| 18:14 | <TimothyGu> | I'll come back to this later. there's a wildfire burning 3km from me |
| 18:16 | <TimothyGu> | and the power just went out |
| 18:32 | <annevk> | TimothyGu: shit, take care |
| 18:32 | <TimothyGu> | thanks |
| 18:52 | <TimothyGu> | tobie: one last question: what about: an interface named "abc" |
| 18:53 | <TimothyGu> | I'll go with "<code>abc</abc>" |
| 18:56 | <TimothyGu> | and what about: the identifier "abc"? I'm going with: the identifier "<code class=idl>abc</code>" but you might have different opinions |
| 19:09 | <tobie> | ES uses: https://tc39.github.io/ecma262/#sec-identifiers-static-semantics-early-errors |
| 19:09 | <tobie> | TimothyGu: ^ |
| 19:11 | <tobie> | TimothyGu: so <code>"txt"</code> |
| 19:12 | <tobie> | We should probably just used: "<code>txt</code>" |
| 19:12 | <tobie> | Here again, it's just a string |
| 19:14 | <TimothyGu> | ah |
| 19:47 | <Domenic> | Oh no, don't catch on fire TimothyGu, that would be bad. |
| 19:47 | <TimothyGu> | lol indeed |
| 19:54 | <gsnedders> | I don't have any personal experience of catching on fire, but I imagine it wouldn't be greate. |
| 19:54 | <gsnedders> | *great |