| 05:36 | <annevk> | aklein: not all of those, so a bit? |
| 08:14 | <annevk> | console.log() becoming a standard seems to excite more folks on Twitter than anything else we ever did |
| 08:15 | <ondras> | :-) |
| 09:22 | <MikeSmith> | annevk: I guess it's something more directly tangible and familiar to most devs |
| 09:23 | <MikeSmith> | sice everybody who does web dev knows about console.log() and has used it |
| 09:41 | <annevk> | Whoa, it seems DreamHost allows enabling Let's Encrypt |
| 09:42 | <annevk> | Trying it out now... If that works Hixie will be so pleased he won't have to copy-and-paste certificates around dozens of domains |
| 09:42 | <ondras> | a quick CSP question -- does my CSP policy apply also *inside* of an iframe that itself sits on an allowed-but-different domain? |
| 09:42 | <annevk> | ondras: nope |
| 09:42 | <ondras> | annevk: nice, thanks. makes sense. |
| 10:00 | <annevk> | TabAtkins: another example, I just updated bikeshed, and now "URL" and "URLs" are no longer the same term |
| 10:02 | <annevk> | or fragment/fragments |
| 10:09 | <zcorpan> | annevk: with an updated bikeshed, for dom i get FATAL ERROR: No 'idl' refs found for 'addEventListener()' that are marked for export. |
| 10:11 | <annevk> | zcorpan: I have no idea how bikeshed works and apparently TabAtkins doesn't run regression tests |
| 10:11 | <zcorpan> | TabAtkins: ^ |
| 10:23 | <zcorpan> | https://travis-ci.org/tabatkins/bikeshed ... not sure what the expected output is there, but it says both FATAL ERROR and ✔ All tests passed. |
| 10:55 | <MikeSmith> | zcorpan: FYI https://lists.w3.org/Archives/Public/www-validator/2016Jan/0019.html |
| 10:59 | <zcorpan> | MikeSmith: intredasting. seems like a spec bug. can you file one? |
| 11:00 | <zcorpan> | i suppose we don't want to allow <template><p lolfoobar=""></template> |
| 11:01 | <MikeSmith> | sure but what about his real example of <img> without src? |
| 11:02 | <MikeSmith> | I will ask him to file a spec bug for it |
| 11:02 | <MikeSmith> | because the validator is conforming to the spec on this |
| 11:03 | <MikeSmith> | and I'm not sure what sane spec change we could actually make for this |
| 11:05 | <MikeSmith> | as far as the validator behavior I could create something that just drops all <template> elements and their subtrees from the document before running validation on it against the RelaxNG schema |
| 11:10 | <MikeSmith> | we don't actually have that many required attributes, so one way I could handle it is to make the RelaxNG schema make them optional but make the Java assertions-checking code report errors for them unless they are in <template> subtrees |
| 11:12 | <ritsyy> | while running the build script i am getting "curl: (55) Send failure: Broken pipe" this error |
| 11:15 | <annevk> | MikeSmith: ^^ turns out connectivity is not stable everywhere which is another good reason to reduce external dependencies |
| 11:16 | <annevk> | MikeSmith: ritsyy: perhaps we should also document options such as -n directly on https://github.com/whatwg/html-build |
| 11:17 | <ritsyy> | annevk: yes it is very much needed, |
| 11:18 | <MikeSmith> | annevk: OK yeah I will put together an html-build PR for that tomorrow (should have had it done before now but been distracted by working on validator stuffーadding support for CSP checking and some other things) |
| 11:21 | <zcorpan> | MikeSmith: yeah we should change the spec to be somewhat laxer on attributes in <template> |
| 11:24 | <MikeSmith> | zcorpan: OK I'll ask them to file the bug since they have real use cases to explain |
| 11:25 | <zcorpan> | thx |
| 11:25 | <ritsyy> | annevk: -n also not working in my case |
| 11:26 | <ritsyy> | again there is the broken pipe error script stops almost everytime at 86% or so |
| 11:29 | <annevk> | Hmm, perhaps even then there is some network stuff |
| 11:30 | <ritsyy> | annevk: yeah |
| 11:34 | <MikeSmith> | ritsyy: do you know what exactly it's doing when it hangs at 86%? |
| 11:34 | <MikeSmith> | I mean, which step |
| 11:34 | <MikeSmith> | if you run it with --verbose it might be more clear |
| 11:35 | <MikeSmith> | that will be super-verbose but if you look at the last few lines of console output before that 86% point, that might show it |
| 11:45 | <ritsyy> | MikeSmith: https://paste.kde.org/pfom38ygc here are these lines but i didn't got any idea about it |
| 11:53 | <zcorpan> | maybe it works better if wattsi is installed locally? |
| 12:01 | <MikeSmith> | ah yeah if you don't have wattsi installed locally then it certainly is going to require network access to send the request to the wattsi server and receive the resulting output |
| 13:28 | <ritsyy> | MikeSmith: zcorpan okay, yes i will install wattsi locally then, thanks! |
| 15:56 | <TabAtkins> | annevk: lolwat, I tested *precisely that*. The change just made it so that *if* I find an exact match, I don't also go look for variants (producing confusing errors if you have two <dfn>s that are variants of each other). I'll debug on the bus this morning, sorry for the trouble. |
| 15:57 | <annevk> | TabAtkins: noticed it for both URL and DOM, kinda surprised nobody else noticed this |
| 15:57 | <TabAtkins> | (Seriously, I verified that <dfn>foo</dfn> is still matching <a>foo</a> and <a>fooing</a>.) |
| 15:57 | <TabAtkins> | Dunno man, I was editting CSS specs all day and didn't run into any problems. |
| 15:58 | <annevk> | TabAtkins: I actually ended up fixing it for URL, by just adding <a lt> things |
| 15:58 | <TabAtkins> | Well you'll be able to revert that in about an hour when I figure out what the deal is. |
| 15:58 | <annevk> | but then DOM was much more complicated and became a whack-a-mole |
| 16:04 | <TabAtkins> | I've told you in the past - don't fix around Bikeshed errors. I'm very fast in dealing with them, you'll just waste your time and get frustrated trying to deal with them and then revert. |
| 16:10 | <annevk> | Well, I was already frustrated, but yes, I did waste time |
| 16:11 | <Domenic> | It would be really great if e.g. the DOM source was checked in to Bikeshed and it was a regression test that it have to be rebaselined every change and sanity checked. |
| 16:17 | <TabAtkins> | Domenic: Yeah, I've been meaning to put some full specs into the testsuite for that purpose, and just haven't done it yet. I'll dump DOM in after I fix this. |
| 16:18 | <Domenic> | \o/ |
| 16:34 | <TabAtkins> | Oof, working on DOM, I'm like "how did this *ever* build cleanly?" |
| 16:36 | <TabAtkins> | Oh dang, I see the error. This is... annoying. |
| 16:42 | <annevk> | MikeSmith: did you know that your download all PRs script also includes closed PRs? |
| 16:42 | <annevk> | MikeSmith: would be nice if those could be excluded somehow |
| 16:44 | <Ms2ger> | annevk, heyo |
| 16:44 | <Ms2ger> | First step in https://xhr.spec.whatwg.org/#the-open%28%29-method , how does that work in Workers? |
| 16:45 | <Ms2ger> | With https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object |
| 16:46 | <annevk> | Ms2ger: workers used to have a responsible document too, if that's gone, not sure |
| 16:47 | <annevk> | Ms2ger: time for an issue I guess and some thinking |
| 16:47 | <Ms2ger> | annevk, you filing? |
| 16:47 | <annevk> | sure |
| 16:48 | <Ms2ger> | Great, thanks |
| 16:49 | <annevk> | https://github.com/whatwg/xhr/issues/47 |
| 16:50 | <Ms2ger> | <3 |
| 16:54 | <TabAtkins> | annevk: Pushing a revert on that commit now, as I'll need to do something differently to make it work properly. |
| 16:55 | <TabAtkins> | And DOM works now. |
| 16:55 | <annevk> | ta |
| 16:59 | <Ms2ger> | https://github.com/whatwg/html/issues/546 |
| 16:59 | <Ms2ger> | Poor avidrissman |
| 17:12 | <Domenic> | He sits next to me in Chrome NYC |
| 17:12 | <Domenic> | it was fun times yesterday learning about this |
| 17:14 | <zcorpan> | anyone have opinions on what JSON.stringify(new DOMMatrix(...)) should do? see https://lists.w3.org/Archives/Public/public-fx/2016JanMar/0014.html |
| 17:16 | <zcorpan> | philipj: ^ |
| 17:17 | <zcorpan> | (WebKitCSSMatrix serializes as {} fwiw) |
| 17:17 | <miketaylr> | i was going to suggest whatever WebKitCSSMatrix does, because i'm lazy |
| 17:19 | <zcorpan> | miketaylr: in the thread it was argued that all geometry objects should have serializers |
| 17:19 | <zcorpan> | that are more useful than {} |
| 17:19 | <miketaylr> | yeah {} is pretty useless |
| 17:22 | <zcorpan> | i'm tempted to switch to serializer = { attribute }; for matrices also |
| 17:22 | <Domenic> | zcorpan: I see two approaches in general: serialize everything and serialize only the minimal amount needed to reconstruct. You seem to have gone with serialize everything elsewhere so being consistent with that makes sense to me. |
| 17:23 | <zcorpan> | Domenic: yeah. thx |
| 17:27 | <zcorpan> | https://github.com/w3c/fxtf-drafts/commit/7b5664a99dff3a3c3afd5085c65fea7ad7791d9c |
| 17:34 | <zcorpan> | Domenic: can you check https://github.com/whatwg/html/pull/514 ? :-) |
| 17:50 | <Domenic> | Will do |
| 18:41 | <nikkibee> | hey annevk I had a question about steps 6 and 7 for a redirect status under https://fetch.spec.whatwg.org/#http-fetch |
| 18:41 | <nikkibee> | er, 7 and 8* |
| 18:41 | <nikkibee> | 7. If request's redirect count is twenty, return a network error. |
| 18:41 | <nikkibee> | 8. Increase request's redirect count by one. |
| 18:42 | <nikkibee> | this means that on the 21st redirect a network error is returned |
| 18:42 | <nikkibee> | since redirect count starts at 0 |
| 18:42 | <nikkibee> | is this intentional? cause if the steps were switched, it'd return a network error on the 20th redirect |
| 18:43 | <nikkibee> | 20 or 21 is arbitrary (afaict) either way, but 20 just seems easier to logic about cause of how we work with numbers |
| 18:44 | <Domenic> | I wonder which (if either) browsers implement... I had no idea that was a thing |
| 18:44 | <Domenic> | I guess I've seen the "too many redirects" for page loads before |
| 18:44 | <Domenic> | But I didn't realize it would apply to all fetches. |
| 18:44 | <nikkibee> | well, it only applies to fetches that start redirecting |
| 18:45 | <nikkibee> | I just want to be sure of the number because I'm writing some tests for redirects in Servo, and I want to make sure I test the boundaries correctly |
| 18:47 | <Domenic> | Anyone want to review the commit message for <script type="module">? https://github.com/whatwg/html/pull/443/commits |
| 19:50 | <annevk> | nikkibee: that should maybe be nineteen indeed |
| 19:50 | <annevk> | nikkibee: not really around now though |
| 19:51 | <nikkibee> | annevk: that's alright, I'm glad I was on to something about it |
| 19:51 | <nikkibee> | should I open an issue about it? |
| 19:51 | <annevk> | nikkibee: PR? |
| 19:51 | <annevk> | nikkibee: but yes |
| 19:51 | <nikkibee> | sure thing |
| 19:51 | <nikkibee> | I think switching the order of the steps would make more sense too |
| 19:52 | <nikkibee> | because stopping at 19 is not obvious unless you think about how it's 0-indexed |
| 19:52 | <annevk> | nikkibee: so actually |
| 19:52 | <annevk> | nikkibee: there's an open PR by me |
| 19:52 | <annevk> | nikkibee: that factors out this redirect business |
| 19:52 | <nikkibee> | oh! no more redirect_count you mean? |
| 19:52 | <annevk> | nikkibee: and changes a couple of things |
| 19:53 | <annevk> | nikkibee: no that is kept |
| 19:53 | <nikkibee> | annevk: what does it change? |
| 19:53 | <annevk> | nikkibee: it changes processing for "manual" |
| 19:54 | <annevk> | nikkibee: but it mostly makes it possible for HTML to reuse that algorithm to follow navigation redirects |
| 19:56 | <annevk> | ttyl |
| 19:58 | <nikkibee> | see ya, thanks for the info |
| 20:05 | <jarek> | Hi |
| 20:06 | <jarek> | Is the problem of relative URLs in web components already resolved? |
| 20:14 | <smaug____> | no zcorpan |
| 20:15 | <smaug____> | https://drafts.csswg.org/cssom-view/#dom-document-scrollingelement could use a small tweak and define what root element means there |
| 20:34 | <annevk> | jarek: nope |
| 20:37 | <jarek> | annevk: is it delayed util https://github.com/whatwg/loader spec is finished? |
| 20:37 | <jarek> | annevk: or is it a problem that can't be solved at all and we will have to stick with directory naming conventions? |
| 20:37 | <jarek> | s/util/until |
| 20:39 | <annevk> | jarek: it would require changes to DOM, but unclear how that works well together with script, indeed, which uses base from execution environment |
| 21:15 | <smaug____> | https://drafts.csswg.org/cssom-view/#dom-document-scrollingelement is so weirdly written. scrollableElement is body if body is _not_ potentially scrollable |
| 21:34 | <smaug____> | rbyers: I don't understand blink's scrollableElement implementation |
| 21:34 | <smaug____> | or perhaps I'm reading the spec wrong |
| 21:35 | <smaug____> | it doesn't seem to care about overflow-x/y values |
| 21:56 | <rbyers> | smaug___: Blink intentionally doesn't exactly match the spec here (which is kind of the point of document.scrollingElement) - unless ScrollTopLeftInterop is enabled - see https://dev.opera.com/articles/fixing-the-scrolltop-bug/ |
| 21:57 | <rbyers> | ... but yeah the pre-existing rules about how body behaves are weird - scrollingElement just reflects that. |
| 21:58 | <rbyers> | ... basically if you have "html, body {overflow: scroll}" then there are two independently scrollable things. But if you just have "body {overflow: scroll }" then that applies to the viewport (behaves the same as just "html {overflow: scroll}" I believe). |
| 21:59 | <rbyers> | But none of this really matters for the definition of scrollableElement. All that really matters for that API is that document.scrollingElement reflects the element whose scrollTop changes when you do window.scrollTo. |
| 22:00 | <rbyers> | The spec over-complicates this by repeating the complex legacy details in both the definition of scrollingElement and the definition of scrollTop (see https://drafts.csswg.org/cssom-view/#dom-element-scrolltop). |
| 22:01 | <rbyers> | My advice to Simon was to just move all the complexity from scrollTop/scrollLeft (which has long been there for legacy reasons) into the defintion of scrollingElement, then write everything else in terms of "if 'e' is the scrollingElement". That's what I did in the blink implementation. |
| 22:02 | <rbyers> | (with the added complexity that we have to support ScrollTopLeftInterop being disabled - for now, I hope to ship it this quarter). |
| 22:19 | <smaug____> | rbyers: well I can't see it ever matching the spec |
| 22:20 | <smaug____> | but I don't understand why this property should be added if blink doesn't implement it per spec |
| 22:20 | <smaug____> | or in other words, I guess I should just implement it the same way it is in blink |
| 22:21 | <smaug____> | but I'm not totally lost with this property |
| 22:24 | <rbyers> | smaug___: If all browsers implemented scrollTop according to spec, there would only be minor utility to this API. |
| 22:25 | <rbyers> | WebKit has a long standing bug where scrollTop/Left behave as if the page was in quirksmode (i.e. body.scrollTop==window.scrollY, documentElement.scrollTop==0) even when it's not (should be documentElement.scrollTop==window.scrollY, body.scrollTop==0). |
| 22:25 | <rbyers> | It's because sites have come to depend on WebKit's long-standing bug where scrollTop behaves as per quirksmode for ALL pages that we need this API. |
| 22:26 | <rbyers> | We've successfully used this API to get sites to migrate away from depending on code like "isWebKit ? body : documentElement". |
| 22:29 | <smaug____> | rbyers: sure, scrollTop and those are old stuff |
| 22:29 | <smaug____> | but why isn't blink implementing this new API per spec? |
| 22:30 | <smaug____> | isn't that the whole point that there is some API which all the browsers implement the same way? |
| 22:30 | <smaug____> | I guess not in this case |
| 22:32 | <rbyers> | It does implement it per spec when ScrollTopLeftInterop mode is enabled, which I'm trying to ship (but can only do once I've gotten enough sites updated). |
| 22:32 | <smaug____> | it is not implementing per spec when that is enabled |
| 22:32 | <rbyers> | BTW it's weird quirksmode cases like this http://jsbin.com/hocuno/edit?html,css,js,output where scrollingElement should be null |
| 22:33 | <smaug____> | blink doesn't care about the overflowx/y values of html element |
| 22:33 | <smaug____> | it checks only body element |
| 22:33 | <rbyers> | because in that case neither document.body.scrollTop nor document.documentElement.scrollTop will match window.scrollY |
| 22:34 | <rbyers> | Are you saying that just based on code inspection, or do you have a repro? |
| 22:34 | <smaug____> | rbyers: based on code inspection |
| 22:34 | <rbyers> | There's some funky logic elsewhere in the code that promotes styles from documentElement to body or vice versa |
| 22:34 | <smaug____> | (I don't even know how to enable RuntimeEnabledFeatures::scrollTopLeftInteropEnabled()) |
| 22:34 | <rbyers> | Try to build a repro |
| 22:34 | <smaug____> | huhuh |
| 22:35 | <smaug____> | so blink is doing some magic there too |
| 22:35 | <rbyers> | You can enable that flag easily by setting chrome://flags/#enable-experimental-web-platform-features |
| 22:35 | <rbyers> | Or explicitly by running with --enable-blink-features=ScrollTopLeftInterop |
| 22:35 | <smaug____> | ah, that, thanks |
| 22:35 | <rbyers> | NP |
| 22:37 | yury`m | is thinking "worker code that holds cross-thread refs to promises" statement along with Domenic streams-from-main-thread-to-worker statement |
| 22:37 | <Domenic> | ? |
| 22:38 | <rbyers> | If you can come up with a repro that's not per spec, I'll definitely investigate. There's a bunch of annoying complexity / long-standing legacy here that was previously exposed only via scrollTop/scrollLeft behavior. scrollingElement should just reflect that behavior (i.e. so we should be able to compare scrollTop behavior between blink with |
| 22:38 | <rbyers> | ScrollTopLeftInterop enabled and Firefox - should match exactly) |
| 22:38 | <yury`m> | Domenic: there was your vimeo video about mozilla thinking about moving streams processing in the worker |
| 22:39 | <yury`m> | do you have more context? |
| 22:40 | <Domenic> | yury`m: I think it was https://w3c.github.io/mediacapture-worker/ |
| 22:40 | <yury`m> | Domenic: at 44:20 of https://vimeo.com/132786072 |
| 22:46 | yury`m | posted to wrong channel his thoughts, so goes back to where he came from to think there :) |
| 23:17 | <MikeSmith> | aannevk: yeah about the PR-branch-fetch config, I don't know how to make it not fetch closed PRs. It's a github-specific thing, not a git thing, and I think it may just need to be made smarter on the github side. But will look into it more. |
| 23:30 | <MikeSmith> | Domenic: given the network problems that ritsyy has had, I'd guess others in some places might run into similar issues, and so wattsi server might not be the best solution in all cases for trying to make things as easy as possible for contributors |
| 23:31 | <MikeSmith> | but since building fpc and watssi locally is also not exactly easy, I wonder if we might consider creating a Docker image |
| 23:32 | <Domenic> | MikeSmith: I am personally scared of docker but that seems like a good solution for a certain class of people. |
| 23:32 | <MikeSmith> | yeah, I've never created one for anything and have been skeptical about the need in other projects where it's come up, but this seems like a case where it might actually solve a real problem |
| 23:33 | <MikeSmith> | anyway, I have a bunch of other open html-build and watssi things on my stack before I could get to that |
| 23:33 | <Domenic> | :) |
| 23:33 | <MikeSmith> | but maybe if we have somebody familiar/experienced with Docker, they could give it a shot |
| 23:33 | <Domenic> | i really need to spend a bit more time on wattsi-server to make it a full build server |
| 23:34 | <Domenic> | Seems like a good thing to post an issue about describing what we'd like help with and then point the community at. |
| 23:34 | <MikeSmith> | yeah I think for most people, wattsi-server really is the best solution |
| 23:34 | <MikeSmith> | OK, will raise an issue for now |
| 23:44 | <MikeSmith> | for anybody on the channel with Docker chops who's interested in helping with the HTML spec effort: https://github.com/whatwg/html-build/issues/55 |
| 23:51 | <Domenic> | Tweeted https://twitter.com/domenic/status/689958419130884098 |