| 00:38 | <gavinc> | heh, thanks TabAtkins for the comment to the RDF-WG, feeling very lonely beating that drum sometimes |
| 00:38 | <TabAtkins> | gavinc: No problem! |
| 00:38 | <TabAtkins> | This is for the json-ld comment? |
| 00:39 | gavinc | nods |
| 00:43 | <gavinc> | Also starting to get all the lovely "You can't link to DOM4 and HTML5" nonsense |
| 00:43 | <TabAtkins> | Asdhfa;lsjkd |
| 00:46 | <gsnedders> | gavinc: Because they're drafts? |
| 00:46 | <gavinc> | Yep. |
| 00:47 | <gsnedders> | gavinc: So it's fine if I build my JSON-LD impl on top of dbaron's desk HTML4 impl? |
| 00:47 | <gavinc> | Nope. |
| 00:47 | <gsnedders> | But I like building on top of solid bases! |
| 00:47 | <gavinc> | Same with new HTML data type ;) Doesn't work with DOM3, only works with DOM4 but may link to DOM3 anyway, yay process :D |
| 00:48 | <gsnedders> | Complete and utter bullshit. As normal. |
| 00:48 | <TabAtkins> | Wait, json-ld allows html? |
| 00:49 | <TabAtkins> | Like, not as strings? Or just as strings? |
| 00:52 | <gavinc> | RDF does. |
| 00:52 | <gavinc> | https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-html |
| 00:53 | <gavinc> | therefor, JSON-LD does. |
| 00:54 | <TabAtkins> | So... as strings, or as raw? |
| 00:54 | <gavinc> | ... both? |
| 00:54 | <gavinc> | ewll |
| 00:54 | <gavinc> | JSON-LD as Strings |
| 00:54 | <TabAtkins> | Okay. So it's not actually JSON at all, then. |
| 00:54 | <TabAtkins> | Ah, kk. |
| 00:55 | <gavinc> | but by "value" as a DOM |
| 00:56 | <gavinc> | there is a lexical-to-value mapping, which defined at the moment in terms of DOM4 and the fragment parsing algorithm, but what SHOULD be https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#parsing |
| 00:56 | <zewt> | heh, just to confuse things, the json api for java is "JSONObject" (which is nothing but a simple map with some helpers on it), so now people think there's such a thing as a "json object" |
| 00:56 | <gavinc> | since the design is for a fragment of HTML that came from or should go into a complete HTML document |
| 00:57 | <zewt> | gotta love trivially simple json apis using inheritance where it makes no sense whatsoever |
| 00:57 | manu1 | notices people talking about JSON-LD... wakes up. |
| 00:57 | gavinc | waves to manu1 |
| 00:57 | manu1 | waves back at gavinc. :) |
| 00:57 | <TabAtkins> | manu1: Just json-ld people being bureaucracy-stupid. |
| 00:58 | <TabAtkins> | We've already complained in the appropriate channels, and are just bitching now. ^_^ |
| 00:58 | <zewt> | that's what irc is there for |
| 00:58 | <manu1> | TabAtkins: Well, kinda... we followed the node.js model... and want to know why we should do futures instead of the node.js callback approach. |
| 00:59 | <manu1> | TabAtkins: Don't know if you know this or not, but I'm the primary editor of the JSON-LD 1.0 Syntax spec... :) |
| 00:59 | <gavinc> | Yes, we depend on DOM4 and also a spec (template or some other fragment parsing method) that isn't really at all done yet, deal with it ;) |
| 00:59 | <manu1> | so I'd like to think that we're not being as retarded as it's coming across, but maybe we are. |
| 01:00 | <TabAtkins> | manu1: Because the node.js/jquery model is based on a pre-promises world. Promises are the *correct* solution to handling completion/error callbacks. |
| 01:00 | <TabAtkins> | And DOM Futures are the implementation fo promises. |
| 01:00 | <manu1> | TabAtkins: one approach we discussed was doing a futures-lite approach w/o referencing the DOM4 spec. |
| 01:00 | <TabAtkins> | manu1: That's the bureaucracy-stupid I was talking about. |
| 01:00 | <manu1> | TabAtkins: got a link to some long-form argument for why promises are better than the node.js model? |
| 01:00 | <gavinc> | Just reference DOM4! If you have any HTML literals your going to need it anyway ;) |
| 01:01 | <gavinc> | I don't care what eric says :P |
| 01:01 | <manu1> | gavinc: We don't have HTML literals, luckily, in JSON-LD. |
| 01:01 | <zewt> | would sure have been nice if there was any discussion at all (use cases, justification, design)about "futures" (painfully buzzwordy name, by the way) on whatwg or webapps, rather than them just mysteriously appearing wholly formed; very much took me by surprise |
| 01:01 | <gavinc> | manu1: Yeah, but RDF Concepts does ;) |
| 01:01 | manu1 | nods at zewt. |
| 01:01 | <TabAtkins> | manu1: Pretending that you have to engineer around a reference is putting bureaucracy ahead of *all the rest of the more important constituency groups*. |
| 01:02 | <TabAtkins> | zewt: There was tons of discussion, over the last several years of development in the rest of Javascript land. |
| 01:02 | <zewt> | none that i've seen, except in the form of JS novices not understanding events |
| 01:02 | <manu1> | TabAtkins: yes, yes, I am a believer... you don't have to convince me of that point. However, I also need to thread the W3C process needle, so I need to create some clear path forward that doesn't require me to go an change W3C process. |
| 01:03 | <TabAtkins> | But basically: Futures turn the concept of "an event that will either complete or error at some future time" into a first-class object. This (a) gives us a standard API to design against, which is better for authors, and (b) lets us design a useful algebra over them, which is non-trivial in the current ad-hoc callback/event world. |
| 01:03 | <manu1> | TabAtkins: If there was tons of discussion, surely somebody has written up a clear set of argumentation for why futures are the future. |
| 01:03 | <TabAtkins> | manu1: The process needle is yours to thread, but it's the least important thing in the entire spec. |
| 01:03 | gavinc | coughs at manu1, and being at PR is important... 'cause? ;) |
| 01:03 | <TabAtkins> | manu1: Importantly, if you're making bad technical decisions just to hit the vaunted "Rec" status, you're doing the wrong thing. |
| 01:04 | <zewt> | (mostly I don't like that it's a separate underlying mechanism, instead of an abstraction on events, so we don't have an ugly low-level schism) |
| 01:04 | <TabAtkins> | Remember the ordering of constituencies: technical purity < implementors < authors < users. |
| 01:04 | <TabAtkins> | And "bureaucracy" is either part of technical purity, or something even further below it. |
| 01:05 | <manu1> | TabAtkins: There are two things going on here: 1) I'm not entirely convinced that futures are the messiah they're being made out to be and I'd like to read something about why they are, and 2) W3C process stuff is a reality I have to deal with, so if I'm going to ask the JSON-LD group to go through another Last Call, I'd like to have a very good reason to do so. |
| 01:05 | <TabAtkins> | zewt: Events have their own baggage and problems. They're reasonably well-designed for their original use-case, that of dealing with events in a tree structure. They're overdesigned for anything not in a tree structure. |
| 01:05 | <manu1> | gavinc: PR / REC is important because it means I can move on to working on the Web Payments stuff ( https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/ ) instead of dealing w/ low-level representation stuff :) |
| 01:06 | <TabAtkins> | Overdesigned/expensive (you can't, for example, ever forget about listeners). |
| 01:06 | <TabAtkins> | manu1: Or you can just leave the spec at CR! That's also a solution, and lets you do your thing. |
| 01:06 | <TabAtkins> | A spec isn't "done" at Rec any more than it is at CR. |
| 01:06 | <manu1> | TabAtkins: Please, please, please write a blog post about this, or ask someone that can to do so - it's going to be very difficult for me to make an argument based on what I'm seeing in this chat channel. |
| 01:06 | <zewt> | the design is very well-understood |
| 01:07 | <gavinc> | manu1: there is a comment in rdf-wg-comments ;) perhaps he should expand it ? :D |
| 01:07 | <manu1> | that would work too. |
| 01:07 | <TabAtkins> | manu1: Planning on doing so. I'm currently messing around with my blog post for a DOM EventStream proposal, built on the precedent of Futures. ^_^ |
| 01:08 | <manu1> | TabAtkins: If we can figure out a way to put futures into the JSON-LD API and get to REC, let's do that (if it's the right thing to do). |
| 01:08 | <zewt> | anyway, it would just have been nice to have the opportunity to offer input and perhaps a counterproposal, but the api appearing whole cloth makes me not motivated to bother (seems like minds have already been made up) |
| 01:08 | <TabAtkins> | manu1: And if it's a choice between putting futures in, and going to Rec, the right choice is to put futures in. Rec is a non-goal for a spec, it's solely a process checkbox. |
| 01:09 | <TabAtkins> | zewt: It's based directly on Promises/Aplus, which has established itself as being the most popular and most theoretically reasonable version of promises. |
| 01:09 | <manu1> | TabAtkins: Not to certain big companies that want to use the technology... REC is an internal requirement for them. |
| 01:10 | <manu1> | TabAtkins: Like it or not, not all companies believe in perma-development for specs (even if it is reality in many cases) |
| 01:10 | <gavinc> | RDF-WG already has to deal with the DOM4 issue, or lie about rdf:HTML |
| 01:10 | <TabAtkins> | manu1: They're welcome to change their policies. Hurting the entire web for the sake of short-term corporate silliness is not a good tradeoff. |
| 01:10 | <manu1> | Why does rdf:HTML depend on DOM4 ? |
| 01:10 | <TabAtkins> | manu1: It depends on the fragment parsing algorithm. |
| 01:11 | <zewt> | "most popular" isn't exactly a compelling argument :) |
| 01:11 | <manu1> | TabAtkins: You're doing your own 'technical purity' argument there - you're arguing from a 'philosophical purity' standpoint. |
| 01:11 | <zewt> | manu1: not sure i'd call "good for the web" a philosophical point |
| 01:12 | <manu1> | TabAtkins: I happen to agree with much of your philosophical purity arguments, but I also have a business to run and getting things to a state that convinces other companies to start using the technology is a driving factor for the work we do. :) |
| 01:12 | <TabAtkins> | manu1: No, I'm arguing for the users. Just a wider set of users - the web, and the *actual developers* in those companies - rather than the company lawyers. |
| 01:12 | <manu1> | zewt: It is a philosophical point :) - I agree with it, but let's call it what it is - it's a philosophy... just like 'good for large corporate interests' is a philosophy... and 'good for the market' is a philosophy. |
| 01:12 | <TabAtkins> | This is no more a theoretical purity argument than arguing about a point relevant to, say, disabled users. |
| 01:13 | <tantek> | manu1 - re: "REC is an internal requirement … for certain big companies that want to use the technology" - those companies rarely (ever?) make/break any kind of adoption curve - they're very much late adopters (after the market has settled on something) so there's no need to cater to such companies whatsoever. |
| 01:13 | <TabAtkins> | (Not intending to invoke a11y deliberately, just the first relevant type of group that pops in.) |
| 01:13 | <zewt> | manu1: however you put it, i definitely don't see an analogy from it to "technical purity" |
| 01:14 | <manu1> | tantek, TabAtkins, zewt: Ok, we're venturing into perma-thread territory here, so I retract my desire to discuss philosophical points (or whether or not something is a philosophical point). |
| 01:14 | <zewt> | uh okay? heh |
| 01:15 | <tantek> | do you also retract bringing up whether REC matters and large companies that care (or not) about REC status? there is no new data on that front. |
| 01:15 | <manu1> | TabAtkins, tantek, zewt: All I'd like help with is figuring out if futures are the right solution for the JSON-LD API, how to get futures into the JSON-LD API, and get to REC at W3C. It seems like something that is do-able... just wondering if anybody else in here has been through that process before. |
| 01:15 | <TabAtkins> | Recall that I live mostly in a group that strongly follows W3C Process, but also manages to be agile and make good technical decisions without fretting about this kind of thing. |
| 01:16 | <manu1> | tantek: I've had discussions with large companies that are thought of as cutting-edge that have asked us when certain specs we're working on are going to get to REC, because they'd like to adopt them when they do. |
| 01:16 | <tantek> | manu1 - which process? taking something to REC? have a few of those. turned out to not really matter much between CR and REC> |
| 01:16 | <manu1> | tantek: No, the process of taking a W3C spec to REC with an API that depends on futures. |
| 01:17 | <manu1> | tantek: specifically, DOM4 Futures. |
| 01:17 | <manu1> | tantek: Also, documentation on why futures are preferable over node.js-style continuation callbacks. |
| 01:17 | <manu1> | tantek: as in a complete blog post on the matter. |
| 01:17 | <tantek> | manu1 "companies that are actually (not just thought of as) cutting-edge" ∩ "when certain specs we're working on are going to get to REC, because they'd like to adopt them when they do" = ∅ |
| 01:18 | <TabAtkins> | (Technically, it's not DOM4. It's WHATWG's DOM.) |
| 01:18 | <manu1> | even worse :) |
| 01:18 | <manu1> | (as in worse from a political standpoint) |
| 01:18 | <manu1> | (not a technical one) |
| 01:19 | <tantek> | manu1 - if caring about the politics is stopping you from getting work done, you're doing it wrong. |
| 01:19 | <manu1> | tantek: It's not stopping us from getting work done at all, I think you're missing some details of what we're discussing. |
| 01:20 | <tantek> | spec it, test it, code it, ship it - if what you've spec'd/tested/coded is good, others will do so as well and interoperate, if it's not, they won't. no amount of political gladhandling/announcements/PR will make a difference compared to implementing/shipping. |
| 01:20 | <tantek> | manu1 - you're the one that bothers to bring up "worse from a political standpoint" - ergo, you care about the politics. if you didn't care about the politics, you wouldn't bring them up. |
| 01:21 | <manu1> | tantek: we've spec'd it, tested it, coded it and shipped it. Nobody complained except for Tab and Boris. |
| 01:21 | <manu1> | When Boris and Tab say something, I try to listen and figure out why they're saying what they're saying (out of respect for their point of view) |
| 01:21 | <manu1> | so this is me trying to figure out what they're saying. |
| 01:21 | <tantek> | shipping = interoperable implementations in an implementation report |
| 01:21 | <tantek> | not shipping a spec |
| 01:22 | <manu1> | we have interoperable implementations in an implementation report - 5 of them. |
| 01:22 | <tantek> | on the public web? or is this more pretend-web? (intranets etc.) |
| 01:22 | <manu1> | public web |
| 01:23 | <tantek> | well congrats then. now you just have to iterate to keep up with market demands. |
| 01:23 | <manu1> | tantek: That's why I'm having this discussion w/ TabAtkins :) |
| 01:23 | <manu1> | tantek: Trying to figure out if we need to change from node.js-style callbacks to futures |
| 01:23 | <tantek> | yup - asking why futures are good technically is a good path forward |
| 01:23 | <tantek> | all the politics/process/REC crap is not |
| 01:23 | <manu1> | tantek: exactly - which is what we're doing here. |
| 01:24 | <manu1> | tantek: Know any convincing posts on why futures are better than node.js-style callbacks? |
| 01:24 | <tantek> | manu1 - your technical message/questions would be more credible with fewer (preferably zero) mentions of politics/process/REC crap |
| 01:24 | <tantek> | have found that when people mention both, they're confused about the relevance (lack thereof) of politics/process/REC crap |
| 01:24 | <manu1> | tantek: Tab is the one that brought up the politics/process/REC crap. |
| 01:25 | <manu1> | I was responding to an e-mail he sent to a W3C mailing list. |
| 01:25 | <TabAtkins> | Okay, finished my current batch of edits to my event-stream proposal. I'll write up a quick Futures defense now. |
| 01:25 | <manu1> | TabAtkins: /thank you/ - that would be super helpful. |
| 01:25 | manu1 | goes back to sleep. |
| 01:26 | <tantek> | manu1 - seemed to me you were the one discussing it more. but then hey if you're willing to drop it, so am I. ;) |
| 01:26 | <manu1> | tantek: It's a perma-thread that doesn't result in technical work getting done... so yeah, let's drop it. :) |
| 01:30 | <Hixie> | ok i worked out why annevk wasn't able to file bugs |
| 01:30 | <Hixie> | turns out i had an early "return" right before the code that actually filed the bug |
| 01:30 | <Hixie> | so that i could test it without filing bugs the other day |
| 01:30 | <Hixie> | "oops" |
| 01:30 | <Hixie> | so if anyone tried to file bugs... sorry... |
| 01:41 | <tantek> | in other news, EmotionML apparently exited CR: http://www.w3.org/TR/2013/PR-emotionml-20130416 with supposedly several implementations: http://www.w3.org/2002/mmi/2013/emotionml-ir/#systems |
| 01:44 | <tantek> | <emotionml xmlns="http://www.w3.org/2009/10/emotionml"><emotion><category name="Surprise" value="0.5"/><category name="Amusement" value="0.5"/></emotion></emotionml> |
| 01:53 | <a-ja> | <emotion><category name="Sarcasm" value="1.0"/>I didn't even get a mention in the spec</emotion> |
| 03:56 | <superm401> | I'd like to request an account on http://wiki.whatwg.org/ so I can register a meta extension. |
| 04:14 | <MikeSmith> | superm401: what username? |
| 04:14 | <superm401> | mattflaschen |
| 08:39 | <zcorpan> | anyone here have opinions on https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#AlternateNames ? |
| 09:49 | <annevk> | zcorpan: there's no way that can be killed? |
| 11:19 | <zcorpan> | annevk: of course there is a way. |
| 11:20 | <zcorpan> | annevk: i bet it would be effective if mozilla were to say "we're not gonna implement the legacy names" :-) |
| 11:20 | <annevk> | For all I know we asked for them to be defined :) |
| 11:21 | <annevk> | Though that specification is sketchy at best |
| 11:21 | <zcorpan> | i don't know what the history is here |
| 11:21 | <zcorpan> | except apparently gassa had complained about it before me |
| 11:22 | <zcorpan> | i would be happier with just the legacy names than duplicated API surface |
| 11:22 | <zcorpan> | but i don't see that the compat claim is valid in the first place |
| 11:24 | <zcorpan> | s/gassa/mage/ |
| 11:26 | <annevk> | mage? |
| 11:27 | <annevk> | You could make that comment on the mailing list |
| 11:27 | <annevk> | You should probably also suggest they ask review on public-script-coord |
| 11:28 | <annevk> | I guess it would be clearer if I made the http/https stuff in http://fetch.spec.whatwg.org/#basic-fetch a list of steps right? |
| 11:57 | <zcorpan> | annevk: i already commented on the mailing list. though haven't suggested -coord |
| 12:43 | <hsivonen> | so much fallout from the Encoding Standard tweaking the meaning of the UTF-16 label |
| 12:44 | <zcorpan> | apparently using ` in commit message is a bad idea |
| 12:44 | <annevk> | hsivonen: the idea was for there not to be fallout, if there is maybe we should fix the spec? |
| 12:46 | <hsivonen> | annevk: let's not go there before analyzing this |
| 12:46 | <annevk> | k |
| 12:50 | <hsivonen> | aargh. yet another use of the encoding detector that I was unaware of |
| 12:51 | <hsivonen> | when attaching a file, guessing the charset and then sending the guess as authoritative metadata |
| 12:51 | <hsivonen> | yay authoritative metadata |
| 13:10 | <hsivonen> | Sharing encoding code between a Web engine and an email client is such a pain. |
| 13:16 | <annevk> | I sort of think that the email encoding stuff should match the web encoding stuff. But if they've really diverged then it is indeed problematic :( |
| 13:18 | <zcorpan> | hmm, i get easily confused by writing modes. anyone have suggestions for how to fix the spec here? http://www.w3.org/mid/A592E245B36A8949BDB0A302B375FB4E0D242ABFEC⊙Mml |
| 13:18 | <zcorpan> | i was thinking of defining terms "logical top" etc, but i'm not sure how things work when the ancestor chain have different writing modes or stuff like that |
| 13:29 | <annevk> | CSS really ought to define all these box concepts in the long run so CSSOM can simply provide script hooks |
| 13:29 | <annevk> | In other words, you don't want to define the model twice |
| 14:03 | <hsivonen> | I really need to make moving bugzilla.validator.nu out to a different VM and making validator.nu not to default to HTML4 higher priorities |
| 14:03 | <hsivonen> | :-( |
| 14:17 | <MikeSmith> | hsivonen: I can work on the not-default-to-HTML4 part if you want |
| 14:18 | <MikeSmith> | bugzilla.validator.nu has been painfully slow for a couple of weeks now at least |
| 14:18 | <MikeSmith> | often to the point of being near-unusable |
| 14:19 | <MikeSmith> | but honestly not sure how many other people are affected by it |
| 14:19 | <MikeSmith> | I think I'm the main user by a longshot |
| 14:20 | <MikeSmith> | still, I can imagine that it might have caused a few people who wanted to report a bug to just give up |
| 14:20 | <MikeSmith> | while waiting for it to respond with the bug-entry form |
| 14:23 | <hsivonen> | MikeSmith: well, if you work on the not-default-to-HTML4 part, bugzilla.validator.nu is likely to become faster :-) |
| 14:23 | <hsivonen> | but really, I should different things on different VMs and just pay a little more for hosting |
| 14:23 | <hsivonen> | *should put |
| 14:24 | <hsivonen> | but not gonna happen in the next 3 weeks :-/ |
| 14:24 | <hsivonen> | maybe after |
| 14:26 | <MikeSmith> | ok |
| 14:36 | <annevk> | Anyone a better name for "basic fetch"? |
| 14:36 | <annevk> | Oh, and reviewing http://fetch.spec.whatwg.org/#fetching is appreciated, even though not all the details are hashed out yet |
| 14:39 | <gavinc> | "For now, unfortunate as it is, file URLs are left as an exercise for the reader." wimp |
| 14:41 | <annevk> | gavinc: I defined file URL parsing (by generalising a Windows-specific bit to happen everywhere), file URL fetching however is even more heavily tied to platforms :( |
| 14:42 | <annevk> | Also, all browsers have a different origin model with respect to file URLs. |
| 14:42 | <gavinc> | yeah :\ |
| 14:46 | <gavinc> | annevk: after 10, of http... if manual redirect flag IS set... does it return the response or the redirect? I guess it's the response, which is now a redirect per 9... okay |
| 14:46 | <gavinc> | err... per 8 |
| 14:47 | <annevk> | gavinc: yeah, you'd get a response that's flagged as a redirect |
| 14:49 | <annevk> | gavinc: I've been thinking of changing that to something like set response's type to redirect |
| 14:49 | <gavinc> | +1 |
| 14:50 | <gavinc> | http: 5, cookies, is where anything dealing with the fact that some cookies should or shouldn't be sent via HTTP and only HTTPS will end up living? |
| 14:51 | <gavinc> | Or just going to refer to 6265? |
| 14:52 | <annevk> | It's mostly about whether we'll include them at all |
| 14:53 | <annevk> | And then we need equivalent wording for the response, to whether or not Set-Cookie headers will be honored |
| 14:55 | <manu-db> | TabAtkins, annevk, gavinc: Response to Tab's post on DOM4 Futures and JSON-LD API, would like to know if I'm wrong: http://lists.w3.org/Archives/Public/public-linked-json/2013Apr/0016.html |
| 15:02 | <annevk> | manu-db: the spec is done... |
| 15:02 | <annevk> | manu-db: do the other languages support Web IDL? |
| 15:02 | <annevk> | in general that kind of argumentation for web apis is flawed imo |
| 15:37 | <TabAtkins> | zewt: See my blog post at http://www.xanthir.com/b4PY0 for an explanation of the value of Futures. |
| 15:41 | <TabAtkins> | manu-db: I have rebuttals to a few of your points, but I'm not subscribed to that list. What's the best way to respond for you? |
| 15:44 | <darobin_> | oooh, XML Core asking about the removal of xml* properties from the DOM! |
| 15:44 | darobin_ | gets some popcorn |
| 15:45 | Ms2ger | wishes that people would spend their time on adding tests rather than trying to remove them |
| 15:46 | <TabAtkins> | manu-db: Oh wait, I see you kept me in the reply loop. I'll just reply to that, then. (Sorry, hadn't gotten through all my mail yet.) |
| 15:49 | <manu-db> | TabAtkins: Yeah, you should be able to respond to public-rdf-comments - your comment should stick there (it's an open list) |
| 15:49 | <Ms2ger> | tobie, stop trolling and go do something useful |
| 15:50 | <tobie> | Ms2ger: :) I return the comment. |
| 15:50 | <tobie> | More seriously, though… I feel khronos stuff should belong in khronos test suites |
| 15:50 | <TabAtkins> | Does anyone know what version of promises Node originally shipped with? |
| 15:50 | <TabAtkins> | manu-db: ^^^ ? |
| 15:51 | <manu-db> | annevk: re: spec done-ness - I meant "done" in a "multiple interoperable implementations" sense... |
| 15:51 | <tobie> | TabAtkins: think node pre-dated the CJS promise effort |
| 15:51 | <manu-db> | TabAtkins: It was a fairly crappy version of Promises (or rather, that's what the Promises Gurus argued) |
| 15:51 | <annevk> | fair enough |
| 15:51 | <annevk> | darobin: hehe, I replied... |
| 15:51 | <manu-db> | TabAtkins: It was node 0.2 that removed promises, in favor of callback management, iirc |
| 15:52 | <manu-db> | TabAtkins: Let me try and find out more about which version of promises shipped w/ node.js 0.2 |
| 15:52 | <tobie> | Ms2ger: which doesn't mean we can't ultimately run these test suites too. |
| 15:52 | <TabAtkins> | manu-db: Thanks - without much knowledge, my searches aren't turning up much useful, just a bunch of userland promise libraries. |
| 15:52 | <tobie> | Ms2ger: just that, as with ES, there is no point duplicating the effort. |
| 15:53 | <manu-db> | TabAtkins: probably going to have to dive into the node.js commit logs or code at v0.2 |
| 15:53 | <TabAtkins> | manu-db: Not willing to do that, so I'll just take you at your word that it was some crappy version of promises. |
| 15:54 | <annevk> | I think I only got part of the email to http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/ :/ |
| 15:54 | <manu-db> | TabAtkins: "crappy" - the pro-promises people were saying that node.js wasn't including certain features that made promises really compelling. The anti-promises people were arguing that node.js shouldn't pick a winner when it came to asynchronous program control flow. |
| 15:56 | manu-db | notices that there is a completely separate Future's discussion happening on public-script-coord... thanks annevk for the link. |
| 15:57 | <manu-db> | TabAtkins: I remember seeing some sort of argumentation that you could build promises on top of a callback management approach, but you couldn't build callback management on top of promises. It sounded like a compelling argument on the surface, but then it seemed like you could do either (and then I stopped thinking about it because of another fire that needed to be put out). |
| 15:58 | <TabAtkins> | Pretty sure you can do either, but I'd have to get into details to make sure. |
| 15:58 | <marcosc> | heh, public-script-coord is on fire :) |
| 16:01 | <darobin> | oh great, now Anne has made TC39 blame W3C for forking Futures into the WHATWG spec |
| 16:01 | <darobin> | let me call up my friends in MPEG to make this really interesting |
| 16:02 | manu-db | wonders when this turned into a 'turf war'? |
| 16:02 | marcosc | chews his pop corn loudly and watches with concern ... and a little entertained smirk... but mostly concern |
| 16:02 | <manu-db> | aren't we just talking about virtual words on a virtual page? |
| 16:02 | <marcosc> | manu-db: we are in a constant state of "cold war" |
| 16:03 | manu-db | wonders who is "winning"... because it doesn't seem like it's W3C, or IETF, or TC39, or WHATWG, or MPEG, or... |
| 16:05 | <annevk> | I need more popcorn |
| 16:05 | <darobin> | well, so long as there are companies that don't know what else to do with their research centres than churn out patents, and so long as there are hapless academics looking for cheap "industrial" validation, then MPEG will be winning (at the game they're playing) |
| 16:06 | <darobin> | as for those of us who care about the actual platform, indeed, I'm not sure |
| 16:11 | <annevk> | Certainly in a way this situation seems similar to ArrayBuffer... We ask for it in 2006. Khronos delivers. TC39 mourns in 2012. |
| 16:13 | <gavinc> | darobin: No, I can happily say LAWYERS are winning. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2247195 |
| 16:16 | <annevk> | happily? |
| 16:16 | <gavinc> | happy to be able to say backed up with data |
| 16:16 | <gavinc> | not just a feeling any more |
| 16:17 | <nimbu1> | where is this drama happening |
| 16:19 | <jgraham> | Oh man "promises are in es7" |
| 16:19 | <jgraham> | I look forward to 2029 or whenever that will be done |
| 16:20 | <jgraham> | And by "done" I mean "implemented" of course, not "ratified by the standards body" |
| 16:20 | <jgraham> | But you all knew that |
| 16:31 | <annevk> | jgraham: for you: http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0143.html |
| 16:32 | <Ms2ger> | http://lists.w3.org/Archives/Public/public-respimg/2013Apr/0001.html |
| 16:33 | <annevk> | o_O |
| 16:33 | <annevk> | but yeah, if people want something, they'll make it happen |
| 16:37 | <Ms2ger> | "XML Signature and XML Encryption are W3C Recommendations" |
| 16:38 | <manu-db> | TabAtkins: Promises were dropped in node.js v0.1.30 on Feb 19th, 2010: https://groups.google.com/forum/?fromgroups=#!msg/nodejs/jaufClrXU9U/ov5WHIk7SAwJ |
| 16:51 | <manu-db> | TabAtkins: found it - http://manu.sporny.org/tmp/node-0.1.29-api.html#_tt_events_promise_tt |
| 16:51 | <manu-db> | looks pretty craptacular... the node.js 'q' module (better promises for Node.js) is much better: https://npmjs.org/package/q |
| 16:52 | <darobin> | annevk: good point here https://twitter.com/rem/status/324533773360320514 |
| 16:53 | <annevk> | darobin: why would you not use .add('foo', 'bar')? |
| 16:54 | <TabAtkins> | manu-db: Ugh, jeezus, that's a bad promises API. No *wonder* it failed. |
| 16:54 | <darobin> | well if you're from HTML land, "foo bar" sort of makes sense |
| 16:54 | <divya> | annevk: because class names are strings ya |
| 16:54 | <darobin> | I'm not saying it's a feature to die for, but it makes sense |
| 16:54 | <divya> | yes |
| 16:54 | <divya> | its intuitive |
| 16:54 | <darobin> | it beats an exception with a big stick in any case |
| 16:56 | <darobin> | anyway, people are opening beers in the office |
| 16:56 | TabAtkins | dbaron, would it help if I published Colors 4 ED with one of those big "Not Ready for Implementation" messages for now? |
| 16:57 | <annevk> | divya: then just do .className += "foo bar" |
| 16:57 | <annevk> | divya: if you want to deal with strings |
| 17:01 | <SimonSapin> | TabAtkins: wrong channel? |
| 17:02 | <tobie> | annevk: well, that doesn't work for .remove("foo bar") and you do want some consistency here. |
| 17:08 | <annevk> | tobie: classList is not a string, it's a list of tokens |
| 17:09 | <tobie> | annevk: in the developer's perspective, this is an implementation detail. |
| 17:10 | <annevk> | it seems super silly to support both spaces and "foo", "bar", "x" notation |
| 17:10 | <tobie> | annevk: the dreadful API for getElementsByClassName created this weird precedent. |
| 17:11 | <annevk> | people should use querySelector or .find when it's out though |
| 17:12 | <annevk> | getElementsBy* are not really encouraged anymore |
| 17:13 | <annevk> | seems to me though that if you store classes as a string you're doing it wrong |
| 17:13 | <tobie> | annevk: I'm by nature more of a formalist than the mean, so I tend to agree with you. But most devs don't, and they just want things to work, whatever they throw at it. |
| 17:14 | <annevk> | I don't have strong opinions either way. We discussed this and decided variadic were the way to go, so I added those. |
| 17:15 | <annevk> | We can add this too, but I rather have browser developers work on more interesting features. |
| 17:15 | <jgraham> | I just want it to work whatever I throw at it doesn't really help for progamming in the large though |
| 17:15 | <karlcow> | and then… element.classList.add(‘foo\nbar’); or element.classList.add(‘foo\tbar’); |
| 17:15 | <jgraham> | I needed more quotes there |
| 17:16 | <tobie> | jgraham: that depends on the size of the project and the team. |
| 17:17 | <jgraham> | Well "in the large" is sort of the limit as those things tend to infinity |
| 17:17 | <tobie> | in general, the web platform is too strict to make small teams happy, and too loose for real large projects. |
| 17:17 | <dglazkov> | good morning, Whatwg! |
| 17:17 | <jgraham> | (except it probably isn't because projects probably get increasingly difficult as the team gets bigger or something, so it doesn't really matter what's good if you have a million programmers because everything will be terrible anyway) |
| 17:20 | <annevk> | karlcow: we always cater to those ;) |
| 17:20 | <karlcow> | heh |
| 17:21 | <annevk> | tobie: I think that depends on what room of the platform you happen to stumble into |
| 17:22 | <gsnedders> | jgraham: https://github.com/html5lib/html5lib-python/issues/21 |
| 17:22 | <gsnedders> | jgraham: Because, like, I want to get 1.0b1 out this month :P |
| 17:23 | <tobie> | annevk: possibly. The point remains that there are very different audiences with conflicting requirements. |
| 17:23 | <annevk> | tobie: there's everything from the too low-level (endianness?!) to the probably too high-level (String.prototype.anchor?) |
| 17:23 | <tobie> | don't you love the later? |
| 17:23 | <tobie> | s/later/latter/ |
| 17:24 | <annevk> | yeah, after the usual sadness delay I typically come to love the quirks |
| 17:25 | <marcosc> | stockholm syndrome is awesome |
| 17:25 | <annevk> | unless they don't stop biting me, like <image> |
| 17:25 | <annevk> | there's some issues on document.createElement("image") needing to create HTMLImageElement whose localName is "img" |
| 17:25 | <karlcow> | marcosc: :D |
| 17:25 | <annevk> | now that's some fucked up shit |
| 17:28 | <marcosc> | annevk: lol, I didn't know that one |
| 17:28 | <marcosc> | that's awesome |
| 17:28 | <marcosc> | who introduced that gem? |
| 17:28 | <Ms2ger> | marcosc, not in Gecko, fwiw |
| 17:28 | <marcosc> | Ms2ger: get to it! implement it now! |
| 17:28 | <marcosc> | :) |
| 17:30 | <jgraham> | It's not really high-level vs low-level though |
| 17:30 | <jgraham> | It's strict vs loose |
| 17:30 | <jgraham> | Or something |
| 17:30 | <Ms2ger> | It's crap and other crap? |
| 17:31 | <jgraham> | gsnedders: Do I need a sourceforge account? |
| 17:31 | <annevk> | it's not vs I think |
| 17:31 | <annevk> | it's the whole spectrum |
| 17:31 | <jgraham> | Well of course |
| 17:31 | <annevk> | usually a function of the people involved |
| 17:32 | <gsnedders> | jgraham: I think so. |
| 17:32 | <annevk> | and due to lack of overall design |
| 17:32 | <annevk> | which is somewhat improbable |
| 17:32 | <jgraham> | But it is useful to know if there is a set of principal axes which allow you to model the problem without the full complexity |
| 17:51 | <annevk> | TabAtkins: FYI, W3C has ISO support these days but yeah, wtf |
| 17:54 | <nimbu> | TabAtkins: curious does the generated content spec address which elements pseudo elements the content property gets applied? |
| 17:54 | <nimbu> | TabAtkins: curious about addnig content within an iframe::before or iframe::after |
| 17:54 | <TabAtkins> | annevk: Interested in potentially adding more Futures combinators? Looks like there are a few decent ones in https://github.com/caolan/async/blob/master/README.md, though I need to go through them in detail to figure out which ones are just working around callback weirdness. |
| 17:54 | <TabAtkins> | nimbu: Everything that's not a replaced element gets ::before/::after. |
| 17:55 | <nimbu> | TabAtkins: is it documented somewhere. |
| 17:55 | <TabAtkins> | Maybe? |
| 17:55 | <annevk> | TabAtkins: I think I'd like to see a browser implementation first and then add some more stuff |
| 17:55 | <TabAtkins> | annevk: Sounds reasonable. |
| 17:55 | <TabAtkins> | What we have for now is sufficient for most things, anyway. |
| 17:55 | <annevk> | TabAtkins: also, if it's not just Mark Miller but the entirety of TC39 that's pissed off, I'd like to see what they can bring to the table |
| 17:56 | <TabAtkins> | Right. |
| 17:56 | <annevk> | well, it's not the entirety for sure, but I'd like to know what the others think |
| 17:56 | <nimbu> | TabAtkins: http://www.w3.org/TR/css3-content/#replacedContent does not define what is a replaced element |
| 17:56 | <nimbu> | TabAtkins: is it in html5 spec? |
| 17:56 | <TabAtkins> | Maybe? |
| 17:57 | <Ms2ger> | Why are you looking at TR? |
| 17:57 | <nimbu> | TabAtkins: !!!!! |
| 17:57 | <TabAtkins> | Also: yes, what Ms2ger said. |
| 17:57 | <nimbu> | TabAtkins: http://www.w3.org/html/wg/drafts/html/master/rendering.html#replaced-elements |
| 17:57 | <nimbu> | Ms2ger: srry first result in googling |
| 17:57 | <Ms2ger> | Why are you looking at the forked HTML? |
| 17:58 | <dglazkov> | lol |
| 17:58 | <marcosc> | s/forked/stolen |
| 17:58 | <marcosc> | heh |
| 17:58 | <TabAtkins> | Hehe |
| 17:58 | <nimbu> | ahahahahahha |
| 17:59 | <nimbu> | Ms2ger: ALSO FIRST RESULT |
| 17:59 | <nimbu> | TabAtkins: http://dev.w3.org/csswg/css-content/ |
| 17:59 | <nimbu> | THIS IS WAI |
| 17:59 | <annevk> | accessibility? |
| 17:59 | <annevk> | or is WAI some kind of hipster variant of WHY? |
| 17:59 | <nimbu> | YES annevk |
| 17:59 | <nimbu> | Y is too not cool |
| 18:00 | <annevk> | WAI COOL |
| 18:00 | <nimbu> | TabAtkins: so should i refer to the 2.1 def of :before |
| 18:00 | <annevk> | oh wait |
| 18:00 | <nimbu> | i cannot |
| 18:00 | <nimbu> | :) |
| 18:00 | <TabAtkins> | I long ago gave up trying to interpret nimbu. |
| 18:00 | <nimbu> | ahahhaa |
| 18:00 | <nimbu> | that is a good idea TabAtkins |
| 18:01 | <dglazkov> | just like abstract art, there's no wrong answer |
| 18:01 | <nimbu> | exactly dglazkov we are all abstract arts |
| 18:02 | <dglazkov> | I am more of surrealism |
| 18:02 | <annevk> | with deadlines |
| 18:02 | annevk | chants "wait for ES6" |
| 18:03 | <TabAtkins> | Huh, gmail's "first-line preview" thing in the email list auto-strips things that look like tags for some reason. |
| 18:09 | <manu-db> | annevk, TabAtkins: Would this be an option - lifting Futures from DOM4 and placing it into the JSON-LD API spec? We would have to do another Last Call for JSON-LD API, but could get to REC by late June 2013... and then we'd at least have a spec that mentioned Futures in a REC-y way? |
| 18:09 | <manu-db> | manu-db: JSON-LD 2.0 could defer to whatever spec ends up being the Futures spec? |
| 18:10 | <TabAtkins> | That seems like a weird place to put it. (And, no offense, likely to at least somewhat taint Futures with the linked-data stuff.) |
| 18:10 | <Ms2ger> | Consider a DOM tree where the root is a frameset element with a body child |
| 18:10 | <Ms2ger> | What does document.body return? |
| 18:11 | <manu-db> | TabAtkins, annevk: No, we'd lift it as-is - no changes to Futures. The other option is to do a FPWD of a Futures-only spec in RDF WG and take that to REC... but that would probably not fly. |
| 18:13 | <annevk> | Ms2ger: frameset? |
| 18:13 | <Ms2ger> | annevk, in Gecko, indeed |
| 18:13 | <annevk> | Ms2ger: also spec iirc |
| 18:13 | <Ms2ger> | In Chrome, the body |
| 18:13 | <Ms2ger> | Per spec, null |
| 18:14 | <annevk> | hmm |
| 18:14 | <annevk> | manu-db: so that's working around a broken policy in the W3C with a solution that seems future-hostile |
| 18:14 | <Ms2ger> | annevk, Future-hostile or future-hostile? :) |
| 18:15 | <annevk> | manu-db: groups have suggested doing that kind of thing in the past for the same reasons and it's always considered a bad idea |
| 18:16 | <annevk> | manu-db: I'd suggest to stop working within the damaging constraints put forward by some of the W3C. Those constraints are not part of the W3C Process |
| 18:16 | <annevk> | Ms2ger: oh you |
| 18:17 | <manu-db> | annevk, TabAtkins: just throwing out ideas in case the group wants to do Futures. Keep in mind that it's not just me in this group - it's many others that have a variety of other positions on W3C process /and/ whether or not futures are useful. |
| 18:18 | Ms2ger | wonders when we started caring about json-ld |
| 18:19 | <manu-db> | annevk, TabAtkins: What if we could publish DOM4 Futures in a stand-alone spec via W3C and get it to REC quickly? Is that something that is of interest? Isn't it "done"? |
| 18:21 | <annevk> | manu-db: I don't like forks personally. We want to enhance the feature over time. Also, I could not care less about REC. |
| 18:21 | <Ms2ger> | (IE appears to always return the root if it's a body/frameset) |
| 18:23 | <TabAtkins> | manu-db: What's the hang-up with referencing a non-W3C document? That's not actually disallowed, as much as people try to pretend that it is when the WHATWG is involved. |
| 18:23 | <manu-db> | annevk: I don't want to fork it, I just want to have a "W3C stable" published version. We can always include text in there that says: "If you want to see the live version of this spec, look here..." (and then informatively point to the DOM4 Futures spec) |
| 18:23 | <manu-db> | TabAtkins: We'd have to normatively reference a non-W3C document, I think... since the object being returned would be a Promise. |
| 18:23 | <annevk> | So there's no DOM4. Nobody is maintaining that. |
| 18:23 | <TabAtkins> | manu-db: ...yes? |
| 18:24 | <manu-db> | TabAtkins: There's no issue w/ informatively referencing... normatively referencing is another issue. |
| 18:24 | <TabAtkins> | To the best of my knowledge, there isn't. Do you have evidence that we can't norm-ref a non-W3C doc? |
| 18:25 | <Ms2ger> | TabAtkins, I have evidence that people whine about imagined Process requirements if you try |
| 18:25 | <manu-db> | TabAtkins: Yeah, let me find the link - you can't normatively reference documents that aren't REC at W3C (because the possibility of the ref'd doc changing is too great from a W3C member company perspective) |
| 18:26 | <Ms2ger> | manu-db, not that case |
| 18:26 | <manu-db> | Ms2ger: s/that/the/ ? |
| 18:26 | <Ms2ger> | manu-db, you can always reference non-W3C-published documents |
| 18:26 | <manu-db> | Ms2ger: Yes, of course you can. |
| 18:26 | <Ms2ger> | manu-db, the only maturity requirement is if you reference a W3C document |
| 18:26 | <manu-db> | Ms2ger: The question isn't that, though... |
| 18:26 | <manu-db> | Ms2ger: Oh, I think I see what you're doing. |
| 18:26 | jgraham | wonders which member company's perspective that is |
| 18:27 | <manu-db> | jgraham: IBM, for one |
| 18:27 | <manu-db> | jgraham: Oracle |
| 18:27 | <Ms2ger> | manu-db, given that DOM4 doesn't have Futures and WHATWG DOM does... |
| 18:28 | <manu-db> | TabAtkins, annevk, Ms2ger: I guess we could make the entire API non-normative... hmm, that might work? |
| 18:28 | <TabAtkins> | No, jeez, just normatively ref the Futures doc! |
| 18:29 | <TabAtkins> | It's no different from CSS norm-reffing a Unicode doc. |
| 18:29 | <TabAtkins> | (And probably at least as stable...) |
| 18:29 | <annevk> | manu-db: I think I'll pardon myself from this discussion. I don't want to play under the rules of damaging constraints, whether real or imaginary. |
| 18:31 | <manu-db> | TabAtkins: link? |
| 18:31 | <annevk> | (I should probably suitably scope that statement somehow, but it should be clear from context.) |
| 18:32 | <manu-db> | annevk: your choice. I'm trying to figure out a way to get the Futures stuff into a form that is usable at W3C, I understand that you don't agree with the exercise, but the end-goal should be something that's beneficial for Futures. |
| 18:35 | <Ms2ger> | https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0053.html |
| 18:49 | <marcosc> | I'm not sure where this should be filed: http://www.w3.org/community/respimg/2013/04/06/devicenormalpixelratio-proposal-for-zoom-independent-devicepixelratio-for-hd-retina-games/ |
| 18:50 | <marcosc> | If it's a CSS WG issue or HTML or ??? |
| 18:50 | <marcosc> | TabAtkins, if you have a min, could you take a quick look? ^^ |
| 18:51 | <marcosc> | the problem is pretty evident if you got to http://webquake.quaddicted.com/ |
| 19:14 | <KyleBarnhart> | Hi. I have a question regarding the WebVTT specification. |
| 19:15 | <KyleBarnhart> | According to the rendering rules, it looks like a cue will be displayed at the top of a video. Normally, captions are rendered on the bottom. Is this correct? |
| 19:17 | <rillian> | KyleBarnhart: that's conventional. Does the spec say anything about default positioning? |
| 19:22 | <KyleBarnhart> | http://dev.w3.org/html5/webvtt/#cues-with-video |
| 19:23 | <KyleBarnhart> | rule 9 sets y-position to 0, rule 11 sets y-position to top |
| 19:23 | <KyleBarnhart> | this is because snap-to-lines is true by default, wiriting direction: horizonal also default |
| 19:24 | <KyleBarnhart> | * sets top to 7-position |
| 19:28 | <rillian> | KyleBarnhart: does http://dev.w3.org/html5/webvtt/#dfn-text-track-cue-automatic-line-position not already set the default position to 100? |
| 19:30 | <KyleBarnhart> | no, default is auto. But it doesn't matter, line position doesn't get used. Because wirting direction is horizonal and snap-to-lines is true, y-position is set to 0. |
| 19:37 | <TabAtkins> | marcosc: Hm, I'll have to think about this. For one thing, device-pixel-ratio doesn't exist. ^_^ |
| 19:52 | <KyleBarnhart> | ok i've figured it out. it's at the bottom. |
| 22:18 | <gavinc> | manu-db: Future/Coroutine/Async in Python http://www.python.org/dev/peps/pep-3156/ |