| 05:06 | <MikeSmith> | Domenic: https://stackoverflow.com/questions/44038877/using-fetch-with-es2015-modules-in-canary |
| 06:22 | <hsivonen> | annevk: http://unicode.org/pipermail/unicode/2017-May/005457.html |
| 06:24 | <hsivonen> | nox: not sure about the normal tone for the unicode list. I regret the tone I started with. I was and continue to be extremely irritated at changing a long-standing and widely-implemented spec provision with a proposal that argues from "feels right" what should and ICU behavior only on what is |
| 06:27 | <annevk> | hsivonen: ffs |
| 06:29 | <annevk> | hsivonen: we can still not follow it of course as it is rather misguided |
| 06:30 | <hsivonen> | annevk: I would hope that the Encoding Standard continue to align with what browsers do instead of changing just because Unicode thought ICU felt right |
| 06:30 | <annevk> | hsivonen: problem is that browsers use ICU sometimes |
| 06:31 | <hsivonen> | annevk: major ones don't for UTF-8 |
| 06:31 | <hsivonen> | annevk: I regret that I momentarily forgot that when I started the thread |
| 06:32 | <hsivonen> | annevk: I should have made an argument from implementation consensus to begin with, but I momentarily forget that Chrome and Safari don't contribute to the deployment of ICU's UTF-8 decoder |
| 06:32 | <hsivonen> | s/forget/forgot/ |
| 06:32 | <annevk> | hsivonen: okay, but this will continue to come up and we have to be vigilant about not changing existing handling and keep it the same in new places such as WebAssembly |
| 06:33 | <hsivonen> | yeah. the change on the Unicode side is really uncool |
| 06:33 | <hsivonen> | I guess I'm annoyed enough to go test even more programming language standard libraries |
| 06:33 | <annevk> | hsivonen: I think we should maybe try something to get them to revert the decision |
| 06:34 | <hsivonen> | yes |
| 06:34 | <annevk> | I saw Martin chime in with Ruby results |
| 06:35 | <hsivonen> | well, so far no one has chimed in with any non-ICU results agreeing with the proposal |
| 06:35 | <annevk> | hsivonen: XML 5th edition |
| 06:36 | <hsivonen> | Gecko, Blink, Edge, OpenJDK, Ruby and Python 3 all side with the current spec (for the cases tested). Python 2 is obviously incompliant in any case. |
| 06:57 | <annevk> | hsivonen: so I pinged Mark Davis and he told me that there's about 9 months to appeal this as it would be for Unicode 11 |
| 06:57 | <annevk> | hsivonen: he also mentioned it's a guideline, not requirement, and that it would be another option to use, not the only option |
| 06:58 | <annevk> | hsivonen: most of that seems like good news |
| 07:06 | <hsivonen> | annevk: I'm aware that it's a guideline, but it being a mere guideline is a reason not to change it instead of a reason to change it |
| 07:06 | <hsivonen> | because it should be ICU and not everyone except ICU who deals with questions "why don't you follow the best practice?" |
| 07:09 | <annevk> | yeah |
| 07:09 | <hsivonen> | also: test suites |
| 07:11 | <hsivonen> | formulating a "best practice" and then saying "you can just not follow it" undermines the credibility of the best practice. It makes no sense to do that. |
| 12:05 | <tobie> | zcorpan: latest LegacyWindowAliases LGTM. There's a few nits, though. Would you prefer I fix them directly or add comments? |
| 12:06 | <tobie> | zcorpan: If it's the former, I don't think you've enabled access to the branch you're working from. |
| 12:10 | <MikeSmith> | annevk: so about https://github.com/whatwg/html/pull/2682, the “End tag template seen, but there were open elements” thing, maybe we should instead make the spec not require a parse error for that case |
| 12:16 | <MikeSmith> | annevk: I guess this would be the requirement at https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inhead:current-node-5 |
| 12:16 | <MikeSmith> | > If the current node is not a template element, then this is a parse error. |
| 12:18 | <MikeSmith> | hmm or maybe it’s instead just that case the the Nu HTML parser is not conforming to the spec on the previous step |
| 12:18 | <MikeSmith> | https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inhead:generate-all-implied-end-tags-thoroughly |
| 12:22 | <zcorpan> | tobie: now checked the checkbox. (I thought it was enabled by default before?) |
| 12:23 | <tobie> | zcorpan: it's weird. Same thing happened to me with the toJSON stuff I accidentally blocked Domenic from editing. He had to send me a patch instead. |
| 12:23 | <tobie> | zcorpan: might have to do with owner repo vs. org repo. |
| 12:47 | <annevk> | If only I could reproduce it reliably |
| 12:48 | <annevk> | I want GitHub to fix it since that checkbox ends up unchecked rather often |
| 12:49 | <annevk> | Also sometimes after being explicitly checked |
| 12:51 | <annevk> | MikeSmith: ah, so my instinct was correct? |
| 12:51 | <annevk> | MikeSmith: I should have actually read the spec |
| 12:52 | <MikeSmith> | hah |
| 12:52 | <MikeSmith> | yup |
| 12:52 | <MikeSmith> | yeah it is clear to me now no spec change is needed for this |
| 12:52 | <MikeSmith> | instead the Nu parser just has a bug in that it doesn’t actually implement “generate all implied end tags thoroughly” |
| 12:53 | <MikeSmith> | https://html.spec.whatwg.org/#generate-all-implied-end-tags-thoroughly |
| 12:53 | <MikeSmith> | which is only used when hitting a </template> end tag |
| 12:54 | <MikeSmith> | there the Nu parser is instead incorrectly just doing “generate implied end tags” |
| 12:54 | <MikeSmith> | https://html.spec.whatwg.org/#generate-implied-end-tags |
| 12:54 | <annevk> | MikeSmith: I suspect that's because <template> was implemented by someone else, with the motivation of making the browser parse it |
| 12:54 | <MikeSmith> | yeah probably so |
| 12:55 | <MikeSmith> | will raise a bmo bug for it |
| 12:55 | <MikeSmith> | but will fix in the checker sources first |
| 12:55 | <MikeSmith> | and will close out the HTML spec PR with a link to the parser PR |
| 14:52 | <MikeSmith> | hsivonen: I guess there’s still not yet any git version of https://hg.mozilla.org/projects/htmlparser/ |
| 15:31 | <jgraham> | MikeSmith: YOu could use cinnabar, depending on what you need |
| 15:31 | <jgraham> | https://github.com/glandium/git-cinnabar |
| 16:47 | <domfarolino> | A commit from over a year ago in whatwg/console has the message "Tweaks for the move to WHATWG"...just curious, anyone know where it was before? Was it a w3c spec or something? |
| 17:17 | <annevk> | domfarolino: private effort afaik |
| 17:25 | <domfarolino> | gotcha |
| 20:02 | <tobie> | annevk: you were also complaining about this, right? https://github.com/heycam/webidl/pull/323#issuecomment-302521924 |
| 21:42 | <SimonSapin> | Domenic: re https://github.com/whatwg/html/issues/2694 , is there mentoring for new contributors writing WPT tests? I’m considering opening a "good first bug" in servo’s tracker for this |
| 21:43 | <Domenic> | SimonSapin: I'm not sure about anything formal, but if the person says it's their first contribution hopefully reviewers will be nice. |
| 21:44 | <gsnedders> | SimonSapin: we had some stuff before |
| 21:44 | <gsnedders> | SimonSapin: but then nobody ever did anything |
| 21:44 | <gsnedders> | SimonSapin: so it kinda died |
| 21:45 | <SimonSapin> | ok |
| 21:45 | <SimonSapin> | I suppose you need mentors spending time, to make this effective |
| 21:46 | <gsnedders> | in general I'm happy to help, but I'm a bit all over the place, especially when it comes to when I'm around for long |
| 21:46 | <gsnedders> | which means it's hard to rely on me |
| 23:42 | <MikeSmith> | hsivonen: I merged latest changes from https://hg.mozilla.org/projects/htmlparser/ to https://github.com/validator/htmlparser/tree/master but now it is failing to build to this: |
| 23:42 | <MikeSmith> | ./htmlparser/src/nu/validator/htmlparser/impl/ElementName.java:30: error: cannot find symbol |
| 23:42 | <MikeSmith> | import nu.validator.htmlparser.annotation.Unsigned; |
| 23:44 | <MikeSmith> | hsivonen: and when I look through the upstream sources in https://hg.mozilla.org/projects/htmlparser/file/tip/src/nu/validator/htmlparser/annotation there is no Unsigned class there nor in https://hg.mozilla.org/mozilla-central/file/tip/parser/html/javasrc either |