| 05:46 | <MikeSmith> | JakeA: I don’t attend the payment-apps meeting normally, so not sure if they were meeting this week or not |
| 06:35 | <annevk> | tobie: oooh you did it |
| 06:35 | <annevk> | tobie: congrats! |
| 06:35 | <annevk> | tobie: and thanks for fast-forwarding the commits rather than merge commits |
| 06:37 | <tobie> | annevk: yeah, didn't want to leave all other bikeshed users blocked until we shipped for too long. |
| 06:38 | <annevk> | tobie: seems the last fixup commit isn't making use of bikeshed functionality (<a lt>) but I guess in general things are okay |
| 06:39 | <tobie> | Oh, I have to look at that. Where is this? |
| 06:41 | <annevk> | tobie: last commit: https://github.com/heycam/webidl/commits |
| 06:43 | <tobie> | Oh. I hadn't seen it. |
| 06:43 | <tobie> | I guess folks need to be schooled on the bikeshed way, now. |
| 06:44 | <annevk> | tobie: seems https://github.com/heycam/webidl/issues/161 also wasn't closed as a result of fixing that |
| 06:44 | <annevk> | Yeah |
| 06:45 | <tobie> | Mmm. I'm much more worried about a chunk of an algorithm disappearing, tbh. |
| 06:48 | <annevk> | tobie: well, yes |
| 06:49 | <tobie> | I *had* to cut some corners, but this is really surprising. |
| 06:54 | <tobie> | annevk: oh, it's this: https://github.com/heycam/webidl/blob/06bae58f/index.xml#L7667 |
| 06:54 | <tobie> | I can see how that botched some of my regexes. |
| 07:01 | <tobie> | OK, so I found three others places where the same thing happened. :( |
| 07:02 | <tobie> | Will fix. Strongly hopping it's not the beginning of an avalanche or similar issues. :( |
| 07:04 | <annevk> | tobie: I thought you used XSLT to generate bikeshed? |
| 07:04 | <annevk> | tobie: XSLT has regular expressions? |
| 07:06 | <tobie> | annevk: I did. |
| 07:07 | <tobie> | annevk: but had to add a line by line post-processor to cleanup the indentation levels and markdownify the source, as XSLT's output can't really deal with this |
| 07:08 | <tobie> | I'm not sure which of the two screwed those up. |
| 08:04 | <tobie> | annevk: alright fixed those: https://github.com/heycam/webidl/pull/163 |
| 08:05 | <tobie> | annevk: seems like a relatively well contained issue. |
| 08:05 | <annevk> | Ah good |
| 08:06 | <tobie> | annevk: combination of nested references and < > and related entities |
| 08:07 | <tobie> | not sure where in the pipeline this broke and not sure it's really worth investigating either. |
| 08:08 | <tobie> | heycam: what's your merging process for WebIDL? |
| 08:08 | <tobie> | heycam: do you self-merge small fixes like these or get a second pair of eyes on them before you do? |
| 08:14 | <heycam> | tobie: hi! I tend to commit my own changes without going through PRs unless I specifically want review from someone |
| 08:15 | <tobie> | heycam: oh, nice. Less process. \o/ |
| 08:16 | <heycam> | heh yes |
| 08:16 | <heycam> | use your discretion I suppose |
| 08:16 | <heycam> | I think bz errs on the side of getting reviews |
| 08:23 | <tobie> | heycam: Well, as long as everyone feels confortable telling someone else they screwed up and need to revert, I'm all for favouring speed of protocol. |
| 08:25 | <tobie> | speed OVER protocol. |
| 08:27 | <tobie> | heycam: will you be at TPAC? |
| 08:27 | <heycam> | tobie: no, won't be there |
| 08:27 | <tobie> | :( |
| 08:27 | <heycam> | :( |
| 08:28 | <annevk> | heycam: not cool |
| 08:29 | Ms2ger | is not cool either |
| 08:30 | <annevk> | Ms2ger: dude |
| 08:31 | <annevk> | Well if it's going to be like this we might have to setup something else at some point |
| 08:31 | <MikeSmith> | yes |
| 08:31 | <MikeSmith> | we really should anyway |
| 08:32 | <Ms2ger> | Do one in Brussels and I'll consider it :) |
| 08:33 | MikeSmith | had forgotten that Ms2ger’s parole requirements prevent him for being able to travel outside Brussels |
| 08:47 | <tobie> | MikeSmith: I'm going, btw. :) |
| 08:56 | <MikeSmith> | tobie: excellent |
| 08:57 | <MikeSmith> | tobie: so given that we should definitely schedule something concrete for WebIDL discussion |
| 08:57 | <tobie> | Yeah, I pinged Yves. |
| 08:57 | <MikeSmith> | OK |
| 08:58 | <tobie> | I have no idea how the super group is organized these days |
| 08:58 | <MikeSmith> | we can get a Tech Plenary breakout session of course, but that’d be just one hour |
| 08:58 | <MikeSmith> | oh |
| 08:59 | <MikeSmith> | yeah I forgot this was in the Web Platform WG |
| 09:00 | <mkwst> | Or, you know, folks could just go get coffee somewhere together. |
| 09:00 | <tobie> | MikeSmith: I was thinking of: |
| 09:00 | <tobie> | 1) short WPWG session just to update people on current status and plans |
| 09:00 | <tobie> | 2) breakout session to gather requirements for future work |
| 09:00 | <tobie> | 3) eventually ad-hoc meeting to get actual work done |
| 09:01 | <MikeSmith> | sounds good |
| 09:01 | <tobie> | mkwst: yeah, see 3) above (so we get a room) |
| 09:02 | <MikeSmith> | mkwst: yeah agree and sometimes a lot more gets done in informal get-togethers between formal meetings |
| 09:02 | <tobie> | "sometimes" |
| 09:02 | <MikeSmith> | heh |
| 09:02 | <MikeSmith> | I was being nice :) |
| 09:03 | <MikeSmith> | tobie: but what do you mean “we get a room”? |
| 09:03 | <tobie> | MikeSmith: last time I looked, we could claim slots in rooms for ad-hoc meetings |
| 09:03 | <MikeSmith> | oh |
| 09:03 | <tobie> | MikeSmith: think we did that for the sensor work last time |
| 09:04 | <MikeSmith> | OK |
| 09:04 | <tobie> | booked half a day or so |
| 09:05 | <tobie> | man the distinction between the bindings and the WebIDL stuff in there is just hard to grok in some places. |
| 09:05 | <MikeSmith> | that is why we should erase that distinction as much as we can |
| 09:06 | <tobie> | How's an ES throw different from a WebIDL one? |
| 09:06 | tobie | cries |
| 09:07 | <Ms2ger> | tobie, what do you mean? |
| 09:08 | <tobie> | Ms2ger: http://heycam.github.io/webidl/#dfn-throw vs http://heycam.github.io/webidl/#ecmascript-throw |
| 09:10 | <Ms2ger> | I think it would be fine to redirect ecmascript-throw to dfn-throw |
| 09:17 | <annevk> | tobie: the difference is that IDL still tries to be language-agnostic |
| 09:18 | <Ms2ger> | Kinda sorta |
| 09:18 | <tobie> | "The meaning of each simple exception matches its corresponding Error object in the ECMAScript specification." |
| 09:18 | <annevk> | tobie: I think we should give up on that to some extent |
| 09:18 | <annevk> | We might actually short circuit some of IDL with wasm, but that should just become part of the IDL spec |
| 09:19 | <annevk> | (E.g., a bunch of type coercion would no longer be needed.) |
| 09:19 | <tobie> | Oh interesting |
| 09:20 | <tobie> | Yeah, the extra level of indirection added by this near 1:1 mirroring makes things really complicated |
| 09:22 | <tobie> | You have a {{SyntaxError}} IDL interface which has a SyntaxError name and maps the ES SyntaxError object. |
| 09:22 | <tobie> | I'm not sure we're getting anything out of that beyond technical purity. |
| 09:23 | <annevk> | I think it does make sense to have an IDL entry-point for all these things |
| 09:23 | <annevk> | So if I define an IDL-algorithm, I use IDL-throw in it and IDL defines the implementation of that |
| 09:24 | <annevk> | Basically IDL should define the language all spec-algorithms are written in |
| 09:24 | <annevk> | How to do loops, comparisons, etc. |
| 09:24 | <annevk> | A major outstanding issue is promise integration |
| 09:25 | <annevk> | There's the promises guide, but that really needs to be part of IDL |
| 09:25 | <annevk> | And once integrated IDL needs to really explain things in terms of ECMAScript, not hand-wavy language |
| 09:27 | <tobie> | How much of that mean pulling in thing s described in HTML? |
| 09:27 | <tobie> | (e.g. the infamous "in parallel" dfn everybody references) |
| 09:30 | <annevk> | tobie: that might need to happen at some point |
| 09:30 | <annevk> | tobie: baby steps |
| 09:31 | <annevk> | tobie: but yeah, "in parallel" is a very special thing only available to IDL-algorithms and not really to ECMAScript |
| 09:32 | <tobie> | annevk: oh yeah. Just trying to build a mental model of how the different pieces fit together so I can make educated decisions down the line. |
| 09:33 | <annevk> | tobie: but IDL / HTML / DOM are intertwined |
| 09:33 | <annevk> | tobie: Hixie would argue they should all be the same thing |
| 09:34 | <tobie> | annevk: yeah, I'm just trying to figure out what the nodes are. |
| 09:34 | <annevk> | tobie: points of overlap? |
| 09:35 | <tobie> | yeah, I'm not exactly sure how to call these things yet. :) |
| 09:35 | <annevk> | Let's not reuse node |
| 09:35 | <annevk> | 😛 |
| 09:36 | <tobie> | heh |
| 09:36 | tobie | was thinking graph-theory node, fwiw. |
| 09:37 | <annevk> | Fair |
| 09:37 | <annevk> | tobie: next step is sorting through the bugs, right? |
| 09:39 | <JakeA> | annevk: if I do a window.open(url), does this create a fetch client for about:blank, then create another for the navigation to url? |
| 09:39 | <JakeA> | Or does the about:blank page use the client of the opener? |
| 09:40 | <tobie> | annevk: There's a bunch of things |
| 09:41 | <tobie> | annevk: removing the inline issues is one. |
| 09:41 | <annevk> | JakeA: opener I think, but not defined yet |
| 09:41 | <tobie> | annevk: triaging bugzilla is the second |
| 09:41 | <annevk> | JakeA: and yeah, new one when you navigate |
| 09:41 | <JakeA> | annevk: ta. This matters for the reserved/target clientid stuff |
| 09:42 | <annevk> | JakeA: <object> and <embed> are especially hairy |
| 09:42 | <tobie> | annevk: there are still parts of the spec that need fixing (bugs that were there before the conversion but whic are now a lot easier to spot) |
| 09:42 | <JakeA> | yeah, that's why we skip them with SW :D |
| 09:42 | <JakeA> | appcache does crazy dancing |
| 09:42 | <tobie> | annevk: lots of low hanging fruits also (small issues, etc.) |
| 09:43 | <annevk> | JakeA: for <object data> and <embed src> you use the fetch group of the element, but then when you pass them to navigate (the response) they create a new fetch group and their own fetches get moved |
| 09:43 | <annevk> | JakeA: there's notes in an issue somewhere, I haven't really defined it yet |
| 09:43 | <annevk> | JakeA: we either need to drop AppCache fast or just embrace that it is there and actually make it a functional part of the platform |
| 09:44 | <annevk> | JakeA: keeping it in its current state is not helping anyone |
| 09:44 | <JakeA> | annevk: can this be simplified if the object has type text/html and typemustmatch? We *know* that's iframe-like at that point |
| 09:44 | <annevk> | JakeA: that wouldn't really simplify the existing code |
| 09:44 | <annevk> | JakeA: that would just add a branch, with more chance for bugs |
| 09:46 | <JakeA> | annevk: hm, I was hoping we could use typemustmatch to send <object> requests through SW |
| 09:46 | <JakeA> | but I'm not that bothered |
| 09:46 | <JakeA> | the only worthwhile thing it's used for is SVG |
| 09:48 | <annevk> | JakeA: oh we could add it, just saying it's not a simplification |
| 09:48 | <JakeA> | fair |
| 09:48 | <annevk> | JakeA: and if we do add it, I would appreciate if whoever wants to add it first cleans up how the elements are defined today, since they're known to be wrong |
| 09:48 | <annevk> | JakeA: it's a rather messy area |
| 09:49 | <annevk> | tobie: sounds really good to get those cleaned up first indeed |
| 09:49 | <annevk> | tobie: will also help with getting yourself familiarized |
| 09:49 | <tobie> | annevk: yeah, I'm getting there |
| 09:49 | <tobie> | annevk: albeit slowly |
| 09:57 | <tobie> | What's the difference between http://heycam.github.io/webidl/#dfn-dictionary and http://heycam.github.io/webidl/#idl-dictionary? |
| 09:59 | <tobie> | I'm also not sure I understand what this means: "There is no way to represent a constant dictionary value in IDL." |
| 10:04 | <tobie> | Oh, never mind the former. I now get it. |
| 10:19 | <annevk> | tobie: IDL has support for constants |
| 10:19 | <annevk> | tobie: I think that's just saying a dictionary value is not a valid value for it |
| 10:19 | <tobie> | really? |
| 10:20 | <tobie> | annevk: that seems super redundant given acceptable values for consts are whitelisted somewhere else |
| 10:20 | <tobie> | annevk: the sequence type is defined as an interface in the type list (and now my head hurts) |
| 10:21 | <annevk> | tobie: it's not a normative statement, so yeah, it's redundant |
| 10:22 | <annevk> | (might still help someone though, or confuse) |
| 10:23 | <tobie> | annevk: I guess whether it does one or the other depends on your programming background |
| 10:29 | <annevk> | tobie: not sure how a sequence is an interface |
| 10:29 | <tobie> | annevk: in the BS sense. |
| 10:32 | <tobie> | annevk: for BS, long long is an interface |
| 10:33 | <annevk> | tobie: oh, you mean bikeshed |
| 10:33 | <annevk> | Guess it works both ways |
| 10:34 | <tobie> | annevk: well, it's currently inconsistant across types which means that you must write [=null type=] but {{sequence|sequence type}} |
| 10:37 | <tobie> | annevk: to make matters worse, the promise type is defined as <dfn interface>Promise</dfn> |
| 10:38 | <tobie> | s/worse/more confusing to me/ |
| 10:38 | <annevk> | tobie: you can probably fix some of that up with TabAtkins |
| 10:39 | <annevk> | tobie: once you have more of an idea of what you want |
| 10:39 | <tobie> | yeah--hoping to talk about these at TPAC. |
| 10:39 | <tobie> | annevk: too confused in my head to have sensible asks for the time being. |
| 10:40 | <tobie> | annevk: concerned about breaking things elsewhere (e.g. in DOM) if I fix these here. |
| 10:41 | <tobie> | annevk: e.g. change type of Promise from interface to dfn to match other type defs |
| 10:42 | <annevk> | tobie: right, those kind of changes need to happen through a PR and with some discussion |
| 10:42 | <annevk> | tobie: but we can do them and should I think, where they make sense |
| 10:43 | <annevk> | tobie: future is longer than the past |
| 10:43 | <tobie> | (hopefully) |
| 10:43 | <annevk> | tobie: but probably better to first have a holistic view of everything that needs to change and then figure out a game plan |
| 10:43 | <annevk> | tobie: if that's false we might as well stop |
| 10:44 | <tobie> | annevk: should we wait for November 8? |
| 10:44 | <tobie> | ;) |
| 10:48 | <annevk> | tobie: what's then? |
| 10:52 | <tobie> | annevk: well, we *might* be a lot closer to nuclear armageddon if small hands gets elected, no? |
| 10:52 | <annevk> | tobie: oh, good to know the date |
| 10:53 | <annevk> | tobie: I kinda stopped paying attention |
| 10:53 | <tobie> | annevk: I hope those who get a say haven't |
| 12:08 | <smaug> | hmm, WICG has become a place to dump random ideas which may then get implemented without much feedback ? |
| 12:09 | <MikeSmith> | smaug: I’m guessing you have something specific in mind that’s happened |
| 12:09 | <smaug> | nah, just the generic use of WICG |
| 12:10 | <annevk> | smaug: yeah, seems like it |
| 12:10 | <MikeSmith> | as far as the implementation part, seems like not so much from WICG has been implemented yet |
| 12:10 | <annevk> | Step up from impl random ideas |
| 12:11 | <MikeSmith> | yeah it’s not like any browser project would ever go ahead an unilaterally implement something without getting any feedback from other implementors first |
| 12:12 | <MikeSmith> | that would be crazy if we ever had any browser projects that did thank |
| 12:12 | <MikeSmith> | so thank god that never happens at least |
| 12:18 | Ms2ger | passes MikeSmith the booze |
| 13:04 | <nox> | Ms2ger: I don't think I've ever seen you drink any alcoholic beverage. |
| 13:05 | <Ms2ger> | It would surprise me if you had |
| 14:01 | <JakeA> | annevk: how do you feel about serviceWorkerRegistration.fetch being a place to get/set fetch options? Or would you rather it was fetchManager? |
| 14:05 | <annevk> | JakeA: shorter is better |
| 14:05 | <JakeA> | ta |
| 14:05 | <annevk> | JakeA: but not part of register dict? |
| 14:07 | <JakeA> | annevk: I'm in two minds about it. Facebook wanted a header that they could set at any point, but it feels like cookies by another name, and it complicates the implementation |
| 14:07 | <JakeA> | annevk: I'm moving towards putting it on the install or activate event |
| 14:08 | <JakeA> | oh I should say this is for the navigation preload thing |
| 14:08 | <JakeA> | It kinda feels like fetch options should sit with the thing handling the fetching |
| 14:10 | <annevk> | As long as we have something that can be easily reused I suppose it's ok |
| 14:11 | <JakeA> | install/activateEvent is where I'd have static routes, if they were a thing |
| 14:14 | <annevk> | You want install for static routes I guess |
| 14:14 | <annevk> | Little weird otherwise |
| 14:19 | <JakeA> | annevk: just seen foreign fetch on install too, so I guess that's where fetch options are going. We should probably review foreign fetch at tpac, I don't think it's had a lot of eyes on it |
| 14:21 | <annevk> | Yeah, makes sense |
| 14:21 | <annevk> | Not sure how much changed since we first designed it |
| 14:22 | <annevk> | But yeah, we should figure out a pattern for these things and make sure folks adopt them |
| 15:06 | <wanderview> | annevk: JakeA: why doesn't an about:blank frame get its own fetch client? I understand it inherits the origin from the parent, but inheriting the client itself seems really weird to me |
| 15:11 | <JakeA> | I don't mind which way we go with this |
| 15:11 | <JakeA> | Can about:blank have its own CSP? |
| 15:55 | <TabAtkins> | smaug: The point of WICG is to gather small groups of relevant people from the various browsers from each project, and dev the idea in a more silo'd repo. The hope is that this avoids (a) the noise of webapps "everything happens in this mailing list", and more importantly, (b) the pathology of long-lived groups where non-functioning trolls gather over time |
| 15:55 | <TabAtkins> | and reduce the usefulness of the group. |
| 16:13 | <astearns> | deliberately impatient misreading: "The point of WICG is to … reduce the usefulness of the group" |
| 16:23 | <TabAtkins> | +1 |
| 16:23 | <smaug> | TabAtkins: well, my tiny experience with WICG stuff has been that things have been designed behind closed doors, and doors have been opened around the time some vendors would like to implement and ship APIs |
| 16:24 | <TabAtkins> | smaug: Some of that's because, well, we really just started on WICG (and really pushing people to dev things there), and so things are entering the pipeline at various stages. |
| 16:25 | <TabAtkins> | If Google people are trying to use WICG to rubberstamp an already-designed API, please yell about it to slightlyoff. |
| 16:26 | <TabAtkins> | (We're also gradually trying to get more people into standards dev internally, so there's a lot more culture friction about it; sorry about that.) |
| 16:28 | <annevk> | rbyers++ and a beer for reply to "[blink-dev] Intent to ship: Media tracks" |
| 16:29 | <annevk> | (or port, offer only valid while at TPAC) |
| 16:30 | <TabAtkins> | ah yes, that's great |
| 16:33 | <smaug> | TabAtkins: WICG seems to be mostly Google trying to push new APIs. Which is totally fine, but it isn't clear how to participate with discussions when new WICG drafts seem to pop up at random time. Or, this is very possible, I'm just not familiar at all with the working model WICG has. |
| 16:34 | <TabAtkins> | If you want to track new things popping up, that's just a matter of following the Discourse and muting everything that's not browser engineers. That's where new repos get proposed. |
| 16:38 | smaug | doesn't know what is Discource |
| 16:38 | <TabAtkins> | This explains some of your problem, then. ^_^ |
| 16:38 | <TabAtkins> | https://discourse.wicg.io/ |
| 16:38 | <smaug> | why is one group using that when others use email + irc? |
| 16:39 | <smaug> | is it possible to get emails from discourse? |
| 16:39 | <TabAtkins> | I'm not sure what you mean by the first question. Yes to the second question; that's how I watch it. |
| 16:40 | <smaug> | TabAtkins: whatwg and webapp (or whatever it is called these days), and HTML and audio and other WGs have traditionally used email for communication |
| 16:40 | <smaug> | like w3c email lists |
| 16:41 | <smaug> | or whatwg mailing list |
| 16:41 | <smaug> | why is wicg doing something else |
| 16:41 | <TabAtkins> | I wasn't part of the decision, but I think it was meant to encourage webdev communication - normal people seem to find forums much less intimidating than mailling lists. |
| 16:45 | <annevk> | WHATWG mostly uses GitHub and IRC for discourse |
| 16:45 | <annevk> | We tried forums, but they failed |
| 16:46 | <JakeA> | I think the mailing lists are a pretty poor experience. Github works really well. |
| 16:47 | <JakeA> | In my experience, mailing list discussions get filibustered by a few |
| 16:47 | <JakeA> | Happens occasionally on github, but far less frequently |
| 16:51 | <smaug> | I've started to cope with github, issue tracking and discussions. |
| 16:51 | <annevk> | JakeA: yeah, the topic isolation of GitHub helps enormously |
| 16:51 | <smaug> | how github still hides useful information is rather annoying. But I think that happens only in PRs or something, not in issues. |
| 16:51 | <annevk> | JakeA: and only following what interests you |
| 16:52 | <annevk> | smaug: yeah, that's how PRs handle commits that change lines someone previously commented on |
| 16:56 | <Domenic> | Less of a problem now with squashing meaning that you no longer need to force-push |
| 16:57 | <rbyers> | annevk: Thanks! I'm definitely trying to ratchet up interop discipline. You all can help by encouraging use of web-platform-test along with normative spec changes. |
| 17:00 | <annevk> | Domenic: the problem also happens with follow up commits |
| 17:00 | <annevk> | Domenic: it's that the comments get collapsed |
| 17:00 | <annevk> | Domenic: that's not obvious to everyone |
| 17:00 | <Domenic> | annevk: ah right, yeah if you comment on the /files tab instead of on the specific commit that's true |
| 17:01 | <annevk> | Ah, I didn't know that bit, maybe I should try to change my review habbits, although then I might end up commenting on outdated stuff |
| 17:03 | <Domenic> | Yeah not sure what the right way to do that is, /files is so convenient. |
| 17:03 | <majidvp> | smaug: My small experience with WICG has been a mixed bag. Most useful feedback has mainly been solicited via reaching out to relevant folks via email and not by publishing to WICG discourse. |
| 17:05 | <smaug> | majidvp: right. That hints about something I've been thinking... many relevant people don't follow WICG discourse at all |
| 17:05 | <majidvp> | smaug: I have WICG setup so I receive an email for every new thread but I feel most people don't so most new proposals fall off radar. |
| 17:05 | <rbyers> | smaug: Yeah, and some of us try but fail to keep up with the threads also. |
| 17:05 | <majidvp> | smaug: Yep! agreed. |
| 17:05 | <annevk> | I only ever look at WICG stuff when asked |
| 17:06 | <annevk> | Too much of a grab bag |
| 17:06 | <rbyers> | IMHO the important bit is that feedback is solicited from relevant folks at other browser vendors before a new API is shipped in the first engine. |
| 17:06 | <rbyers> | This is why soliciting feedback is part of the blink launch process. |
| 17:06 | <annevk> | Yeah, I'm surprised Mozilla is not copying more of that |
| 17:07 | <rbyers> | If people are doing it right, they're getting feedback early in the spec process, well before "intent to ship" and there's not much value in trying to watch for new specs appearing (from google at least) on WICG. |
| 17:07 | <annevk> | "Intent to implement/ship" is really great |
| 17:08 | <rbyers> | Thanks. It's a tough tradeoff (eg. we also say we don't block waiting for feedback when there hasn't been any meaningful response) but we're trying to be pretty careful about it. |
| 17:08 | <rbyers> | And just eat the compat pain when we need to correct our mistakes (eg. ShadowDOM v1 vs. v0) |
| 17:09 | <rbyers> | smaug: Speaking of all this, you said https://github.com/NavidZ/auxclick seemed reasonable to you, right? If you say that at https://discourse.wicg.io/t/new-event-for-non-primary-button-click/1527/7 then we can move the repo to WICG (start getting IP protection etc.) |
| 17:13 | <smaug> | rbyers: curious, why would it be added as WICG thing? |
| 17:13 | <smaug> | and why not to UIEvents ? |
| 17:13 | <rbyers> | "incubation first standards policy" |
| 17:13 | <rbyers> | i.e. it's too early to move it to UIEvents. |
| 17:14 | <rbyers> | Maybe when a 2nd implementation ships... |
| 17:14 | <rbyers> | But that's absolutely where it should end upt. |
| 17:15 | <rbyers> | WICG is intended as a staging ground to get details ironed out and multiple interoperable implementations, not the ultimate standards destination. |
| 17:16 | <smaug> | I'm having hard time to understand this model and what good it gives us. How is that better than WhatWG model? |
| 17:17 | <rbyers> | Only one big benefit: Microsoft will participate in it. |
| 17:17 | <smaug> | if things are first hidden in some WICG draft, they sure don't get as much feedback or reviewing than if the feature was discussed in the place such feature is normally handled |
| 17:17 | <smaug> | like, in this case, github issue would be ok place |
| 17:17 | <smaug> | w3c github |
| 17:18 | <rbyers> | Otherwise it aims to have all the upside of WHATWG with very little of the problems of the W3C. |
| 17:18 | <smaug> | so that MS can give feedback |
| 17:18 | <smaug> | I'm worried that people start to think that once something from WICG is moved to some other kind of spec, it somehow becomes more official, more "standard" |
| 17:19 | <smaug> | yet, given the current setup, WICG doesn't probably get enough feedback and real spec reviewing happens only once the feature is in some other spec |
| 17:20 | <rbyers> | Are you worried primarily here about spec quality or about interoperability risk (getting locked into APIs we'd like to change)? |
| 17:21 | <smaug> | both |
| 17:22 | <rbyers> | I think it's absolutely intentional that WICG specs start sort of rough (you don't need to be a full-time standards professional to write one) and the spec quality matures as it moves through the standards process along with implementations. |
| 17:22 | <smaug> | ok, then there should be some "DO NOT IMPLEMENT THIS" in WICG drafts |
| 17:23 | <smaug> | or at least "DO NOT SHIP IMPLEMENTATIONS BASED ON THIS API" :) |
| 17:26 | <MikeSmith> | annevk: http://stackoverflow.com/questions/39393909/how-do-i-handle-javascript-fetch-errors |
| 17:27 | <rbyers> | We're trying to be more incremental about shipping new features rather than blocking every new feature on some WG reaching 100% consensus on it. I know that's controversial (you and I have talked about the tradeoffs before) and increases the risk of getting locked into things we regret. But the alternative is not really that much better - we regret plenty |
| 17:27 | <rbyers> | of things that shipped based on a W3C REC spec. |
| 17:28 | <rbyers> | And worse, the web almost became irrelevant when it couldn't respond to the shift to mobile in any sort of reasonable timeframe. |
| 17:28 | <annevk> | rbyers: I don't see how you're preventing the bad stuff if you ship |
| 17:28 | <annevk> | rbyers: it's shipping that's the main issue, not where you spec stuff |
| 17:29 | <annevk> | rbyers: I totally agree with smaug that stuff that goes into UI Events should not be discussed elsewhere |
| 17:29 | <annevk> | rbyers: that's the same shit as with passive listeners, that didn't go that well |
| 17:30 | <rbyers> | There is no "preventing the bad stuff" in any world - there's just risk/benefit tradeoffs. |
| 17:30 | <annevk> | rbyers: and when shipping you don't want to look at the standard, as you already established on blink-dev |
| 17:30 | <annevk> | rbyers: you look at which browsers are planning on shipping, who was involved, what's the testing story, who reviewed, etc. |
| 17:30 | <rbyers> | Anyway this isn't my call - Alex Russel has basically dictated that all new blink features go through incubation of some sort. See https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/PJ_E04kcFb8/ZXJXLJYYAAAJ |
| 17:32 | <annevk> | I'm not sure what incubation means |
| 17:32 | <rbyers> | Not sure what you mean "don't want to look at the standard". Of course we want to look at it as one signal on the likely eventual interoperability. |
| 17:35 | <rbyers> | To me "incubation" means doing new feature development iteratively in collaboration with customers who are actually using the thing, and being agile in responding to their feedback and (when possible) making breaking changes. |
| 17:35 | <rbyers> | BTW I meant to say that having a UI Events issue for 'auxclick' is a good idea - I'm embarassed to find one doesn't exist yet. Will file it now. |
| 17:36 | <annevk> | The first rule of monkey patching is to tell upstream it's happening |
| 17:38 | <slightlyoff> | for the purposes of Googlers, incubation means "do it at WICG or the ES stages process, or ping me directly and we'll figure something out" |
| 17:50 | <rbyers> | annevk: Oh we definitely discussed it with the UI Events editor (looking for a public thread, but you can see garykac was cc'd in the initial discourse thread: https://discourse.wicg.io/t/new-event-for-non-primary-button-click/1527/7). |
| 17:50 | <rbyers> | This isn't monkey patching though, it's an entirely stand-alone feature. |
| 17:50 | <rbyers> | Sure it makes logical sense to group into UI Events but it doesn't change the existing UI Events spec in any way. |
| 17:51 | <annevk> | rbyers: the current UI spec isn't really complete though |
| 17:51 | <annevk> | rbyers: there's some kind of processing model where this is a branch that's not yet defined |
| 17:52 | <annevk> | UI Events is still in a rather sad state |
| 17:54 | <rbyers> | Yeah it could definitely be better. I think opinions differ on the urgency of defining a full processing model. Personally I'd much rather invest resources in having automated tests which watch the event stream generated for various types of input (that's at least where my team is currently investing for UI Events) |
| 18:36 | <Domenic> | Hmm I thought "Note:" shorthand in Bikeshed omitted the leading "Note:" in the output |
| 18:39 | <TabAtkins> | Domenic: What do you mean? It should be omitting it in text; it instead marks it up as a marker for the block. |
| 18:39 | <Domenic> | TabAtkins: it isn't omitting it; see https://heycam.github.io/webidl/#dfn-partial-interface |
| 18:39 | <TabAtkins> | Wait, hmmmm |
| 18:40 | <TabAtkins> | Did something start screwing up? Gonna investigate. |
| 18:40 | <TabAtkins> | No clue how this could have changed... |
| 18:47 | <TabAtkins> | Hm, no, looks like it's always been like that since the beginning. |
| 18:54 | <Domenic> | Can we change it? |
| 18:54 | <Domenic> | Hmm and "Warning:" doesn't work, sad |
| 18:55 | <TabAtkins> | Try "Advisement: " for something that might be better for your style? |
| 18:55 | <Domenic> | I guess that's it, yeah |
| 18:56 | <TabAtkins> | Recognizing "Warning:" as the same thing is a good idea, tho. |
| 18:57 | <Domenic> | Oh but that makes it strong, like tobie mentioned earlier, so we have to use <p class="advisement"> instead |
| 18:57 | <TabAtkins> | Why is this a problem? |
| 18:57 | <Domenic> | It doesn't match the style of all the other notes/examples/etc. |
| 18:58 | <TabAtkins> | Right, because it's calling out something important, correctly using <strong> semantics. |
| 18:58 | <tobie> | Well, more precisely, the problem is that the style doesn't match between single and multiple element advisements. |
| 18:58 | <Domenic> | Nah, I don't think this is more important than the nearby note |
| 18:58 | <TabAtkins> | Notes and examples can be skipped; they're at the same level of importance as surrounding text (or less so). Advisements (/warnings) are *more* important. |
| 18:59 | <TabAtkins> | tobie: Yeah, if you're not using the shorthand, you have to provide the <strong> yourself. |
| 18:59 | <TabAtkins> | Domenic: Then it's not a advisement/warning. |
| 18:59 | <Domenic> | *shrug* I disagree. |
| 19:00 | <TabAtkins> | I mean, you can use whatever wording you want for it on your own. But the "Advisement: " pattern is meant to capture rare, important call-outs that shouldn't be ignored. |
| 19:00 | <TabAtkins> | If you have your own, different concept of advisements, that's cool. But it wont' be captured by the markup shorthand Bikeshed provides. |
| 19:00 | <tobie> | Domenic, see: https://github.com/tabatkins/bikeshed/issues/790 and particularly the output of using the different markup strategies |
| 19:01 | <Domenic> | Yeah, that's why I have to use <p class="advisement"> |
| 19:01 | <Domenic> | I understand that my opinions differ from yours and so I can't use your shorthands |
| 19:04 | <tobie> | TabAtkins: to be clear, I'm in the same position as Domenic: I'd like to use the shorthand but can't because it creates a stylistic difference with cases where I can't use the shorthand because there are multiple elements. |
| 19:05 | <TabAtkins> | tobie: Like I said above, it doesn't. You're just not using the same markup pattern in your "manual" examples. The styling created by the "Advisement:" shorthand is more than just what's applied via a class on the container; it also applies a <strong>, and styles that somewhat. |
| 19:05 | <TabAtkins> | This is different than note/issue, which derive all of their styling from a class on the container, but that's because they don't need any additional structure for their intended semantics. |
| 19:06 | <TabAtkins> | (heading to lunch, bbs) |
| 19:08 | <tobie> | TabAtkins: yup, that's understood. I was just responding to your question about needing to add "strong" manually. (I don't want the strong at all.) |
| 19:08 | <tobie> | But like I said, I haven't lost any sleep over the wontfix. :) |
| 19:09 | <tobie> | Also, bon appetit! |
| 19:28 | <Domenic> | Is there a way to get rid of "This version:" I wonder |
| 19:36 | <tobie> | Domenic: it would be nice to have a syntax to override or remove metadata. |
| 19:36 | <Domenic> | tobie: It looks like "This version:" is mandatory for non-living standards |
| 19:37 | <Domenic> | I wonder who would get made if we changed "ED" to "LS" in the bikeshed file :P |
| 19:37 | <tobie> | Domenic: mandatory in the published drafts |
| 19:37 | <Domenic> | Even for EDs according to bikeshed |
| 19:37 | <Domenic> | I don't know what the rules are for EDs (or who enforces them) |
| 19:38 | <Domenic> | E.g. presumably it's important to have that giant "status of this document" thing clogging up your intro and people would get mad if it went away |
| 19:40 | <tobie> | Domenic: there are things which are legal requirements and there are pubrules |
| 19:40 | <tobie> | the latter don't apply to EDs. |
| 19:41 | <Domenic> | At some point I feel like trying to make the first screenful useful is just a worthless cause. Look at all that whitespace dedicated to the W3C logo, before the title "Web IDL" even appears |
| 19:42 | <tobie> | Domenic: these are design issues to be brought with Fantasai during the tech plenary on the Wednesday. |
| 19:42 | <tobie> | *brought up |
| 19:42 | <tobie> | Domenic: those are neither pubrules nor legal reqs. |
| 19:43 | <tobie> | Domenic: also sotd could most probably be turned into much smaller text |
| 19:43 | <tobie> | with the approval of W3C legal |
| 19:44 | <Domenic> | Paragraphs 2 and 3 duplicate the header |
| 19:44 | <Domenic> | Anyway enough of that, back to the fun stuff :) |
| 19:46 | <tobie> | there's isn't a definition of type in WebIDL |
| 19:46 | <tobie> | shouldn't there be one? |
| 19:48 | <tobie> | Domenic: ^ |
| 19:48 | <Domenic> | mehhh? I guess if people want to link to it? |
| 19:56 | <TabAtkins> | fantasai dedicated this year's redesign to (a) as much as possible, just CSS changes, and (b) overcoming the massive inertia against *any* change. |
| 19:57 | <TabAtkins> | Having accomplished both those goals, fixing the top-matter to be useful and tiny (and remove or move as much boilerplate as possible) is her next redesign goal. |
| 20:04 | <jyasskin> | TabAtkins: Note that the Conformance section says that notes start with "Note:". If you start dropping it, you should also make the Conformance section match. |
| 20:04 | <TabAtkins> | jyasskin: Right, I think that's why I'm keeping it currently. |
| 20:42 | <tobie> | Domenic: https://www.w3.org/2015/Process-20150901/#general-requirements are surprisingly light weight |