| 08:23 | <annevk> | rn... am now |
| 08:40 | <tobie> | JakeA: would love your input on whether or not to wait for cancellable promises for returning a promise from the start method of sensors. |
| 08:45 | <tobie> | or Domenic |
| 08:45 | <JakeA> | tobie: I'm worried about ending up with legacy APIs that use rejection to mean cancellation |
| 08:47 | <tobie> | JakeA: right, so I have a start/stop pair. start returned a promise that stop could abort before the sensor was fully activated. |
| 08:48 | <tobie> | JakeA: so yeah, rejected the promise. |
| 08:49 | <tobie> | JakeA: given there are statechange events, the promise isn't strictly necessary (it's sugar really), it *can* wait until a v2 of the spec. |
| 08:50 | <tobie> | JakeA: should it? |
| 08:50 | <tobie> | JakeA: seems your answer is "yes" and that's what I've gone with so far, but I want to make sure, so I have a good answer for all the people that are going to complain for the lack of promise in that API. |
| 08:50 | <tobie> | :) |
| 08:52 | <JakeA> | tobie: yeah, I think so, but will let Domenic have the final word |
| 08:52 | <tobie> | JakeA: for reference: https://w3c.github.io/sensors/#sensorstart |
| 08:52 | <JakeA> | The alternative is to add the promise, but when it's cancelled just never resolve the promise. That lets you add cancellation later. But it's a bit eww |
| 08:53 | <tobie> | JakeA: yeah--that sounds like even more explaining to do. |
| 08:56 | <tobie> | JakeA: Thanks for the help. |
| 09:15 | <zcorpan> | how do i run the html5lib tests with html5lib-python? jgraham gsnedders |
| 09:15 | <zcorpan> | i want to write new tests for <menuitem> parsing |
| 09:19 | <jgraham> | zcorpan: They are in wpt. There is a script to generate new tests from html5lib source files in html/tools iirc |
| 09:20 | <Ms2ger> | Presumably that's not the optimal way to test html5lib-python though |
| 09:23 | <zcorpan> | jgraham: yes, i found that but i figured if i want to write new tests it makes more sense to run the tests with html5lib than to run them in a browser? |
| 09:24 | <zcorpan> | jgraham: it's not clear to me what the typical procedure is for writing a new test, and it's not clear to me how to run tests with html5lib-python from reading the READMEs |
| 09:24 | <zcorpan> | (i have no idea what tox is) |
| 09:30 | <jgraham> | Oh I read "with" as "without" |
| 09:30 | <jgraham> | Makes a difference |
| 09:30 | <zcorpan> | heh |
| 09:31 | <jgraham> | zcorpan: tests/README sort of tells you |
| 09:32 | <jgraham> | Install nose |
| 09:32 | <jgraham> | and type |
| 09:32 | <jgraham> | nose |
| 09:32 | <jgraham> | or |
| 09:32 | <jgraham> | node path/to/test.py |
| 09:33 | <jgraham> | s/nose/nosetests/ |
| 09:33 | <jgraham> | and also not node |
| 09:33 | <zcorpan> | pip install nosetests ? |
| 09:33 | <jgraham> | such an unfortunate typo |
| 09:33 | <jgraham> | Yeah |
| 09:34 | <jgraham> | Well I think pip install nose |
| 09:34 | <jgraham> | The package is nose but the command is nosetests |
| 09:35 | <jgraham> | (Seems like pytest also works if that's less confusing) |
| 09:35 | <jgraham> | (but maybe doesn't respect the skip annotations or something) |
| 09:37 | <zcorpan> | Cleaning up... |
| 09:37 | <zcorpan> | Exception: |
| 09:37 | <zcorpan> | Traceback (most recent call last): |
| 09:37 | <zcorpan> | File "/Library/Python/2.7/site-packages/pip-1.5.6-py2.7.egg/pip/basecommand.py", line 122, in main |
| 09:37 | <zcorpan> | status = self.run(options, args) |
| 09:39 | <zcorpan> | installing pytest worked |
| 09:43 | <zcorpan> | py.test runs now. lots of tests and quite a bit of "F"s :-) |
| 09:44 | <zcorpan> | 676 failed, 25007 passed, 118 skipped, 2 pytest-warnings, 1 error in 168.03 seconds |
| 09:48 | <zcorpan> | though py.test tree_construction.py runs 0 tests. renaming the file to test_tree_construction.py gives: WC1 /Users/zcorpan/VCS/git/html5lib/html5lib-python/html5lib/tests/test_tree_construction.py cannot collect test class 'TestData' because it has a __init__ constructor |
| 09:51 | <zcorpan> | ok installed nose with easy_install instead |
| 09:54 | <zcorpan> | how do i run only the treebuilder tests? |
| 10:06 | <zcorpan> | nosetests test_treewalkers.py |
| 10:07 | <zcorpan> | jgraham: can i restrict it more to only run a specific dat file? haven't figured it out by myself yet from nosetests --help |
| 10:09 | <jgraham> | zcorpan: test_treewalkers isn't what you want, it's test_parser |
| 10:10 | <zcorpan> | jgraham: test_parser2.py ? |
| 10:11 | <jgraham> | I don't actually know what the reason for test_parser and test_parser2 is |
| 10:11 | <zcorpan> | i don't see any test_parser |
| 10:11 | <jgraham> | Looks like there isn't an easy way to run a specific .dat file, but you could hack get_data_files in support.py |
| 10:12 | <jgraham> | Oh? |
| 10:12 | <jgraham> | Looking at test_parser2 it clearly isn't what you want |
| 10:13 | <zcorpan> | https://github.com/html5lib/html5lib-python/tree/master/html5lib/tests no test_parser.py here |
| 10:13 | <jgraham> | Oh wait, it looks like I had an old checkout and gsnedders changed something |
| 10:14 | <jgraham> | I guess these days you are supposed to use py.test and tree_construction.py |
| 10:16 | <zcorpan> | https://github.com/html5lib/html5lib-python/commit/9337b003fa4465e91c1d9b3271064e34e26d876b ? |
| 10:17 | <zcorpan> | gsnedders: help? |
| 10:23 | <zcorpan> | py.test testdata/tree-construction/main-element.dat seems to work? |
| 10:29 | <jgraham> | Neat |
| 10:30 | <zcorpan> | ok now i'm happy (for now). might need help again with the wpt import later :-) |
| 10:30 | <zcorpan> | thx! |
| 10:39 | <zcorpan> | hsivonen: i get 502 for https://validator.nu/ and https://html5.validator.nu/ |
| 10:43 | <annevk> | zcorpan: I'm running into https://www.w3.org/Bugs/Public/show_bug.cgi?id=25552 and co with <slot> |
| 10:44 | <annevk> | zcorpan: <slot> needs to be as generic as <template> more or less |
| 10:44 | <zcorpan> | annevk: any opinions? i still think script and template should be allowed in as many places as possible, basically |
| 10:45 | <annevk> | zcorpan: I tend to agree, the parser already allows for it and implementations already deal, right? |
| 10:46 | <annevk> | zcorpan: I'll also need your help with <slot> since I don't really have a firm grasp on how all the details need to be filled in |
| 10:46 | <zcorpan> | annevk: right. iirc there's like one exception where the parser supports script but not template for some reason |
| 10:47 | <zcorpan> | annevk: i still need to fix the <template> content model bug |
| 10:47 | <zcorpan> | annevk: does <slot> parse into a different tree like <template> does? |
| 10:49 | <annevk> | zcorpan: no |
| 10:49 | <annevk> | zcorpan: that's the main difference |
| 10:50 | <zcorpan> | annevk: but you can do <slot><tr><td>x</slot> ? |
| 10:50 | <annevk> | zcorpan: ideally, yes |
| 10:51 | <zcorpan> | annevk: and what should validators complain about? for <template> the latest thinking is to basically not validate the subtree (but still report parse errors) |
| 10:52 | <annevk> | zcorpan: I should probably think through the parsing rules again though, to see if it actually makes sense to follow <template> |
| 10:52 | <annevk> | zcorpan: not sure, technically <slot> contents are fallback content, so you could validate with respect to the surrounding tree perhaps |
| 10:55 | <zcorpan> | hmmmm. ok. transparent content model maybe |
| 10:55 | <zcorpan> | MikeSmith: ^ |
| 10:56 | <zcorpan> | MikeSmith: hsivonen: btw, i remember there being an online tool to dump only parse errors with the v.nu html parser. Is it still up somewhere? |
| 11:25 | <annevk> | Defining a new element is hard |
| 11:25 | <annevk> | Hixie_ deserves much respect for figuring out over a 100 |
| 11:44 | <annevk> | hayato: are you around? |
| 11:44 | <annevk> | hayato: I can't find the issue where we discuss the default rendering of <slot> |
| 12:04 | <annevk> | zcorpan: so given that attachShadow() comes with restrictions you could come up with restrictions on <slot> too that match that, but it'll get complicated quick |
| 12:21 | <nox> | zcorpan: What's the <template> content model bug? |
| 12:38 | <hsivonen> | zcorpan: thanks. the watchdog has automatically brought the service back up, but I need a faster watchdog |
| 12:39 | <hsivonen> | zcorpan: I don't recall an error dumper, but there's https://parsetree.validator.nu/ |
| 12:46 | <nox> | What should { elem.classList = "foo bar foo"; elem.classList.replace("foo", "qux"); return elem.classList.value; } return? |
| 12:49 | <annevk> | nox: suspect "quz bar" |
| 12:49 | <nox> | annevk: Doesn't seem specified to me. |
| 12:49 | <nox> | "Replace token in tokens with newToken." |
| 12:50 | <annevk> | nox: why isn't it specified? |
| 12:51 | <nox> | annevk: I mean in the spec. |
| 12:51 | <annevk> | nox: I think it is |
| 12:52 | <nox> | annevk: When removing duplicate tokens in `remove`, we specify 'For each token in tokens, remove token from tokens.', |
| 12:52 | <nox> | when replacing in `replace`, we specify 'Replace token in tokens with newToken.', |
| 12:52 | <nox> | to me it sounds like it should become "qux bar qux". |
| 12:52 | <annevk> | nox: there are no duplicate tokens though |
| 12:53 | <nox> | What do you mean? |
| 12:53 | <annevk> | nox: why would there be duplicate tokens after they are parsed? |
| 12:54 | <annevk> | Maybe remove should not account for duplicates |
| 12:55 | <nox> | annevk: Oh I see. |
| 12:55 | <nox> | "If the collected string is not in tokens, append the collected string to tokens." in the ordered set parser. |
| 13:01 | <zcorpan> | annevk: https://github.com/whatwg/html/issues/541 |
| 13:03 | <annevk> | zcorpan: that seems reasonable for <template> |
| 13:03 | <annevk> | zcorpan: the weird thing with <slot> that makes it trickier too is that it's actually non-conforming for it to appear in a normal document (except perhaps inside <template> contents) |
| 13:03 | <annevk> | zcorpan: it's only useful in a shadow tree |
| 13:04 | <annevk> | zcorpan: so unless the validator is integrated in the browser, you cannot meaningfully check its conformance |
| 13:04 | <zcorpan> | annevk: integrated in the browser is something i hope will happen |
| 13:06 | <zcorpan> | annevk: the first step of attachShadow could be made laxer if <slot> is parsed more like <template> though? |
| 13:07 | <annevk> | zcorpan: they're not tightly related |
| 13:08 | <zcorpan> | hsivonen: thanks! i don't know if i caused the 502 but it started right after i tried to guess the URL to parsetree (with some unknown path for validator.nu) |
| 13:08 | <annevk> | zcorpan: it's mostly about elements having complex requirements, perhaps builtin shadow tree, vs guaranteed to be simple without builtin shadow tree |
| 13:10 | <zcorpan> | annevk: ok. i think i need to take a day to read all the shadow specs to understand what's going on here :-) |
| 13:11 | <annevk> | That'd help |
| 13:16 | <zcorpan> | if we make <slot><tr> work i think we should also make <foo-bar><tr> work, otherwise people will use <slot> all over the place to take advantage of the better parsing |
| 13:21 | <annevk> | zcorpan: add a longer form of that argument to https://github.com/w3c/webcomponents/issues/59? |
| 13:30 | <SimonSapin> | jgraham: cProfile says that wpt/lint spends 32% of its time in html5lib’s detectEncoding. Would it be wrong for the lint to assume everything is UTF-8 ? |
| 13:31 | <jgraham> | SimonSapin: Yes |
| 13:31 | <jgraham> | some things quite intentionally aren't |
| 13:32 | <jgraham> | Although you could perhaps try making it assunme utf8 and fall back to not-utf8 if parsing fails |
| 13:32 | <jgraham> | For some definiton of "fails" |
| 13:33 | <SimonSapin> | ok, that sounds uncertain enough that it’s not worth it. thanks |
| 14:13 | <annevk> | Domenic: https://github.com/w3c/webcomponents/issues/59#issuecomment-199831277 |
| 14:13 | <Domenic> | annevk: yeah saw that. anything in particular for me to comment on? |
| 14:13 | <Domenic> | oh i guess making custom elements parse like slot |
| 14:14 | <annevk> | Domenic: exactly |
| 14:15 | <Domenic> | Let me check with the googlers... |
| 14:16 | <annevk> | Domenic: if logical properties exist now, I think we can remove a couple of those LTR-specific things |
| 14:18 | <nox> | https://github.com/heycam/webidl/pull/94 Is that blocked by something? |
| 14:19 | <annevk> | nox: heycam|away might know |
| 14:20 | <Domenic> | annevk: unclear to what extent they fully exist... although I think Firefox has been shipping a versino of them (behind a flag??) for a while |
| 14:22 | <annevk> | Domenic: Gecko has had prefixed versions for ages |
| 14:22 | <Domenic> | sure, so has chrome |
| 14:22 | <Domenic> | but not ones that match that spec |
| 14:49 | <MikeSmith> | zcorpan: reading scrollback about the validator thing. Is https://parsetree.validator.nu/ the thing you had been thinking of? |
| 14:50 | <zcorpan> | MikeSmith: yes |
| 14:50 | <MikeSmith> | ok |
| 14:50 | <zcorpan> | thx |
| 14:51 | <MikeSmith> | also yeah it would be nice to get the <template> document-conformance stuff in the spec updated |
| 14:52 | <MikeSmith> | happy to make the validator changes to conform to whatever we end up with in the spec |
| 14:53 | <zcorpan> | hmm wonder if https://parsetree.validator.nu/?parser=html5&content=<%21DOCTYPE+html><option>&submit=Print+Tree is per spec and if it's intentional |
| 14:53 | <zcorpan> | i mean that it's a parse error |
| 14:56 | <zcorpan> | i wish <dt>s in the spec had ids |
| 14:56 | <zcorpan> | "If there is a node in the stack of open elements that is not either a dd element, a dt element, an li element, an optgroup element, an option element, a p element, an rb element, an rp element, an rt element, an rtc element, a tbody element, a td element, a tfoot element, a th element, a thead element, a tr element, the body element, or the html element, then this is a parse error." |
| 14:57 | <zcorpan> | so a bug in v.nu. and i also need to add menuitem to this list |
| 14:57 | <zcorpan> | maybe factor it out |
| 15:10 | <annevk> | So, I landed something on master without review |
| 15:10 | <annevk> | Domenic: what to do? |
| 15:10 | <zcorpan> | git diff --color-words ❤️ (when there's rewrap) |
| 15:12 | annevk | checks that he didn't leave the tree burning |
| 15:13 | <annevk> | ok, that's all good |
| 15:13 | <Domenic> | annevk: this seems like a case where you open an issue asking for review. In more drastic circumstances (like when I accidentally landed some script evaluation stuff) you could either push a revert commit, or you could un-protect master, force-push to a previous state, and re-protect it. |
| 15:13 | <annevk> | Will do and then I'm going to take a break for a bit 😃 |
| 15:14 | <annevk> | Things started getting so repetitive I forgot the branch making step |
| 15:46 | <zcorpan_> | MikeSmith: hsivonen: where should i file bugs about v.nu html parser? https://bugzilla.validator.nu/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=HTML%20parser ? |
| 15:58 | <hsivonen> | zcorpan_: in the HTML: Parser component on bugzilla.mozilla.org |
| 15:59 | <zcorpan_> | hsivonen: also if it's only about parse error vs. no parse error? |
| 16:00 | <zcorpan_> | hsivonen: about.validator.nu says "Bugs should be reported to Validator.nu Bugzilla." btw |
| 16:01 | <zcorpan_> | i meant https://about.validator.nu/htmlparser/ points to the link i gave above |
| 16:55 | <annevk> | Domenic: the slow review wasn't meant as critique |
| 16:56 | <annevk> | Domenic: it's just that I don't have a good system for landing a set of incremental changes |
| 16:56 | <Domenic> | annevk: hmm ok |
| 16:56 | <annevk> | Domenic: e.g., I want to revive how we do "effective script origin", but I first want to land the outstanding PRs |
| 16:57 | <annevk> | Domenic: I guess I could create a new branch that also contains those commits, but then it becomes like a house of cards (and also I don't really know how to do that just yet) |
| 16:59 | <zcorpan_> | annevk: git checkout -b fix-1; /* PR for fix-1 */ git checkout -b fix-2; /* while on fix-1, so becomes on top of fix-1, then PR for fix-2 */ ... i think |
| 16:59 | <jyasskin> | Chrome's depot-tools have some good tools for managing dependent branches: https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools.html |
| 17:01 | <Domenic> | annevk: yeah you can just branch of a previous branch. But, I'll try to focus on the origin stuff after I work through the easy stuff. |
| 17:01 | <Ms2ger> | OTOH, depot is horrible in general :) |
| 17:02 | <annevk> | Domenic: can you branch from two branches? |
| 17:02 | <annevk> | Domenic: anyway, seems icky, but maybe at some point |
| 17:03 | <Domenic> | annevk: not quite. I would just create a linear history of all the changes in the order you think they should be applied. |
| 17:04 | <Domenic> | annevk: I broke https://github.com/whatwg/html/pull/920 by force-pushing my local checkout. Can you re-force-push your with the fixed title and merge? |
| 17:04 | <annevk> | Domenic: yeah, if I knew what I was doing upfront that'd be easy, but it's often on the go |
| 17:04 | <Ms2ger> | Domenic, that does mean you need to PR them sequentially, though |
| 17:04 | <annevk> | Domenic: will unbreak |
| 17:04 | <Domenic> | Ms2ger: I figure we'll be sure to make it work while landing, but just for getting work up that people can critique, seems to be OK. |
| 17:05 | <annevk> | done |
| 17:14 | <smaug____> | has http://krijnhoetmer.nl/irc-logs/ stopped working |
| 17:14 | <annevk> | smaug____: yeah |
| 17:28 | <Domenic> | Anyone want to review https://github.com/whatwg/html/pull/884 btw? |
| 17:29 | <annevk> | Domenic: that change looked fine to me, I thought the problem was finding implementers |
| 17:29 | <Domenic> | annevk: it seems like a small enough bug we should just fix the spec and then file bugs on implementations (after doing some testing) |
| 17:30 | <annevk> | Domenic: although looking at it again I think you should add the word "exception" after the class name |
| 17:30 | <annevk> | Domenic: maybe assign it to junov? |
| 17:45 | <Domenic> | annevk: origins are not mutable right? |
| 17:47 | <Domenic> | annevk: ah i guess they are, that is how document.domain works |
| 17:47 | <Domenic> | annevk: would it be possible to make them immutable and then document.domain changes the origin to a value that is a copy but modified? |
| 17:48 | <annevk> | Domenic: my plan is to make a single field on origin mutable that document.domain can mutate |
| 17:48 | <Domenic> | annevk: hmm I guess per https://github.com/whatwg/html/issues/794 implementations don't do that |
| 17:49 | <annevk> | Domenic: the PRs just make sure we don't contradict implementations |
| 17:49 | <annevk> | Domenic: after that I'll merge effective script origin into origin |
| 17:52 | <annevk> | Domenic: is https://github.com/whatwg/html/pull/915 good now? |
| 17:52 | <Domenic> | annevk: no: "It's very weird how this (and set and "delete an existing named property") are dfn'ed. Can you fix them to be xrefs to the appropriate Web IDL concepts while you're fixing this up?" |
| 17:56 | <annevk> | Domenic: that comment is not in the PR? |
| 17:56 | <Domenic> | annevk: " domenic commented on an outdated diff an hour ago " last one |
| 17:56 | <annevk> | Domenic: it's also not immediately obvious to me what that means, guess I'll look tomorrow |
| 17:56 | <annevk> | Oh |
| 17:57 | <annevk> | Domenic: wouldn't that remove the links from the IDL fragment? |
| 17:59 | <Domenic> | annevk: hmmm I see. But for Window and Document we don't do that. |
| 18:00 | <Domenic> | annevk: hmm but we do for option and such |
| 18:00 | <Domenic> | annevk: I don't like this; these places aren't defining the term "set". But I guess we can keep it. |
| 18:00 | <annevk> | Domenic: sounds like a follow up issue to clean things up |
| 18:01 | <annevk> | Domenic: I can file one |
| 18:01 | <Domenic> | cool. I'll get back to merging your PRs |
| 18:13 | <Domenic> | annevk: you should be able to merge https://github.com/whatwg/html/pull/870 now |
| 19:12 | <annevk> | So close to a streak of 10, but my internet connection dropped |
| 19:12 | <annevk> | So now it's 12 commits today, with a streak of 9 |
| 19:12 | <annevk> | For w3c/html |
| 19:12 | <annevk> | Euh, whatwg/html, lol |
| 20:39 | <smaug____> | the latest css for w3c specs is super annoying. Takes ages to load, and when it finally loads, the spec layout changes radically. So, not worth to start reading anything before the css has been loaded. |
| 21:06 | <TabAtkins> | smaug____: Takes ages to load? Shouldn't be any slower than it ever has been. |
| 21:06 | <TabAtkins> | (That said, avoiding relying on the w3c server for styles is why Bikeshed writes the styles in manually for EDs.) |
| 21:15 | <smaug____> | TabAtkins: for some reason has been slow here lately |
| 21:15 | <smaug____> | (in Helsinki) |
| 21:16 | <TabAtkins> | Also if you're experiencing slow loads *consistently* that implies they're not being reasonably cached, which is dumb. |
| 21:22 | <TabAtkins> | Well, the cache header only allows it to be cached for 6 hours. |
| 23:21 | <heycam> | nox: looking now |