| 04:22 | <MikeSmith> | TabAtkins: wondering what should be done about https://lists.w3.org/Archives/Public/www-archive/2016Oct/0009.html (change to allow child-index pseudos to select unparented elements) |
| 04:23 | <MikeSmith> | TabAtkins: even though the spec change was made more than 3 years ago, Gecko is the only engine that has changed to match the spec change |
| 04:24 | <MikeSmith> | wondering if at least there are browser bugs open for rest |
| 04:41 | <MikeSmith> | raised https://github.com/w3c/csswg-drafts/issues/695 |
| 10:45 | <zcorpan> | is there a reason html has data-file-issue-url=https://whatwg.org/newbug rather than having the link go straight to github without a redirect? |
| 10:48 | <annevk> | zcorpan: I suspect to advertise the shortlinks |
| 10:50 | <annevk> | tobie: https://github.com/heycam/webidl/pull/211 is no longer waiting on me, right? |
| 10:51 | <annevk> | tobie: we should probably move bz's data to the SameObject issue, I suppose I could do that |
| 11:04 | <smaug> | there isn't any target value to target the opener, right? anything like <a href="foo.html" target="_opener">? |
| 11:05 | <ondras> | I am not aware of any. |
| 11:27 | <annevk> | smaug: don't think so |
| 11:28 | <smaug> | k, thanks |
| 11:36 | <tobie> | annevk: unassigned you. |
| 12:35 | <tobie> | TabAtkins: argue you should choose between dfn and algorithm attribute value to name algos and deprecate the other one. |
| 12:35 | <tobie> | TabAtkins: it's really confusing to have both |
| 12:40 | <zcorpan> | annevk: https://html.spec.whatwg.org/multipage/not_found.html the source here doesn't match that of https://github.com/whatwg/html/blob/master/404.html - what gives? (I was going to change the script src to /link-fixup.js) |
| 13:02 | <zcorpan> | i have an urge to change link-fixup.js to XHR /multipage/fragment-links.json so the browser doesn't need to download and compile a 2.8MB script that then typically no-ops |
| 13:13 | <Ms2ger> | Good call |
| 13:21 | <MikeSmith> | seconded |
| 13:40 | <annevk> | zcorpan: it looks like multipage has its own 404 and .htaccess |
| 13:47 | <annevk> | zcorpan: but locally that does not appear to be the case, so maybe the folder on the server is not properly cleared? |
| 13:51 | <annevk> | zcorpan: it seems the build script on the server uses rsync, so that might be the issue |
| 13:52 | <annevk> | zcorpan: we don't use rsync with --delete |
| 13:53 | <zcorpan> | annevk: ok |
| 13:53 | <annevk> | zcorpan: filed an issue, copied you |
| 13:54 | <annevk> | zcorpan: would like input from Domenic since he set this up |
| 13:55 | <zcorpan> | thx |
| 17:16 | <TabAtkins> | MikeSmith: It's a necessary change to get sane results from querySelector() on a DocumentFragment (as bz argued in the email that prompted the change). Theoretically we could match browsers closer by making it match things with *Element or DocumentFragment* parents, but that's just ridiculous. |
| 17:16 | <TabAtkins> | tobie: Agree, honestly. Been considering how best to handle this, as I want to add in the algo arguments soon. |
| 17:17 | <MikeSmith> | ok given that then it seems like to get interop on it we should at least have browser bugs open for getting the the implementations to update to the current spec |
| 17:17 | <TabAtkins> | What I think I'll do is add an attribute to <dfn> that designates it the naming dfn for the algorithm, so you get the right behavior even if there are 2+ dfns in the block. Then issue an unskippable warning for manually-named algos that they should switch to using a <dfn> to name themselves. |
| 17:17 | <TabAtkins> | MikeSmith: Yes. |
| 17:18 | <MikeSmith> | in general seems like we need some more systematic way of getting bugs raised in cases like this one |
| 17:18 | MikeSmith | has no brilliant ideas how to do that |
| 17:24 | <tobie> | TabAtkins: multiple DFNs per algos don't bother me per se. (Never had the use case personally.) |
| 17:24 | <TabAtkins> | tobie: It's not unusual. You just happen to define more than one thing in an area. |
| 17:25 | <tobie> | TabAtkins: OK. |
| 17:27 | <tobie> | TabAtkins: we're trying to move to more TC-39 like naming for algorithms in WebIDL which you can then Call(with, args...) |
| 17:27 | <annevk> | Domenic: do you know if there are any missing custom element tests? |
| 17:28 | <annevk> | botie: ask rniwa if there are any missing custom element or shadow tree tests? |
| 17:28 | <botie> | will do |
| 17:28 | <tobie> | TabAtkins: so UpperCamelCase. |
| 17:29 | <annevk> | tobie: use <dfn abstract-op> to preserve the case |
| 17:29 | <tobie> | annevk: oh |
| 19:33 | <Domenic> | annevk: what do you mean "missing"? |
| 19:36 | <annevk> | Domenic: stuff that needs to be written |
| 19:37 | <annevk> | Domenic: Mozilla might have some resources |
| 19:50 | <tobie> | TabAtkins: how do you link to an abstract op, though? <a></a>? |
| 19:50 | <tobie> | TabAtkins: no shortcut? |
| 19:51 | <TabAtkins> | <a abstract-op>. I haven't added a shortcut yet, because nobody's expressed a preference in the syntax. Let me go dig up the issue real quick. |
| 19:51 | <TabAtkins> | https://github.com/tabatkins/bikeshed/issues/809 |
| 19:53 | <tobie> | TabAtkins: Thanks. Can you do (!|?)identifier(args) as a shortcut? And do all of the !? magic linking while you're at it? |
| 19:54 | <TabAtkins> | What's all this? |
| 19:54 | <tobie> | TabAtkins: also ponies would be nice |
| 19:54 | <tobie> | TabAtkins: iirc ? throws, ! doesn't throw |
| 19:55 | <TabAtkins> | Oh, I have an long-term issue to support ecmarkup. |
| 19:56 | <tobie> | TabAtkins: I was suggesting to use ! or ? as your shorthand prefix and (...) as suffix |
| 19:56 | <tobie> | TabAtkins: but that is probably too magical |
| 19:56 | <Domenic> | annevk: I guess there might be a gap in testing [CEReactions] for customized built-ins |
| 20:46 | <zcorpan> | Domenic: i don't know how the server setup works. will things just work if the link-fixup PRs are merged, or is something more necessary? |
| 20:46 | <Domenic> | zcorpan: supposedly it will but sometimes i need to poke it. Let me know when you merge things and I'll ensure things are straightened out on the backend |
| 20:48 | <zcorpan> | Domenic: ok. i suppose someone should review first |
| 20:50 | <zcorpan> | MikeSmith: you r+ed the wattsi PR; could you review the other two also? :-) |
| 20:54 | <tobie> | Hey Domenic, saw your comment about UpperCase vs. English phrases and would like to understand your thoughts better around this. |
| 20:54 | <Domenic> | tobie: sure. |
| 20:55 | <Domenic> | Anything in particular? |
| 20:55 | <tobie> | Domenic: so I'm working on https://www.w3.org/Bugs/Public/show_bug.cgi?id=22859 right now |
| 20:56 | <tobie> | Domenic: and not only does this bring in more CamelCase notation |
| 20:57 | <tobie> | Domenic: it also revealed that ES6 no longer defines "sign" |
| 20:57 | <Domenic> | hah wow really? |
| 20:57 | <tobie> | at least I couldn't find it |
| 20:57 | <Domenic> | yeah apparently so |
| 20:57 | <tobie> | ironically they're using prose for this now |
| 20:59 | <Domenic> | So in my mind using existing PascalCase abstract ops is not a problem |
| 20:59 | <tobie> | So my first reflex was to create an abstract ops for that: https://gist.github.com/tobie/cf495a00600d904769c30fce05c0069f |
| 20:59 | <Domenic> | But it's a little strange that Web IDL exports a bunch of algorithms with English names, like most web specs |
| 20:59 | <Domenic> | And then starts exporting a few with PascalCase notation |
| 20:59 | <zcorpan> | Domenic: \o/ OK let's do this |
| 21:00 | <tobie> | Domenic: PascalCase--couldn't remember the name |
| 21:00 | <tobie> | Domenic: ok, so that's where you draw the line |
| 21:00 | <Domenic> | It's not a big deal, and Web IDL is a strange case anyway |
| 21:01 | <Domenic> | E.g. it makes perfect sense to me to have LegacyPlatformObjectGetOwnProperty or whatever it's called |
| 21:01 | <Domenic> | But that's not exported so I feel a bit better |
| 21:02 | <tobie> | Domenic: OK, so you sort of see WebIDL as a cushion between JS and the Web |
| 21:02 | <tobie> | Domenic: I can work with that. |
| 21:03 | <Domenic> | Yeah, basically. There's a valid debate to be had about whether we should be cushioning the web from JS, or at least, whether we should be cushioning it from JS notation. |
| 21:03 | <Domenic> | Maybe all specs should switch to PascalCaseFunctionCall(a, b, c) instead of "perform the operation given a, b, and c" |
| 21:03 | <Domenic> | But I'm a little leery of starting that conversion right here |
| 21:05 | <tobie> | Domenic: tbh, I'm not sure if there's a proper venue for this conversation to be productive |
| 21:05 | <TabAtkins> | I prefer the prose names, fwiw. |
| 21:05 | <zcorpan> | Domenic: ok all merged |
| 21:05 | <Domenic> | zcorpan: great. Apparently the server did not recompile wattsi automatically... I've run into this in the past. Manually doing so now. |
| 21:06 | <zcorpan> | thx |
| 21:07 | <tobie> | TabAtkins: yeah, it's not the PascalCasing I'm after, it's the [abstract ops name](arguments) construct. |
| 21:07 | <TabAtkins> | Why is that better? It's not unusual for my algo invocations to use values that don't easily lend themselves to that formal syntax. |
| 21:08 | <TabAtkins> | Plus, it leans us toward ordered arguments, rather than named, which is always fragile, but *especially* so when it's cross-domain calls like this. |
| 21:08 | <TabAtkins> | The Bikeshed syntax is going to be named-argument based. |
| 21:08 | <tobie> | TabAtkins: I just think it reads better and is more explicit about what's going on |
| 21:09 | <tobie> | TabAtkins: do you have pointers as to how that's going to look? |
| 21:09 | <TabAtkins> | I don't see how "Let |foo| be the result of SomeOp(|bar|, |baz|)" is more explicit than "Let |foo| be the result of <a>doing the op</a> with |bar| and |baz|". |
| 21:09 | <TabAtkins> | tobie: I don't yet, but I'm happy to draw up my plans in an issue. |
| 21:10 | <tobie> | TabAtkins: I'd like that |
| 21:10 | <tobie> | TabAtkins: I'm basically in need of more organization and structure in the WebIDL spec and the only model I have given the problem domain is the ES spec |
| 21:11 | <TabAtkins> | Which is, imo, one of the least readable specs in existence. ^_^ |
| 21:11 | <TabAtkins> | Precise, but extremely unreadable. |
| 21:12 | <tobie> | TabAtkins: yeah—I'm not arguing this is a _good_ model. |
| 21:14 | <tobie> | TabAtkins: as an aside, I've found the borders around the algorithm extremely helpful to visualize the overall structure of the spec |
| 21:14 | <TabAtkins> | Yeah, me too. |
| 21:14 | <tobie> | TabAtkins: similarly, the scroll-spy script I added helped a lot |
| 21:14 | <TabAtkins> | ? |
| 21:15 | <TabAtkins> | Oh, I see it! |
| 21:15 | <TabAtkins> | Ah, that's pretty cool. I wouldn't mind building that into Bikeshed. |
| 21:15 | <tobie> | TabAtkins: I've opened an issue against tr-design |
| 21:15 | <tobie> | TabAtkins: https://github.com/w3c/tr-design/issues/108 |
| 21:16 | <Domenic> | zcorpan: is it just me or are the browser-logos 200ing each time instead of 304ing |
| 21:16 | <Domenic> | Hmm Chrome says "from memory cache" though so something's going on there |
| 21:17 | <Domenic> | Meh probably devtools somehow |
| 21:18 | <Domenic> | So happy we have the section self-links now, thanks annevk |
| 21:18 | <tobie> | TabAtkins: so I'm basically hungry for something that lets me define the algorithm and call them in a way that's super clear |
| 21:19 | <tobie> | TabAtkins: whether that's PascalCasing or something else it secondary. |
| 21:20 | <tobie> | *is |
| 21:20 | <TabAtkins> | Right. Will write up in a few, finishing up a feature right now. |
| 21:24 | <zcorpan> | Domenic: images have a special cache, maybe that's why devtools are saying 200 |
| 21:25 | <Domenic> | tobie: reviewing legacy platform objects now btw |
| 21:50 | <gsnedders> | TabAtkins, tobie: the harder problem, which I think is more needed, is *not* have unintended side-effects, or access other variables from some implicit scope |
| 21:51 | <tobie> | gsnedders: yes. Pure functions ftw. |
| 21:55 | <gsnedders> | I've been wondering about trying to prove properties in such functions again. |
| 21:55 | <zcorpan> | is the "too slow?" alert helping anyone? i think the dialog itself is slowing down loading of the single-page spec |
| 21:57 | <gsnedders> | I wonder if that is partly the opacity? |
| 21:57 | <Domenic> | zcorpan: I hates it but I imagine some newbies who accidentally ended up on singlepage might use it |
| 21:57 | <zcorpan> | it's fixed-pos but still causes layout invalidation in chromium for some reason. maybe selectors need to be reevaluated |
| 22:01 | <zcorpan> | Domenic: how about we make the "Multipage Version" link stand out a lot more in the single-page version, and remove the alert |
| 22:02 | <Domenic> | zcorpan: sounds plausible |
| 22:05 | <gsnedders> | zcorpan: an extreme solution would be redirect to multipage, unless there's a cookie for the single-page |
| 22:05 | <gsnedders> | zcorpan: given I expect relatively few people actually want the single page |
| 22:05 | <TabAtkins> | Yes, single-page sucks and I hate it. |
| 22:06 | <TabAtkins> | Except for the rare use-case of "I want to ctrl-F the entire spec for something" |
| 22:06 | <zcorpan> | gsnedders: might actually be a good idea |
| 22:08 | <gsnedders> | I think it's probably actually the best option |
| 22:08 | <gsnedders> | because I expect almost nobody wants the single page apart from a few of us in here |
| 22:11 | <Domenic> | dislike |
| 22:11 | <Domenic> | I think a lot of implementers and spec developers want the single-page |
| 22:16 | <MikeSmith> | yeah a lot people cite the single-page version |
| 22:16 | <Domenic> | annevk: ping for tests for https://github.com/whatwg/html/pull/1986 |
| 22:16 | <botie> | will do |
| 22:17 | <MikeSmith> | hey is there not some query param that somebody can append to the spec URL to get the developer-only view? |
| 22:17 | <MikeSmith> | I have forgotten |
| 22:18 | <Domenic> | no :( |
| 22:18 | <MikeSmith> | oh |
| 22:18 | <MikeSmith> | we removed all the JS and CSS for that too? |
| 22:18 | <MikeSmith> | I thought I saw it was still there |
| 22:19 | <MikeSmith> | where in the olden times there were was button at the top of the spec to get the developer-only view |
| 22:19 | <Domenic> | MikeSmith: https://github.com/whatwg/wattsi/issues/27 |
| 22:19 | MikeSmith | looks |
| 22:19 | <Domenic> | MikeSmith: an outdated version still exists at developers.whatwg.org |
| 22:19 | <Domenic> | But we don't link to it anymore since it's outdated |
| 22:20 | <MikeSmith> | oh yeah |
| 22:20 | <MikeSmith> | I remember this wattsi issue now |
| 22:20 | <MikeSmith> | I guess I should work on that |
| 22:20 | <Domenic> | Yeah. And maybe we don't need perfect parity with the existing one and should just be happy with what's created |
| 22:21 | <Domenic> | e.g. just accept the new splitting |
| 22:21 | <gsnedders> | Domenic: but won't most implementers and spec developers already have the single-page-allowing cookie? |
| 22:21 | <Domenic> | gsnedders: how would they get such a cookie? |
| 22:21 | <Domenic> | gsnedders: and what if they get/use a new computer? |
| 22:21 | <gsnedders> | Domenic: load spec, click link to single page, get cookie |
| 22:21 | <gsnedders> | Domenic: but that's relatively rare |
| 22:31 | <TabAtkins> | Oh man, I finally figured out why the ToC jiggles sometimes in Bikeshed specs (and fixed it). |
| 22:31 | <TabAtkins> | Frickin' border-width rounding. |
| 22:32 | <TabAtkins> | So going from "border-width: 1px" to "border-width: 3px; margin: -2px" doesn't necessarily result in an identical layout size, depending on your DPI. |
| 22:34 | <gsnedders> | wat. |
| 22:35 | <TabAtkins> | border sizes have to round to exact hardware-pixel sizes, so you don't get banding! |
| 22:35 | <gsnedders> | oh, and the fact that most things don't use 1:1 or 1:4 rounding nowadays, duh |
| 22:35 | <gsnedders> | soz, all the HiDPI stuff I have uses 1:4 |
| 22:36 | <TabAtkins> | Well, and my spec window on my work computer uses 90% zoom, to make it small enough to trigger the sidebar ToC. |
| 22:36 | <gsnedders> | Ah, that doesn't help :) |
| 22:36 | <TabAtkins> | Was wondering why the computed value of border was 1.1111111px ^_^ |
| 22:51 | <zcorpan> | hmm i accidentally removed the reload preventor. does it work? can't recall seeing it |
| 22:52 | <Domenic> | yeah me neitehr |
| 22:53 | <Domenic> | maybe browsers stopped firing key events for that |
| 22:56 | <gsnedders> | so: what are some interesting, complex functions/operations/whatever-we-want-to-call-them in specs that might be interesting to look at with formal methods? |
| 23:01 | <Domenic> | for what purpose? |
| 23:54 | <smaug> | Google docs uses Flash o_O |
| 23:54 | <smaug> | well, spreadsheets |