| 00:16 | <smaug____> | Domenic: why CustomElements take reference to the lifecycle callbacks? Couldn't it just call the relevant methods in the prototype? |
| 00:17 | <smaug____> | (in other words I think https://github.com/heycam/webidl/issues/101 needs to be fixed somehow. The current specs using ctor as a callback are hard to follow and error prone to maintain ) |
| 00:19 | <smaug____> | (but still no idea how, since I don't know what has lead to the way ctors and classes are being used right now) |
| 05:27 | <MikeSmith> | botie, inform zcorpan I wonder if you could run a query for me and find out how widely used lang=zh-Hans* and lang=zh-Hant* are on the Web relative to lang=zh-cn* and lang=zh-tw* |
| 05:27 | <botie> | will do |
| 05:28 | <MikeSmith> | botie, inform zcorpan I suspect lang=zh-Hans* and lang=zh-Hant* are used almost not at all in practice yet (and maybe never really will be) |
| 05:28 | <botie> | will do |
| 05:29 | <MikeSmith> | botie, inform zcorpan this is related to implementation of https://github.com/validator/validator/issues/284 “Check for missing lang and mislabeled lang” |
| 05:29 | <botie> | will do |
| 05:43 | <annevk> | TabAtkins: supported the cause |
| 06:02 | <MikeSmith> | annevk: I suspect the other commentors there did not realize a new camelcase element would require a parser change |
| 06:03 | <MikeSmith> | but now I wonder who will be the first purpose to comment to say, Well, if you’re already special-casing others, than it can’t really be much trouble to just add this one to the existing special-case list |
| 06:03 | <MikeSmith> | or something like that |
| 06:03 | <MikeSmith> | because consistency |
| 06:04 | <annevk> | Then my next question will be about how many HTML parser implementers vouched for this |
| 06:04 | <annevk> | But I think they generally want to do the right thing these days, they just might not know as you say |
| 06:10 | <MikeSmith> | yeah |
| 07:17 | <botie> | zcorpan, at 2016-07-01 05:27 UTC, MikeSmith said: I wonder if you could run a query for me and find out how widely used lang=zh-Hans* and lang=zh-Hant* are on the Web relative to lang=zh-cn* and lang=zh-tw* and at 2016-07-01 05:28 UTC, MikeSmith said: I suspect lang=zh-Hans* and lang=zh-Hant* are used almost |
| 07:17 | <botie> | not at all in practice yet (and maybe never really will be) and at 2016-07-01 05:29 UTC, MikeSmith said: this is related to implementation of https://github.com/validator/validator/issues/284 “Check for missing lang and mislabeled lang” |
| 08:20 | <MikeSmith> | zcorpan: thanks! |
| 08:21 | <zcorpan> | welcome |
| 08:22 | <zcorpan> | y'all should sign up for a bigquery account |
| 08:29 | <MikeSmith> | think I did at one point |
| 08:30 | <MikeSmith> | guess I should actually use it :) |
| 08:32 | <MikeSmith> | zcorpan: so there is some non-insignificant performance impact from implementing language detection in the checker |
| 08:32 | <alwu> | zcorpan, hi, I'm alastor0325, I would like to ask a question about webvtt rendering. If we modify the value of attributes of cues (eg. line, position), should we update the rendering immediately? If so, did we mention that in the spec? Thanks! |
| 08:36 | <zcorpan> | alwu: good question :-) |
| 08:36 | <zcorpan> | "When a WebVTT cue whose active flag is set has its writing direction, snap-to-lines flag, line, position, size, text alignment, region, or text change value, then the user agent must empty the text track cue display state, and then immediately run the text track’s rules for updating the display of WebVTT text tracks." |
| 08:37 | <zcorpan> | i suppose that should be updated to also cover position alignment etc |
| 08:40 | <alwu> | got it, thanks :) |
| 08:42 | <zcorpan> | alwu: also see https://w3c.github.io/webvtt/#css-extensions |
| 08:45 | <alwu> | ok! |
| 08:55 | <Ms2ger> | Manishearth, complain at zcorpan? :) |
| 08:56 | <zcorpan> | woot? |
| 08:57 | <Ms2ger> | Btw, Servo has a technical demo out: https://blog.servo.org/2016/06/30/servo-nightlies/ |
| 08:57 | <Ms2ger> | Don't use it for your bank |
| 08:58 | <Manishearth> | zcorpan: why should html/semantics/embedded-content/the-img-element/update-the-image-data/fail-to-resolve.html pass? |
| 08:58 | <Manishearth> | zcorpan: if the URL fails to parse, the spec says to abort the steps before the request (which updates the current source) is initiated |
| 08:59 | <Manishearth> | > ⌛ Parse selected source, relative to the element's node document, and let urlString be the resulting URL string. If that is not successful, abort these steps. |
| 09:02 | <zcorpan> | Manishearth: that is the algorithm to run when the *environment changes* |
| 09:02 | <zcorpan> | Manishearth: that is not the case in this test |
| 09:02 | <zcorpan> | Manishearth: you want to look at https://html.spec.whatwg.org/multipage/embedded-content.html#update-the-image-data |
| 09:03 | <zcorpan> | step 11 |
| 09:06 | <zcorpan> | MikeSmith: are you analyzing the entire doc? can it be limited? |
| 09:07 | <MikeSmith> | zcorpan: I limited it |
| 09:07 | <zcorpan> | ok |
| 09:08 | <MikeSmith> | but the size of the text that the language detection gets run on does not seem to be the biggest factor |
| 09:08 | <MikeSmith> | right now I am limiting it to the first 3OK characters |
| 09:08 | <MikeSmith> | which seems to take no more measurable time than if I limited it to only 2K |
| 09:09 | <MikeSmith> | but as far as the rest of the implementation goes, it is affected by the size of the doc |
| 09:09 | <zcorpan> | is the cost initializing the analyzer? (can it be done once and re-used?) |
| 09:10 | <annevk> | Does anyone know if "filesystem" is a scheme that's a thing in one or more browsers? |
| 09:10 | <annevk> | At some point I added it to a few places, but I think it's mostly gone nowhere |
| 09:12 | <MikeSmith> | zcorpan: well the way the checker is architected, I cannot do implement it using a singleton instance the way the microsyntax/datatype checkers are done |
| 09:12 | <MikeSmith> | but it doesn’t matter, because the cost is not bound by that |
| 09:13 | <MikeSmith> | it seems to bound by the document size (though the call to the 3rd-party language-detection library code itself is not) |
| 09:14 | <MikeSmith> | so when test it locally I ran into OOM errors from the Java GC when I tested with the HTML spec, which is now 8.2MB |
| 09:15 | <MikeSmith> | but that was running with the default Java heap size restricted to just 128MB, which I think nowadays is just way too low for the checker anyway |
| 09:15 | <MikeSmith> | so, I upped it to 256MB and no more OOM errors |
| 09:16 | <MikeSmith> | though it still ran slightly more slowly than it does without the language-detection enabled |
| 09:17 | <zcorpan> | annevk: https://cs.chromium.org/search/?q="filesystem:http"&sq=package:chromium&type=cs |
| 09:17 | <MikeSmith> | zcorpan: so I upped the Java heap size to 512MB and now it seems to run at much closer to the same speed |
| 09:18 | <zcorpan> | MikeSmith: does the language checker use a lot of memory? |
| 09:19 | <MikeSmith> | no, the language-detection library itself does not, as far as I can see |
| 09:19 | <MikeSmith> | but my code seems to |
| 09:19 | <zcorpan> | ah ok |
| 09:19 | <MikeSmith> | I am not sure why |
| 09:20 | <zcorpan> | can you upload a diff? |
| 09:20 | <MikeSmith> | the fact that the OOM message was about Java GC seems to indicate it is creating a lot of objects quickly but they are not getting freed quickly |
| 09:21 | <MikeSmith> | zcorpan: yeah I will, and I am going to push it to https://checker.html5.org/ shortly |
| 09:21 | <zcorpan> | cool |
| 09:23 | <Manishearth> | zcorpan: why do we queue a task to change the current url? |
| 09:23 | <annevk> | Ms2ger: does Servo have its updating story figured out already? |
| 09:23 | <Manishearth> | should the error event get the old URL? |
| 09:23 | <Ms2ger> | annevk, no |
| 09:23 | <annevk> | Ms2ger: also, is it better than FirefoxNightly? |
| 09:23 | <annevk> | Ms2ger: I see |
| 09:23 | <zcorpan> | Manishearth: the idea is to change the url and fire the event in the same task |
| 09:23 | <Ms2ger> | I would not recommend trying to use it as a browser |
| 09:24 | <Manishearth> | zcorpan: hm |
| 09:24 | <annevk> | Ms2ger: it's crap at my blog |
| 09:25 | <annevk> | I like how it presents the selection cursor, but then fails at selection |
| 09:26 | <annevk> | Ms2ger: UX is pretty good though |
| 09:26 | <Ms2ger> | \o/ |
| 09:26 | <annevk> | Ms2ger: fails at security a bit, but probably fixable |
| 09:27 | <jgraham> | I think "fails at security a bit" is expected |
| 09:27 | <annevk> | jgraham: it's a little weird how they decided to not show the domain anywhere |
| 09:27 | <annevk> | jgraham: present a lock icon plus the title of the page is... I dunno |
| 09:28 | <jgraham> | Oh, in the UI? |
| 09:28 | <jgraham> | I didn't try that |
| 09:29 | <jgraham> | Speak to fabrice I guess |
| 09:29 | <annevk> | I should not have loaded the HTML Standard |
| 09:29 | <annevk> | I think I crashed it |
| 09:30 | <annevk> | Well that didn't last long 😊 |
| 09:39 | <zcorpan> | it gets the mobile view for w3.org |
| 09:40 | <zcorpan> | I got a FOUC on duckduckgo :-) |
| 09:59 | <MikeSmith> | zcorpan: https://github.com/validator/validator/commit/d1ee5cdb941051625e29ce4ac6ca44b2f2a4b38a |
| 09:59 | <MikeSmith> | and pushed to https://checker.html5.org/ |
| 10:13 | <zcorpan> | MikeSmith: is the garbage in elementContent, maybe? wild guess :-) |
| 10:15 | <alwu> | zcorpan : it seems that the spec didn't mention about how to parse the "cue identifier"? because I only found one place to set it to empty string, and didn't see other place to modify it. do I miss something? |
| 10:19 | <MikeSmith> | zcorpan: yeah though that would be the likely culprit, it does not seem to actually be. In debugging, I basically eliminated the text collection altogether and still ran in that GC OOM error. I think it could just be that since we are already running all these other filters of the parser for various other checks, it may not actually be anything particular in this new code itself, but instead it is just |
| 10:19 | <MikeSmith> | that the additional memory hit of adding any new filter at all just pushed it to the tipping point. |
| 10:19 | <MikeSmith> | *still ran into that GC OOM error |
| 10:26 | <zcorpan> | alwu: hmmmm. seems like i made a mistake in converting https://github.com/w3c/webvtt/issues/222#issuecomment-151361368 to spec text. |
| 10:32 | <zcorpan> | alwu: fix is to set cue identifier to buffer on cue creation, right? |
| 10:34 | <zcorpan> | MikeSmith: ok |
| 10:38 | <alwu> | zcorpan : seem yes :) ! but maybe we also need to check the content of the buffer? because the syntax rule mentions that the cue identifier can't contain the string "-->". |
| 10:40 | <zcorpan> | alwu: if the first line of a block has -->, buffer will be empty on cue creation, i believe |
| 10:40 | <zcorpan> | so no need to check |
| 10:40 | <alwu> | that means the cue identifier is empty? |
| 10:41 | <alwu> | like this file http://w3c-test.org/webvtt/webvtt-file-format-parsing/webvtt-file-parsing/support/arrows.vtt |
| 10:41 | <zcorpan> | yes |
| 10:41 | <zcorpan> | do you want to submit a PR for the spec? |
| 10:43 | <alwu> | zcorpan : ok, let me check how to modify it because I never send PR for the spec :) |
| 10:44 | <zcorpan> | i figured this could be a "good first bug" :-) |
| 10:46 | <smaug____> | annevk: sorry to ask about another thing here: https://html.spec.whatwg.org/multipage/forms.html#dom-input-valueasnumber |
| 10:46 | <smaug____> | I still can't parse that, how it returns number of months for type=month |
| 10:47 | <annevk> | smaug____: ooh, is that what Chrome does? |
| 10:47 | <smaug____> | annevk: based on the test jessica linked |
| 10:49 | <smaug____> | and yes, tested locally |
| 10:49 | <zcorpan> | MikeSmith: https://www.ingdirect.es/ - mislabeled only for legacy IE :-D |
| 10:52 | <annevk> | smaug____: I see, then Chrome is indeed wrong per spec :-/ |
| 10:52 | <smaug____> | annevk: ok, need to then test other browsers |
| 10:52 | <smaug____> | sounds like we'll need a spec change |
| 10:53 | <annevk> | smaug____: should probably ask https://github.com/tkent-google about this |
| 10:54 | <annevk> | smaug____: / tkent@ |
| 10:54 | <annevk> | sigh |
| 11:03 | <yoav> | Hey! I'm having trouble finding the definition Window's onload event and when and how it should fire |
| 11:03 | <yoav> | Looking at https://html.spec.whatwg.org/multipage/browsers.html#the-window-object I only see it defined for about:blank |
| 11:04 | <yoav> | (at least when CMD-Fing through the page) |
| 11:05 | <yoav> | any pointers would be appreciated! :) Specifically, I want to see if it should fire as part of a queued task or synchronously |
| 11:05 | <zcorpan> | yoav: https://html.spec.whatwg.org/multipage/syntax.html#stop-parsing |
| 11:06 | <zcorpan> | step 6 and 7 |
| 11:07 | <yoav> | OK, so it should fire after a task |
| 11:07 | <yoav> | Thanks! :) |
| 11:08 | <yoav> | zcorpan: Do you know if there are any tests that verify that this is what happens? I suspect that's not the case in WebKit (from inspecting the code), but want to make sure |
| 11:08 | <zcorpan> | MikeSmith: look great! https://github.com/validator/validator/issues/284#issuecomment-229920015 |
| 11:09 | <zcorpan> | MikeSmith: hope it has the impact we're looking for. can check httparchive somehow in a year or so and see if the amount of mislabeled pages has gone down |
| 11:11 | <zcorpan> | yoav: i see a simple test at http://w3c-test.org/html/syntax/parsing/the-end.html but it doesn't check if load is queued or sync |
| 11:12 | <yoav> | zcorpan: what I'm seeing in WebKit is that for <link rel=preload onload>, unless I sync them, they fire after Window.onload |
| 11:12 | <zcorpan> | how would you test it? setTimeout in DOMContentLoaded? |
| 11:13 | <yoav> | zcorpan: I don't know. That's why I'm asking :) |
| 11:13 | <zcorpan> | yoav: "The preload link element must not delay the load event of the element's node document." |
| 11:14 | <yoav> | unless it was discovered |
| 11:15 | <MikeSmith> | zcorpan: yeah seems certain it can help significantly over the long run. Will push it to https://validator.w3.org/nu/ maybe later today, and hopefully nothing blows up under load. The instances behind that are each processing at least 2.5 validation requests every second. |
| 11:17 | <MikeSmith> | zcorpan: Thanks for pushing for that featureーif you hadn’t taken time to raise that request I think it’s not something I would embarked on on my own |
| 11:17 | <yoav> | zcorpan: so if I have preload link for a resource which is later also part of the HTML, the load of that resource blocks the document's load event |
| 11:17 | <MikeSmith> | yoav: will send out some kind of announcement once I have it pushed to https://validator.w3.org/nu/ |
| 11:18 | <MikeSmith> | oofs |
| 11:18 | <MikeSmith> | meant that for zcorpan 😊 :) |
| 11:18 | <yoav> | :) |
| 11:19 | <zcorpan> | yoav: i suppose so. but it doesn't say what the relative ordering should be for <link onload> vs window.onload in that case, does it? |
| 11:20 | <yoav> | not really, no |
| 11:20 | <zcorpan> | nor, for that matter, <link> vs <img> that are loading the same url |
| 11:20 | <yoav> | should that be defined as part of the preload spec? |
| 11:20 | <zcorpan> | MikeSmith: sounds good. something for the whatwg blog, maybe? :-) |
| 11:22 | <zcorpan> | yoav: yeah i think so |
| 11:22 | <yoav> | OK, I'll file an issue |
| 11:23 | <yoav> | zcorpan: do you agree that logically, the resource's onload should fire before the document's onload? (like it does today for other resources) |
| 11:24 | <zcorpan> | if something was found that reuses the same load, and it delays the load event, then yes |
| 11:24 | <zcorpan> | no opinion on <link> vs <img>, but maybe <link> should be queued first? |
| 11:25 | <zcorpan> | no strong opinion... |
| 11:26 | <yoav> | zcorpan: yeah, I don't have strong opinions on <link> vs <img> either (maybe discovery order, which would put <link> first in most normal cases) |
| 12:06 | <yoav> | filed https://github.com/w3c/preload/issues/69 |
| 12:24 | <MikeSmith> | zcorpan: update on the language-detection: I pushed it to https://validator.w3.org/nu/ but it is only working as expected there maybe 50% of the time :( |
| 12:25 | <MikeSmith> | from teh logs I can see the reason is that the initialization of the language identifier is failing very often |
| 12:25 | <zcorpan> | MikeSmith: ok :-| |
| 12:28 | <MikeSmith> | a language-identifier object is getting created once for every document, and it reads some profile files each time it is created, so maybe not so surprising to have it failing a lot when that is happening 2.5 times a second |
| 12:29 | <MikeSmith> | I need to figure out how to create it just once and re-use it, but in the current structure of the rest of the checker code, it is not very clear how I can do that or if it is even possible with the current code |
| 12:30 | <gsnedders> | create a factory which has a LRU cache? |
| 12:30 | <gsnedders> | OH GOD I'M GOING FULL JAVA. |
| 12:34 | <MikeSmith> | zcorpan: actually I do have a specific idea and will try it |
| 12:35 | <zcorpan> | gsnedders: maybe need a factory factory? |
| 12:36 | <MikeSmith> | heh |
| 12:36 | <gsnedders> | zcorpan: html5lib has one of those *IN PYTHON*. |
| 12:36 | gsnedders | wishes he was joking, but it's seriously the most sensible approach |
| 12:37 | <MikeSmith> | actually for this case, I can write (another) wrapper around the SAX reader, which is how I implemented the outline feature |
| 12:37 | <MikeSmith> | just creates another filter off the SAX events from the parser |
| 12:38 | <MikeSmith> | similar to how I already implemented it except that if I do it this way I can pass objects to it |
| 12:39 | <MikeSmith> | gsnedders: you probably could not fail at Java worse than me :) and I been writing in Java relatively often for the last 5 years or so for the validator stuff |
| 12:40 | <gsnedders> | MikeSmith: I don't know, I've scarcely written much outside of uni, and I get the impression that there's actually much nicer ways to do many things now with some of the more recent changes |
| 12:42 | <MikeSmith> | yeah, though I don’t know most of the more recent features well until I see code that somebody else has written up that uses them (like the Salvation CSP library the validator uses now, which relies on some Java8 features) |
| 12:42 | <MikeSmith> | anyway in general I am basically just semi-randomly pulling levers and pushing buttons and banging on the side of it until something works |
| 12:52 | <JakeA> | Domenic: vague comment on streams API: I'm looking at making Handlebars work with streams. In their templates they have stuff like {{#if val}} - I want this conditional to be true if val is a stream that yields at least one value (since an empty array is false in Handlebars). This is tricky as the conditional is fed into a helper, but teeing will lock val. I |
| 12:52 | <JakeA> | want to read the first val but without consuming it. |
| 12:52 | <JakeA> | I guess I want .clone rather than .tee |
| 12:54 | <JakeA> | The helper is in the shape of function ifHelper(val), which should return true/false depending on val |
| 14:45 | <wanderview> | JakeA: isn't there an optional bool to clone chunks in the .tee? |
| 14:46 | <wanderview> | JakeA: also, isn't what you are trying to do a bit racy? what if there will be a value in the stream, but it just hasn't arrived yet? you want the to be a false? |
| 14:46 | <JakeA> | wanderview: I don't think so, but that's not the problem here. |
| 14:46 | <JakeA> | wanderview: I'm happy to wait, so there's no race |
| 14:47 | <wanderview> | JakeA: it waits until either a value appears or the stream is closed? |
| 14:47 | <JakeA> | wanderview: imagine streamEmitsAtLeastOneValue(stream).then(answer => …) |
| 14:47 | <JakeA> | But then I want to get that value from stream.getReader().read() |
| 14:48 | <wanderview> | JakeA: I think I would do this with a wrapper stream... new ReadableStream() where the underlying source contains the ReadableStream you want to observe and buffers a single value... you can then provide a promise hanging off this wrapper underlying source |
| 14:48 | <wanderview> | and pas the wrapper ReadableStream on to the next person in the chain |
| 14:49 | <wanderview> | pass |
| 14:49 | <JakeA> | I could tee the stream, pass one part to streamEmitsAtLeastOneValue, then continue using the other half of the tee |
| 14:49 | <JakeA> | But in this case I don't control the outside, I just receive a stream into a function |
| 14:50 | <wanderview> | JakeA: ah, yea... in that case you do have tee |
| 14:51 | <wanderview> | JakeA: assuming you have to have this as a separate function that takes a REadableStream arg |
| 14:52 | <JakeA> | wanderview: but if I tee, the original stream is locked |
| 14:52 | <wanderview> | JakeA: the person calling your function has to tee |
| 14:53 | <wanderview> | JakeA: your function is just a consuming function... so the caller has to deal with that |
| 14:53 | <JakeA> | wanderview: yeah, I guess I just have to put up with that. Means it doesn't work in a simple {{#if val}} template |
| 14:54 | <wanderview> | JakeA: can you make a HandleBarsReadableStream that gets created from the start that does the wrapping I talked about above? It could then expose its own stuff like "ever got a value promise" |
| 14:54 | <wanderview> | I guess I don't know enough about Handlebars |
| 14:56 | <JakeA> | wanderview: I could probably do it if I pull apart the guts of Handlebars. Wouldn't need to if it was like response.clone() :D |
| 14:56 | <wanderview> | JakeA: but you can't response.clone if anything else has touched the stream yet... seems a similar problem |
| 14:57 | <JakeA> | wanderview: happy to make "untouched" stream a requirement in this case |
| 14:58 | <wanderview> | JakeA: what are you using in handlebars? registerHelper()? |
| 14:58 | <JakeA> | wanderview: yeah |
| 14:59 | <annevk> | Ms2ger: did you look at https://github.com/whatwg/url/issues/53 already? |
| 14:59 | <annevk> | Ms2ger: seems like another issue with IDNA :/ |
| 14:59 | <annevk> | Ms2ger: they really didn't do their homework and just went with what made sense it seems like |
| 15:00 | <annevk> | Ms2ger: this is similar to the crypto folks at Mozilla implementing their own domain name parser and not caring about compat or consistency |
| 15:00 | <wanderview> | JakeA: it seems the value is passed in to the helper on the `this`, right? can you just overwrite it with the new stream out from the tee? |
| 15:00 | <Ms2ger> | annevk, no, I just wanted you to be aware of the servo change |
| 15:00 | <wanderview> | looking at the examples on handlebars.js.com |
| 15:01 | <JakeA> | wanderview: nah, `this` is the context. The conditional is passed in as the first arg |
| 15:01 | <annevk> | Ms2ger: I see, it makes me all rather sad |
| 15:01 | <Ms2ger> | annevk, that we can all agree ob |
| 15:01 | <Ms2ger> | on |
| 15:02 | <wanderview> | JakeA: probably worth a streams issue to capture the use case |
| 15:03 | <wanderview> | JakeA: its kind of a common problem, though, even in c++ land I had to make our "clone a stream" possibly give back a stream to replace the argument |
| 15:07 | <wanderview> | sometimes you just can't clone/tee a stream without draining the original |
| 15:08 | <JakeA> | yeah, I think that's the conclusion I'm coming to |
| 15:09 | <wanderview> | having an object the stream sits on (like Response) lets you hide this by replacing the original stream |
| 19:07 | <MikeSmith> | zcorpan: reimplemented the language-detection feature as a SAX reader wrapper and that appears to have solved the problem and it now should work again 100% as expected even at https://validator.w3.org/nu/ |
| 19:09 | <MikeSmith> | and pushed it to https://checker.html5.org/ too |
| 19:10 | <bkardell> | so... for helping me understand more, can someone point me to discussions around inert? I've searched both irc logs and mailing lists and I can't find more than a handful of references and most of those are initial comments by hixie saying 'I added this thing'. |
| 19:11 | <gsnedders> | bkardell: https://github.com/whatwg/html/issues/897 is possibly helpful |
| 19:12 | <bkardell> | gsnedders, yeah not really - I'm aware of that one too |
| 19:13 | gsnedders | isn't really aware of anywhere better that links to stuff, and expects others can summarise better than he |
| 19:13 | <wanderview> | JakeA: you around? |
| 19:14 | <JakeA> | wanderview: ish! |
| 19:14 | <bkardell> | not the attribute so much even - but there is a concept in the spec called 'inert' and, for example, it would seem that disabled elements are inert. inert is part of the magic of the platform, yet I'm not entirely sure how it works even |
| 19:15 | <wanderview> | JakeA: what would you expect this to do? let swc = frame.contentWindow.navigator.serviceWorker; frame.remove(); console.log(swc.controller); |
| 19:15 | <wanderview> | JakeA: throw or just return undefined for controller? |
| 19:17 | <JakeA> | wanderview: let's go for undefined |
| 19:17 | <wanderview> | sounds good |
| 19:17 | <wanderview> | thanks |
| 19:18 | <wanderview> | JakeA: I'm adding a WPT test for this corner case |
| 19:23 | <JakeA> | wanderview: Cheers! |
| 19:23 | <JakeA> | Good catch |
| 19:24 | <wanderview> | JakeA: or not... I'm not sure the case I'm trying to test is actually triggered by frame.remove()... |
| 19:26 | <wanderview> | oh, it is... just bugs :-\ |
| 20:26 | <bkardell> | ugh, scratch my misread about disabled elements are inert above :( |
| 20:34 | <smaug____> | is there any tool to go through all the known specs to check whether they refer to some terminology defined in HTML (or other) spec? |
| 20:52 | <annevk> | bkardell: at the moment inert is just for dialog |
| 20:55 | <TabAtkins> | smaug____: No, there's no spiders yet that track cross-linking. |
| 20:59 | <TabAtkins> | I've been thinking of writing a spider anyway (and switching Bikeshed to it, rather than relying on Shepherd), and this might be a good intro. |
| 20:59 | <TabAtkins> | Oooooh, I was wanting a learner project for Rust smaller than "rewrite Bikeshed", and I bet this would work great. |
| 21:28 | <smaug____> | some kind of cross-linking tracker would be really nice for cases link in-document handling, where introducing shadow DOM changes lots of things |
| 21:29 | <smaug____> | and if we had cross-linking tracker, perhaps then HTML spec could be split to smaller, more manageable pieces. maybe. not sure it is a good idea. maybe it is. |