| 01:09 | <tobie> | Domenic: you also have the infamous https://html.spec.whatwg.org/#canplaytyperesult |
| 08:45 | <JakeA> | wanderview: I would expect a "something went wrong" page if the fetch rejects, yeah |
| 08:53 | <annevk> | tobie: really enjoying all the IDL PRs |
| 08:57 | <tobie> | annevk: Thanks, and likewise. It's a tad Danaidean, though: new issues come in faster than I make PRs. ;) |
| 08:59 | <annevk> | tobie: yeah, HTML has that problem too |
| 08:59 | <annevk> | tobie: most specs I think, and browsers as well |
| 08:59 | <tobie> | annevk: true |
| 09:01 | <annevk> | Encoding almost stabilized, but then folks wanted to track upstream changes to gb18030 and add Streams support |
| 09:02 | <annevk> | But even with that I think that might be a small enough problem to actually be done at some point and only requiring refactoring now and then of prose per changing conventions |
| 09:05 | <tobie> | annevk: software is hard |
| 09:05 | <tobie> | annevk: Last night, I spent three hours figuring out a solution to https://github.com/tobie/specref/issues/184 |
| 09:05 | <tobie> | annevk: only to figure out it completely broke. |
| 09:06 | <annevk> | oh my |
| 09:07 | <annevk> | I have been doing some Pascal hacking this week |
| 09:07 | <annevk> | Can't say I know what I'm doing, but it compiles |
| 09:08 | <tobie> | annevk: oh wow, contemplating a career change? |
| 09:09 | <annevk> | tobie: nah, HTML preprocessor |
| 09:09 | <tobie> | oh |
| 09:10 | <tobie> | annevk: are you planning to move that to Bikeshed at some point? |
| 09:10 | <annevk> | tobie: we haven't really decided, bikeshed is super slow |
| 09:11 | <tobie> | annevk: so I've been working on the sensor spec again, which is probably 1/10th of the size of WebIDL, and boy is Bikeshed suddenly fast! |
| 09:12 | <annevk> | tobie: hmm yeah, bikeshed is pretty slow on DOM too |
| 09:12 | <annevk> | tobie: but HTML is like 10x DOM if not more |
| 09:13 | <tobie> | annevk: It seemed TabAtkins was looking into perf issues recently |
| 09:32 | <tobie> | Should I reuse the OnErrorEventHandler (https://html.spec.whatwg.org/multipage/webappapis.html#onerroreventhandler) for sensor onerror attribute? |
| 09:33 | <tobie> | I'm generally super confused about error handling on this platform. |
| 09:35 | <zcorpan> | tobie: what's sensor onerror? |
| 09:36 | <tobie> | zcorpan: one of: user denied access, hw is missing, can't read from hw, other? |
| 09:37 | <Ms2ger> | tobie, no, that's only for window.onerror |
| 09:37 | <zcorpan> | tobie: then i suppose it doesn't make sense to use the ErrorEvent interface for that error event, and so not OnErrorEventHandler |
| 09:38 | <tobie> | Ms2ger: that was my assumption too. Thanks. |
| 09:38 | tobie | goes off to close https://github.com/w3c/sensors/issues/137 |
| 09:40 | <tobie> | Ms2ger: is there a note to that effect somewhere in the spec? |
| 09:42 | <Ms2ger> | I don't think so |
| 09:45 | <annevk> | rbyers: https://bugs.chromium.org/p/chromium/issues/detail?id=275675 is an issue I filed about the URL Standard that got closed as a non-useful duplicate |
| 09:46 | <annevk> | rbyers: https://bugs.chromium.org/p/chromium/issues/detail?id=257354 got closed without Chrome volunteering an alternative solution or trying to drive something that other browsers could adopt |
| 09:47 | <annevk> | rbyers: another one was a dupe of a 2012 issue about data URLs that's still open: https://bugs.chromium.org/p/chromium/issues/detail?id=123004 |
| 09:47 | <annevk> | rbyers: I'm guessing you found these too, any suggested next steps? |
| 09:48 | <annevk> | nox: ping https://github.com/whatwg/url/pull/153 |
| 09:57 | <nox> | annevk: Do we define empty? |
| 09:58 | <annevk> | nox: hopefully at one point we actually define that, but thus far not |
| 09:58 | <annevk> | nox: I need to write an Infrastructure document that all standards can reuse that also documents Lists/Records etc. and what operations you can perform on them |
| 09:59 | <annevk> | nox: I haven't really found the time, but it's slowly going to the top of the priority list |
| 10:01 | <nox> | annevk: No need, just appeal to common sense!!1! |
| 10:01 | <annevk> | nox: here's an example, please implement the API |
| 10:02 | <nox> | :D |
| 10:02 | <annevk> | nox: "but how does it work?" |
| 10:02 | <annevk> | nox: common sense, doh |
| 10:02 | <Ms2ger> | That would be a first on the web |
| 10:02 | <annevk> | Ms2ger: sarcasm or too young to remember HTML4? |
| 10:03 | <Ms2ger> | The implementations of HTML4 followed common sense? |
| 10:03 | <Ms2ger> | I suppose dbaron's desk did :) |
| 10:05 | <annevk> | I wonder how long we can keep that reference alive |
| 10:06 | <Ms2ger> | Well, what's my life expectancy? :) |
| 10:57 | <zcorpan> | so when do we get keyboards where every key has a display? it seems like an obvious thing, i got that idea like 15 years ago (would be cool for games at least) |
| 11:00 | <jgraham> | Well that isn't what the new mac thing is, is it? |
| 11:01 | <jgraham> | It's a small flat display at the top of the keyboard |
| 11:01 | <jgraham> | Making per-key displays for real keys seems like it would be a much harder problem |
| 11:13 | <annevk> | Replace keyboard with an iPad? |
| 11:15 | <annevk> | Once tactile feedback can be part of the screen and only effect touch targets, maybe an option… |
| 11:15 | <annevk> | Affect |
| 11:25 | <zcorpan> | annevk: yeah i like keyboards over touchscreens because i can type without looking. so tactile feedback is important; not sure how that would work on a flat screen |
| 11:26 | <zcorpan> | jgraham: i know basically nothing about hardware, but what seems hard about it? |
| 11:29 | <annevk> | I think it exists already |
| 11:30 | <hsivonen> | in reference to the discussion yesterday, I was told that Mars (the planet) is even more featured across Wikipedias that World War II. I'll go with Mars, since a) it's even more featured, b) it's a less violent topic and b) the articles visually look more normal to me in terms of linkified/non-linkified text ratio |
| 11:32 | hsivonen | can't count to c) |
| 11:33 | <hsivonen> | (choosing a different topic for each language by median length wasn't feasible in the Wikidata data set) |
| 11:48 | <MikeSmith> | hsivonen: I guess I’m now curious why the Mars article has the characteristic of being featured across so mamy Wikipedias |
| 11:48 | <MikeSmith> | anyway, interesting |
| 11:49 | <MikeSmith> | hope when you are done you have a chance write up something about this selection process |
| 11:49 | <MikeSmith> | because it seems like it might be useful to others later |
| 11:50 | <hsivonen> | MikeSmith: I'll write something in the README of encoding_bench, but the selection is very unscientific. |
| 11:51 | <MikeSmith> | sure |
| 11:52 | <MikeSmith> | but I think trial-and-error is a kind of scientific approach |
| 11:52 | <annevk> | zcorpan: any reason I should keep https://github.com/whatwg/url/issues/124 open? |
| 12:00 | <zcorpan> | annevk: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4621 seems to throw in gecko... but i suppose i don't feel strongly about it, so ok to close |
| 12:00 | <annevk> | zcorpan: Gecko doesn't implement relative URLs for non-special schemes |
| 12:06 | <zcorpan> | wonder if http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4622 can lead to XSS problems |
| 12:06 | <annevk> | zcorpan: that was the demo that caused you to file this issue |
| 12:07 | <annevk> | zcorpan: think we've gone full circle now |
| 12:07 | <zcorpan> | haha |
| 12:07 | <hsivonen> | MikeSmith: How's https://github.com/hsivonen/encoding_bench/#selection-of-test-data ? |
| 12:07 | MikeSmith | looks |
| 12:10 | <MikeSmith> | hsivonen: nice writeup yeah |
| 12:10 | <MikeSmith> | looks great |
| 12:10 | <hsivonen> | thanks |
| 12:23 | <hsivonen> | I wish Raspberry Pi 3 had enough memory to link libxul. But no. I guess I'll have to learn to cross-compile Firefox if I want uconv numbers for ARM. |
| 14:05 | <wanderview> | JakeA: ok, I guess I should write a chromium issue for that then |
| 14:26 | <annevk> | Domenic: sorry, forgot about looking into updating Ruby today |
| 14:26 | <annevk> | Domenic: will look into it Monday |
| 14:29 | <Domenic> | annevk: I might be able to do it all today, but maybe not; I need to spend a bit more time on streams than I have been. |
| 14:29 | <annevk> | Domenic: no rush, it might actually be useful for me to figure out, so I can then set it up for Fetch and Fullscreen too |
| 14:29 | <annevk> | Domenic: and URL |
| 14:29 | <annevk> | Domenic: btw, Streams is in bikeshed right? |
| 14:30 | <Domenic> | annevk: yep |
| 14:30 | <annevk> | Domenic: does Streams export all the things? |
| 14:30 | <Domenic> | probably not |
| 14:30 | <annevk> | Fetch has a large list of stream references, but I haven't figured out if that's necessary yet |
| 14:30 | <Domenic> | gonna keep trying to move ServiceWorker to having no link-defaults/anchors block and fixing issues as I find them |
| 14:30 | <Domenic> | Then we can tell jungkees to stop adding them :P |
| 14:31 | <annevk> | Yeah, I think both jungkees and JakeA are confused by how that works |
| 14:31 | <annevk> | And since they're editing that spec... |
| 14:31 | <JakeA> | That is probably true |
| 14:37 | <astearns> | zcorpan: (every key a display) http://www.artlebedev.com/optimus/popularis/ |
| 14:39 | <annevk> | astearns: quite ugly |
| 14:39 | <annevk> | astearns: and so expensive for something so ugly |
| 14:42 | <astearns> | annevk: you're just resisting the inevitable future |
| 14:43 | <annevk> | astearns: I'm just going to adopt it at the point where Apple can make it pretty and sell it for less than the price of a laptop |
| 14:43 | <astearns> | Apple's version will require one dongle per key |
| 14:53 | <wanderview> | JakeA: I filed this: https://bugs.chromium.org/p/chromium/issues/detail?id=660377 |
| 15:23 | <JakeA> | wanderview: Cheers! Sorry I've not been awfully engaged with service worker for a few weeks, got a big deadline for Chrome Dev Summit. Will be back on it once that's done |
| 15:24 | <wanderview> | JakeA: np... I;ve been pretty distrated myself |
| 15:25 | wanderview | wonders how many typos he can get in one line... |
| 15:56 | <rbyers> | annevk: Yeah I saw those old bugs. The org situation has improved a lot since then. |
| 15:57 | <rbyers> | .. I went to file some new bugs when we last talked, but that was when GitHub was down :-(. Just filed a beta bug https://crbug.com/660384, and started a discussion with the network TL to get this on his radar. |
| 15:58 | <rbyers> | .. If you can add any examples of real-world developer pain as a result of these interop issues (even cases like sites working correctly only in Chrome), that'll help me boost the priority. |
| 15:58 | <rbyers> | .. Obviously there's tons of places we need to invest around spec conformance, we're trying to prioritize based on web developer impact (improving "web platform predictability"). |
| 15:59 | <rbyers> | s/beta bug/meta bug/ |
| 16:06 | <rbyers> | annevk: BTW, I believe it IS sleevi's team that owns this, so his involvement on that one issue is a good sign. |
| 16:07 | <annevk> | rbyers: thanks, I'm mostly aware of engines being different, though I suppose devs do end up filing bugs as a result |
| 16:10 | <rbyers> | Yep. All engine differences are definitely bad. Keep your ears open for web-dev anecdotes though (and point to them on that bug I filed). We know that for each dev gripe there are hundreds suffering in silence :-) |
| 16:20 | <rbyers> | Annevk: also, thanks for pinging me about this. I'm trying (but mostly failing) to keep an eye on interop across the whole platform instead of just the limited areas I've mostly worked in the past... |
| 16:22 | <annevk> | rbyers: interested in working on styling form controls? 😛 |
| 16:27 | <rbyers> | Not personally 😉, but I can try to encourage the DOM team (Dominic Cooney, tkent, etc.) to take a look. Again, especially if there's evidence or real-world compat problems or confusion. |
| 16:29 | <Domenic> | rbyers: FYI, there is evidence of real-world confusion for datalist, so we did https://github.com/whatwg/html/pull/1836. But, not much for Chrome to do, as they already do the thing that users and web developers seem to like, so we just had the spec suggest that. |
| 16:51 | <smaug> | are there some recommendations when a spec should use iterable interface and when sequence/FrozenArray ? |
| 17:07 | <smaug> | Domenic: which spec bug changed https://bugzilla.mozilla.org/show_bug.cgi?id=869690#c8 ? |
| 17:08 | <smaug> | (it feels odd to use value in the UI) |
| 17:08 | <smaug> | (so I wonder whether the spec issue got feedback from some ux devs) |
| 17:10 | <Domenic> | smaug: https://github.com/whatwg/html/pull/1836 |
| 17:11 | <Domenic> | Also prefer normal JS arrays if you have an array like data structure, iterable for something specialized like URLSearchParams |
| 17:25 | <rbyers> | Domenic: cool, thanks |
| 20:06 | <TabAtkins> | tobie: Yeah, unfortunately Bikeshed's perf is approximately 1/3 HTML parse, 1/3 HTML serialize, 1/3 everything else together. |
| 20:08 | <tobie> | TabAtkins: this ratio is consistent as file size increases? |
| 20:08 | <TabAtkins> | Hmm, let me check actually. That's the ratio for W3C HTML (which also takes ~55s on my hyper-powered work machine). |
| 20:10 | <TabAtkins> | No, that is absolutely not consistent. |
| 20:11 | <TabAtkins> | On a teensy spec, parsing is about 5% and serializing is about 3%. |
| 20:23 | <wanderview> | annevk: is it just me, or does this link to the wrong referrer: https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer |
| 20:23 | <wanderview> | annevk: seems like it should link to the fetch spec instead of html spec |
| 20:29 | <annevk> | wanderview: not just you |
| 20:32 | <tobie> | TabAtkins: oh, those are the ratios for HTML. :( |
| 20:33 | <TabAtkins> | annevk, wanderview: The spec explicitly lists the HTML spec as the place to grab "referrer" from. :/ |
| 20:35 | <TabAtkins> | https://github.com/w3c/webappsec-referrer-policy/blob/master/index.src.html#L43 |
| 20:51 | <Domenic> | TabAtkins: only with for="meta", right? |
| 20:52 | <TabAtkins> | No. I'm going to keep repeating "autolinking is a filter" until it works. ^_^ |
| 20:52 | <Domenic> | And I'm going to keep telling you "your system is too hard for humans to understand" until you see that ^_^ |
| 20:54 | <TabAtkins> | And I'll continue pointing to all the places where "no `for` on the autolink means the same as `for=/`" would result in people having to be unnecessarily verbose. |
| 20:55 | <TabAtkins> | Lack of a `spec` attribute doesn't mean "only select definitions that don't appear in a spec", it means "I'm not filtering by spec right now". I'm not sure why it's so hard to intuit the exact same thing for `for`. |
| 20:55 | <Domenic> | Maybe we need a preprocessor before we feed things into Bikeshed |
| 21:00 | <TabAtkins> | In this case (referrer) the problem is that anchor-block things (rightfully) get selected before foreign things, based on the assumption that you if you're putting the anchor in your spec you probably want to link to it, and would get annoyed if it then complained about other anchors and required you to specify a link-defaults to select the thing you just |
| 21:00 | <TabAtkins> | wrote in. |
| 21:01 | <TabAtkins> | In this case it would be more useful if Fetch was actually in the database, as then they'd get a normal "ambiguous reference" link error. |
| 21:08 | <TabAtkins> | Sigh. Inevitable tradeoffs of usability vs specificity. The Anolis "you have to make up an identifier for your term that's globally unique across all specs, and then remember and type it every single time you want to link to it" is never *wrong*, but it's only *slightly* better than just providing a full URL. |
| 21:08 | <Domenic> | TabAtkins: I thought Fetch was in the database? It has a bunch of Bikeshed exports, and is recently in Bikeshed. |
| 21:09 | <TabAtkins> | Domenic: Oh, indeed it is. Then it's just a case of them overusing anchor blocks. |
| 21:10 | <Domenic> | Yeah, I think people are cargo-culting large blocks of link-defaults and anchors around, not realizing Bikeshed is supposed to save you from that |
| 21:11 | <Domenic> | I'm trying to fix that by going through specs and deleting them and updating HTML to export anything that Bikeshed still warns about, but I don't want to do that until we have something in place to make <a>browsing context</a> and <a>origin</a> and so on work. |
| 21:16 | <botie> | rniwa, at 2016-10-27 19:31 UTC, Domenic said: if he's writing tests for the [CEReactions] on elements/document.close/etc.? |
| 21:16 | <Domenic> | rniwa already answered that, botie |
| 21:16 | <botie> | Domenic: sorry... |
| 21:17 | <rniwa> | Domenic: I'm landing it into WebKit first: https://bugs.webkit.org/show_bug.cgi?id=163969 |
| 21:17 | <rniwa> | Domenic: since i really want to finish up our impl this week |
| 21:18 | rniwa | needs to have someone review https://github.com/w3c/web-platform-tests/pull/3968 |
| 21:18 | <Domenic> | rniwa: makes sense, cool! |
| 21:18 | <Domenic> | rniwa: that's still waiting on you to fix zcorpan's comment at https://github.com/w3c/web-platform-tests/pull/3968#issuecomment-256330138, right? |
| 21:18 | <rniwa> | Domenic: I've fixed that |
| 21:19 | <Domenic> | rniwa: hmm it still says "propertyName: 'border-radius'" on GitHub |
| 21:20 | <rniwa> | Domenic: oh, that one |
| 21:20 | <rniwa> | Domenic: i just replied |
| 21:21 | <Domenic> | rniwa: ah OK. LGTM then but we should wait to make sure zcorpan signs off |
| 21:22 | <rniwa> | Domenic: ya |