| 01:20 | <MikeSmith> | https://twitter.com/awesomekling/status/588102855019495424 |
| 01:20 | <MikeSmith> | "DOM attributes on the prototype chain? WebKit did that over a year ago, jeez. We just had to keep some as own properties due to compat." |
| 01:21 | <MikeSmith> | last time I ran some web-platform-tests interface/WebIDL tests, I didn't seem to find that to be true for the interfaces I was looking at |
| 01:21 | <MikeSmith> | WebKit still seemed to be failing on a lot of those interface tests |
| 01:30 | <TabAtkins> | MikeSmith: "some" is technically compatible with "most". It just means "not all". ^_^ |
| 01:30 | <MikeSmith> | heh |
| 01:32 | <MikeSmith> | TabAtkins: sometimes I think you would make a good lawyer 😀 |
| 01:32 | <MikeSmith> | or at least you could play one on TV |
| 01:34 | <TabAtkins> | Technically correct is the best kind of correct. |
| 01:36 | <MikeSmith> | sitcom pilot: "Texan Web developer relocates to wild-and-crazy San Franciso in the 2010s, moonlights as lawyer, fun ensues" |
| 01:37 | <TabAtkins> | I'd watch it. |
| 01:37 | <TabAtkins> | And star in it. |
| 01:37 | <TabAtkins> | Wait no, I need someone else to be me. |
| 01:39 | <MikeSmith> | yes! |
| 01:39 | <MikeSmith> | now we got to think about who |
| 01:39 | <TabAtkins> | Elijah Wood. |
| 01:39 | <MikeSmith> | I could play you, then you could play me in my sitcom |
| 01:39 | <MikeSmith> | heh |
| 01:40 | <MikeSmith> | yeah, the *young* Elijah Wood |
| 01:40 | TabAtkins | is still hung up on when cute senior girls told freshman-Tab that he looked like a young Elijah Wood. |
| 01:40 | <MikeSmith> | he's be the 12-year-old version of you |
| 01:40 | <TabAtkins> | Yeah. |
| 01:41 | <TabAtkins> | That's actually just right for my age at the time. |
| 01:41 | <MikeSmith> | like Doogie Howser, except a webdeveloper/lawyer instead of a doctor |
| 01:42 | <MikeSmith> | I want Werner Herzog to play me |
| 01:44 | <MikeSmith> | and in my sitcom I hang out with Werner Herzog but he's played by Zach Galifianakis |
| 01:44 | <TabAtkins> | I like this plan. |
| 01:45 | <TabAtkins> | I'll take Zach as my little brother in my sitcom, too. |
| 01:45 | <MikeSmith> | that would be great |
| 01:45 | <MikeSmith> | we could have some tie-ins where we meet |
| 01:49 | <MikeSmith> | anyway, it's nice to have another career to fall back on |
| 01:50 | GPHemsley | wants second chair |
| 02:06 | <MikeSmith> | anyway results of tests like http://w3c-test.org/webstorage/idlharness.html and http://w3c-test.org/geolocation-API/interfaces.html seem to indicate WebKit has a lot of properties they need to move still |
| 02:11 | <MikeSmith> | makes me wonder what properties they did actually move |
| 02:33 | <MikeSmith> | speaking of wonders, they never cease: IETF has moved to using Bootstrap for their site http://tracker.tools.ietf.org/release/about |
| 03:14 | <MikeSmith> | does anybody remember what's holding us up from adding "Copy to clipboard" support to the platform? |
| 03:15 | <MikeSmith> | I mean to enable the kind of thing in the github UI where it has that "Copy to clipboard" button |
| 03:15 | <MikeSmith> | e.g., on a repo home page like https://github.com/w3c/web-platform-tests |
| 03:15 | <MikeSmith> | the "clone URL" field |
| 04:50 | <caitp-> | does the File api suggest upper bounds on the byte size of a file, to be able to read it? |
| 04:50 | <caitp-> | chrome silently failing to read a1 gig file as text was hard to track down today :l |
| 05:46 | <JakeA> | MikeSmith: I think we just added it to Canary |
| 06:04 | <MikeSmith> | JakeA: ah cool |
| 06:30 | <JakeA> | MikeSmith: I believe it's document.execCommand('copy') from an interaction event |
| 06:44 | <MikeSmith> | JakeA: thanks, this is in the Clipboard Ops spec? |
| 06:44 | MikeSmith | looks |
| 06:45 | <MikeSmith> | oh that wouldn't be in the clipboard ops spec I guess |
| 06:52 | <MikeSmith> | so, still wondering what spec they're implementing from |
| 06:52 | <MikeSmith> | I guess https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html but not sure |
| 06:52 | <MikeSmith> | botie, inform darobin what's the current spec for document.execCommand('copy') etc |
| 06:54 | <MikeSmith> | botie, inform darobin what's the current spec for document.execCommand('copy') etc |
| 06:54 | <botie> | will do |
| 07:25 | <zcorpan> | can anyone come up with a test case to check https://www.w3.org/Bugs/Public/show_bug.cgi?id=28433 ? |
| 08:00 | <botie> | darobin, at 2015-04-15 06:54 UTC, MikeSmith said: what's the current spec for document.execCommand('copy') etc |
| 08:05 | <darobin> | MikeSmith: last I checked you still needed a mix of https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html and http://dev.w3.org/2006/webapi/clipops/clipops.html |
| 08:07 | <MikeSmith> | darobin: ok |
| 08:07 | <darobin> | MikeSmith: there are proposals for intention events to handle that, but nothing actually real |
| 08:08 | MikeSmith | wonders who implemented this is blink |
| 08:08 | <darobin> | I don't know what the implementation status for clipops is in general |
| 08:08 | <darobin> | execCommand in Blink I would expect dates back to WebKit |
| 08:08 | <darobin> | unless it's been redone somehow |
| 08:08 | <MikeSmith> | darobin: JakeA said they landed it only recently |
| 08:09 | <darobin> | oh? |
| 08:09 | <darobin> | hmmm, I guess that might make sense actually, people still overwhelmingly use Flash for copying |
| 08:09 | <MikeSmith> | Yeah |
| 08:09 | <darobin> | or maybe they landed support for it outside of contentEditable? |
| 08:09 | <MikeSmith> | dunno |
| 08:36 | <annevk> | wanderview: thanks so much for all the triaging btw |
| 08:36 | <annevk> | wanderview: we really need a script to go from GitHub issue to file a bug on browsers to fix something |
| 08:43 | <jgraham> | gsnedders: I don't know what you mean? |
| 09:49 | JakeA | stalls for time on the clipboard questions as there's an article coming shortly |
| 09:49 | <annevk> | MikeSmith: it should be part of the clipboard spec |
| 09:49 | <JakeA> | http://updates.html5rocks.com/2015/04/cut-and-copy-commands |
| 09:49 | <JakeA> | agreed |
| 09:51 | <annevk> | JakeA: we're tracking this in https://bugzilla.mozilla.org/show_bug.cgi?id=1151429 btw |
| 10:50 | <MikeSmith> | does iOS have anything like Chrome Native Messaging? |
| 10:51 | <MikeSmith> | https://developer.chrome.com/extensions/nativeMessaging |
| 11:16 | <gsnedders> | jgraham: https://github.com/html5lib/html5lib-python/issues/182 — do we merge this in after we have xfails working and a seemingly clean tree or do we wait till everything's done? |
| 11:16 | <gsnedders> | jgraham: I would rather merge once the tree is green agai |
| 11:16 | <gsnedders> | *again |
| 11:22 | <jgraham> | gsnedders: Do you mean "do we finish this before merging anything else"? |
| 11:28 | <gsnedders> | jgraham: I'd rather that, as I've said before, but I felt like I lost that argument already. I mean do we finish the subtasks of that completely before merging it or do we just finish those needed to get the tree green? |
| 11:31 | <jgraham> | gsnedders: Merge the smallest possible thing at a time seems sensible |
| 11:31 | <gsnedders> | jgraham: basically the first 90% of the work to get rid of xfails is now done |
| 11:34 | <annevk> | JakeA: wanderview: in https://github.com/whatwg/fetch/issues/43#issuecomment-93176616 we also came up with the need for making a URL from a Response |
| 13:22 | <wanderview> | annevk: what exactly does that mean? the Response.url? or a URL mapping to the underlying source of that Response (like the Cache API file on disk)? |
| 13:24 | <annevk> | wanderview: the latter |
| 13:24 | <annevk> | wanderview: e.g. <img src=response:identifier> or some such |
| 13:25 | <wanderview> | annevk: does this effectively mean we need a cache:// scheme or something? or is it just a non-human-readable id? |
| 13:25 | <wanderview> | annevk: the life cycle of the URL is a bit scary to me too... if they forget to call revokeObjectUrl()... |
| 13:26 | <annevk> | wanderview: non-human-readable |
| 13:26 | <annevk> | wanderview: yeah, we'd need to make it a one-time thing |
| 13:26 | <annevk> | wanderview: that streams can only be read once helps here of course |
| 13:26 | <wanderview> | annevk: well, what if its never read from? |
| 13:26 | <wanderview> | annevk: does reading from the URL drain the Response? |
| 13:26 | <wanderview> | or is the Response "drained" by creating a URL |
| 13:26 | <annevk> | wanderview: yeah |
| 13:27 | <wanderview> | I guess I'm asking if creating the URL is effetively a clone |
| 13:27 | <wanderview> | ok |
| 13:27 | <wanderview> | annevk: I think thats easier to implement, then |
| 13:27 | <annevk> | wanderview: I don't think the URL should clone |
| 13:27 | <annevk> | wanderview: if you want a clone, use .clone() first |
| 13:27 | <annevk> | wanderview: that's the motto |
| 13:27 | <wanderview> | we can do this all in the child process without any extra hooks into the back end |
| 13:27 | <annevk> | or party line |
| 13:28 | <annevk> | I more optimal API would be <img>.srcObject = Response, however, we don't have srcObject on all possible things we want to feed Responses to and for some cases such as CSS it's a bit unlikely |
| 13:28 | <wanderview> | annevk: why do this as a function wrapping Response? why not have a Response.drainToUrl() or something |
| 13:29 | <wanderview> | hmm |
| 13:29 | <wanderview> | annevk: I guess that half of it (setting it as a .src on arbitrary attributes) may be a lot harder... not sure what we support there |
| 13:29 | <zewt> | (does a "one-time url" make sense in general, given that urls today can normally be read multiple times?) |
| 13:29 | <zewt> | (assuming GET, which is all you have with a url in isolation) |
| 13:31 | <annevk> | zewt: if you have a parser hook one-time URL makes some sense still I think |
| 13:32 | <zewt> | but typically that's logically referred to a resource, not an "open unseekable file handle to a resource" or something along those lines |
| 13:32 | <zewt> | i suspect it'll work most of the time anyway, just curious about the edge cases |
| 13:32 | <wanderview> | I could see people getting bitten by it |
| 13:32 | <annevk> | zewt: it doesn't seem different from blob to me, other than Response having headers that might be useful |
| 13:33 | <wanderview> | var url = response.drainToUrl(); headerImage.src = url; otherImage.src = url; |
| 13:33 | <zewt> | eg. browsers today could discard an image entirely if it's been offscreen for a while, and then redownload it later when needed |
| 13:33 | <annevk> | wanderview: the first wins |
| 13:33 | <wanderview> | annevk: blob object URLs are reusable, no? |
| 13:33 | <wanderview> | I don't think the consumer of a URL should have to know what created it |
| 13:34 | <annevk> | wanderview: depends on how you create them |
| 13:34 | <zewt> | i guess if the url logically caches the whole response it'd basically be like a blob |
| 13:35 | <wanderview> | annevk: so I can't write a generic function loadImageInMultiplePlaces(url) because someone might hand me some strange one-time-use URL? sounds like bad ergonomics to me |
| 13:35 | <zewt> | er, other than the one-time thing |
| 13:35 | <wanderview> | annevk: we have no way to inspect if a URL is drained, etc |
| 13:35 | <zewt> | wanderview: that was my objection to the old microsoft proposal for auto-revoking blobs, iirc |
| 13:35 | <annevk> | wanderview: yeah, server could do the same technically |
| 13:35 | <wanderview> | annevk: I think URL might need to imply .clone() for every time its read |
| 13:35 | <zewt> | or one of them |
| 13:36 | <annevk> | wanderview: I don't really see why |
| 13:36 | <wanderview> | if there is precedent, I guess I don't object... just reinforces my existing hatred of createObjectUrl/revokeObjectUrl |
| 13:36 | <zewt> | that sounds not great but probably not a dealbreaker |
| 13:36 | <zewt> | obviously needs to not repeat the revoke* mistake |
| 13:36 | <annevk> | wanderview: srcObject = Response would be better |
| 13:37 | <annevk> | no doubt about that |
| 13:37 | <annevk> | zewt: right |
| 13:37 | <zewt> | err |
| 13:37 | <zewt> | <wanderview> annevk: the life cycle of the URL is a bit scary to me too... if they forget to call revokeObjectUrl()... |
| 13:37 | <zewt> | ^ does this repeat the revoke* mistake? heh |
| 13:37 | <annevk> | zewt: there's no proposal for a method that works with Response yet |
| 13:37 | <wanderview> | zewt: my experience with working on memory problems in firefoxos gallery app and others... people forget to revokeObjectUrl() all the time |
| 13:37 | <annevk> | zewt: but it would definitely not have a revoke thing going on |
| 13:38 | <wanderview> | and it creates huge memory pressure when the url is representing an image |
| 13:38 | <zewt> | wanderview: yeah, that was a huge screwup with object urls, javascript != manual resource management |
| 13:38 | <zewt> | annevk: k |
| 13:38 | <wanderview> | zewt: yea... Response drains after first use... so that it better... unless we need to mash it into the manual revokeObjectUrl() scheme |
| 13:38 | <zewt> | wanderview: well, blobs are intended to be able to be written to disk even if there's an open url to them |
| 13:39 | <zewt> | (still a leak if people don't revoke, of course, but a disk space leak instead of memory) |
| 13:39 | <wanderview> | I guess gecko only gives you a file backed blob if you explicitly write it to IDB or something, and then get it back out |
| 13:39 | <zewt> | that sounds like an implementation shortcoming rather than blob's |
| 13:40 | <zewt> | only as far as the memory thing |
| 13:40 | <zewt> | being completely async is one thing blob got right (well, except for the size and mime type, which it screwed up and made sync) |
| 13:40 | <wanderview> | zewt: you still have issues with "I spent all the time to read this huge thing from disk... do I waste time reading again later or waste memory holding it in memory" its a tradeoff thats hard to always get right at the browser |
| 13:42 | <zewt> | wanderview: well the idea is that if the data is on disk in the first place, a blob is just a pointer to it and you'd never actually need to read the whole thing (which i know has plenty of other complexities, in particular if the data might change out from under you) |
| 13:43 | <zewt> | excess flood of excess flood |
| 13:43 | <annevk> | zewt: feedback on https://wiki.whatwg.org/wiki/Storage is welcome too btw |
| 13:44 | <zewt> | more unreadable promise ugliness :( |
| 13:46 | <zewt> | headed to work, will take a look later |
| 14:02 | <MikeSmith> | https://twitter.com/CraigMcPheat/status/588335648987308032 |
| 14:02 | <MikeSmith> | sounds like a fun place to work |
| 14:03 | <MikeSmith> | I wonder if people in his office are also blocked from just using the real Web from their own smartphones |
| 14:04 | <MikeSmith> | and what is a "virtualised Chrome" |
| 14:04 | <JakeA> | annevk: the only blocked response headers are the cookie ones right? Chrome isn't giving me things like the "date" header for a CORS response, sound like a bug? |
| 14:05 | <jgraham> | annevk: It's not clear to me why the default box is atomic |
| 14:05 | <annevk> | JakeA: no |
| 14:05 | <annevk> | JakeA: did you use access-control-expose-headers? |
| 14:05 | <annevk> | jgraham: what else would it be? |
| 14:06 | <wanderview> | MikeSmith: probably a virtual desktop thin client |
| 14:06 | <JakeA> | omg, sorry about that annevk. You're right of course |
| 14:06 | <annevk> | no worries |
| 14:06 | <jgraham> | annevk: Well that introduces the requirement that all of indexeddb, cookies, etc. are cleared together. I don't think any requirement like that exists at present |
| 14:07 | <jgraham> | It seems like each is a seperate atomic box (although the document should be clear that "cleared" means "cleared through UA", not "cleared through DOM APIs") |
| 14:09 | <jgraham> | "global quota" seems like it shouldn't be explained as "free space - constant" unless that's really the only allowed model |
| 14:11 | <wanderview> | jgraham: I think pretty much everyone we've talked to favors clearing everything or nothing (aka atomic) to avoid half-broken pages |
| 14:11 | <wanderview> | unless there is an explicit way to signal "this part can get cleared without the rest" |
| 14:11 | <jgraham> | wanderview: That isn't how UAs work today |
| 14:11 | <wanderview> | jgraham: browsers today don't work offline... we're trying to fix that? |
| 14:13 | <jgraham> | My point is that a) people will regard this as a functional regression "what do you mean I can't delete a cookie from a site unless I clear all the other data?!", and is likely to interfere with troubleshooting instructions for some sites |
| 14:14 | <wanderview> | jgraham: who said you can't delete a cookie? its just saying the browser can't delete the cookie behind your back without reseting the storage for the whole origin |
| 14:14 | <jgraham> | wanderview: Is it? |
| 14:15 | <jgraham> | In that case it needs to be phrased to be much clearer |
| 14:15 | <wanderview> | jgraham: yes... this is about what the browser can do when the system is under storage-pressure |
| 14:15 | <wanderview> | annevk: ^^^ |
| 14:16 | <jgraham> | wanderview: I assumed that "cleared" would include any browser-initiated clearing including via the UI |
| 14:16 | <wanderview> | I guess thats an interesting case |
| 14:17 | <wanderview> | jgraham: I guess I would question if most users understand the difference between "cookies" and other data... for example, we are moving to block things like IDB in third-party iframes if the "disallow third-party cookies" pref is set |
| 14:17 | <wanderview> | we == gecko |
| 14:18 | <jgraham> | wanderview: Well I agree that some users don't. But I can still clear a single cookie from the Fx UI |
| 14:18 | <wanderview> | jgraham: I imagine things like that and devtools storage inspector (does it allow modifying? it could...) would still work |
| 14:19 | <jgraham> | Yeah, so it should be clear that these "atomic" boxes are not really atomic in general, but only according to how they react to storage pressure |
| 14:20 | <wanderview> | jgraham: the intention is that browsers know they can treat them as atomic... but things like devtools allow you to break the rules... just like changing CSS or js via devtools on a site is not "spec'd" or "normal" |
| 14:20 | <Domenic> | +1 |
| 14:21 | <Domenic> | "atomic" is too strong of a guarantee |
| 14:21 | <Domenic> | call it something like "lives and dies together" :P |
| 14:24 | <jgraham> | wanderview: They are also not "atomic" from the point of view of creation. You can add or remove data from an "atomic |
| 14:24 | <jgraham> | " box using APIs |
| 14:24 | <wanderview> | I'm not really interested bikeshedding the name |
| 14:24 | <jgraham> | It's really only under storage pressure that they act as atoms |
| 14:24 | <jgraham> | OK, but I |
| 14:24 | <jgraham> | 'm just explaining why the wiki wasn't clear to me |
| 14:25 | <wanderview> | jgraham: sure... and that is good feedback... I think annevk will see this and respond eventually |
| 14:36 | <Domenic> | I think there are people in this channel very interested in bikeshedding the name :) |
| 14:43 | annevk | wonders if the bikeshedding has concluded |
| 14:44 | <annevk> | jgraham: if you have a better term I'd be happy to update the page, though you can too :-) |
| 14:44 | <jgraham> | Well just trampling over someone else's proposal seems wrong :) |
| 14:45 | <jgraham> | (I'm not sure I have a better term, but someone might. Or it might just need better explaination) |
| 14:49 | <annevk> | "atomic under pressure" (could also be a new album title) |
| 14:54 | <annevk> | It's somewhat surprising to me we still offer control over individual cookies |
| 14:57 | <annevk> | If it was up to me we would have a panel called "Sites" that gives you an overview of sites (ordered by frecency, no typo) where you can get/set permissions and clear storage |
| 15:00 | <annevk> | Domenic: are you taking time to review https://w3c.github.io/mediacapture-main/ at some point? |
| 15:00 | <Domenic> | annevk: it was on my to do list but keeps slipping downward |
| 15:01 | <annevk> | Domenic: they'll play process games on us if we don't do it by May 15 |
| 15:01 | <annevk> | although they might anyway since I think most of this has shipped |
| 15:01 | <Domenic> | Hmm |
| 16:32 | <TabAtkins> | Domenic: "life-bonded" |
| 16:37 | <TabAtkins> | How do people query that webdevdata these days? Is it still "download the zip and run grep", or is there something else? |
| 17:25 | annevk | typically asks zcorpan |
| 17:38 | <TabAtkins> | Well yeah, but that's not super-scalable. ^_^ |
| 19:11 | <TabAtkins> | annevk: Finishing up DOM right now. I'll have a PR for you this afternoon. |
| 19:31 | <TabAtkins> | annevk: MouseEvent is no longer defined by UI Events, if I follow the reference in your bibliography. Where should I point this link? |
| 19:33 | <Ms2ger> | Should be in UI Events |
| 19:34 | <TabAtkins> | The ED seems super stripped down: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm |
| 19:34 | <Ms2ger> | https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#interface-MouseEvent |
| 19:34 | <TabAtkins> | Ah, the biblio ref in DOM pointed to d4e. |
| 19:36 | <TabAtkins> | That url depresses me, though. |
| 20:37 | <TabAtkins> | annevk: And DOM is done. Could use some review, but the changes are extensive enough that doing so will be difficult. I did my best to make sure things linked correctly, though. |
| 20:38 | <TabAtkins> | In particular, everything that linked cross-document, I noted down as I discovered them. After conversion, I verified that they were all failing to link (so they weren't getting grabbed by a local link), and manually specified their target in the anchors block. |