freenode :: #whatwg

18 May 2017
05:06MikeSmithDomenic: https://stackoverflow.com/questions/44038877/using-fetch-with-es2015-modules-in-canary
06:22hsivonenannevk: http://unicode.org/pipermail/unicode/2017-May/005457.html
06:24hsivonennox: 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:27annevkhsivonen: ffs
06:29annevkhsivonen: we can still not follow it of course as it is rather misguided
06:30hsivonenannevk: 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:30annevkhsivonen: problem is that browsers use ICU sometimes
06:31hsivonenannevk: major ones don't for UTF-8
06:31hsivonenannevk: I regret that I momentarily forgot that when I started the thread
06:32hsivonenannevk: 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:32hsivonens/forget/forgot/
06:32annevkhsivonen: 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:33hsivonenyeah. the change on the Unicode side is really uncool
06:33hsivonenI guess I'm annoyed enough to go test even more programming language standard libraries
06:33annevkhsivonen: I think we should maybe try something to get them to revert the decision
06:34hsivonenyes
06:34annevkI saw Martin chime in with Ruby results
06:35hsivonenwell, so far no one has chimed in with any non-ICU results agreeing with the proposal
06:35annevkhsivonen: XML 5th edition
06:36hsivonenGecko, 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:57annevkhsivonen: 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:57annevkhsivonen: he also mentioned it's a guideline, not requirement, and that it would be another option to use, not the only option
06:58annevkhsivonen: most of that seems like good news
07:06hsivonenannevk: 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:06hsivonenbecause it should be ICU and not everyone except ICU who deals with questions "why don't you follow the best practice?"
07:09annevkyeah
07:09hsivonenalso: test suites
07:11hsivonenformulating 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:05tobiezcorpan: latest LegacyWindowAliases LGTM. There's a few nits, though. Would you prefer I fix them directly or add comments?
12:06tobiezcorpan: If it's the former, I don't think you've enabled access to the branch you're working from.
12:10MikeSmithannevk: 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:16MikeSmithannevk: I guess this would be the requirement at https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inhead:current-node-5
12:16MikeSmith> If the current node is not a template element, then this is a parse error.
12:18MikeSmithhmm or maybe its instead just that case the the Nu HTML parser is not conforming to the spec on the previous step
12:18MikeSmithhttps://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inhead:generate-all-implied-end-tags-thoroughly
12:22zcorpantobie: now checked the checkbox. (I thought it was enabled by default before?)
12:23tobiezcorpan: 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:23tobiezcorpan: might have to do with owner repo vs. org repo.
12:47annevkIf only I could reproduce it reliably
12:48annevkI want GitHub to fix it since that checkbox ends up unchecked rather often
12:49annevkAlso sometimes after being explicitly checked
12:51annevkMikeSmith: ah, so my instinct was correct?
12:51annevkMikeSmith: I should have actually read the spec
12:52MikeSmithhah
12:52MikeSmithyup
12:52MikeSmithyeah it is clear to me now no spec change is needed for this
12:52MikeSmithinstead the Nu parser just has a bug in that it doesnt actually implement generate all implied end tags thoroughly
12:53MikeSmithhttps://html.spec.whatwg.org/#generate-all-implied-end-tags-thoroughly
12:53MikeSmithwhich is only used when hitting a </template> end tag
12:54MikeSmiththere the Nu parser is instead incorrectly just doing generate implied end tags
12:54MikeSmithhttps://html.spec.whatwg.org/#generate-implied-end-tags
12:54annevkMikeSmith: I suspect that&#39;s because <template> was implemented by someone else, with the motivation of making the browser parse it
12:54MikeSmithyeah probably so
12:55MikeSmithwill raise a bmo bug for it
12:55MikeSmithbut will fix in the checker sources first
12:55MikeSmithand will close out the HTML spec PR with a link to the parser PR
14:52MikeSmithhsivonen: I guess theres still not yet any git version of https://hg.mozilla.org/projects/htmlparser/
15:31jgrahamMikeSmith: YOu could use cinnabar, depending on what you need
15:31jgrahamhttps://github.com/glandium/git-cinnabar
16:47domfarolinoA commit from over a year ago in whatwg/console has the message &quot;Tweaks for the move to WHATWG&quot;...just curious, anyone know where it was before? Was it a w3c spec or something?
17:17annevkdomfarolino: private effort afaik
17:25domfarolinogotcha
20:02tobieannevk: you were also complaining about this, right? https://github.com/heycam/webidl/pull/323#issuecomment-302521924
21:42SimonSapinDomenic: re https://github.com/whatwg/html/issues/2694 , is there mentoring for new contributors writing WPT tests? Im considering opening a &quot;good first bug&quot; in servos tracker for this
21:43DomenicSimonSapin: I&#39;m not sure about anything formal, but if the person says it&#39;s their first contribution hopefully reviewers will be nice.
21:44gsneddersSimonSapin: we had some stuff before
21:44gsneddersSimonSapin: but then nobody ever did anything
21:44gsneddersSimonSapin: so it kinda died
21:45SimonSapinok
21:45SimonSapinI suppose you need mentors spending time, to make this effective
21:46gsneddersin general I&#39;m happy to help, but I&#39;m a bit all over the place, especially when it comes to when I&#39;m around for long
21:46gsnedderswhich means it&#39;s hard to rely on me
23:42MikeSmithhsivonen: 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:42MikeSmith./htmlparser/src/nu/validator/htmlparser/impl/ElementName.java:30: error: cannot find symbol
23:42MikeSmithimport nu.validator.htmlparser.annotation.Unsigned;
23:44MikeSmithhsivonen: 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
19 May 2017
No messages
   
Last message: 6 days and 15 hours ago