2018-06-01 [18:49:28.0000] "into document" is the bit you omitted from your quote that's rather key there [19:42:05.0000] astearns: so about the github/w3c perms, if I understand correctly, the thing that blocks you is that you can’t on your own add people to github/w3c teams unless they’re already members of the w3c org? [19:50:09.0000] I think for any repo where you have Admin perms, you can still add anybody you want as a CollaboratorーI mean without adding them to a Team [19:51:45.0000] to me, using github teams seems like overkill unless you have multiple repos that you want to give the same set of people write access to (like we do with web-platform-tests) [19:54:56.0000] They have multiple repos though [19:55:32.0000] Less than I’d like, but more than one [20:02:45.0000] MikeSmith: You are correct. I can add random people as collaborators, but the current set are official CSSWG members, so I think it makes sense to add them to the org [20:03:36.0000] astearns: OK [20:06:14.0000] annevk: you mean web-platform-tests has multiple repos? and it should have more? [20:06:50.0000] MikeSmith: I meant CSS [20:06:55.0000] ah [20:06:57.0000] yeah [20:07:05.0000] Might have missed some context [20:07:11.0000] no [20:07:21.0000] that was the original context [20:07:36.0000] but IMHO too yeah CSS should have more repos [20:09:19.0000] anyway as far as the thing about giving perms for a repo Admin adding members to the w3c org, as far as I can see the only way to do that is by giving Admin (Owner?) perms for the entire w3c org [20:10:07.0000] and one reason for not being able to do that is, there are some private repos in the org, so it would also mean exposing those to them [20:11:45.0000] but I guess one way to deal with that particular part would be to move those private repos to a different org, e.g., w3c-private or whatever [20:12:43.0000] but even if we did that, the other people would still have complete owner/admin perms for changing whatever they wanted in org config, and blocking users org-wide, etc. [20:13:12.0000] summary: it’s complicated :) [20:13:15.0000] MikeSmith: if associating a W3C account with a github handle would automatically invite people to the W3C github org, then I think my particular problem would be solved. Tab suggested this on sysreq [20:13:23.0000] yes [20:13:33.0000] I will follow up with the systeam about that [20:14:09.0000] since it’s their tool that does the W3C-account association [02:46:08.0000] ok folks, which text editor should I switch to (on macOS)? [02:47:48.0000] vim [02:48:18.0000] I like rectangular selection and multiple cursors, multi-file regexp search & replace [02:49:35.0000] vim has rectangular selection built in [02:50:15.0000] multi-file regexp search & replace I reckon it either has built in or there’s some plugin [02:50:31.0000] multiple cursors I dunno [02:51:15.0000] personally for multi-file regexp search & replace I just use perl from the shell [03:23:02.0000] https://github.com/w3c/payment-request/pull/715 seems like a useful template we could use for PRs [03:23:37.0000] https://blog.github.com/2016-02-17-issue-and-pull-request-templates/ [03:23:47.0000] annevk: Domenic: foolip: thoughts? [03:25:10.0000] https://github.com/w3c/payment-request/blob/gh-pages/.github/PULL_REQUEST_TEMPLATE.md is the template [03:30:43.0000] zcorpan: might be worth considering [03:31:36.0000] zcorpan: if we make it a little clearer they don't all have to be completed before the PR is created that might be better [03:32:00.0000] zcorpan: but we also get a lot of editorial contributions, for which a lot of this would be noise [03:32:03.0000] so hmm [03:43:00.0000] zcorpan: I use Sublime Text, but no idea if it has all those features [03:43:33.0000] I used to use TextWrangler, but it couldn't handle "source" very well [03:59:46.0000] annevk: yeah I want to switch away from TextWrangler/BBEdit [04:00:20.0000] https://www.sublimetext.com/ demos multiple selections [04:04:52.0000] I'll give this a try [04:38:44.0000] MikeSmith: vim seems intimidating but several people recommend it. I just never feel like hitting a steep learning curve, but maybe sometime I'll give it a try [04:45:32.0000] zcorpan: GVim can help make it less intimidating [04:46:13.0000] it’s a GUI program that runs outside the shell [04:47:02.0000] with default settings for easier use with a mouse instead of keyboard shortcuts [04:47:59.0000] e.g., normal simple visual selection with a mouse [04:48:54.0000] which is something that’s not such a great feature that you actually want if you’re running in a shell instead [05:02:12.0000] With WPT, I find myself writing a lot of code to get information about a request the browser made (using the stash). Am I missing an easier way? It'd be nice if I could just query the server log, or use EventSource to get information about requests to a particular URL. [05:05:10.0000] Currently I stash it (https://github.com/jakearchibald/web-platform-tests/blob/accept-encoding-range/fetch/range/resources/long-wav.py#L57) then create an endpoint to read from the stash (https://github.com/jakearchibald/web-platform-tests/blob/accept-encoding-range/fetch/range/resources/stash-take.py) [05:08:27.0000] I'd love to just monitorRequest(url) and get a stream of requests to that URL [05:11:58.0000] Better hope that nobody else is using that URL in parallel [05:12:18.0000] Same problem exists with the stash [05:13:36.0000] I guess you could enforce something like a token in the URL [05:14:13.0000] JakeA: you're supposed to mint a token for stash [05:14:41.0000] JakeA: token() from /common/utils.js is what's typically used [05:16:03.0000] annevk: yeah, that's what I do. monitorRequest could enforce a similar thing if needed. Or: const [urlWithToken, stream] = createMonitoredUrl(url) [05:17:20.0000] JakeA: I guess if we abuse the path bit of a stash and use a token as the path as well we could write a get_stash.py and have some kind of JavaScript utility on top [05:18:06.0000] JakeA: so the user has to write a Python script that takes a token and stores the stuff they care about, but doesn't need to have retrieval logic [05:18:33.0000] JakeA: not sure how much that ends up simplifying though [05:18:39.0000] annevk: A generic retrieval endpoint would be great, but that's usually the easy part [05:19:23.0000] JakeA: https://github.com/web-platform-tests/wpt/pull/11164/files is my first stash thingy [05:19:51.0000] JakeA: I'm not sure how much can be abstracted there, other than doing the second request and getting the stash value [05:21:00.0000] Oh, and I forgot I retrieve the stash value as JSON, that wouldn't work as a generic [05:21:14.0000] Well, maybe it would, if everyone obeyed [05:23:01.0000] annevk: with aborting & the range request stuff, I keep wanting to answer questions like: What headers did the browser send? Did the browser actually make a request? Did it follow the redirect? A stream from the server would make this a lot easier. I agree I'd have to make the monitored URLs unique for the test. [05:24:21.0000] JakeA: it seems we could do that, by dumping all the request data in the stash [05:24:40.0000] JakeA: I guess one question there is when can you retrieve it [05:25:33.0000] annevk: yeah, that's a problem I have today. [05:25:34.0000] JakeA: but when the request / response finishes or errors that's probably good enough? [05:26:13.0000] My script does the redirect thing btw and it does store data from the request, just not that much [05:26:38.0000] annevk: yeah, although each API has a different way of telling you that. And with media, "finished" is a bit late. [05:26:57.0000] annevk: to clarify, I've done what I need to do. I just feel it's a pain each time I need to do it. [05:28:03.0000] JakeA: we could file an issue I suppose [05:28:18.0000] I can write it up [05:28:48.0000] It might only be a problem I've had because of the kind of fetch tests I've been writing recently [05:28:49.0000] JakeA: basically what you want is having a handle on an EventSource/WebSocket endpoint to write data to as requests come in [05:29:26.0000] annevk: that's what I said 😀 [05:29:52.0000] It'd be easy to create a stream from either, which would work better in promise tests [05:29:59.0000] Yeah sorry, was trying to restate it [05:31:27.0000] That kind of setup would greatly simplify a lot of CORS tests too I think [05:31:39.0000] E.g., did the preflight happen, did it have the right headers, etc. [05:32:00.0000] Ohh yeah, I imagine they have exactly the same issues. [05:32:21.0000] With redirects you want to monitor more than one url, but I guess you can create multiple monitors [05:33:10.0000] Although there may be cases where it's difficult to make sure the same token is in each URL [05:34:09.0000] JakeA: you can redirect to the same path on a different server and forward the token (that's what I do) [05:34:29.0000] JakeA: if the EventSource/WebSocket handle is token-based that would work [05:34:43.0000] annevk: Yeah, I was wondering about cases where the token might be stripped, but I can't think of any [05:35:21.0000] As long as you can put it in the URL it's okay [05:35:42.0000] I guess that means you can't quite test /favicon.ico and such with this [05:36:53.0000] Hmm yeah. Maybe you want a monitorUrl(url, { noTokenIKnowWhatImDoing: true }) for cases where having a token just wouldn't work [05:47:07.0000] Well, the problem with that is that you cannot have multiple requests [05:48:29.0000] Maybe instead the setup could be that register a set of paths to monitor and you just get all the request objects handed to you [05:49:51.0000] Allowing an array of URLs is important for determining order I suppose [05:52:41.0000] annevk: https://github.com/web-platform-tests/wpt/issues/11298 [07:43:29.0000] is the filesystem api expected to gain traction [08:04:02.0000] oh heh it died like 5 years ago [09:57:06.0000] MikeSmith: Command-line support for highlighter should be working now. Just execute highlighter/__init__.py. Run it with -h flag to get information on the arguments you can pass. Basic usage is `__init__.py webidl < input_file.json > highlighted_output.json`. [09:57:32.0000] The output will be a JSON object with `html` and `css` keys. [15:20:44.0000] Is there a way to stop getting email about a bug I reported to Firefox Bugzilla? [15:21:08.0000] Watching patches and reviews fly by is not that interesting [15:38:43.0000] Domenic: only way I know of is to go into https://bugzilla.mozilla.org/userprefs.cgi?tab=email and uncheck some stuff under Reporter [15:39:21.0000] but of course that will affect notifications on all bugs you reported, no just that one [15:40:06.0000] Hmm OK :-/. I guess email-client-level filtering is probably the way to go. [15:40:07.0000] TabAtkins: yee-hahー will try it again this weekend [15:43:09.0000] Domenic: yeah, though this case makes me think the e-mail preferences could be enhanced with by adding a new row with "A comment is added for a patch" or whatever [16:17:54.0000] devsnek: https://wicg.github.io/entries-api/ is the replacement for that [16:17:59.0000] File and Directory Entries API [16:18:19.0000] I think that’s actually implemented in all four browser engines [16:18:23.0000] hype [16:18:29.0000] does that have writing files too [16:18:42.0000] no [16:18:50.0000] well not as far as I know [16:18:56.0000] hmm [16:18:59.0000] jsbell would be the one to ask for details [16:19:04.0000] i suppose i'll read through it [16:19:14.0000] i want to do something spec-ish for file operations in my runtime [16:20:48.0000] why does the spec include engine-specific properties [16:22:22.0000] devsnek: dunno but jsbell can certainly shed some light when he’s around [16:22:44.0000] but there’s also https://github.com/WICG/entries-api/blob/gh-pages/EXPLAINER.md [16:24:50.0000] thx [16:52:24.0000] Domenic: if it isn't too much trouble could i bother you about my url implementation? 2018-06-03 [01:12:13.0000] does anyone know what task source we're supposed to use when queuing a PromiseRejectionEvent? [01:12:14.0000] https://html.spec.whatwg.org/multipage/webappapis.html#notify-about-rejected-promises [01:58:23.0000] KiChjang: I think someone opened a bug about this... Or maybe it was just Blink engineers asking me internally... Anyway use the DOM manipulation task source (basically the default) and please file a bug so I can fix. [01:58:35.0000] gotcha [01:58:42.0000] that's what i thought as well\ [01:58:53.0000] the DOM manipulation task source is the closest thing that makes sense [02:15:51.0000] https://github.com/whatwg/html/issues/3731 2018-06-04 [18:42:27.0000] Domenic++ [18:44:24.0000] FTR, I just touched a bunch of old wpt tickets about URL [18:44:47.0000] there aren't too many that are still open, which is cool [18:44:54.0000] https://github.com/web-platform-tests/wpt/labels/url [18:46:10.0000] Not bad [18:48:28.0000] https://github.com/web-platform-tests/wpt/issues/11218 is kind of depressing [21:13:12.0000] Yeah, there is a real problem there. PSL maintainers saying it need not be relied upon and nobody else heeding their advice. [00:52:00.0000] annevk: Ryan's going to be in Zurich next week. I might be there as well. Maybe we can get coffee and argue about the PSL a bit. [00:56:14.0000] mkwst: that'd bad timing, it's Mozilla week in SF [00:56:27.0000] Oh. :( [00:56:35.0000] Mozilla week somehow didn't make it onto my calendar. :) [00:56:50.0000] mkwst: would have loved to though, it's a rather intriguing mismatch between the maintainers and how it's used [00:57:45.0000] I think he's in London this week for CA/B. [00:58:04.0000] Maybe we can set up a call or something. I don't really understand his position, though I agree with what I imagine it' [00:58:13.0000] its philosophical underpinnings might be. [01:02:14.0000] mkwst: sounds good to me, available 9-5 daily and 7-8 if we cannot make it work otherwise [01:40:02.0000] annevk: I'll ping Ryan and see if he can carve out some time. [01:54:41.0000] mkwst: should we wait for this meeting before proceeding with the URL PR? [01:56:16.0000] annevk: Meh. I think we need to define the terms somewhere. My impression is that Ryan's concerns are broader than this PR. [01:56:41.0000] Fair enough, I'll give everyone until Wednesday just in case [01:56:47.0000] That seems totally reasonable. [05:58:02.0000] annevk: On background fetch's 'failed' event, I'm looking to communicate the reason for the failure (as long as security allows). Is there any prior art here? Would an enum 'reason' work? Creating an 'error' property would involve defining new error types, which seems bad. [05:59:01.0000] JakeA: it seems like a bit of a layering violation if background fetch gets to expose that, but not fetch [05:59:20.0000] JakeA: unless it's network error vs some HTTP layer errors only [06:01:21.0000] annevk: it wouldn't be anything new, but it'd distinguish between a quota error, a non-ok status code on one of the fetches, a network error... [06:02:28.0000] Another reason could be "underlying resource changed" if the etags change between partial responses [06:03:52.0000] JakeA: okay, an enum seems fine I suppose, if that works for developers [06:04:18.0000] JakeA: does background fetch enforce CORS? [06:04:24.0000] annevk: yes [06:04:34.0000] great [06:04:46.0000] one less vector to worry about [06:04:49.0000] :D [06:11:35.0000] JakeA: could you expose an exception type like NetworkError or QuotaExceededError on a property? [06:11:49.0000] or TypeError with a good message, etc [06:13:03.0000] wanderview: I'd probably have to create a load of new error types to allow code to test the difference. That feels worse than an enum, but I can't quite put my finger on why. [06:13:57.0000] JakeA: the one advantage of the error exception object types is that they allow you to provide a decent message... at least for TypeError [06:14:48.0000] JakeA: I guess it depends on if there is anything useful the site can do with the error other than just logging it [06:15:34.0000] JakeA: the problem with that is that I think exception type messages are localized [06:15:37.0000] wanderview: ^ [06:15:42.0000] Hmm, I'm going to collect all the possible failures we have so far, and see if the right answer becomes clearer [06:15:47.0000] wanderview: so if you want to allow branching, what JakeA suggests seems better [06:15:59.0000] yeah, I'd have to create new error types if I was to use errors [06:16:13.0000] I only ask because in firefox we have an old enum-based system... and its a constant annoyance to me because I have to go plumb extra stuff to get good TypeError with messages so devs can actually tell what happened... enums are never fine-grained enough [06:16:19.0000] ok [06:16:32.0000] JakeA: make sure to test that not-ok is only exposed after CORS succeeds [06:17:17.0000] JakeA: and if you want granular non-ok, you'll either need two fields or a dictionary of sorts, since ~400 enum values seems like too much [06:19:00.0000] annevk: if the error is related to a particular fetch, we can point to the "record" that generated the failure. But yeah, CORS, SSL, MIX related failures will just be "network error" 2018-06-05 [18:16:04.0000] TabAtkins: about the highlighter, --output html seems to not work [18:16:12.0000] echo '["pre", {}, "interface Foo {};"]' | python2.7 ./highlighter/__init__.py --output html webidl [18:16:23.0000] ...still emits JSON output [04:39:07.0000] Do folks think https://github.com/w3c/resource-hints/issues/74 is the "right" place to specify the `Purpose` header sent by prefetch requests, or would another place be better, like Fetch or an IETF draft? [04:42:24.0000] jyasskin: I suspect it needs some Fetch integration [04:42:54.0000] jyasskin: in particular, it seems this is another header that violates the same-origin policy? [04:44:07.0000] It's probably true that prefetch in general could use some Fetch integration. I don't immediately see the same-origin violation here; what are you thinking of? [04:44:48.0000] jyasskin: it's a non-safelisted header included in cross-origin requests [04:45:13.0000] https://fetch.spec.whatwg.org/#cors-safelisted-request-header in particular? [04:45:49.0000] jyasskin: now arguably this is a little muddy, as certain protocol headers such as Host are not safelisted either, but basically each addition beyond what we did in 2000 or so I'd count [04:46:14.0000] jyasskin: yeah [04:46:51.0000] Thanks. Would you put the full specification of the header in Fetch, or just have us make sure to add it to the appropriate lists there? [04:46:57.0000] jyasskin: it doesn't matter much since the value isn't attacker-controlled (and when it is, there'll be a preflight), but still [04:47:14.0000] jyasskin: something similar to Sec-Metadata I suspect [04:47:31.0000] (although that might not be fully defined yet) [04:48:00.0000] I think Sec-Metadata is still in the sketch phase, while Purpose is actually shipped without the matching specification. [04:48:18.0000] jyasskin: I guess I'd expect something similar to https://github.com/whatwg/fetch/pull/751 [04:48:57.0000] jyasskin: check if request's initiator is "prefetch", then append it [04:49:05.0000] jyasskin: maybe also prerender? [04:52:44.0000] Yep, whichever actually controls it in Chrome. There's also a rumble of sending it from browser-initiated requests (https://groups.google.com/a/chromium.org/d/topic/blink-dev/IT3pYF5B_p4/discussion), but specifying that probably shouldn't go in Fetch. [04:54:42.0000] jyasskin: browser-initiated fetches ideally still go through Fetch [04:54:54.0000] Ok, good to know. [04:55:10.0000] jyasskin: otherwise it's easy to accidentally bypass SOP [04:55:44.0000] jyasskin: sleevi might not necessarily agree though, https://github.com/whatwg/fetch/issues/530 has a bunch of details [05:45:48.0000] Anyone any idea why https://software.hixie.ch/utilities/js/live-dom-viewer/saved/5987 does not work? In particular, they/them are supposed to be shared with Singular/Plural row [05:46:26.0000] Is it just too complicated to allocate the cells and therefore browsers / the spec give up? [05:55:29.0000] I think per spec I'm doing the right thing (and the conformance checker agrees), but browsers are sad [06:04:42.0000] annevk: isn't it, though? set a height to 3em the they cell to visualize it [06:06:22.0000] zcorpan_: I'm not sure I follow [06:06:30.0000] zcorpan_: I filed https://github.com/whatwg/html/issues/3738 meanwhile [06:08:23.0000] annevk: commented [06:10:16.0000] zcorpan_: why would it be collapsed? [06:10:44.0000] annevk: cells shrink-wrap and it doesn't need more space than that? [06:10:56.0000] Yeah I guess, that's rather weird [06:11:19.0000] you can see a slight jigger caused by the cell spacing [06:11:40.0000] I guess there's still the magic issue with the spec, but it does seem this "works as intended" [06:40:38.0000] just a heads up but I'm PR'ing Node to add a JS API for accessing the MIME Parsing API from https://mimesniff.spec.whatwg.org/ [06:46:05.0000] bradleymeck: did you see https://github.com/whatwg/mimesniff/issues/43? [06:46:56.0000] annevk: I had missed that issue but saw the package Domenic made. I'm still not keen on involving myself w/ whatwg as I've stated in the past though [06:47:59.0000] the PR I made closely resembles Domenic's idea but has some minor differences. I am not a browser implementor and haven't had good experiences in this arena so it is more of a heads up than me wanting to get involved in this sphere currently [06:48:33.0000] most of the difference is wanting to match URLSearchParams more closely I think [06:49:11.0000] That sounds wrong, since that allows for duplicates and this doesn't, afaik [06:50:23.0000] annevk: i had .getAll originally but pulled it before I PR'd due to it not being used anywhere I can see right now. The parser I wrote is exposing all the parameters though, it is just not available once I turn it into a JS representation [06:51:22.0000] I don't know what that means [06:52:08.0000] If it means you support duplicate names, it's not an implementation of the standard you referenced [06:52:41.0000] the C++ parser in that PR takes `foo/bar;a=1;a=2` and exposes both pairs of `a=1` and `a=2`. The API using the parser though only exposes `a=1` [06:54:49.0000] annevk: correct in a sense, but I'm not sure why multiple parameters aren't supported in MIME, I just prevented exposing the duplicates to user code for now. all existing stuff I saw only uses the first parameter of a given name so I think it was written to drop duplicates for existing matching usage, but there doesn't seem to be a reason why to expose them, since you have to parse the duplicates anyway [06:55:21.0000] bradleymeck: does Node.js's HTML parser expose duplicate attributes? [06:55:46.0000] Node doesn't have an HTML parser, but it does expose duplicate query parameters [06:55:59.0000] and http headers too [06:56:16.0000] For both of those it's explicitly part of the data model [06:56:27.0000] That's a pretty significant difference [06:59:37.0000] annevk: do you have a clear reference to where something says they are not part of the data model when they are duplicates, i spidered out from https://tools.ietf.org/html/rfc6838#section-4.3 but may have missed something but https://tools.ietf.org/html/rfc2045 doesn't note anything that I saw [07:00:21.0000] per the WHATWG parser it does explicitly drop duplicates, but that doesn't seem to be a requirement of MIME itself [07:08:33.0000] bradleymeck: I'm not sure it can be directly derived from RFC2046, but given that parameters are unordered and all implementations handle them as maps, I think it's highly likely that was the intent [07:08:47.0000] bradleymeck: there's also no hint that I know of that indicates they are to be multimaps [07:08:56.0000] annevk: the whatwg tests actually require the parameters to be ordered [07:09:22.0000] but that might just be a symptom of how they are written [07:10:17.0000] if you want to make a comment that duplicates should not be exposed, feel free to do so on the PR; currently they are not exposed in a way that users could access them though. [07:10:28.0000] bradleymeck: https://tools.ietf.org/html/rfc2045#section-5 at least says it's a set [07:12:14.0000] seems good enough to make a statement that we should not multi-map it, still a bit vague on if the set is based upon the entire value+key or just key but 🤷 I'll comment on PR with this restriction that this API should not be extended [07:13:32.0000] bradleymeck: there's other differences too, such as the WHATWG standard handling text/html; per how servers expect clients to do so [07:14:16.0000] annevk: is there something that needs to be done beyond following https://mimesniff.spec.whatwg.org/ 's algorithm for that? [07:15:30.0000] I was running all my tests against the data in https://github.com/web-platform-tests/wpt/tree/master/mimesniff/mime-types/resources [07:16:14.0000] bradleymeck: I meant relative to the RFC [07:16:34.0000] ah, yes, thats largely why I am not going with RFC as the parsing algorithm. [07:16:36.0000] bradleymeck: since if you rather follow that and its data model, this is not the way to go [07:16:40.0000] ok [07:17:55.0000] data model restriction on WHATWG parser is fine, just seemed a restriction by implementation not by any problems with the model if you only use the first declared parameter of a given name to my knowledge [07:18:15.0000] requires that the parameters be ordered if you do that, but the whatwg tests fail if you produce things out of order [07:20:48.0000] I wonder if we should consider changing that, but it doesn't really seem worth it since then we'd either have to sort or randomize [07:21:20.0000] But I guess we'd be slightly more interoperable with other MIME types [07:22:17.0000] why not change the `output` to be an `{ type: string, subtype: string, parameters { [key: string]: value: string }`? wouldn't that avoid randomizing or sorting? [07:22:39.0000] I could PR that, but thought it might be a bit of a burden for people using the existing tests [07:23:16.0000] bradleymeck: there's a number of places that need to serialize [07:27:42.0000] could include a possible output per test and ensure both `input` and `output` produce the same type/subtype/parameters when parsed (against a "golden" parsed form like the above object type). Seems a bit odd though, since serializing will make things ordered in a sense anyway [07:29:32.0000] bradleymeck: right, for serializing you'd need sorting (so you can rely on order) or randomizing (so nobody relies on order) [07:33:23.0000] you could also just have a few duplicates I think, maybe make the serialized form an array : [`a/b;foo=1;bar=2`, `a/b;bar=2;foo=1`] and let test harnesses ensure all possible serialized forms match expectations? [07:34:27.0000] I'm not sure how that would meet the requirements [07:36:30.0000] if your `input` has to match multiple `output`s that are in different order wouldn't that ensure that it is unordered? [07:49:53.0000] MikeSmith: Yes, it emits a JSON object. But the value of the "html" key is a string of HTML, not of JSON-encoded HTML. [07:50:17.0000] TabAtkins: so what does --output html do? [07:50:27.0000] ah [07:50:31.0000] What I just said, controls what format the "html" key is in. [07:50:34.0000] I see [07:51:02.0000] I was hoping to get just HTML back [07:51:17.0000] the consuming code I wrote in wattsi just expects HTML [07:51:18.0000] I need to emit the HTML and CSS separately so you don't spam CSS into the spec for every single highlight. [07:51:24.0000] I see [07:51:35.0000] OK [07:52:26.0000] well the bigger problem I’ve realized I have is that all the HTML examples in the HTML spec use < instead of "<" [07:52:38.0000] because, you know, they’re in an HTML document [07:53:12.0000] but Pygments apparently doesn’t recognize character entities [07:53:33.0000] That shouldn't be a problem? Your HTML parser should have turned them into text by the time you read the DOM and construct the JSON. [07:53:46.0000] yeah that ' [07:54:11.0000] yeah that’s not the way wattsi works [07:54:11.0000] I mean that if your input is `<pre>`, then by the time you read the DOM you should just get out "
", right?

[07:54:16.0000] 
Sigh.

[07:54:26.0000] 
I don’t read the DOM

[07:54:33.0000] 
I don’t re-parse the source

[07:55:21.0000] 
at the point where I emit this content, wattsi just sees strings

[07:56:48.0000] 
How much escapes you got? Just <?

[07:57:17.0000] 
I think so

[07:57:44.0000] 
it is whatever escapes were used by whoever authored the particular example

[07:58:09.0000] 
I think by convention everybody only escapes the "<"

[07:58:19.0000] 
because that’s the only one necessary

[07:58:30.0000] 
example:

[07:58:33.0000] 
  [

[07:58:33.0000] 
    "pre",

[07:58:33.0000] 
    {

[07:58:33.0000] 
      "id": "intro-early-example"

[07:58:33.0000] 
    },

[07:58:35.0000] 
    "<!DOCTYPE html>\n<html lang=\"en\">\n <head>\n  <title>Sample page</title>\n </head>\n <body>\n  <h1>Sample page</h1>\n  <p>This is a <a href=\"demo.html\">simple</a> sample.</p>\n  <!-- this is a comment -->\n </body>\n</html>"

[07:58:40.0000] 
  ]

[07:59:25.0000] 
If it's a finite set, I can give you an option for a quick unescape.

[07:59:32.0000] 
OK

[07:59:41.0000] 
I think just <

[08:00:14.0000] 
anyway to be clear, even in terms of the DOM, the contents of all the examples are just text nodes

[08:00:26.0000] 
inside 
 elements

[08:00:44.0000] 
oh

[08:01:10.0000] 
I thought you wanted to highlight the webidl parts too?

[08:01:15.0000] 
yes

[08:01:18.0000] 
Which have , , etc.

[08:01:24.0000] 
yes

[08:01:29.0000] 
that is the exception

[08:01:48.0000] 
and that is the other big problem I ran into

[08:01:57.0000] 
Yeah, I thought that was the whole point of adapting my tool, as there are lots of highlighters that don't understand HTML but can just handle a string.

[08:02:03.0000] 
the highlighter does not seem to handle those as expected

[08:03:10.0000] 
[ "pre", { "class": "idl" }, "[Exposed=Window,\n ", [ "a", { "href": "#htmlconstructor", "id": "the-menu-element:htmlconstructor" }, "HTMLConstructor" ], "]\ninterface ", [ "dfn", { "id": "htmlmenuelement" }, "HTMLMenuElement" ], " : ", [ "a", { "href": "#htmlelement", "id": "the-menu-element:htmlelement" }, "HTMLElement" ], " {\n};" ],

[08:04:13.0000] 
or simpler case:

[08:04:15.0000] 
echo '[ "pre", { "class": "idl" }, "[NoInterfaceObject]\ninterface ", [ "dfn", { "id": "noncedelement" }, "NoncedElement" ], " {\n attribute DOMString nonce;\n};" ]' | python2.7 ./highlighter/__init__.py webidl

[08:04:30.0000] 
=> TypeError: sequence item 1: expected string or Unicode, list found

[08:05:03.0000] 
... if I remove [ "dfn", { "id": "noncedelement" }, "NoncedElement" ] from that JSON object, that error goes away

[08:05:17.0000] 
Sigh, I just spotted the bug. Fix is pushed.

[08:05:35.0000] 
Me looping over a container then returning the container rather than the item. :/

[08:08:13.0000] 
glad it was an easy fix :)

[08:22:34.0000] 
MikeSmith: Okay, added a --unescape flag that unescapes the "big 5" for HTML - &<>'"

[08:25:25.0000] 
\o/ thank you thank you thank you

[08:25:49.0000] 
will get back to it in the morning my time

[09:15:54.0000] 
TabAtkins: --unescape working beautifully, and the embedded markup in IDL too

[09:16:33.0000] 
working on integrating it back into wattsi+html-build

[09:16:45.0000] 
(as long as my insomnia lasts)

[09:17:30.0000] 
Do you want, like, a --just-html and --just-css argument too, so you can get them independently and shove them in easier?

[09:17:50.0000] 
TabAtkins: yes please

[09:18:06.0000] 
I think I only need the CSS once, right?

[09:18:16.0000] 
(The only problem with --just-css is that the returned CSS can vary based on what arguments you give. But as long as you're always/never doing line-numbers/line-highlighting, it'll stay the same.)

[09:18:22.0000] 
aha

[09:18:26.0000] 
OK

[09:19:02.0000] 
So you can just pass some nonsense el to it to get the CSS out when you need it, I suppose.

[09:19:19.0000] 
yeah as long as the class names are consistent, and the associated CSS rules consistent, I can just add the styles to the main stylesheet, once

[09:19:22.0000] 
I think

[09:20:06.0000] 
oh hey one thing: in the --output html output, newlines get emitted as "\n" (like for JSON) instead of as newlines

[09:20:53.0000] 
ah but that’s within JSON

[09:21:23.0000] 
/me tries to remember if we have a JSON parser in the wattsi code

[09:23:40.0000] 
Right.

[09:24:34.0000] 
With --output=html --just=html it'll print directly, no \n

[09:27:06.0000] 
MikeSmith: And pushed

[09:27:46.0000] 
...and just pulled

[09:27:54.0000] 
beautiful

[09:27:57.0000] 
perfect

[09:28:01.0000] 
thanks very very much

[09:28:04.0000] 
np

[09:29:02.0000] 
I should be able to get the related wattsi+html-build stuff landed this week

[09:29:26.0000] 
and then finally syntax-hightlighted examples in the HTML spec

[09:30:07.0000] 
thanks to magic of combining Free Pascal + Python + TabAtkins

[09:31:03.0000] 
Yay!

[09:31:11.0000] 
:)

[09:33:00.0000] 
and a bonus is that this may push the size of the single-page output of the spec up to 10MB!

[09:33:12.0000] 
after all the years we been trying hard to get it there

[09:33:41.0000] 
currently it’s still just a tiny 8.5MB

[09:33:41.0000] 
MikeSmith: euh that's probably worth a discussion before we land?

[09:33:50.0000] 
MikeSmith: or is it already close to 10?

[09:34:01.0000] 
MikeSmith: I see

[09:34:03.0000] 
annevk: only 8.5MB now

[09:34:05.0000] 
yeah

[09:34:29.0000] 
maybe this won’t really add an additional 1.5MB, I dunno

[09:34:38.0000] 
but we got a lot of examples...

[09:35:51.0000] 
That seems good to verify as a 15-20% increase or so will also affect the speed of multipage

[09:37:07.0000] 
yeah this basically makes the source of each example at least 4 times bigger

[09:38:12.0000] 
anyway we’ll find out soon enough, once I got the highlighter plugged in

[09:42:32.0000] 
If HTML had added  for inline text (for "character") we'd shave a lot of weight off of that. ^_^

[09:42:54.0000] 
And then I'd be able to write my terrible talk "Learn the   s of HTML".

[09:46:10.0000] 
heh

[09:50:34.0000] 
would "Learn the    of HTML" work?

[09:53:41.0000] 
astearns: Learn the   Cs(s) of HTML?

[09:56:24.0000] 
astearns: That's only a 2-characters savings per element, and so not very impressive. (one per tag)

[09:57:49.0000] 
Wait tho.

[09:58:15.0000] 
Actually... if I could bake the classes into the tagname, it would save a bunch more characters.

[09:58:50.0000] 
..., versus ...

[09:59:01.0000] 
I *think* it highlights with only a single class per? I'd have to check.

[10:01:24.0000] 
Are arbitrary attributes allowed on custom elements, or do they still have to be data-*?

[10:08:46.0000] 
Looks like arbitrary attributes are allowed, per both MDN and spec examples, nice.

[10:12:16.0000] 
... is 12 characters of weight, and looks to be valid, versus ... which is 24 characters of weight. I can literally halve the weight-cost of highlighting.

[10:16:12.0000] 
/me watches as TabAtkins rediscovers XML ;)

[10:17:03.0000] 
golfing ftw

[10:17:27.0000] 
/me remembers when it was tennis

[10:17:47.0000] 
TabAtkins: I think I like the idea of being able to wrap things for test annotations, , 
  • ,  -- could it be an attribute wpt-test?

[10:18:12.0000] 
yeah, it def could be. Just requires some more sophisticated handling for output.

[10:30:32.0000] 
👍

[10:31:43.0000] 
I love it when a dumb joke turns into a terrible hack

[10:40:47.0000] 
And... pushed. Highlight weight is now magically cut in half.

[10:47:13.0000] 
I could cut it a little bit more if I explode out the namespace - going with ... saves one character, and for the single-char classes I'd save 3.

[10:53:24.0000] 
But nah, that'd stomp on the element-name namespace too much, make it difficult for me to do this sort of minification on other things. But I can at least rejigger the highlight-names so that i use the entire single-letter alphabet before I go to two letters, save a character on a bunch of stuff.

[11:47:40.0000] 
Domenic: I believe there's no intention of unifying DOM streams and Node.js streams. Is that correct?

[11:47:51.0000] 
jugglinmike: up to Node.js, I guess?

[11:48:12.0000] 
Oh, okay

[12:06:26.0000] 
are Blobs frowned upon these days? I do see them in Response objects but was wondering

[12:10:58.0000] 
 Blobs are OK. The FileReader API is terrible, but there's no good alternative yet. Blob URLs are frowned upon in general.

[12:21:30.0000] 
Domenic: thanks

[13:09:32.0000] 
MikeSmith, FYI, incoming in a few weeks, new aria roles blockquote paragraph and caption < https://w3c.github.io/aria/#changelog >

[13:33:29.0000] 
there is a great alternative to the FileReader API: new Response(blob).body gives you a ReadableStream to read the blob

[13:33:41.0000] 
and yeah, Blob URLs are terrible

[16:02:15.0000] 
new Response(blob).whatever still feels like a hack to me, but you're right :)

[16:21:10.0000] 
TabAtkins: per https://drafts.csswg.org/css-fonts-3/#font-prop is body { font: 3.5mm message-box,serif,helvetica,sans-serif; }

[16:21:23.0000] 
.. valid?

[16:21:39.0000] 
the context is https://github.com/validator/validator/issues/661#issuecomment-394836779

[16:22:15.0000] 
the CSS checker reports an error for body { font: 3.5mm message-box,serif,helvetica,sans-serif; }

[16:22:35.0000] 
but not for body { font: 3.5mm message-box,serif,helvetica,sans-serif; }

[16:23:07.0000] 
as far as I read that grammar, both should actually be valid, right?

[16:23:57.0000] 
    [ [ <‘font-style’> ||  || <‘font-weight’> || <‘font-stretch’> ]? <‘font-size’> [ / <‘line-height’> ]? <‘font-family’> ] | caption | icon | menu | message-box | small-caption | status-bar

[16:24:08.0000] 
...

[16:25:36.0000] 
though in both cases “message-box” doesn’t mean the system font but instead is just a (non-existent) font-family name?

[16:25:43.0000] 
Yes

[16:25:54.0000] 
OK thanks

[16:26:12.0000] 
If you want the message box font, you do it all by itself

[16:26:18.0000] 
right

[16:26:20.0000] 
OK

[16:26:39.0000] 
But yeah it's valid

[16:26:46.0000] 
hai

[16:28:17.0000] 
so I dunno why the checker reports an error for the first case but not the second, but I guess the case-switch the code is using isn’t written in quite the order it should be


2018-06-06
[17:48:51.0000] 
TabAtkins: the following WebIDL isn’t syntactically valid?

[17:48:52.0000] 
[Exposed=Window]

[17:48:52.0000] 
interface Example {

[17:48:52.0000] 
  // this is an IDL definition

[17:48:52.0000] 
};

[17:51:49.0000] 
That seems to work. Is highlighter complaining?

[17:52:09.0000] 
Its webidl parser is relatively old at this point, I should update it.

[17:53:07.0000] 
TabAtkins: Yeah the highlighter chokes on it

[17:53:12.0000] 
echo '["pre", { "class": "idl extract" }, "[Exposed=Window]\ninterface ", [ "dfn", "Example" ], " {\n // this is an IDL definition\n};" ]' | python2.7 ./highlighter/__init__.py webidl

[17:53:40.0000] 
=> Exception: IDL SYNTAX ERROR LINE: 1 - skipped: "[Exposed=Window] ...

[17:54:52.0000] 
that is the very first example in the spec

[17:55:29.0000] 
I just updated widlparser and pushed, and it seems to work just fine now.

[17:55:31.0000] 
well, code example at least

[17:55:36.0000] 
oh cool

[17:55:43.0000] 
/me pulls

[17:57:43.0000] 
hmm still fails for me, with the same error

[17:57:49.0000] 
even after pulling

[17:58:42.0000] 
/me does find . -name *.pyc | xargs rm

[17:59:10.0000] 
... gets same error

[17:59:18.0000] 
Huh, that's odd.

[18:00:03.0000] 
Ah, I'm getting it now with your exact example. Hm.

[18:00:25.0000] 
Oh, duh, it's the ["dfn"].

[18:00:32.0000] 
It needs a {} as the second arg!

[18:00:36.0000] 
aha

[18:00:45.0000] 
yeah I ran into that before

[18:01:13.0000] 
I guess I need to change the serializer code I wrote for wattsi to always emit that

[18:01:20.0000] 
Yeah.

[18:01:23.0000] 
k

[18:01:25.0000] 
thanks

[18:02:18.0000] 
(The error hints at this - it just says `interface  {`, with no name.)

[18:02:36.0000] 
ah yeah

[18:02:51.0000] 
/me adds the {}

[18:03:04.0000] 
sweet yeah it works

[18:12:51.0000] 
TabAtkins: btw whenever I pull I need to do a git checkout first

[18:13:15.0000] 
otherwise git says error: cannot pull with rebase: You have unstaged changes

[18:14:11.0000] 
...because of pygments/__init__.pyc being under version control and it gets regenerated when I run the highlighter/__init__.py script

[18:14:57.0000] 
maybe you want to git rm pygments/__init__.pyc

[18:18:58.0000] 
Ah, indeed, I'll fix

[18:21:48.0000] 
super

[19:33:04.0000] 
igrigorik: https://github.com/wicg/event-timing

[19:33:12.0000] 
what is duration trying to capture

[19:35:11.0000] 
igrigorik: remember that 'Update the rendering' is basically end of task model

[19:35:23.0000] 
not "UA will actually update rendering at this time"

[19:35:36.0000] 
UA may decide, per spec, to not update rendering of documents

[19:36:06.0000] 
igrigorik: or perhaps you know who to ask about that proposal

[19:39:23.0000] 
filed https://github.com/WICG/event-timing/issues/6

[23:24:37.0000] 
Thanks smaug____, filed an issue too

[23:25:01.0000] 
I wish folks would be better about filing upstream early

[00:27:28.0000] 
JakeA: CC'd self on http://crbug.com/849952 as I may be interested in implementing, but it'll be on the backlog unfortunately (just figured I'd mention tho)

[00:29:44.0000] 
domfarolino: Ohh cheers!

[00:32:31.0000] 
annevk: ohhhhh so I should be using the "core" component? Seems weird that isn't signposted on https://bugzilla.mozilla.org/enter_bug.cgi

[00:34:25.0000] 
JakeA: yeah, dunno

[00:35:06.0000] 
JakeA: I've tried to improve some aspects of that Bugzilla instance, but there's quite a lot of apathy from peers so I stopped caring

[00:35:22.0000] 
fair enough

[04:06:06.0000] 
what RFC states the requirement that quoted parameter values must use double quotes? (rather than single quotes)

[04:23:12.0000] 
MikeSmith: HTTP RFC?

[04:23:33.0000] 
MikeSmith: might be since the dawn of MIME though

[06:10:15.0000] 
JakeA: annevk: I highly recommend using the "find product" search box on the new bug page

[06:10:42.0000] 
for example, if you type "service worker" in there it will give you CORE:DOM:ServiceWorkers, etc

[06:12:08.0000] 
neat

[09:23:29.0000] 
I'm a little confused on https://github.com/w3c/webcomponents/issues/468 discussion about fake-shadow-root ... this is the thing referred to also as virtual-shadow-root, yes?

[09:28:05.0000] 
annevk said interested in seeing how this translates into a proper specification" but domenic also said "what's interesting is that the UA stylesheet-based spec text and the virtual-shadow-root based spec text are almost exactly equivalent in their observable consequences"

[09:33:40.0000] 
sorry, so many conversations/overlapping ideas - it can get a little confusing and hard to backtrack to the real thing

[09:40:17.0000] 
I didn't know we'd upped the price of standards to two bits

[10:29:53.0000] 
annevk: Would you mind taking a look at https://bugs.chromium.org/p/chromium/issues/detail?id=532782 and see if my take on it is correct?

[10:31:06.0000] 
domfarolino: yeah

[10:31:08.0000] 
GPHemsley: hah

[10:31:27.0000] 
domfarolino: not sure if we have good tests, but that seems accurate

[10:32:14.0000] 
bkardell: Domenic focusing on what it actually means helps

[10:32:18.0000] 
bkardell: yes, I am having a hard time understanding as well. Tried to straighten out a bit...

[10:32:19.0000] 
I'm still confused though

[10:32:43.0000] 
Domenic, yes, I gave you a 👍 on that - thank you :)

[10:33:25.0000] 
annevk, are you mostly confused in _how_ it is treated that way in the virtual/fake case?

[10:35:12.0000] 
bkardell: I basically don't understand what people mean when they say "fake shadow root"

[10:43:37.0000] 
As I understand it, it is really simply saying what Domenic recapped - but I wanted to know if that is what we were saying.  Effectively this applies to, more or less, how you match selectors in 3rd arg stylesheet?

[10:45:06.0000] 
in other words, I think there is no new 'node' in here or anything

[10:45:33.0000] 
Domenic: I think you need to make your last bullet point more specific as to which style sheet you would use that selector in

[10:45:50.0000] 
Domenic: I think rniwa is saying that such a selector would not work here

[10:51:44.0000] 
annevk: hmm, I thought such selectors worked with shadow DOM today, but maybe I should have tested

[10:54:03.0000] 
Domenic, they said they implemented in chrome, will it be in nightlies or something?

[10:54:23.0000] 
Might be in Canary behind a flag, not sure, might just be on rakina's local machine...

[10:55:36.0000] 
I wonder if maybe a good thing would be for rakina to create demo illustrating the test cases and say 'you can get release x and flip such and such flag' - then people could just actually see/play with it and ask better questions... is that a reasonable thing to ask on the thread?

[10:56:59.0000] 
Yeah maybe.

[11:04:21.0000] 
done

[12:35:06.0000] 
annevk: ta for checking

[12:38:20.0000] 
I'll check out the tests (if any) we have around that

[12:58:24.0000] 
annevk: is https://github.com/whatwg/html/pull/3742 ready for review or should I hold off?

[15:51:51.0000] 
anyone here?

[15:53:51.0000] 
should be


2018-06-07
[23:31:34.0000] 
Domenic: it's ready; planning on writing tests later

[23:57:20.0000] 
hsivonen: if you could review the window.event tests I think we're all good to go

[23:58:06.0000] 
hsivonen: only https://github.com/web-platform-tests/wpt/pull/10329 really

[23:58:44.0000] 
I guess I can also try foolip again

[00:22:53.0000] 
annevk: need review on something?

[00:25:48.0000] 
foolip: yeah, the above URL

[00:29:56.0000] 
annevk: I'll take a look

[00:31:27.0000] 
\o/

[00:37:07.0000] 
annevk: most of the tests fail in Chrome and Safari, did you look into that?

[00:37:15.0000] 
I haven't tested Edge

[00:37:30.0000] 
foolip: I filed bugs on that

[00:37:53.0000] 
foolip: they follow a suggestion that we should base the global on the global of the listener's callback

[00:38:26.0000] 
annevk: ah, as opposed to the event target?

[00:38:39.0000] 
foolip: made by Shiino Yuki from Chrome

[00:39:04.0000] 
foolip: yeah, and even that wasn't consistent I think, it's a little unclear to me still what the existing mechanism is

[00:40:57.0000] 
annevk: the first two test names include  "{ [native code] }", do you think that's worth fixing?

[00:41:01.0000] 
foolip: if you want to do some light background reading: https://github.com/whatwg/dom/issues/334

[00:41:43.0000] 
foolip: I could fix that, sure

[00:41:49.0000] 
annevk: fixing now

[00:42:16.0000] 
annevk: Would we ever allow developers to get at the undecoded bytes of a response? I imagine it'd require an additional CORS opt-in at least

[00:43:47.0000] 
JakeA: we could, I don't think we'd need another opt-in per se, but I maybe I haven't thought about it enough

[00:44:21.0000] 
JakeA: we actually wanted to go that way initially, but it turned out it was buried deep into the networking stack and nobody liked it, so it didn't seem good as a default

[00:44:58.0000] 
annevk: what

[00:45:06.0000] 
annevk: what's "listener intentionally not wrapped in t.step_func" about?

[00:45:13.0000] 
annevk: is it to cause a harness error?

[00:45:32.0000] 
annevk: or because that would change the global of the listener?

[00:45:39.0000] 
I guess that's it

[00:45:41.0000] 
gotta run

[00:46:55.0000] 
annevk: I was wondering about compression formats with some kind of dictionary that might leak additional info, but I guess that'd be a separate request. Ta. Just trying to get my head around Chrome's complaints about the Accept-Encoding stuff.

[00:46:59.0000] 
foolip: that's it

[00:47:46.0000] 
JakeA: I think some H/2 stuff might be across requests, but maybe that's just for headers?

[00:47:58.0000] 
JakeA: dunno how brotli works either

[00:48:27.0000] 
annevk: If it becomes a big problem, we could add an optional arg to https://fetch.spec.whatwg.org/#concept-request-add-range-header which can specify the encoding, which would default to identity.

[00:48:48.0000] 
me neither

[00:48:57.0000] 
JakeA: I was thinking that could be another solution here, but it doesn't help when someone sets Range manually

[00:49:28.0000] 
JakeA: there are a ton of issues around Accept-Encoding though that I recently surfaced a bit in issues, mmenke(sp?) helped with that

[00:49:53.0000] 
annevk: we always want identity in that case, so we'd still need the line we already have, unless something set Accept-Encoding first

[00:50:48.0000] 
JakeA: yeah, but the way we set things up nothing can set that first

[00:51:33.0000] 
JakeA: I guess their concern is that their layering is different from ours, but I'm not sure how to reconcile properly

[00:52:54.0000] 
annevk: I'll see what they come back with. It seems like they're softening a bit from the initial "this doesn't make sense" reaction

[00:53:47.0000] 
k

[00:56:31.0000] 
botie, inform tantek http://microformats.org/wiki/existing-rel-values is not responding

[00:56:31.0000] 
will do

[07:46:44.0000] 
annevk: Domenic about the syntax highlighter: After doing some initial testing with TabAtkins tool hooked into wattsi and html-build:

[07:47:21.0000] 
the good news is that increases the output file size by only 3.5%

[07:48:22.0000] 
the single-page output size increases by 300MB, to 8.8MB from 8.5MB

[07:49:49.0000] 
the somewhat less good news is that makes the build go from 16 seconds (without the highlighter) up to about 4.5 minutes

[07:51:53.0000] 
but that’s not too surprising given that we have 1121 examples in the spec, and because of the way it needs to be handled in wattsi, each example gets processed 3 times: 1) single-page full spec, 2) multipage full spec, 3) developer version

[07:52:19.0000] 
Holy shit tho

[07:52:38.0000] 
Hmm

[07:52:44.0000] 
TabAtkins: well I think that works out to only 80ms per example

[07:53:19.0000] 
MikeSmith: You think you could do a pass and pull all the to-be-highlighted text out so I can play with it?

[07:53:21.0000] 
to pipe the example to the highlighter, have the highlighter process it, write it back to the output

[07:53:29.0000] 
Also one singlepage snapshot

[07:53:40.0000] 
80ms is a long time. 😤

[07:53:58.0000] 
But I'm wondering how much is it vs highlighting

[07:54:09.0000] 
annevk: right now I have it not highlighting the snapshot output

[07:54:15.0000] 
* is IO

[07:54:49.0000] 
annevk: on the assumption we don’t want to make the snapshot especially user-friendly anyway

[07:54:58.0000] 
4.5min would be annoying with Travis too, currently failure is reported quite quick

[07:55:08.0000] 
MikeSmith: fair

[07:55:09.0000] 
or rather maybe, we don’t want people using the snapshot for anything

[07:55:09.0000] 
Yeah we knew it would take a while. But I think it's ok since we'll only run it on CI.

[07:55:25.0000] 
I think the snapshot should be user friendly, but not the review draft

[07:55:45.0000] 
Snapshot is for people being like "this is what I implemented last Thursday"

[07:55:45.0000] 
How long does Bikeshed take?

[07:56:02.0000] 
TabAtkins: yeah I can get you the source for all the examples

[07:56:12.0000] 
If we don’t care about build times…

[07:56:24.0000] 
(I care a bit)

[07:56:34.0000] 
TabAtkins: oh, you want the JSONized source of the examples? or the original HTML?

[07:56:58.0000] 
On my laptop, the Bikeshedded version of HTML took about 3min. On my desktop it was a minute and change iirc.

[07:57:18.0000] 
MikeSmith: the json, what you'd give to highlighter.

[07:57:50.0000] 
Sounds like we’d be better of switching to Bikeshed…

[07:58:58.0000] 
We could potentially do that by making wattsi output a bs source file

[07:59:00.0000] 
TabAtkins: OK, I have https://gist.githubusercontent.com/sideshowbarker/8284404/raw/cff69f158ea995a17a73af3e9eff29823617caa8/html-spec-all-pre-elements.json but I generated that before I added code for emitting {} for the no-attributes case. So I will regenerate it

[07:59:13.0000] 
For the conversion

[08:00:20.0000] 
Domenic: ah OK (about the snapshot). I can flip it on and see how much time it adds

[08:00:42.0000] 
MikeSmith: I presume you tell which language to highlight it with by looking at the class?

[08:00:50.0000] 
oh

[08:01:01.0000] 
I have not implemented that yet

[08:01:17.0000] 
I think right now I just have it assuming it’s all HTML

[08:01:32.0000] 
but yeah I will need to have it check the class value

[08:01:33.0000] 
Ahahaha, ok. That won't give right results. 😀

[08:01:40.0000] 
yeah I know

[08:02:22.0000] 
But yeah I'm guessing most of the cost here is in IO, shelling out for each individual example.

[08:03:11.0000] 
But I think wattsi is intentionally single-pass?

[08:06:53.0000] 
TabAtkins: single-pass?

[08:07:24.0000] 
As in it runs thru the source document only one time, rather than repeatedly searching over it (like Bikeshed does).

[08:08:08.0000] 
it runs through it once for each “variant” we output

[08:08:16.0000] 
but we output 4 variants

[08:08:52.0000] 
1) single-page full spec, 2) multipage full spec, 3) developer version, 4) snapshot

[08:08:56.0000] 
Yeah, but that's fine. Single-pass is just the only way I could imagine getting 16s for each.

[08:09:10.0000] 
(I really need to buckle down and see about converting wattsi's HTML parser/serializer to Python; those are still the *dominant* time-sinks in large Bikeshed specs.)

[08:09:42.0000] 
(I think in the Bikeshed-HTML spec they're each 40% of the runtime?)

[08:09:52.0000] 
MikeSmith: I think it only parses once, serializes a lot though

[08:10:21.0000] 
annevk: ah right yeah for sure

[08:10:38.0000] 
if we are talking about HTML parsing, yes, it does it only once

[08:10:59.0000] 
and blazingly blazingly fast

[08:11:19.0000] 
Parsing and just general *handling*. Like, Bikeshed obvi only does a single HTML parse, but then it runs over the DOM many many times.

[08:11:59.0000] 
One of my 2018 goals is to replace almost all of my selectors with a properly-maintained data structure sorting elements by significant classes.

[08:18:39.0000] 
annevk: I prefer the <10 second times of the current build to 1.5 minute times...

[08:21:20.0000] 
(OK, it's up to 23 seconds now, including linting and pre-processing.)

[08:21:36.0000] 
Notably it parses once and then does the three output passes

[08:21:57.0000] 
TabAtkins: https://gist.githubusercontent.com/sideshowbarker/8284404/raw/8efdf8fe9713839b839955c9a099ff90e2e559a1/examples.json

[08:23:10.0000] 
My understanding is that a large part of Wattsi's speed comes from being very intentional about memory use with strings, which is hard to do in a high-level language (i.e. not C/C++/Rust, or apparently, Pascal).

[08:23:20.0000] 
s/memory usage/allocation and copying/

[08:23:46.0000] 
Ah, that would make sense.

[08:26:53.0000] 
I think it’s actually pretty hard to do even in Pascal

[08:27:31.0000] 
Hixie did it by inventing some stuff optimized for it

[08:31:36.0000] 
Domenic: oh, we’d only enable syntax highlighting on master or some such? That’s getting rather fragmented

[08:32:20.0000] 
why would we need it other than on master?

[08:32:45.0000] 
I mean the goal is just for end users to have it in the published spec, right?

[08:32:47.0000] 
annevk: Well, I certainly wouldn't run it when building locally. Whether we make it on by default (so you have to pass a flag to build.sh to get fast build times) or off by default (so that CI has to pass a flag to get syntax highlighting) is up to us, but I lean toward off by default.

[08:33:22.0000] 
ah

[08:33:25.0000] 
good point

[08:33:47.0000] 
we can add a build flag to disable it

[08:34:02.0000] 
for local builds

[08:34:13.0000] 
Or add one to enable it, for CI builds?

[08:34:18.0000] 
yeah

[08:35:49.0000] 
so yeah however we enable/disable it, it runs only for CI builds, so the time cost would only be for CI runs

[08:36:15.0000] 
that makes it a lot less icky I guess

[08:36:37.0000] 
as long as it doesn’t cause CI to time out

[08:37:14.0000] 
I can make it emit log output the whole time at least

[08:38:44.0000] 
I mean, say, just keeping a counter (of examples) and emitting that after incrementing it each time

[08:38:49.0000] 
Yeah I think CI timeout is like 15 minutes so we should be OK

[08:38:57.0000] 
cool

[08:39:08.0000] 
Incremental logs sounds good, yeah, it's annoying staring at CI and wondering if it's stuck

[08:39:16.0000] 
true yeah

[08:39:45.0000] 
at this poitn without emitting something, it just feels like it’s hung

[08:39:56.0000] 
so yeah will add that regardless

[08:40:26.0000] 
anyway it’s late here so I’ll need to finish the wattsi patch for this later (maybe not til over the weekend)

[08:45:24.0000] 
Sounds good! Excited to have these.

[09:26:36.0000] 
tantek, at 2018-06-07 07:56 UTC, MikeSmith said: http://microformats.org/wiki/existing-rel-values is not responding

[09:49:03.0000] 
botie, inform MikeSmith WFM now, please try reloading microformats.org/wiki/existing-rel-values to confirm and thanks for the heads-up.

[09:49:03.0000] 
will do

[09:51:51.0000] 
If the CI-errors being quick is something you really care about, the no-highlight version is *so fast* that you could just... do it twice, once without highlighting and once with.

[10:02:27.0000] 
Not a bad idea

[10:47:13.0000] 
Ugh, some of the people who want header support in WebSocket are really not helping their cause

[12:34:01.0000] 
jgraham: you're right that the survey should be more coordinated, sorry about that. Can we coordinate now and make tweaks if necessary?

[12:35:58.0000] 
foolip annevk ^

[12:47:14.0000] 
Also what distribution method do you think we should use

[12:48:13.0000] 
Should we have a question for which employer?

[13:03:16.0000] 
zcorpan: I don’t think any of this matters much personally due to window.js and any.js

[13:04:06.0000] 
zcorpan: I’d be okay trying to get rid of the single test format entirely

[13:06:18.0000] 
FWIW, I've always stayed away from it because I never really knew until reading the source how it worked, and when I saw it first thought the tests must be broken

[13:06:33.0000] 
Which makes me a bad judge of what people who like it would want, of course

[13:18:02.0000] 
zcorpan: I think we should withdraw the survey and send out a new one in a week or so. I know that's annoying but since we can only do this kind of thing once per year I think we have to be sure we're getting the input we need each time

[13:30:48.0000] 
Ok

[13:38:25.0000] 
Turned off responses and removed the tweet. Maybe MikeSmith can still reject my email as it's in moderation

[13:39:43.0000] 
zcorpan: Thanks. I'll spend some time tomorrow on this

[13:43:20.0000] 
Thank you

[16:22:06.0000] 
hai, successfully rejected that e-mail message

[16:22:06.0000] 
MikeSmith, at 2018-06-07 16:49 UTC, tantek said: WFM now, please try reloading microformats.org/wiki/existing-rel-values to confirm and thanks for the heads-up.


2018-06-08
[17:37:32.0000] 
TabAtkins: good point (about how we can just run the build twice in CI)

[03:23:04.0000] 
is the following WebIDL not syntactically valid?

[03:23:07.0000] 
https://html.spec.whatwg.org/multipage/workers.html#abstractworker

[03:23:14.0000] 
interface mixin AbstractWorker {

[03:23:14.0000] 
  attribute EventHandler onerror;

[03:23:16.0000] 
};

[03:25:53.0000] 
looks correct to me (the language about "implementing" should probably be changed to "includes" though)

[03:32:06.0000] 
annevk: OK, I ask because it causes the highlighter to throw with a syntax error

[03:33:02.0000] 
and there are 5 other WebIDL blocks from the HTML spec that it also fails on

[03:33:07.0000] 
https://github.com/tabatkins/highlighter/issues/4

[03:33:19.0000] 
    https://html.spec.whatwg.org/multipage/workers.html#abstractworker

[03:33:19.0000] 
    https://html.spec.whatwg.org/multipage/interaction.html#elementcontenteditable

[03:33:22.0000] 
    https://html.spec.whatwg.org/multipage/webappapis.html#globaleventhandlers

[03:33:25.0000] 
    https://html.spec.whatwg.org/multipage/links.html#htmlhyperlinkelementutils

[03:33:27.0000] 
    https://html.spec.whatwg.org/multipage/dom.html#htmlorsvgelement

[03:33:29.0000] 
    https://html.spec.whatwg.org/multipage/embedded-content.html#htmlimageelement

[03:34:09.0000] 
MikeSmith: what's the error?

[03:34:49.0000] 
Apart from the last one those are all interface mixins...

[03:36:21.0000] 
Exception: IDL SYNTAX ERROR LINE: 2 - skipped: "attribute EventHandler onerror"

[03:36:37.0000] 
...is the error for the https://html.spec.whatwg.org/multipage/workers.html#abstractworker one

[03:37:08.0000] 
Exception: IDL SYNTAX ERROR LINE: 2 - skipped: "[CEReactions] attribute DOMString contentEditable"

[03:37:20.0000] 
...for the https://html.spec.whatwg.org/multipage/interaction.html#elementcontenteditable one

[03:40:38.0000] 
Exception: IDL SYNTAX ERROR LINE: 62 - skipped: "attribute unrestricted double globalAlpha"

[03:40:50.0000] 
...for the https://html.spec.whatwg.org/multipage/embedded-content.html#htmlimageelement one

[03:45:22.0000] 
I checked out Safari favicons, doesn't do SVG

[03:45:32.0000] 
Is Firefox really the only browser? I assume it regressed in Opera?

[04:47:21.0000] 
annevk: I wouldn't guarantee it regressed in Opera, given AFAIK the favicon handling is all in the UI layer?

[04:48:52.0000] 
Could be, too lazy to test though

[05:08:43.0000] 
I don't think I even have Opera installed nowadays :)

[10:16:43.0000] 
Domenic: so one thing I was thinking of is that maybe we could have a "document state" object that ends up being 1:1 with Document objects and is created early

[10:17:06.0000] 
Domenic: but even that might not quite work if we invoke the parser and such too early

[10:17:19.0000] 
Domenic: so much technical debt

[10:43:39.0000] 
annevk: yeah it seems pretty bad. I'm hoping TimothyGu and I can make a dent in some of it this summer, although I am trying to find smaller scoped pieces instead of "fix all of navigation"

[10:44:40.0000] 
Domenic: it's all so intertwined which makes it really hard

[10:45:06.0000] 
I think I've found two separable pieces, namely document.open() and javascript: URLs. Each have like 6 open bugs.

[10:45:21.0000] 
Domenic: another thing that might be interesting is script execution

[10:45:36.0000] 
What's wrong with script execution? :(

[10:46:03.0000] 
Domenic: I wrote a bunch of tests for document.open() and eventually you hit how it opens the HTML parser which is tricky, but yeah (see a lot of outstanding test PRs on that)

[10:46:38.0000] 
Domenic: https://github.com/whatwg/dom/issues/575 et al

[10:46:57.0000] 
Ah, right :(

[10:46:58.0000] 
Domenic: basically that browsers have some kind of "it's safe to run scripts stack"

[10:47:17.0000] 
and some stuff around parser-inserted and moving around documents was also non-interoperable

[15:49:38.0000] 
TabAtkins: thanks for the highlighter merges


2018-06-09
[23:11:49.0000] 
Domenic: happy b-day!

[02:27:13.0000] 
https://lists.w3.org/Archives/Public/public-webrtc/2018Jun/0012.html - what do you guys think? I'm not into A/V, so I can't comment on that. :)

[14:22:20.0000] 
there's no event for img.naturalWidth and naturalHeight changing? :|

[14:23:17.0000] 
(or more accurately, to find out when they reflect a new src, whether they change or not)


2018-06-11
[17:34:41.0000] 
/me wanders on in

[17:34:53.0000] 
Hello

[17:35:10.0000] 
anyone around?

[17:36:09.0000] 
/me frowns and sits quietly on the side wall while he waits for someone to join in on the conversation*

[17:37:36.0000] 
/me sits with his back to the wall and looks about the room and plays with some dice while waits patiently*

[17:39:22.0000] 
/me ponders about getting a crayon and drawning on the wall but decides its best against that course of action*

[17:39:54.0000] 
wfpkhc: if you have a question, ask it. this isn't a conversational channel, and you're likely to be kicked if you're spamming emotes

[17:40:14.0000] 
/me waves hello to astearns -

[17:40:17.0000] 
yes i have a question

[17:40:24.0000] 
what do you know about standards sir?

[17:40:45.0000] 
html5 standards - more specifically

[17:41:48.0000] 
i try to follow html standards as much as possible and have done a good job up until now - but while migrating from html4 to html5 - i seem to keep coming up with this warning with the validator -

[17:41:54.0000] 
Warning: The type attribute is unnecessary for JavaScript resources.

[17:42:26.0000] 
have they removed that in html5?

[17:43:30.0000] 
wfpkhc: I don't know the answer, but that's a specific-enough question that someone who does know the answer might respond.

[17:43:42.0000] 
ok sir, thank you

[17:44:33.0000] 
welcome back ckrn_

[17:45:04.0000] 
i hate it when the damn hamster dies on the power wheel and you lose connection

[17:45:39.0000] 
oh come on that was funny :)

[17:46:02.0000] 
i have to go i might come back later

[17:46:06.0000] 
thank you all

[18:19:02.0000] 
if I were to expose a bunch of non spec globals in my runtime what would be the best way to do that

[18:19:28.0000] 
chrome has all it's weird stuff on a "chome" property so im assuming that's a good way?

[06:07:33.0000] 
frivoal: that spatial navigation spec is indeed rather long. Will take quite a few hours to review

[06:08:02.0000] 
one thing I noticed that the draft seems to think focusin fires differently than it actually fires

[06:08:03.0000] 
see https://github.com/w3c/uievents/issues/88

[06:08:56.0000] 
smaug____: We've tried to organize the reading order of the spec in a way to minimize the pain. If we have done a poor job at that, that is also useful feedback

[06:09:27.0000] 
frivoal: just something I noticed in Example 8

[06:09:53.0000] 
focusin/out handling is totally bogus in browsers

[06:10:08.0000] 
since webkit/blink decided to implement broken behavior

[06:10:51.0000] 
Ok. We should fix that, but this is thankfully only incidental. The rest of the spec does not depend on that behavior, it was just given for context

[06:11:44.0000] 
Still, if it's wrong (and I trust you that it is), we should fix it

[06:12:10.0000] 
frivoal: question, the example mention keydown

[06:12:17.0000] 
what about keyup?

[06:12:34.0000] 
or is the idea that there can be several keydown in case of repeated events or something?

[06:13:24.0000] 
This is really the problem with example that try to illustrate the general idea without getting into the details too much. For people who know the details, they raise more questions than they answer :)

[06:14:19.0000] 
In our case, we spec that it is up to the browser to decide what triggers spat nav. We expect that key down on arrow keys (or shift+arrow keys) will be rather typical, but that's a UI decision, up to the UA.

[06:15:01.0000] 
So the example is meant to illustrate (possibly with insufficient details) what a typical implementation would do, but there is some flexibility about that

[06:15:17.0000] 
but the idea is that repeated key (long press) will cause several navigations.

[06:15:27.0000] 
I assume so

[06:15:41.0000] 
It is one possible behavior, and I assume it would be typical. But not required by the spec.


2018-06-12
[02:15:35.0000] 
annevk: I'm a tad confused; should Request objects have an exposed `body` attribute, similar to Responses?

[02:21:16.0000] 
Seems like it should, no implementations do this right now however I couldn't find tests testing this (albeit did not spend very long looking)

[04:04:33.0000] 
domfarolino: it was added before we had a test requirement

[04:05:02.0000] 
domfarolino: there are also some open issues against Fetch related to that

[04:05:52.0000] 
domfarolino: but yeah, impl of request body streams has not yet happened, which is the main issue

[04:31:07.0000] 
annevk: about the mechanism that other of our build scripts use for determining whether they’re being run under Travis or not:

[04:32:05.0000] 
I see that whatwg.org/resources.whatwg.org/build/deploy.sh checks for a TRAVIS environment variable to see if it’s set to true

[04:32:25.0000] 
but I don’t see where/how that TRAVIS variable ever gets set

[04:33:27.0000] 
ah nm

[04:33:50.0000] 
from https://docs.travis-ci.com/user/environment-variables/#Default-Environment-Variables I see it’s set by Travis itself

[04:41:46.0000] 
👍

[05:28:51.0000] 
mkwst: is specifying data: as a source in a CSP policy still unsafe?

[05:29:08.0000] 
or is it handled differently in Blink now at least?

[05:29:54.0000] 
I mean as far as the thing about data: URLs running in a unique origin

[05:30:40.0000] 
I don’t have a clear understanding if that makes data: safer or not as far as CSP goes

[05:31:11.0000] 
*I mean as far as the thing about *scripts* from data: URLs running in a unique origin

[08:38:11.0000] 
MikeSmith: Framed `data:` URLs produce a document running in an opaque origin (e.g. `