| 01:40 | <TabAtkins> | a-ja: I just looked at Counter Styles, and discovered that I'd already taken directionality into account. |
| 01:42 | <a-ja> | TabAtkins: k...will have a re-read. |
| 01:43 | <TabAtkins> | I do so in prose, rather than in code. |
| 01:44 | <a-ja> | TabAtkins: verticality handled, too? i.e. tb and bt ? |
| 01:45 | <TabAtkins> | I just say that if it's directional, it must correspond to the writing mode of the element. |
| 01:45 | <TabAtkins> | And expect that, via magic, it'll work. |
| 01:47 | <a-ja> | TabAtkins: had a look at the moz patch....looks like it handles directionality with some magic hand-wavy code, rather than in ua stylesheet. will have to test overriding styles once it's ready for testing |
| 01:48 | <Domenic_> | ugh DOM forked again. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25021 |
| 04:40 | SamB | likes this guy's picture: https://twitter.com/gimsieke |
| 08:38 | <annevk> | darobin: so how is adding Attr.prototype.ownerElement preserving a subset? |
| 08:39 | <annevk> | seems like that statement was full of shit |
| 08:52 | <Ms2ger> | I'm surprised. |
| 10:34 | <annevk> | Just read a bunch of forum topics on indexes vs indices |
| 10:35 | <annevk> | To fix a bug in shift_jis's encoder |
| 10:46 | <annevk> | Anyone a good short name for "HTML decimal numeric character reference" |
| 10:47 | <SimonSapin> | annevk: if they context implies "some way to deal with code points", maybe just "html"? |
| 10:48 | <SimonSapin> | as in "the html error handling" vs. "the strict error handling" |
| 10:49 | <annevk> | HTML error mode* |
| 10:56 | <annevk> | Bit torn on whether I should adopt the terms "character" and "Unicode character" |
| 10:59 | <SimonSapin> | Sounds bad to use both. If they’re the same, pick one. If they’re not, the difference might be too subtle (as in, readers maybe will not notice they’re not the same) |
| 11:01 | <annevk> | HTML uses those terms meaning code point and Unicode scalar value |
| 11:30 | <SimonSapin> | well, my opinion above still applies |
| 11:46 | <JakeA> | annevk: hey |
| 11:46 | <JakeA> | annevk: yt? |
| 11:46 | <annevk> | JakeA: yup |
| 11:46 | <JakeA> | annevk: I'm typing a question |
| 11:46 | <JakeA> | annevk: Going to type it now |
| 11:46 | JakeA | types |
| 11:47 | <JakeA> | annevk: re .add on caches, do you see it resolving before everything downloads? |
| 11:47 | <annevk> | SimonSapin: it seems worse to have different terms |
| 11:47 | <annevk> | JakeA: i was just wondering whether you'd report success/failure |
| 11:48 | <annevk> | JakeA: seems like you wouldn't necessarily expose the response objects |
| 11:48 | <JakeA> | (someone just hello'd me, so I thought I'd pass on the pain) |
| 11:48 | <annevk> | heh |
| 11:49 | <JakeA> | annevk: Yeah, that makes sense. Returning responses felt like something to return, but I can't think of a good use of it. |
| 11:49 | <JakeA> | annevk: actually, you're right, since .add(fiveItems) can result in less-than 5 items being added, we shouldn't resolve with responses |
| 11:50 | <JakeA> | Will update the ticket |
| 11:51 | <annevk> | JakeA: given that, .add(...items) makes sense... |
| 11:52 | <annevk> | JakeA: it seems the preferred style is arity |
| 11:53 | <JakeA> | annevk: unless the input should map to output, like Promise.all |
| 11:58 | <annevk> | yeah |
| 12:20 | <annevk> | hsivonen: do you think the operations for arithmetic in http://encoding.spec.whatwg.org/#terminology are sufficiently defined? |
| 12:21 | <annevk> | hsivonen: also, if you could provide guidance on how algorithms could be rewritten as you asked for in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24198 that'd be appreciated |
| 14:36 | <gsnedders> | SimonSapin: Stop making statements that I want to +1, because that's unproductive! |
| 14:37 | <SimonSapin> | gsnedders: about character vs. Unicode character? |
| 14:37 | <gsnedders> | Yeah |
| 14:37 | <SimonSapin> | well that statement itself was not very productive since I don’t have a better suggestion |
| 14:37 | <gsnedders> | :) |
| 14:38 | gsnedders | votes for just using code point and Unicode scalar value |
| 14:39 | <SimonSapin> | but Unicode scalar value is so bleh |
| 14:41 | <jgraham> | Why "scalar"? Is there also a "Unicode vector value"? |
| 14:42 | <SimonSapin> | who knows |
| 14:42 | <zcorpan> | Hixie: i wontfixed your suggestion to rename source https://github.com/ResponsiveImagesCG/picture-element/issues/133 |
| 14:42 | <SimonSapin> | http://www.unicode.org/glossary/#unicode_scalar_value |
| 14:42 | <gsnedders> | No, but it makes us just use the underlying terminology, which seems easier than people having to know that Unicode character == Unicode scalar value and then the definition of that. |
| 14:44 | <SimonSapin> | maybe omit the "Unicode"? http://www.unicode.org/glossary/#scalar_value |
| 14:44 | <SimonSapin> | (just like we omit it in "Unicode code point") |
| 14:46 | <SimonSapin> | but "scalar value" by itself has no indication it has anything to do with text |
| 14:55 | <gsnedders> | Yeah |
| 14:55 | <zcorpan> | call it "value" |
| 14:56 | <SimonSapin> | object, or node |
| 15:02 | <SimonSapin> | more seriously: annevk, how about "(Unicode) character" as an alias for "Unicode scalar value", and "(Unicode) code point" for itself? |
| 15:03 | <SimonSapin> | Hixie: same for HTML ^ |
| 15:06 | <Ms2ger> | It's probably a good idea to make our specs match |
| 15:15 | <gsnedders> | SimonSapin: I dislike character because of its multitude of Unicode definitions |
| 15:18 | <dglazkov> | good morning, Whatwg! |
| 15:22 | <jcgregorio> | morning dglazkov! |
| 15:40 | <annevk> | SimonSapin: I went with scalar value an hour ago or so |
| 15:40 | <annevk> | SimonSapin: happy to rename once someone else sorts this out |
| 15:41 | <SimonSapin> | I’m not sure who you expect someone else to be |
| 15:44 | <annevk> | yup |
| 17:08 | <Hixie> | zcorpan: if you reuse <source>, then you're taking over the whole media section as well. there's no way i'm speccing this mistake. |
| 17:11 | <TabAtkins> | SamB: I've got the IE version of that guy's picture: https://twitter.com/tabatkins |
| 17:14 | <jgraham> | Hixie: That doesn't seem like a good way to deal with the situation. From the bug it didn't appear that you had established the critical difference between this instance of reusing an element name in multiple contexts and other instances of the same (including the existing reuse of <source>) |
| 17:19 | <TabAtkins> | Hixie: Yes - as far as I can tell (as I explained in the bug), this is no more troublesome than the existing reuse of <source> in <video> and <audio>. |
| 17:56 | <Hixie> | TabAtkins: <video> and <audio> are the same element, in the spec, essentially. |
| 17:56 | <Hixie> | TabAtkins: and <source> with <video> and <audio> is a huge pain even then |
| 17:56 | <Hixie> | TabAtkins: i'm willing to pay the cost of making that mistake, since i made it |
| 17:56 | <Hixie> | TabAtkins: i'm not willing to pay the cost of someone else making the same mistake even after i warned them not to |
| 18:18 | <SamB> | TabAtkins: hmm, I can't say I recognize that precise icon; it looks just a little too simple somehow |
| 18:20 | SamB | wonders what the significance of 앳켄스 탭 may be ... wonders why unifont borrowed hangul from such a heavy font |
| 18:25 | <SamB> | TabAtkins: also why did you make the text on your page xanthir.com invisible? |
| 18:25 | SamB | goes to open it in elinks |
| 18:27 | <SimonSapin> | Hixie: how is this a mistake / what is the cost? |
| 18:30 | <Hixie> | i've explained this multiple times over the past few years |
| 18:30 | <Hixie> | but basically: |
| 18:30 | <Hixie> | whenever your processing model involves multiple elements, it is exponentially more complicated to spec |
| 18:31 | <Hixie> | you have to handle mutations, shadow DOMs, non-atomic parsing, non-atomic scripted creation, etc |
| 18:31 | <Hixie> | and every time we've done this, we've ended up finding edge case errors for _years_ afterwards |
| 18:31 | <Hixie> | i mean, i'm literally _still_ dealing with obscure spec bugs around <source> |
| 18:32 | <Hixie> | race conditions, unexpected DOM states, etc |
| 18:32 | <Hixie> | but i already went through all this years ago, that's why i didn't spec <picture> in the first place, and i specced srcset="" instead |
| 18:32 | <Hixie> | i wrote long e-mails to the whatwg list explaining this |
| 18:33 | <Hixie> | at this point, if people want to keep ignoring my feedback on this, then that's fine, but at least don't make me pay the cost |
| 18:38 | <SimonSapin> | so the problem is not having the name "source" re-used, but having multiple elements for one (media) "unit"? |
| 18:38 | <hober> | there are two problems |
| 18:39 | <hober> | 1) using multiple elements is a bad idea |
| 18:39 | <hober> | 2) if you insist on using multiple elements, naming one of them "source" entangles your mistake with Hixie's prior mistake |
| 18:39 | <Hixie> | right |
| 18:40 | <Hixie> | so then we have to figure out the interactions of both in obscure ways |
| 18:40 | <Hixie> | if it wasn't a mistake, i'd have no problem reusing the same element name |
| 18:40 | <Hixie> | and i'd have no problem taking responsibility for speccing it |
| 18:41 | <Hixie> | (or even if it was a mistake, but i didn't know yet) |
| 18:48 | <SamB> | TabAtkins: also I think we do reverse the seasons on the other side of the equator, and I hear some places have only *two* seasons ... |
| 18:52 | <Hixie> | california has several seasons, but they're distributed geographically rather than chronologically... |
| 18:56 | arunranga | that’s called a Hixism ^^ |
| 18:59 | <jgraham> | The flip side is that zcorpan (and others) did a lot of work to minimise the badness of the multiple elements, learning from the prior experience, and that people seem to have a strong preference for a multiple-element design |
| 19:01 | <Hixie> | that he had to do a lot of work is kind of the point |
| 19:01 | <Hixie> | anyway, i'm not saying this shouldn't be in the spec, especially if browsers implement it. i've already talked with zcorpan about how we're going to integrate it. |
| 19:02 | <hober> | is more than one browser going to implement it? |
| 19:02 | <Hixie> | basically, he's gonna own the parts that are affected by this, and they'll get merged in during publication |
| 19:02 | <TabAtkins> | SamB: The icon is the IE broken image icon. (And it's fooled IE engineers before!) |
| 19:02 | <Hixie> | hober: i hope not, but people are claiming they've conned both mozilla and chrome into doing it (ahem) |
| 19:02 | <TabAtkins> | SamB: 앳켄스 탭 is my name in Hangul. |
| 19:02 | SamB | wonders if there couldn't be a framework to allow sanity AND multi-element stuff |
| 19:03 | <TabAtkins> | SamB: And finally, the text is invisible because the text-shadow si doing the rendering (to enable the animated blur effect). |
| 19:03 | <SamB> | TabAtkins: well I don't see it in Firefox 24 ... |
| 19:03 | <Hixie> | SamB: the problems are pretty deeply integrated into how the DOM works (and are only gonna get worse with things like Shadow DOM) |
| 19:04 | <TabAtkins> | SamB: Hm, I have both -moz-prefixed versions and unprefixed. |
| 19:05 | <SamB> | do you want me to look again and check for warnings? |
| 19:05 | <SamB> | okay, it's working now |
| 19:05 | <SamB> | oh, it disappeared again now |
| 19:11 | <Hixie> | TabAtkins: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25026 |
| 19:38 | <Ms2ger> | TabAtkins, is this something we don't support unprefixed? |
| 20:09 | <TabAtkins> | Ms2ger: I dunno, you definitely support one or the other, and I have both. |
| 20:09 | <TabAtkins> | SamB: What do you mean? What's happening? |
| 20:10 | <Ms2ger> | TabAtkins, I was wondering if I should ask you to remove the prefix :) |
| 20:12 | <TabAtkins> | I'll do whatever, it's old code and I'm happy to update. Dunno what all I can remove right now, though. |
| 20:15 | <SamB> | oh maybe I have blink turned off |
| 20:15 | <Ms2ger> | Less prefixes proliferating is generally good :) |
| 20:15 | <Ms2ger> | (Fewer?) |
| 20:29 | <TabAtkins> | SamB: Turning off <blink> would only affect the blinking cursor. |
| 20:29 | <TabAtkins> | SamB: Why are you on FF 24? |
| 20:30 | <TabAtkins> | Aurora is 28 right now - you're a version or two behind. |
| 20:30 | <SamB> | because I have an irrational fear that if I switch from ESR to mainline that I'll end up regretting it |
| 20:30 | <TabAtkins> | Well, you regret your current choice, because it's somehwo broken. |
| 20:32 | <SamB> | actually I think I care more about how badly the devtools are doing at helping me see what's wrong ;-) |
| 20:33 | <TabAtkins> | Yeah, being 4 versions behind would exacerbate that. |
| 20:36 | SamB | ponders looking into having multiple installs ... |
| 20:39 | <SamB> | what is aurora doing at 28, anyway, when there already seem to be a 30 and a 31? |
| 20:47 | <nephyrin> | SamB: Aurora is currently 30 |
| 21:02 | <TabAtkins> | Hah, so my install is behind as well. |
| 21:03 | <TabAtkins> | Oh, no, I'm not even on Aurora. |
| 21:03 | <TabAtkins> | Just stable channel. |
| 21:09 | <SamB> | hmm, I'm a bit confused though because I just looked at Firefox's download tree and they don't have anything for 30 or 31 yet |
| 21:09 | <SamB> | I only saw those versions in Firebug release announcements |
| 21:13 | <svl> | http://nightly.mozilla.org/ has 31, http://www.mozilla.org/en-US/firefox/aurora/ has 30 - stable is on 28 |
| 21:38 | <Hixie> | tantek: it was brought to my attention that you are under the mistaken belief that w3c specs can't reference whatwg specs |
| 21:38 | <Hixie> | tantek: HTML5.1 references several wikis, guides on the w3c site, unicode technical reports and notes, the CLDR, several WHATWG specs, editor's drafts of w3c specs, pages on github, graphviz.org, the ES6 draft, IANA registries, mozilla developer docs, publicsuffix.org, torproject.org, and a random page on rniwa.com |
| 21:39 | <Hixie> | tantek: so i don't think that's accurate |
| 22:20 | <arunranga> | Hixie, tantek: I really *hope* that we can cross-reference. File API does pretty liberally (e.g. url.spec.whatwg.org, amongst others, including mimesniff). FileSystem might. Others within WebApps do. |
| 22:21 | <Hixie> | we clearly can |
| 22:21 | <Hixie> | lots of specs do |
| 22:21 | <arunranga> | Hixie, tantek, these references are also normative. So, disabuse me if I’m wrong to do so. |
| 22:21 | <Hixie> | it'd be pretty funny if the whatwg decided to instigate a policy of not referencing w3c docs |
| 22:21 | <Hixie> | and then forked all the specs needed to work around that |
| 22:22 | <Domenic_> | all the DOM4 references I see make me sad. Just reference the real DOM. |
| 22:22 | <arunranga> | Hixie, unless there’s a patent-ish sense here about cross-references opening a backdoor to thwart licensing declarations, I can’t think of a reason not to do that. |
| 22:23 | <Hixie> | there isn't |
| 22:23 | arunranga | tempest in a teacup then :) |
| 22:24 | <Hixie> | the forking isn't "in a teacup", it's causing real harm and confusion |
| 22:29 | <sgalineau> | Hixie: examples of harm and confusion? |
| 22:29 | <Hixie> | IE follows one spec, Chrome follows another. |
| 22:29 | <Hixie> | Web authors ask me about a bug that's fixed in one and not the other. |
| 22:30 | <Hixie> | people don't know if features are in or out because different specs disagree. |
| 22:30 | <Hixie> | i get e-mails at least weekly, often more, from people confused about this stuff one way or another. |
| 22:30 | <sgalineau> | I think you're assuming IE follows one spec out of confusion instead of deliberately |
| 22:30 | <Hixie> | whether it's deliberate or not, it's harm |
| 22:31 | <sgalineau> | sure, but is it super different from two browsers implementing two versions of the same spec a few months apart |
| 22:32 | <TabAtkins> | Yes, because there's a single obvious answer when anyone asks what the right behavior is. |
| 22:32 | <sgalineau> | fair |
| 22:33 | <sgalineau> | and to be clear, I do find the situation crazy. OTOH folks complain about w3schools confusing things then we turn around and fork stuff for unclear reasons (when there is a reason) |
| 22:33 | <Hixie> | it's also harm in more subtle ways, like, all the effort that could be spent editing specs that desperately need editing, but have no editors, is instead spent redundantly editing specs that already have editors. |
| 22:34 | <sgalineau> | still, is the mess documented someplace? even part of it? |
| 22:35 | <Hixie> | http://wiki.whatwg.org/wiki/FAQ#WHATWG_and_the_W3C_HTML_WG |
| 22:35 | <Hixie> | and the w3c "landscape" doc |
| 22:35 | <Hixie> | (but that's woefully incomplete) |
| 22:35 | <Hixie> | but even i don't have a clear idea of what the full extent of the mess is |
| 22:35 | <Hixie> | and it's not just w3c vs whatwg |
| 22:36 | <Hixie> | there's also the problem of w3c vs w3c |
| 22:36 | <sgalineau> | right |
| 22:37 | <sgalineau> | it's a bit like we're going <spec><source...><source...><source...></spec> |
| 22:37 | <sgalineau> | 'what could go wrong?' |
| 22:37 | <Hixie> | e.g. http://damowmow.com/temp/canvas-specs |
| 22:39 | <Hixie> | none of that would be a problem if the w3c hadn't forked the whatwg spec (let alone forked it apparently 27 times) |
| 22:39 | <sgalineau> | I wonder if it's worth collecting a bunch of examples like these for the new TAG. Not that they don't know but I've never seen the evidence marshalled in a single place (may have missed it though) |
| 22:40 | <sgalineau> | though it might be too late |
| 22:41 | <Hixie> | wtf can the TAG do about it |
| 22:41 | <Hixie> | they have no authority |
| 22:42 | <sgalineau> | I don't think there is a single authority involved. got to start somewhere + some of the folks there are able to make some public noise about it |
| 22:42 | <Hixie> | there's one single authority who could fix all this. Jeff Jaffe. |
| 22:42 | <sgalineau> | what would he do? |
| 22:42 | <sgalineau> | besides a memo saying 'don't do that' |
| 22:44 | <Hixie> | well a memo would be a fine start, but then he could also enforce it. |
| 22:44 | <Hixie> | e.g. delete any forked spec. |
| 22:44 | <Hixie> | deprecate the TR/ page. |
| 22:44 | <Hixie> | etc. |
| 22:44 | <sgalineau> | which won't happen without enough members believing it is a problem they need to fix |
| 22:44 | <Hixie> | he's the CEO. He can do whatever he wants with or without members. |
| 22:45 | <Hixie> | in fact, if I was the CEO, the first thing I would do is disband the AC, followed by dropping the concept of paid membership. |
| 22:45 | <sgalineau> | not really. he funds his organization from the members. |
| 22:45 | <Hixie> | the third thing i would do is fire all the staff, thus solving the funding problem. |
| 22:45 | <sgalineau> | lol |
| 22:45 | <sgalineau> | sure, but you're not the CEO |
| 22:45 | <sgalineau> | so, in the meantime... |
| 22:46 | <Hixie> | but he is, and he could do that. |
| 22:46 | <Hixie> | the whatwg is funded out of my pocket |
| 22:46 | <sgalineau> | he could ride into the TPAC plenary day on a pony, too |
| 22:47 | <sgalineau> | all fascinating hypotheticals but I doubt they lead to a practical solution |
| 22:47 | <Hixie> | my point is that it's his responsibility, and he has the authority. |
| 22:47 | <Hixie> | that's all. |
| 22:47 | <Hixie> | he clearly has decided not to solve these problems, though. |
| 22:47 | <Hixie> | even though he could. |
| 22:48 | <Hixie> | (i'd also cancel tpac.) |
| 22:48 | <sgalineau> | You could argue all CEOs have the authority to fold their own organization and that by doing so they'd eliminate all the issues within. |
| 22:48 | <sgalineau> | That may be 100% true but it's not a particularly interesting argument. |
| 22:49 | <Hixie> | i didn't say it should fold. |
| 22:49 | <Hixie> | and in most cases, it wouldn't solve the problems |
| 22:49 | <Hixie> | the w3c is a special case in that respect. |
| 22:50 | <Hixie> | standards organisations, imho, should not have paid memberships. It totally screws up the incentives for the people running the organisation. |
| 22:51 | <Hixie> | the W3C is a case study in that. |
| 22:52 | <sgalineau> | I'm not sure how eliminating paid membership prevents forking but I think we've wandered away from the topic here... |
| 22:53 | <Hixie> | you said he could only do what the membership wanted. eliminating memberships means that's no longer a problem. |
| 22:53 | <Hixie> | (but also, i don't actually accept your premise. He could totally tell the membership that he was not allowing forking even if they disagreed.) |
| 22:54 | <Hixie> | (plus, i disagree with the premise that the majority of the membership actually wants the w3c to be forking specs. they in fact have indicated that they are so _against_ forking that they don't even think the w3c should use a document license that allows it.) |
| 22:54 | <sgalineau> | without money he has no staff and is not paid himself. the notion that he has more power that way seems odd but anyway... |
| 22:55 | <sgalineau> | well, if enough of the membership is against, that's a start and suggests we don't need to abolish the whole thing to fix the problem |
| 22:55 | <Hixie> | he can get paid himself (and even a small staff to organise events and maintain the servers) via small grants, like the IETF. |
| 22:55 | <Hixie> | the w3c has no power _today_ except over its own web site. he'd still have that power without a membership. |
| 22:57 | <sgalineau> | I'm interested in practical solutions that are not only possible but have some realistic probability of occurring in the near future. not hearing that... |
| 22:57 | <sgalineau> | and if we know Jeff is not going to do that anyway, arguing what he could do should he choose to do it sounds like a wankfest, to be honest |
| 22:57 | <Hixie> | the practical solution is just for the w3c to not publish forks of specs. i don't understand why this is impractical. |
| 22:58 | <sgalineau> | I don't think it is. |
| 22:58 | <Hixie> | what would the w3c do if the whatwg changed the copyrights on its specs so the w3c could no longer legally fork the specs? |
| 22:58 | <sgalineau> | but if you're going to argue for it by saying 'well, jeff could just fire all the staff and suspend paid membership' that's an excellent way to get tuned out |
| 22:58 | <sgalineau> | I don't know. I'm sort of tickled to see what would happen if it did... |
| 23:04 | <TabAtkins> | Just make a new copyright notice that's exactly the same as today, but specifically prevents the w3c from forking it or any derivatives. |
| 23:05 | <Domenic_> | i think it's much simpler to argue for no-w3c-forking than for no-paid-membership |
| 23:08 | <Hixie> | well, i think both need to happen, but sure |
| 23:08 | <Hixie> | i don't think the w3c will ever really solve its fundamental problems until it changes its funding model, and i don't think it will ever change its funding model |
| 23:09 | <Hixie> | i was just pointing out that it could, and Jeff has the authority to do it if he wanted to. |
| 23:11 | <Hixie> | sgalineau: why do you think the w3c is forking so many specs? and why do you think it can't not do it? |
| 23:11 | <hober> | Hixie: would you have to get agreement from the WHATWG Membership to change the copyright in that manner? |
| 23:12 | <SamB> | hober: the WHATWG would probably not do that |
| 23:12 | <Hixie> | technically everything i've written since joining google is (c) google and technically none of it has ever had a clear license. |
| 23:12 | <Hixie> | so... |
| 23:12 | <SamB> | Hixie: it says right on the spec what the license is doesn't it |
| 23:12 | <Hixie> | but no, the editors can just pick their own license |
| 23:12 | <Hixie> | SamB: yeah... not clear how accurate that license has been since about 2005. :-) |
| 23:13 | <Hixie> | hober: (in particular, note that the licenses for the other specs are much clearer) |
| 23:13 | <Hixie> | (i just don't like changing legal boilerplate, so i haven't done anything about it) |
| 23:14 | <SamB> | well, I believe there's precedent for contributing to a work with a license statement like that being interpreted as licensing your contributions under that license |
| 23:14 | <Hixie> | yeah, i think that's why nobody has cared |
| 23:14 | <Hixie> | but anyway, it's only subsequent contributions that would matter |
| 23:14 | <Hixie> | since the w3c has already forked everything written so far |
| 23:15 | <Hixie> | and it would be easy for me just to add "contributions since this date (c) google all rights reserved" or some such |
| 23:15 | <Hixie> | (i'd speak to my copyright lawyer first to get the exact wording obviously) |
| 23:15 | <Hixie> | but doing so goes against everything i think a standards organisation should do |
| 23:15 | <Hixie> | (as does forking) |
| 23:15 | <Hixie> | so i dunno, do i believe it's more important to stop the w3c or do i believe it's more important to be open |
| 23:15 | <Hixie> | it's a hard call |
| 23:16 | <Hixie> | (stop the w3c forking, i mean) |
| 23:16 | <Hixie> | (obviously openness is more important than stopping the w3c entirely :-P) |
| 23:16 | <SamB> | Hixie: I'm pretty sure if you were to decide "I'm going to GFDL this and I'm going to add 'The W3C is dead.' as a cover text", the existing material would still be available under, uh |
| 23:17 | <zewt> | things that would be bad: the internet depending on a spec which which nobody else is allowed to take over if the maintainer/owner stops maintaining it for some unforeseen reason |
| 23:17 | <zewt> | just to throw the obvious out there, heh |
| 23:17 | <SamB> | this: "You are granted a license to use, reproduce and create derivative works of this document." |
| 23:18 | <SamB> | Hixie: hmm, what is the W3C's copyright policy anyway |
| 23:18 | <zewt> | anyone can take the document and make further modifications to it which aren't under that license; it's not a copyleft, in other words |
| 23:18 | <SamB> | zewt: sure |
| 23:19 | <zewt> | continuing to maintain forks would become difficult if they had to re-spec all future work due to being unable to merge in changes |
| 23:19 | <Hixie> | SamB: GFDL would be an interesting idea, but it's not open enough for e.g. Mozilla to reuse the text in their MPL-covered code. |
| 23:19 | <Hixie> | zewt: yeah, well, welcome to ALL W3C SPECS EVER |
| 23:20 | <zewt> | i recall gfdl being really terrible, though it's been years since i looked at it closely and i couldn't say why off the top of my head |
| 23:20 | <SamB> | Hixie: that was a "hixie is replaced by his evil twin" scenareo |
| 23:20 | <Hixie> | zewt: (one reason why we had to rewrite teh entire HTML spec from scratch rather than just forking it, when the w3c refused to maintain it. The other reason, of course, was that there was no material there worthy of being reused...) |
| 23:20 | <SamB> | there's a reason I mentioned the cover text |
| 23:21 | <Hixie> | SamB: we're at the point where that's the kind of thing i'm considering. |
| 23:24 | <SamB> | so, um, what's the union of the licenses on Gecko, Webkit, and Blink? |
| 23:31 | <Hixie> | Gecko is MPL, GPL, LGPL. Dunno about webkit/blink. |
| 23:31 | <Hixie> | (i assume BSD or MIT or some such?) |
| 23:38 | <SamB> | hmm, looking at <http://metadata.ftp-master.debian.org/changelogs/main/i/iceweasel/unstable_copyright>;, <http://metadata.ftp-master.debian.org/changelogs/main/q/qtwebkit-opensource-src/unstable_copyright>;, and <http://metadata.ftp-master.debian.org/changelogs/main/c/chromium-browser/unstable_copyright>; ... |
| 23:39 | <SamB> | I see, well, a few more licenses than you said for mozilla ... |
| 23:42 | <SamB> | WAAAAY too many BSD variants |
| 23:45 | <zewt> | the bsd license encourages editing it, unfortunately, with the stupid endorsement clause |
| 23:45 | <zewt> | MIT/X11 doesn't have that problem |
| 23:46 | <SamB> | yeah, but they even have a strange variant of BSD2 requiring it be the first thing, other than copyright notices, in the file |
| 23:46 | <zewt> | that's pretty much a nonstarter for me, if I put licenses in files, they go at the end |
| 23:48 | <zewt> | amusingly, that's also GPL-incompatible |
| 23:50 | <zewt> | (i'm not a huge GPL fan these days, but I am for GPL-compatibility) |
| 23:50 | <SamB> | yes, GPL compatibility is fairly important ... |