| 00:11 | <Hixie> | AryehGregor: i updated the wiki page with some recent arguments |
| 00:11 | <Hixie> | http://wiki.whatwg.org/wiki/Forking |
| 01:30 | <llrcombs> | ohai |
| 01:30 | <llrcombs> | about the cache manifest spec |
| 01:32 | <llrcombs> | may I suggest that the manifest spec include another field for each vile, specifying the last-modified date of the file, so that the client can auto-update the file if it's been modified since the cache was stored? |
| 04:26 | <MikeSmith> | hmm |
| 04:27 | <MikeSmith> | the spec doesn't say anything about what the allowed value of the mediagroup attribute is |
| 04:29 | <MikeSmith> | clearly it's not meant to be a list of tokens |
| 04:29 | <MikeSmith> | so any string? |
| 04:41 | <MikeSmith> | hmm, I guess if no additional constraints are specified for any particular attribute, by default it's just text |
| 04:41 | <MikeSmith> | or text and character references |
| 08:37 | <zcorpan> | "Whether the W3C allows forking or not, and even if we grant that a license could stop this, this scenario could already happen because the entire HTML spec is already under a liberal license at the W3C." http://wiki.whatwg.org/wiki/Forking - s/W3C./WHATWG./ ? |
| 09:00 | <othermaciej> | I think Lawrence Rosen only likes the Option 1 and Option 3 licenses because he came up with them |
| 09:10 | <jgraham> | zcorpan: I think the right response is "it's a wiki". But I noticed the same mistake and didn't fix it so… |
| 09:12 | <zcorpan> | fixed |
| 09:18 | <othermaciej> | hmm |
| 09:19 | <othermaciej> | I'm not sure it's right to call either CHTML or HDML "WC-hosted forks" |
| 09:19 | <jgraham> | A reasonable response to "there is nothing special about W3C sanctioned forks" might be that non-W3C forks aren't covered by the same IP commitments as W3C forks; so W3C forks are equivalent from a brand-dilution, confusion, fragmentation point of view, but not from a "people injecting stuff and charging for it later" point of view |
| 09:19 | <othermaciej> | they were both originally developed outside the W3C, published as member submission notes, and then rejected and developed outside the W3C |
| 09:19 | <othermaciej> | (afaik) |
| 09:28 | <jgraham> | (I don't know if there is a good response to that other than "the risk is outweight by the positive effects that the ability to fork brings") |
| 09:29 | <othermaciej> | whaoh |
| 09:29 | <othermaciej> | never heard of this before, HTML 4.0 Mobile: http://www.w3.org/TR/1999/NOTE-html40-mobile-19990315/ |
| 09:29 | <othermaciej> | (has its own DTD and everything) |
| 09:30 | <othermaciej> | also, XHTML+SMIL Profile: http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/ |
| 09:31 | <othermaciej> | (not entirely sure if that is an HTML/XHTML fork) |
| 09:31 | <jgraham> | Ah, another entry from the graveyard "mobile will never be able to browse the real web" |
| 09:31 | <jgraham> | +of |
| 09:32 | <othermaciej> | it seems like the W3C forks HTML more than the rest of the world put together |
| 09:32 | <jgraham> | othermaciej: Interesting. A design goal of XHTML and XHTML2 was modularity so that people could take parts of specs and recombine them into a different form. That seems a lot like forking |
| 09:32 | <othermaciej> | the whole XHTML Modularization thing? |
| 09:33 | <jgraham> | Yeah |
| 09:33 | <othermaciej> | I do not know what that is all about |
| 09:33 | <othermaciej> | I am not even sure whether XHTML 1.1 could reasonably be called an incompatible fork of 1.0 |
| 09:34 | <jgraham> | "This modularization provides a means for subsetting and extending XHTML, a feature needed for extending XHTML's reach onto emerging platforms" |
| 09:34 | <jgraham> | http://www.w3.org/TR/xhtml-modularization/ |
| 09:34 | <jgraham> | That sounds a lot like "forking" to me |
| 09:35 | <jgraham> | Albeit that you were probably not supposed to change the modules you reused. But you could add or subtract modules |
| 09:35 | <othermaciej> | I guess advocates of this approach would distinguish reusability and extensibility from forking |
| 09:35 | <othermaciej> | though forkability is really just reusability with arbitrarily fine granularity |
| 09:35 | <jgraham> | I don't see the practical difference |
| 09:36 | <jgraham> | In particular I don't see the difference from the point of view of IP |
| 09:36 | <othermaciej> | restricting the granularity of reuse may encourage greater pockets of interoperability (in theory) |
| 09:37 | <othermaciej> | it's funny to me that opinions on allowing forking per license, and on allowing free extension via "distributed extensibility" seem to be anticorrelated |
| 09:37 | <jgraham> | Yeah, that seems like a very theoretical outcome |
| 09:37 | <othermaciej> | with the exception of notable individuals like Sam Ruby, who favors allowing both, which strikes me as a laudably consistent set of views |
| 09:38 | <othermaciej> | (note: I mean that sincerely, not trying to be snarky in any way) |
| 09:38 | <hsivonen> | jgraham: wow. indeed the whole Modularization thing is interesting in the context of being scared of licenses that allow forking |
| 09:38 | <hsivonen> | jgraham: I had forgotten about Modularization |
| 09:38 | <jgraham> | hsivonen: Lucky you ;) |
| 09:38 | <hsivonen> | jgraham: :-) |
| 09:38 | <MikeSmith> | othermaciej: I'd never hear of HTML 4.0 Mobile either |
| 09:38 | <othermaciej> | I am amazed at how many different HTML forks have been published in some form by the W3C |
| 09:38 | <MikeSmith> | HTML 4.0 Mobile looks like a proto-"Mobile Web Best Practices" |
| 09:39 | <jgraham> | othermaciej: I don't think distributed extensibility and forking have much to do with each other really. At least the main arguments in favour of allowing forking aren't the same as the main arguments people use for DE |
| 09:39 | <othermaciej> | that's not even counting the mainline successor specs, even though you could argue that XHTML1 is an incompatible fork of HTML4, and perhaps likewise for XHTML 1.1 |
| 09:39 | <MikeSmith> | hmm, the did actually publish a HTML 4.0 Mobile DTD - HTML 4.0 Mobile |
| 09:39 | <MikeSmith> | http://www.w3.org/TR/1999/NOTE-html40-mobile-19990315/DTD/html40-mobile.dtd |
| 09:39 | <othermaciej> | HTML5 plausibly is a successor to HTML4 and XHTML1 so I'll give the W3C a pass on that |
| 09:40 | <othermaciej> | MikeSmith: yeah, I thought it might be a "best practices" but it has its own DTD |
| 09:40 | <MikeSmith> | yeah |
| 09:40 | <MikeSmith> | othermaciej: btw, you are right about CHTML and HDML, afaik -- I don't think they ever had any organizational support from any standards body at all |
| 09:41 | <othermaciej> | I mean, I was not around at the time |
| 09:41 | <othermaciej> | but from what I can tell, they were published in a totally unofficial way |
| 09:42 | <othermaciej> | oh hey, another fork, the html4all "HTML 4.1" draft: http://html4all.org/HTMLDraft.html |
| 09:44 | <espadrine> | I think crockford has its own html5 fork |
| 09:44 | <Lachy> | FWIW, developers.whatwg.org is also technically a fork |
| 09:44 | <MikeSmith> | crockford's draft is vaporware |
| 09:44 | <MikeSmith> | or vapor-spec |
| 09:44 | <Lachy> | espadrine, where is crockford's draft? |
| 09:45 | <MikeSmith> | http://www.crockford.com/html/ |
| 09:45 | <espadrine> | Lachy: no idea, but he said in a talk I saw that he did have it! |
| 09:45 | othermaciej | has CNN on in the background going on about Bin Laden |
| 09:46 | <espadrine> | MikeSmith: "That's it." Whaa, so soon? |
| 09:46 | <jgraham> | I think calling Crockford's effort a fork is insulting to all serious forkers everywhere |
| 09:46 | <abarth> | "No more framesets, frames, or iframes. The security properties of these were problematic. Instead we'll have modules." |
| 09:47 | <abarth> | "The only character encoding permitted in HTML 5 is UTF-8." <-- I like that part. |
| 09:48 | <othermaciej> | so I added a section for "W3C-published but disavowed forks" |
| 09:48 | <othermaciej> | I am not sure if XHTML2 should go in that section or in "W3C-hosted forks" |
| 09:49 | <othermaciej> | did the ex-XHTML2 folks ever follow through on their plan to continue development outside the W3C? |
| 09:50 | <jgraham> | (FWIW I think that wiki page would be better without all the nonsense about governments creating incompatible forks to restrict access to the web. There is only ~1 person who can possibly seriously believe that) |
| 09:50 | <MikeSmith> | othermaciej: not that I've heard |
| 09:51 | <Lachy> | That wiki page you're working on seems to be using a strange definition of forking. Many of those specs listed are not forks of previous specs, but rather newly created versions. |
| 09:52 | <othermaciej> | does JHTML count as an HTML fork: http://en.wikipedia.org/wiki/JHTML |
| 09:52 | <othermaciej> | Lachy: mostly they fork the language without textually forking a previous spec document |
| 09:52 | <Lachy> | but then, I guess that just proves that the W3C's fear of forks that could be prevented by stricter copyright are a very limited subset. |
| 09:53 | <othermaciej> | or how about FBML |
| 09:53 | <Lachy> | ok |
| 09:54 | <Lachy> | then I think it may be useful to more clearly distinguish between language forks and specification forks. The former would include ISO-HTML, EPUB, etc. The latter would include specs like developers.whatwg.org |
| 09:55 | <othermaciej> | by that standard, you could claim the HTML5 author view is a spec fork |
| 09:55 | <Lachy> | it is |
| 09:55 | <othermaciej> | but indeed, it is possible to fork the spec text without changing any normative requirements |
| 09:55 | <Lachy> | and it would be prevented by the W3C's strict licence |
| 09:55 | <jgraham> | Lachy: I think the point is that the supposed risks of forking are independent of whether one rewrites or one juct changes the existing text |
| 09:56 | <Lachy> | it's also an example of why the W3C should permit forking |
| 09:56 | <espadrine> | the dangerous part isn't about forking, it is the intent that the forker has |
| 09:56 | <espadrine> | if he just wants to confuse people, it will confuse people |
| 09:56 | <Lachy> | jgraham, yes, but it's also useful to show the examples of forking that are beneficial, in order to illustrate the risk of preventing forks |
| 09:57 | <othermaciej> | I can't find a spec for FBML that makes clear whether it is actually an HTML fork or not |
| 09:57 | <jgraham> | othermaciej: FBML was abandonded so I think it might be hard to find documentation |
| 09:57 | <othermaciej> | Wikipedia says it is a customized version of HTML with extra tags, but I can't verify that with facebook's docs |
| 09:58 | <jgraham> | They have now forked RDFa instead... |
| 09:58 | <jgraham> | (in the sense that their processing requirments are, by design, entirely different to those in the RDFa spec) |
| 09:58 | <abarth> | fbml is still used |
| 09:58 | <abarth> | e.g., for the like button |
| 09:59 | <jgraham> | Lachy: I agree |
| 09:59 | <abarth> | http://developers.facebook.com/docs/reference/plugins/like/ |
| 09:59 | <abarth> | <fb:like ref="top_left"></fb:like> |
| 09:59 | <jgraham> | Does it count as forking if you use colons? :) |
| 10:00 | <abarth> | that i can't tell you |
| 10:00 | <abarth> | but fbml uses lots of colons |
| 10:00 | <Lachy> | that looks more like "distributed extensibility" |
| 10:00 | <hsivonen> | colons are definitely distributed |
| 10:00 | <othermaciej> | it adds a bunch of tags with colons in them |
| 10:00 | <jgraham> | Although, having said the arguments in favour of the two are totally different, the arguments against forking also work against DE |
| 10:00 | <othermaciej> | what I am not sure of is whether you mix those with HTML, or use only the funky fb: tags |
| 10:00 | <abarth> | it also changes the semantics of existing tags |
| 10:00 | <abarth> | like <script> |
| 10:01 | <othermaciej> | abarth: do you know of anything close to a spec for this? |
| 10:01 | <jgraham> | Unless you think that the before-colon part is enough to avoid confusion or whatever |
| 10:01 | <othermaciej> | I wonder why all the anchors on CNN seem to have australian accents |
| 10:02 | <othermaciej> | or it might be kiwi accents, I'm not totally sure I can hear the difference |
| 10:03 | <Lachy> | othermaciej, what's the anchor's name? I'll tell you if (s)he is Aussie |
| 10:03 | <abarth> | XFBML |
| 10:03 | <abarth> | omg |
| 10:03 | <abarth> | http://developers.facebook.com/docs/reference/javascript/ |
| 10:03 | <abarth> | those script tags have really wonky semantics |
| 10:04 | <abarth> | but i'm not sure how much else they've changed about HTML semantics |
| 10:04 | <abarth> | i suspect they've changed things like autofocus |
| 10:04 | <abarth> | there isn't a spec so much as "try it on our site" |
| 10:04 | <othermaciej> | Lachy: they're not showing or mentioning their names |
| 10:06 | jgraham | wonders why Lachy has memorised all the Australian anchor's names on CNN |
| 10:09 | <hsivonen> | does anyone want to make predictions about the how Web pages will fail when the blink rate returned is -1? |
| 10:09 | <jgraham> | I predict that web pages won't fail because they won't use that API |
| 10:09 | <othermaciej> | that's assuming they try to use it to drive a timer? |
| 10:10 | <othermaciej> | what happens if you pass a negative number to setTimeout()? |
| 10:11 | <hsivonen> | othermaciej: assuming the most obvious failure wouldn't be Web-like. The Web can fail in more creative ways. :-) |
| 10:12 | <othermaciej> | I could certainly believe results like an infinite loop due to a poor termination condition |
| 10:14 | <hsivonen> | it would be rather tragic, though, if -1 lead to a seizure-inducing rate due to getting clamped to blinking avery 10 milliseconds. |
| 10:14 | <zcorpan> | hsivonen: i predict that it will fail in the following way: the page's background color will be hot pink instead of dark blue |
| 10:15 | <hsivonen> | zcorpan: let's file that away for the claim chowder |
| 10:15 | <jgraham> | I'm reasonably sure 10ms blinks wouldn't induce seziures in most photo-sensitive epileptics |
| 10:16 | <jgraham> | But I need a citation for that |
| 10:17 | <jgraham> | "Most people with photosensitive epilepsy are sensitive to 16-25 Hz, although some people may be sensitive to rates as low as 3 Hz and as high as 60 Hz." |
| 10:17 | <othermaciej> | Lachy: I think I'm watching Rosemary Church, who is indeed an ozzie |
| 10:17 | <jgraham> | http://www.epilepsy.org.uk/info/photosensitive-epilepsy |
| 10:18 | <othermaciej> | I wonder what the default frequencies are |
| 10:23 | <jgraham> | (I wonder how common it is to have caret-induced seziures in general. It seems that a person susceptible to such a stimulus would have a very high chance of having a seziure induce by many random things they would encounter in day to day life. Which is of course quite possible) |
| 10:23 | <Lachy> | jgraham, because a lot of the CNN anchors were formerly anchors on Australian News programs |
| 10:23 | <Lachy> | or are at least still used as foreign correspondants |
| 10:24 | <Lachy> | eg. Rosemary Church was on ABC News in Australia |
| 10:36 | <jgraham> | gprof is so slow :( |
| 10:40 | <MikeSmith> | hsivonen: fwiw, I implemented schematron checking for img alt exceptions |
| 10:40 | <MikeSmith> | it turned out less ugly than I thought it would be |
| 10:40 | <MikeSmith> | https://bitbucket.org/validator/syntax/changeset/cb28748fbe89 |
| 10:41 | <hsivonen> | MikeSmith: cool. I'll try to get to the Java review today. |
| 10:42 | <MikeSmith> | great if you can, but no rush |
| 10:47 | <hsivonen> | so if a Web author is implementing a pseudo-caret as a span outline/border and not as pixels on a canvas, the author needs to use canvas APIs to discover the desired blink rate? |
| 10:48 | <othermaciej> | hsivonen: Hixie's proposal is to put this API on the navigator object instead |
| 10:49 | <hsivonen> | othermaciej: ok. I guess I've lost track of all the proposals. did the placement on navigator get an objection yet? |
| 10:49 | <othermaciej> | I don't recall anyone objecting to it |
| 10:50 | <hsivonen> | exceptional |
| 10:50 | <jgraham> | Well people objected to having this API at all |
| 10:50 | <othermaciej> | but that's just an off-the-cuff statement, I did not double-check the email record |
| 10:50 | <othermaciej> | indeed, Jonas provided potential information to reopen the issue on the basis of objecting to this API |
| 10:50 | <othermaciej> | I believe Mac OS X has no obvious user-visible UI to set the caret blink rate |
| 10:51 | <othermaciej> | you can only change it via a hidden command-line setting |
| 10:51 | <othermaciej> | another command-line setting lets you turn off blinking entirely |
| 10:51 | <othermaciej> | I have not heard of anyone complaining about this |
| 13:05 | <zcorpan> | hmm. how come firefox doesn't support contenteditable in text/xml? |
| 13:06 | <zcorpan> | or application/xml, but does support it in application/xhtml+xml |
| 13:07 | <hsivonen> | zcorpan: Firefox predates the HTML5 requirement of having all Documents implement all the HTMLDocument, SVGDocument, etc., interfaces |
| 13:08 | <hsivonen> | zcorpan: and for whatever historical reason, only HTMLDocuments can be editable |
| 13:08 | <hsivonen> | zcorpan: or something like that |
| 13:08 | <zcorpan> | ah |
| 14:23 | <wilhelm_> | WTF. Take a look at the DOM of the first paragraph here: https://www.uka.no/program/oktoberfest2011/ |
| 14:23 | <wilhelm_> | Who comes up with that kind of madness? |
| 14:25 | <MikeSmith> | the <cufon> element is a clue |
| 14:26 | <MikeSmith> | Lord Cufon |
| 14:27 | <MikeSmith> | the Merciless |
| 14:27 | <hsivonen> | wilhelm_: I was rather surprised the first time I realized that Cufon works in Opera Mini |
| 14:27 | <wilhelm_> | MikeSmith: Looks like the guy is currently in Shinjuku. Could you please head over there with a baseball bat and say hello from me? |
| 14:28 | <MikeSmith> | I will look around the neighborhood for him |
| 14:28 | <wilhelm_> | Good, thanks. |
| 14:28 | <MikeSmith> | it's a small place so he should be easy to find |
| 14:28 | <wilhelm_> | Definitely. |
| 14:29 | <hsivonen> | I hope Cufon could be declared obsolete already, but Opera Mini is one browser where Cufon works but @font-face doesn't... |
| 14:29 | <MikeSmith> | hsivonen: Cufon is some real thing? |
| 14:29 | <hsivonen> | for some visual definition of "works" |
| 14:30 | <wilhelm_> | Yes, it's real: http://cufon.shoqolate.com/generate/ |
| 14:30 | <hsivonen> | MikeSmith: it's a Web font thing that predates wide @font-face support |
| 14:30 | <MikeSmith> | ah |
| 14:30 | <hsivonen> | IIRC, there are font foundries that like Cufon more than @font-face |
| 14:30 | <hsivonen> | which is really sad |
| 14:47 | <zcorpan> | shelley says there's a pending comment to approve, and Wordpress needs updating in the blog |
| 14:48 | hsivonen | looks for a comment to approve |
| 14:49 | <hsivonen> | ok. I approved the comment |
| 14:49 | <zcorpan> | thanks |
| 14:49 | <zcorpan> | i don't even know where to log in to the admin interface |
| 14:50 | <hsivonen> | I'll defer to Lachy on updating WP |
| 14:50 | <hsivonen> | hmm. maybe I could try the update... |
| 14:50 | <jgraham> | There isn't a link afaict. One has to try random page names until one remembers the right one |
| 14:50 | <hsivonen> | hmm. I think I'll leave updating to Lachy after all |
| 14:50 | <zcorpan> | Lachy: ^ |
| 14:51 | <Lachy> | hsivonen, WP should be able to update automatically if you just click the link in Dashboard |
| 14:51 | <hsivonen> | since I don't know how to make a backup of the data before updating |
| 14:51 | <hsivonen> | Lachy: yeah, but I don't know how to take any precautions |
| 14:52 | <Lachy> | I don't usually bother. I have DB backups emailed to me weekly, so we're protected there |
| 14:52 | <Lachy> | I updated it. |
| 14:52 | <hsivonen> | Lachy: thanks |
| 15:14 | <matjas_> | zcorpan: so efficient :’) |
| 15:25 | <zcorpan> | matjas_: heh |
| 15:28 | <MikeSmith> | jgraham: amen |
| 15:43 | <zcorpan> | is forums.whatwg.org slow for everyone or just me? |
| 15:51 | <zcorpan> | is http://dev.w3.org/html5/markup/ a fork? |
| 15:51 | <MikeSmith> | yeah, I suppose it is |
| 15:52 | <MikeSmith> | though it does not claim to be a technical specification |
| 15:52 | <MikeSmith> | it claims only to be a reference |
| 15:52 | <MikeSmith> | at this point |
| 15:52 | <MikeSmith> | one that does not normatively define anything |
| 15:52 | <zcorpan> | added to the wiki |
| 15:53 | <MikeSmith> | hmm, I think I should also make it more clear that http://dev.w3.org/html5/spec-author-view/ is non-normative |
| 15:54 | <Philip`> | Is http://w3c-test.org/html/tests/submission/PhilipTaylor/annotated-spec/canvas.html a fork? |
| 15:54 | <zcorpan> | yeah |
| 15:55 | <MikeSmith> | I have "Because this document does not provide implementation conformance criteria, UA implementors should not rely on it, but should instead refer to the full specification.", but I guess I should also have that part explicitly state, "This document is non-normative." |
| 15:55 | <zcorpan> | is that W3C-hosted or other? |
| 15:57 | zcorpan | goes for other |
| 16:56 | <MikeSmith> | zcorpan: fwiw, I don't think non-normative documents can really be considered forks |
| 16:56 | <MikeSmith> | though I guess they are in the context of the current license discussion |
| 16:58 | <jgraham> | "forks" is a misleading term |
| 16:58 | <jgraham> | What licenses care about is "derivative works" |
| 16:59 | <jgraham> | "forks" are what (some) people want to avoid |
| 16:59 | <jgraham> | attempting to prevent all "derivative works" seems to be their favoured method |
| 17:02 | <Lachy> | MikeSmith, a fork of a specification does not have to be a normative specification to be considered a fork, in the software development sense |
| 17:04 | <MikeSmith> | Lachy: says you |
| 17:04 | <Lachy> | MikeSmith, define fork? |
| 17:04 | <MikeSmith> | jgraham: yeah |
| 17:04 | <MikeSmith> | no |
| 17:04 | <MikeSmith> | can't be bothered |
| 17:05 | <jgraham> | Lachy: The sense in which github uses "fork" is not really the same as the older meaning |
| 17:05 | <Lachy> | MikeSmith, I just want to understand why you're excluding some derivative works that use the existing work as the basis as not being a fork |
| 17:06 | <jgraham> | The older meaning is a deliberate decison to create incompatible changes to a project without the intent to merge them back in |
| 17:06 | <jgraham> | or really with the intent not to merge them back in |
| 17:06 | <Lachy> | jgraham, that's basically the way I'm using it. |
| 17:07 | <Lachy> | but they don't necessarily have to be incompatible changes |
| 17:08 | <jgraham> | Lachy: Not really. A authoring guide that subsets the spec text isn't a fork; it doesn't compete with the original in any way. It is a derivative work however |
| 17:08 | <Lachy> | e.g. You could fork a piece of software, cut out some modules, and distribute it without any other modification to what was left it. That would still be a fork. |
| 17:08 | <Lachy> | there's no requirement about competing with the original |
| 17:08 | <jgraham> | I disagree |
| 17:09 | <Lachy> | "In software engineering, a project fork happens when developers take a legal copy of source code from one software package and start independent development on it, creating a distinct piece of software." -- Wikipedia |
| 17:09 | <jgraham> | Right. So a subset of a spec isn't independent |
| 17:09 | <jgraham> | It is tied to the original |
| 17:09 | <jgraham> | It is still a derivative work, however |
| 17:10 | <jgraham> | A new spec like HTML-Mobile is a fork |
| 17:10 | <jgraham> | It has independent requirments that the original didn't have |
| 17:11 | <jgraham> | It makes sense to distinguish these things because often people who dislike *forks* will nevertheless like some classes of *derivative work* |
| 17:11 | <jgraham> | So licenses that stop any derivative work will be less acceptable to them |
| 17:12 | <jgraham> | (this is more or less why the W3C has tried to come up with licenses that allow some derivative works but prevent forks) |
| 17:13 | <jgraham> | (but haven't dealt with the fact that many useful derivative works are OSS and the fact that the ability to fork itself is can be a positive thing) |
| 17:13 | <Lachy> | jgraham, no, there is no difference. A fork is simply a derivative work. It's just that some people are confused and think that a fork is a special subset of derivative works. |
| 17:13 | <jgraham> | Well I agree that some people are confused |
| 17:13 | <zewt> | well, "fork" in software terms usually implies competition: you don't like how software is maintained or they won't accept your patches, so you make a copy and try to get people to use it instead; a fork of a program often has a lot of overlap with the original |
| 17:13 | <jgraham> | I disagree about which set of people :) |
| 17:14 | <zewt> | forking a spec *can* have that effect ... but the ratio may be different, anyway |
| 17:16 | <zewt> | Lachy: taking a small subsection from a spec to use in your own is a derivative work, but I don't think I'd call it a fork |
| 17:16 | <zewt> | (you might call it a fork of that subsection, but I don't think that's how most people think of the term) |
| 17:20 | <Lachy> | zewt, you're just applying arbitrary restrictions to your definition of fork, and discounting the modifications that have been made in deriviative works like developers.whatwg.org |
| 17:20 | <zewt> | eh, no, I'm saying what the word "fork" means to most people |
| 17:20 | <zewt> | how, exactly, did I discount anything? |
| 17:21 | <zewt> | it's not "forking" that needs to be allowed, it's "arbitrary derivative works", whether it's a fork or anything else |
| 17:22 | <jgraham> | Lachy: applying "arbitary restrictions" to the definitions of words so that they mean a specific thing rather than all meaning very general things is often considered a desirable property of language |
| 17:25 | <gsnedders> | Lachy: The concept referred to by a referent will be different between different people, because denotation and connotation are not definite things, and vary over time. |
| 17:25 | <gsnedders> | Lachy: So expecting everyone to have the same denotations/connotations for referents as you is unrealistic |
| 17:25 | <zewt> | ... however, "derivative works" is a legal term, and while it likely varies by jurisdiction, it's far more clearly-defined than "fork" :) |
| 17:26 | <jgraham> | In other news gsnedders learnt some posh words in his langauge course :p |
| 17:26 | <gsnedders> | jgraham: Nothing I didn't know before (well, that's untrue, but I knew the above before :P) |
| 17:27 | <jgraham> | gsnedders: Well you're not really sayign anything particularly difficult |
| 17:27 | <jgraham> | Just dressing it up in a fancy way |
| 17:27 | <gsnedders> | jgraham: meh |
| 17:27 | <jgraham> | :) |
| 17:27 | <MikeSmith> | cours de linguistique générale |
| 17:31 | <Lachy> | jgraham, say for example, you take source of some free software, like VLC player. All you do is remove a few codecs you don't need/want to support and change the name/icon. Then you start distributing that. Is that a fork or not? |
| 17:31 | <zewt> | yes |
| 17:31 | <gsnedders> | I'd say no |
| 17:31 | <Lachy> | How is that different from taking the specification text, removing bits you don't need/want, changing the title, and then distributing that |
| 17:31 | <Lachy> | gsnedders, why? |
| 17:32 | <jgraham> | Lachy: If you're distributing the result *as a specification* I would call it a fork |
| 17:32 | <jgraham> | For the specification case |
| 17:33 | <jgraham> | Well it is a bit complex |
| 17:33 | <Lachy> | gsnedders, what about GNU IceCat vs. Firefox? Pretty much all they did there was change the branding to work around some licence restritions, and otherwise keep up with Firefox's modifications. Is that a fork or not? |
| 17:33 | <jgraham> | Certainly if you removed <canvas> and <img> and <video> and distributed the result as "Accessible HTML5" I would call that a fork |
| 17:34 | <zewt> | "fork" is a very fuzzy term; for what it's worth I don't think it should matter--you should be able to make derivative works for any purpose (including whatever each person's intuitive understanding of "fork" means) |
| 17:34 | <jgraham> | Lachy: (I would call the specific example of IceCat "petulant whining", but that could just be me) |
| 17:34 | <zewt> | heh |
| 17:35 | <gsnedders> | Lachy: I would claim a fork implies a branch that won't really be resynced. |
| 17:36 | <Lachy> | gsnedders, what about Ubuntu and Debian? Ubuntu gets resynced with Debian all the time, but is still a fork |
| 17:36 | <zewt> | (I suppose some part of my intuitive understanding of "fork" is the implication that it goes in a different direction--that development forks off and does something else--but that's all fuzzy and intuitive and subjective and all those things that have no place around licensing) |
| 17:36 | <jgraham> | Lachy: Ubuntu has long-lived changes |
| 17:36 | <jgraham> | it is only a partial resync |
| 17:37 | <gsnedders> | Lachy: what jgraham said |
| 17:48 | <MikeSmith> | Dear Mike, |
| 17:48 | <MikeSmith> | As a developer for HTML5, I would like to know why native support for Flash was not built-in like video and audio. HTML5 only hurts web developers by not supporting the most popular animation software ever created. |
| 17:48 | <MikeSmith> | Developers must now resort to writing Javascripts to add website animation much like back in the 90s. HTML5 appears to be a big backwards step for web standards. |
| 17:49 | <zewt> | does he write javascripts to manipulate his HTMLs? |
| 17:51 | <MikeSmith> | Joyent should trademark the phrase "Back to the future" |
| 17:58 | <TabAtkins> | > |
| 17:58 | <TabAtkins> | > |
| 17:58 | <TabAtkins> | > |
| 17:58 | <TabAtkins> | > |
| 17:58 | <jgraham> | < |
| 18:03 | <karlcow> | ⪥ |
| 18:06 | <TabAtkins> | Um. |
| 18:06 | <TabAtkins> | I... don't know how that happened. |
| 18:06 | <TabAtkins> | I was reading backlog when I apparently did it. |
| 18:11 | <miketaylr> | MikeSmith: seen at jsconf party last night (re: node.js TM) http://dl.dropbox.com/u/5821876/IMAG0605.jpg |
| 18:13 | <JoePeck> | does ValidityState typeMismatch make sense if an input type has a value sanitization algorithm? |
| 18:15 | <MikeSmith> | miketaylr: heh |
| 18:16 | <MikeSmith> | lovely |
| 18:16 | <miketaylr> | from one of the 'nodejitsu' guys shirts :) |
| 18:16 | <MikeSmith> | ah |
| 18:16 | <MikeSmith> | yeah, that figures |
| 18:17 | <MikeSmith> | those dudes are sharp |
| 18:17 | <MikeSmith> | well, most of them |
| 18:17 | <MikeSmith> | the ones I've met personally seem so |
| 18:18 | <MikeSmith> | the ones I've seen only on youtube videos and abusing the #Node.js channel less so |
| 18:18 | <MikeSmith> | but I guess I should shut up |
| 18:18 | <miketaylr> | haha |
| 18:18 | <miketaylr> | 'nuff said |
| 19:24 | <MikeSmith> | othermaciej: to be clear, that "requirement" that Larry mentions in his message is not one that there was ever any discussion or agreement about |
| 19:24 | <MikeSmith> | it made it into that Wiki page because he added it there |
| 19:24 | <AryehGregor> | Which requirement? |
| 19:25 | <othermaciej> | MikeSmith: I'm not going to get into it with Larry |
| 19:26 | <MikeSmith> | just like the stuff at http://trac.tools.ietf.org/area/app/trac/wiki/IriWorkGoals#HTML5EditorRequirements made it into that page because I added it there after he neglected to include it in the original version of the page when he created it |
| 19:26 | <MikeSmith> | othermaciej: yeah, understood |
| 19:46 | <MikeSmith> | AryehGregor: http://lists.w3.org/Archives/Public/public-iri/2011May/0000.html |
| 21:54 | <AryehGregor> | It's amazing how complicated something like "insertOrderedList" or "indent" can be. |
| 23:00 | <uf0> | . |
| 23:01 | <Hixie> | & |
| 23:02 | <tw2113> | ~ |
| 23:03 | <TabAtkins> | ` |
| 23:19 | <jamesr> | heycam: around? |
| 23:20 | <heycam> | hi jamesr |
| 23:20 | <jamesr> | heycam: i'm pretty sure i have a w3 account and whatnot, so i'm going to try committing to their mercurial |
| 23:21 | <jamesr> | i'm thinking for an initial draft to put this up: http://webstuff.nfshost.com/anim-timing/Overview.html but without the element argument as i'm not that happy with the text i have for that right now |
| 23:22 | <heycam> | jamesr, yeah I just got a mail from plh saying I didn't need a special account, since I'm in the relevant WG |
| 23:22 | <jamesr> | so requestAnimationFrame(), cancelRAF(), the timestamp stuff, and the invoke algorithm (to deal with cancellations) |
| 23:22 | <heycam> | jamesr, that sounds like a good starting place |
| 23:22 | <jamesr> | and then we can try to hash out some good normative text for the element visibility stuff on the mailing list |
| 23:22 | <heycam> | so the timestamp stuff |
| 23:22 | <jamesr> | of course i don't remember my w3 password :/ |
| 23:23 | <jamesr> | yeah! timestamps... |
| 23:23 | <heycam> | by that do you mean the argument to the callback? what about the attribute on the window object? (i can't remember if i removed that from my version, but boris was convincing me recently that it should stay.) |
| 23:23 | <jamesr> | the argument to the callback |
| 23:23 | <jamesr> | so another topic related to this is what the value should be |
| 23:24 | <jamesr> | i think it'd be really useful to provide a timestamp that was more reliable for intervals that javascript Date.now() is in the case where the system clock is adjusted, etc |
| 23:24 | <heycam> | aha |
| 23:24 | <jamesr> | i'm not entirely sure what Date.now() is supposed to do when the system clock is adjusted |
| 23:24 | <jamesr> | or where that is defined |
| 23:24 | <heycam> | yeah I only recently discovered that Date.now() isn't actually defined in the ES spec :) |
| 23:24 | <jamesr> | but for animation, it seems that most of the time you just want to know "how long was it since the start of the animation/since the last frame" |
| 23:24 | <zewt> | js is going to need a concept of a monotonic clock more and more |
| 23:24 | <heycam> | zewt, yeah |
| 23:25 | <heycam> | so they were talking abotu monotonic clocks on the list recently weren't they |
| 23:25 | <jamesr> | and if we have such a concept, then we definitely need a way to get at it globally |
| 23:25 | <jamesr> | yeah |
| 23:25 | <zewt> | don't recall |
| 23:25 | <jamesr> | they have some very very weak text in the navigation timing spec |
| 23:25 | <jamesr> | but it doesn't actually specify anything |
| 23:25 | <jamesr> | is there a normative definition of Date.now() anywhere? |
| 23:26 | <jamesr> | in chrome we have some fairly sophisticated logic behind that function to deal with the windows time APIs being complete dogshit |
| 23:26 | <zewt> | in the javascript/ecmascript specs, maybe? |
| 23:27 | <heycam> | oh it is in ES5 |
| 23:27 | <heycam> | I must have been thinking of something else that wasn't |
| 23:27 | <heycam> | http://people.mozilla.org/~jorendorff/es5.html#sec-15.9.4.4 |
| 23:27 | <jamesr> | well that's helpful :P |
| 23:28 | <jamesr> | so presumably if i do Date.now(), then move my system clock back by an hour, then call Date.now() again what do i get? |
| 23:28 | <heycam> | you get the earlier time, it seems from the spec |
| 23:28 | <jamesr> | does anyone implement that behavior? |
| 23:29 | <heycam> | without testing, I would've assumed that's what everyone implemented |
| 23:29 | <heycam> | since it's easier, and that's what it says to do |
| 23:29 | <zewt> | i'd be very surprised if I call "now" and I don't get now, according to the actual value of the clock |
| 23:29 | <heycam> | yeah :) |
| 23:30 | <zewt> | well, a clock--linux appears to have no less than 5 |
| 23:31 | <heycam> | iirc for Event.timestamp, gecko returns a number of milliseconds since document load |
| 23:31 | <heycam> | or something like that |
| 23:31 | <heycam> | which is monotonic |
| 23:31 | <heycam> | (monotonically increasing :)) |
| 23:32 | <heycam> | jamesr, so for getting the first revision of the spec up, I don't think we need to solve this, but we should discuss it on the list once it is up |
| 23:33 | <jamesr> | agree |
| 23:33 | <zewt> | would be nice to use a timestamp that can be filled in from a system clock, for example so input events can, if the system supports it, fill in the time of the actual hardware event rather than when it was received by the browser |
| 23:33 | <jamesr> | monotonic isn't quite enough |
| 23:33 | <jamesr> | has to be uniformly monotonically increasing |
| 23:33 | <heycam> | yes |
| 23:33 | <heycam> | you don't want your animation speeds to change |
| 23:33 | <zewt> | (eg. mapping directly to MONOTONIC or MONOTONIC_RAW in Linux) |
| 23:33 | <jamesr> | or freeze for a bit if the clock went backwards and you are just waiting for things to "catch up" |
| 23:34 | <heycam> | so maybe an offset from document load/start makes more sense than something that looks like it could be Date.now(), but could well get way out of sync with that |
| 23:34 | <zewt> | also using the system monotonic clock directly means timestamps between windows are comparable |
| 23:34 | <jamesr> | yeah, it's super confusing to have a number that will normally be very close to Date.now() |
| 23:34 | <jamesr> | starting at 0 in document load should help clear up a lot of confusion there |
| 23:35 | <heycam> | are you happy to do this initially fiddling to get the spec up? |
| 23:35 | <zewt> | could use 0 as the browser startup time (maybe +- a random value to avoid leaking info) to have consistent timestamps across windows |
| 23:36 | <zewt> | (they wouldn't be consistent across browser restarts, but that probably couldn't be guaranteed anyway) |
| 23:36 | <heycam> | consistent across windows... for keeping animations in iframes easily in sync with those in the parent document? |
| 23:36 | <jamesr> | i don't think http://webstuff.nfshost.com/anim-timing/Overview.html defines the timestamp value very well at all |
| 23:37 | <jamesr> | and i'm happy just leaving it that way until we figure out something better |
| 23:37 | <zewt> | well, i'm thinking in terms of a monotonic timer for general use across the platform |
| 23:37 | <jamesr> | zewt: what's the advantage of having it be in sync across documents? |
| 23:37 | <zewt> | being able to find out how much time passed between two events in general--it just seems like a natural property |
| 23:37 | <jamesr> | on multicore systems it's probably expensive to keep it in sync with too much precision |
| 23:38 | <zewt> | maybe on windows, not sure |
| 23:38 | <zewt> | on linux CLOCK_MONOTONIC(_RAW) does the work for you, iirc |
| 23:38 | <jamesr> | time is a very fluid concept on modern architectures at higher levels of precision |
| 23:43 | <jamesr> | i just have to figure out this workflow stuff |
| 23:43 | <heycam> | you're going with anolis? |
| 23:44 | <jamesr> | i dunno - i've never used any of these |
| 23:44 | <jamesr> | what do you recommend? |
| 23:45 | <heycam> | so, the xslt gunk I've got going there at the moment is reasonably simple to use, i.e. it doesn't do much magic processing to the input document |
| 23:45 | <heycam> | anolis plenty of people in here use, but I haven't used it myself personally |
| 23:45 | <heycam> | you could also go with ReSpec, berjon's client-side js spec formatter |
| 23:45 | <heycam> | I think they're the main feasible choices |
| 23:47 | <jamesr> | so to use your xslt thing what would files i need to check in? |
| 23:48 | <jamesr> | the Makefile, Overview.xml, Overview.html, and then which .css/.js files? |
| 23:48 | <heycam> | anim-timing.css, anim-timing.xsl, dfn.js, section-links.js |
| 23:49 | <heycam> | (and feel free to rename those first two to match the directory name if you wish) |
| 23:49 | <heycam> | the dfn.js/section-links.js are scripts from Hixie that pop up references when you click on a defining instance of a term |
| 23:49 | <jamesr> | and the workflow just "edit Overview.xml, make" |
| 23:50 | <heycam> | yeah |
| 23:50 | <heycam> | as long as you have xsltproc installed |
| 23:50 | <jamesr> | and i should be able to view both Overview.xml and Overview.html in an XSLT-supporting browser, right? |
| 23:50 | <heycam> | technically yes :) |
| 23:50 | <heycam> | there's a <?xml-stylesheet?> PI at the top of Overview.xml |
| 23:51 | <jamesr> | aight, sounds good |
| 23:51 | <heycam> | cool |
| 23:52 | <heycam> | thanks for doing the work here |
| 23:52 | <jamesr> | i guess the only downside is that the document you edit is XML instead of HTML, so i'll have to match my tags and all that other stuff |
| 23:52 | <heycam> | ah yeah |
| 23:52 | <heycam> | it probably isn't too much trouble to retrofit an html parser on the front of that toolchain if you really want :) |
| 23:56 | <jamesr> | parser error : Opening and ending tag mismatch |
| 23:56 | <jamesr> | gonna get used to that :P |
| 23:56 | <sephr> | I'm a little confused with classList/relList; iss element.classList/relList supposed to be a DOMTokenList or a DOMSettableTokenList? |
| 23:57 | <sephr> | or is it up to the implementor? |
| 23:57 | <sephr> | if so, why? It makes more sense to just make it always have to be DOMSettableTokenList |
| 23:58 | <jamesr> | are <p>s supposed to be self-closing in XML or encapsulate the paragraph? |
| 23:58 | <heycam> | jamesr, nothing is self closing in xml |
| 23:59 | <AryehGregor> | sephr, http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements-in-the-dom |
| 23:59 | <jamesr> | <p/> i mean |
| 23:59 | <AryehGregor> | sephr, that says DOMTokenList. |
| 23:59 | <AryehGregor> | Also here: http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element |
| 23:59 | <sephr> | thanks |
