| 05:02 | <kalimann> | brothers. how would you make a list like this? http://snag.gy/U0c5P.jpg |
| 05:03 | <kalimann> | with year numbers as bulletins, and then two different lines of info for each year |
| 05:03 | <kalimann> | i tried some nested lists but cant make it work |
| 05:04 | <kalimann> | should i just break it into different <p> or is there a systemical way to do this? |
| 06:05 | <renlinx> | hi.. |
| 06:05 | <renlinx> | my github account is |
| 06:05 | <renlinx> | github.com/sideffect0 |
| 06:10 | <annevk> | caitp: heh |
| 07:23 | <nox> | annevk: Made a PR for the issue I mentioned yesterday. |
| 08:25 | <MikeSmith> | mkwst: about the HTML CSP PR, gimme a second to rebuild from it and look at the rendered output |
| 08:25 | <mkwst> | MikeSmith: No rush. :) |
| 08:25 | <mkwst> | I'm sure it's broken. I'm still not building locally. :/ |
| 08:25 | <mkwst> | Maybe I'll take some time to play with the new scripts y'all have put together. |
| 08:28 | <MikeSmith> | mkwst: yeah please do try out the script update and help test it |
| 08:29 | <MikeSmith> | mkwst: it's in the pr/20 branch there (aka sideshowbarker/redesign-output-input-split) |
| 08:31 | <MikeSmith> | mkwst: so yeah I "Parse Error: (14573,170) unexpected end tag" when building |
| 08:32 | <MikeSmith> | isn't that the line I sent you a PR for? |
| 08:32 | <mkwst> | Does it not like splitting the `span`'s attribute across lines? |
| 08:32 | <MikeSmith> | no, hang on |
| 08:32 | <mkwst> | Did you send me a PR? |
| 08:32 | <MikeSmith> | yeah https://github.com/mikewest/html/pulls |
| 08:33 | <MikeSmith> | https://github.com/validator/html/commit/3a47bf6209f3b7cee9773dec6b89142eae5cad22 |
| 08:33 | <MikeSmith> | the fix is to remove "</dfn></dt>" from the end of that line |
| 08:33 | <MikeSmith> | you don't need to use my PR as such |
| 08:34 | <MikeSmith> | I just made that because I wanted to see if it was possible to make a PR against somebody else's PR branch |
| 08:35 | <mkwst> | Ok, the `</dfn>` is certainly wrong, thanks! I guess the rest of the file drops the `</dt>` as well, even though that style choice is objectively incorrect. :) |
| 08:36 | <MikeSmith> | right yeah, the "</dt>" is not wrong but Hixie style is to omit it |
| 08:36 | <MikeSmith> | (personally I like that style too) |
| 08:36 | <MikeSmith> | "objectively incorrect" :) |
| 08:37 | <mkwst> | Eh. It feels wrong not to close tags that are closable. That said, out of all the things in this file that annoy me, lack of some closing tags is hardly at the top of the list. |
| 08:37 | <MikeSmith> | but it's not a big deal to have it |
| 08:37 | <mkwst> | Dropped it from the latest commit. |
| 08:37 | <MikeSmith> | k |
| 08:37 | <Ms2ger> | Annoyingly, he doesn't drop </li>, though |
| 08:38 | MikeSmith | pulls |
| 08:38 | <MikeSmith> | Ms2ger: yeah but Hixie does that specifically you personally ;-) |
| 08:39 | <MikeSmith> | Ms2ger: yeah but Hixie does that specifically to annoy you personally ;-) |
| 08:39 | <Ms2ger> | I knew it |
| 08:40 | <annevk> | Ms2ger: it depends, </li> is sometimes dropped |
| 08:40 | <MikeSmith> | mkwst: build success but got some non-build errors |
| 08:40 | <hsivonen> | aargh. I can't reuse the Web Platform Tests gbk encoder test for Gecko, because the test assumes that the browser has a URL Standard-compliant URL parser, which Gecko doesn't have |
| 08:40 | <MikeSmith> | mkwst: |
| 08:40 | <MikeSmith> | Error: missing <dfn> for topic "reflected-xss" explicitly from <code> element containing "reflected-xss"; previous heading contents are "4.2.5.3 Pragma directives" |
| 08:40 | <MikeSmith> | Error: missing <dfn> for topic "report-uri" explicitly from <code> element containing "report-uri"; previous heading contents are "4.2.5.3 Pragma directives" |
| 08:40 | <MikeSmith> | Error: missing <dfn> for topic "frame-ancestors" explicitly from <code> element containing "frame-ancestors"; previous heading contents are "4.2.5.3 Pragma directives" |
| 08:40 | <MikeSmith> | Error: missing <dfn> for topic "sandbox" explicitly from <code> element containing "sandbox"; previous heading contents are "4.2.5.3 Pragma directives" |
| 08:41 | <mkwst> | can I not just have `code` elements? Do they need to reference something? |
| 08:41 | <MikeSmith> | annevk: ↑ |
| 08:41 | <MikeSmith> | mkwst: empty |
| 08:41 | <MikeSmith> | oofs |
| 08:42 | <MikeSmith> | mkwst: <code data-x=""> |
| 08:42 | <MikeSmith> | I think |
| 08:42 | <MikeSmith> | or something like that |
| 08:42 | <MikeSmith> | right annevk ? |
| 08:43 | <mkwst> | this document's conventions are so strange. :( |
| 08:43 | <annevk> | MikeSmith: yes |
| 08:43 | <annevk> | MikeSmith: though perhaps we should just add references for those since they're all terms defined by CSP |
| 08:44 | <MikeSmith> | mkwst: you will learn to love it eventually (stockholm syndrome) |
| 08:44 | <mkwst> | yeah, i'm adding references. |
| 08:44 | <MikeSmith> | k |
| 08:44 | <Ms2ger> | MikeSmith, not before it's been bikeshedded, I hope :) |
| 08:45 | <mkwst> | Are we bikeshedding? That would be nice! |
| 08:45 | <Ms2ger> | I hope we will |
| 08:46 | <mkwst> | How will you deal with the multipage version? That logic seems somewhat custom. |
| 08:46 | <MikeSmith> | mkwst: you don't need to necessarily |
| 08:46 | <MikeSmith> | except for your local testing |
| 08:46 | <MikeSmith> | ah you mean the xrefs |
| 08:47 | <MikeSmith> | I guess? |
| 08:47 | <mkwst> | and the generation. |
| 08:47 | <nox> | Why would he have written wattsi if it's for the spec to be bikeshedded afterwards, though? |
| 08:49 | <mkwst> | MikeSmith: So what do I need to build locally at the moment? Do I still need to build wattsi locally? |
| 08:53 | <MikeSmith> | mkwst: no you do not need a local wattsi at all |
| 08:53 | <MikeSmith> | Domenic put together a service that the build script now calls |
| 08:53 | <mkwst> | do I need to patch anything in? |
| 08:54 | <MikeSmith> | the build sends your source to the service, and the service returns a zip file and the build unpacks that and runs the rest of the build using that |
| 08:54 | <annevk> | mkwst: "valid Content Security Policy" is not defined |
| 08:54 | <MikeSmith> | mkwst: I think the trunk has that service change |
| 08:54 | MikeSmith | looks |
| 08:54 | <annevk> | Ms2ger: is Bikeshed fast enough? |
| 08:55 | <MikeSmith> | mkwst: yeah it does (I realize now I was the one who merged it...( |
| 08:56 | <MikeSmith> | mkwst: so yeah you don't need to build wattsi. run the script and it Should Just Work |
| 08:56 | <mkwst> | MikeSmith: Using the sideshowbarker/redesign-output-input-split branch? |
| 08:57 | <MikeSmith> | mkwst: you can if you want, though the trunk will also work for you |
| 08:57 | <MikeSmith> | but the sideshowbarker/redesign-output-input-split branch is faster |
| 08:57 | <mkwst> | faster === better. |
| 08:57 | <MikeSmith> | yeah it's quite a bit faster |
| 08:57 | <mkwst> | and it looks like it solves the "copy everything into this directory" problem? |
| 08:57 | <MikeSmith> | yes |
| 08:57 | <MikeSmith> | that too |
| 08:57 | <MikeSmith> | yeah |
| 08:58 | <MikeSmith> | you don't need to copy anything or symlink anything |
| 08:58 | <Ms2ger> | Bikeshed in Rust |
| 08:58 | <MikeSmith> | oh, you should set HTML_SOURCE to the relative path to your html repo |
| 08:58 | <MikeSmith> | or if you have one in ../html the build will use it |
| 08:59 | <mkwst> | Ok. It worked! I think. |
| 08:59 | <MikeSmith> | mkwst: yeah look in the output dir |
| 08:59 | <MikeSmith> | you should have an output dir with everything |
| 09:00 | <annevk> | Ms2ger: or wattsi |
| 09:00 | <MikeSmith> | as far as speed, wattsi is extremely fast |
| 09:01 | <MikeSmith> | I can run a rebuild of the spec in just 8 seconds on my machine |
| 09:01 | <mkwst> | MikeSmith,annevk: I think the latest patch fixes the things you've noted. |
| 09:01 | <MikeSmith> | the code is actually pretty nice as well |
| 09:01 | MikeSmith | pulls |
| 09:04 | <MikeSmith> | annevk: btw before I forget http://stackoverflow.com/tags/fetch-api/info |
| 09:05 | <MikeSmith> | mkwst: so I tried twice and I'm still getting Error: missing <dfn> for topic "reflected-xss" explicitly from <code> element containing "reflected-xss"; previous heading contents are "4.2.5.3 Pragma directives" |
| 09:05 | <MikeSmith> | and 3 more |
| 09:06 | <MikeSmith> | and I still see <code>reflected-xss</code> in my source |
| 09:06 | <MikeSmith> | and I'm pretty sure I did actually merge |
| 09:07 | <mkwst> | MikeSmith: Yup. I missed reflected-xss. :/ Sorry about that. |
| 09:07 | <MikeSmith> | I mean, I merged in your latest to my clone of that branch |
| 09:07 | <mkwst> | Up now. |
| 09:08 | MikeSmith | does git fetch && git merge origin/pr/93 again |
| 09:10 | <MikeSmith> | mkwst: actually I believe the paragraph at line 14575 is what it's reporting those errors for |
| 09:10 | <mkwst> | Do I need any exciting flags to make errors appear? Even without that last commit, I only see "Possible incomplete sections", but no errors. |
| 09:10 | <MikeSmith> | oh |
| 09:10 | <MikeSmith> | that's odd |
| 09:10 | <MikeSmith> | oh |
| 09:10 | <MikeSmith> | hmm, yeah, I think I know why |
| 09:10 | <MikeSmith> | those errors are from wattsi |
| 09:10 | <MikeSmith> | the other ones you can see are from perl scripts |
| 09:10 | <mkwst> | (using the origin/sideshowbarker/redesign-output-input-split branch) |
| 09:11 | <MikeSmith> | yeah |
| 09:11 | <mkwst> | ok. so what command line are you executing? |
| 09:11 | <MikeSmith> | if you're not running wattsi locally you won't see those errors I think |
| 09:11 | <annevk> | So server-side wattsi doesn't report the parse errors? |
| 09:11 | <annevk> | That seems like a problem |
| 09:11 | <MikeSmith> | annevk: apparently it does not |
| 09:11 | <MikeSmith> | and yeah if so we need to fix that |
| 09:11 | <mkwst> | That seems somewhat critical. :) |
| 09:11 | <MikeSmith> | yeah |
| 09:12 | <MikeSmith> | but it's fixable |
| 09:12 | <annevk> | Installing wattsi is pretty trivial though |
| 09:12 | <annevk> | Should be even easier with MikeSmith's fix for OS X |
| 09:13 | <annevk> | (if you're running OS X) |
| 09:13 | <MikeSmith> | we just send the errors back with the bundle, as a errors.log text file, and we just emit (cat) whatever is in thatc |
| 09:13 | <MikeSmith> | yeah it is trivial to build wattsi |
| 09:13 | <MikeSmith> | except that you have to build Free Pascal from the unstable development sources first |
| 09:14 | <MikeSmith> | but hey that's not a PITA, right? |
| 09:14 | <MikeSmith> | and download the Free Pascal sources from FTP first too |
| 09:14 | <MikeSmith> | but we all like to do that kind of stuff |
| 09:14 | <mkwst> | ... |
| 09:15 | <MikeSmith> | annevk: so I do notice that those error messages don't report the line numbers, which is also not ideal |
| 09:15 | <annevk> | MikeSmith: which error messages? |
| 09:16 | <MikeSmith> | mkwst: as far as command-line for the build script invocation, I usually just do ./build.sh --no-update |
| 09:16 | <MikeSmith> | the ones I cited here earlier |
| 09:16 | <MikeSmith> | Error: missing <dfn> for topic "reflected-xss" explicitly from <code> element containing "reflected-xss"; previous heading contents are "4.2.5.3 Pragma directives" |
| 09:16 | <mkwst> | MikeSmith: Right. I understand now that it's just wattsi locally vs wattsi as a service. |
| 09:16 | <MikeSmith> | k |
| 09:16 | <mkwst> | (and I kinda don't want to build wattsi... :) ) |
| 09:17 | <MikeSmith> | something must be wrong with you if you're not thrilled about the idea of building wattsi yourself |
| 09:18 | <MikeSmith> | but, to each his own, as my chauffeur always says |
| 09:18 | MikeSmith | is loopy from lack of sleep and can be safely ignored |
| 09:19 | <MikeSmith> | seriously thanks for being the pioneer on using this gear, and for being patient |
| 09:20 | <MikeSmith> | we will soon have something that could be GAed for wide use |
| 09:22 | <mkwst> | No worries. Thanks for answering my stupid questions. :) |
| 09:23 | <annevk> | mkwst: so basically, for CSP and Mixed Content et al, do we want "requesting client" and "target browsing context"? |
| 09:24 | <mkwst> | annevk: Yeah, I think that's a reasonable way to name things, and it matches the kinds of checks that I think we actually want to be doing. |
| 09:47 | <MikeSmith> | mkwst: pulled and error-free now |
| 09:47 | <mkwst> | Huzzah! |
| 09:47 | MikeSmith | turns back to reading the actual content |
| 09:48 | <mkwst> | Bah. Form is all that matters! |
| 09:53 | <MikeSmith> | mkwst: reviewed and LGTM as far as resolving the review comments I made |
| 09:54 | <MikeSmith> | annevk: you're reviewing the changes? |
| 09:54 | <mkwst> | Cool. Once annevk is happy, I'll squash. *shrug* No rush. I'd prefer annevk make the Fetch changes so I can make MIX make sense. |
| 09:54 | <mkwst> | :) |
| 10:05 | <annevk> | mkwst: shouldn't "frame-ancestors directive</dfn>" be "<code>frame-..."? |
| 10:05 | <annevk> | <dfn><code>frame-ancestors</code> directive</dfn> |
| 10:14 | <annevk> | mkwst: so I go add target browsing context and I notice Fetch has a note on client being null for navigation... |
| 10:14 | <annevk> | mkwst: ugh navigation |
| 10:16 | <annevk> | I wonder if JakeA is around |
| 10:16 | <JakeA> | Yep! |
| 10:16 | <JakeA> | Ish |
| 10:17 | <annevk> | JakeA: so there's a problem with "client" of sorts in that it doesn't do the right thing for referrer and such |
| 10:17 | <annevk> | JakeA: in navigating scenarios |
| 10:17 | <annevk> | JakeA: in particular things like <a target=name href=...>x</a> <iframe name=name></iframe> |
| 10:18 | <annevk> | JakeA: for this CSP would want the global of <a> as client, SW currently expects null? |
| 10:18 | <annevk> | JakeA: is it problematic if we change that around? |
| 10:22 | <JakeA> | annevk: the change sounds fair to me |
| 10:22 | <JakeA> | wait - is this a security leak? |
| 10:23 | <JakeA> | If origin A contains <a href="//B"> and doesn't want to send referrer, B's serviceworker could look at the client and get the full url of the page |
| 10:24 | <JakeA> | Feels like the client should be null, to script at least |
| 10:24 | <JakeA> | Or, perhaps only in cross-origin cases |
| 10:30 | <mkwst> | I'd agree that we shouldn't expose a cross-origin client to script. |
| 10:30 | <mkwst> | That would be bad in a number of ways. |
| 10:31 | <JakeA> | "Client is null if it's from another origin" seems like a reasonable rule |
| 10:32 | <mkwst> | But that makes it difficult to do things like blocking navigation based on `child-src`, or upgrading requests based on the navigator's 'upgrade-insecure-requests' directive, or etc. |
| 10:33 | <mkwst> | We need the "requesting client", but there are times where we probably shouldn't expose it to script. |
| 10:33 | <JakeA> | Yeah, when I said "Client is null if it's from another origin" I mean script-facing |
| 10:33 | <JakeA> | Happy for it to be exposed in spec land |
| 10:54 | <mkwst> | annevk: Regarding churn, you could at least use local linking text of "requesting client" in Fetch itself. |
| 10:55 | <renlinx> | hi |
| 10:56 | <annevk> | mkwst: that would make it request's requesting client |
| 10:56 | <annevk> | mkwst: given that you typically prefix usage by request, it might not actually be needed |
| 10:57 | <mkwst> | *shrug* As long as "`request`'s `client`" can never be the place where the content is being delivered, and is always the initiator, that's fine. |
| 11:01 | <annevk> | mkwst: it's fine that it can go away though right? |
| 11:01 | <annevk> | mkwst: e.g., when a browsing context navigates itself |
| 11:01 | <mkwst> | Go away? |
| 11:02 | <annevk> | mkwst: a browsing context's associated global is typically destroyed in some fashion when navigation takes place |
| 11:03 | <mkwst> | Right. I'd hope that would happen after policy checks? |
| 11:03 | <annevk> | I hope so |
| 11:03 | <mkwst> | Then the spec can hope so too? |
| 11:03 | <annevk> | Navigate is not written in terms of Fetch yet |
| 11:04 | <annevk> | But yeah, that should be the case |
| 13:20 | <MikeSmith> | botie, seen othermaciej |
| 13:21 | <MikeSmith> | botie, seen othermaciej? |
| 13:39 | <zcorpan> | annevk: pls see https://github.com/whatwg/web-apps-tracker/pull/2 (i don't have mod_python locally so i haven't actually tested it) |
| 14:55 | <annevk> | zcorpan: oh cool |
| 14:59 | zcorpan | gotta go |
| 15:11 | <annevk> | seems to work with some tweaks |
| 15:11 | <jochen__> | annevk: who are you waiting for on https://github.com/whatwg/fetch/issues/80#issuecomment-132474557 ? |
| 15:34 | <annevk> | jochen__: nobody really, I fixed the issue |
| 15:35 | <annevk> | jochen__: I just don't know how stable it is :-) |
| 15:35 | <annevk> | jochen__: I would be okay with Chrome shipping though, personally |
| 16:18 | <annevk> | I created https://github.com/whatwg/misc-server for those that have been asking about hosting more miscellaneous server resources |
| 16:18 | <annevk> | It's not exactly complete, but it's a start |
| 16:18 | <annevk> | (It's a rename of the old web-apps-tracker repository, which we don't really need anymore.) |
| 16:32 | <annevk> | mkwst: is your CSP PR waiting on me? |
| 16:34 | annevk | leaves a comment |
| 16:46 | <zcorpan> | annevk: nice |
| 22:52 | <MikeSmith> | gsnedders: did you ever get a response to https://bugs.launchpad.net/lxml/+bug/1191545/comments/2 |
| 22:57 | <MikeSmith> | gsnedders: the lxml sources are at https://github.com/lxml/lxml so maybe you could submit a patch |
| 23:24 | <MikeSmith> | gsnedders: nm I just did https://github.com/lxml/lxml/pull/174 |
| 23:28 | <MikeSmith> | hmm, so that change doesn't actually break any of the existing lxml tests |
| 23:28 | <MikeSmith> | https://travis-ci.org/lxml/lxml/builds/79199872 |
| 23:29 | <MikeSmith> | I would have thought its test suite would have a test that this would regress |
| 23:30 | <MikeSmith> | maybe it actually doesn't have any tests for the html5parser at all https://travis-ci.org/lxml/lxml/jobs/79199874 |
| 23:32 | <MikeSmith> | seems maybe it does not https://github.com/lxml/lxml/tree/master/src/lxml/tests |
| 23:32 | <gsnedders> | MikeSmith: I don't care, really. I was just throwing out my opinion why the "bug" is in lxml |
| 23:36 | <MikeSmith> | gsnedders: please care :) |
| 23:36 | <MikeSmith> | there are a lot of lxml users |
| 23:36 | <MikeSmith> | and this causes a lot of them to be confused |
| 23:38 | <MikeSmith> | plus, it would be nice if more users used lxml's html5parser rather that the default ad-hoc one |
