| 00:00 | <jgraham> | And the second is also a mutation? |
| 00:00 | <hober> | jgraham: yeah, that's the real question |
| 00:01 | <annevk> | oh |
| 00:01 | <annevk> | that was confusing |
| 00:02 | <annevk> | reflect does say 2 |
| 00:02 | <hober> | where |
| 00:02 | <annevk> | "On setting, the content attribute must be removed if the IDL attribute is set to false, and must be set to the empty string if the IDL attribute is set to true." |
| 00:04 | <hober> | hmm. yeah, ok, fair enough |
| 00:11 | <jernoble> | annevk: so, what if you call video.controls = false; setTimeout(function() { video.controls = false; }); how many times would you fire a MO then? |
| 00:11 | <jernoble> | annevk: “the content attribute must be removed”, but the content attribute is not present the second time. |
| 00:15 | <jwalden> | peoples! anyone want to fix w-p-t tests to not refer to ArrayBuffer neutering any more, since the spec changed to use "detach" as the verb instead? |
| 00:15 | jwalden | summons lazychannel |
| 00:17 | <hober> | jernoble annevk: twice when redundant true setting but once when redundant false setting is pretty weird |
| 00:23 | <MikeSmith> | hey it's a rare visit to #whatwg by jernoble |
| 00:23 | <MikeSmith> | hi jernoble |
| 00:23 | <jernoble> | hi MikeSmith |
| 00:23 | <jernoble> | long time lurker, 1st time caller |
| 00:23 | <MikeSmith> | hah 😀 |
| 00:23 | <annevk> | hober: well, you cannot remove it twice, but you can set it twice |
| 00:24 | <Domenic> | jwalden: HTML spec hasn't changed yet... |
| 00:24 | <jwalden> | peoples! anyone want to fix the HTML spec to not refer to ArrayBuffer neutering any more, since the ES6 spec changed to use "detach" as the verb instead? |
| 00:24 | <jwalden> | ;-) |
| 00:24 | <annevk> | jernoble: hober: I guess we could change it, I don't really care |
| 00:25 | <annevk> | jwalden: that is actually a hard change to make |
| 00:25 | <jwalden> | annevk: wut |
| 00:25 | <annevk> | jwalden: doing that properly would require untangling a whole mess of things and how transferables work |
| 00:25 | <annevk> | jwalden: did you look into it? |
| 00:25 | <MikeSmith> | smaug____: webex in fact has no webby stuff. so I think the name is a clever troll. |
| 00:25 | <annevk> | jwalden: "neuter" is shared by a bunch of objects that are transferable |
| 00:26 | <jwalden> | annevk: it's just a terminology change, shouldn't be any actual algorithm changes -- basically along the lines of all the naming changes I've done in https://bugzilla.mozilla.org/show_bug.cgi?id=1079844 |
| 00:26 | <annevk> | jwalden: and then there's the IDL vs JavaScript object confusion |
| 00:26 | <Domenic> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=27031#c4 |
| 00:26 | <Domenic> | jwalden annevk ^ |
| 00:26 | <annevk> | right |
| 00:26 | <jwalden> | oh, stab |
| 00:27 | <jwalden> | welp, most of Mozilla will be detach-friendly, at least, after those patches land |
| 00:27 | <jwalden> | with w-p-t tests as close to the only exception |
| 00:28 | <annevk> | I mean I could rename neuter to detach, but none of the problems would go away |
| 00:28 | <MikeSmith> | smaug____: I don't have any of the webex client stuff installed in my laptop. when I need to call into webex meetings, I use the android client and just use it to make the webex system dial my phone number. Then I just close the client. So I don't use the video part. For me the whole system is there just to make phone calls to me. |
| 00:28 | <jwalden> | if neuter were defined as an HTML-side generic concept, it could be specified that when performed upon an ArrayBuffer it would detach that ArrayBuffer |
| 00:30 | <hober> | MikeSmith: that's exactly how i "use" webex |
| 00:31 | <hober> | [well, s/android/ios/ but otherwise yeah :)] |
| 00:31 | <MikeSmith> | hober: high five |
| 00:31 | <hober> | :) |
| 00:32 | <MikeSmith> | btw you apple guys need to get a "high five" emoji added to the next barrage for emoji you unleash |
| 00:34 | <annevk> | jwalden: yeah, something like that |
| 00:34 | <hober> | that's what U+1F64F PERSON WITH FOLDED HANDS is |
| 00:36 | <smaug____> | MikeSmith: I ended up using skype |
| 00:37 | <smaug____> | to listen to the custom elements meeting |
| 00:37 | <MikeSmith> | hober: ah yeah, that's close. It's either that or somebody high-fiving themselves, clearly |
| 00:39 | <hober> | well, if your platform renders that in a way that doesn't look like a high five, you're gonna have a bad time :) |
| 00:39 | <MikeSmith> | smaug____: yeah that usually works better than anything else. I mean, just calling somebody in the room with skype, or having them call you |
| 00:39 | <MikeSmith> | hober: heh yeah I guess the unpredictability of the rendering adds to the fun |
| 00:41 | <MikeSmith> | jgraham: The first two sentences in your summary of the TAG are spot-on. But to be fairーas annevk pointed outーthe pushing-back-against-https didn't come from others on the TAG as far as I recall. |
| 00:42 | <MikeSmith> | Others on the TAG worked on coming up with the "Making the Web Secure" finding, or whatever it was called. Which I recall being sane |
| 00:43 | <MikeSmith> | especially Yan of course but not just Yan |
| 00:43 | <MikeSmith> | and they were strongly supportive of the Powerful Features doc |
| 00:43 | <MikeSmith> | or whatever that ended up being called now |
| 00:44 | <MikeSmith> | Secure Contexts |
| 00:45 | <MikeSmith> | but to you point about tests I also don't want to invite the TAG to get involved |
| 00:45 | <MikeSmith> | and anyway I am certain that some or most of the TAG members would not want the TAG to |
| 00:46 | <MikeSmith> | but hey glad we can still count on gsnedders for crazy ideas. He gets it right more often than he gets it wrong |
| 00:46 | <roc> | jgraham: the TAG was useful for telling the Web Audio editor he was doing it wrong |
| 00:48 | <MikeSmith> | hey that too |
| 00:48 | <roc> | albeit too late to fix most of the wrongness |
| 00:49 | <MikeSmith> | we need to the TAG around to explain to spec editors that it's not OK to introduce race conditions into standards |
| 00:50 | <Hixie_> | roc: couldn't other people tell him that? |
| 00:51 | <roc> | Hixie_: sure; I, for one, did. But he didn't have to listen to me. |
| 00:51 | <Hixie_> | did he have to listen to the TAG? |
| 00:51 | <Hixie_> | (if an editor is ignoring feedback, that seems like a larger problem) |
| 00:52 | <gsnedders> | MikeSmith: this is pretty much my job, being crazy |
| 00:52 | <roc> | I don't know, but the TAG certainly had a bigger effect than I did. |
| 00:53 | <roc> | I guess there might have been hidden Google influence in play too |
| 01:02 | <TabAtkins> | Yeah, pushing back against http was solely timbl, who is "TAG" for ceremonial purposes. |
| 01:03 | <TabAtkins> | roc: Next time a Google editor is being bad, let me know, too. He was asking me questions, but I didn't know much about what was going on. |
| 01:10 | <MikeSmith> | JakeA: the Without Streaming / With Streaming animation is https://jakearchibald.com/2016/streams-ftw/ is pretty nice |
| 01:11 | <gsnedders> | MikeSmith: besides, where would this channel be if I didn't suggest mad stuff? |
| 01:28 | <JakeA> | MikeSmith: cheers! I don't think I've ever done SVG without animating stroke offset |
| 01:28 | <JakeA> | One trick pony |
| 01:50 | <roc> | JakeA: there's some confusion about Streams here |
| 01:50 | <roc> | AFAICT everything you describe (and is implemented in Chrome) is about streams of byte |
| 01:50 | <roc> | s |
| 01:50 | <roc> | parts of the Streams spec, and discussion about Streams, mention streams of other data types, e.g. video frames |
| 01:51 | <roc> | I think the case for that is ... less compelling |
| 01:51 | <roc> | Ted's comment on your post is representative of that confusion |
| 02:08 | <JakeA> | roc: https://jakearchibald.com/2016/streams-ftw/#streaming-results these performance results aren't compelling? |
| 02:08 | <roc> | those are all byte streams |
| 02:09 | <JakeA> | Yes |
| 02:09 | <roc> | I understand that streaming processing of data is a good idea |
| 02:10 | <roc> | I'm less certain that the JS Streams API is the right API for, say, writing video codecs in JS |
| 02:12 | <roc> | likewise, I'm skeptical that MediaRecorder is a natural fit for Streams. It should be able to *produce* a Stream of bytes, of course, but I don't see it fitting in easily as a Streams transducer |
| 02:39 | <JakeA> | roc: isn't that how encoders are written now? They have config, then they're given frames |
| 02:40 | <JakeA> | Like ffmpeg takes an input file, config, and produces an output |
| 02:41 | <roc> | I had this discussion with Domenic a while back |
| 02:42 | <roc> | MediaRecorder supports pause() and resume(). Data received while paused is dropped. |
| 02:43 | <roc> | in general MediaStreams have this property that there's no backpressure. They're always real-time and data gets dropped to meet that requirement |
| 02:44 | <roc> | also they have structure in the form of tracks |
| 06:02 | <zcorpan> | i wonder what the best way is to make https://streams.spec.whatwg.org/#rs-state-diagram accessible |
| 06:06 | <zcorpan> | maybe it could have focusable boxes, with nav-left -> closed, etc? |
| 06:08 | <Hixie_> | Describe it in English |
| 06:08 | <Hixie_> | and let the image be a repetition of the prose |
| 06:25 | <zcorpan> | Hixie_: there are many arrows, i'm not sure how to describe it in a way that is easier to understand than the normative spec itself |
| 06:26 | <zcorpan> | maybe the description could just cover the no-close no-error case, and then as an afterthought say that each step can also go to closed or errored |
| 09:40 | <zcorpan> | heh, clicking the "reflect" dfn in single-page and following one of the links makes the helpful "little" box showing all the instances cover the entire page |
| 09:54 | <ritsyy> | zcorpan: for this bug https://github.com/whatwg/html/issues/293 could you give some pointers |
| 09:55 | <zcorpan> | (fixed dfn.js now) |
| 09:57 | <zcorpan> | ritsyy: commented in the bug |
| 09:58 | <ritsyy> | zcorpan: okay seeing it |
| 09:59 | <zcorpan> | neato! |
| 10:02 | <ritsyy> | zcorpan: oh yeah now i got the point, not to define one more state as the invalid value default, thanks! |
| 10:11 | <zcorpan> | philipj: hmmmm. microdata attributes don't have reflecting attributes anymore in the spec? |
| 10:16 | <philipj> | zcorpan: nope, all nuked |
| 10:17 | <philipj> | unusual, right? |
| 10:19 | <zcorpan> | maybe we should put back only the simple reflecting attributes. but i dunno |
| 10:19 | <zcorpan> | suppose i should file an issue |
| 10:20 | <philipj> | zcorpan: I doubt you'll find a browser implementor willing to add reflected attributes for things that have no effect internally |
| 10:23 | <ritsyy> | i am getting this warning, while running the build-script https://paste.kde.org/pzt0msrye |
| 10:24 | <zcorpan> | ritsyy: known issue https://github.com/whatwg/wattsi/issues/14 |
| 10:24 | <ritsyy> | zcorpan: oh okay |
| 10:25 | <zcorpan> | hmm nope, that was a bug i introduced in https://github.com/Fyrd/caniuse/pull/2239/files oops |
| 10:25 | <zcorpan> | will fix |
| 10:28 | <ritsyy> | zcorpan: yes, cool |
| 12:36 | <ritsyy> | annevk: zcorpan: for this issue https://github.com/whatwg/html/issues/513 i am not able to figure out how the other content types will process for embed element as it is in object element https://html.spec.whatwg.org/multipage/embedded-content.html#the-object-element , any pointers? |
| 12:59 | <zcorpan> | ritsyy: in the current spec i think it's covered by "If the user agent can't find a suitable plugin when attempting to find and instantiate one for the algorithm above, then the user agent must use a default plugin. This default could be as simple as saying "Unsupported Format"." |
| 13:36 | <JakeA> | roc: in terms of tracks you want to encode those separately and have a muxer deal with the joining right? |
| 13:37 | <JakeA> | roc: I disagree that an encoder must be real time. For live streams, sure, but that's not always the case |
| 14:06 | <MikeSmith> | botie, inform zcorpan wanted to ask more about the wattsi patch when you're back around and have time |
| 14:06 | <botie> | will do |
| 14:17 | <JakeA> | annevk: what time are we planning on starting? |
| 14:18 | <annevk> | Around nine, likely a little later due to logistics and setting things up |
| 14:19 | <annevk> | I will be there 8:30 to get a temp badge, forgot my own |
| 14:21 | <MikeSmith> | oh, Antti was at the meeting yesterday? |
| 14:23 | <thatprogrammer> | when a HTTP server returns a HTTP 200 on POST with Pragma: no-cache, is the POST parameters cached by the browser? |
| 14:25 | <annevk> | MikeSmith: he was, and I didn't take the chance to say hi (he left early, though) 😟 |
| 14:26 | <annevk> | thatprogrammer: what are POST parameters? |
| 14:32 | <thatprogrammer> | annevk: ur ? is irrelevant to my ? :) |
| 14:32 | <thatprogrammer> | oh, u dont even know what a POST parameter is? lol i thought u were asking what the values were >.< |
| 14:54 | <JakeA> | I'm pretty sure people on the internet are getting worse |
| 14:57 | <jgraham> | This kind of thing honestly makes me wonder if contributing to the web actually makes the world better |
| 14:57 | <jgraham> | Well this kind of thing, TwitterRage, the comments under any online news article, wtc. etc. |
| 14:58 | <botie> | zcorpan, at 2016-01-26 14:07 UTC, MikeSmith said: wanted to ask more about the wattsi patch when you're back around and have time |
| 16:02 | <ritsyy> | MikeSmith: annevk zcorpan some suggestions for this https://richarupela.wordpress.com/2016/01/26/outreachy-mid-term/ |
| 16:10 | <annevk> | ritsyy: that's great, thanks for writing that, perhaps we should move some of your tips into the readme |
| 16:12 | <zcorpan> | MikeSmith: here now for a bit |
| 16:12 | <ritsyy> | annevk: yeah that would be great :) |
| 17:01 | <JakeA> | annevk: where should we head for this meeting? Do we need to sign in at the ground floor? |
| 17:08 | <ritsyy> | Domenic: in this issue https://github.com/whatwg/html/issues/502 you said that DTDs are not to be changed, is it right because in the w3c blog DTDs are mentioned too |
| 17:11 | <Domenic> | ritsyy: hmm what W3C blog DTDs? |
| 17:11 | <Domenic> | ritsyy: ah I see |
| 17:11 | <Domenic> | ritsyy: The important sentence is "Note that this change has no effect on namespaces. The actual namespace will continue to use HTTP, even if it is also served through HTTPS. This applies as well for XMI DTD, Schema, and SGML DTDs resources." |
| 17:11 | <jgraham> | ritsyy: From the point of view of the HTML parser, DTDs are opaque strings and are not dereferenced |
| 17:12 | <Domenic> | So what the blog is saying is "we now serve the DTD over HTTPS if you happen to change the "http:" to "https:", but the official DTD URL is still the original "http:" one. |
| 17:12 | <jgraham> | And it will break stuff if you change it |
| 17:12 | <jgraham> | (in documents) |
| 17:13 | <ritsyy> | Domenic: okay got that now |
| 17:14 | <ritsyy> | jgraham: okay understood DTDs working, thanks! |
| 17:20 | <JakeA> | annevk: we're in the elevator bit |
| 23:04 | <MikeSmith> | hober: still hoping a link[rel=mask-icon] spec will appear on the scene soon |