| 01:16 | <MikeSmith> | TabAtkins: about the highlighter, --output html seems to not work |
| 01:16 | <MikeSmith> | echo '["pre", {}, "interface Foo {};"]' | python2.7 ./highlighter/__init__.py --output html webidl |
| 01:16 | <MikeSmith> | ...still emits JSON output |
| 11:39 | <jyasskin> | 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? |
| 11:42 | <annevk> | jyasskin: I suspect it needs some Fetch integration |
| 11:42 | <annevk> | jyasskin: in particular, it seems this is another header that violates the same-origin policy? |
| 11:44 | <jyasskin> | 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? |
| 11:44 | <annevk> | jyasskin: it's a non-safelisted header included in cross-origin requests |
| 11:45 | <jyasskin> | https://fetch.spec.whatwg.org/#cors-safelisted-request-header in particular? |
| 11:45 | <annevk> | 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 |
| 11:46 | <annevk> | jyasskin: yeah |
| 11:46 | <jyasskin> | 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? |
| 11:46 | <annevk> | jyasskin: it doesn't matter much since the value isn't attacker-controlled (and when it is, there'll be a preflight), but still |
| 11:47 | <annevk> | jyasskin: something similar to Sec-Metadata I suspect |
| 11:47 | <annevk> | (although that might not be fully defined yet) |
| 11:48 | <jyasskin> | I think Sec-Metadata is still in the sketch phase, while Purpose is actually shipped without the matching specification. |
| 11:48 | <annevk> | jyasskin: I guess I'd expect something similar to https://github.com/whatwg/fetch/pull/751 |
| 11:48 | <annevk> | jyasskin: check if request's initiator is "prefetch", then append it |
| 11:49 | <annevk> | jyasskin: maybe also prerender? |
| 11:52 | <jyasskin> | 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. |
| 11:54 | <annevk> | jyasskin: browser-initiated fetches ideally still go through Fetch |
| 11:54 | <jyasskin> | Ok, good to know. |
| 11:55 | <annevk> | jyasskin: otherwise it's easy to accidentally bypass SOP |
| 11:55 | <annevk> | jyasskin: sleevi might not necessarily agree though, https://github.com/whatwg/fetch/issues/530 has a bunch of details |
| 12:45 | <annevk> | 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 |
| 12:46 | <annevk> | Is it just too complicated to allocate the cells and therefore browsers / the spec give up? |
| 12:55 | <annevk> | I think per spec I'm doing the right thing (and the conformance checker agrees), but browsers are sad |
| 13:04 | <zcorpan_> | annevk: isn't it, though? set a height to 3em the they cell to visualize it |
| 13:06 | <annevk> | zcorpan_: I'm not sure I follow |
| 13:06 | <annevk> | zcorpan_: I filed https://github.com/whatwg/html/issues/3738 meanwhile |
| 13:08 | <zcorpan_> | annevk: commented |
| 13:10 | <annevk> | zcorpan_: why would it be collapsed? |
| 13:10 | <zcorpan_> | annevk: cells shrink-wrap and it doesn't need more space than that? |
| 13:10 | <annevk> | Yeah I guess, that's rather weird |
| 13:11 | <zcorpan_> | you can see a slight jigger caused by the cell spacing |
| 13:11 | <annevk> | I guess there's still the magic issue with the spec, but it does seem this "works as intended" |
| 13:40 | <bradleymeck> | 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/ |
| 13:46 | <annevk> | bradleymeck: did you see https://github.com/whatwg/mimesniff/issues/43? |
| 13:46 | <bradleymeck> | 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 |
| 13:47 | <bradleymeck> | 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 |
| 13:48 | <bradleymeck> | most of the difference is wanting to match URLSearchParams more closely I think |
| 13:49 | <annevk> | That sounds wrong, since that allows for duplicates and this doesn't, afaik |
| 13:50 | <bradleymeck> | 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 |
| 13:51 | <annevk> | I don't know what that means |
| 13:52 | <annevk> | If it means you support duplicate names, it's not an implementation of the standard you referenced |
| 13:52 | <bradleymeck> | 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` |
| 13:54 | <bradleymeck> | 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 |
| 13:55 | <annevk> | bradleymeck: does Node.js's HTML parser expose duplicate attributes? |
| 13:55 | <bradleymeck> | Node doesn't have an HTML parser, but it does expose duplicate query parameters |
| 13:55 | <bradleymeck> | and http headers too |
| 13:56 | <annevk> | For both of those it's explicitly part of the data model |
| 13:56 | <annevk> | That's a pretty significant difference |
| 13:59 | <bradleymeck> | 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 |
| 14:00 | <bradleymeck> | per the WHATWG parser it does explicitly drop duplicates, but that doesn't seem to be a requirement of MIME itself |
| 14:08 | <annevk> | 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 |
| 14:08 | <annevk> | bradleymeck: there's also no hint that I know of that indicates they are to be multimaps |
| 14:08 | <bradleymeck> | annevk: the whatwg tests actually require the parameters to be ordered |
| 14:09 | <bradleymeck> | but that might just be a symptom of how they are written |
| 14:10 | <bradleymeck> | 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. |
| 14:10 | <annevk> | bradleymeck: https://tools.ietf.org/html/rfc2045#section-5 at least says it's a set |
| 14:12 | <bradleymeck> | 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 |
| 14:13 | <annevk> | bradleymeck: there's other differences too, such as the WHATWG standard handling text/html; per how servers expect clients to do so |
| 14:14 | <bradleymeck> | annevk: is there something that needs to be done beyond following https://mimesniff.spec.whatwg.org/ 's algorithm for that? |
| 14:15 | <bradleymeck> | I was running all my tests against the data in https://github.com/web-platform-tests/wpt/tree/master/mimesniff/mime-types/resources |
| 14:16 | <annevk> | bradleymeck: I meant relative to the RFC |
| 14:16 | <bradleymeck> | ah, yes, thats largely why I am not going with RFC as the parsing algorithm. |
| 14:16 | <annevk> | bradleymeck: since if you rather follow that and its data model, this is not the way to go |
| 14:16 | <annevk> | ok |
| 14:17 | <bradleymeck> | 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 |
| 14:18 | <bradleymeck> | requires that the parameters be ordered if you do that, but the whatwg tests fail if you produce things out of order |
| 14:20 | <annevk> | 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 |
| 14:21 | <annevk> | But I guess we'd be slightly more interoperable with other MIME types |
| 14:22 | <bradleymeck> | why not change the `output` to be an `{ type: string, subtype: string, parameters { [key: string]: value: string }`? wouldn't that avoid randomizing or sorting? |
| 14:22 | <bradleymeck> | I could PR that, but thought it might be a bit of a burden for people using the existing tests |
| 14:23 | <annevk> | bradleymeck: there's a number of places that need to serialize |
| 14:27 | <bradleymeck> | 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 |
| 14:29 | <annevk> | bradleymeck: right, for serializing you'd need sorting (so you can rely on order) or randomizing (so nobody relies on order) |
| 14:33 | <bradleymeck> | 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? |
| 14:34 | <annevk> | I'm not sure how that would meet the requirements |
| 14:36 | <bradleymeck> | if your `input` has to match multiple `output`s that are in different order wouldn't that ensure that it is unordered? |
| 14:49 | <TabAtkins> | MikeSmith: Yes, it emits a JSON object. But the value of the "html" key is a string of HTML, not of JSON-encoded HTML. |
| 14:50 | <MikeSmith> | TabAtkins: so what does --output html do? |
| 14:50 | <MikeSmith> | ah |
| 14:50 | <TabAtkins> | What I just said, controls what format the "html" key is in. |
| 14:50 | <MikeSmith> | I see |
| 14:51 | <MikeSmith> | I was hoping to get just HTML back |
| 14:51 | <MikeSmith> | the consuming code I wrote in wattsi just expects HTML |
| 14:51 | <TabAtkins> | I need to emit the HTML and CSS separately so you don't spam CSS into the spec for every single highlight. |
| 14:51 | <MikeSmith> | I see |
| 14:51 | <MikeSmith> | OK |
| 14:52 | <MikeSmith> | well the bigger problem Iâve realized I have is that all the HTML examples in the HTML spec use < instead of "<" |
| 14:52 | <MikeSmith> | because, you know, theyâre in an HTML document |
| 14:53 | <MikeSmith> | but Pygments apparently doesnât recognize character entities |
| 14:53 | <TabAtkins> | 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. |
| 14:53 | <MikeSmith> | yeah that ' |
| 14:54 | <MikeSmith> | yeah thatâs not the way wattsi works |
| 14:54 | <TabAtkins> | I mean that if your input is `<pre>`, then by the time you read the DOM you should just get out "<pre>", right? |
| 14:54 | <TabAtkins> | Sigh. |
| 14:54 | <MikeSmith> | I donât read the DOM |
| 14:54 | <MikeSmith> | I donât re-parse the source |
| 14:55 | <MikeSmith> | at the point where I emit this content, wattsi just sees strings |
| 14:56 | <TabAtkins> | How much escapes you got? Just <? |
| 14:57 | <MikeSmith> | I think so |
| 14:57 | <MikeSmith> | it is whatever escapes were used by whoever authored the particular example |
| 14:58 | <MikeSmith> | I think by convention everybody only escapes the "<" |
| 14:58 | <MikeSmith> | because thatâs the only one necessary |
| 14:58 | <MikeSmith> | example: |
| 14:58 | <MikeSmith> | [ |
| 14:58 | <MikeSmith> | "pre", |
| 14:58 | <MikeSmith> | { |
| 14:58 | <MikeSmith> | "id": "intro-early-example" |
| 14:58 | <MikeSmith> | }, |
| 14:58 | <MikeSmith> | "<!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>" |
| 14:58 | <MikeSmith> | ] |
| 14:59 | <TabAtkins> | If it's a finite set, I can give you an option for a quick unescape. |
| 14:59 | <MikeSmith> | OK |
| 14:59 | <MikeSmith> | I think just < |
| 15:00 | <MikeSmith> | anyway to be clear, even in terms of the DOM, the contents of all the examples are just text nodes |
| 15:00 | <MikeSmith> | inside <pre> elements |
| 15:00 | <MikeSmith> | oh |
| 15:01 | <TabAtkins> | I thought you wanted to highlight the webidl parts too? |
| 15:01 | <MikeSmith> | yes |
| 15:01 | <TabAtkins> | Which have <a>, <dfn>, etc. |
| 15:01 | <MikeSmith> | yes |
| 15:01 | <MikeSmith> | that is the exception |
| 15:01 | <MikeSmith> | and that is the other big problem I ran into |
| 15:01 | <TabAtkins> | 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. |
| 15:02 | <MikeSmith> | the highlighter does not seem to handle those as expected |
| 15:03 | <MikeSmith> | [ "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};" ], |
| 15:04 | <MikeSmith> | or simpler case: |
| 15:04 | <MikeSmith> | echo '[ "pre", { "class": "idl" }, "[NoInterfaceObject]\ninterface ", [ "dfn", { "id": "noncedelement" }, "NoncedElement" ], " {\n attribute DOMString nonce;\n};" ]' | python2.7 ./highlighter/__init__.py webidl |
| 15:04 | <MikeSmith> | => TypeError: sequence item 1: expected string or Unicode, list found |
| 15:05 | <MikeSmith> | ... if I remove [ "dfn", { "id": "noncedelement" }, "NoncedElement" ] from that JSON object, that error goes away |
| 15:05 | <TabAtkins> | Sigh, I just spotted the bug. Fix is pushed. |
| 15:05 | <TabAtkins> | Me looping over a container then returning the container rather than the item. :/ |
| 15:08 | <MikeSmith> | glad it was an easy fix :) |
| 15:22 | <TabAtkins> | MikeSmith: Okay, added a --unescape flag that unescapes the "big 5" for HTML - &<>'" |
| 15:25 | <MikeSmith> | \o/ thank you thank you thank you |
| 15:25 | <MikeSmith> | will get back to it in the morning my time |
| 16:15 | <MikeSmith> | TabAtkins: --unescape working beautifully, and the embedded markup in IDL too |
| 16:16 | <MikeSmith> | working on integrating it back into wattsi+html-build |
| 16:16 | <MikeSmith> | (as long as my insomnia lasts) |
| 16:17 | <TabAtkins> | Do you want, like, a --just-html and --just-css argument too, so you can get them independently and shove them in easier? |
| 16:17 | <MikeSmith> | TabAtkins: yes please |
| 16:18 | <MikeSmith> | I think I only need the CSS once, right? |
| 16:18 | <TabAtkins> | (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.) |
| 16:18 | <MikeSmith> | aha |
| 16:18 | <MikeSmith> | OK |
| 16:19 | <TabAtkins> | So you can just pass some nonsense el to it to get the CSS out when you need it, I suppose. |
| 16:19 | <MikeSmith> | 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 |
| 16:19 | <MikeSmith> | I think |
| 16:20 | <MikeSmith> | oh hey one thing: in the --output html output, newlines get emitted as "\n" (like for JSON) instead of as newlines |
| 16:20 | <MikeSmith> | ah but thatâs within JSON |
| 16:21 | MikeSmith | tries to remember if we have a JSON parser in the wattsi code |
| 16:23 | <TabAtkins> | Right. |
| 16:24 | <TabAtkins> | With --output=html --just=html it'll print directly, no \n |
| 16:27 | <TabAtkins> | MikeSmith: And pushed |
| 16:27 | <MikeSmith> | ...and just pulled |
| 16:27 | <MikeSmith> | beautiful |
| 16:27 | <MikeSmith> | perfect |
| 16:28 | <MikeSmith> | thanks very very much |
| 16:28 | <TabAtkins> | np |
| 16:29 | <MikeSmith> | I should be able to get the related wattsi+html-build stuff landed this week |
| 16:29 | <MikeSmith> | and then finally syntax-hightlighted examples in the HTML spec |
| 16:30 | <MikeSmith> | thanks to magic of combining Free Pascal + Python + TabAtkins |
| 16:31 | <TabAtkins> | Yay! |
| 16:31 | <MikeSmith> | :) |
| 16:33 | <MikeSmith> | and a bonus is that this may push the size of the single-page output of the spec up to 10MB! |
| 16:33 | <MikeSmith> | after all the years we been trying hard to get it there |
| 16:33 | <MikeSmith> | currently itâs still just a tiny 8.5MB |
| 16:33 | <annevk> | MikeSmith: euh that's probably worth a discussion before we land? |
| 16:33 | <annevk> | MikeSmith: or is it already close to 10? |
| 16:34 | <annevk> | MikeSmith: I see |
| 16:34 | <MikeSmith> | annevk: only 8.5MB now |
| 16:34 | <MikeSmith> | yeah |
| 16:34 | <MikeSmith> | maybe this wonât really add an additional 1.5MB, I dunno |
| 16:34 | <MikeSmith> | but we got a lot of examples... |
| 16:35 | <annevk> | That seems good to verify as a 15-20% increase or so will also affect the speed of multipage |
| 16:37 | <MikeSmith> | yeah this basically makes the source of each example at least 4 times bigger |
| 16:38 | <MikeSmith> | anyway weâll find out soon enough, once I got the highlighter plugged in |
| 16:42 | <TabAtkins> | If HTML had added <c> for inline text (for "character") we'd shave a lot of weight off of that. ^_^ |
| 16:42 | <TabAtkins> | And then I'd be able to write my terrible talk "Learn the <a> <b> <c>s of HTML". |
| 16:46 | <MikeSmith> | heh |
| 16:50 | <astearns> | would "Learn the <a> <b> <c-s> of HTML" work? |
| 16:53 | <tantek> | astearns: Learn the <a> <b> Cs(s) of HTML? |
| 16:56 | <TabAtkins> | astearns: That's only a 2-characters savings per element, and so not very impressive. (one per tag) |
| 16:57 | <TabAtkins> | Wait tho. |
| 16:58 | <TabAtkins> | Actually... if I could bake the classes into the tagname, it would save a bunch more characters. |
| 16:58 | <TabAtkins> | <c-kt>...</c-kt>, versus <span class=kt>...</span> |
| 16:59 | <TabAtkins> | I *think* it highlights with only a single class per? I'd have to check. |
| 17:01 | <TabAtkins> | Are arbitrary attributes allowed on custom elements, or do they still have to be data-*? |
| 17:08 | <TabAtkins> | Looks like arbitrary attributes are allowed, per both MDN and spec examples, nice. |
| 17:12 | <TabAtkins> | <c- kt>...</c-> is 12 characters of weight, and looks to be valid, versus <span class='kt'>...</span> which is 24 characters of weight. I can literally halve the weight-cost of highlighting. |
| 17:16 | tantek | watches as TabAtkins rediscovers XML ;) |
| 17:17 | <TabAtkins> | golfing ftw |
| 17:17 | tantek | remembers when it was tennis |
| 17:17 | <zcorpan> | TabAtkins: I think I like the idea of being able to wrap things for test annotations, <span>, <li>, <tr> -- could it be an attribute wpt-test? |
| 17:18 | <TabAtkins> | yeah, it def could be. Just requires some more sophisticated handling for output. |
| 17:30 | <zcorpan> | đ |
| 17:31 | <astearns> | I love it when a dumb joke turns into a terrible hack |
| 17:40 | <TabAtkins> | And... pushed. Highlight weight is now magically cut in half. |
| 17:47 | <TabAtkins> | I could cut it a little bit more if I explode out the namespace - going with <kt->...</kt-> saves one character, and for the single-char classes I'd save 3. |
| 17:53 | <TabAtkins> | 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. |
| 18:47 | <jugglinmike> | Domenic: I believe there's no intention of unifying DOM streams and Node.js streams. Is that correct? |
| 18:47 | <Domenic> | jugglinmike: up to Node.js, I guess? |
| 18:48 | <jugglinmike> | Oh, okay |
| 19:06 | <bradleymeck> | are Blobs frowned upon these days? I do see them in Response objects but was wondering |
| 19:10 | <Domenic> | Blobs are OK. The FileReader API is terrible, but there's no good alternative yet. Blob URLs are frowned upon in general. |
| 19:21 | <bradleymeck> | Domenic: thanks |
| 20:09 | <a-ja> | MikeSmith, FYI, incoming in a few weeks, new aria roles blockquote paragraph and caption < https://w3c.github.io/aria/#changelog > |
| 20:33 | <Mek> | there is a great alternative to the FileReader API: new Response(blob).body gives you a ReadableStream to read the blob |
| 20:33 | <Mek> | and yeah, Blob URLs are terrible |
| 23:02 | <Domenic> | new Response(blob).whatever still feels like a hack to me, but you're right :) |
| 23:21 | <MikeSmith> | TabAtkins: per https://drafts.csswg.org/css-fonts-3/#font-prop is body { font: 3.5mm message-box,serif,helvetica,sans-serif; } |
| 23:21 | <MikeSmith> | .. valid? |
| 23:21 | <MikeSmith> | the context is https://github.com/validator/validator/issues/661#issuecomment-394836779 |
| 23:22 | <MikeSmith> | the CSS checker reports an error for body { font: 3.5mm message-box,serif,helvetica,sans-serif; } |
| 23:22 | <MikeSmith> | but not for body { font: 3.5mm message-box,serif,helvetica,sans-serif; } |
| 23:23 | <MikeSmith> | as far as I read that grammar, both should actually be valid, right? |
| 23:23 | <MikeSmith> | [ [ <âfont-styleâ> || <font-variant-css21> || <âfont-weightâ> || <âfont-stretchâ> ]? <âfont-sizeâ> [ / <âline-heightâ> ]? <âfont-familyâ> ] | caption | icon | menu | message-box | small-caption | status-bar |
| 23:24 | <MikeSmith> | ... |
| 23:25 | <MikeSmith> | though in both cases âmessage-boxâ doesnât mean the system font but instead is just a (non-existent) font-family name? |
| 23:25 | <TabAtkins> | Yes |
| 23:25 | <MikeSmith> | OK thanks |
| 23:26 | <TabAtkins> | If you want the message box font, you do it all by itself |
| 23:26 | <MikeSmith> | right |
| 23:26 | <MikeSmith> | OK |
| 23:26 | <TabAtkins> | But yeah it's valid |
| 23:26 | <MikeSmith> | hai |
| 23:28 | <MikeSmith> | 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 |