| 01:32 | <MikeSmith> | anybody have a clue about http://stackoverflow.com/questions/32103768/accessing-reponse-headers-on-cors-request |
| 01:33 | <MikeSmith> | I tried the code in question there and get the same result |
| 01:34 | <MikeSmith> | doing response.headers.get('Link') returns null despite the fact that if you look at the console, in the response it's getting there is in fact a Link header |
| 01:35 | <MikeSmith> | the only headers I can actually see with response.headers.get for the response there are the Content-Type and Cache-Control headers |
| 02:01 | <Domenic> | Doesn't CORS block all headers except those allowed by Access-Control-Allow-Headers, MikeSmith? |
| 02:05 | <annevk> | Domenic: correct |
| 02:05 | annevk | just replied |
| 02:30 | <MikeSmith> | oh |
| 02:31 | <MikeSmith> | yeah I'd just not bothered to check Access-Control-Allow-Headers |
| 02:32 | <MikeSmith> | annevk: thanks for replying there |
| 02:33 | <MikeSmith> | Domenic: ah but annevk's answer is about Access-Control-Expose-Headers |
| 02:33 | <Domenic> | Ah didn't even know about that one |
| 02:34 | <annevk> | Oh, I just read Expose where Domenic wrote Allow |
| 02:34 | <MikeSmith> | but wait I think I don't understand what the conforming behavior is here |
| 02:34 | <annevk> | It's a bit too hot to fall asleep here, but clearly I'm not very much awake either |
| 02:34 | <MikeSmith> | heh |
| 02:35 | <annevk> | hallvors: do we test parsing of CORS headers? https://stackoverflow.com/questions/24514666/why-is-this-cors-request-failing-only-in-firefox suggests Safari/Chrome are sloppy |
| 02:35 | <boogyman> | why is the header given if it's not allowed? shouldn't that be truncated at the network before ever being given to the client? |
| 02:36 | <annevk> | boogyman: Access-Control-Expose-Headers is defense-in-depth for the server |
| 02:37 | MikeSmith | reads cors |
| 02:37 | <MikeSmith> | oofs |
| 02:37 | MikeSmith | reads https://fetch.spec.whatwg.org/#concept-filtered-response-cors |
| 02:40 | <boogyman> | annevk: are you assuming that header has been set on said server? Nothing in the op's message implies that to be true |
| 02:41 | <annevk> | boogyman: I'm not sure what you're asking |
| 02:41 | <boogyman> | I understand that header provides this "defense in depth" concept, but I don't understand it's relevance to the thread |
| 02:43 | MikeSmith | keeps busy voting up the answers annevk is posting on SO right now |
| 02:44 | <annevk> | boogyman: if you want to read a Link header value from a cross-origin resource, you need to use that header to get the Link header value exposed to script |
| 02:46 | <MikeSmith> | annevk: you should answer fetch/CORS questions on SO more often |
| 02:50 | <boogyman> | okay, so the client (in this case the browser) will only allow programmatic access if the key is added to that header (defense in depth)? But what about human eyes? Shouldn't the server never provide that header, regardless of how the client may react; is my understanding incorrect? |
| 02:55 | <annevk> | boogyman: it depends on what the server is concerned with |
| 02:55 | <annevk> | boogyman: note that web's security model is build around the thesis that the server is not aware it may be leaking sensitive data |
| 02:56 | <annevk> | MikeSmith: I tried to search for "fetch" but that is rather useless |
| 02:56 | <MikeSmith> | yeah |
| 02:56 | <annevk> | MikeSmith: let me know if you find any, happy to help out folks whenever |
| 02:56 | <MikeSmith> | will do |
| 02:57 | <MikeSmith> | maybe we should try to get somebody to add a "fetch-method" tag, or "fetch-standard" |
| 02:57 | <MikeSmith> | (I don't have enough SO reputation to add tags myself or I would) |
| 02:58 | <MikeSmith> | maybe Domenic does? |
| 02:59 | <boogyman> | re wsm: that's worst case scenario. It would be considered out of specification compliance though, right? The end point should understand the type of response it is expected to provide given the request details (it is allowed to guess at anything else that is not implied by the request eg: no Accept, the server could respond with with any Content-Type) |
| 03:04 | <annevk> | There's no specification that requires that a server cannot reveal confidential information when accessed from a certain IP address... Or when accessed behind a firewall (through evil.com). |
| 03:05 | <boogyman> | isn't that what the Access-Control headers are exactly for when making a cors request? |
| 03:08 | <annevk> | Sure, but we don't want folks putting those headers there and then inadvertently leaking some details they did not expect, that's why there's some additional headers to reveal all the things |
| 03:10 | <annevk> | Domenic: so the idea is that we'll use our own copy of the repo to make PRs from and not just use branches? |
| 03:10 | <Domenic> | annevk: yeah, that's what philipj seems to prefer |
| 03:11 | <annevk> | I guess I can try that out, I always seem to end up with a mess that way, but I can learn |
| 03:14 | <Domenic> | Currently trying to get file-issue.js working, woo |
| 03:14 | <boogyman> | annevk: but as an author, I take care of the headers I expose, so by the specification allowing that (instead of it being human error in your scenario), I am now unexpectedly able to leak information even though the headers /have/ been explicitly provided |
| 03:14 | <annevk> | boogyman: leaking them to whom? |
| 03:15 | <boogyman> | whomever is making the request |
| 03:17 | <boogyman> | It's good that the client doesn't given access to the key because the key was not provided, yet at the same time I would argue the fact that the server did provide the header is a bad thing. |
| 03:19 | <MikeSmith> | annevk: Domenic I'm not sure why philipj prefers that you'd make PRs from forks instead of branches, but I you can convince him otherwise. But IMHO there are better collaborative advantages to using branchesーespecically if the number of people pushing is small (as it is here)ーand not many disadvantages |
| 03:19 | <boogyman> | because the header* |
| 03:20 | <MikeSmith> | Domenic: I'd be curious to hear what philipj sees as the disadvantages of y'all using branches for PRs |
| 03:20 | <Domenic> | MikeSmith: IIRC he says they tend to accumulate |
| 03:20 | <MikeSmith> | well |
| 03:20 | <MikeSmith> | that's true |
| 03:20 | <MikeSmith> | but you just delete them |
| 03:20 | <MikeSmith> | hygiene |
| 03:20 | <MikeSmith> | and GH has the button which makes it easy |
| 03:21 | <MikeSmith> | any time you merge a PR, the "delete this branch" button is right there |
| 03:21 | <Domenic> | Yeah that's my experience as well |
| 03:21 | <Domenic> | But I don't really care much |
| 03:21 | <MikeSmith> | ok |
| 03:23 | <MikeSmith> | anway for the wpt case, the biggest advantage we've found in practice is that any pusher can make a change to any PR branch. And sometimes we've used that. e.g., When you're reviewing, for small editorial-type changes, it's sometimes way easier and faster to just make the change in the branch yourself rather than needing to write up a review comment to ask the PR submitter to do that |
| 03:24 | <MikeSmith> | I know jgraham very much prefers branches for PRs, and could probably articulate some reasons |
| 03:24 | <MikeSmith> | anyway, 'nuff said |
| 03:28 | <MikeSmith> | ah whatwg.org/newbug is nice to have |
| 03:28 | <Domenic> | Yeah that's a good point, I used that feature the other day with streams |
| 03:29 | <MikeSmith> | Domenic: yeah once you're used to using that feature it'd kind of hard to go back |
| 03:29 | <Domenic> | Maybe philipj will be persuaded by these arguments when he wakes up :) |
| 03:29 | <MikeSmith> | heh |
| 03:29 | <MikeSmith> | I hope so |
| 03:29 | <MikeSmith> | so shouldn't whatwg.org/newbug be, like, whatwg.org/newbug?spec=html or something? |
| 03:30 | <Domenic> | Heh, that would be neato I suppose |
| 03:31 | <MikeSmith> | but I guess even that it would make sense to have it go to https://github.com/whatwg/html/issues/new by default (if no query param specified) |
| 03:33 | <Domenic> | MikeSmith: can you do a thing where people cannot file new bugs in the HTML component on bugzilla? I have heard of such things being done in the past. |
| 03:34 | <MikeSmith> | yes |
| 03:34 | <MikeSmith> | I think we should go ahead and do that right now |
| 03:34 | <MikeSmith> | agreed? |
| 03:34 | <MikeSmith> | or you want to wait? |
| 03:35 | <MikeSmith> | annevk: ↑ |
| 03:35 | annevk | reads scrollback |
| 03:36 | <annevk> | MikeSmith: please do |
| 03:37 | <annevk> | MikeSmith: we will only close bugs in HTML from now on |
| 03:37 | <annevk> | and for each bug we close, I'm sure two issues will arise, though I hope not |
| 03:38 | <boogyman> | annevk: thanks for your time re: cors discussion |
| 03:38 | <Domenic> | Any ideas on https://www.w3.org/Bugs/Public/show_bug.cgi?id=28992 ? |
| 03:38 | <annevk> | boogyman: I agree with you that it would be better for servers to reveal as little as possible |
| 03:39 | <annevk> | boogyman: although the only attacker I can see here is the user and potentially mitm if the server didn't use HTTPS properly |
| 03:39 | <annevk> | Domenic: sounds like a validator message submitted as bug |
| 03:39 | <annevk> | Domenic: so INVALID |
| 03:39 | annevk | is fixing all typo bugs in one sweep |
| 03:40 | <Domenic> | haha oh i was starting on that, good thing you said something :P |
| 03:42 | <Domenic> | Oooh a juicy one |
| 03:42 | <Domenic> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=28219 |
| 03:45 | <MikeSmith> | christ, "Bugs: 4005" (for the HTML spec component in bugzilla) |
| 03:46 | <MikeSmith> | OK, no more music by the HTML component in W3C bugzilla |
| 03:46 | <MikeSmith> | that is, no new bugs can be filed there |
| 03:46 | <MikeSmith> | we will just have to get by with the paltry 4005 we already have there |
| 03:47 | <Domenic> | Only 400-odd open... |
| 03:47 | <MikeSmith> | yeah, that's open-bugs number is seriously not so daunting |
| 03:51 | <Domenic> | Some good stuff in https://www.w3.org/Bugs/Public/quips.cgi?action=show |
| 03:54 | <MikeSmith> | anyway, I look back with some melancholy on the life of HTML in W3C bugzilla, recalling epic moments in history like when 8 years ago or whenever, when I first put some facts on the ground by setting it up for us to use for the spec when Hixie was still working on it in the HTML WG, then the grand "project convergence" when Hixie cloned all the open bugs over to the WHATWG product, and then the time when |
| 03:54 | <MikeSmith> | I took the component on his first fishing trip at the cottage by the lake, and so on |
| 03:59 | <MikeSmith> | botie: inform zcorpan, seems like we should now please consider closing the W3C "HTML - <img>" component to new bugs, and moving to either just using https://github.com/whatwg/html/issues/new (or to https://github.com/ResponsiveImagesCG/picture-element/issues if there's still good reason to do that) |
| 03:59 | <botie> | will do |
| 03:59 | <annevk> | Domenic: heh, I caused that feature to be added |
| 04:00 | <annevk> | botie: inform zcorpan, we should merge <picture> into HTML proper now it can be maintained through PRs |
| 04:00 | <botie> | will do |
| 04:05 | <MikeSmith> | Domenic: dinnet know "Git tradition is no periods at the end of commit message first-lines." |
| 04:05 | MikeSmith | reads https://github.com/erlang/otp/wiki/Writing-good-commit-messages |
| 04:06 | <MikeSmith> | in reviewing patches to the validator code, Henri would sometimes ask if I could add a period to the commit message |
| 04:06 | <MikeSmith> | but I always sorta was happier without the period |
| 04:06 | <MikeSmith> | now I feel vindicated |
| 04:07 | <MikeSmith> | "Don't end the summary line with a period - it's a title and titles don't end with a period." YES |
| 04:07 | <annevk> | Domenic: what's the GitHub way of approving a PR? |
| 04:08 | <Domenic> | annevk: "LGTM" |
| 04:08 | <Domenic> | annevk: why is https://github.com/whatwg/html/pull/7 async instead of defer, i am so confused |
| 04:08 | <annevk> | Domenic: because that's what the script says |
| 04:09 | <annevk> | Domenic: that script listens for DOMContentLoaded |
| 04:09 | <Domenic> | Well, yeah, but I wrote the script :P. And I clearly don't know any better. |
| 04:09 | <Domenic> | I guess defer seems in the spirit of "don't interrupt me while i'm loading this giant document" |
| 04:09 | <annevk> | Domenic: presumably we could rewrite our scripts at some point to be better about all this |
| 04:09 | <annevk> | if we cared enough |
| 04:09 | <annevk> | Domenic: well, you copied from zcorpan, he started the trend I think |
| 04:09 | <Domenic> | I can change the comment in file-issue.js, just confused. |
| 04:10 | <annevk> | Domenic: see https://resources.whatwg.org/file-bug.js |
| 04:10 | <Domenic> | Right. |
| 04:10 | <Domenic> | That one polls though, crazysauce. |
| 04:35 | <Domenic> | annevk: So, fetch everything. Check out your master. Reset it hard to whatwg/html master. Then check out your FrameRequestCallback branch, and rebase it on top of your master. You can then force push to your FrameRequestCallback branch and everything should work. |
| 04:38 | <annevk> | Domenic: how do I do the hard reset? |
| 04:38 | <philipj> | annevk, Domenic, MikeSmith: I'm about to head to the train, today is a day off |
| 04:38 | <annevk> | philipj: enjoy |
| 04:39 | <philipj> | About branches in the "production" repo, those seem to accumulate, but if you have a way to not make them accumulate, fine by me |
| 04:39 | philipj | is gone |
| 04:40 | <Domenic> | annevk: git reset --hard upstream/master or whatever you called it |
| 04:41 | <annevk> | ta |
| 04:45 | <MikeSmith> | well, I do have ways to make branches not accumulate. The easiest way is simply for whoever merges a PR to just take a half-second to push the "delete branch" button (and for anybody else to at any time just delete any got-left-behind already-merged branches that they notice) |
| 04:53 | <Domenic> | Oops, build hook was not pointing to the right domain. Fixed. |
| 04:53 | <annevk> | So I can't do the git push for some reason since I can't authenticate from the command line |
| 04:53 | <annevk> | I use 2FA, but GitHub also has my SSH key so I've no idea what's going on |
| 04:54 | <annevk> | I've been happily using the GitHub client for Mac staying ignorant of all this |
| 04:55 | <MikeSmith> | 2FA doesn't affect the command-line behavior afaik |
| 04:56 | <Domenic> | 2FA means you need special passwords |
| 04:56 | <MikeSmith> | annevk: if you do "ssh -T github.com" what happens? |
| 04:56 | <Domenic> | annevk: you can generate such passwords at https://github.com/settings/tokens |
| 04:57 | <annevk> | MikeSmith: that works |
| 04:57 | <Domenic> | GitHub for Mac might have set up the remote as HTTPS instead of SSH |
| 04:57 | <Domenic> | you could change that and things would probably work fine |
| 04:58 | <Domenic> | git remote set-url whateveryounamedyourannevkremote git⊙gc:annevk/html.git |
| 04:58 | <MikeSmith> | Domenic: I have 2FA set up for github and I don't need special passwords; git push to the ssh repo URL from the command line just works as expected |
| 04:58 | <annevk> | Domenic: that did work |
| 04:58 | <annevk> | Domenic: with the token password |
| 04:58 | <Domenic> | MikeSmith: yeah if you're set up using SSH no need |
| 04:59 | <Domenic> | MikeSmith: but if you're using HTTPS you need a token password |
| 04:59 | <MikeSmith> | ah |
| 05:00 | <MikeSmith> | shouldn't y'all be using the git⊙gc:whatwg/html.git URL? |
| 05:00 | <MikeSmith> | ah |
| 05:00 | <MikeSmith> | this annevk pushing to his fork, I see |
| 05:07 | <annevk> | MikeSmith: Domenic: so now I made some changes to a branch, how do commit those into the previous commit? |
| 05:07 | <Domenic> | git commit --amend |
| 05:13 | <annevk> | I think I did it |
| 05:13 | <annevk> | But geez this is hard |
| 05:15 | <Domenic> | You get used to it :) |
| 05:16 | <Domenic> | Oh how embarassing, GitHub thinks that the spec's .inc files are PHP. |
| 05:16 | <MikeSmith> | hah |
| 05:17 | <Hixie> | Domenic: what's your e-mail address? |
| 05:17 | <MikeSmith> | hola Hixie |
| 05:18 | <annevk> | Domenic: seems like you still have better merge techniques |
| 05:18 | <Hixie> | hey MikeSmith |
| 05:19 | <annevk> | Domenic: I believe I use your pr bash but it never closes automatically... |
| 05:20 | <annevk> | Hixie: msg'd you Domenic's email, he might be asleep |
| 05:21 | <Domenic> | annevk: the auto-closing is only if you are very obsessive like me and force-push your final version up on to the PR branch. That ensures your commit shas are the same on master and on the PR branch and thus it happens. |
| 05:21 | <Domenic> | I really *should* sleep |
| 05:21 | <Hixie> | he posted here like literally 500ms ago, but i guess he could be asleep typing... |
| 05:21 | <Hixie> | :_P |
| 05:21 | <annevk> | Domenic: I see, I might not worry about that just yet |
| 05:22 | <Hixie> | sent mail about pdf |
| 05:23 | <Domenic> | \o/ |
| 05:23 | <Domenic> | actually sleeping now |
| 05:25 | <Hixie> | ditto |
| 07:08 | <zcorpan> | Domenic: wanna close https://www.w3.org/Bugs/Public/show_bug.cgi?id=23039 ? |
| 07:14 | <MikeSmith> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 seems like a priority, since it's a case where the spec is behind implementation(s), and there seems to be agreement already that the spec will be updated to match what already got implemented |
| 07:14 | <MikeSmith> | annevk: so not sure anybody other than Hixie is brave/foolhardy/patient enough to want to tackle it |
| 07:15 | <annevk> | Been a fair bit of spam in that bug too |
| 07:15 | <MikeSmith> | annevk: yeah, weird spam |
| 07:16 | <MikeSmith> | sorry for not having caught that when it was happening |
| 07:16 | <Ms2ger> | Also, <ruby> |
| 07:16 | <MikeSmith> | zcorpan: looks like Ms2ger did just now close that |
| 07:16 | <MikeSmith> | Ms2ger: what specifically about <ruby>? |
| 07:17 | <MikeSmith> | oh, matching implementations |
| 07:17 | <Ms2ger> | The parsing changes from the w3c fork never made it back, did they? |
| 07:17 | <MikeSmith> | right |
| 07:17 | <MikeSmith> | no, they didn't yet |
| 07:18 | <Ms2ger> | On another note, having the generated spec in a git repo somewhere would be nice for my offline use |
| 07:19 | <Ms2ger> | Though I guess I don't need that often anymore |
| 07:21 | <annevk> | So it basically comes down to defining https://etherpad.mozilla.org/html5-cross-origin-objects |
| 07:21 | <MikeSmith> | Ms2ger: fwiw I've been adding "spec_lags_implementation" in the Whiteboard field, for cases that are such (well, I've only done it for two bugs so far, but it's a start) |
| 07:23 | <MikeSmith> | annevk: you pasted that in from somewhere else? (you didn't write all that up just now..) |
| 07:23 | <annevk> | MikeSmith: that's from that bug |
| 07:23 | MikeSmith | reads |
| 07:23 | <Ms2ger> | I was going to suggest adding a 100-columns lint, but there's about 9000 lines that cross it :) |
| 07:23 | <MikeSmith> | ah those are Hixie's notes |
| 07:23 | <MikeSmith> | Ms2ger: haha |
| 07:25 | MikeSmith | for the first time he can remember, set tw=100 in his vim today when writing a patch |
| 07:25 | <Ms2ger> | annevk, I guess the IDEAS section at the end would be better in an issue |
| 07:27 | <annevk> | Ms2ger: feel free |
| 07:27 | <Ms2ger> | It's a brave new world |
| 07:29 | <MikeSmith> | heh |
| 07:30 | <MikeSmith> | so incidentally looking at https://github.com/whatwg/html/pull/14#commitcomment-12941721 I didn't know GH could thread comments like that |
| 07:30 | <TabAtkins> | Bluh at columns limit, but since most people don't understand how to linebreak properly, I guess wtv |
| 07:30 | <MikeSmith> | ah I see, those are comments from the diff, nm |
| 07:40 | <annevk> | Ms2ger: thank you. I'll leave it open for now to see what Domenic thinks |
| 07:40 | <Ms2ger> | wfm |
| 07:47 | <MikeSmith> | can anybody think of why the <li> element should not be classified as "palpable content"? |
| 07:47 | <MikeSmith> | because the spec currently doesn't classify it as such |
| 07:48 | <MikeSmith> | seems like an oversight |
| 07:51 | <zcorpan> | MikeSmith: why would it be? you can't put it in elements that want palpable content? |
| 07:52 | <MikeSmith> | zcorpan: this gets back to https://www.w3.org/Bugs/Public/show_bug.cgi?id=28728 |
| 07:52 | <MikeSmith> | the spec doesn't actually define "elements that want palpable content" |
| 07:53 | <zcorpan> | MikeSmith: "As a general rule, elements whose content model allows any flow content or phrasing content should have at least one node in its contents that is palpable content and that does not have the hidden attribute specified." |
| 07:53 | <MikeSmith> | instead it defines such elements themselves as "palpable content" |
| 07:54 | <MikeSmith> | zcorpan: "The following elements are palpable content" |
| 07:54 | <zcorpan> | MikeSmith: yes? and any element whose content model allows flow or phrasing wants a palpable child |
| 07:56 | <MikeSmith> | ok yeah |
| 07:56 | <MikeSmith> | will try to make wording for a note to help clarify this |
| 07:57 | <MikeSmith> | because it's not clear now |
| 08:04 | <annevk> | zcorpan: did you see the suggestion to merge <picture> into HTML now that we have a distributed editing model? |
| 08:05 | <annevk> | zcorpan: actually doing it might be a little involved since it requires updating the build script I think, but should be okay |
| 08:05 | <zcorpan> | annevk: yeah, that's fine with me. i think the picture repo contains the entire history of html, so that will need some massaging |
| 08:06 | <zcorpan> | and i'm not competent enough with git to pull that off (i.e. to get a sane history) |
| 08:08 | <annevk> | zcorpan: ooh that does sound tricky |
| 08:08 | <annevk> | zcorpan: I wonder if philipj can help out when he's back |
| 08:30 | <zcorpan> | should we write something on the whatwg blog? |
| 08:35 | <annevk> | zcorpan: we didn't want to make a big deal about it for now |
| 08:37 | <zcorpan> | k |
| 08:54 | <annevk> | Anyone suggestions for how to reword the whatwg/html README about the 100 character wide columns? |
| 08:58 | <MikeSmith> | zcorpan: please take a look at https://github.com/whatwg/html/pull/24 and add comments if you have any |
| 11:21 | <zcorpan> | Domenic: so i wanted the bug-filer link to be available ASAP so the user doesn't have to wait for the document to finish loading before s/he can report a bug |
| 11:22 | <TabAtkins> | zcorpan: And so they can report the spec being slow as a bug? |
| 11:23 | <zcorpan> | sure |
| 12:09 | <MikeSmith> | annevk: will try to think of some good wording |
| 12:11 | <MikeSmith> | annevk: I guess for going forward right now I would be more worried about ending up getting bunches of patches submitted from people who don't actually understand the spec |
| 12:12 | <MikeSmith> | annevk: e.g., the comment at https://github.com/whatwg/html/pull/24#issuecomment-135694902 |
| 12:12 | <MikeSmith> | 「Why is "Text" capitalized?」 |
| 12:14 | <MikeSmith> | so I think the README will eventually need to have wording saying something like, Your patch will have to be rejected if it's not consistent with the technical conventions used in the language in the spec. |
| 12:16 | <MikeSmith> | e.g., "Terms like Text are capitalized and linked to <dfn>s etc. for a reason; you need to read the spec and understand the reasons why it's written the way it is, and why it's necessary for any patch you submit to be written in the same way." |
| 12:16 | <Domenic> | Dammit annevk got all the easy ones I bookmarked last night |
| 12:16 | <MikeSmith> | heh |
| 12:17 | <MikeSmith> | "If the spec words something in certain way, or marks up something in a certain way, always assume it was written that way very intentionally and carefully for a specific purpose." |
| 12:17 | <MikeSmith> | etc. |
| 12:23 | <nox> | annevk: I've noticed some spaces went away in DOM, is that known? |
| 12:24 | <astearns> | does DOM use bikshed? https://github.com/tabatkins/bikeshed/issues/467 |
| 12:24 | <Ms2ger> | Yes |
| 12:27 | <ato> | annevk: Has an “absolute path relative url” been renamed to something else? |
| 12:38 | <Krinkle> | Hm.. how far are source maps on the standards track? I'm trying to figure out whether it's a bug or gap in specification that //# sourceURL in Chrome treats //foo.com/bar.js as relative to (no domain), instead of expanding to http:// or using something like that |
| 12:38 | tantek | notes 4y+2d anniversary of http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces |
| 12:39 | <Krinkle> | especially since it does support absolute urls. |
| 12:40 | <Krinkle> | In the generic handling for it, would be nice not to have to do string manipulation on href values before passing to eval. |
| 12:50 | <Domenic> | Krinkle: last I saw their spec was a google doc that seemed kind of iffy |
| 12:50 | <Krinkle> | yeah |
| 12:50 | <Krinkle> | is that still the state of things? |
| 12:50 | <Krinkle> | Looks like something that's quite widely used now. Time for a spec. |
| 12:51 | <Krinkle> | Though I suppose it's hard to claim because it's not strictly of use within the DOM or HTML categoriers. |
| 12:51 | <Krinkle> | similar how console.log isn't standardised (or did I miss that one?) |
| 12:51 | <Krinkle> | but we could at least put it up somewhere using spec-like formatting, maybe on github pages somewhere as a vendor-maintained spec. |
| 12:52 | <Krinkle> | google doc isn't a good issue tracker :P |
| 12:56 | <smaug____> | I thought there is some draft for console.log |
| 12:56 | <Domenic> | Krinkle: would you like a whatwg/source-maps repo all of your own? |
| 12:57 | <Domenic> | And yeah, we have a couple console spec repos that never got finished |
| 12:57 | <Krinkle> | Aha, that'd be amazing |
| 12:57 | <Krinkle> | i'll have no excuse to finally give in and learn about how to use bikeshed |
| 12:57 | <Domenic> | Sweet :). GitHub username? |
| 12:57 | <Krinkle> | Krinkle |
| 12:58 | <Krinkle> | http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ |
| 12:58 | <Krinkle> | https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?hl=en_US&pli=1&pli=1 |
| 12:59 | <Krinkle> | CC BY-SA so that's doable. |
| 12:59 | <Krinkle> | Though we usually use cc0, right? |
| 13:00 | <Domenic> | Yeah |
| 13:00 | <Domenic> | That's a pretty restrictive license actually |
| 13:00 | <Domenic> | Interesting |
| 13:00 | <Krinkle> | I'll create an issue asking the authors to re-license |
| 13:00 | <Domenic> | Depends on how much text you're reusing directly |
| 13:00 | <Krinkle> | In the new repo? |
| 13:00 | <Domenic> | Yeah seems good |
| 13:01 | <Krinkle> | I don't have massive plans for the spec, so at this point, I do intend to import most of the writing as-is |
| 13:01 | <Ms2ger> | smaug____, yeah, I've seen one or two |
| 13:01 | <Domenic> | Gotcha |
| 13:01 | <Krinkle> | at least to make any changes more explicit as follow-up commits |
| 13:02 | <Krinkle> | Domenic: Can you close the wiki? |
| 13:02 | <Domenic> | For general setup, the easiest thing to do for now will be to work on gh-pages and check in both index.bs source, and index.html output. You can also do fun things with build scripts running on Travis, but that might be yakshaving. |
| 13:02 | <Krinkle> | Yeah |
| 13:02 | <Domenic> | Done. |
| 13:02 | <Krinkle> | And make gh-pages the default branch |
| 13:03 | <Krinkle> | If not already, I don't know |
| 13:03 | <Ms2ger> | There's http://sideshowbarker.github.io/console-spec/ but also something else... |
| 13:03 | <Krinkle> | https://github.com/whatwg/dom is a good example to draw from structure wise? |
| 13:03 | <Domenic> | Krinkle: it appears you need to actually push a gh-pages commit before I can do that |
| 13:03 | <Krinkle> | Ah, okay |
| 13:03 | <Domenic> | And yeah it is |
| 13:03 | <MikeSmith> | Ms2ger: I think terinjokes was working on a real console spec |
| 13:04 | <Ms2ger> | https://github.com/terinjokes/console-spec |
| 13:04 | <Ms2ger> | You should link it |
| 13:11 | <MikeSmith> | I should just redirect it I guess |
| 13:11 | <MikeSmith> | Ms2ger: except I don't see where it's actually published |
| 13:12 | <MikeSmith> | which I remember now is why I didn't link to it already |
| 13:12 | <MikeSmith> | and I don't want to just link the repo |
| 13:12 | <Ms2ger> | The latest rendered version can be viewed at https://terinjokes.github.io/console-spec. |
| 13:12 | MikeSmith | looks |
| 13:13 | <MikeSmith> | so yeah now I also remember there's still almost nothing there |
| 13:14 | <MikeSmith> | so I'd rather really not (re)waste any more time futzing around with linking/redirecting to it until it would actually be useful/rewarding for anybody to spend time doing that |
| 13:14 | <Krinkle> | Hm.. I guess I have to name it index.bs so that it creates index.html |
| 13:15 | <MikeSmith> | in the mean time, http://getfirebug.com/wiki/index.php/Console_API is still a lot more useful to people |
| 13:16 | <MikeSmith> | annevk: see my PR about the 100-character thing, which is the best wording I can manage to come up with |
| 13:16 | <Domenic> | Yeah until we have one console spec to rule them all, let a thousand console specs bloom |
| 13:22 | <MikeSmith> | Domenic: I guess I should actually take time to read through all of https://github.com/erlang/otp/wiki/Writing-good-commit-messages |
| 13:23 | <MikeSmith> | the statements of rationale in that are great |
| 13:23 | <Ms2ger> | FTR, I disagree with no-period-at-end-of-first-sentence |
| 13:26 | <jgraham> | FTR I think that kind of thing is pointless bikeshedding |
| 13:27 | <Ms2ger> | Pointless |
| 13:27 | <Ms2ger> | I see what you did there |
| 13:27 | <jgraham> | It seems that periodically I can make an unintentional pun ;) |
| 13:28 | <Ms2ger> | Ooh, you're on a roll |
| 13:33 | smaug____ | thinks long commit messages are just adding extra noise, and short description + link to the bug is better |
| 13:48 | <Krinkle> | Domenic: Hm.. before I go much further in converting the google doc into markdown/bikeshed, you reckon it'll gain traction? I mean, right now it's managed by Mozilla mostly via the google mailinglist. I could ask there first. |
| 13:50 | <Domenic> | Krinkle: yeah, that is probably a good idea... especially if you aren't planning on investing too much time beyond just converting the doc. If it's just a format change that's not so valuable. |
| 13:50 | <wanderview> | hmm... I guess the html spec repo might be higher traffic than the other repos I watch |
| 13:50 | <Krinkle> | Yeah, they have no obligation to use github forward |
| 13:50 | <Krinkle> | Domenic: But it is something whatwg would want to cover under its umbrella? |
| 13:50 | <Krinkle> | I don't know what authority decides what whatwg/* covers :) |
| 13:51 | <Domenic> | Krinkle: definitely. If we have an active editor :) |
| 13:53 | <Domenic> | Krinkle: but yeah getting buy in from the people currently maintaining it is probably a pretty important step. |
| 13:53 | <Krinkle> | Domenic: Yeah, and we can invite the current editors to become active editors here, right? |
| 13:54 | <Domenic> | Krinkle: for sure! |
| 13:54 | <Krinkle> | Maybe some of them have already participated in whatwg conversations in the past. |
| 13:57 | <Krinkle> | Hm.. seems they prefer "Source Map" as opposed to Source Maps |
| 13:57 | <Krinkle> | makes sense I suppose |
| 13:57 | <Domenic> | Want a rename? |
| 13:57 | <Krinkle> | Yeah |
| 13:58 | <Domenic> | Done |
| 13:58 | <Krinkle> | Thx |
| 14:06 | <Krinkle> | Domenic: Sent, bcc-ed you |
| 14:12 | <nox> | There is no way to distinguish adding an attribute from removing an attribute through mutation records, right? |
| 14:13 | <MikeSmith> | jgraham: given the 50-character-summary git convention, I think using consistent language conventions for the summary is not pointless if the end result is that the commit summaries are consistently shorter rather than consistently longer (e.g., it typically make thems 3-4 characters shorter, by dropping the -ed with one other character before it, along with the period) |
| 14:13 | <smaug____> | nox: how so |
| 14:13 | <nox> | smaug____: Sorry, changing an attribute vs removing an attribute. |
| 14:13 | <smaug____> | nox: if you observe the old value, adding an attribute has null old valu |
| 14:13 | <jgraham> | MikeSmith: The 50 character summary convention is also not all that |
| 14:13 | <nox> | smaug____: Change: smaug____: 'Queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue attribute’s value.' |
| 14:13 | <nox> | Remove: 'Queue a mutation record of "attributes" for element with name attribute’s local name, namespace attribute’s namespace, and oldValue attribute’s value.' |
| 14:14 | <MikeSmith> | jgraham: yeah I know, but it's there |
| 14:14 | <smaug____> | nox: if you remove attribute, you can check .getAttribute what is the new value |
| 14:14 | <smaug____> | and it is null if there is no attribute anymore |
| 14:15 | <jgraham> | MikeSmith: "there" in the sense that some people suggest it and GitHub is annoying at some length that isn't 50 characters (and annoying in a dumb way too; it will replace one character over the limit with three periods) |
| 14:15 | <jgraham> | I tend to agree that the first line should be reasonably short |
| 14:15 | <jgraham> | I don't think you should kill yourself |
| 14:16 | <Ms2ger> | It's actually a unicode ellipsis now |
| 14:17 | <MikeSmith> | jgraham: agreed about "I don't think you should kill yourself". Especially when futzing with the commit summary makes it less clear, or more klunkly |
| 14:17 | <MikeSmith> | we should all just write commit summaries in Chinese |
| 14:18 | <MikeSmith> | you can write an entire book in 50 characters in Chinese |
| 14:20 | <Ms2ger> | I recently learned the Chinese character for "get married" |
| 14:20 | <Ms2ger> | In utf-16, it's 0x5A5A |
| 14:21 | <Ms2ger> | Which happens to be what we use to fill freed memory |
| 14:22 | <nox> | smaug____: That could have changed by the time the mutation record is handled. |
| 14:22 | <nox> | smaug____: In the case of children changes, you still have all the information, even if it changed. |
| 14:22 | <nox> | In the case of attributes, not so much. |
| 14:23 | <smaug____> | nox: when you handle mutation records, you may need to check the latest mutation records |
| 14:23 | <smaug____> | and if you need to be very careful, use takeRecords() |
| 14:24 | <zcorpan> | is botie not working? |
| 14:24 | <jgraham> | botie: Are you broken? |
| 14:24 | <botie> | i don't know, jgraham |
| 14:25 | <nox> | smaug____: Meh, I still find that inconsistent. |
| 14:25 | <jgraham> | zcorpan: Signs are inconclusive |
| 14:25 | <smaug____> | nox: you have all the information with attributes |
| 14:25 | <zcorpan> | it didn't inform me of things it was told afaict |
| 14:25 | <zcorpan> | botie: you're fired |
| 14:25 | <botie> | zcorpan: excuse me? |
| 14:25 | <nox> | smaug____: You couldn't write some sort of "mutation logger" that accurately reflects whatever happened on the tree even if the records aren't handled immediately. |
| 14:25 | <smaug____> | just like you have with children changes |
| 14:26 | <smaug____> | nox: Google has mutation logger |
| 14:26 | <smaug____> | using mutation observer |
| 14:26 | <nox> | No, in children changes, even if removed children are added back to the same parent, you still know they were removed at that point, |
| 14:26 | <smaug____> | oh, you mean that |
| 14:26 | <nox> | with attributes, you may lose the fact that they were removed. |
| 14:26 | <smaug____> | nox: no |
| 14:26 | <nox> | If you remove and add it back, the two mutation records are the same. |
| 14:26 | <smaug____> | nox: the next time attribute is added, the old value is null |
| 14:27 | <nox> | Oh right. So you have to look at all the later records, right? |
| 14:28 | <smaug____> | right |
| 14:38 | <annevk> | ato: yeah, https://url.spec.whatwg.org/#syntax-url-path-absolute |
| 14:39 | <ato> | annevk: Perfect, thank you! |
| 14:39 | <annevk> | nox: Bikeshed changed serialization |
| 14:44 | <annevk> | Domenic: sorry about that, at some point I stopped fixing IDL stuff philipj had filed figuring he might as well fix it itself |
| 14:44 | <annevk> | MikeSmith: thanks for adding that, I think we need to reword the first paragraph now at some point so it makes more sense together, but this is probably good enough for now |
| 14:50 | <TabAtkins> | annevk: Nearly done fixing that! |
| 14:50 | <TabAtkins> | Doing this fiddly crap while in the middle of CSSWG f2f has been way slow |
| 14:50 | <TabAtkins> | Should have taken just, like, a single 2-hour session or something. |
| 15:03 | <annevk> | heh |
| 15:06 | <TabAtkins> | Done now, finally, just cleaning up before commit. |
| 15:07 | <TabAtkins> | Debugging serialization of whitespace is amazingly annoying. |
| 15:10 | <ato> | So is it fine to reference the Annotated ECMAScript reference (es5.github.io) or should I (try to) link directly to ECMA-262? |
| 15:11 | <jgraham> | ato: My suggestion is to link to the most convenient one and let someone else challenge you later if they think it's an actual issue |
| 15:11 | <MikeSmith> | ato: why not reference the HTML version of the ES6 spec? |
| 15:11 | <JonathanNeal> | I saw that <hgroup> was formally removed from w3c’s spec. Is there any movement on an element or markup pattern for subheading elements that do not trigger sectioning? |
| 15:12 | <ato> | jgraham: Makes sense. |
| 15:12 | <ato> | MikeSmith: Is that a thing now? |
| 15:12 | <Ms2ger> | JonathanNeal, it was still in the canonical spec last time I checked |
| 15:12 | <JonathanNeal> | Ms2ger: http://www.w3.org/TR/html5/obsolete.html ? |
| 15:13 | <Ms2ger> | That document is particularly dry science fiction |
| 15:13 | <Ms2ger> | https://html.spec.whatwg.org/multipage/#the-hgroup-element |
| 15:13 | <MikeSmith> | ato: http://www.ecma-international.org/ecma-262/6.0/index.html |
| 15:13 | <MikeSmith> | jorendorff produced that |
| 15:14 | <ato> | MikeSmith: So we’re still referencing 5.1 but we should probably upgrade to 6.0. |
| 15:14 | <jorendorff> | yes for sure. |
| 15:15 | <MikeSmith> | JonathanNeal: no there is not any such movement, nor would I guess there is likely to ever be much. Few people care about it very much, and for the ones that do, they can still safely just just <hgroup> |
| 15:15 | <JonathanNeal> | Sad times at Ridgemont High. :| |
| 15:16 | <MikeSmith> | to me on the sadness scale, lack of a perfect way to mark up subheading doesn't even register |
| 15:16 | <darobin> | that's... sad |
| 15:17 | <MikeSmith> | heh |
| 15:17 | <MikeSmith> | lots of bigger fish to fry |
| 15:18 | <MikeSmith> | like when jesus made all those fishes |
| 15:18 | <Ms2ger> | darobin, the w3c fork? Yeah ;) |
| 15:18 | <MikeSmith> | except the web platform has a jesus that doesn't stop making fishes |
| 15:18 | <darobin> | lol :) |
| 15:18 | <MikeSmith> | we have a jesus who's like the sorcerer's apprentice of fish-making |
| 15:19 | <JonathanNeal> | and subheadings apparently do not inherit the kingdom. |
| 15:19 | <MikeSmith> | bingo |
| 15:20 | <MikeSmith> | JonathanNeal the Baptist, voice crying in the wilderness |
| 15:20 | <MikeSmith> | eating grasshoppers and hallucinating |
| 15:21 | <annevk> | ato: do you need to reference JavaScript? |
| 15:21 | <annevk> | ato: often standards just need to reference IDL |
| 15:22 | <jgraham> | annevk: WebDriver isn't defining IDL interfaces |
| 15:23 | <jgraham> | It wants to actually inject and execute js |
| 15:23 | <annevk> | Ah, I was wondering if it was the same standard you were working on |
| 15:23 | <ato> | annevk: WebDriver is creating an execution environment for scripts to allow an out-of-process program to inject code into the content space. |
| 15:23 | <ato> | jgraham: We have one IDL! |
| 15:23 | <annevk> | Though that does very much sound like a callback-based system which IDL does support |
| 15:24 | <annevk> | Coupled with queueing tasks et al |
| 15:25 | <annevk> | Woohoo, <400 legacy open bugs |
| 15:25 | <jgraham> | If it is describable using IDL it isn't obvious to me at least |
| 15:25 | <JonathanNeal> | MikeSmith: Or I could go the other direction. http://i.imgur.com/JQkHbHV.png |
| 15:27 | <jgraham> | annevk: https://w3c.github.io/webdriver/webdriver-spec.html#dfn-execute-a-function-body and surrounding parts, if you want to look |
| 15:28 | <annevk> | jgraham: that looks fairly similar to what setTimeout needs to do |
| 15:28 | <MikeSmith> | JonathanNeal: heh |
| 15:29 | <annevk> | jgraham: but admittedly all of the callback-based stuff has some holes and could use tightening |
| 15:34 | <miketaylr> | zcorpan: hey, yeah so compat standard. the plan is for gecko to implement and match (for the most part) what edge has implemented as well |
| 15:34 | <jgraham> | annevk: setTimeout seems to reference ECMA262 directly as well |
| 15:34 | <jgraham> | Generally I copied these parts from setTimeout and event handlers in HTML |
| 15:35 | <zcorpan> | miketaylr: ok. i didn't know edge had implemented WebKitMatrix etc |
| 15:35 | <miketaylr> | zcorpan: yeah |
| 15:35 | <miketaylr> | zcorpan: there's a gdoc linked from https://bugzilla.mozilla.org/show_bug.cgi?id=1170774#c0 that jacob rossi sent me |
| 15:35 | <zcorpan> | possibly we can fold it into the geometry spec at some point |
| 15:35 | <miketaylr> | webkit things that edge implements |
| 15:36 | <miketaylr> | sgtm |
| 15:37 | <zcorpan> | miketaylr: so WebKitPoint was removed from blink |
| 15:38 | <miketaylr> | good to know zcorpan |
| 15:38 | <miketaylr> | we haven't found any sites that break for us related to WebKitPoint |
| 15:38 | <miketaylr> | so it's not a priority for us |
| 15:38 | <miketaylr> | (which doesn't mean they don't exist) |
| 15:39 | <zcorpan> | https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/pIbpN_8Lqpg/tp9f71GsslIJ |
| 15:39 | <miketaylr> | zcorpan: https://wiki.mozilla.org/Compatibility/Mobile/Non_Standard_Compatibility is a better roadmap for what the compat spec will have, rather than that gdoc |
| 15:39 | <miketaylr> | at least, to begin with |
| 15:40 | miketaylr | needs to re-subscribe to blink-dev |
| 15:40 | <zcorpan> | miketaylr: can you link to that in the spec's introduction or so? |
| 15:40 | <miketaylr> | zcorpan: yeah, planning on spending a few hours editing this afternoon |
| 15:41 | <zcorpan> | k cool |
| 16:07 | <TabAtkins> | All right, Houdini is switching over to using GH exclusively for discussion. |
| 16:07 | <annevk> | MikeSmith: about hgroup, what about https://www.w3.org/Bugs/Public/show_bug.cgi?id=28077? |
| 16:07 | <annevk> | TabAtkins: no more F2F? |
| 16:09 | Krinkle | fears the days of mailing lists are over. |
| 16:09 | <Krinkle> | :O |
| 16:09 | <TabAtkins> | annevk: Hahaha, still f2f |
| 16:09 | <TabAtkins> | but mailling list is reserved just for pinging everyone for a wide review or something |
| 16:10 | <TabAtkins> | If this works reasonably well, we'll switch CSS over to it, too. |
| 16:12 | <Ms2ger> | Uhuh |
| 16:25 | <MikeSmith> | annevk: I think that bug should probably just be closed as wontfix, because there's no spec bug and IMHO not even any note needed |
| 16:26 | <annevk> | MikeSmith: does the validator complain about hgroup? |
| 16:26 | <MikeSmith> | The default validator code doesn't emit any error for hgroup. Only the W3C instance of the checker does |
| 16:27 | <MikeSmith> | if soembody else downloads the checker and runs it, they will not get errors about hgroup |
| 16:28 | <annevk> | MikeSmith: okay, resolved WONTFIX per your advice |
| 16:28 | <MikeSmith> | k |
| 16:28 | <annevk> | forgot to include ™ :-/ |
| 16:29 | <MikeSmith> | contributor⊙wo always have the option of re-opening the bug if not satisfied with the resolution, so no worries there! |
| 16:30 | <ccardona_work> | Top of tha morning/afternoon/evening WHATWG crew o/ |
| 16:30 | <MikeSmith> | hey ccardona_work |
| 16:31 | <ccardona_work> | hey MikeSmith ✌🏽 |
| 16:31 | <MikeSmith> | oh shit just got real, annevk pushed "Deprecate <keygen> and appcache" |
| 16:34 | <ccardona_work> | MikeSmith: Out of curiosity how long have you lived in Japan (if you don’t mind me asking) |
| 16:34 | <ccardona_work> | were you ever in the bay area? |
| 16:35 | <annevk> | TabAtkins: could you evaluate https://www.w3.org/Bugs/Public/show_bug.cgi?id=17632 please? |
| 16:36 | <MikeSmith> | ccardona_work: I've been in Japan for 14 years. Before that the closest I lived to the bay area was one year in Santa Cruz |
| 16:37 | <MikeSmith> | ccardona_work: I lived near the "other" South Bay, in LA county, for quite a few years (Torrance, Hawthorne, how of the Beach Boys) |
| 16:38 | <MikeSmith> | ccardona_work: I lived in Santa Barbara for year as well (added for the sake of completeness in cataloging my California experiences) |
| 16:40 | <jgraham> | ccardona_work: MikeSmith is actually Brian Wilson in disguise |
| 16:41 | <jgraham> | The person making the public appearance as "Brian Wilson" is actually a not-very-convincing automaton |
| 16:41 | <MikeSmith> | heh. I'm trying to get as much psychedelics as he did. I still have a ways to go to catch up |
| 16:42 | <MikeSmith> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28197#c2 should be resolved I think |
| 16:44 | <annevk> | MikeSmith: ta, done |
| 16:44 | <ccardona_work> | MikeSmith: wow 14 years in Japan. That’s epic. Yes I lived in Santa Cruz as well. That’s where my son was born 7 years ago. I also spent 3 months there about 5 months ago as I took a mini break from SF when transitioning out of a relationship w/ my ex-wife. |
| 16:45 | <ccardona_work> | pretty funny regarding the psycadelics. ha 😲 |
| 17:05 | <annevk> | MikeSmith: going forward, please resolve as you see fit and let this channel know |
| 17:05 | <annevk> | MikeSmith: that seems like it would get sufficient peer review |
| 17:05 | <MikeSmith> | annevk: OK |
| 17:05 | <MikeSmith> | will do so |
| 17:06 | <annevk> | seems easier and I'll get less email |
| 17:06 | <MikeSmith> | indeed |
| 17:10 | <frewsxcv> | should Object.getOwnPropertyNames ever iterate through the 'supported property names'? (as defined here: https://heycam.github.io/webidl/#dfn-supported-property-names) |
| 17:10 | <Ms2ger> | Why wouldn't it? |
| 17:10 | <frewsxcv> | well, i think it does, but i'm wondering where that is defined in the spec |
| 17:11 | <Ms2ger> | https://heycam.github.io/webidl/#property-enumeration I guess |
| 17:11 | <Ms2ger> | We need to upgrade idl to es6 |
| 17:11 | <Ms2ger> | Now if heycam could just push it under the whatwg umbrella... :) |
| 17:12 | <frewsxcv> | like, I understand the ECMAScript spec specifies the getOwnPropertyNames function and the [[OwnPropertyKeys]] trap, I'm just wondering if those are referenced somewhere in a w3c or whatwg spec somewhere to iterate through the 'supported property names' |
| 17:13 | <frewsxcv> | the webidl spec hosted on heycam's github doesn't even mention [[OwnPropertyKeys]] |
| 17:13 | annevk | has a case of deja vu |
| 17:13 | frewsxcv | is just sanity checking |
| 17:13 | <Ms2ger> | Indeed, and it should |
| 17:30 | <annevk> | Ms2ger: if he did, would you fix all the bugs? |
| 17:36 | <Ms2ger> | I would fix some of the rhings |
| 17:36 | <Ms2ger> | things |
| 17:40 | <MikeSmith> | wontfixed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28296 (a minor editorial clarification thing that's not needed, and OP didn't understand the parsing behavior and DOM for the case) |
| 17:45 | <Domenic> | MikeSmith: wrong link I think |
| 17:46 | <MikeSmith> | oofs yeah |
| 17:46 | <MikeSmith> | hang on |
| 17:46 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=28323 is the one I had meant to cite |
| 17:48 | <Domenic> | MikeSmith: can I get bugmail for all HTML bugs? Can't find a preference that easily. |
| 17:52 | <MikeSmith> | Domenic: I think you can't, but short of that you can add a watch for Hixie, and that will get you them (as well as some WebApps bugs too though) |
| 17:52 | <Domenic> | MikeSmith: I'll give that a shot, should be fine. I think I'll start getting 3 mails per webapps bug then... |
| 17:53 | <MikeSmith> | yeah I gets dupes for a lot of bugs |
| 17:53 | <MikeSmith> | will be glad to cut down on that some after we close the existing HTML ones |
| 17:54 | <MikeSmith> | ...and replace it with a flood of GH issue notifications! |
| 18:22 | <MikeSmith> | Domenic: about Text vs text, it seems to me that the spec does actually use capital <code>Text</code> references throughout consistently when it's referring to the concept of text nodes |
| 18:22 | <MikeSmith> | that case you cite seems like an exception that maybe oughtta be changed |
| 18:23 | <Domenic> | MikeSmith: right. Text = https://html.spec.whatwg.org/#text; text = https://html.spec.whatwg.org/#text-content |
| 18:23 | <MikeSmith> | but if you think I should lowercase it here, I will |
| 18:23 | <Domenic> | I don't think so |
| 18:23 | <MikeSmith> | ah |
| 18:23 | <Domenic> | "text" lowercase is about the content model, which I think is what you're talking about |
| 18:23 | MikeSmith | re-looks |
| 18:24 | <MikeSmith> | ah yeah |
| 18:24 | <MikeSmith> | I missed the distinction |
| 18:24 | <MikeSmith> | will change it |
| 18:44 | <Domenic> | Still pretty surprised that the build system is holding up tbh :P |
| 18:44 | <Domenic> | So many moving parts... |
| 19:35 | <MikeSmith> | speak of the devil |
| 19:35 | <MikeSmith> | I am just now checking out the build tools |
| 19:36 | <Domenic> | watti needs a readme |
| 19:36 | <Domenic> | I'll do that |
| 19:45 | <Domenic> | Done https://github.com/whatwg/wattsi |
| 19:45 | MikeSmith | reads |
| 19:46 | <MikeSmith> | nice |
| 19:47 | <MikeSmith> | I was having problems trying to run the wattsi build with fpc v2.6 |
| 19:47 | MikeSmith | grabs v3 |
| 19:51 | <MikeSmith> | https://nondante.files.wordpress.com/2011/08/larsonhellaccordian.png |
| 19:52 | <MikeSmith> | except in the bottom part, it's Hixie saying, Welcome to the WHATWG, here's your Free Pascal |
| 20:02 | <MikeSmith> | "htmlparser.pas(336,42) Error: Data element too large" 😢 |
| 20:09 | <Domenic> | hmm I haven't seen that one... |
| 20:38 | <MikeSmith> | this is on OSX |
| 20:39 | <MikeSmith> | think I will just switch to trying in my linux server instead |
