| 05:42 | <annevk> | zcorpan: on the fence |
| 07:37 | <annevk> | zcorpan: I'd go with "Editorial" given the descriptions in TEAM |
| 07:38 | <zcorpan> | ok |
| 07:53 | <annevk> | MikeSmith: I guess you have no preference on what fix to use for Wattsi? |
| 07:53 | <annevk> | MikeSmith: if not I think we should just land the one I wrote so the markup errors are resolved |
| 08:07 | <alwu> | zcorpan : hi, I would like to ask a question about webvtt's web platform tests, do you have a time? |
| 08:09 | <zcorpan> | alwu: sure |
| 08:11 | <alwu> | zcorpan : thanks! the cue.line's value should be auto by default. In this test [1], whether we need to change all -1/-2 into "auto"? |
| 08:11 | <alwu> | [1] https://github.com/w3c/web-platform-tests/tree/master/webvtt/webvtt-api-for-browsers/vttcue-interface |
| 08:12 | <alwu> | I also confuse about why we wrote '-2' in that test (I know '-1' was the old default value, but '-2'...?) |
| 08:13 | <zcorpan> | yes the default should be "auto" |
| 08:14 | <zcorpan> | alwu: if you have two tracks showing at the same time |
| 08:15 | <zcorpan> | alwu: http://w3c.github.io/webvtt/#cue-computed-line step 6 onwards |
| 08:16 | <alwu> | zcorpan : yes, but the return value of the computeLine is not equal to cue.line, right? |
| 08:16 | <zcorpan> | alwu: no, but it was when the test was written |
| 08:16 | <zcorpan> | i think |
| 08:17 | <alwu> | I thought that the return value of the computeLine is used for the internal, only be used for sec.6 'Processing model' |
| 08:18 | <zcorpan> | well it doesn't matter so much what the spec used to say, right? :-) |
| 08:20 | <alwu> | because if we set line > 100, the computeLine would only return 100 |
| 08:20 | <Ms2ger> | annevk, doh |
| 08:20 | <Ms2ger> | Someone hardcoded that Firefox 52 == nightly |
| 08:20 | <alwu> | that means we would have a conflict |
| 08:20 | <annevk> | Ms2ger: hah |
| 08:21 | <Ms2ger> | jgraham, can you fix check_stability? |
| 08:21 | <alwu> | zcorpan : what I said is http://w3c.github.io/webvtt/#cue-computed-line step 1 |
| 08:23 | <alwu> | or we set line < 0, but the computeLine would return 100 |
| 08:23 | <zcorpan> | alwu: what is the conflict? |
| 08:25 | <alwu> | if the return value of the computeLine is the "cue.line", that that value is not equal to the original value we set |
| 08:29 | <alwu> | zcorpan ^ |
| 08:30 | <MikeSmith> | about the wattsi change, I like the fix you committed to the branch better than .RemoveChild one |
| 08:31 | <annevk> | MikeSmith: ok, let's roll with it |
| 08:31 | <MikeSmith> | k |
| 08:31 | <MikeSmith> | merged |
| 08:32 | <MikeSmith> | annevk: thanks for fixing that so quick |
| 08:34 | <zcorpan> | alwu: right. i suppose that's a reason the spec changed to not have the computed line influence cue.line anymore |
| 08:35 | <zcorpan> | alwu: the current spec says "The line attribute, on getting, must return the WebVTT cue line " (not computed line) |
| 08:37 | <zcorpan> | https://github.com/whatwg/html/pull/2062 all green \o/ |
| 08:38 | <MikeSmith> | Ms2ger: is the hardoded Firefox 52 == nightly thing the reason why Travis for wpt is failing to download Firefox? |
| 08:38 | <Ms2ger> | MikeSmith, yes |
| 08:40 | <MikeSmith> | Ms2ger: OK yeah I see now |
| 08:40 | <MikeSmith> | https://github.com/w3c/web-platform-tests/blob/master/check_stability.py#L170 |
| 08:41 | <annevk> | zcorpan: I think I found a fix for the <span> thingy |
| 08:41 | <annevk> | zcorpan: gonna test |
| 08:41 | <zcorpan> | cool |
| 08:45 | <alwu> | zcorpan : ok thanks! since the computedLine doesn't affect the cue.lines, I'll modify that test :) |
| 08:46 | <zcorpan> | alwu: 👍 |
| 08:50 | <annevk> | zcorpan: I get 40 errors when I do that, gonna fix those |
| 09:27 | <jgraham> | Ms2ger: hmm? |
| 09:27 | <Ms2ger> | jgraham, https://github.com/w3c/web-platform-tests/pull/4249 |
| 09:30 | <jgraham> | Ms2ger: OK, merged, but I think we need a better solution for the long term |
| 09:30 | <Ms2ger> | Agreed |
| 09:36 | <jgraham> | re.search("(firefox-\d+\.[^\.]+\.en-US\.linux-i686\.tar\.bz2)", requests.get("https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/").text).group(0) |
| 09:36 | <jgraham> | I suppose |
| 09:36 | <jgraham> | Not necessarily as a one-lines |
| 09:37 | <jgraham> | *one-liner |
| 09:37 | <jgraham> | Anyway, I should think about going into the office |
| 11:36 | <hsivonen> | zcorpan: Are there browsers that are passing https://github.com/w3c/web-platform-tests/blame/56ea52b8668ceee63ec196c59dd11ad7797e4f0d/html/infrastructure/urls/resolving-urls/query-encoding/resources/resolve-url.js#L17 |
| 11:36 | <hsivonen> | which seems to call for treating unmappable characters in URLs as percent-encoded question marks |
| 11:36 | <hsivonen> | surely that's no longer correct per spec |
| 11:37 | <zcorpan> | hsivonen: i think that was the behavior of IE? |
| 11:37 | <hsivonen> | zcorpan: possibly |
| 11:37 | <zcorpan> | i need to leave now, sorry |
| 11:37 | <hsivonen> | ok. I'll just adjust the test |
| 11:37 | <zcorpan> | sounds good |
| 11:40 | <annevk> | JakeA: the script mentioned in https://github.com/whatwg/fullscreen/commit/f9df3ea73f1f32490699e0a925d7e0822c2084a1 might be useful to figure out if you regressed any links or IDs |
| 11:41 | <annevk> | JakeA: also, copying the text of the output HTML (of original and new) and comparing that with git diff --word-diff -w will help you spot other mistakes |
| 11:41 | <JakeA> | annevk: ta. I've already done the latter |
| 11:41 | <JakeA> | Although I'm just using opendiff |
| 11:42 | <annevk> | JakeA: I think doing word diff and ID/URL diff is probably sufficient to prove nothing was harmed |
| 11:43 | <annevk> | JakeA: although <dfn> and for= review would still be good to see that is all in order too I suppose |
| 11:44 | <annevk> | That went rather wrong with the conversion of Fetch |
| 11:49 | <Ms2ger> | Hrm |
| 11:49 | <Ms2ger> | iframe = document.createElement("iframe"); |
| 11:49 | <Ms2ger> | document.body.appendChild(iframe); |
| 11:49 | <Ms2ger> | doc = iframe.contentDocument; |
| 11:49 | <Ms2ger> | assert_equals(doc.readyState, "complete", "The readyState attribute should be 'complete'."); |
| 11:49 | <Ms2ger> | Where does the spec back that up? |
| 12:45 | <annevk> | MikeSmith: tried a whole bunch of parens already to get that to compile |
| 12:45 | <annevk> | Although maybe I should try one last time... |
| 12:46 | <JakeA> | annevk: yeah I caught a load of stuff that was pointing at the fetch concept rather than the fetch event |
| 12:46 | <JakeA> | annevk: but hardly surprising as I changed almost every <a href> to just <a> as a starting point |
| 12:46 | <annevk> | JakeA: ah, that does make it harder 😊 |
| 12:47 | <JakeA> | I was determined to eliminate as many of those anchor things as I could |
| 12:57 | <MikeSmith> | annevk: pretty sure those missing parens at least are a syntax error that has to be fixed first |
| 12:57 | <annevk> | MikeSmith: yeah, you're right |
| 12:58 | <MikeSmith> | yeah I did not otherwise try to actually understand the change |
| 12:58 | <MikeSmith> | I will thugh |
| 13:02 | <annevk> | MikeSmith: found it |
| 13:02 | <annevk> | MikeSmith: Element.Attributes is not always assigned |
| 13:03 | <annevk> | MikeSmith: works perfectly |
| 13:03 | <MikeSmith> | ah ok |
| 13:03 | <MikeSmith> | that caused it to fail to compile? |
| 13:03 | <annevk> | MikeSmith: that was the runtime failure |
| 13:04 | <MikeSmith> | ah runtime failure |
| 13:04 | <annevk> | MikeSmith: so I change (Element.Attributes.Count = 0) to (not Assigned(Element.Attributes)) |
| 13:04 | <annevk> | MikeSmith: and boom, reports issues perfectly |
| 13:05 | <MikeSmith> | nice |
| 13:05 | <MikeSmith> | reminds me, fpc compiler error messages are nearly useless |
| 13:06 | <MikeSmith> | as far as identifying what the actual problem is |
| 13:07 | <MikeSmith> | ah, loking back at the bug now |
| 13:07 | <MikeSmith> | your comment there |
| 13:08 | <MikeSmith> | I’m not getting timely github notifications the last few days |
| 13:09 | <MikeSmith> | my mail server got hammered the other day after I pushed a change to the production w3c html checker that caused it to fatally fail for every single document it was chekcing |
| 13:10 | <MikeSmith> | and I have it configured to send me a notification with a stack trace when that happens |
| 13:10 | <MikeSmith> | because it should only happen very rarely |
| 13:10 | <MikeSmith> | but this time after I pushed it I didn’t notice for probably an hour or so, did not look at my mail |
| 13:11 | <MikeSmith> | but during that time it tried to send me at least 50,000 e-mail messages I think |
| 13:11 | <MikeSmith> | I got it fixed but I think it put my mail server in some kind of state it has not recovered from yet |
| 13:12 | <MikeSmith> | message coming in out of order or hours or even days late |
| 18:10 | <annevk> | Blink implements DOMActivate?! |
| 18:11 | <annevk> | sigh |
| 22:22 | nox | just did a PR to implement document.write in Servo. |
| 22:22 | <nox> | Not perfect yet but it's almost there AFAIK. |
| 22:23 | <nox> | Seems like foregoing the concept of insertion point altogether was the way to go. |