| 00:42 | <annevk> | "Anne's behavior is quite similar to crismannoble's but crismannoble is more of a whiner." |
| 00:42 | <annevk> | "Anne is an awesome Javascripter who loves pushing code. Anne is an early-week worker who seems to work best in the wee hours." |
| 00:42 | <annevk> | Listen up TC39! |
| 00:54 | <sgalineau> | annevk, you high? |
| 01:02 | <annevk> | Heh, just playing with http://osrc.dfm.io/ |
| 01:04 | <heycam> | TabAtkins, my IRC bouncer gets confused sometimes about whether it should append an "|away" |
| 01:05 | <heycam> | TabAtkins, there is no such functionality in Web IDL yet |
| 01:05 | <TabAtkins> | heycam: So if I want to use a Map for CSSStyleRule#vars, what should I do? |
| 01:06 | <heycam> | TabAtkins, do you want this Map to dynamically reflect the variable declarations, and to affect the declarations when you set properties on it? |
| 01:06 | <TabAtkins> | Yes. |
| 01:07 | <heycam> | TabAtkins, then I think you don't want a Map, since you can't "watch" the map for changes |
| 01:08 | <TabAtkins> | Well, apparently I don't want a naked getter/setter object either |
| 01:08 | <heycam> | TabAtkins, oh, why not? |
| 01:08 | <TabAtkins> | annevk can explain better, but I think it's because just using an "object map" is subject to trickiness with things defined on the prototype chain, including Object.prototype. |
| 01:09 | <TabAtkins> | Someone can add Object.prototype.foo and it'll show up on el.style.vars.foo, even though there's no var-foo rule. |
| 01:09 | <annevk> | heycam: basically what we did for dataset is disliked by TC39 |
| 01:10 | <heycam> | annevk, I'm not sure there is a better solution currently |
| 01:10 | <TabAtkins> | The better solution is to magic up a Map. |
| 01:10 | <annevk> | TabAtkins: a Map does not have the .vars.x functionality |
| 01:10 | <TabAtkins> | (Also, using a Map probably is better in general, because you interoperate with the rest of the collection API stuff.) |
| 01:10 | <heycam> | Map just has get() and set() methods, right? |
| 01:10 | <annevk> | TabAtkins: it only has .vars.get("x") |
| 01:10 | <TabAtkins> | annevk: Right, but .vars.get('x') wouldn't kill me. |
| 01:11 | <annevk> | TabAtkins: in that case just create your own Map like URLQuery does |
| 01:11 | <heycam> | I think the problem is that Map is being thought of as an interface that you want to use for vars, but ES6's Map is a concrete class |
| 01:11 | <annevk> | TabAtkins: you need to do that anyway since you need the serialization stuff to happen |
| 01:11 | <heycam> | and a class that doesn't allow watching it for changes |
| 01:11 | <annevk> | TabAtkins: whereas Map is just in/out |
| 01:12 | <TabAtkins> | annevk: But I want it to be a Map for the purpose of working with the iterable functions, getting the rest of the Map extras, etc. |
| 01:12 | <TabAtkins> | URLQuery can't quite do that yet, because MultiMap doesn't exist. |
| 01:12 | <TabAtkins> | But I assume it's planned to do that. |
| 01:12 | <annevk> | TabAtkins: I guess, if MultiMap ever exists :) |
| 01:12 | <annevk> | (and if that matches) |
| 01:12 | <heycam> | this sounds very similar to the problem of Arrays |
| 01:12 | <TabAtkins> | Ah, it will. And I think we did a good job with it. |
| 01:13 | <TabAtkins> | heycam: It's identical to that problem. |
| 01:13 | <heycam> | there's no Array interface that we can use for things like NodeList |
| 01:13 | <annevk> | heycam: yeah, I guess you want [MapClass] or some such |
| 01:13 | <TabAtkins> | Yup yup. |
| 01:13 | <heycam> | it would be great if there were native ES6 functionality for Array-likes, Map-likes, ... |
| 01:13 | <annevk> | heycam: or map CSSVariables { ... } |
| 01:13 | <heycam> | annevk, sure, but I'd like there to be a blessed way of doing similar things in plain JS |
| 01:14 | <heycam> | annevk, so that it's obvious what an IDL map should correspond to |
| 01:14 | <TabAtkins> | heycam: There is, at least for Maps. |
| 01:14 | <heycam> | TabAtkins, oh yes? |
| 01:14 | <TabAtkins> | In teh constructor, run Map.call(this) |
| 01:14 | <annevk> | heycam: I thought you could put Array on the prototype chain? |
| 01:14 | <TabAtkins> | You'll get a mapdata set up, etc. |
| 01:14 | <TabAtkins> | And also put Map on the prototype chain to get the methods. |
| 01:14 | <heycam> | annevk, you can, but I don't think that's going to get you the "platform object wants to monitor the object for changes" functionality |
| 01:15 | <TabAtkins> | heycam: We can just define our own methods, which do some work and then defer to Map.prototype.add or whatever. |
| 01:15 | <annevk> | heycam: you'll have to implement the methods yourself, always, I think, it's just that you want to share the methods |
| 01:15 | <annevk> | heycam: share the extra methods :) |
| 01:15 | <heycam> | annevk, ok, but also prevent Map.prototype.set from working |
| 01:15 | <TabAtkins> | Ah right, yes. |
| 01:15 | <annevk> | hmm |
| 01:15 | <TabAtkins> | Also, you can't even defer to Map.prototype.get, since your mapdata is magically populated. |
| 01:16 | <heycam> | I think you want to wrap a Map object that is hidden from the outside |
| 01:16 | <heycam> | and that wrapper object has the same-feeling interface to a Map |
| 01:16 | <TabAtkins> | But this really shouldn't be a hard spec problem, any more than saying that the properties on an object are magically populated, like you can do today. |
| 01:16 | <heycam> | but forwards to the Map object inside it, as well as doing whatever other dynamic things it wants |
| 01:16 | <TabAtkins> | heycam: And, ideally, is detectably a Map using the standard testing methods. |
| 01:16 | <annevk> | TabAtkins: well, we need to get it right :-) |
| 01:16 | <heycam> | TabAtkins, that might be a problem |
| 01:17 | <annevk> | TabAtkins: once we know what's right, specifying it is not really a problem |
| 01:17 | <heycam> | you want to identify it has implementing this Map-like interface, but not being a Map object itself |
| 01:17 | <heycam> | because it's not one of these concrete Map objects really |
| 01:17 | TabAtkins | goes to read the ES spec around Maps real quick. |
| 01:18 | <TabAtkins> | If I'm right, the ideal way is to just define that the mapdata is magical, populated by something per-spec, and mutations to it have some spec effect as well. |
| 01:20 | <heycam> | and the default Map object behaviour that ES has just has no other spec effect? |
| 01:20 | <TabAtkins> | Yes. |
| 01:20 | <heycam> | sounds reasonable on first read |
| 01:24 | <TabAtkins> | The spec for .get() just grabs from the [[MapData]] internal property. We can hook this; the normal Map constructor initializes it to empty, but we could just define that it's instead filled with something specific. |
| 01:24 | <TabAtkins> | The spec for .set() appends tuples to [[MapData]], but that could be generalized or overridden to allow a hook for specs. |
| 01:25 | <heycam> | TabAtkins, so it would be nice if there were a plain JS way of doing this hooking. otherwise I can imagine complaints that we shouldn't be doing more messing with internal [[Properties]] like this |
| 01:25 | <TabAtkins> | Everything else is defined in terms of get/set or just reading from [[MapData]] directly. |
| 01:25 | <TabAtkins> | heycam: Certainly. I'll bug es-discuss. |
| 01:25 | <heycam> | cool |
| 01:25 | heycam | wonders if Arrays could be specced similarly |
| 02:12 | <TabAtkins> | heycam: Bugging done. Comment if you'd like. |
| 05:29 | <annevk> | Man, this comment syntax in VTT is annoying. |
| 05:30 | <annevk> | Well, the parser not having conformance requirements is annoying. |
| 07:17 | <zcorpan> | TabAtkins: shouldn't "reconsume the current input token" be called "unconsume the current input token" |
| 09:23 | <annevk> | I wonder what is happening to public-webapps: http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0762.html |
| 09:23 | <annevk> | It's not April 1... |
| 09:28 | <marcosc> | annevk: heh, I had to respond to that |
| 10:37 | <zcorpan> | Hixie: fail https://www.w3.org/Bugs/Public/show_bug.cgi?id=22106 |
| 11:40 | <marcosc> | sooo... anyone looked at the Web Audio API? The "Required Support for Alternate Names" seems like an epic f'up. https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#AlternateNames |
| 11:43 | <marcosc> | there is a lot of badness in that spec |
| 11:44 | <jgraham> | Well if they got past the whole "the spec is the WebKit implementation" thing, that's a win at least |
| 12:25 | <marcosc> | jgraham: but the spec doesn't even match WebKit |
| 13:31 | <annevk> | marcosc: there's a bunch of Mozilla guys on that already |
| 13:32 | <annevk> | marcosc: long and short of it is that Google managed to get some crappy API shipped on iPhone via Apple so now we're stuck with it... |
| 13:33 | <jgraham> | Is there actually a web api that has worked out OK? |
| 13:33 | <marcosc> | annevk: yeah, but why not then stick with the old names |
| 13:33 | <marcosc> | ? |
| 13:33 | <marcosc> | why have two names for things |
| 13:33 | <marcosc> | it's confusing |
| 13:33 | <jgraham> | It seems like every single one we have decided was horrible just after it shipped |
| 13:33 | <marcosc> | they have noteOn() and start(), and they don't even work as the spec says |
| 13:33 | <annevk> | jgraham: are TextEncoder and TextDecoder bad? |
| 13:34 | <jgraham> | annevk: Dunno, does anyone ship them? |
| 13:34 | <annevk> | jgraham: think so |
| 13:34 | <annevk> | marcosc: because the old names suck and methods are cheap? |
| 13:35 | <annevk> | "cheap" lest anyone thinks we should boil the ocean |
| 13:43 | <darobin> | jgraham: don't we usually realise they're horrible and then ship them anyway? |
| 13:44 | <Ms2ger> | Did someone mention webrtc? |
| 13:44 | <marcosc> | :)..... :( |
| 13:45 | <darobin> | that's beyond horrible |
| 13:45 | <jgraham> | Well there's usually a race between realising they're horrible and shipping them |
| 13:45 | <jgraham> | But somehow never between fixing them and shipping them |
| 13:46 | <marcosc> | ok, so lesson here is not to bother fixing |
| 13:46 | <marcosc> | "jQuery will fix it" :D |
| 13:46 | <marcosc> | The W3C - jQuery will fix it (TM) |
| 13:46 | <marcosc> | heh |
| 13:46 | <marcosc> | I like it |
| 13:47 | Ms2ger | fires marcosc |
| 13:48 | <marcosc> | You can't fire me! I quit! |
| 13:48 | <marcosc> | :) |
| 13:48 | <jgraham> | marcosc: To paraphrase mpilgrim, I think the moral of the story is that it’s time for us to find a new hobby. Preferably one that doesn’t involve angle brackets. Or computers. Or electricity. |
| 13:51 | <marcosc> | that would be nice |
| 15:13 | <darobin> | hsivonen: I am being asked if CC-BY addresses all the use cases in http://www.w3.org/2011/03/html-license-options.html#usecases, do you know if that happens to be the case? |
| 15:15 | <darobin> | hsivonen: I think it's the case, but I'm wondering if it's something you've checked |
| 15:46 | <tantek> | darobin - it's something I've checked, and in general it does, with the only possible source of conflicts has to do with *GPL open source where the "BY" requirement is unable to be passed on. But in practice *GPL open source projects seem to get around this somehow. |
| 15:46 | <tantek> | theoretically CC0 is best for this reason - it cleanly satisfies all the use cases |
| 15:47 | <tantek> | that being said, CC-BY is an excellent step forward here, and I think one that everyone who needs those use-cases will be able to work with. |
| 15:47 | <tantek> | the "BY" clause seems to make it a "less scary" option to some W3C folks, so if that's what it takes, to take a big step toward open licensing, I think it is worth it. |
| 16:01 | <darobin> | tantek: thanks, that's what I thought |
| 16:02 | <tantek> | darobin - hence why I'm ok supporting the CC-BY experiment for HTML5 extension specifications in the HTMLWG charter |
| 16:02 | <darobin> | note that for the code-related parts I think that in general they should fall under the W3C Software License irrespective of whether they appear in the body of the spec or not |
| 16:03 | <tantek> | darobin - that's an interesting exception clause. Perhaps we can similarly say that code-related parts in anything CC-BY we publish are subject themselves to CC0. |
| 16:03 | <tantek> | any code examples, any algorithms |
| 16:03 | <darobin> | that could probably be done without much of a problem assuming CC-BY is accepted |
| 16:03 | <tantek> | that would address the "only possible source of conflicts" case I noted above |
| 16:03 | <tantek> | indeed |
| 16:04 | <darobin> | I've asked team-legal about the current situation regarding the Software License as it's not at all clear from the current copyright document |
| 16:04 | <Ms2ger> | Does the HTML parser count as a code part? |
| 16:05 | <darobin> | Ms2ger: I doubt any interpretation would agree, but it certainly has crossed my mind :) |
| 16:39 | <TabAtkins> | zcorpan: I just copied the naming from HTML's parser. ^_^ |
| 16:43 | <dglazkov> | good morning, Whatwg! |
| 17:03 | <testtest> | alert("hello world") |
| 17:06 | window | Hello world |
| 17:06 | <testtest> | :) |
| 17:25 | <hallvors> | annevk, where art thou? |
| 17:28 | <nimbu> | miketaylr: i am sure you were referring to anne in your tweet |
| 17:28 | hallvors | goes to see what Mike is tweeting about |
| 17:29 | <nimbu> | hallvors: https://twitter.com/miketaylr/status/336894563497160704 |
| 17:29 | <nimbu> | hallvors: ALSO HAI LONG TIME NO SEE |
| 17:29 | <miketaylr> | nimbu: you can't prove that! |
| 17:30 | <hallvors> | nimbu: thanks :-D although I'm seeing you on Twitter all the time so it's more a case of "long see no time"! |
| 17:30 | <nimbu> | ahahah |
| 17:30 | <hallvors> | <3 |
| 17:31 | <Ms2ger> | Sounds more like gsnedders |
| 17:32 | <nimbu> | Ms2ger: but 15 YO |
| 17:32 | <nimbu> | on xhmlt2 |
| 17:32 | <jgraham> | Could be Hixie except for the 15 part :) |
| 17:32 | <nimbu> | :D |
| 17:32 | <nimbu> | miketaylr: put all of us out of our misery by revealing the redacted |
| 17:32 | <jgraham> | http://ln.hixie.ch/?start=1042630901&count=1 |
| 17:32 | <hallvors> | interesting exercise to come up with a list of all the people in the world who were digging XHTML at 15 |
| 17:32 | <nimbu> | ahahaha omg |
| 17:33 | jgraham | has plenty of misery but doubts that knowing who miketaylr was talking about will reduce it much |
| 17:33 | <Ms2ger> | OH: "Updated Candidate Recommendation of XPath and XQuery Functions and Operators 3.0" |
| 17:33 | <nimbu> | i want to tweet this |
| 17:34 | <nimbu> | hixie's view of xhmlt2 |
| 17:34 | <hallvors> | good old times :) |
| 17:34 | <nimbu> | lol structurally sound <l>ine element |
| 17:34 | <jgraham> | It does sound like satire now |
| 17:34 | <jgraham> | But I believe he was serious when he wrote it |
| 17:34 | hallvors | didn't write XHTML until it was out of fashion |
| 17:34 | <nimbu> | "I've gone over two years now without using it. I know this, because I set about, two years ago, to see if I could find a use case for the style attribute, and I never found one. " |
| 17:34 | <nimbu> | omg all gold here. |
| 17:34 | <nimbu> | ahahah |
| 17:35 | <jgraham> | Kind of puts paid to the idea that he can't change his mind |
| 17:35 | <jgraham> | Oh, Hixie still thinks that about the style attribute |
| 17:35 | <nimbu> | i would agree if he thinks so about css |
| 17:36 | <jgraham> | That there isn't a use case for it? |
| 17:36 | <jgraham> | Oh I see |
| 17:36 | <jgraham> | *if* |
| 17:36 | <jgraham> | Well no I think he still believes exactly what he wrote there |
| 17:37 | <jgraham> | That it is always possible to work without an inline style attribute |
| 17:37 | <jgraham> | Or at least, to the extent it isn't, that represents deficiencies in CSS |
| 17:39 | <jgraham> | Not that I can find the mail right now |
| 17:39 | <nimbu> | ha. |
| 17:39 | <hallvors> | Hixie prefers people who have class to people who have only style. Who would disagree with that? |
| 17:40 | <Ms2ger> | I remember the time he only allowed style="" on font elements |
| 17:40 | <hallvors> | that's a fontastic idea |
| 17:40 | <nimbu> | ahahahahahhaha hallvors |
| 17:40 | Ms2ger | cringes |
| 17:41 | <nimbu> | O DEAR LORD Ms2ger |
| 17:41 | <nimbu> | no |
| 17:41 | hallvors | is apparently too tired to stop making stupid jokes |
| 17:42 | <nimbu> | it is a great joake hallvors |
| 17:42 | <hallvors> | I'll licence the word fontastic to you any day Divya ;) |
| 17:43 | <nimbu> | immediately using this license hallvors THNX |
| 18:14 | <zcorpan> | marcosc: i've whined about it (web audio), but seemingly without success. please bring it up on the list (asking for the new names to be removed) |
| 18:15 | <marcosc> | zcorpan: I will |
| 18:15 | <marcosc> | I'm putting together a demo |
| 18:15 | <zcorpan> | thanks |
| 18:15 | <marcosc> | to show that it's borked |
| 18:16 | <marcosc> | ... but I literally just bought Dead Space and Dead Space 2 for EU10 on Steam... so I'm gonna go play! :D |
| 19:33 | <Yuhong> | Wonder if Hixie is at Google I/O or something. |
| 19:38 | <tantek> | #googleio was last week |
| 19:40 | <jgraham> | I believe Hixie is away for a few days |
| 19:40 | <jgraham> | or s/days/weeks/ perhaps |
| 19:40 | <Ms2ger> | Monthish |
| 19:42 | <jgraham> | Which is "a few weeks", more or less :p |
| 19:42 | <jgraham> | (days was a misleadingly small unit) |
| 19:43 | <hober> | Yuhong: he's on (or at least was on) vacation |
| 19:45 | <Yuhong> | I wanted to mention that the crash in http://ln.hixie.ch/?start=1115899732&count=1 |
| 19:46 | <Yuhong> | Was later rediscovered in http://blogs.norman.com/2011/security-research/drag-and-drop-vulnerability-in-ms11-050 and it turned out to be a exploitable crash fixed in MS11-050. |