| 01:08 | <Domenic> | jolvera: definitely, yeah. We have one possibility in progress at https://github.com/whatwg/html/pull/2751 but it's client side and breaks some things that currently work, like where the spec highlights certain parts of the code as bad or good or changed. |
| 01:08 | <Domenic> | I'm hoping TabAtkins can factor out his highlighter from Bikeshed so we can run through that |
| 01:09 | <TabAtkins> | Oh, you want that? It's just Pygments, with some extra code to merge highlighting into existing markup. |
| 01:09 | <TabAtkins> | Tho there's also now custom line-numbering/highlighting code too. |
| 01:11 | <TabAtkins> | Oh, plus it relies on widlparser for highlighting WebIDL, because Pygments doesn't do that language. |
| 01:12 | <Domenic> | Yeah, don't need the line number stuff really, but packaging up pygments + merge + Web IDL into something we could shell out to would be lovely |
| 01:14 | <TabAtkins> | Can you just shell out the html contents of a given element? Much easier if that's all I need to worry about, rather than parsing and finding the highlightable elements myself. |
| 01:22 | <jolvera> | if it's Pygments it can be added through the build process |
| 01:22 | <jolvera> | right? |
| 01:22 | <TabAtkins> | Actually, I need an intermediate format - text requires me to include a full parser, but markup doesn't have a cross-lang built-in data structure. You have the parsed spec, right? Can you generate a `[tagname, {attrs}, ...contents]`-style tree? |
| 01:22 | <TabAtkins> | jolvera: It's not *just* Pygments, because Pygments only works on raw text. Bikeshed has extra smarts to merge it into existing markup. |
| 01:24 | <jolvera> | oh ok, im not familiar with Bikeshed |
| 01:35 | <Domenic> | TabAtkins: yes, that should work. |
| 01:36 | <Domenic> | Oh, then I read the intermediate format thing |
| 01:36 | <Domenic> | Probably still doable |
| 01:36 | <Domenic> | Let me capture this in an issue |
| 01:38 | <jolvera> | i've another question, that maybe i should ask in the issue, but |
| 01:38 | <jolvera> | https://github.com/whatwg/html/issues/2779 |
| 01:38 | <jolvera> | the former implementation used a search_index.json that probably was generated on build process |
| 01:39 | <jolvera> | https://github.com/benschwarz/developers.whatwg.org/blob/97ff943a8f5b8fe38f78e224b4b44b472ccefb57/javascript/master.js#L44-L53 |
| 01:40 | <Domenic> | jolvera: yep, re-generating that is the primary task. Unfortunately our build tooling is kind of hard to hack on :(. |
| 01:40 | <jolvera> | generating the index on page load async isn't an option? |
| 01:41 | <Domenic> | Like... downloading and spidering every page of the spec to assemble it each time? That seems pretty slow to me... |
| 01:41 | <jolvera> | not on load, and if someone happen to click the search box before it's done adding a message of loading? |
| 01:41 | <jolvera> | well, just getting the list of links to create a index on memory |
| 01:41 | <jolvera> | as in https://dsh.re/c3498 |
| 01:41 | <Domenic> | Still, spidering 40+ pages to find all their headings seems pretty hard... |
| 01:42 | <Domenic> | And slow |
| 01:42 | <Domenic> | Better than nothing I guess? |
| 01:43 | <jolvera> | worth a try |
| 01:44 | <jolvera> | unless, is there a way to add separate processes like in python |
| 01:45 | <jolvera> | a small python script could do this on build process |
| 01:45 | <jolvera> | or node |
| 01:46 | <Domenic> | Yeah, that is probably the best middle ground |
| 01:46 | <Domenic> | Ideally we would integrate it into our existing build tooling, which is already traversing the document |
| 01:46 | <Domenic> | I think I'd like to try that, at least |
| 01:46 | <Domenic> | But the tooling is written in FreePascal, which makes it hard to find contributors |
| 01:46 | <Domenic> | So we're open to slower alternatives written in normal languages |
| 01:47 | <jolvera> | kk |
| 01:50 | <Domenic> | https://github.com/whatwg/html-build/issues/113 for syntax highlighting, TabAtkins |
| 02:30 | <jolvera> | Domenic is it possible to add classes to h2, h3, and h4 inside the section page? |
| 02:31 | <jolvera> | `<h3 id="is-this-html5?">` to `<h3 id="is-this-html5?" class="section-heading">` |
| 02:31 | <Domenic> | jolvera: I don't see why we'd need it? h3 is always a section heading |
| 02:32 | <jolvera> | to generate the search_index.json and make the scrapping faster |
| 02:32 | <jolvera> | and get each one ordered on the way |
| 02:33 | <jolvera> | instead i'd have to get all h3's then h4's and order based on the '.secno' |
| 02:35 | <Domenic> | Why order based on secno? They're already in order |
| 02:35 | <Domenic> | querySelectorAll("h3, h4") --> all in order |
| 02:38 | <jolvera> | oh ok, you right, that actually works on python too |
| 02:38 | <Domenic> | \o/ |
| 02:38 | <jolvera> | html.cssselect('h3, h4') gives me the same output. nvm then :) |
| 05:38 | <jolvera> | i've created a python script that generates the same search_index.json file as the ruby version |
| 05:38 | <jolvera> | https://gist.github.com/thinkxl/f8722c6fba97e97d67e84cb32c22cb5f |
| 05:40 | <jolvera> | if we would use this, how it could be integrated into the build process |
| 05:41 | <jolvera> | it has two dependencies, lxml and cssselect |
| 05:41 | <jolvera> | cc Domenic |
| 05:43 | <jolvera> | i'll update the GitHub issue |
| 09:39 | <annevk> | TabAtkins: nox: I think the main concern with Houdini is that it might force slow paths in the future as it's primarily being built on top of a single-thread architecture for doing all things CSS |
| 09:41 | <annevk> | TabAtkins: nox: see e.g. https://twitter.com/pcwalton/status/835937849237106688 |
| 09:41 | <annevk> | (and replies) |
| 11:56 | <yhirano__> | annevk: can you tell me the relationship between RFC2045 and mime type parsing algorithm in https://mimesniff.spec.whatwg.org/? |
| 12:02 | <annevk> | yhirano__: I haven't investigated MIME type parsing |
| 12:03 | <yhirano__> | It's referenced from XHR overrideMimeType, and you wrote a wpt depending on the behavior. |
| 12:03 | <yhirano__> | annevk: http://w3c-test.org/XMLHttpRequest/overridemimetype-blob.html |
| 12:06 | <annevk> | yhirano__: I tried to pick MIME types that are invalid in both the RFC and the MIME Sniffing |
| 12:06 | <yhirano__> | annevk: "HI/x;test", used in the last case, seems valid in the algorithm and invalid in RFC2045. Is that intentional? |
| 12:08 | <annevk> | yhirano__: it wasn't |
| 12:08 | <annevk> | yhirano__: I'd be okay if we changed that to ;test=test |
| 12:09 | <yhirano__> | annvk: thanks, we |
| 12:09 | <yhirano__> | annevk: thanks, we'll change it. |
| 12:59 | <GPHemsley> | yhirano__: It's been a while, but I might be of some assistance here |
| 13:02 | <GPHemsley> | yhirano__: As I recall, the decision to allow keys without values in the MIME type parsing algorithm was to accommodate 'base64' in data URLs |
| 13:02 | <GPHemsley> | so we didn't have to special case |
| 13:04 | <GPHemsley> | (see step 9 in serializing a MIME type0 |
| 13:19 | <yhirano__> | GPHemsley: We are currently using the parser for RFC2045 and as an implementer it would be really great if the spec could also use it. Maintaining many similar (but differnt) parsers is really hard... |
| 13:21 | <yhirano__> | GPHemsley: It's OK to add or remove some restrictions to/from the RFC2045 rule, but with the current (really complicated) algorithmic style It's hard to see how different it is from the RFC2045 rule. |
| 13:27 | <GPHemsley> | yhirano__: When the definition of a language goes from context-free to context-sensitive, the parsing algorithm necessarily becomes more complex. |
| 13:28 | <GPHemsley> | yhirano__: That said, I'm no longer the maintainer of the spec, so changes (or lack thereof) are no longer my call. |
| 15:41 | <wanderview> | JakeA: who cares about requestIdleCallback() in chrome? |
| 15:42 | <wanderview> | eh, I'll just write an issue |
| 15:43 | <JakeA> | wanderview: igrigorik & Ross Mcilroy |
| 15:44 | <wanderview> | thanks |
| 15:44 | <wanderview> | igrigorik: is this expected behavior? https://bugs.chromium.org/p/chromium/issues/detail?id=739750 |
| 15:45 | <JakeA> | ohh that's a good one |