| 00:41 | <jgraham> | nikkibee: I think it updates whenever there are issues found, but annevk will know more |
| 02:56 | <annevk> | What jgraham said is correct nikkibee, coupled with me finding time |
| 02:57 | <annevk> | That or someone submitting a PR, though that still requires review |
| 03:33 | <annevk> | I wanted to give a super short introduction to some of the platform team tomorrow as to how/why they can get involved in standards: https://html5.org/temp/whatwg.html |
| 03:34 | <annevk> | Overnight feedback welcome, I have another 11h minus sleep and breakfast to make adjustments |
| 03:35 | <annevk> | I guess I should probably mention the rule of two implementations and tests in there somehow |
| 03:37 | <annevk> | Done |
| 03:40 | <smaug____> | as someone not doing any development in github, showing just basic reviewing workflow and such might be good |
| 03:40 | <nikkibee> | annevk: alright, I did notice that when new updates are made, it's noted in multiple places, so I'll just keep an eye on that. and I can see the additions easily on github |
| 03:41 | <annevk> | nikkibee: yeah either subscribe on GitHub or follow https://twitter.com/fetchstandard |
| 03:41 | <annevk> | nikkibee: that's the state of the art |
| 03:41 | <nikkibee> | yep, I'm following the account |
| 03:41 | <annevk> | smaug____: that might be a tad hard within the five minutes I have |
| 03:41 | <nikkibee> | I was wondering if there's more meta level discussion available is all |
| 03:42 | <annevk> | smaug____: happy to have a longer session at some later point though |
| 03:42 | <smaug____> | ah |
| 03:42 | smaug____ | just doesn't know if the spec source should follow some coding style rules etc |
| 03:42 | <annevk> | nikkibee: not sure what you mean by that, GitHub and sometimes certain mailing lists is all there is |
| 03:43 | <annevk> | nikkibee: we've had some in person discussion, but not a whole lot |
| 03:43 | <annevk> | smaug____: ah yes, that should be written in most of the README files these days |
| 03:43 | <nikkibee> | well I mean like, where I can figure out what changes were made for what reason, and see what's upcoming |
| 03:43 | <annevk> | smaug____: though it needs to be improved, we're a software project in the very early stages still :/ |
| 03:44 | <nikkibee> | like we found that the first fetch entry has two new steps added to the start since the fetch code for servo was last worked on- I'd like knowing where to go to see what went into that |
| 03:44 | <annevk> | nikkibee: GitHub issues, mostly, and if you cannot figure it out you might have found a bug |
| 03:44 | <nikkibee> | alright, I'll see it as a point to gain more experience with navigating github |
| 03:46 | <annevk> | you're also welcome to ask here and I can probably dig it up quite easily though availability is not great this week |
| 03:46 | <nikkibee> | thanks! |
| 03:47 | <nikkibee> | if I really can't turn anything up on my own I'll ask here, but knowing it's all in the github issues helps a lot. I reckon once I get a handle on searching through it it'll be a lot easier to do again |
| 04:18 | <MikeSmith> | fyi https://lists.w3.org/Archives/Public/public-html/2015Dec/0017.html proposes adding a new attribute named "rels" |
| 04:18 | <MikeSmith> | 「The syntax of the "rels" attribute value is a whitespaceseparated sequence of whitespace separated pairs of link relationsand URL values.」 |
| 04:19 | <MikeSmith> | example: <a href="software.tar.gz" rels="signature software.tar.gz.sig">software</a> |
| 04:20 | <MikeSmith> | Internet-draft from Sean Palmer |
| 04:23 | <MikeSmith> | I wonder if he knows about subresource integrity |
| 04:38 | <MikeSmith> | ah I see now he sent it to the whatwg list as well |
| 08:55 | <mkwst> | MikeSmith: Thanks for forwarding that on to WebAppSec. I expect the use case to be covered by SRI2; we discussed signature-based integrity validation briefly at TPAC, but I don't think any of the SRI editors have done anything concrete about it. |
| 08:55 | <mkwst> | I don't think the PGP-based signature that Sean wants is a good idea, but something more generic would indeed be valuable. |
| 08:58 | <mkwst> | The notes here are muddled, but you get the idea: http://www.w3.org/2015/10/28-webappsec-minutes#item07 |
| 09:48 | <yoav> | annevk: if you're around I'd appreciate if you could take a look at https://github.com/whatwg/dom/pull/123 |
| 11:28 | <annevk> | yoav: can prolly look today, on first glance, supports() needs to be a two step algorithm |
| 11:29 | <annevk> | yoav: the first step assigns the return value to a variable and rethrows any exceptions, in line with text elsewhere in the standard |
| 11:30 | <annevk> | yoav: the second step would simply return the variable |
| 12:06 | <yoav> | annevk: OK, I think I addressed that |
| 12:34 | <annevk> | yoav: you want to use "Let" since you're initializing the variable and the second step needs to end with a period |
| 12:34 | <yoav> | ok |
| 12:36 | <yoav> | fixed |
| 12:37 | <annevk> | yoav: seems the "throw TypeError" is also not consistent with throwing a TypeError elsewhere |
| 12:38 | <annevk> | yoav: which also makes me suspect the addition to the ignored terms list |
| 12:39 | <yoav> | Yeah, zcorpan suggested that this would be the correct way, but I could change that to the way it is done elsewhere if you prefer |
| 12:39 | <annevk> | yoav: also, thinking about it more, what has associated supported tokens, the DOMTokenList or the attribute local name? |
| 12:40 | <annevk> | yoav: I think it needs to be the DOMTokenList instance |
| 12:40 | <annevk> | yoav: I would prefer internal consistency first I think and then maybe a separate follow up |
| 12:41 | <annevk> | yoav: is the "correct way" also without "a" inbetween? I wonder if that's defined anywhere |
| 12:41 | <Domenic> | Web IDL says to use an "a" |
| 12:41 | <yoav> | he was referring to the {{TypeError}} rather than <code>TypeError</code> |
| 12:41 | <yoav> | the "a" was my omission |
| 12:46 | <yoav> | so should it be "If the associated <a>attribute</a>'s <a for=Attr>DOMTokenList</a> " instead of "If the associated <a>attribute</a>'s <a for=Attr>local name</a> "? |
| 12:54 | <MikeSmith> | mkwst: thanks yeah I vaguely recalled hearing there'd been some discussion of signature-based SRI |
| 12:57 | <yoav> | annevk: or is the attribute itself the DOMTokenList instance? Any example on how to refer to the instance? |
| 14:22 | <annevk> | You should just refer to the DOMTokenList, which is the context object, afaict |
| 18:24 | <annevk> | The attribute is not the instance... |
| 18:25 | <annevk> | The instance is the "context object" |
| 18:25 | <annevk> | I thought I mentioned this, but it seems that was not transmitted or something :/ Downsides of IRCCloud already showing |
| 20:02 | <smaug____> | ++aklein (for unshipping Object.observe) |
| 20:38 | <annevk> | oooh yes |
| 20:38 | <annevk> | excellent |
| 21:15 | <TabAtkins> | By the by, I consider "-foo-min-bar" to be the correct prefixed variant of the "min-bar" media feature, and think "min--foo-bar" is bizarre and don't understand why anyone would do that. |
| 22:24 | <jsbell> | wanderview: https://critic.hoppipolla.co.uk/r/6044 and https://critic.hoppipolla.co.uk/r/6045 may be of interest to you |
| 22:25 | <wanderview> | jsbell: thanks! on a work trip at the moment, but will try to look next week |
| 22:44 | <Ms2ger> | annevk, ping |
| 22:48 | <annevk> | Ms2ger: yo |
| 22:49 | <Ms2ger> | annevk, https://github.com/whatwg/fetch/issues/171 is confusing us over in #servo |
| 22:49 | <annevk> | Ms2ger: that looks like a case that wasn't considered |
| 22:50 | <Ms2ger> | annevk, weird thing is that it's considered in some steps and not others |
| 22:50 | <annevk> | Ms2ger: yeah, I should probably have some macro for this or a better model |
| 22:51 | <annevk> | Ms2ger: the filtering seemed pretty great initially but now I need to poke holes here and there it's getting ugly :-( |
| 23:00 | <annevk> | Ms2ger: good ideas appreciated btw, but you know that |
| 23:02 | <Ms2ger> | annevk, yeah, I never really read the fetch spec entirely, so I have no good mental model at this point, unfortunately |